The implementation of `<f64 as ToPrimitive>::to_f32` was written at a
time when float-to-float overflow was though to be undefined behavior,
per rust-lang/rust#15536, but this was later determined to be fine.
Casting a large `f64` to `f32` just results in an infinity with the
matching sign. The sign gives more information than if `to_f32` just
returns `None`, so now we let these infinities through as a result.

See also rust-num/num-bigint#163 and rust-num/num-rational#83.

185: Trust the "i128" feature r=cuviper a=cuviper

If the "i128" feature is explicity requested, don't bother probing for
it. It will still cause a build error if that was set improperly.

186: Allow large f64-to-f32 to saturate to infinity r=cuviper a=cuviper

The implementation of `<f64 as ToPrimitive>::to_f32` was written at a
time when float-to-float overflow was though to be undefined behavior,
per rust-lang/rust#15536, but this was later determined to be fine.
Casting a large `f64` to `f32` just results in an infinity with the
matching sign. The sign gives more information than if `to_f32` just
returns `None`, so now we let these infinities through as a result.

See also rust-num/num-bigint#163 and rust-num/num-rational#83.

190: Normalize the comment style r=cuviper a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>

Other SOMs that I've tried error (whether deliberately or not) when a big
integer is too big to be represented as a floating point number. The
`BigInt::to_f64()` function used to return `None` in such cases but now they
always return `Some::(f64::INFINITY)` (see
rust-num/num-bigint#163). This PR handles that
explicitly.

On the plus side, we can simplify our code a little bit; on the downside we'll
also probably be a tiny bit slower in the common case.

Other SOMs that I've tried error (whether deliberately or not) when a big
integer is too big to be represented as a floating point number. The
`BigInt::to_f64()` function used to return `None` in such cases but now they
always return `Some::(f64::INFINITY)` (see
rust-num/num-bigint#163). This PR handles that
explicitly.

On the plus side, we can simplify our code a little bit; on the downside we'll
also probably be a tiny bit slower in the common case.