Clarifying the behavior of `#[rustc_nounwind]` at trait methods

[dianqk]

Currently, #[rustc_nounwind] is only applied to functions that are explicitly annotated; it's neither required nor applied by default to all implementations. I have no objection to this, but I think we need to clarify what the expected behavior should be.

An alternative is:

If you apply #[rustc_nounwind] on a trait method, it should be fine to assume that all calls of this trait method don't unwind, right? If any of the implementations doesn't use #[rustc_nounwind], that should probably be reported as error. (from #137669 (comment) @bjorn3)

pub trait Trait {
    #[rustc_nounwind]
    fn m(&self, _: (i32, i32, i32));
}

impl Trait for () {
    fn m(&self, _: (i32, i32, i32)) {
        panic!();
    }
}

Based on the current behavior, there are some miscompile.
In the case of https://rust.godbolt.org/z/aTWsEMxWq, all invokes should be unwinding.

From #137669.

[compiler-errors]

I think it should be fine to just reject it on (trait) associated fns, do we apply to any today?

[dianqk]

I think it should be fine to just reject it on (trait) associated fns, do we apply to any today?

I agree. I believe it's not applied anywhere. I think #[rustc_nounwind] should only be used for trivial functions, and the following code is quite odd:

#[rustc_nounwind]
fn foo() {
    panic!()
}

[bjorn3]

#[rustc_nounwind] is also used for the global allocator and the unstable std::panic::abort_unwind function, both of which run arbitrary user code.