Description
By accident I came across an ICE from this code: (-1.0 as usize,)
. The ICE is triggered by an assertion while building the constant tuple. The field has a value of undef
.
Looking into it, the two floating point to integer cast instructions, fptoui
and fptosi
have a very large surface for producing undefined values. Any time the result cannot fit into the destination type, the result is undefined. This means casting from a negative float to an unsigned integer is undefined and casting from a float with a value outside the range for the target integer type (signed or otherwise) is undefined.
Some possible solutions:
- Treat it as an error always. This means generating an assertion before the cast, similar to how we generate assertions to check for divide-by-zero.
- Clamp the value. Casting from outside the valid range will clamp to one end of the range. so
-1.0 as u32
would produce0
. - A combination of both. Treat the case similarly to how we treat integer overflow and emit an assertion in debug builds, but omit them in release builds, falling back to the clamping behaviour.
I'm personally leaning towards 3. Most of the time an invalid cast of this nature will be unintentional, so protecting against it seems reasonable. The problem is also similar enough to overflowing that handling it similarly seems reasonable.
/cc @rust-lang/compiler @rust-lang/lang