const Mutex<T> never makes sense, and therefore should raise a warning (or an error)

[Trolldemorted]

Given the following code:

use std::sync::Mutex;
const FOO: Mutex<u64> = Mutex::new(0);

fn main() {
    {
        let foo = &FOO;
        let a: &mut u64 = &mut foo.lock().unwrap();
        *a = 1;
    }
    println!("{:?}", &FOO);
}

The current output is:

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.86s
     Running `target/debug/playground`
Mutex { data: 0, poisoned: false, .. }

The const expression causes every site to have their own Mutex<T>, which never makes any sense. Imho this should raise a warning, or even an error.

[CraftSpider]

I'd vote for warning, as I've seen some situations, such as generics and traits, where things like const DEFAULT: Self are used, and you do in fact want the 'new instance on use' behavior. On the other hand, I think a warning would be useful for this case, as it's often a mistake.

[SkiFire13]

I wouldn't go as far as to say that a const Mutex doesn't make sense. AFAIK it's still the only way to const initialize an array of more than 32 or a const generic number of Mutexes. That is, [Mutex::new(0); N] doesn't work, but const INIT: Mutex<i32> = 0; [INIT; N] does.

Also, the example shown in the OP works because of the let foo = &FOO;, which is already kind of weird. Notably, FOO.lock().unwrap() raises an error, although *FOO.lock().unwrap() = 1; works fine and should be warned against.

[sfackler]

Clippy already has a lint that covers this.

[cuviper]

This is a duplicate of #40543 -- and recently there's a suggesting to uplift the lint from clippy.