`let_unit_value` and `no_effect` trigger for static assertions

Summary

When using a const to assert certain conditions at compile time, clippy currently first asks to omit the let binding, and after doing so says that the statement has no effect.

Lint Name

let_unit_value, no_effect

Reproducer

I tried this code [playground]:

#![allow(dead_code)]

struct Check<const N: usize>;

impl<const N: usize> Check<N> {
    const STATIC_ASSERT: () = {
        assert!(N > 0);
    };

    fn let_unit_value() -> Self {
        let _ = Self::STATIC_ASSERT;
        Self
    }
    
    fn no_effect() -> Self {
        Self::STATIC_ASSERT;
        Self
    }
}

I saw this happen:

warning: this let-binding has unit value
  --> src/lib.rs:11:9
   |
11 |         let _ = Self::STATIC_ASSERT;
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: omit the `let` binding: `Self::STATIC_ASSERT;`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_unit_value
   = note: `#[warn(clippy::let_unit_value)]` on by default

warning: statement with no effect
  --> src/lib.rs:16:9
   |
16 |         Self::STATIC_ASSERT;
   |         ^^^^^^^^^^^^^^^^^^^^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#no_effect
   = note: `#[warn(clippy::no_effect)]` on by default

I expected to see this happen:
No warnings for either case, since 'using' the constant leads to the compiler evaluating it, which can be seen as a side effect.

Version

rustc 1.79.0-nightly (aa067fb98 2024-04-10)
binary: rustc
commit-hash: aa067fb984d36462548bb785da221bfaf38253f0
commit-date: 2024-04-10
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
LLVM version: 18.1.3

Additional Labels

No response

Run the provided Rust reproducer with Clippy to confirm both warnings. Start by locating the implementations and tests for the let_unit_value and no_effect lints, then determine how compile-time evaluation affects their side-effect checks. Done means the static assertion examples no longer trigger either warning while ordinary ineffective statements remain covered.