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

Rustc doesn't report line numbers for type errors within proc macro async fn within macro_rules macro #68430

Closed
lily-mara opened this issue Jan 21, 2020 · 10 comments · Fixed by #72388
Labels
A-async-await A-diagnostics A-macros A-proc-macros AsyncAwait-Triaged C-bug D-terse P-high T-compiler

Comments

@lily-mara
Copy link

@lily-mara lily-mara commented Jan 21, 2020

When using a macro to generate an async fn with a proc macro inside it, if the generated function includes a type error, rustc will not report any line number information. This makes finding and debugging type errors in large async applications extremely difficult.

I tried this code:

async fn foo() {}

macro_rules! gen_test {
    ($before:expr) => {
        #[tokio::test]
        async fn test_foo() {
            $before;
            let x: () = foo();
        }
    }
}

gen_test!(dbg!(4));

I expected to see this happen:

Error including line number information (you will get this output if you just comment out the $beforeline in the test fn)

error[E0308]: mismatched types
  --> src/lib.rs:8:25
   |
8  |             let x: () = foo();
   |                         ^^^^^
   |                         |
   |                         expected (), found opaque type
   |                         help: consider using `.await` here: `foo().await`
...
13 | gen_test!(dbg!(4));
   | ------------------- in this macro invocation
   |
   = note: expected type `()`
              found type `impl std::future::Future`

Instead, this happened:

Error including no line number information

error[E0308]: mismatched types
  |
  = note: expected type `()`
             found type `impl std::future::Future`

error: aborting due to previous error

Meta

rustc --version --verbose: Tested on Playground with stable 1.40.0 and nightly 1.42.0 (2020-01-20)

@jonas-schievink jonas-schievink added A-async-await A-diagnostics A-macros C-bug T-compiler labels Jan 21, 2020
@swilcox3
Copy link

@swilcox3 swilcox3 commented Jan 22, 2020

I can also add that incorrect line information is reported for panics, it's says src/main.rs:1:1 instead of the actual file and line.

thread 'tests::test_get_all_files_query_encoded' panicked at 'assertion failed: path.is_dir() || path.extension().unwrap() == "vwxp"', src\main.rs:1:1

@tmandry tmandry added AsyncAwait-OnDeck AsyncAwait-Triaged labels Jan 28, 2020
@Centril
Copy link
Contributor

@Centril Centril commented Jan 28, 2020

@Sushisource
Copy link

@Sushisource Sushisource commented Feb 3, 2020

I'm seeing the same thing, at the trait/impl level. I have a macro that wraps async_trait (and can only be applied to trait defs or impls):

pub fn async_sync_trait(args: TokenStream, input: TokenStream) -> TokenStream {
    let args = parse_macro_input!(args as Args);
    let mut item = parse_macro_input!(input as Item);
    // Adds some methods
    expand(&mut item, args.local);
    if args.local {
        TokenStream::from(quote! {
            #[async_trait::async_trait(?Send)]
            #item
        })
    } else {
        TokenStream::from(quote! {
            #[async_trait::async_trait]
            #item
        })
    }
}

If I don't emit the #[async_trait::async_trait] attribute, line numbers work fine. If I don't use my macro at all and only use async_trait, line numbers work fine. The act of one macro emitting another seems to be the problem.

@tmandry tmandry added this to To do in wg-async work Feb 11, 2020
@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Feb 24, 2020

[triagebot] Can't say anything without investigating, won't investigate due to low priority.

@maackle
Copy link

@maackle maackle commented Feb 24, 2020

I'm having this problem too. I made a repo with a minimal reproduction FWIW.

I'm not sure if this completely explains the problem, but in this repo I defined two trivial proc macro attributes, one which spits out the code unchanged (#[noop]), another which quotes the code and then spits that out unchanged ([#quoter]). I tried various combinations of these two macros, and all of them preserve line numbers for type errors except when applying noop and then quoter. Here is the line that demonstrates the combination that causes line numbers to be erased: https://github.com/maackle/nested-proc-macro-mcve/blob/master/app/src/main.rs#L21

@tmandry tmandry added P-high D-terse labels Mar 3, 2020
@najamelan
Copy link
Contributor

@najamelan najamelan commented May 1, 2020

@petrochenkov It's P-high now, I posted a small repro in another issue: #51635 (comment) That doesn't need anything async to show this behavior, so it might just be more general.

@nellshamrell
Copy link
Contributor

@nellshamrell nellshamrell commented May 4, 2020

Taking a look at this.

@pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented May 6, 2020

triage: visited as part of general query of unassigned P-high non-ICE issues. But it looks like @nellshamrell is taking a look at this, so I'm marking as assigned to nell for now.

@nellshamrell
Copy link
Contributor

@nellshamrell nellshamrell commented May 11, 2020

Hello all - looking at my list of things to do, I realized I'm not going to be able to get to this in the immediate future. Taking my name off the issue for now so someone else can pick it up if they have time before I do.

@nellshamrell nellshamrell removed their assignment May 11, 2020
@Aaron1011
Copy link
Member

@Aaron1011 Aaron1011 commented May 18, 2020

This looks like another instance of #43081

bors added a commit to rust-lang-ci/rust that referenced this issue May 21, 2020
…ty, r=<try>

Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`

Fixes rust-lang#68430

When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.

This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).

This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
@Aaron1011 Aaron1011 added the A-proc-macros label May 21, 2020
bors added a commit to rust-lang-ci/rust that referenced this issue May 22, 2020
…ty, r=petrochenkov

Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`

Fixes rust-lang#68430

When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.

This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).

This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
wg-async work automation moved this from On deck to Done May 24, 2020
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jun 24, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jun 24, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jun 25, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jun 26, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jul 22, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jul 25, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Aug 2, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Aug 21, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Aug 22, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Aug 22, 2020
Fixes rust-lang#68430

This is a re-attempt of PR rust-lang#72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await A-diagnostics A-macros A-proc-macros AsyncAwait-Triaged C-bug D-terse P-high T-compiler
Projects
Development

Successfully merging a pull request may close this issue.