Use floats for wasmtime::component::Val::Float*

[lann]

The definitions of wasmtime::component::Val::Float{32,64} mirrored wasmtime::Val::F{32,64} by using integers as their wrapped types, storing the bit representation of their floating point values. This was necessary for the core Wasm f32/f64 types because Rust floats don't have guaranteed NaN bit representations.

#5480 (comment) @jameysharp:
We do this in Cranelift too. I don't know if it's for the same reason that Wasmtime's API works this way, but Cranelift's reason was discussed in #2251 (comment). In short, Rust doesn't make any guarantees about the bit-representation of NaN values being preserved in floating-point types. So if you care about that, you need to keep the raw bits in an integer type until the time when you want to do actual floating-point operations on them.

The component model float32/float64 types require NaN canonicalization, so we can use normal Rust f{32,64} instead.

Closes #5480

[lann]

I failed to mention: this removes the #[derive(Eq)] from Val and some related structs because f{32,64} aren't Eq. I think this makes sense in this context but it's technically a breaking change.

[alexcrichton]

Yeah that's ok and I think it makes sense as well due to the usage of floats it shouldn't be applicable for Val anyway.

[github-actions]

Subscribe to Label Action

cc @fitzgen, @peterhuene

This issue or pull request has been labeled: "fuzzing", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing
• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

It looks like this broke fuzzing here because nan is no longer equal to nan. @lann would you be up for helping to fix this? I think the way to fix it would be to write a custom equality function which considers two NaN values to be equal.

[lann]

Would it make sense to change the test code? e.g.

match (expected, actual) {
    // NaNs never compare equal
    (Val::Float32(expected), Val::Float32(actual)) if expected.is_nan() => assert!(actual.is_nan()),
    (Val::Float64(expected), Val::Float64(actual)) if expected.is_nan() => assert!(actual.is_nan()),
    (expected, actual) => assert_eq!(expected, actual),
};

[alexcrichton]

More-or-less that's what needs to happen, but floats can appear recursively as well so the equality change there would need to be applied deeply through types like lists and recors too