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

Specifying lint levels does not work on macros #87391

Open
asquared31415 opened this issue Jul 23, 2021 · 1 comment
Open

Specifying lint levels does not work on macros #87391

asquared31415 opened this issue Jul 23, 2021 · 1 comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@asquared31415
Copy link
Contributor

Given the following code:

fn main() {
    #[allow(irrefutable_let_patterns)]
    println!("{}", if let _ = 1 { 42 } else { 0 });
    
    // The macro doesn't matter, even macros like `asm!` exhibit this behavior
    #[allow(irrefutable_let_patterns)]
    dbg!("{}", if let _ = 1 { 42 } else { 0 });
    
    #[allow(irrefutable_let_patterns)]
    {
        println!("{}", if let _ = 2 { 84 } else { 0 });
    }
    
    #[allow(irrefutable_let_patterns)]
    if let _ = 3 { 
        println!("{}", 168);
    } else { 
        println!("{}", 0);
    }
}

playground

The current output is:

warning: irrefutable `if let` pattern
 --> src/main.rs:3:20
  |
3 |     println!("{}", if let _ = 1 { 42 } else { 0 });
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(irrefutable_let_patterns)]` on by default
  = note: this pattern will always match, so the `if let` is useless
  = help: consider replacing the `if let` with a `let`

warning: irrefutable `if let` pattern
 --> src/main.rs:7:16
  |
7 |     dbg!("{}", if let _ = 1 { 42 } else { 0 });
  |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this pattern will always match, so the `if let` is useless
  = help: consider replacing the `if let` with a `let`

warning: 2 warnings emitted

Ideally in this case, the compilation should succeed without warning, as the lint appears to have been explicitly allowed everywhere it is used.

This likely applies for all lints and all lint levels and all macros

  • (only tested println!, dbg!, and asm! with allow, warn, and deny for irrefutable_let_patterns as well as in in my in progress lint named_asm_labels)

A current workaround is to create a scope to put the macro in, and apply the lint level to that scope, as demonstrated in the example.

Applying the lint level to the crate with #![level(lint)] works as expected, however this is often not desirable.

Possibly related: #59306

@asquared31415 asquared31415 added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 23, 2021
@asquared31415
Copy link
Contributor Author

Update: I'm not sure this is fixed but the compiler at least tells you that it doesn't work now

warning: unused attribute `allow`
 --> src/main.rs:2:5
  |
2 |     #[allow(irrefutable_let_patterns)]
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the built-in attribute `allow` will be ignored, since it's applied to the macro invocation `println`
 --> src/main.rs:3:5
  |
3 |     println!("{}", if let _ = 1 { 42 } else { 0 });
  |     ^^^^^^^
  = note: `#[warn(unused_attributes)]` on by default

warning: unused attribute `allow`
 --> src/main.rs:6:5
  |
6 |     #[allow(irrefutable_let_patterns)]
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the built-in attribute `allow` will be ignored, since it's applied to the macro invocation `dbg`
 --> src/main.rs:7:5
  |
7 |     dbg!("{}", if let _ = 1 { 42 } else { 0 });
  |     ^^^

However it does not offer any suggestions to work around this issue.

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 T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

1 participant