Fix precision loss in CastExpr::check_bigger_cast for integer-to-float conversions #23808

Rationale for this change

CastExpr::check_bigger_cast is used to determine whether a cast is a widening (order-preserving) conversion. Currently, it classifies all (Int8 | Int16 | Int32 | UInt8 | UInt16 | UInt32) -> (Float32 | Float64) and (Int64 | UInt64) -> Float64 as widening casts.

However, integer-to-float conversions can lose precision when the integer value exceeds the mantissa bit limit (24 bits for Float32, 53 bits for Float64).

For example, Int32 -> Float32 loses precision for integers greater than 2^24 (16,777,216):

assert_eq!(16_777_216_i32 as f32, 16_777_217_i32 as f32); // true! (both yield 16777216.0f32)

Because distinct integer inputs can collapse to the same float output, these casts are not strictly 1-to-1 (injective). When used in multi-column ordering analysis (e.g. [CAST(a AS Float32), b]), this value collapse can invalidate the ordering of subsequent sort keys (b).

What changes should be made?

Modify CastExpr::check_bigger_cast to only treat integer-to-float conversions without precision loss as widening casts:

• Float32 (24-bit mantissa): Allow Int8, Int16, UInt8, UInt16 (<= 16 bits). Exclude Int32, UInt32.
• Float64 (53-bit mantissa): Allow Int8, Int16, Int32, UInt8, UInt16, UInt32 (<= 32 bits). Exclude Int64, UInt64.

// Proposed change in CastExpr::check_bigger_cast
| (Int8 | Int16 | UInt8 | UInt16, Float32)
| (Int8 | Int16 | Int32 | UInt8 | UInt16 | UInt32, Float64)

Are there any breaking changes?

No breaking API changes. This improves optimizer soundness by preventing invalid sort substitution when precision loss occurs.

Reference

Discussion: #23807 (comment)