Support `#[track_caller]` on EII declarations by cezarbbb · Pull Request #158535 · rust-lang/rust

cezarbbb · 2026-06-29T03:52:54Z

Tracking issue: #125418
Zulip thread: Zulip

#[track_caller] is currently rejected on EII declarations by the catch-all in split_attrs. This routes it onto the foreign item and
derives it onto every implementation during codegen.

The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — check_attr already rejects #[track_caller] on EII implementations (EiiWithTrackCaller), since the attribute is part of the ABI.

The flag is then derived onto each implementation in codegen_attrs: if the foreign item is #[track_caller], every impl gets the flag too. The shim in add_function_aliases takes its ABI from the impl's fn_abi, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute.

#[track_caller] on a foreign item is an already-supported path (see tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs); this just wires it into EII. Statics are unaffected — #[track_caller] isn't a valid target on statics and is rejected as before.

r? @jdonszelmann @bjorn3

rustbot · 2026-06-29T03:52:59Z

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

cezarbbb · 2026-07-08T07:46:38Z

Summarizing the Zulip thread for context, there are two directions came up. One requires #[track_caller] symmetrically on both decl and impl, rejecting mismatches. The other propagates the flag from the decl onto every impl during codegen (mirroring how trait impls already inherit #[track_caller] from the trait declaration via should_inherit_track_caller, without the impl writing it), with a possible trampoline follow-up for the decl-without/impl-with case.

The discussion landed on propagation, which is what this PR implements. Adding/removing #[track_caller] isn't a semver break today (the compiler handles it transparently), so there's no need to treat it as part of the signature that decl and impl must explicitly match. The trampoline was agreed to be a follow-up, not part of this PR.

@jdonszelmann whenever you have capacity, could you take a look?

bjorn3 · 2026-07-08T09:00:16Z

+                    // its ABI from the impl's `fn_abi`, so every impl must agree on whether the
+                    // caller-location argument is present, otherwise it would be silently dropped.
+                    if tcx
+                        .body_codegen_attrs(foreign_item)


The foreign_item would never be a const or global asm block if this code is reached, right? So you should be able to use codegen_fn_attrs directly.

View changes since the review

bjorn3 · 2026-07-08T14:16:22Z

r? bjorn3

bjorn3 · 2026-07-09T08:43:36Z

@bors r+

rust-bors · 2026-07-09T08:43:39Z

📌 Commit 5c33d50 has been approved by bjorn3

It is now in the queue for this repository.

@jdonszelmann

Support `#[track_caller]` on EII declarations Tracking issue: rust-lang#125418 Zulip thread: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Questions.20about.20support.20.60.23.5Btrack_caller.5D.60.20on.20EII.20declaration) `#[track_caller]` is currently rejected on EII declarations by the catch-all in `split_attrs`. This routes it onto the foreign item and derives it onto every implementation during codegen. The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — `check_attr` already rejects `#[track_caller]` on EII implementations (`EiiWithTrackCaller`), since the attribute is part of the ABI. The flag is then derived onto each implementation in `codegen_attrs`: if the foreign item is `#[track_caller]`, every impl gets the flag too. The shim in `add_function_aliases` takes its ABI from the impl's `fn_abi`, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute. `#[track_caller]` on a foreign item is an already-supported path (see `tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs`); this just wires it into EII. Statics are unaffected — `#[track_caller]` isn't a valid target on statics and is rejected as before. r? @jdonszelmann @bjorn3

…uwer Rollup of 17 pull requests Successful merges: - #158510 (Enable `static_position_independent_executables` on all gnu and musl targets) - #158541 (Move `std::io::Write` to `core::io`) - #158899 (Fix `unaligned_volatile_store` by removing `MemFlags::UNALIGNED`) - #155429 (Support `u128`/`i128` c-variadic arguments) - #156370 (Reject linked dylib EII default overrides) - #157153 (allow `Allocator`s to be used as `#[global_allocator]`s) - #158535 (Support `#[track_caller]` on EII declarations) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158645 (Fix splat ICEs and ban it in closures) - #158988 (Redo `TokenStreamIter`) - #158347 (Improve generic parameters handling for #[diagnostic::on_const]) - #158722 (delegation: do not always inherit `ConstArgHasType` predicates) - #158739 (view-types: HIR lowering) - #158883 (tests: fix enum-match.rs to handle LLVM 23) - #158886 (Add documentation for the `no_std` attribute) - #158951 (Merge three `MaxUniverse`s into one) - #158961 (Reapply "LLVM 23: Run AssignGUIDPass in some places")

