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