Mention first and last macro in backtrace

[compiler-errors]

Slight improvement to diagnostic mentioning what macro an error originates from. Not sure if it's worthwhile.

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[nagisa]

Yeah, not entirely sure either. On one hand the first macro is going to be underlined already so naming it is probably not adding all that much in terms of new information.

But if we do go forward with it I would probably rephrase the message to “first macro! which eventually expands to last macro!”...

r? @estebank may have stronger opinions either way.

[estebank]

I think it is worth it because when the text doesn't refer to the code as written, it confuses people. Having that extra redundancy makes it clearer what's going on. I agree that using "expands" instead of "calls" is better.

r=me after that change

[compiler-errors]

@bors r=estebank

[bors]

📌 Commit 1075d8b7c27ae83b5e484f1b0cd0caf5858e2948 has been approved by estebank

[compiler-errors]

@bors r-

[estebank]

@bors r+

[bors]

📌 Commit 5b3f391 has been approved by estebank

[matthiaskrgr]

@bors r-
this needs clippy tests updated: #98689 (comment)

[camsteffen]

Suggested change

	= note: this error originates in the macro `println` which expands to macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info)
	= note: this error originates in the macro `$crate::format_args_nl` which is expanded from the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

I think it would be better to name the inner macro first?

[compiler-errors]

I think I prefer the outer macro first, because that's the one the user is actually familiar with.

[camsteffen]

That is not always the case though, right? It might even be more common for errors to occur in user-written macros.

[compiler-errors]

I'm not sure if I understand. The first macro in the macro expansion is the one that's present in surface code -- presumably the user is familiar with it (or at least has seen it before) because they had to have written it for it to appear in code. The last macro in the expansion, at least for foreign macros, is less likely to be familiar because it can be some detail or inner macro. I don't think it's as useful to mention it first, since I'm worried the user's eyes will have glazed over when they read $crate::format_args_nl and before they see println.

[camsteffen]

Here is an example.

macro_rules! foo {() => (1 + x);}macro_rules! bar {() => (1 + foo!());}fnmain(){bar!();}

Current error:

error[[E0425]](https://doc.rust-lang.org/stable/error-index.html#E0425): cannot find value `x` in this scope
--> src/main.rs:2:16
|
2 | () => (1 + x);
| ^ not found in this scope
...
10 | bar!();
| ------ in this macro invocation
|
= note: this error originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info)

With this PR currently, the note would say

note: this error originates in the macro `bar` which expands to macro `foo`

This is misleading. The error is in foo, not bar.

[estebank]

What about

note: the macro `bar` expands to macro `foo`, where the error originates from

[compiler-errors]

I'll just go with @camsteffen's ordering. I'm don't really want to refactor the code to make the new phrasing work 😅

[compiler-errors]

Maybe this new wording is more reasonable? It's a bit long though.

[estebank]

@bors r+

[bors]

📌 Commit 2d7d40d6320c0867190462328dba93515447e180 has been approved by estebank

It is now in the queue for this repository.

[estebank]

We can iterate on the wording later :)

[compiler-errors]

Thanks @estebank ❤️! I fear there's like a 99% chance this no longer merges because of UI tests added since 11 days ago, so let me rebase this first after work today. I'd hate for this to mess up a rollup because of failing tests.

@bors r-

[compiler-errors]

@bors r=estebank

[bors]

📌 Commit 01b2379 has been approved by estebank

It is now in the queue for this repository.