JonathanBrouwer · 2026-07-09T13:04:23Z

@bors try jobs=aarch64-apple

JonathanBrouwer · 2026-07-09T13:04:29Z

@bors r-

Support `#[track_caller]` on EII declarations try-job: aarch64-apple

rust-bors · 2026-07-09T13:04:35Z

This pull request was unapproved.

View changes since this unapproval

rust-bors · 2026-07-09T14:25:38Z

💔 Test for 69d1e2b failed: CI. Failed job:

try - aarch64-apple (web logs, enhanced plaintext logs)

JonathanBrouwer · 2026-07-10T10:40:18Z

@bors r-

rust-bors · 2026-07-10T10:40:22Z

This pull request was unapproved.

View changes since this unapproval

cezarbbb · 2026-07-13T02:27:41Z

A silly mistake. The line numbers in .stderr are not updated synchronously when comments are modified.
@JonathanBrouwer I think it's ok now.
@rustbot ready

bjorn3 · 2026-07-13T10:02:58Z

@bors r+

rust-bors · 2026-07-13T10:03:06Z

📌 Commit e9273fc has been approved by bjorn3

It is now in the queue for this repository.

@jdonszelmann

Support `#[track_caller]` on EII declarations Tracking issue: rust-lang#125418 Zulip thread: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Questions.20about.20support.20.60.23.5Btrack_caller.5D.60.20on.20EII.20declaration) `#[track_caller]` is currently rejected on EII declarations by the catch-all in `split_attrs`. This routes it onto the foreign item and derives it onto every implementation during codegen. The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — `check_attr` already rejects `#[track_caller]` on EII implementations (`EiiWithTrackCaller`), since the attribute is part of the ABI. The flag is then derived onto each implementation in `codegen_attrs`: if the foreign item is `#[track_caller]`, every impl gets the flag too. The shim in `add_function_aliases` takes its ABI from the impl's `fn_abi`, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute. `#[track_caller]` on a foreign item is an already-supported path (see `tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs`); this just wires it into EII. Statics are unaffected — `#[track_caller]` isn't a valid target on statics and is rejected as before. r? @jdonszelmann @bjorn3

…uwer Rollup of 13 pull requests Successful merges: - #159039 (resolve: fix effective visibilities for items in ambiguous glob sets) - #157706 (Deny `todo!()` in tidy) - #156712 (Pointer authentication config and user facing options) - #158535 (Support `#[track_caller]` on EII declarations) - #158632 (First steps of late-bound turbofishing (place FnDef behind a dummy binder)) - #159002 (Small refactorings in `need_type_info` module) - #159202 (Bump rustc-demangle to 0.1.28) - #159216 (Avoid using probe self_ty for delegation arguments) - #159222 (semicolon_in_expressions_from_macros: Lint on non-local macros too) - #156609 (Consider structurally impossible Sized predicates in MIR) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158998 (Some minor ast validation and visiting cleanups) - #159123 (doc: clarify attr parser APIs)

@jdonszelmann

Support `#[track_caller]` on EII declarations Tracking issue: rust-lang#125418 Zulip thread: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Questions.20about.20support.20.60.23.5Btrack_caller.5D.60.20on.20EII.20declaration) `#[track_caller]` is currently rejected on EII declarations by the catch-all in `split_attrs`. This routes it onto the foreign item and derives it onto every implementation during codegen. The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — `check_attr` already rejects `#[track_caller]` on EII implementations (`EiiWithTrackCaller`), since the attribute is part of the ABI. The flag is then derived onto each implementation in `codegen_attrs`: if the foreign item is `#[track_caller]`, every impl gets the flag too. The shim in `add_function_aliases` takes its ABI from the impl's `fn_abi`, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute. `#[track_caller]` on a foreign item is an already-supported path (see `tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs`); this just wires it into EII. Statics are unaffected — `#[track_caller]` isn't a valid target on statics and is rejected as before. r? @jdonszelmann @bjorn3

