FCW for `#[panic_handler]` on `unsafe fn`. by theemathas · Pull Request #162974 · rust-lang/rust

theemathas · 2026-09-18T15:39:36Z

Mitigates #162967.

A function annotated with #[panic_handler] can be called by the compiler from anywhere. So, such functions must not have any safety preconditions.

A github search shows many crates that would run into this, so a hard error seems infeasible. If needed, I can modify the code in order to run crater to check how much code would be flagged by this FCW.

~~I have not yet created a proper tracking issue for the FCW. If this PR seems like the right direction, I will do so before merging.~~ I've created a tracking issue for this FCW at #163263

An LLM pointed me towards check_panic_info_fn and emit_node_span_lint (which I verified to be right). However, this PR is otherwise written manually.

rustbot · 2026-09-18T15:39:41Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 77 candidates
Random selection from 21 candidates

traviscross · 2026-09-23T16:35:24Z

Makes sense to me. Thanks @theemathas.

@rfcbot fcp merge lang

rust-rfcbot · 2026-09-23T16:35:27Z

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

tmandry · 2026-09-23T16:36:20Z

@rfcbot reviewed

rust-rfcbot · 2026-09-23T16:36:27Z

🔔 This is now entering its final comment period, as per the review above. 🔔

mejrs · 2026-09-24T23:03:23Z

@RalfJung That's at

rust/compiler/rustc_attr_parsing/src/attributes/codegen_attrs.rs

Line 574 in a92214c

fn finalize_check(cx: &FinalizeCheckContext<'_, '_>, attr_span: Span) {

. I considered putting the check somewhere around there, but it seems like it might be a mess? Not sure.

There's not a way to check that in attribute parsing, you don't get to look at the item the attribute is on, only what it is. You could wait for #162530 and implement it by checking AstTarget.

Does that make sense? I'm not sure, it seems there are a lot of these checks scattered around and I'm not sure what the best place is.

RalfJung · 2026-09-25T07:30:02Z

I thought we had a separate check was entirely independent of attribute parsing. But it seems things got moved and my knowledge is outdated. Never mind :)

mejrs · 2026-09-25T10:10:14Z

There is also the check_attr pass where such things usually are, especially if the checks need to use the tcx. Otherwise we'd like them to be in the attribute parser.

RalfJung · 2026-09-25T12:02:35Z

The point is that there is a family of functions (lang items, incl panic_handler) that need to reject a bunch of attributes (and non-attribute things like unsafe). Duplicating that across those attributes does not seem great.

rust-rfcbot · 2026-10-03T16:38:53Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

mejrs

r? me

r=me after rebase

View changes since this review

rustbot · 2026-10-04T09:07:49Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

theemathas · 2026-10-04T09:08:22Z

@bors r=mejrs rollup

rust-bors · 2026-10-04T09:08:26Z

📌 Commit 0ed52fa has been tentatively approved by mejrs

It will be put into the queue for this repository once PR CI succeeds.

…uwer Rollup of 6 pull requests Successful merges: - #162974 (FCW for `#[panic_handler]` on `unsafe fn`.) - #163627 (Add documentation for the `no_main` and `repr` attributes) - #163671 (Add `--frontend-threads` option to `./x perf`) - #163694 (c_str_alloc_error test: mention why this is mostly Miri-only) - #163711 (Stabilize `CStr::display`) - #163723 ([tiny] Remove useless `.into()` calls)

Rollup merge of #162974 - theemathas:fcw-unsafe-panic-handler, r=mejrs FCW for `#[panic_handler]` on `unsafe fn`. Mitigates #162967. A function annotated with `#[panic_handler]` can be called by the compiler from anywhere. So, such functions must not have any safety preconditions. A [github search](https://github.com/search?q=language%3Arust+%2F%23%5C%5Bpanic_handler%5C%5D%5Cnunsafe%2F&type=code) shows many crates that would run into this, so a hard error seems infeasible. If needed, I can modify the code in order to run crater to check how much code would be flagged by this FCW. ~~I have not yet created a proper tracking issue for the FCW. If this PR seems like the right direction, I will do so before merging.~~ I've created a tracking issue for this FCW at #163263 An LLM pointed me towards `check_panic_info_fn` and `emit_node_span_lint` (which I verified to be right). However, this PR is otherwise written manually.

theemathas added T-lang Relevant to the language team T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. labels Sep 18, 2026

rustbot assigned wesleywiser Sep 18, 2026

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 18, 2026

theemathas force-pushed the fcw-unsafe-panic-handler branch from 6e2584d to bdd65bd Compare September 18, 2026 15:49