fix nounwind attribute logic

[RalfJung]

With #62603 landed, we no longer add abort-on-panic shims to extern "C" functions. However, that means we should also not emit nounwind for extern fn because we are not actually catching those panics. The comment justifying that nounwind in the source is just factually wrong.

I also noticed that we annotate extern declarations (of any ABI) with nounwind, which seems wrong? I removed this. Code like mozjpeg (the code that prompted the removal of the abort-on-panic shim) throws a panic from Rust code that enters C code (meaning the extern "C" definition must not have nounwind, or else we got UB), but then the panic bubbles through the C code and re-enters Rust code (meaning the extern "C" declaration that gets called from the Rust side must not have nounwind either).

This should be beta-backported if #62603 gets backported.

TODO: add test case for #63943.

[rust-highfive]

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

This part of the test seems dubious to me. Wouldn't code that bubbles Rust panics through C (the kind of code for which #62603 got merged) also have an extern "C" declaration like this where the panic enters back into Rust?

[RalfJung]

We don't have a stable vs nightly difference in semantics. That would be a bad mess.

We document panicking from extern "C" as UB, but (similar to #62825) are willing to patch things such that code exploiting this UB is not broken until we provide adequate alternatives to said code.

So, I think this function should not be unwind. I am waiting for @alexcrichton to confirm.

[gnzlbg]

So, I think this function should not be unwind

This is right. The check should say CHECK-NOT: nounwind.

[alexcrichton]

I believe this is correct, all imported FFI functions, by default, should be tagged with nounwind

[RalfJung]

But doesn't this mean that when e.g. mozjpeg calls C that calls Rust (the situation due to which #62603 was accepted), and a panic passes from C to Rust, we still violate nounwind?

This PR removes the nounwind on the first edge the panic crosses (Rust -> C), but there's another edge (C -> Rust) and we should not have nounwind there either.

[gnzlbg]

This PR removes the nounwind on the first edge the panic crosses (Rust -> C), but there's another edge (C -> Rust) and we should not have nounwind there either.

Yes, that's correct, that is, the check should be CHECK-NOT: nounwind. Otherwise, the second example in #63943, which is equivalent to mozjpeg use case, would still be miscompiled.

[RalfJung]

Okay, I have implemented that.

[gnzlbg]

I also noticed that we annotate extern "Rust" declarations with nounwind, which seems wrong?

Yeah, that sounds like a big bug. cc @eddyb (I think we discussed that at some point?)

---

This fixes a soundness bug that causes mis-compilations, and is IMO release notes worthy. cc @Centril

[gnzlbg]

So I've left some comments, under the assumption that this primarly targets master, and therefore Rust nightly. Some of the tests would be incorrect for beta/stable, because there the semantics differ. I mentioned that in the comments, but I don't know how best to adress that. I think it would probably make sense to add what makes sense for nightly here, and tune the tests for stable Rust when doing the beta backport.

[RalfJung]

So I've left some comments, under the assumption that this primarly targets master, and therefore Rust nightly. Some of the tests would be incorrect for beta/stable, because there the semantics differ.

How do they differ? #62603 has landed on master and I am assuming will be backported to beta. So the semantics should be the same.

[RalfJung]

This fixes a soundness bug that causes mis-compilations, and is IMO release notes worthy.

Which mis-compilations does this fix? I do not know of any.

[gnzlbg]

On my machine using stable Rust 1.37.0:

extern "C" fn bar() -> ! { panic!("lolz") }
extern "C" fn baz() -> i32 {
    if let Ok(_) = std::panic::catch_unwind(|| bar() ) {
        unsafe { std::hint::unreachable_unchecked() }
    }
    42
}
fn main() { std::process::exit((baz() != 42) as i32); }

returns success with cargo run --release but fails with RUSTFLAGS="-C lto=fat" cargo run --release. If I change bar to:

fn bar() -> ! { panic!("lolz") } // no extern "C"

then it always works.

If unwinding from extern "C" should be supported, e.g., for Rust->C->Rust FFI, then the code above should always work.

This means that for Rust->C-Rust, adapting the code above to the following:

// foo.cpp
using fn_type = void(*)();
[[ noreturn ]] extern "C" void foo(fn_type x);
[[ noreturn ]] extern "C" void foo(fn_type x)  { x(); /* unreachable: */ throw 0; }

// main.rs
extern "C" { fn foo(x: extern "C" fn() -> !) -> !; }
extern "C" fn bar() -> ! { panic!("lolz") }
extern "C" fn baz() -> i32 {
    if let Ok(_) = std::panic::catch_unwind(|| unsafe { foo(bar) }) {
        unsafe { std::hint::unreachable_unchecked() }
    }
    42
}
fn main() {
   std::process::exit((baz() != 42) as i32);
}

should also always return success, but like the example above, it returns success with cargo run --release but fails with RUSTFLAGS="-C lto=fat" cargo run --release. Removing extern "C" from bar fixes it.

That is, AFAICT, as long as we make extern "C" function definitions nounwind, Rust->C->Rust is unsound, and examples like this get miscompiled on stable Rust. It looks like this PR should actually fix that - otherwise, there is another issue somewhere else breaking Rust->C->Rust FFI.

[RalfJung]

returns success with cargo run --release but fails with RUSTFLAGS="-C lto=fat" cargo run --release

Good catch!
Still, we don't usually put all soundness fixes into the release notes, do we?

That is, AFAICT, as long as we make extern "C" function definitions nounwind, Rust->C->Rust is unsound, and examples like this get miscompiled on stable Rust. It looks like this PR should actually fix that - otherwise, there is another issue somewhere else breaking Rust->C->Rust FFI.

This PR does fix that, doesn't it?

[gnzlbg]

Still, we don't usually put all soundness fixes into the release notes, do we?

I don't know, no idea who decides that. I thought this might at least be interesting enough for that.

This PR does fix that, doesn't it?

I haven't tried a patched compiler - will try when this lands on nightly unless somebody beats me to it.

[cuviper]

@gnzlbg Note that we've removed the abort-unwind behavior difference between nightly/beta/stable, per #62505 (comment) -> #62603.

[gnzlbg]

@gnzlbg Note that we've removed the abort-unwind behavior difference between nightly/beta/stable, per #62505 (comment) -> #62603.

Ah! I did not know. Sorry @RalfJung , my comments are all wrong, they were referring to the old nightly-only behavior.

[estebank]

@rust-lang/compiler this is outside of my wheelhouse.

[estebank]

r? @alexcrichton

[alexcrichton]

In its current state this seems like it's undoing an optimization which has been in rustc for quite some time? I was under the impression that it was well known that extern imported functions (and defined functions in Rust) are undefined behavior if they unwind. This looks to be fixing that situation but this has historically been a relatively important optimization for some scenarios.

[Centril]

@rfcbot concern lets-not-increase-de-facto-reliance-meanwhile

I noted in #63909 (comment) and in conversations with @joshtriplett (where I also said I'd leave such a concern on FCP-merge...) that:

Based on recent discussion in rust-lang/rfcs#2753 I think the idea of reaching quick consensus and stabilization on that RFC was overly optimistic. Therefore, I'd like for this to remain UB (i.e. the PR should not land) as I believe a prolonged time within which we don't emit nounwind will just increase reliance on us not doing so.

Also, situations like noalias (although that was due to LLVM bugs) suggests that once we remove these attributes it becomes increasingly hard to readd them.

I strongly disagree. Landing #62603 and not landing my PR here feels disingenious -- I am aware that that is not your intent, but putting on the hat of a Rust language user, that is the message that would come across to me. The lang team should take a stance and either respect or not respect the existing UB-exploiting code -- whereas right now, we are somewhat respecting it but then not really: landing #62603 indicates "we respect your use-case", but then not landing this PR here means we still are happily risking subtle miscompilations in such code. These are very contradicting signals we are sending here, which is no good.

I don't respect the existing UB-exploiting code. I think I've made that clear before that I do not agree with "people need to do their jobs" based reasoning. On a social level, I find that objectionable behavior to do so knowingly and it leads to "tragedy of the commons" situation. There are differences of opinion on the language which is why there are contradicting signals. What I think we're really agreeing to at the moment is "keeping the status quo". I should note that when I FCP-ed #58794 (comment), I expected this to be a mere formality.

The story would be different if there is a big benefit to actually telling LLVM about this bit of Rust-level UB -- but so far, all we have in that regard are claims that the optimization is important, but no data. The perf results for this PR are negative (as in, no perf change); rustc is not the heaviest user of FFI but it does a fair bit of FFI to LLVM so I think this is not an entirely silly benchmark either.

@gnzlbg seems to be of a different opinion re. noalias here at least. I would also like to not end up in a situation where we de-facto stabilize the ABI.

You were also not using performance impact as an argument, making it seem like you want to use miscompilations(*) as a means to "teach users a lesson", which I consider one of the worst possible reasons to miscompile code -- in particular because landing #62603 teaches the opposite lesson.

I don't think that not actively facilitating reliance on spec-UB is "teaching users a lesson".

Note that this is not about using UB to disincentivize users to use some feature; you are proposing to risk actual breakage in the compiled code. All I want to do is remove that risk. There is no spec change involved here. This PR does not change what is UB in Rust.

When you have a single compiler, not-rustc-UB tends to translate into not-spec-UB over time.

And just to reiterate, I would be totally on board with closing this PR if we re-enable the abort-on-panic shims, and if we do it for real (i.e., let it ride the trains to stable).

That would be my preference but that option seems foreclosed until we have a stable alternative.

Meanwhile, we feel that merging this will actually provide motivation to make that progress, as it removes an optimization opportunity. We would very much like to see that optimization opportunity reclaimed.

I disagree with this rationale. First, I think it puts pressure on the wrong people. Second, I think this will contribute to stress and rushing through a sub-optimal solution because time is running out. I don't think either of those are a good idea.

---

I would not like to spend further language team meeting time discussing this as it seems clear to me that it would not change things and the time is better spent on other things, e.g. figuring out a stable alternative.

[BatmanAoD]

First, I think it puts pressure on the wrong people.

Maybe this is just a poor choice of phrase, but are you suggesting that there are people on whom there should be more pressure? If so, why?

I do not agree with "people need to do their jobs" based reasoning.

I haven't heard this phrase before; do you mind explaining what kind of reasoning you're objecting to?

[Centril]

Maybe this is just a poor choice of phrase, but are you suggesting that there are people on whom there should be more pressure? If so, why?

What I think is that more pressure should not be laid on the folks who benefit from the optimization. Keeping the status-quo of pressure on folks who do rely on what we have said is UB is (acceptable) fallout from that.

I haven't heard this phrase before; do you mind explaining what kind of reasoning you're objecting to?

I object to the reasoning that it's socially acceptable to rely on things that are explicitly UB "because there's no other way to do it" and that "folks need to do their jobs". Lotsa folks need to do their job but such a reliance may be detrimental to other users, the lang team, etc. Also, who determines "what you want to do is reasonable"? Folks have varying opinions on that... e.g. some think a fully stable ABI is reasonable (I don't).

[RalfJung]

Also, situations like noalias (although that was due to LLVM bugs) suggests that once we remove these attributes it becomes increasingly hard to readd them.

I see no parallel here. No noalias violations that we have currently would have been prevented by keeping the attribute in. They got detected only because Miri was able to catch them, not because of miscompilations; and some of them predate the noalias removal.

I don't respect the existing UB-exploiting code.

Then we should add the abort-on-panic shim and call it done.

The current situation is not a middle-ground. It is a "both sides are worse off" kind of situation.

I don't think that not actively facilitating reliance on spec-UB is "teaching users a lesson".

Well, I am not sure which other terms to use for your argument here. The main argument I could extract so far is "if we don't do this, it could happen that someone else might also start doing what mozjpeg already does". I think that argument can be rephrased as "we should use de-facto (not de-jure!) UB as a teaching device" (the kind of teaching device that hurts you when you do the wrong thing). Maybe I missed other arguments you made?

FWIW, this argument I mentioned is not backed by data (quite the contrary: it's been many months since we first reverted the abort-on-panic shim and no new users came up), and I don't even see the thing it wants to prevent as a big problem (we are not changing our intentions to re-add the attribute once the shim is back in place). I see miscompilations in production code as a much bigger problem.

When you have a single compiler, not-rustc-UB tends to translate into not-spec-UB over time.

I see little to no evidence for that. In the UCG discussions, a lot of the UB we are considering is not-de-facto UB. For example, barely any of our aliasing rules are de-facto UB right now, and still the general reception of Miri being very strict about checking these rules is positive.

I object to the reasoning that it's socially acceptable to rely on things that are explicitly UB "because there's no other way to do it" and that "folks need to do their jobs". Lotsa folks need to do their job but such a reliance may be detrimental to other users, the lang team, etc. Also, who determines "what you want to do is reasonable"? Folks have varying opinions on that... e.g. some think a fully stable ABI is reasonable (I don't).

Language design involves (amongst others) trade-offs between the interests of the language designers and its users -- and in your consideration, I see no indication that user's interests are taken into account. I would be entirely on-board with your reasoning if this was a research language, but I think for a language that wants to be a foundational piece of infrastructure, this kind of no-compromise attitude will do more harm than good.

The picture you are painting of Rust users is an adversarial one: if we give in an inch by not making LLVM exploit this UB any more, they'll jump on that and completely disregard the intentions behind that change.

This picture does not at all reflect my experience. Most of the time my impression is that users understand the language design concerns around UB, and understand that we want to keep our options open; my discussions along those lines have mostly been constructive (there are exceptions, of course). Users don't want to halt Rust language development, but they also want to use Rust to do "something" and sometimes, only after doing all the work they realize that what they want to do is not (de-jure) possible in Rust.

To speak more concretely, I am regularly talking with users about Stacked Borrows or validity invariants; much of that is de-jure but not de-facto UB and it is also much more fuzzy than nounwind. For example, for validity invariants, the current de-jure UB contradicts our own advice from two years ago (mem::uninitialized)! I expected a lot of pushback, people saying "this always used to work, it should still work". But mostly, people were just happy that we gave them precise rules, even if that requires changing the entire ecosystem to use MaybeUninit. So, if anything, the data we have indicates that we can constructively work with our users and turn de-jure into de-facto UB once we give them a proper migration path and help them detect UB (all of which is given for nounwind, much more so than for uninitialized data). The same kinds of conversations happened for Stacked Borrows.

So, I think your worry is unfounded. I doubt there will be a lot of pushback against re-adding the attribute and the abort-on-panic shim once one of the RFCs lands; if past experience tells us anything, people will just be happy that finally there are some proper rules for what they want to do.

[BatmanAoD]

Thank you very much for your comment. I do have one small correction.

it's been many months since we first reverted the abort-on-panic shim and no new users came up.

There are several users of cross-language unwinding participating in RFC 2753 (though to be fair, they may have been doing so since before the abort revert). In particular, @acfoltzer has explained how Lucet uses this functionality and is helping draft the RFC text itself.

[acfoltzer]

I doubt there will be a lot of pushback against re-adding the attribute and the abort-on-panic shim once one of the RFCs lands; if past experience tells us anything, people will just be happy that finally there are some proper rules for what they want to do.

As one of the people who would benefit in the interim from the lack of nounwind, I can confirm that I'll be absolutely thrilled to ditch that behavior once an RFC lands. After all, it'll hopefully contain some of my own text 😂

[pnkfelix]

discussed at T-compiler meeting. This is not yet landed in nightly and we are not going to beta backport this before the upcoming release next week.

As I understand it, landing #62603 and not landing #63909 is in fact maintaining status quo

Therefore we are declining to beta backport.

[pnkfelix]

So when I originally skimmed over this PR and its description, I was under the impression that it only addressed bugs in "safe code" that arose in cases where you had Rust calling into C (and then from there potentially back into Rust, which then may be the cause of a root panic).

And that impression may or may not be correct. I'm not sure yet ...

... but what I do know is that this fixes a bug in some code which has no such back-and-forth calling between Rust and C (at least not at the surface level; though there may be some in the stdlib), namely this example adapted from #64655:

struct Droppable;
impl Drop for Droppable { fn drop(&mut self) { println!("Dropping a Droppable"); } }
fn main() { let _guard = Droppable; None::<()>.expect("???"); }

I'd like to understand why this PR fixes that bug.

---

But in the meantime, even absent such understanding on my part, I also think we should just land this PR. The case illustrated above is not some subtle interaction between C and Rust; at least, not from the user's perspective.

[pnkfelix]

Okay thanks to the comment thread on this issue I have lots of fun variants on my previous example.

• (and I have posted an explanation for why this PR fixes Drop implementations not being called on panic with Fat LTO. #64655 in a comment over there.)

[RalfJung]

Looks like we are unable to decide that we want to protect users like mozjpeg from UB while the RFC process bikeshed is ongoing. That makes me sad. :(

But I guess there's no point in leaving this PR open, then.