…uwer Rollup of 14 pull requests Successful merges: - #159039 (resolve: fix effective visibilities for items in ambiguous glob sets) - #157706 (Deny `todo!()` in tidy) - #158535 (Support `#[track_caller]` on EII declarations) - #158632 (First steps of late-bound turbofishing (place FnDef behind a dummy binder)) - #158846 (Fix unused variable warnings for diverging expressions) - #159002 (Small refactorings in `need_type_info` module) - #159202 (Bump rustc-demangle to 0.1.28) - #159216 (Avoid using probe self_ty for delegation arguments) - #159222 (semicolon_in_expressions_from_macros: Lint on non-local macros too) - #156609 (Consider structurally impossible Sized predicates in MIR) - #157993 (Expose more info about ADTs and functions in rustc_public) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158998 (Some minor ast validation and visiting cleanups) - #159123 (doc: clarify attr parser APIs)

@jdonszelmann

Support `#[track_caller]` on EII declarations Tracking issue: rust-lang#125418 Zulip thread: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Questions.20about.20support.20.60.23.5Btrack_caller.5D.60.20on.20EII.20declaration) `#[track_caller]` is currently rejected on EII declarations by the catch-all in `split_attrs`. This routes it onto the foreign item and derives it onto every implementation during codegen. The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — `check_attr` already rejects `#[track_caller]` on EII implementations (`EiiWithTrackCaller`), since the attribute is part of the ABI. The flag is then derived onto each implementation in `codegen_attrs`: if the foreign item is `#[track_caller]`, every impl gets the flag too. The shim in `add_function_aliases` takes its ABI from the impl's `fn_abi`, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute. `#[track_caller]` on a foreign item is an already-supported path (see `tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs`); this just wires it into EII. Statics are unaffected — `#[track_caller]` isn't a valid target on statics and is rejected as before. r? @jdonszelmann @bjorn3

…uwer Rollup of 15 pull requests Successful merges: - #159039 (resolve: fix effective visibilities for items in ambiguous glob sets) - #157706 (Deny `todo!()` in tidy) - #156047 (Fix trait method resolution on an adjusted never type) - #158535 (Support `#[track_caller]` on EII declarations) - #158632 (First steps of late-bound turbofishing (place FnDef behind a dummy binder)) - #158846 (Fix unused variable warnings for diverging expressions) - #159002 (Small refactorings in `need_type_info` module) - #159202 (Bump rustc-demangle to 0.1.28) - #159216 (Avoid using probe self_ty for delegation arguments) - #156609 (Consider structurally impossible Sized predicates in MIR) - #157993 (Expose more info about ADTs and functions in rustc_public) - #158804 (Clarify `as_uninit_mut` may point to uninitialized memory) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158998 (Some minor ast validation and visiting cleanups) - #159123 (doc: clarify attr parser APIs)

…uwer Rollup of 13 pull requests Successful merges: - #157706 (Deny `todo!()` in tidy) - #158535 (Support `#[track_caller]` on EII declarations) - #158632 (First steps of late-bound turbofishing (place FnDef behind a dummy binder)) - #158846 (Fix unused variable warnings for diverging expressions) - #159002 (Small refactorings in `need_type_info` module) - #159202 (Bump rustc-demangle to 0.1.28) - #159216 (Avoid using probe self_ty for delegation arguments) - #156609 (Consider structurally impossible Sized predicates in MIR) - #157993 (Expose more info about ADTs and functions in rustc_public) - #158804 (Clarify `as_uninit_mut` may point to uninitialized memory) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158998 (Some minor ast validation and visiting cleanups) - #159123 (doc: clarify attr parser APIs)

@jdonszelmann

