Implement float literals in valtree

[compiler-errors]

Fixes #98813
cc: @rust-lang/wg-const-eval

[rust-highfive]

r? @jackh726

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

[compiler-errors]

r? @lcnr @oli-obk

[RalfJung]

Not having floats in valtrees was somewhat deliberate since their equality is not very well-behaved.

[RalfJung]

Do we really want to accept this program? Obviously it shouldn't ICE, but IMO it should be rejected.

[compiler-errors]

Interesting. Thanks for the info @RalfJung... in that case, how should we fix this ICE? 🤔

The code seems to assume we can always turn a const lit into a val tree..?

[RalfJung]

Let's see what @lcnr @oli-obk say, my info might be outdated. :)

[compiler-errors]

(Alternatively, we could just provide some other error kind in lit_to_const that captures the "not meaningful to evaluate into a valtree" case, and handle that try_eval_lit_or_param instead of ICEing there.)

[RalfJung]

My expectation was that types in constants are limited to "structural types" in some sense, and the type checker would bug out early when a non-structural type is used. And structural types are exactly those for which we can always create a valtree.

[compiler-errors]

Ah.. so ideally we shouldn't be able to use floats in a const generic to begin with... hmm yeah I guess we'll see what the others say

[lcnr]

Ah.. so ideally we shouldn't be able to use floats in a const generic to begin with...

jup, seems like this was an oversight in fn check_param_wf if adt_const_params is enabled.

We don't want to accept floats as const parameters. The only possible equality we could use for them would by bitwise equality and that seems bad for 2 reasons:

• "equal" values can have the same bitwise repr, e.g. different nans, +0 -0.
• fun float facts like 0.1 + 0.2 != 0.3.

[compiler-errors]

@lcnr, soooo apparently we use search_for_structural_match_violation to determine if it's a valid const type... but ty::Float isn't a structural match violation. I'm happy to fix this, maybe adding a flag to make f32/f64 forbidden in this case. Thoughts?

[oli-obk]

Yea, I think adding a Float variant to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/structural_match/enum.NonStructuralMatchTyKind.html seems the right way forward, as this way the pattern matching thing can avoid emitting a structural match error and keep emitting a float future incompat error instead.

[RalfJung]

match should treat floats like non-structural-match types though, i.e., no exhaustiveness checking and no "primitive" representation in the "match tree".