Mark the panic_no_unwind lang item as nounwind #93489
Conversation
rustbot
added
the
T-compiler
|
r? @lcnr (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
cc @nbdd0121 |
|
r? @nagisa maybe don't know enough here |
| // unwind. If the panic handler that it invokes unwind then it will simply | ||
| // call the panic handler again. | ||
| if Some(id) == tcx.lang_items().panic_no_unwind() { | ||
| codegen_fn_attrs.flags |= CodegenFnAttrFlags::NEVER_UNWIND; |
There was a problem hiding this comment.
Could we use #[rustc_allocator_nounwind] instead? There's nothing allocator-specific for that attribute even though it has allocator in its name.
There was a problem hiding this comment.
If we did this, I would suggest renaming the attribute.
There was a problem hiding this comment.
I agree that this should be an attribute (or possibly a extern "Rust-nounwind" ABI?). I've been away this past week and haven't had time to implement this yet, but it is on my TODO list.
|
@bors r+ I think its okay if we rely on language items to figure out what attributes we want to add to specific ones since we do that already quite pervasively. I can see us using a dedicated attribute once we have one. Right now what we have is pretty arbitrarily scoped to specific component of the standard library and I'm not entirely sure its a responsibility of this PR to adapt it to be more general. @Amanieu your description mentions soundness improvements. Do you think this is something that should appear in the relnotes? |
|
📌 Commit f738669 has been approved by |
bors
added
S-waiting-on-bors
|
This is only reachable with nounwind functions ( |
…askrgr Rollup of 2 pull requests Successful merges: - rust-lang#90998 (Require const stability attribute on all stable functions that are `const`) - rust-lang#93489 (Mark the panic_no_unwind lang item as nounwind) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This has 2 effects:
panic_no_unwind.PanicInfo::can_unwindreturns true. This will simply cause another panic once the unwind tries to go past thepanic_no_unwindlang item. Eventually this will cause a stack overflow, which is safe.