libm MSRV bump

[tgross35]

Reasons to switch to different versions:

• 1.66: saturating_sub_unsigned
• 1.67: I::ilog2
• 1.67: can lex suffixed float literals other than *f32 and *f64
• 1.73: u*::div_ceil
• 1.77: consistent :: in build scripts (small convenience)
• 1.79: const blocks (mostly polyfill removal)
• 1.82: const floating point arithmetic (not currently used but definitely useful and not easy to polyfill)
• 1.82: const in asm
• 1.83: const F::from_bits (polyfill removal)
• 1.85: abs, copysign in core (codegen improvements)
• 1.85: Edition 2024 (not too much here)
• 1.87: <iN>::cast_unsigned, <uN>::cast_signed support: Rename signed to cast_signed to match core #1123 (code cleanup)

1.67 seems pretty reasonable

[tgross35]

Previous unintentional bump at rust-lang/libm#330 would have required 1.77, that got some feedback

[quaternic]

Notably, 1.82 also stabilized floating point arithmetic in const contexts: +, -, *, /, %, and all comparisons. Those could be quite useful, and don't have reasonable alternatives.

At the time that the 1.63 MSRV was set, it was the version provided in Debian stable. The next Debian stable was released recently and has Rust 1.85.

[tgross35]

Oh yeah, that's a great one.

Going to 1.82 would be a pretty big jump though. rust-lang crates use Debian as a loose target MSRV but don't really track it specifically, bumping two year increments would be big for the rest of the ecosystem (some more at #general > Trixie is out). So I'll probably do 1.67 for now, we can reevaluate 1.82 once it's 12-18 months old or so. Or if we have a change that needs it.

[james7132]

Debian LTSes should now have Rust 1.85. Pushing 1.82 seems reasonable. I'm running into cases where having a const f32 sqrt implemented via libm would be very useful.

[tgross35]

libm will not be providing const impls. Please see #893 and related discussion for a viable path forward there.

[tgross35]

Bumped to 1.67 in #1084