Rust: Pluggable panic implementations (tracking issue for RFC 1513)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1513.

-C panic=abort is now stable, but the ability to create customized panic implementations is still unstable.

[alexcrichton]

I'm working on an implementation.

[mrpollo]

is there a branch we can track? @alexcrichton, thanks!

[alexcrichton]

Sure! -- https://github.com/alexcrichton/rust/tree/panic2abort

[ketsuban]

Will I still need a dummy eh_personality lang item after this goes through? Some googling suggests -Z no-landing-pads was supposed to remove the need for it (for example, this regression report led to this issue which was resolved by this PR) but I only started using Rust for OSdev since it went stable and I've always needed eh_personality even with -Z no-landing-pads.

[alexcrichton]

@Ketsuban it depends. If you use any library compiled with -C panic=unwind (like the binaries we ship) then you'll need to define eh_personality. If, however, you compile everything with -C panic=abort then you shouldn't need to define a personality.

[alexcrichton]

I've opened a PR for this.

[alexcrichton]

Ah I should leave this open as the tracking issue

[phil-opp]

The corresponding cargo option is still missing, isn't it? From the RFC:

Add a [profile.dev] option to Cargo to disable unwinding.

[alexcrichton]

@phil-opp indeed! I was just waiting for a new nightly but now I've got a PR for that as well

[steveklabnik]

cargo PR has landed. should this be closed?

[alexcrichton]

Nah this is sticking around as the tracking issue for panic runtimes in general. Only the -C panic=abort portion is stable, however.

[aidanhs]

Is it intentional/known that anything with plugin = true (i.e. has --crate-type dylib -C prefer-dynamic on the command line to rustc) doesn't work in combination with -C panic=abort?

[alexcrichton]

@aidanhs I believe that's https://github.com/rust-lang/cargo/issues/2738

[brson]

The only remaining thing here is the stable mechanism for plugging in new unwinders, which is not a priority.

[Ericson2314]

And which should probably wait for some needs-provides functionality to be implemented or avoided.

[Ericson2314]

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile. The other profile options do not (to my knowledge) change ABI or semantics so it is inconsistent to put the panic strategy in there. The target spec as per https://github.com/rust-lang/rust/issues/36647 is a better home for the time being.

[japaric]

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile.

What would be the ideal way to pick the panic strategy then? Would it be something like this? (assuming abort is the default and you want to switch to panic=unwind):

• executable that depends on std. List std as dependency but enable std's "unwind" Cargo feature
• executable that doesn't depends on std. Either depend on the panic_unwind crate or some other crate that provides an unwinder.
• library that wants to indicate that relies on unwinding: depend on std with the "unwind" feature enabled or depend on panic_unwind.

Plus some magic attribute in panic_unwind that causes Cargo to compile everything (std included) with landing pads.

[hanna-kruppe]

@Ericson2314

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile.

How would that work? Leaving aside the issue that it would be a breaking change, per-profile panic strategies are useful: For unit tests you _need_ panic=unwind if you have #[should_panic] tests, but having unit tests is certainly not mutually exclusive with wanting panic=abort in release builds.

[Ericson2314]

Here are some ideas:

For the low-level panic ABI stuff (abort/unwinding)

I've been thinking that crates should be able to assert a cfg/scenario formula, and that this formula can be used during dependency solving. [lib]/[bin]/[test]/whatever can each have their own formulas. The panic-abi stuff, since it is part of the target, can be mentioned in those formulas.

Additionally, [bin],[test], etc, since they form a depenency root, could be allowed to specify a default target inline, which could be a diff on one of the built-in defaults.

For high-level strategies

@japaric that's the basic idea, but a proper-needs provides solution should make that slicker. https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst is a proposal for Haskell that basically gives it parameterized packages. For "global/singleton" things panic strategies and log, we need to make a "needer" package for them that must be instantiated exactly 1 way in the install plan.

It's a huge undertaking (Backpack is a PHD thesis), but would be the pinnacle of everything we are trying to do build-system-wise for exotic platform development.

[Centril]

cc @japaric is this fully done now that #[panic_handler] is stabilized? should we close?

[japaric]

@Centril That depends on whether we want to use this issue to track a stable mechanism for implementing unwinding in no_std (right now you have to use the unstable eh_personality lang item), or if we want to do that in another issue, perhaps in a rust-lang/rfcs issue.

[Centril]

@japaric can you raise this on internals perhaps (and close this issue after...)? I'd like to avoid reusing tracking issues and rather keep their scope tightly delimited.

[Dylan-DPC]

@japaric any update on this?