Use spans for -Z external-macro-backtrace by estebank · Pull Request #46605 · rust-lang/rust

estebank · 2017-12-09T18:29:45Z

% 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

rust-highfive · 2017-12-09T18:29:55Z

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

estebank · 2017-12-09T18:31:34Z

Follow up to #45545 (comment).

CC @durka.

``` % 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 ```

durka · 2017-12-09T20:59:54Z

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> .

pnkfelix · 2017-12-13T18:53:53Z

- () => { syntax error }; //~ ERROR expected one of
+ () => { syntax error };
 //~^ ERROR expected one of
+ //~| ERROR expected one of


... 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?

I'm thinking something along the lines of:
// a local macromacro_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 macromacro_rules! pong {() => { syntax error };}//~^ ERROR expected one of//~| ERROR expected one of//~| ERROR expected one of

pnkfelix · 2017-12-13T19:17:29Z

r=me once the //~ERROR annotations are moved outside of the macro. (Or if that turns out not to be possible for some reason, then just r=me. 😄)

estebank · 2017-12-13T20:59:51Z

@bors r=pnkfelix

bors · 2017-12-13T20:59:52Z

📌 Commit d4b8e99 has been approved by pnkfelix

bors · 2017-12-14T07:06:08Z

⌛ Testing commit d4b8e99 with merge 8954b16...

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 ```

bors · 2017-12-14T10:08:40Z

☀️ Test successful - status-appveyor, status-travis
Approved by: pnkfelix
Pushing 8954b16 to master...

@petrochenkov

… 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

rust-highfive assigned pnkfelix Dec 9, 2017

estebank mentioned this pull request Dec 9, 2017
show macro backtrace with -Z flag #45545
Merged

estebank added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 9, 2017

estebank force-pushed the macro-backtrace-spans branch 2 times, most recently from 3893031 to 4a17affCompare December 9, 2017 19:32

estebank force-pushed the macro-backtrace-spans branch from 4a17aff to b7bb67aCompare December 9, 2017 20:43

estebank mentioned this pull request Dec 13, 2017
Type errors in macros have poor spans #38771
Open

pnkfelix reviewed Dec 13, 2017
View reviewed changes

Move error checks out of span for easier to follow .stderr
d4b8e99

estebank added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 13, 2017

bors mentioned this pull request Dec 14, 2017
rustc: unpack newtyped of #[repr(simd)] vector types. #46701
Merged

bors merged commit d4b8e99 into rust-lang:masterDec 14, 2017

bors mentioned this pull request Dec 14, 2017
Use PathBuf instead of String where applicable #46335
Merged

eddyb mentioned this pull request Dec 16, 2019
Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation. #67359
Merged

Navigation Menu

Uh oh!

Uh oh!

Use spans for -Z external-macro-backtrace - #46605

Use spans for -Z external-macro-backtrace#46605
bors merged 2 commits into
rust-lang:masterfrom
estebank:macro-backtrace-spans

estebank commented Dec 9, 2017

Uh oh!

rust-highfive commented Dec 9, 2017

Uh oh!

estebank commented Dec 9, 2017

Uh oh!

durka commented Dec 9, 2017 via email

Uh oh!

pnkfelixDec 13, 2017

Uh oh!

pnkfelixDec 13, 2017

Uh oh!

pnkfelix commented Dec 13, 2017

Uh oh!

estebank commented Dec 13, 2017

Uh oh!

bors commented Dec 13, 2017

Uh oh!

bors commented Dec 14, 2017

Uh oh!

bors commented Dec 14, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

estebank commented Dec 9, 2017

Uh oh!

rust-highfive commented Dec 9, 2017

Uh oh!

estebank commented Dec 9, 2017

Uh oh!

durka commented Dec 9, 2017 via email

Uh oh!

pnkfelixDec 13, 2017

Choose a reason for hiding this comment

Uh oh!

pnkfelixDec 13, 2017

Choose a reason for hiding this comment

Uh oh!

pnkfelix commented Dec 13, 2017

Uh oh!

estebank commented Dec 13, 2017

Uh oh!

bors commented Dec 13, 2017

Uh oh!

bors commented Dec 14, 2017

Uh oh!

bors commented Dec 14, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants