mark sys_common::once::generic::Once::new const-stable

[krasimirgg]

Attempt to address #103191 by marking the impl const-stable.
Picked the declaration from the callsite:

rust/library/std/src/sync/once.rs

Line 67 in 21b2465

#[rustc_const_stable(feature = "const_once_new", since = "1.32.0")]

This is similar to #98457.

With this in, python3 x.py build library/std --target x86_64-unknown-none succeeds.

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[RalfJung]

https://doc.rust-lang.org/nightly/std/sync/struct.Once.html#method.new has been const fn since forever so this is probably just an internal change?
r? @m-ou-se

[Amanieu]

This seems to be necessary because the generic implementation uses ptr::invalid_mut, which is still unstable.

@bors r+ rollup

[bors]

📌 Commit df5d035 has been approved by Amanieu

It is now in the queue for this repository.

[Manishearth]

This seems to be necessary because the generic implementation uses ptr::invalid_mut, which is still unstable.

cc @estebank@oli-obk

might be worth looking at showing proximal cause in the diagnostics for stuff like this, fwiw

[estebank]

@Manishearth can we have an minimal repro for this? I'm not as involved with the const fn space so I don't have the context for how the current state is bad.

[Manishearth]

@estebank tricky thing is that because it has to do with const_stable it needs to be reprod in std.

I can try but I don't fully understand what's happening here either, that's why I cc'd oli

[oli-obk]

I think this is a hole in our const stability checks. Basically functions without stability attributes are usable from stable const fn even if they internally call unstable const fn