mark is_val_statically_known intrinsic as stably const-callable

[RalfJung]

The intrinsic doesn't actually "do" anything in terms of language semantics, and we are already using it in stable const fn. So let's just properly mark it as stably const-callable to avoid needing rustc_allow_const_fn_unstable (and thus reducing noise and keeping the remaining rustc_allow_const_fn_unstable as a more clear signal).

Cc @rust-lang/lang usually you have to approve exposing intrinsics in const, but this intrinsic is basically just a compiler implementation detail. So FCP doesn't seem necessary.
Cc @rust-lang/wg-const-eval

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[traviscross]

@rustbot labels +I-lang-nominated

Purported easy items must still be nominated to make it onto our agenda.

[nikomatsakis]

Should this intrinsic be unsafe?

[nikomatsakis]

pub const fn is_val_statically_known<T: Copy>(_arg: T) -> bool {

it doesn't appear to be...?

[nikomatsakis]

OK, discussed a bit in the meeting, I see that the unsafe thing is the use of unreachable, but it still feels like the user has a kind of obligation to use the result of this value to produce an "equivalent" results (i.e., it's intended for "performance specialization"). I suppose that we no longer guarantee deterministic results so maybe that's par for the course and not unsafe

[RalfJung]

Yeah, we made const_eval_select safe with the same reasoning -- it's not UB-inducing, just undesired.

[traviscross]

@rfcbot fcp merge

Thanks @RalfJung for working to clean this sort of thing up.

[traviscross]

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

@rfcbot reviewed

[compiler-errors]

r=me after fcp

[RalfJung]

@rust-lang/lang I heard questions about the new stability attributes came up in the meeting today. If you are curious you can read the docs at https://rustc-dev-guide.rust-lang.org/stability.html#rustc_const_unstable. :)

[RalfJung]

Thanks for working to clean this sort of thing up.

I went over all the rustc_allow_const_fn_unstable and this was the last one, so we're all cleaned up there now. :)
Same for rustc_const_unstable, those are all either in FCP or still very fresh (except for HashMap::with_hasher, I am working on that one). So we are ready for the next wave of unstable experimentation, with const traits. :)

[bors]

☔ The latest upstream changes (presumably #132756) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @rust-lang/wg-const-eval