rustup https://github.com/rust-lang/rust/pull/67455

[rust.git] / clippy_lints / src / neg_cmp_op_on_partial_ord.rs

diff --git a/clippy_lints/src/neg_cmp_op_on_partial_ord.rs b/clippy_lints/src/neg_cmp_op_on_partial_ord.rs
index 50031dd68cf15dd2e5496e3f1d9bb91c22c31458..432d2552f2fee43e668305f90da3bb6541bf5a4e 100644 (file)
--- a/clippy_lints/src/neg_cmp_op_on_partial_ord.rs
+++ b/clippy_lints/src/neg_cmp_op_on_partial_ord.rs
@@ -1,66 +1,57 @@
 use if_chain::if_chain;
+use rustc::declare_lint_pass;
 use rustc::hir::*;
 use rustc::lint::{in_external_macro, LateContext, LateLintPass, LintArray, LintContext, LintPass};
-use rustc::{declare_tool_lint, lint_array};
+use rustc_session::declare_tool_lint;
 
 use crate::utils::{self, paths, span_lint};
 
-/// **What it does:**
-/// Checks for the usage of negated comparison operators on types which only implement
-/// `PartialOrd` (e.g. `f64`).
-///
-/// **Why is this bad?**
-/// These operators make it easy to forget that the underlying types actually allow not only three
-/// potential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is
-/// especially easy to miss if the operator based comparison result is negated.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-///
-/// ```rust
-/// use std::cmp::Ordering;
-///
-/// // Bad
-/// let a = 1.0;
-/// let b = std::f64::NAN;
-///
-/// let _not_less_or_equal = !(a <= b);
-///
-/// // Good
-/// let a = 1.0;
-/// let b = std::f64::NAN;
-///
-/// let _not_less_or_equal = match a.partial_cmp(&b) {
-///     None | Some(Ordering::Greater) => true,
-///     _ => false,
-/// };
-/// ```
 declare_clippy_lint! {
+    /// **What it does:**
+    /// Checks for the usage of negated comparison operators on types which only implement
+    /// `PartialOrd` (e.g., `f64`).
+    ///
+    /// **Why is this bad?**
+    /// These operators make it easy to forget that the underlying types actually allow not only three
+    /// potential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is
+    /// especially easy to miss if the operator based comparison result is negated.
+    ///
+    /// **Known problems:** None.
+    ///
+    /// **Example:**
+    ///
+    /// ```rust
+    /// use std::cmp::Ordering;
+    ///
+    /// // Bad
+    /// let a = 1.0;
+    /// let b = std::f64::NAN;
+    ///
+    /// let _not_less_or_equal = !(a <= b);
+    ///
+    /// // Good
+    /// let a = 1.0;
+    /// let b = std::f64::NAN;
+    ///
+    /// let _not_less_or_equal = match a.partial_cmp(&b) {
+    ///     None | Some(Ordering::Greater) => true,
+    ///     _ => false,
+    /// };
+    /// ```
     pub NEG_CMP_OP_ON_PARTIAL_ORD,
     complexity,
     "The use of negated comparison operators on partially ordered types may produce confusing code."
 }
 
-pub struct NoNegCompOpForPartialOrd;
-
-impl LintPass for NoNegCompOpForPartialOrd {
-    fn get_lints(&self) -> LintArray {
-        lint_array!(NEG_CMP_OP_ON_PARTIAL_ORD)
-    }
-
-    fn name(&self) -> &'static str {
-        "NoNegCompOpForPartialOrd"
-    }
-}
+declare_lint_pass!(NoNegCompOpForPartialOrd => [NEG_CMP_OP_ON_PARTIAL_ORD]);
 
 impl<'a, 'tcx> LateLintPass<'a, 'tcx> for NoNegCompOpForPartialOrd {
     fn check_expr(&mut self, cx: &LateContext<'a, 'tcx>, expr: &'tcx Expr) {
         if_chain! {
 
             if !in_external_macro(cx.sess(), expr.span);
-            if let ExprKind::Unary(UnOp::UnNot, ref inner) = expr.node;
-            if let ExprKind::Binary(ref op, ref left, _) = inner.node;
+            if let ExprKind::Unary(UnOp::UnNot, ref inner) = expr.kind;
+            if let ExprKind::Binary(ref op, ref left, _) = inner.kind;
             if let BinOpKind::Le | BinOpKind::Ge | BinOpKind::Lt | BinOpKind::Gt = op.node;
 
             then {