Re: Editing a vendored crate for a try push
On Tuesday, April 10, 2018 at 8:45:57 AM UTC-5, Ted Mielczarek wrote: > On Mon, Apr 9, 2018, at 7:18 AM, Henri Sivonen wrote: > > What's the current status of tooling for editing vendored crates for > > local testing and try pushes? > > > > It looks like our toml setup is too complex for cargo edit-locally to > > handle (or, alternatively, I'm holding it wrong). It also seems that > > mach edit-crate never happened. > > > > How do I waive .cargo-checksum.json checking for a crate? > > I don't think we have any tooling around this currently. bug 1323557 is still > open but hasn't seen any real movement. I did test a potential workflow last > year[1] that worked at the time, but recent comments suggest that it no > longer works. I haven't tried it again with a newer cargo/rustc so I don't > know what the errors are, but if that no longer works we should figure out if > we can fix whatever broke it. > > -Ted > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1323557#c3 FWIW we added suppot to Cargo awhile back to be able to directly edit the vendored crates where they live in third_party so long as `[patch.crates-io]` was provided at the workspace level indicating "yes, I'm editing this". The main change required there was we had to tweak Cargo.toml as it was published to crates.io. That means that only newly published crates are 100% compatible, and there may still be some historical versions that have been published since this was changed in Cargo. If something is required beyond [patch.crates-io], though, to modify third-party sources please feel free to file a bug on Cargo! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads
Hello! I do agree it is indeed bad to spawn a new thread for all calls into Rust :). You likely don't want a custom panic handler [1], however, as those are actually more appropriately called "hooks" (just renamed [2]). Instead, the `std::panic::recover` function [3] is what you'll want for the FFI use case. This is essentially a "catch" block which will prevent the panic from aborting the process and allow you to handle the case that the code panicked properly (for example poisoning state, propagating the error to C++, etc). This way you avoid spawning a thread for all calls into Rust and it's far cheaper to create a stack frame to catch a panic. This function is currently unstable, but it is up for stabilization [4] in the 1.9 release (perhaps with a new name). It should be available immediately on nightly for experimenting, however. Let me know if that doesn't make sense or if you need any more info! [1]: https://github.com/rust-lang/rust/issues/30449 [2]: https://github.com/rust-lang/rust/pull/32282 [3]: http://doc.rust-lang.org/std/panic/fn.recover.html [4]: https://github.com/rust-lang/rust/issues/27719 On Tuesday, March 22, 2016 at 6:04:25 AM UTC-7, Henri Sivonen wrote: > It seems that the Rust MP4 parser is run a new Rust-created thread in > order to catch panics. Once we introduce Rust code that intermingles > with C++ more, it won't be practical to put all potentially panicing > Rust code into dedicated threads. > > Can we install a custom panic function that detects whether it's > running on a Rust-created thread and performs a normal Rust panic if > it is and performs a MOZ_CRASH if not (i.e. if it is on a > non-Rust-created thread)? > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads
Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I believe) as it's just normal execution. If you want a panic in Rust to translate to an abort of the entire process, however, then you've got two options. On one hand you could use the custom panic hook support I mentioned above to install a hook that aborts the process. That way it would prevent reaching the machinery that actually throws an exception in Rust to be caught. An alternative is outlined in RFC 1513 [1] which is to configure compilations to always trigger an abort on panic instead of doing it via a roundabout method. Does that make sense? [1]: https://github.com/rust-lang/rfcs/pull/1513 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads
> My code doesn't currently use panic::recover. What > happens when somebody doesn't use it and an exception hits the FFI > boundary? Undefined behavior? Technically, yes, undefined behavior. It's specifically undefined to unwind past an FFI boundary. Practically on Linux this will abort the process so long as there's no C++ stack frame that's trying to catch an exception. > What is the timeline for getting this stabilized? The panic hook support is likely to become stable in 1.9, the RFC I mentioned would likely be later as it needs to be accepted, implemented, and then stabilized. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads
> Ok, so that should be released in about 2 months, right? I believe so, yes! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mapping Rust panics to MOZ_CRASH on non-Rust-created threads
> I think for release builds, we should have the following: Thanks for this information! For reference, I've responded on the RFC to the technical bits here. https://github.com/rust-lang/rfcs/pull/1513#issuecomment-200626686 > On Wed, Mar 23, 2016 at 7:38 PM, Ralph Giles wrote: > > so unwinding through FFI is > > something we need to think about. > > I'd much prefer we didn't have to think about it. Since the semantics > of panic!() are "game over", it makes sense to map it to MOZ_CRASH() > to remove the possibility of cross-FFI unwinding. FWIW I agree that this is likely the best way to think of panics in Gecko ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
