Skip to content

a type error in a nested macro leads to a confusing compiler error message #45921

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

Closed
oconnor663 opened this issue Nov 10, 2017 · 2 comments
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-diagnostics Working group: Diagnostics

Comments

@oconnor663
Copy link
Contributor

oconnor663 commented Nov 10, 2017

Here's a toy program demonstrating the problem:

macro_rules! my_macro {
    () => {
        fn my_func() {
            // An intentional type error here. The compiler doesn't do a good
            // job of saying what line is causing it.
            assert_eq!(0u8, 0u16);
        }
    }
}

my_macro!();

fn main() {
    my_func();
}

Compiling it (current stable rustc, 1.21) gives the following error:

error[E0308]: mismatched types
  --> src/main.rs:11:1
   |
11 | my_macro!();
   | ^^^^^^^^^^^^
   | |
   | expected u8, found u16
   | in this macro invocation
   |
   = note: this error originates in a macro outside of the current crate

All the compiler is telling me is that "something inside the macro generates this type error". In particular, it's not able to tell me that the problem is on line 6. I wouldn't be surprised if this was a known problem somewhere, but I wanted to make sure to report it, since it's probably super confusing for new developers. (For example, I expect you could run into this easily by combining assert! with another common macro like lazy_static!.)

@TimNN TimNN added A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Nov 14, 2017
@estebank
Copy link
Contributor

estebank commented Dec 7, 2017

On nightly, you can provide the flag -Z external-macro-backtrace for "better" diagnostics, introduced by #45545:

% rustc file.rs -Z external-macro-backtrace                                                                                                                                                                        
error[E0308]: mismatched types
 --> <assert_eq macros>:5:22
  |
5 | if ! ( * left_val == * right_val ) {
  |                      ^^^^^^^^^^^ expected u8, found u16
file.rs:11:1: 11:13 note: in this expansion of my_macro! (defined in file.rs)
file.rs:6:13: 6:35 note: in this expansion of assert_eq! (defined in <assert_eq macros>)

error: aborting due to previous error

@estebank estebank added the WG-diagnostics Working group: Diagnostics label Dec 7, 2017
@estebank estebank added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 29, 2020
@estebank
Copy link
Contributor

Current output:

error[E0308]: mismatched types
  --> src/main.rs:6:29
   |
6  |             assert_eq!(0u8, 0u16);
   |                             ^^^^ expected `u8`, found `u16`
...
11 | my_macro!();
   | ----------- in this macro invocation
   |
   = note: this error originates in the macro `my_macro` (in Nightly builds, run with -Z macro-backtrace for more info)
help: change the type of the numeric literal from `u16` to `u8`
   |
6  |             assert_eq!(0u8, 0u8);
   |                              ~~

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, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-diagnostics Working group: Diagnostics
Projects
None yet
Development

No branches or pull requests

3 participants