bevy_math: Apply `#[deny(clippy::allow_attributes, clippy::allow_attr…

…ibutes_without_reason)]` (#17091)

# Objective
We want to deny the following lints:
* `clippy::allow_attributes` - Because there's no reason to
`#[allow(...)]` an attribute if it wouldn't lint against anything; you
should always use `#[expect(...)]`
* `clippy::allow_attributes_without_reason` - Because documenting the
reason for allowing/expecting a lint is always good

## Solution
Set the `clippy::allow_attributes` and
`clippy::allow_attributes_without_reason` lints to `deny`, and bring
`bevy_math` in line with the new restrictions.

No code changes have been made - except if a lint that was previously
`allow(...)`'d could be removed via small code changes. For example,
`unused_variables` can be handled by adding a `_` to the beginning of a
field's name.

## Testing
I ran `cargo clippy`, and received no errors.

---------

Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>

crates/bevy_math/src/bounding/bounded2d/primitive_impls.rs

@@ -51,10 +51,12 @@ fn arc_bounding_points(arc: Arc2d, rotation: impl Into<Rot2>) -> SmallVec<[Vec2;
         // If inverted = true, then right_angle > left_angle, so we are looking for an angle that is not between them.
         // There's a chance that this condition fails due to rounding error, if the endpoint angle is juuuust shy of the axis.
         // But in that case, the endpoint itself is within rounding error of the axis and will define the bounds just fine.
-        #[allow(clippy::nonminimal_bool)]
-        if !inverted && angle >= right_angle && angle <= left_angle
-            || inverted && (angle >= right_angle || angle <= left_angle)
-        {
+        let angle_within_parameters = if inverted {
+            angle >= right_angle || angle <= left_angle
+        } else {
+            angle >= right_angle && angle <= left_angle
+        };
+        if angle_within_parameters {
             bounds.push(extremum * arc.radius);
         }
     }
@@ -475,7 +477,6 @@ mod tests {
     // Arcs and circular segments have the same bounding shapes so they share test cases.
     fn arc_and_segment() {
         struct TestCase {
-            #[allow(unused)]
             name: &'static str,
             arc: Arc2d,
             translation: Vec2,
@@ -629,7 +630,6 @@ mod tests {
     #[test]
     fn circular_sector() {
         struct TestCase {
-            #[allow(unused)]
             name: &'static str,
             arc: Arc2d,
             translation: Vec2,

crates/bevy_math/src/cubic_splines/mod.rs

@@ -995,7 +995,6 @@ impl<P: VectorSpace> CubicSegment<P> {
     }
 
     /// Calculate polynomial coefficients for the cubic curve using a characteristic matrix.
-    #[allow(unused)]
     #[inline]
     fn coefficients(p: [P; 4], char_matrix: [[f32; 4]; 4]) -> Self {
         let [c0, c1, c2, c3] = char_matrix;
@@ -1376,7 +1375,6 @@ impl<P: VectorSpace> RationalSegment<P> {
     }
 
     /// Calculate polynomial coefficients for the cubic polynomials using a characteristic matrix.
-    #[allow(unused)]
     #[inline]
     fn coefficients(
         control_points: [P; 4],

crates/bevy_math/src/curve/easing.rs

@@ -471,9 +471,15 @@ mod easing_functions {
     // with blatantly more digits than needed (since rust will round them to the
     // nearest representable value anyway) rather than make it seem like the
     // truncated value is somehow carefully chosen.
-    #[allow(clippy::excessive_precision)]
+    #[expect(
+        clippy::excessive_precision,
+        reason = "This is deliberately more precise than an f32 will allow, as truncating the value might imply that the value is carefully chosen."
+    )]
     const LOG2_1023: f32 = 9.998590429745328646459226;
-    #[allow(clippy::excessive_precision)]
+    #[expect(
+        clippy::excessive_precision,
+        reason = "This is deliberately more precise than an f32 will allow, as truncating the value might imply that the value is carefully chosen."
+    )]
     const FRAC_1_1023: f32 = 0.00097751710654936461388074291;
     #[inline]
     pub(crate) fn exponential_in(t: f32) -> f32 {

crates/bevy_math/src/float_ord.rs

@@ -47,7 +47,10 @@ impl PartialOrd for FloatOrd {
 }
 
 impl Ord for FloatOrd {
-    #[allow(clippy::comparison_chain)]
+    #[expect(
+        clippy::comparison_chain,
+        reason = "This can't be rewritten with `match` and `cmp`, as this is `cmp` itself."
+    )]
     fn cmp(&self, other: &Self) -> Ordering {
         if self > other {
             Ordering::Greater
@@ -124,7 +127,10 @@ mod tests {
     }
 
     #[test]
-    #[allow(clippy::nonminimal_bool)]
+    #[expect(
+        clippy::nonminimal_bool,
+        reason = "This tests that all operators work as they should, and in the process requires some non-simplified boolean expressions."
+    )]
     fn float_ord_cmp_operators() {
         assert!(!(NAN < NAN));
         assert!(NAN < ZERO);

crates/bevy_math/src/lib.rs

@@ -1,4 +1,5 @@
 #![forbid(unsafe_code)]
+#![deny(clippy::allow_attributes, clippy::allow_attributes_without_reason)]
 #![cfg_attr(
     any(docsrs, docsrs_dep),
     expect(

crates/bevy_math/src/ops.rs

@@ -8,9 +8,6 @@
 //! It also provides `no_std` compatible alternatives to certain floating-point
 //! operations which are not provided in the [`core`] library.
 
-#![allow(dead_code)]
-#![allow(clippy::disallowed_methods)]
-
 // Note: There are some Rust methods with unspecified precision without a `libm`
 // equivalent:
 // - `f32::powi` (integer powers)
@@ -23,6 +20,10 @@
 // - `f32::ln_gamma`
 
 #[cfg(not(feature = "libm"))]
+#[expect(
+    clippy::disallowed_methods,
+    reason = "Many of the disallowed methods are disallowed to force code to use the feature-conditional re-exports from this module, but this module itself is exempt from that rule."
+)]
 mod std_ops {
 
     /// Raises a number to a floating point power.
@@ -519,6 +520,10 @@ mod libm_ops_for_no_std {
 }
 
 #[cfg(feature = "std")]
+#[expect(
+    clippy::disallowed_methods,
+    reason = "Many of the disallowed methods are disallowed to force code to use the feature-conditional re-exports from this module, but this module itself is exempt from that rule."
+)]
 mod std_ops_for_no_std {
     //! Provides standardized names for [`f32`] operations which may not be
     //! supported on `no_std` platforms.