`#[allow(...)]` doesn't work on expressions

[OliveIsAWord]

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=01f0dcf3b636948e5c1cf8baeeedb35c

#![feature(stmt_expr_attributes)]

// Compiles successfully
#[allow(arithmetic_overflow)]
pub fn attr_on_func() -> u8 {
    200 + 200
}

// Yields compiler error
pub fn attr_on_expr() -> u8 {
    #[allow(arithmetic_overflow)]
    200 + 200
}

The current output is:

   Compiling playground v0.0.1 (/playground)
error: this arithmetic operation will overflow
  --> src/lib.rs:11:5
   |
11 | /     #[allow(arithmetic_overflow)]
12 | |     200 + 200
   | |_____________^ attempt to compute `200_u8 + 200_u8`, which would overflow
   |
   = note: `#[deny(arithmetic_overflow)]` on by default

error: could not compile `playground` due to previous error

The same thing occurs for clippy lints:

// Lint correctly silenced
#[allow(clippy::unused_unit)]
pub fn clippy_attr_on_func() {
    ()
}

// Lint erroneously not silenced
pub fn clippy_attr_on_expr() {
    #[allow(clippy::unused_unit)]
    ()
}

warning: unneeded unit expression
  --> src\lib.rs:10:5
   |
10 |     ()
   |     ^^ help: remove the final `()`
   |
   = note: `#[warn(clippy::unused_unit)]` on by default

To reiterate: the issue is that attributes for silencing warnings are ignored when placed on expressions. I realize now the first example might be an issue with higher precedence, but the second example with clippy is obviously faulty.

[est31]

For #97266 I've recently become very familiar with the code that determines lint levels. @rustbot claim

[ehuss]

I believe the arithmetic_overflow example is because attributes bind tighter than any other operator, so the attribute is part of the expression 200, not 200 + 200. You have to place the addition expression in parenthesis for it to work. See https://rust-lang.github.io/rfcs/0016-more-attributes.html for more.

[est31]

Oh yeah good point

[RodBurman]

Should the issue be closed then?

[ehuss]

Yea, I'm going to close in favor of #127436 where this very issue is being decided. I think people understand the ambiguity can be confusing, and will likely not be stabilized as-is without some mitigations.