r? @jackh726

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

r? @lcnr @oli-obk

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

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..?

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

(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.)

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.

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

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.

@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?

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.

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