Tracking Issue for `Mutex::new()` as const fn

[elichai]

Hi,
I think being able to do
static mut GLOBAL_LOCK: Mutex<Type> = Mutex::new(Type::new())

Is a very important feature, right now you have to do weird jumps with Option/MaybeUninit and Once to then return a &'static Mutex<T>.
In practice, the missing pieces here are: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/mutex.rs#L24 and #57349

alexcrichton Pointed out here #66823 (comment) that this also requires Box. so that's another missing piece in cost fn for these to be usable in const fn's

---

I opened this Issue as part of: #57563

[CryZe]

This would mean that Rust needs to use its own Mutex implementation (such as via parking_lot) as in general the mutexes provided via the OS can not be made const. It may be possible to do so on some OS's but that can't be generalized to all.

It probably makes more sense to make sure you can use parking_lot's Mutex::new as a const fn on stable Rust before trying to do this for std.

[elichai]

@CryZe Makes some sense that we can't ask the OS for a mutex in compile time.
but what we might be able to do, is maybe not init() the mutex when calling new(). but instead using Once to only initialize it on the first lock.
altough the AtomicBool overhead here might not be worth it

[jacob-greenfield]

This should include RwLock too, right?

[elichai]

Looking at the code from my phone Rwlock looks already doable, and I don't quite get why it's on the heap.
I'll open the laptop soon and experiment with it

[Mark-Simulacrum]

Closing as this isn't really viable to do today (we need to box the system primitives) and isn't likely to get forgotten (i.e., is trivial to implement and widely desirable) once we get something like parking_lot merged.

[jonas-schievink]

This is still listed as part of #57563

[Darksonn]

For those looking for the PR that stabilized this, it is #97791.