@@ -632,70 +632,7 @@ declare_clippy_lint! {
632
632
633
633
declare_clippy_lint ! {
634
634
/// ### What it does
635
- /// Checks for (in-)equality comparisons on constant floating-point
636
- /// values (apart from zero), except in functions called `*eq*` (which probably
637
- /// implement equality for a type involving floats).
638
- ///
639
- /// ### Why restrict this?
640
- /// Floating point calculations are usually imprecise, so asking if two values are *exactly*
641
- /// equal is asking for trouble because arriving at the same logical result via different
642
- /// routes (e.g. calculation versus constant) may yield different values.
643
- ///
644
- /// ### Example
645
- ///
646
- /// ```no_run
647
- /// let a: f64 = 1000.1;
648
- /// let b: f64 = 0.2;
649
- /// let x = a + b;
650
- /// const Y: f64 = 1000.3; // Expected value.
651
- ///
652
- /// // Actual value: 1000.3000000000001
653
- /// println!("{x}");
654
- ///
655
- /// let are_equal = x == Y;
656
- /// println!("{are_equal}"); // false
657
- /// ```
658
- ///
659
- /// The correct way to compare floating point numbers is to define an allowed error margin. This
660
- /// may be challenging if there is no "natural" error margin to permit. Broadly speaking, there
661
- /// are two cases:
662
- ///
663
- /// 1. If your values are in a known range and you can define a threshold for "close enough to
664
- /// be equal", it may be appropriate to define an absolute error margin. For example, if your
665
- /// data is "length of vehicle in centimeters", you may consider 0.1 cm to be "close enough".
666
- /// 1. If your code is more general and you do not know the range of values, you should use a
667
- /// relative error margin, accepting e.g. 0.1% of error regardless of specific values.
668
- ///
669
- /// For the scenario where you can define a meaningful absolute error margin, consider using:
670
- ///
671
- /// ```no_run
672
- /// let a: f64 = 1000.1;
673
- /// let b: f64 = 0.2;
674
- /// let x = a + b;
675
- /// const Y: f64 = 1000.3; // Expected value.
676
- ///
677
- /// const ALLOWED_ERROR_VEHICLE_LENGTH_CM: f64 = 0.1;
678
- /// let within_tolerance = (x - Y).abs() < ALLOWED_ERROR_VEHICLE_LENGTH_CM;
679
- /// println!("{within_tolerance}"); // true
680
- /// ```
681
- ///
682
- /// NB! Do not use `f64::EPSILON` - while the error margin is often called "epsilon", this is
683
- /// a different use of the term that is not suitable for floating point equality comparison.
684
- /// Indeed, for the example above using `f64::EPSILON` as the allowed error would return `false`.
685
- ///
686
- /// For the scenario where no meaningful absolute error can be defined, refer to
687
- /// [the floating point guide](https://www.floating-point-gui.de/errors/comparison)
688
- /// for a reference implementation of relative error based comparison of floating point values.
689
- /// `MIN_NORMAL` in the reference implementation is equivalent to `MIN_POSITIVE` in Rust.
690
- #[ clippy:: version = "pre 1.29.0" ]
691
- pub FLOAT_CMP_CONST ,
692
- restriction,
693
- "using `==` or `!=` on float constants instead of comparing difference with an allowed error"
694
- }
695
-
696
- declare_clippy_lint ! {
697
- /// ### What it does
698
- /// Checks for getting the remainder of integer division by one or minus
635
+ /// Checks for getting the remainder of a division by one or minus
699
636
/// one.
700
637
///
701
638
/// ### Why is this bad?
@@ -869,7 +806,6 @@ impl_lint_pass!(Operators => [
869
806
INTEGER_DIVISION ,
870
807
CMP_OWNED ,
871
808
FLOAT_CMP ,
872
- FLOAT_CMP_CONST ,
873
809
MODULO_ONE ,
874
810
MODULO_ARITHMETIC ,
875
811
NEEDLESS_BITWISE_BOOL ,
0 commit comments