Point at span within local macros even when error happens in nested external macro

[estebank]

Address issue noticed at https://users.rust-lang.org/t/error-message-does-not-specify-where-in-macro/135157/1. On errors occurring within a macro expansion, point at the innermost local macro expansion point.

error[E0308]: mismatched types
  --> $DIR/macro-span-caller-replacement.rs:5:17
   |
LL |             s = format!("{arg}");
   |                 ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL |     macro_with_format!();
   |     -------------------- in this macro invocation
   |
   = note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)

[rustbot]

rustc_errors::emitter was changed

cc @Muscraft

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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

[petrochenkov]

Not sure what's going on here.

The span is external, why is it reported? Because we cannot find its local parent call site?
Why is it reported twice now?

A number of tests show improvements similar to the macro-span-caller-replacement.rs case, but more tests show changes like this, which don't seem right.

[Muscraft]

I think this is caused by a bug/difference in how AnnotateSnippetEmitter handles annotations from files whose source is unavailable ("unannotated messages"). I have some changes locally that will hopefully address this issue.

[estebank]

The span is external, why is it reported? Because we cannot find its local parent call site?
Why is it reported twice now?

I think it is because it is now considered local from the point of view of the current module being shown, not from the span in the main subdiagnostic. There are now two spans because there's one pointing inside the macro and one pointing at the macro call. (You can see this when running these tests in an environment that has the std files available for rendering.)

I have some changes locally that will hopefully address this issue.

Are you also looking at making the ordering consistent? I don't think we used to do that. I also noticed that when we have multiple primary spans within different macros, we only point at a single macro call. I'm assuming that MultiSpan never accounted for its component Spans having different contexts. I wouldn't worry too much about that for now, but it's good that this change surfaced that.

[Muscraft]

Are you also looking at making the ordering consistent? I don't think we used to do that.

I'm not sure what ordering you are referring to here, but I can look into it if you give me a couple of examples.

I also noticed that when we have multiple primary spans within different macros, we only point at a single macro call. I'm assuming that MultiSpan never accounted for its component Spans having different contexts. I wouldn't worry too much about that for now, but it's good that this change surfaced that.

Could you also provide a couple of examples of this?

[estebank]

For context, this is what it looks like in a sane std environment:

error[E0277]: `*mut ()` can't be used as a const parameter type
    --> tests/ui/const-generics/adt_const_params/const_param_ty_bad.rs:11:11
     |
  11 |     check(&mut () as *mut ()); //~ error: `*mut ()` can't be used as a const parameter type
     |     ----- ^^^^^^^^^^^^^^^^^^ the trait `ConstParamTy_` is not implemented for `*mut ()`
     |     |
     |     required by a bound introduced by this call
     |
help: the trait `ConstParamTy_` is implemented for `()`
    --> /home/gh-estebank/workspace/rust/library/core/src/marker.rs:60:26
     |
  60 |           $(#[$($meta)*])* impl< $($($bounds)*)? > $Trait for $T {}
     |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
1098 | / marker_impls! {
1099 | |     #[unstable(feature = "adt_const_params", issue = "95174")]
1100 | |     ConstParamTy_ for
1101 | |         usize, u8, u16, u32, u64, u128,
...    |
1106 | |         {T: ConstParamTy_, const N: usize} [T; N],
1107 | | }
     | |_- in this macro invocation
note: required by a bound in `check`
    --> tests/ui/const-generics/adt_const_params/const_param_ty_bad.rs:4:18
     |
   4 | fn check(_: impl std::marker::ConstParamTy_) {}
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `check`
     = note: this error originates in the macro `marker_impls` (in Nightly builds, run with -Z macro-backtrace for more info)

And this is what it currently looks like:

error[E0277]: `*mut ()` can't be used as a const parameter type
    --> tests/ui/const-generics/adt_const_params/const_param_ty_bad.rs:11:11
     |
  11 |     check(&mut () as *mut ()); //~ error: `*mut ()` can't be used as a const parameter type
     |     ----- ^^^^^^^^^^^^^^^^^^ the trait `ConstParamTy_` is not implemented for `*mut ()`
     |     |
     |     required by a bound introduced by this call
     |
help: the trait `ConstParamTy_` is implemented for `()`
    --> /home/gh-estebank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/marker.rs:1098:1
     |
1098 | / marker_impls! {
1099 | |     #[unstable(feature = "adt_const_params", issue = "95174")]
1100 | |     ConstParamTy_ for
1101 | |         usize, u8, u16, u32, u64, u128,
...    |
1106 | |         {T: ConstParamTy_, const N: usize} [T; N],
1107 | | }
     | |_^
note: required by a bound in `check`
    --> tests/ui/const-generics/adt_const_params/const_param_ty_bad.rs:4:18
     |
   4 | fn check(_: impl std::marker::ConstParamTy_) {}
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `check`
     = note: this error originates in the macro `marker_impls` (in Nightly builds, run with -Z macro-backtrace for more info)

[petrochenkov]

This example does look convincing, it's unfortunate that our tests suite is not representative here.
But it would be similarly annoying to update tests outputs on miscellaneous changes to the standard library, so it seems similar to LL:COL line number anonymization.

[petrochenkov]

r=me with CI fixed and commits squashed.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Why does this need normalization? Does the output differ between targets?

[estebank]

It looks like it: f3b52fd

[RalfJung]

Oh I see, I misread the regex. Makes sense, thanks.

[estebank]

@bors r=petrochenkov

[bors]

📌 Commit 7339e67 has been approved by petrochenkov

It is now in the queue for this repository.

[Zalathar]

Possibly failed in rollup: #149820 (comment)

@bors r-

[Zalathar]

@bors try jobs=x86_64-gnu-llvm-21-3

[rust-bors]

💔 Test for e546dea failed: CI. Failed jobs:

• try - x86_64-gnu-llvm-21-3 (web logs, enhanced plaintext logs)

[rustbot]

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.

[estebank]

@bors r=petrochenkov

[bors]

📌 Commit 1bd7934 has been approved by petrochenkov

It is now in the queue for this repository.