Implement RFC 2945: "C-unwind" ABI

[cratelyn]

Implement RFC 2945: "C-unwind" ABI

This branch implements RFC 2945. The tracking issue for this RFC is #74990.

The feature gate for the issue is #![feature(c_unwind)].

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

Changes

Further details will be provided in commit messages, but a high-level overview
of the changes follows:

• A boolean unwind payload is added to the C, System, Stdcall,
  and Thiscall variants, marking whether unwinding across FFI boundaries is
  acceptable. The cases where each of these variants' unwind member is true
  correspond with the C-unwind, system-unwind, stdcall-unwind, and
  thiscall-unwind ABI strings introduced in RFC 2945 [3].

• This commit adds a c_unwind feature gate for the new ABI strings.
  Tests for this feature gate are included in src/test/ui/c-unwind/, which
  ensure that this feature gate works correctly for each of the new ABIs.
  A new language features entry in the unstable book is added as well.

• We adjust the rustc_middle::ty::layout::fn_can_unwind function,
  used to compute whether or not a FnAbi object represents a function that
  should be able to unwind when panic=unwind is in use.

• Changes are also made to
  rustc_mir_build::build::should_abort_on_panic so that the function ABI is
  used to determind whether it should abort, assuming that the panic=unwind
  strategy is being used, and no explicit unwind attribute was provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @varkor (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[varkor]

r? @Amanieu

[bors]

☔ The latest upstream changes (presumably #76582) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[nikomatsakis]

Looking good to me so far!

[cratelyn]

Cross-posting from the #project-ffi-unwind zulip channel:

I am bumping into some platform-specific CI errors that I'll sort out, hopefully on Monday? In any case, that's the shape of the implementation of RFC 2945 🎉 I'll mark it as a formal PR, rather than a draft, once I've appeased CI 😊

[nikomatsakis]

The changes look good. One thing I am wondering about is when we call C-unwind functions that are implemented in, well, C. In other words, I think we should have a test for the fastly use case, where we invoke a C function that invokes a Rust function which panics, and we test that this panic propagates up the stack. I'm not sure how easy/hard it will be to write such a test though, including C code might be a pain. At minimum we could have a test for panics propagating through Rust functions with C-unwind ABI (and perhaps the same but where those functions are in an auxiliary crate).

(Cross crate tests can be created by using the // aux-build: comments in tests; I didn't find any docs on this, but you can maybe grep around to see how it's done. You basically write // aux-build: foo.rs and then add a file auxiliary/foo.rs. You can then import the crate foo.)

[Mark-Simulacrum]

For C functions to call, I believe https://github.com/rust-lang/rust/blob/master/src/test/auxiliary/rust_test_helpers.c is the place to add it to -- that file is compiled once and then linked with all UI tests I believe. Or, if you need more complex invocations of C compilers or linkers then run-make tests are the way to go.

[nikomatsakis]

Ah, nice. I didn't know about that.

[bors]

☔ The latest upstream changes (presumably #75671) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[cratelyn]

Providing a small update. These two tests are currently failing, because of an undefined reference to rust_eh_personality'`. I'm not quite sure why that's happening, but I'm planning to look into it tomorrow.

failures:
    [ui] ui/allocator/no_std-alloc-error-handler-custom.rs
    [ui] ui/allocator/no_std-alloc-error-handler-default.rs

Aside from that, I want to add the tests described in the comments above, and then this should be in good shape.

[Mark-Simulacrum]

I've seen both those tests fail locally too when using lld as the linker, so I would check without your PR. It's quite possible that it's unrelated to your work :)

[BatmanAoD]

Interesting... it may be the case that "C unwind" can't be supported in a no_std environment, because there won't be exception-handling infrastructure available on the target.

[bors]

☔ The latest upstream changes (presumably #78837) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[cratelyn]

Leaving another note here for posterity...

One of the key design goals specified in RFC 2945 is stated as such:

Enable foreign exceptions to propagate through Rust frames: Similarly, we would like to make it possible for C++ code (or other languages) to raise exceptions that will propagate through Rust frames "as if" they were Rust panics (i.e., running destrutors or, in the case of unwind=abort, aborting the program).

This appears to have already been implemented in 5f1a0af, and has test coverage in src/test/run-make-fulldeps/foreign-exceptions. I'll refrain from duplicating these tests, since they already seem to exercise that goal well enough.