Skip to content
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

Attribute macro within macro_rules! macro causes error messages to lose spans #75801

Closed
wuggen opened this issue Aug 22, 2020 · 2 comments · Fixed by #83671
Closed

Attribute macro within macro_rules! macro causes error messages to lose spans #75801

wuggen opened this issue Aug 22, 2020 · 2 comments · Fixed by #83671
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@wuggen
Copy link

wuggen commented Aug 22, 2020

I tried the following on the current nightly build:

macro_rules! foo {
    ($arg:expr) => {
        #[foo]
        fn bar() {
            let _bar: u32 = $arg;
        }
    };
}
foo!("baz");

// In a different, proc-macro crate:
#[proc_macro_attribute]
pub fn foo(_args: TokenStream, item: TokenStream) -> TokenStream {
    item
}

I expected to see something like the following:

error[E0308]: mismatched types
 --> src/lib.rs:3:9
  |
  | foo!("baz");
  |       ^^^^^
  |      |
  |      expected `u32`, found `&str`

error: aborting due to previous error

Instead, the error message lacks any span or additional context at all:

error[E0308]: mismatched types

error: aborting due to previous error

Removing the #[foo] from the macro_rules! body, or writing #[foo] fn bar() { ... } manually without going through the foo! macro, produces a correct error message; it's only when they are combined that the error loses contextual information.

Meta

The current beta and nightly builds are affected:

rustc --version --verbose:

rustc 1.47.0-nightly (de521cbb3 2020-08-21)
binary: rustc
commit-hash: de521cbb303c08febd9fa3755caccd4f3e491ea3
commit-date: 2020-08-21
host: x86_64-unknown-linux-gnu
release: 1.47.0-nightly
LLVM version: 10.0
rustc 1.46.0-beta.4 (32c481e15 2020-08-09)
binary: rustc
commit-hash: 32c481e156c6431d2947d865bd2abc2315a931fc
commit-date: 2020-08-09
host: x86_64-unknown-linux-gnu
release: 1.46.0-beta.4
LLVM version: 10.0

The current stable version displays the expected behavior.

@wuggen wuggen added the C-bug Category: This is a bug. label Aug 22, 2020
@Aaron1011
Copy link
Member

Bisected to #73345

This is caused by the fact that we no longer pass a single NtItem to #[foo] - instead, we pass the individual tokens of the bar function. Since the tokenstream contains an NtExpr (for the $arg metavariable), the pretty-print/reparse check fails, causing us to lose spans.

This will be fixed by #73084

@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros labels Aug 22, 2020
@Aaron1011
Copy link
Member

Error in the latest nightly:

error[E0308]: mismatched types
 --> src/main.rs:9:6
  |
5 |             let _bar: u32 = $arg;
  |                       --- expected due to this
...
9 | foo!("baz");
  |      ^^^^^ expected `u32`, found `&str`

error: aborting due to previous error

@Aaron1011 Aaron1011 added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Sep 5, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Mar 30, 2021
…-DPC

Add a regression test for issue-75801

Closes rust-lang#75801
r? `@Aaron1011`
@bors bors closed this as completed in f1ad4bd Mar 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants