about summary refs log tree commit diff
path: root/compiler/rustc_next_trait_solver/src/resolve.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2025-03-15 05:29:22 +0000
committerbors <bors@rust-lang.org>2025-03-15 05:29:22 +0000
commitadea7cbc093434a527baa4c39df6a1f0c27341e6 (patch)
tree8d544bc9c8da3b15235d56d7e457d3e99d1c4987 /compiler/rustc_next_trait_solver/src/resolve.rs
parent282865097d138c7f0f7a7566db5b761312dd145c (diff)
parentf0b8e13b59a68d63cf7083be5cd6dcca3abf18ff (diff)
downloadrust-adea7cbc093434a527baa4c39df6a1f0c27341e6.tar.gz
rust-adea7cbc093434a527baa4c39df6a1f0c27341e6.zip
Auto merge of #138379 - estebank:macro-backtrace-note, r=petrochenkov
Do not suggest using `-Zmacro-backtrace` for builtin macros

For macros that are implemented on the compiler, or that are annotated with `rustc_diagnostic_item`, which have arbitrary implementations from the point of view of the user and might as well be intrinsics, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros like `panic!` and `format!`.

This PR adds a field to every `Span`'s `ExpnData` stating whether it comes from a builtin macro. This is determined by the macro being annotated with either `#[rustc_builtin_macro]` or `#[rustc_diagnostic_item]`. An alternative to using these attributes that already exist for other uses would be to introduce another attribute like `#[rustc_no_backtrace]` to have finer control on which macros are affected (for example, an error within `vec![]` now doesn't mention the backtrace, but one could make the case that it should). Ideally, instead of carrying this information in the `ExpnData` we'd instead try to query the `DefId` of the macro (that is already stored) to see if it is annotated in some way, but we do not have access to the `TyCtxt` from `rustc_errors`.

r? `@petrochenkov`
Diffstat (limited to 'compiler/rustc_next_trait_solver/src/resolve.rs')
0 files changed, 0 insertions, 0 deletions