const_eval: update for const-fn float stabilization

[RalfJung]

Accompanying reference update for rust-lang/rust#128596.

The float semantics RFC decided that this is not a guarantee we actually provide (and I am surprised to see that this was ever documented here, since we have other plans that will make this even less true):

Calling a const function at compile-time
will always yield the same result as calling it at runtime, even when called
multiple times.

Therefore, I removed this paragraph. I am not sure what its purpose was.

Also fixes #1581.

[RalfJung]

Seems like this guarantee was added a long time ago, in #440. Cc @oli-obk

[oli-obk]

I am not sure what its purpose was.

the purpose was to be able to land the reference change and doing any work, as there was resistance to breaking that "guarantee" that we accidentally had

[ehuss]

Do you happen to know what the restrictions are?

Also, just to verify, there are no restrictions for const generic parameters now?

[RalfJung]

I don't know, I just copied this text to a place where I think it makes more sense.
Cc @BoxyUwU

[BoxyUwU]

type system const expressions can either be arbitrary expressions not making using of any generics, or a single bare const parameter, e.g. { N }

[RalfJung]

Thanks! I've added this to the PR.

It's not related to "const fn float" at all, but I don't want to make this a separate PR as those would conflict...

[joshtriplett]

Accompanying reference update for rust-lang/rust#128596.

The float semantics RFC decided that this is not a guarantee we actually provide (and I am surprised to see that this was ever documented here, since we have other plans that will make this even less true):

Calling a const function at compile-time
will always yield the same result as calling it at runtime, even when called
multiple times.

Therefore, I removed this paragraph. I am not sure what its purpose was.

Would it be feasible, rather than deleting this paragraph, to document exceptions to it (e.g. NaN bit patterns, calls to some floating-point functions)? It still seems to generally be true with the current set of things we've accepted.

(This is not an objection or a blocker, just a question.)

[RalfJung]

Yes, it is feasible. Currently, the NaN bit patterns returned by some float operations are the only case. However, I'm not very fond of the idea that we'll have to update the reference each time we add a new source of potential non-determinism or other kinds of difference between compiletime and runtime behavior...

[chorman0773]

Also sounds like a stability nightmare.

[ehuss]

Thanks!