]> git.lizzy.rs Git - rust.git/blobdiff - clippy_lints/src/drop_forget_ref.rs
Auto merge of #3946 - rchaser53:issue-3920, r=flip1995
[rust.git] / clippy_lints / src / drop_forget_ref.rs
index 9bead9c1d8697a47649c11c98f6f3531073fd4cf..b880e28fc647d2a573ebcb7c57f3fbc4c2a5f51b 100644 (file)
-// Copyright 2014-2018 The Rust Project Developers. See the COPYRIGHT
-// file at the top-level directory of this distribution.
-//
-// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
-// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
-// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
-// option. This file may not be copied, modified, or distributed
-// except according to those terms.
-
-
-use crate::rustc::lint::{LateContext, LateLintPass, LintArray, LintPass};
-use crate::rustc::{declare_tool_lint, lint_array};
+use crate::utils::{is_copy, match_def_path, paths, span_note_and_lint};
 use if_chain::if_chain;
-use crate::rustc::ty;
-use crate::rustc::hir::*;
-use crate::utils::{is_copy, match_def_path, opt_def_id, paths, span_note_and_lint};
+use rustc::hir::*;
+use rustc::lint::{LateContext, LateLintPass, LintArray, LintPass};
+use rustc::ty;
+use rustc::{declare_tool_lint, lint_array};
 
-/// **What it does:** Checks for calls to `std::mem::drop` with a reference
-/// instead of an owned value.
-///
-/// **Why is this bad?** Calling `drop` on a reference will only drop the
-/// reference itself, which is a no-op. It will not call the `drop` method (from
-/// the `Drop` trait implementation) on the underlying referenced value, which
-/// is likely what was intended.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let mut lock_guard = mutex.lock();
-/// std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
-/// // still locked
-/// operation_that_requires_mutex_to_be_unlocked();
-/// ```
 declare_clippy_lint! {
+    /// **What it does:** Checks for calls to `std::mem::drop` with a reference
+    /// instead of an owned value.
+    ///
+    /// **Why is this bad?** Calling `drop` on a reference will only drop the
+    /// reference itself, which is a no-op. It will not call the `drop` method (from
+    /// the `Drop` trait implementation) on the underlying referenced value, which
+    /// is likely what was intended.
+    ///
+    /// **Known problems:** None.
+    ///
+    /// **Example:**
+    /// ```ignore
+    /// let mut lock_guard = mutex.lock();
+    /// std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
+    /// // still locked
+    /// operation_that_requires_mutex_to_be_unlocked();
+    /// ```
     pub DROP_REF,
     correctness,
     "calls to `std::mem::drop` with a reference instead of an owned value"
 }
 
-/// **What it does:** Checks for calls to `std::mem::forget` with a reference
-/// instead of an owned value.
-///
-/// **Why is this bad?** Calling `forget` on a reference will only forget the
-/// reference itself, which is a no-op. It will not forget the underlying
-/// referenced
-/// value, which is likely what was intended.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let x = Box::new(1);
-/// std::mem::forget(&x) // Should have been forget(x), x will still be dropped
-/// ```
 declare_clippy_lint! {
+    /// **What it does:** Checks for calls to `std::mem::forget` with a reference
+    /// instead of an owned value.
+    ///
+    /// **Why is this bad?** Calling `forget` on a reference will only forget the
+    /// reference itself, which is a no-op. It will not forget the underlying
+    /// referenced
+    /// value, which is likely what was intended.
+    ///
+    /// **Known problems:** None.
+    ///
+    /// **Example:**
+    /// ```rust
+    /// let x = Box::new(1);
+    /// std::mem::forget(&x) // Should have been forget(x), x will still be dropped
+    /// ```
     pub FORGET_REF,
     correctness,
     "calls to `std::mem::forget` with a reference instead of an owned value"
 }
 
-/// **What it does:** Checks for calls to `std::mem::drop` with a value
-/// that derives the Copy trait
-///
-/// **Why is this bad?** Calling `std::mem::drop` [does nothing for types that
-/// implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the
-/// value will be copied and moved into the function on invocation.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let x:i32 = 42;   // i32 implements Copy
-/// std::mem::drop(x) // A copy of x is passed to the function, leaving the
-/// // original unaffected
-/// ```
 declare_clippy_lint! {
+    /// **What it does:** Checks for calls to `std::mem::drop` with a value
+    /// that derives the Copy trait
+    ///
+    /// **Why is this bad?** Calling `std::mem::drop` [does nothing for types that
+    /// implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the
+    /// value will be copied and moved into the function on invocation.
+    ///
+    /// **Known problems:** None.
+    ///
+    /// **Example:**
+    /// ```rust
+    /// let x: i32 = 42; // i32 implements Copy
+    /// std::mem::drop(x) // A copy of x is passed to the function, leaving the
+    ///                   // original unaffected
+    /// ```
     pub DROP_COPY,
     correctness,
     "calls to `std::mem::drop` with a value that implements Copy"
 }
 
-/// **What it does:** Checks for calls to `std::mem::forget` with a value that
-/// derives the Copy trait
-///
-/// **Why is this bad?** Calling `std::mem::forget` [does nothing for types that
-/// implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the
-/// value will be copied and moved into the function on invocation.
-///
-/// An alternative, but also valid, explanation is that Copy types do not
-/// implement
-/// the Drop trait, which means they have no destructors. Without a destructor,
-/// there
-/// is nothing for `std::mem::forget` to ignore.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let x:i32 = 42;     // i32 implements Copy
-/// std::mem::forget(x) // A copy of x is passed to the function, leaving the
-/// // original unaffected
-/// ```
 declare_clippy_lint! {
+    /// **What it does:** Checks for calls to `std::mem::forget` with a value that
+    /// derives the Copy trait
+    ///
+    /// **Why is this bad?** Calling `std::mem::forget` [does nothing for types that
+    /// implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the
+    /// value will be copied and moved into the function on invocation.
+    ///
+    /// An alternative, but also valid, explanation is that Copy types do not
+    /// implement
+    /// the Drop trait, which means they have no destructors. Without a destructor,
+    /// there
+    /// is nothing for `std::mem::forget` to ignore.
+    ///
+    /// **Known problems:** None.
+    ///
+    /// **Example:**
+    /// ```rust
+    /// let x: i32 = 42; // i32 implements Copy
+    /// std::mem::forget(x) // A copy of x is passed to the function, leaving the
+    ///                     // original unaffected
+    /// ```
     pub FORGET_COPY,
     correctness,
     "calls to `std::mem::forget` with a value that implements Copy"
@@ -122,6 +112,10 @@ impl LintPass for Pass {
     fn get_lints(&self) -> LintArray {
         lint_array!(DROP_REF, FORGET_REF, DROP_COPY, FORGET_COPY)
     }
+
+    fn name(&self) -> &'static str {
+        "DropForgetRef"
+    }
 }
 
 impl<'a, 'tcx> LateLintPass<'a, 'tcx> for Pass {
@@ -130,7 +124,7 @@ fn check_expr(&mut self, cx: &LateContext<'a, 'tcx>, expr: &'tcx Expr) {
             if let ExprKind::Call(ref path, ref args) = expr.node;
             if let ExprKind::Path(ref qpath) = path.node;
             if args.len() == 1;
-            if let Some(def_id) = opt_def_id(cx.tables.qpath_def(qpath, path.hir_id));
+            if let Some(def_id) = cx.tables.qpath_def(qpath, path.hir_id).opt_def_id();
             then {
                 let lint;
                 let msg;