modify code

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

diff --git a/clippy_lints/src/arithmetic.rs b/clippy_lints/src/arithmetic.rs
index 9861d8cfc4e5f4146e7101d57fbea558b2d9c081..e0c1d6ab6e12235577859c606f9e572dcbaf9f0f 100644 (file)
--- a/clippy_lints/src/arithmetic.rs
+++ b/clippy_lints/src/arithmetic.rs
@@ -1,12 +1,13 @@
-use crate::consts::constant_simple;
-use crate::utils::span_lint;
+use clippy_utils::consts::constant_simple;
+use clippy_utils::diagnostics::span_lint;
 use rustc_hir as hir;
 use rustc_lint::{LateContext, LateLintPass};
 use rustc_session::{declare_tool_lint, impl_lint_pass};
 use rustc_span::source_map::Span;
 
 declare_clippy_lint! {
-    /// **What it does:** Checks for integer arithmetic operations which could overflow or panic.
+    /// ### What it does
+    /// Checks for integer arithmetic operations which could overflow or panic.
     ///
     /// Specifically, checks for any operators (`+`, `-`, `*`, `<<`, etc) which are capable
     /// of overflowing according to the [Rust
@@ -14,35 +15,36 @@
     /// or which can panic (`/`, `%`). No bounds analysis or sophisticated reasoning is
     /// attempted.
     ///
-    /// **Why is this bad?** Integer overflow will trigger a panic in debug builds or will wrap in
+    /// ### Why is this bad?
+    /// Integer overflow will trigger a panic in debug builds or will wrap in
     /// release mode. Division by zero will cause a panic in either mode. In some applications one
     /// wants explicitly checked, wrapping or saturating arithmetic.
     ///
-    /// **Known problems:** None.
-    ///
-    /// **Example:**
+    /// ### Example
     /// ```rust
     /// # let a = 0;
     /// a + 1;
     /// ```
+    #[clippy::version = "pre 1.29.0"]
     pub INTEGER_ARITHMETIC,
     restriction,
     "any integer arithmetic expression which could overflow or panic"
 }
 
 declare_clippy_lint! {
-    /// **What it does:** Checks for float arithmetic.
+    /// ### What it does
+    /// Checks for float arithmetic.
     ///
-    /// **Why is this bad?** For some embedded systems or kernel development, it
+    /// ### Why is this bad?
+    /// For some embedded systems or kernel development, it
     /// can be useful to rule out floating-point numbers.
     ///
-    /// **Known problems:** None.
-    ///
-    /// **Example:**
+    /// ### Example
     /// ```rust
     /// # let a = 0.0;
     /// a + 1.0;
     /// ```
+    #[clippy::version = "pre 1.29.0"]
     pub FLOAT_ARITHMETIC,
     restriction,
     "any floating-point arithmetic statement"
@@ -91,7 +93,7 @@ fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx hir::Expr<'_>) {
                     match op.node {
                         hir::BinOpKind::Div | hir::BinOpKind::Rem => match &r.kind {
                             hir::ExprKind::Lit(_lit) => (),
-                            hir::ExprKind::Unary(hir::UnOp::UnNeg, expr) => {
+                            hir::ExprKind::Unary(hir::UnOp::Neg, expr) => {
                                 if let hir::ExprKind::Lit(lit) = &expr.kind {
                                     if let rustc_ast::ast::LitKind::Int(1, _) = lit.node {
                                         span_lint(cx, INTEGER_ARITHMETIC, expr.span, "integer arithmetic detected");
@@ -114,7 +116,7 @@ fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx hir::Expr<'_>) {
                     self.expr_span = Some(expr.span);
                 }
             },
-            hir::ExprKind::Unary(hir::UnOp::UnNeg, arg) => {
+            hir::ExprKind::Unary(hir::UnOp::Neg, arg) => {
                 let ty = cx.typeck_results().expr_ty(arg);
                 if constant_simple(cx, cx.typeck_results(), expr).is_none() {
                     if ty.is_integral() {