Suggest lazy initialization when calling a non-const function in a static initializer

[jyn514]

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=67155cb72a24e0a080d9dee88483fbec

use std::sync::Mutex;

static MUTEX: Mutex<i32> = Mutex::new(1);

fn main() {
    println!("{}", MUTEX.lock().unwrap());
}

The current output is:

error[E0015]: cannot call non-const fn `Mutex::<i32>::new` in statics
 --> src/main.rs:3:28
  |
3 | static MUTEX: Mutex<i32> = Mutex::new(1);
  |                            ^^^^^^^^^^^^^
  |
  = note: calls in statics are limited to constant functions, tuple structs and tuple variants

I have a friend learning rust who concluded, reasonably, that global mutexes are not allowed and you have to declare them in main and pass them down to functions with an argument. It would be great if the compiler could suggest the common alternative approach instead, which is lazy initialization:

Ideally the output should look like:

error[E0015]: cannot call non-const fn `Mutex::<i32>::new` in statics
 --> src/main.rs:3:28
  |
3 | static MUTEX: Mutex<i32> = Mutex::new(1);
  |                            ^^^^^^^^^^^^^
  |
  = note: calls in statics are limited to constant functions, tuple structs and tuple variants
  = help: consider using the `once_cell` crate: https://crates.io/crates/once_cell

I know the compiler generally has a policy of not favoring individual crates, but once_cell is literally becoming part of the standard library so I think this is reasonable and doesn't show favoritism.

(I'm aware Mutex::new will be a const fn in 1.63, but this same diagnostic would be helpful in any other case where the initializer isn't const.)

[jyn514]

also, in this particular case it could have suggested using AtomicI32 instead; not sure if that's a good suggestion to make though.

[jyn514]

Mentoring instructions: add that note immediately after

rust/compiler/rustc_const_eval/src/transform/check_consts/ops.rs

Lines 328 to 332 in 8b2637f

	err.note(&format!(
	"calls in {}s are limited to constant functions, \
	tuple structs and tuple variants",
	ccx.const_kind(),
	));

[cameron1024]

@rustbot claim

[mqudsi]

Can't we just punt this until after #74465 lands?

[jyn514]

@mqudsi I don't understand why it has to be blocked on that? we can certainly update the message to suggest std::once after that lands, but I don't think it needs to block the suggestion.

[mqudsi]

I guess it's just being conservative when evaluating the costs vs benefits?

once_cell (and before it, lazy_static) have been around for a long time and it would have been a great tradeoff to suggest either years ago (cost: suggesting an external crate, benefit: years of people benefiting from it), but if we've not suggested an external crate for this long and a native solution is just around the corner, it feels like it would be prudent to just wait it out at this point (cost: same, benefit: capped to however long it takes for std's equivalent to land).

I'm not a zero-dependency zealot (but I do appreciate the distinction between cargo and rustc), but my concern is that in some ways, this suggestion isn't something we can take back (it's not like we'll emit a diagnostic message to stop using once_cell once std gets support for the same). Every time someone interacts with the rust compiler and gets an officially sanctioned message coming from rustc itself saying "use a 3rd party lib" that could change the reaction from "I need to do this some other way" to "rust can't even do basic things without using a 3rd party lib, and even the compiler knows it." As you mentioned, there are workarounds that don't have dependencies on 3rd party crates, and they're technically more idiomatic even if they're less ergonomic.

I could be mistaken, but I've been following it and I don't think any serious issues have been raised with the core/std port of once_cell and there's no reason to expect the proposal will languish for years to come like some other, more controversial changes; all that just makes me think "let sleeping dogs lie"... but that's just my two cents and I'm obviously not going to complain if this does get implemented - I just thought I'd share my perspective, for what little it is worth.

(I use once_cell myself and even plug it in my own crate's docs.)

[jyn514]

but my concern is that in some ways, this suggestion isn't something we can take back (it's not like we'll emit a diagnostic message to stop using once_cell once std gets support for the same). Every time someone interacts with the rust compiler and gets an officially sanctioned message coming from rustc itself saying "use a 3rd party lib" that could change the reaction from "I need to do this some other way" to "rust can't even do basic things without using a 3rd party lib, and even the compiler knows it."

tbh people who feel like that probably already feel that way regardless of what the compiler says

We already suggest async_trait for async functions in traits, I don't think this is that much of a stretch. If std::once is just around the corner like you say, then we won't suggest an external crate for long anyway :)

[mqudsi]

Fair enough!

[Noratrieb]

#100507 fixed this.