Permit unwinding through FFI by default

[cuviper]

This repeats #62505 for master (Rust 1.38+), as #58794 is not yet resolved. This is a stopgap until a stable alternative is available, like RFC 2699, as long as progress is being made to that end.

r? @joshtriplett

[RalfJung]

To be clear, this allows extern C functions to unwind and it does not set the nounwind attribute for them? So there's lots of platform-specific concerns, but at least not outright UB?

[cuviper]

@RalfJung no, this has no effect on the nounwind attribute, maintaining the (questionable) status quo that we've been releasing with so far. The only effect here is whether we add a cleanup block to non-Rust-ABI functions, so it forces an abort on panic/unwinding.

I believe nounwind is controlled here:

rust/src/librustc_codegen_llvm/attributes.rs

Lines 278 to 286 in 2eb0bc5

	if cx.tcx.is_foreign_item(id) {
	// Foreign items like `extern "C" { fn foo(); }` are assumed not to
	// unwind
	false
	} else if sig.abi != Abi::Rust && sig.abi != Abi::RustCall {
	// Any items defined in Rust that *don't* have the `extern` ABI are
	// defined to not unwind. We insert shims to abort if an unwind
	// happens to enforce this.
	false

[bors]

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

[cuviper]

Rebased.

[Alexendoo]

Ping from triage: Any updates? @joshtriplett

[cuviper]

A new beta 1.38 has branched -- @joshtriplett what's your preference here? Are we ready to land this on master and then nominate for beta? Or should I do another beta-targeted PR?

[bors]

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

[wirelessringo]

Ping from triage. @cuviper please resolve the merge conflicts. Thanks.

@rustbot modify labels to +S-waiting-on-author, -S-waiting-on-review

[RalfJung]

I believe nounwind is controlled here:

Could you expand this PR to also remove the nounwind then? We keep applying this on beta, which is silly -- but IMO applying this patch while still emitting nounwind is also a bad idea.

With that change, I will nominate this for lang-team discussion.

[RalfJung]

Ideally, that code (deciding about the LLVM unwind attribute) would call should_abort_on_panic. Not sure if that is possible.

EDIT: Hm, this is odd -- the code tests for CodegenFnAttrFlags::UNWIND but I am not sure how that relates to Rust's UnwindAttr.

EDIT2: Looks like the code here permits a function to unwind if any unwind attribute is present, including unwind(aborts)?!?

[RalfJung]

Looks like #48380 repurposed the attribute, but some old users still treat is as basically a boolean. I think CodegenFnAttrFlags::UNWIND should be removed, and from_fn_attrs should just call should_abort_on_panic to make sure that it only ever adds nounwind when we really do the abort-on-panic. I can do this in a separate cleanup PR, maybe?

[RalfJung]

See #63884 for fixing how we control the nounwind attribute. If both that PR and this one land, that will correctly stop adding nounwind to extern "C" fn.

[cuviper]

@RalfJung - Thanks for tackling the other side of this!

I've rebased this PR, and I got a verbal r+ to go ahead at RustConf. I'll also nominate for beta since we missed the branch.

@bors r=joshtriplett

[bors]

📌 Commit 367b793 has been approved by joshtriplett

[bors]

⌛ Testing commit 367b793 with merge 4c58535...

[bors]

☀️ Test successful - checks-azure
Approved by: joshtriplett
Pushing 4c58535 to master...

[pnkfelix]

based on my interpretation of the recent Lang Team meetings (including the one last night), I am going to unilaterally accept this for a beta backport, due to time pressure with a release in two weeks. @joshtriplett shares this interpretation of the lang team meetings.

(The other motivating detail is that, the way things are now, if we do not beta-backport this, then we will have breakage that is solely on the current beta, not in stable nor master, which means we'd be scheduling one cycle of breakage.)

(I'm pretty sure there was some sort of process failure along the way here that led to a breakdown in our normal procedure, probably due to a conflation of how this PR is semi-coupled with PR #63909, the question of which teams should have been tagged to each PR, etc...)

[cuviper]

Thanks @pnkfelix -- the backport is underway in #64438.