Update is_val_statically_known Docs

[NCGThompson]

• Add Type Requirements section, listing the allowed inputs, as requested by Document is_val_statically_known only supports primitives (ICE otherwise) #121115
• Add Pointers subsection, explaining is_val_statically_known handles pointers.
• Add Stability concerns section, referring to other documentation relating to consistency in const functions.

Fixes #121115

Sorry this took so long.

[rustbot]

r? @Nilstrieb

rustbot has assigned @Nilstrieb.
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

[jhpratt]

@bors r+ rollup

[bors]

📌 Commit 5969ad4 has been approved by jhpratt

It is now in the queue for this repository.

[bors]

⌛ Testing commit 5969ad4 with merge 5b1d58c...

[bors]

☀️ Test successful - checks-actions
Approved by: jhpratt
Pushing 5b1d58c to master...

[rust-timer]

Finished benchmarking commit (5b1d58c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.1%, 0.1%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 674.79s -> 673.986s (-0.12%)
Artifact size: 315.95 MiB -> 316.05 MiB (0.03%)

[NCGThompson]

this intrinsic isn't guaranteed to behave deterministically even in a const context.

@RalfJung It's too late to change it, but I wonder if we can guarantee that it will behave deterministically while in const context? I don't know of any other const function that doesn't come with that guarantee. Miri randomly selects an output at runtime, but not in const.

[RalfJung]

I don't know of any other const function that doesn't come with that guarantee.

See rust-lang/rfcs#3514, rust-lang/rfcs#3352.

[NCGThompson]

Thanks, that clears things up.

A const fn being called in a const context will still be required to be deterministic, as this is required for type system soundness. This invariant is required by the compiler and cannot be broken, even with unsafe code.

While that is from a not-yet accepted RFC, this seems to also apply to the current state. Considering that in const contexts, const functions already must be deterministic, the intrinsic currently is deterministic (it always returns false), and there is no foreseeable reason to make it non-deterministic (we don't actually care about the output), and that it is an unstable core intrinsic, I believe we should make that guarantee.

I'm not going to open another PR to remove the disclaimer just yet though; there are other changes I can make along with it.

[RalfJung]

This is the relevant part of the float RFC for that:

It is entirely possible to implement a non-deterministic language on a deterministic machine, by simply making some fixed choices. However, we will not specify a particular choice, and we will not guarantee it to remain the same in the future.

The intrinsic is not deterministic, but it is "determinised" by the const-eval machine to ensure sound compilation. However, the exact way it is "determinised" is an unspecified implementation detail; users should treat the operation as non-deterministic.

Also, discussing things in a closed PR is somewhat pointless, and I don't understand what problem you intend to solve by specifying is_val_statically_known differently. I want const-eval to support operations that are non-deterministic (like float ops) or that behave different at compiletime and runtime (like const_eval_select). This is not a bug, it's a feature. It is true that currently no such operation is stable, but so what?

If there is a problem, please open an issue so we have a proper place for discussion. If you are just wondering how it can make sense that is_val_statically_known is specified as non-deterministic, then probably a topic on Zulip asking for someone to explain this is the best way to proceed. Non-determinism is a non-trivial topic and I think many people are confused about its subtler points.