Rollup merge of #158535 - cezarbbb:eii-track-caller, r=bjorn3 Support `#[track_caller]` on EII declarations Tracking issue: #125418 Zulip thread: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Questions.20about.20support.20.60.23.5Btrack_caller.5D.60.20on.20EII.20declaration) `#[track_caller]` is currently rejected on EII declarations by the catch-all in `split_attrs`. This routes it onto the foreign item and derives it onto every implementation during codegen. The foreign item is the symbol callers link against, so it must carry the flag for call sites to append the caller location. It is routed onto the foreign item only, not the default impl — `check_attr` already rejects `#[track_caller]` on EII implementations (`EiiWithTrackCaller`), since the attribute is part of the ABI. The flag is then derived onto each implementation in `codegen_attrs`: if the foreign item is `#[track_caller]`, every impl gets the flag too. The shim in `add_function_aliases` takes its ABI from the impl's `fn_abi`, so if any impl lacked the flag the caller-location argument would be silently dropped rather than reported as a type error. Deriving it keeps default and explicit impls in sync without requiring users to repeat the attribute. `#[track_caller]` on a foreign item is an already-supported path (see `tests/ui/rfcs/rfc-2091-track-caller/track-caller-ffi.rs`); this just wires it into EII. Statics are unaffected — `#[track_caller]` isn't a valid target on statics and is rejected as before. r? @jdonszelmann @bjorn3

rustbot assigned jdonszelmann Jun 29, 2026

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 29, 2026

This comment has been minimized.

Sign in to view

cezarbbb force-pushed the eii-track-caller branch from dc7acb0 to e1e75ea Compare June 29, 2026 06:13

bjorn3 reviewed Jul 8, 2026

View reviewed changes

bjorn3 added the F-extern_item_impls `#![feature(extern_item_impls)]` label Jul 8, 2026

rustbot assigned bjorn3 and unassigned jdonszelmann Jul 8, 2026

cezarbbb force-pushed the eii-track-caller branch from e1e75ea to 5c33d50 Compare July 9, 2026 01:20

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 9, 2026

JonathanBrouwer mentioned this pull request Jul 9, 2026

Rollup of 17 pull requests #159007

Closed

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 9, 2026

Auto merge of #158535 - cezarbbb:eii-track-caller, r=<try>

69d1e2b

Support `#[track_caller]` on EII declarations try-job: aarch64-apple

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 9, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 10, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 10, 2026

rust-bors Bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 10, 2026

Support #[track_caller] on EII declarations

e9273fc

cezarbbb force-pushed the eii-track-caller branch from 35163c9 to e9273fc Compare July 13, 2026 00:59

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 13, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 13, 2026

JonathanBrouwer mentioned this pull request Jul 13, 2026

Rollup of 13 pull requests #159231

Closed

JonathanBrouwer mentioned this pull request Jul 13, 2026

Rollup of 14 pull requests #159236

Closed

JonathanBrouwer mentioned this pull request Jul 13, 2026

Rollup of 15 pull requests #159240

Closed

JonathanBrouwer mentioned this pull request Jul 13, 2026

Rollup of 13 pull requests #159246

Merged

rust-bors Bot merged commit 153165d into rust-lang:main Jul 13, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Jul 13, 2026

cezarbbb deleted the eii-track-caller branch July 14, 2026 01:00

Uh oh!

Uh oh!

Conversation

cezarbbb commented Jun 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 29, 2026

Uh oh!

This comment has been minimized.

cezarbbb commented Jul 8, 2026

Uh oh!

bjorn3 Jul 8, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorn3 commented Jul 8, 2026

Uh oh!

bjorn3 commented Jul 9, 2026

Uh oh!

rust-bors Bot commented Jul 9, 2026

Uh oh!

JonathanBrouwer commented Jul 9, 2026

Uh oh!

JonathanBrouwer commented Jul 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 9, 2026

Uh oh!

rust-bors Bot commented Jul 9, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

JonathanBrouwer commented Jul 10, 2026

Uh oh!

rust-bors Bot commented Jul 10, 2026

Uh oh!

cezarbbb commented Jul 13, 2026

Uh oh!

bjorn3 commented Jul 13, 2026

Uh oh!

rust-bors Bot commented Jul 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

cezarbbb commented Jun 29, 2026 •

edited by rustbot

Loading

bjorn3 Jul 8, 2026 •

edited by rustbot

Loading