Reduce verbosity of errors involving builtin macros#106526
Reduce verbosity of errors involving builtin macros#106526estebank wants to merge 1 commit intorust-lang:masterfrom
Conversation
|
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
Do not show note "this error originates in" when it is caused by one in an explicit block list of builtin macros. Most notably, `println!` and friends will stop doing so.
estebank
force-pushed
the
verbose-print
branch
from
c32d78a to
ab107e3
Compare
|
I disagree with adding this kind of hacks to macro expansion infra, this PR does more harm than good. |
| "assert" | "bench" | "cfg" | "concat" | "concat_idents" | "env" | "format_args" | ||
| | "format_args_nl" | "global_allocator" | "include_str" | "test", |
There was a problem hiding this comment.
I also don't love the hardcoded list of macro names. It feels to me like what these have in common, and why we might want to suppress the subdiagnostic, is that these act more like a regular function call that returns a value than a macro that expands into multiple statements which you would potentially want a macro-backtrace expansion for.
Perhaps we should have an internal rustc attribute that controls this behavior which can be applied to the appropriate macros in the std? That feels like it could be a cleaner solution than hardcoding the macro names at this place.
There was a problem hiding this comment.
I also don't love the hardcoded list of macro names.
That's fair, I would like to hide the note for all builtin macros at some point, just audit that the derive macros in particular don't have bad corner cases (didn't see any in the test suite, but they have occurred in the past). The idea behind the blocklist was to test this out in a controlled manner, and see if we have to back off from hiding this information.
Initially I tried using a solution based on DefIds, but doing any kind of querying in the Emitter was a non-starter. That being said, maybe we could inject a trait object callable to allow Emitter to have queries. If that were to work, then we can accomplish the same behavior with annotations on the macros. I do not know at this point how feasible it would be to do so.
|
☔ The latest upstream changes (presumably #106637) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Hi, what's the status of this pull request? Needs more design work or is the idea to fold the proposal? thanks |
|
@apiraino I need to change the approach. I can close and retry later. |
6 participants
Do not show note "this error originates in" when it is caused by one in an explicit block list of builtin macros. Most notably,
println!and friends will stop doing so.