-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use spans for -Z external-macro-backtrace #46605
Conversation
estebank
commented
Dec 9, 2017
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
Follow up to #45545 (comment). CC @durka. |
3893031
to
4a17aff
Compare
``` % rustc ui/type-check/cannot_infer_local_or_vec.rs -Z external-macro-backtrace error[E0282]: type annotations needed --> <vec macros>:3:1 | 1 | / ( $ elem : expr ; $ n : expr ) => ( 2 | | $ crate :: vec :: from_elem ( $ elem , $ n ) ) ; ( $ ( $ x : expr ) , * ) => ( 3 | | < [ _ ] > :: into_vec ( box [ $ ( $ x ) , * ] ) ) ; ( $ ( $ x : expr , ) * ) | | ^^^^^^^^^^^^^^^^^^^^^ | | | | | cannot infer type for `T` 4 | | => ( vec ! [ $ ( $ x ) , * ] ) | |______________________________- in this expansion of `vec!` | ::: ui/type-check/cannot_infer_local_or_vec.rs | 12 | let x = vec![]; | - ------ in this macro invocation | | | consider giving `x` a type error: aborting due to previous error ```
4a17aff
to
b7bb67a
Compare
Looks really good!
…On Dec 9, 2017 1:31 PM, "Esteban Kuber" ***@***.***> wrote:
Follow up to #45545 (comment)
<#45545 (comment)>.
CC @durka <https://github.com/durka>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46605 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3nyYaxTxTqf_JwFCV6b4fJoDN_egQks5s-tIbgaJpZM4Q8MZg>
.
|
src/test/ui/macro_backtrace/main.rs
Outdated
//~^ ERROR expected one of | ||
//~| ERROR expected one of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... would it be better to move these annotations outside of the macro_rules! pong { ... }
? I was a little confused at first by the main.stderr until I realized that they were just transcribed from the source because they happen to occur within the macro definition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking something along the lines of:
// a local macro
macro_rules! pong {
() => { syntax error };
}
//~^^ ERROR expected one of
//~| ERROR expected one of
//~| ERROR expected one of
but maybe I misremember the exact syntax here.
Its possible that even this may work:
// a local macro
macro_rules! pong {
() => { syntax error };
} //~^ ERROR expected one of
//~| ERROR expected one of
//~| ERROR expected one of
r=me once the |
@bors r=pnkfelix |
📌 Commit d4b8e99 has been approved by |
Use spans for -Z external-macro-backtrace ``` % rustc ui/type-check/cannot_infer_local_or_vec.rs -Z external-macro-backtrace error[E0282]: type annotations needed --> <vec macros>:3:1 | 1 | / ( $ elem : expr ; $ n : expr ) => ( 2 | | $ crate :: vec :: from_elem ( $ elem , $ n ) ) ; ( $ ( $ x : expr ) , * ) => ( 3 | | < [ _ ] > :: into_vec ( box [ $ ( $ x ) , * ] ) ) ; ( $ ( $ x : expr , ) * ) | | ^^^^^^^^^^^^^^^^^^^^^ | | | | | cannot infer type for `T` 4 | | => ( vec ! [ $ ( $ x ) , * ] ) | |______________________________- in this expansion of `vec!` | ::: ui/type-check/cannot_infer_local_or_vec.rs | 12 | let x = vec![]; | - ------ in this macro invocation | | | consider giving `x` a type error: aborting due to previous error ```
☀️ Test successful - status-appveyor, status-travis |
… r=petrochenkov Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation. This is my attempt at dealing with rust-lang#66364 (comment), although I'm not sure it's the least disruptive one. The behavior of `-Zexternal-macro-backtrace` was already to enable full macro backtraces for *all* macros, the only part of it that was specific to cross-crate macros was showing this when *not used*: ``` note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) ``` After this PR: * the flag is renamed to `-Zmacro-backtrace` * do we need to have a deprecation period? cc @rust-lang/compiler * the message informing you about the flag is always shown when an expansion of a bang macro/attribute/derive is involved, not just cross-crate ones * this accounts for most of the changes in tests * we could perhaps only show it for the bang macro case? feels odd for derives * `fix_multispans_in_std_macros` is split into `fix_multispans_in_extern_macros` and `render_multispans_macro_backtrace` * this roughly reverts the non-behavioral parts of rust-lang#46605, which combined the two functionalities * not sure where the old `std_macros` name came from, perhaps the `<std macros>` synthetic "file"? even then, odd that `std` specifically was mentioned * `render_multispan_macro_backtrace`, by default (i.e. without `-Zmacro-backtrace`), hides the `in this macro invocation` label specifically to avoid redundancy in the diagnostic * that is, showing the macro use site is only useful when the diagnostic is inside the macro definition and the user can't otherwise tell which use site it applies to, not when the diagnostic is at/inside the use site already (which would make the label redundant) * before, it was only checking for the situation in which a cross-crate macro *definition* span would be replaced with the invocation span, which both made the connection to redundancy unobvious, and didn't help with other redundancy (e.g. when the diagnostic was pointing to an argument inside the macro invocation) * this accounts for the remaining test changes, which I've first noticed in rust-lang#66364 (comment) but only later understood as part of this PR (hence the "redundancy" descriptions) This PR is not needed for rust-lang#66364, but it would help, as after this PR there's only one `.span_to_filename(...).is_macros()` check (i.e. for `<... macros>` synthetic "files") left in `rustc_errors`, and it's much more self-contained. r? @petrochenkov