-use crate::utils::{last_path_segment, match_def_path, paths, snippet, span_lint, span_lint_and_then};
-use crate::utils::{opt_def_id, sugg};
+use crate::utils::{last_path_segment, match_def_path, paths, snippet, span_lint, span_lint_and_then, sugg};
use if_chain::if_chain;
use rustc::hir::*;
use rustc::lint::{LateContext, LateLintPass, LintArray, LintPass};
use std::borrow::Cow;
use syntax::ast;
-/// **What it does:** Checks for transmutes that can't ever be correct on any
-/// architecture.
-///
-/// **Why is this bad?** It's basically guaranteed to be undefined behaviour.
-///
-/// **Known problems:** When accessing C, users might want to store pointer
-/// sized objects in `extradata` arguments to save an allocation.
-///
-/// **Example:**
-/// ```rust
-/// let ptr: *const T = core::intrinsics::transmute('x')
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes that can't ever be correct on any
+ /// architecture.
+ ///
+ /// **Why is this bad?** It's basically guaranteed to be undefined behaviour.
+ ///
+ /// **Known problems:** When accessing C, users might want to store pointer
+ /// sized objects in `extradata` arguments to save an allocation.
+ ///
+ /// **Example:**
+ /// ```ignore
+ /// let ptr: *const T = core::intrinsics::transmute('x')
+ /// ```
pub WRONG_TRANSMUTE,
correctness,
"transmutes that are confusing at best, undefined behaviour at worst and always useless"
}
-/// **What it does:** Checks for transmutes to the original type of the object
-/// and transmutes that could be a cast.
-///
-/// **Why is this bad?** Readability. The code tricks people into thinking that
-/// something complex is going on.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// core::intrinsics::transmute(t) // where the result type is the same as `t`'s
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes to the original type of the object
+ /// and transmutes that could be a cast.
+ ///
+ /// **Why is this bad?** Readability. The code tricks people into thinking that
+ /// something complex is going on.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// core::intrinsics::transmute(t) // where the result type is the same as `t`'s
+ /// ```
pub USELESS_TRANSMUTE,
complexity,
"transmutes that have the same to and from types or could be a cast/coercion"
}
-/// **What it does:** Checks for transmutes between a type `T` and `*T`.
-///
-/// **Why is this bad?** It's easy to mistakenly transmute between a type and a
-/// pointer to that type.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// core::intrinsics::transmute(t) // where the result type is the same as
-/// // `*t` or `&t`'s
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes between a type `T` and `*T`.
+ ///
+ /// **Why is this bad?** It's easy to mistakenly transmute between a type and a
+ /// pointer to that type.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// core::intrinsics::transmute(t) // where the result type is the same as
+ /// // `*t` or `&t`'s
+ /// ```
pub CROSSPOINTER_TRANSMUTE,
complexity,
"transmutes that have to or from types that are a pointer to the other"
}
-/// **What it does:** Checks for transmutes from a pointer to a reference.
-///
-/// **Why is this bad?** This can always be rewritten with `&` and `*`.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let _: &T = std::mem::transmute(p); // where p: *const T
-///
-/// // can be written:
-/// let _: &T = &*p;
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from a pointer to a reference.
+ ///
+ /// **Why is this bad?** This can always be rewritten with `&` and `*`.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let _: &T = std::mem::transmute(p); // where p: *const T
+ ///
+ /// // can be written:
+ /// let _: &T = &*p;
+ /// ```
pub TRANSMUTE_PTR_TO_REF,
complexity,
"transmutes from a pointer to a reference type"
}
-/// **What it does:** Checks for transmutes from an integer to a `char`.
-///
-/// **Why is this bad?** Not every integer is a Unicode scalar value.
-///
-/// **Known problems:**
-/// - [`from_u32`] which this lint suggests using is slower than `transmute`
-/// as it needs to validate the input.
-/// If you are certain that the input is always a valid Unicode scalar value,
-/// use [`from_u32_unchecked`] which is as fast as `transmute`
-/// but has a semantically meaningful name.
-/// - You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.
-///
-/// [`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html
-/// [`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html
-///
-/// **Example:**
-/// ```rust
-/// let _: char = std::mem::transmute(x); // where x: u32
-///
-/// // should be:
-/// let _ = std::char::from_u32(x).unwrap();
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from an integer to a `char`.
+ ///
+ /// **Why is this bad?** Not every integer is a Unicode scalar value.
+ ///
+ /// **Known problems:**
+ /// - [`from_u32`] which this lint suggests using is slower than `transmute`
+ /// as it needs to validate the input.
+ /// If you are certain that the input is always a valid Unicode scalar value,
+ /// use [`from_u32_unchecked`] which is as fast as `transmute`
+ /// but has a semantically meaningful name.
+ /// - You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.
+ ///
+ /// [`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html
+ /// [`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let _: char = std::mem::transmute(x); // where x: u32
+ ///
+ /// // should be:
+ /// let _ = std::char::from_u32(x).unwrap();
+ /// ```
pub TRANSMUTE_INT_TO_CHAR,
complexity,
"transmutes from an integer to a `char`"
}
-/// **What it does:** Checks for transmutes from a `&[u8]` to a `&str`.
-///
-/// **Why is this bad?** Not every byte slice is a valid UTF-8 string.
-///
-/// **Known problems:**
-/// - [`from_utf8`] which this lint suggests using is slower than `transmute`
-/// as it needs to validate the input.
-/// If you are certain that the input is always a valid UTF-8,
-/// use [`from_utf8_unchecked`] which is as fast as `transmute`
-/// but has a semantically meaningful name.
-/// - You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.
-///
-/// [`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html
-/// [`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html
-///
-/// **Example:**
-/// ```rust
-/// let _: &str = std::mem::transmute(b); // where b: &[u8]
-///
-/// // should be:
-/// let _ = std::str::from_utf8(b).unwrap();
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from a `&[u8]` to a `&str`.
+ ///
+ /// **Why is this bad?** Not every byte slice is a valid UTF-8 string.
+ ///
+ /// **Known problems:**
+ /// - [`from_utf8`] which this lint suggests using is slower than `transmute`
+ /// as it needs to validate the input.
+ /// If you are certain that the input is always a valid UTF-8,
+ /// use [`from_utf8_unchecked`] which is as fast as `transmute`
+ /// but has a semantically meaningful name.
+ /// - You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.
+ ///
+ /// [`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html
+ /// [`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let _: &str = std::mem::transmute(b); // where b: &[u8]
+ ///
+ /// // should be:
+ /// let _ = std::str::from_utf8(b).unwrap();
+ /// ```
pub TRANSMUTE_BYTES_TO_STR,
complexity,
"transmutes from a `&[u8]` to a `&str`"
}
-/// **What it does:** Checks for transmutes from an integer to a `bool`.
-///
-/// **Why is this bad?** This might result in an invalid in-memory representation of a `bool`.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let _: bool = std::mem::transmute(x); // where x: u8
-///
-/// // should be:
-/// let _: bool = x != 0;
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from an integer to a `bool`.
+ ///
+ /// **Why is this bad?** This might result in an invalid in-memory representation of a `bool`.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let _: bool = std::mem::transmute(x); // where x: u8
+ ///
+ /// // should be:
+ /// let _: bool = x != 0;
+ /// ```
pub TRANSMUTE_INT_TO_BOOL,
complexity,
"transmutes from an integer to a `bool`"
}
-/// **What it does:** Checks for transmutes from an integer to a float.
-///
-/// **Why is this bad?** Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive
-/// and safe.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let _: f32 = std::mem::transmute(x); // where x: u32
-///
-/// // should be:
-/// let _: f32 = f32::from_bits(x);
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from an integer to a float.
+ ///
+ /// **Why is this bad?** Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive
+ /// and safe.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let _: f32 = std::mem::transmute(x); // where x: u32
+ ///
+ /// // should be:
+ /// let _: f32 = f32::from_bits(x);
+ /// ```
pub TRANSMUTE_INT_TO_FLOAT,
complexity,
"transmutes from an integer to a float"
}
-/// **What it does:** Checks for transmutes from a pointer to a pointer, or
-/// from a reference to a reference.
-///
-/// **Why is this bad?** Transmutes are dangerous, and these can instead be
-/// written as casts.
-///
-/// **Known problems:** None.
-///
-/// **Example:**
-/// ```rust
-/// let ptr = &1u32 as *const u32;
-/// unsafe {
-/// // pointer-to-pointer transmute
-/// let _: *const f32 = std::mem::transmute(ptr);
-/// // ref-ref transmute
-/// let _: &f32 = std::mem::transmute(&1u32);
-/// }
-/// // These can be respectively written:
-/// let _ = ptr as *const f32
-/// let _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };
-/// ```
declare_clippy_lint! {
+ /// **What it does:** Checks for transmutes from a pointer to a pointer, or
+ /// from a reference to a reference.
+ ///
+ /// **Why is this bad?** Transmutes are dangerous, and these can instead be
+ /// written as casts.
+ ///
+ /// **Known problems:** None.
+ ///
+ /// **Example:**
+ /// ```rust
+ /// let ptr = &1u32 as *const u32;
+ /// unsafe {
+ /// // pointer-to-pointer transmute
+ /// let _: *const f32 = std::mem::transmute(ptr);
+ /// // ref-ref transmute
+ /// let _: &f32 = std::mem::transmute(&1u32);
+ /// }
+ /// // These can be respectively written:
+ /// let _ = ptr as *const f32
+ /// let _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };
+ /// ```
pub TRANSMUTE_PTR_TO_PTR,
complexity,
"transmutes from a pointer to a pointer / a reference to a reference"
fn check_expr(&mut self, cx: &LateContext<'a, 'tcx>, e: &'tcx Expr) {
if let ExprKind::Call(ref path_expr, ref args) = e.node {
if let ExprKind::Path(ref qpath) = path_expr.node {
- if let Some(def_id) = opt_def_id(cx.tables.qpath_def(qpath, path_expr.hir_id)) {
+ if let Some(def_id) = cx.tables.qpath_def(qpath, path_expr.hir_id).opt_def_id() {
if match_def_path(cx.tcx, def_id, &paths::TRANSMUTE) {
let from_ty = cx.tables.expr_ty(&args[0]);
let to_ty = cx.tables.expr_ty(e);
|db| {
let arg = sugg::Sugg::hir(cx, &args[0], "..");
let arg = if let ty::Int(_) = from_ty.sty {
- arg.as_ty(ty::Uint(ast::UintTy::U32))
+ arg.as_ty(ast::UintTy::U32)
} else {
arg
};
}
}
-/// Get the snippet of `Bar` in `…::transmute<Foo, &Bar>`. If that snippet is
+/// Gets the snippet of `Bar` in `…::transmute<Foo, &Bar>`. If that snippet is
/// not available , use
/// the type's `ToString` implementation. In weird cases it could lead to types
/// with invalid `'_`