| mod crosspointer_transmute; |
| mod eager_transmute; |
| mod missing_transmute_annotations; |
| mod transmute_float_to_int; |
| mod transmute_int_to_bool; |
| mod transmute_int_to_char; |
| mod transmute_int_to_float; |
| mod transmute_int_to_non_zero; |
| mod transmute_null_to_fn; |
| mod transmute_num_to_bytes; |
| mod transmute_ptr_to_ptr; |
| mod transmute_ptr_to_ref; |
| mod transmute_ref_to_ref; |
| mod transmute_undefined_repr; |
| mod transmutes_expressible_as_ptr_casts; |
| mod transmuting_null; |
| mod unsound_collection_transmute; |
| mod useless_transmute; |
| mod utils; |
| mod wrong_transmute; |
| |
| use clippy_config::msrvs::Msrv; |
| use clippy_utils::in_constant; |
| use rustc_hir::{Expr, ExprKind, QPath}; |
| use rustc_lint::{LateContext, LateLintPass}; |
| use rustc_session::impl_lint_pass; |
| use rustc_span::symbol::sym; |
| |
| 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 behavior. |
| /// |
| /// ### 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') |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub WRONG_TRANSMUTE, |
| correctness, |
| "transmutes that are confusing at best, undefined behavior at worst and always useless" |
| } |
| |
| // FIXME: Move this to `complexity` again, after #5343 is fixed |
| 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. |
| /// |
| /// ### Example |
| /// ```rust,ignore |
| /// core::intrinsics::transmute(t); // where the result type is the same as `t`'s |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub USELESS_TRANSMUTE, |
| complexity, |
| "transmutes that have the same to and from types or could be a cast/coercion" |
| } |
| |
| // FIXME: Merge this lint with USELESS_TRANSMUTE once that is out of the nursery. |
| declare_clippy_lint! { |
| /// ### What it does |
| ///Checks for transmutes that could be a pointer cast. |
| /// |
| /// ### Why is this bad? |
| /// Readability. The code tricks people into thinking that |
| /// something complex is going on. |
| /// |
| /// ### Example |
| /// |
| /// ```no_run |
| /// # let p: *const [i32] = &[]; |
| /// unsafe { std::mem::transmute::<*const [i32], *const [u16]>(p) }; |
| /// ``` |
| /// Use instead: |
| /// ```no_run |
| /// # let p: *const [i32] = &[]; |
| /// p as *const [u16]; |
| /// ``` |
| #[clippy::version = "1.47.0"] |
| pub TRANSMUTES_EXPRESSIBLE_AS_PTR_CASTS, |
| complexity, |
| "transmutes that could be a pointer cast" |
| } |
| |
| 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. |
| /// |
| /// ### Example |
| /// ```rust,ignore |
| /// core::intrinsics::transmute(t) // where the result type is the same as |
| /// // `*t` or `&t`'s |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub CROSSPOINTER_TRANSMUTE, |
| complexity, |
| "transmutes that have to or from types that are a pointer to the other" |
| } |
| |
| 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 |
| /// - `mem::transmute` in statics and constants is stable from Rust 1.46.0, |
| /// while dereferencing raw pointer is not stable yet. |
| /// If you need to do this in those places, |
| /// you would have to use `transmute` instead. |
| /// |
| /// ### Example |
| /// ```rust,ignore |
| /// unsafe { |
| /// let _: &T = std::mem::transmute(p); // where p: *const T |
| /// } |
| /// |
| /// // can be written: |
| /// let _: &T = &*p; |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_PTR_TO_REF, |
| complexity, |
| "transmutes from a pointer to a reference type" |
| } |
| |
| 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 |
| /// ```no_run |
| /// let x = 1_u32; |
| /// unsafe { |
| /// let _: char = std::mem::transmute(x); // where x: u32 |
| /// } |
| /// |
| /// // should be: |
| /// let _ = std::char::from_u32(x).unwrap(); |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_INT_TO_CHAR, |
| complexity, |
| "transmutes from an integer to a `char`" |
| } |
| |
| 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 |
| /// ```no_run |
| /// let b: &[u8] = &[1_u8, 2_u8]; |
| /// unsafe { |
| /// let _: &str = std::mem::transmute(b); // where b: &[u8] |
| /// } |
| /// |
| /// // should be: |
| /// let _ = std::str::from_utf8(b).unwrap(); |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_BYTES_TO_STR, |
| complexity, |
| "transmutes from a `&[u8]` to a `&str`" |
| } |
| |
| 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`. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// let x = 1_u8; |
| /// unsafe { |
| /// let _: bool = std::mem::transmute(x); // where x: u8 |
| /// } |
| /// |
| /// // should be: |
| /// let _: bool = x != 0; |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_INT_TO_BOOL, |
| complexity, |
| "transmutes from an integer to a `bool`" |
| } |
| |
| 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. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// unsafe { |
| /// let _: f32 = std::mem::transmute(1_u32); // where x: u32 |
| /// } |
| /// |
| /// // should be: |
| /// let _: f32 = f32::from_bits(1_u32); |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_INT_TO_FLOAT, |
| complexity, |
| "transmutes from an integer to a float" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmutes from integers to `NonZero*` types, and suggests their `new_unchecked` |
| /// method instead. |
| /// |
| /// ### Why is this bad? |
| /// Transmutes work on any types and thus might cause unsoundness when those types change |
| /// elsewhere. `new_unchecked` only works for the appropriate types instead. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// # use core::num::NonZeroU32; |
| /// let _non_zero: NonZeroU32 = unsafe { std::mem::transmute(123) }; |
| /// ``` |
| /// Use instead: |
| /// ```no_run |
| /// # use core::num::NonZeroU32; |
| /// let _non_zero = unsafe { NonZeroU32::new_unchecked(123) }; |
| /// ``` |
| #[clippy::version = "1.69.0"] |
| pub TRANSMUTE_INT_TO_NON_ZERO, |
| complexity, |
| "transmutes from an integer to a non-zero wrapper" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmutes from a float to an integer. |
| /// |
| /// ### Why is this bad? |
| /// Transmutes are dangerous and error-prone, whereas `to_bits` is intuitive |
| /// and safe. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// unsafe { |
| /// let _: u32 = std::mem::transmute(1f32); |
| /// } |
| /// |
| /// // should be: |
| /// let _: u32 = 1f32.to_bits(); |
| /// ``` |
| #[clippy::version = "1.41.0"] |
| pub TRANSMUTE_FLOAT_TO_INT, |
| complexity, |
| "transmutes from a float to an integer" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmutes from a number to an array of `u8` |
| /// |
| /// ### Why this is bad? |
| /// Transmutes are dangerous and error-prone, whereas `to_ne_bytes` |
| /// is intuitive and safe. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// unsafe { |
| /// let x: [u8; 8] = std::mem::transmute(1i64); |
| /// } |
| /// |
| /// // should be |
| /// let x: [u8; 8] = 0i64.to_ne_bytes(); |
| /// ``` |
| #[clippy::version = "1.58.0"] |
| pub TRANSMUTE_NUM_TO_BYTES, |
| complexity, |
| "transmutes from a number to an array of `u8`" |
| } |
| |
| 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. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// 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) }; |
| /// ``` |
| #[clippy::version = "pre 1.29.0"] |
| pub TRANSMUTE_PTR_TO_PTR, |
| pedantic, |
| "transmutes from a pointer to a pointer / a reference to a reference" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmutes between collections whose |
| /// types have different ABI, size or alignment. |
| /// |
| /// ### Why is this bad? |
| /// This is undefined behavior. |
| /// |
| /// ### Known problems |
| /// Currently, we cannot know whether a type is a |
| /// collection, so we just lint the ones that come with `std`. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// // different size, therefore likely out-of-bounds memory access |
| /// // You absolutely do not want this in your code! |
| /// unsafe { |
| /// std::mem::transmute::<_, Vec<u32>>(vec![2_u16]) |
| /// }; |
| /// ``` |
| /// |
| /// You must always iterate, map and collect the values: |
| /// |
| /// ```no_run |
| /// vec![2_u16].into_iter().map(u32::from).collect::<Vec<_>>(); |
| /// ``` |
| #[clippy::version = "1.40.0"] |
| pub UNSOUND_COLLECTION_TRANSMUTE, |
| correctness, |
| "transmute between collections of layout-incompatible types" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmutes between types which do not have a representation defined relative to |
| /// each other. |
| /// |
| /// ### Why is this bad? |
| /// The results of such a transmute are not defined. |
| /// |
| /// ### Known problems |
| /// This lint has had multiple problems in the past and was moved to `nursery`. See issue |
| /// [#8496](https://github.com/rust-lang/rust-clippy/issues/8496) for more details. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// struct Foo<T>(u32, T); |
| /// let _ = unsafe { core::mem::transmute::<Foo<u32>, Foo<i32>>(Foo(0u32, 0u32)) }; |
| /// ``` |
| /// Use instead: |
| /// ```no_run |
| /// #[repr(C)] |
| /// struct Foo<T>(u32, T); |
| /// let _ = unsafe { core::mem::transmute::<Foo<u32>, Foo<i32>>(Foo(0u32, 0u32)) }; |
| /// ``` |
| #[clippy::version = "1.60.0"] |
| pub TRANSMUTE_UNDEFINED_REPR, |
| nursery, |
| "transmute to or from a type with an undefined representation" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for transmute calls which would receive a null pointer. |
| /// |
| /// ### Why is this bad? |
| /// Transmuting a null pointer is undefined behavior. |
| /// |
| /// ### Known problems |
| /// Not all cases can be detected at the moment of this writing. |
| /// For example, variables which hold a null pointer and are then fed to a `transmute` |
| /// call, aren't detectable yet. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// let null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) }; |
| /// ``` |
| #[clippy::version = "1.35.0"] |
| pub TRANSMUTING_NULL, |
| correctness, |
| "transmutes from a null pointer to a reference, which is undefined behavior" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for null function pointer creation through transmute. |
| /// |
| /// ### Why is this bad? |
| /// Creating a null function pointer is undefined behavior. |
| /// |
| /// More info: https://doc.rust-lang.org/nomicon/ffi.html#the-nullable-pointer-optimization |
| /// |
| /// ### Known problems |
| /// Not all cases can be detected at the moment of this writing. |
| /// For example, variables which hold a null pointer and are then fed to a `transmute` |
| /// call, aren't detectable yet. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// let null_fn: fn() = unsafe { std::mem::transmute( std::ptr::null::<()>() ) }; |
| /// ``` |
| /// Use instead: |
| /// ```no_run |
| /// let null_fn: Option<fn()> = None; |
| /// ``` |
| #[clippy::version = "1.68.0"] |
| pub TRANSMUTE_NULL_TO_FN, |
| correctness, |
| "transmute results in a null function pointer, which is undefined behavior" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks for integer validity checks, followed by a transmute that is (incorrectly) evaluated |
| /// eagerly (e.g. using `bool::then_some`). |
| /// |
| /// ### Why is this bad? |
| /// Eager evaluation means that the `transmute` call is executed regardless of whether the condition is true or false. |
| /// This can introduce unsoundness and other subtle bugs. |
| /// |
| /// ### Example |
| /// Consider the following function which is meant to convert an unsigned integer to its enum equivalent via transmute. |
| /// |
| /// ```no_run |
| /// #[repr(u8)] |
| /// enum Opcode { |
| /// Add = 0, |
| /// Sub = 1, |
| /// Mul = 2, |
| /// Div = 3 |
| /// } |
| /// |
| /// fn int_to_opcode(op: u8) -> Option<Opcode> { |
| /// (op < 4).then_some(unsafe { std::mem::transmute(op) }) |
| /// } |
| /// ``` |
| /// This may appear fine at first given that it checks that the `u8` is within the validity range of the enum, |
| /// *however* the transmute is evaluated eagerly, meaning that it executes even if `op >= 4`! |
| /// |
| /// This makes the function unsound, because it is possible for the caller to cause undefined behavior |
| /// (creating an enum with an invalid bitpattern) entirely in safe code only by passing an incorrect value, |
| /// which is normally only a bug that is possible in unsafe code. |
| /// |
| /// One possible way in which this can go wrong practically is that the compiler sees it as: |
| /// ```rust,ignore (illustrative) |
| /// let temp: Foo = unsafe { std::mem::transmute(op) }; |
| /// (0 < 4).then_some(temp) |
| /// ``` |
| /// and optimizes away the `(0 < 4)` check based on the assumption that since a `Foo` was created from `op` with the validity range `0..3`, |
| /// it is **impossible** for this condition to be false. |
| /// |
| /// In short, it is possible for this function to be optimized in a way that makes it [never return `None`](https://godbolt.org/z/ocrcenevq), |
| /// even if passed the value `4`. |
| /// |
| /// This can be avoided by instead using lazy evaluation. For the example above, this should be written: |
| /// ```rust,ignore (illustrative) |
| /// fn int_to_opcode(op: u8) -> Option<Opcode> { |
| /// (op < 4).then(|| unsafe { std::mem::transmute(op) }) |
| /// ^^^^ ^^ `bool::then` only executes the closure if the condition is true! |
| /// } |
| /// ``` |
| #[clippy::version = "1.77.0"] |
| pub EAGER_TRANSMUTE, |
| correctness, |
| "eager evaluation of `transmute`" |
| } |
| |
| declare_clippy_lint! { |
| /// ### What it does |
| /// Checks if transmute calls have all generics specified. |
| /// |
| /// ### Why is this bad? |
| /// If not set, some unexpected output type could be retrieved instead of the expected one, |
| /// potentially leading to invalid code. |
| /// |
| /// This is particularly dangerous in case a seemingly innocent/unrelated change can cause type |
| /// inference to start inferring a different type. E.g. the transmute is the tail expression of |
| /// an `if` branch, and a different branches type changes, causing the transmute to silently |
| /// have a different type, instead of a proper error. |
| /// |
| /// ### Example |
| /// ```no_run |
| /// # unsafe { |
| /// let x: i32 = std::mem::transmute([1u16, 2u16]); |
| /// # } |
| /// ``` |
| /// Use instead: |
| /// ```no_run |
| /// # unsafe { |
| /// let x = std::mem::transmute::<[u16; 2], i32>([1u16, 2u16]); |
| /// # } |
| /// ``` |
| #[clippy::version = "1.77.0"] |
| pub MISSING_TRANSMUTE_ANNOTATIONS, |
| suspicious, |
| "warns if a transmute call doesn't have all generics specified" |
| } |
| |
| pub struct Transmute { |
| msrv: Msrv, |
| } |
| impl_lint_pass!(Transmute => [ |
| CROSSPOINTER_TRANSMUTE, |
| TRANSMUTE_PTR_TO_REF, |
| TRANSMUTE_PTR_TO_PTR, |
| USELESS_TRANSMUTE, |
| WRONG_TRANSMUTE, |
| TRANSMUTE_INT_TO_CHAR, |
| TRANSMUTE_BYTES_TO_STR, |
| TRANSMUTE_INT_TO_BOOL, |
| TRANSMUTE_INT_TO_FLOAT, |
| TRANSMUTE_INT_TO_NON_ZERO, |
| TRANSMUTE_FLOAT_TO_INT, |
| TRANSMUTE_NUM_TO_BYTES, |
| UNSOUND_COLLECTION_TRANSMUTE, |
| TRANSMUTES_EXPRESSIBLE_AS_PTR_CASTS, |
| TRANSMUTE_UNDEFINED_REPR, |
| TRANSMUTING_NULL, |
| TRANSMUTE_NULL_TO_FN, |
| EAGER_TRANSMUTE, |
| MISSING_TRANSMUTE_ANNOTATIONS, |
| ]); |
| impl Transmute { |
| #[must_use] |
| pub fn new(msrv: Msrv) -> Self { |
| Self { msrv } |
| } |
| } |
| impl<'tcx> LateLintPass<'tcx> for Transmute { |
| fn check_expr(&mut self, cx: &LateContext<'tcx>, e: &'tcx Expr<'_>) { |
| if let ExprKind::Call(path_expr, [arg]) = e.kind |
| && let ExprKind::Path(QPath::Resolved(None, path)) = path_expr.kind |
| && let Some(def_id) = path.res.opt_def_id() |
| && cx.tcx.is_diagnostic_item(sym::transmute, def_id) |
| { |
| // Avoid suggesting non-const operations in const contexts: |
| // - from/to bits (https://github.com/rust-lang/rust/issues/73736) |
| // - dereferencing raw pointers (https://github.com/rust-lang/rust/issues/51911) |
| // - char conversions (https://github.com/rust-lang/rust/issues/89259) |
| let const_context = in_constant(cx, e.hir_id); |
| |
| let (from_ty, from_ty_adjusted) = match cx.typeck_results().expr_adjustments(arg) { |
| [] => (cx.typeck_results().expr_ty(arg), false), |
| [.., a] => (a.target, true), |
| }; |
| // Adjustments for `to_ty` happen after the call to `transmute`, so don't use them. |
| let to_ty = cx.typeck_results().expr_ty(e); |
| |
| // If useless_transmute is triggered, the other lints can be skipped. |
| if useless_transmute::check(cx, e, from_ty, to_ty, arg) { |
| return; |
| } |
| |
| let linted = wrong_transmute::check(cx, e, from_ty, to_ty) |
| | crosspointer_transmute::check(cx, e, from_ty, to_ty) |
| | transmuting_null::check(cx, e, arg, to_ty) |
| | transmute_null_to_fn::check(cx, e, arg, to_ty) |
| | transmute_ptr_to_ref::check(cx, e, from_ty, to_ty, arg, path, &self.msrv) |
| | missing_transmute_annotations::check(cx, path, from_ty, to_ty, e.hir_id) |
| | transmute_int_to_char::check(cx, e, from_ty, to_ty, arg, const_context) |
| | transmute_ref_to_ref::check(cx, e, from_ty, to_ty, arg, const_context) |
| | transmute_ptr_to_ptr::check(cx, e, from_ty, to_ty, arg) |
| | transmute_int_to_bool::check(cx, e, from_ty, to_ty, arg) |
| | transmute_int_to_float::check(cx, e, from_ty, to_ty, arg, const_context) |
| | transmute_int_to_non_zero::check(cx, e, from_ty, to_ty, arg) |
| | transmute_float_to_int::check(cx, e, from_ty, to_ty, arg, const_context) |
| | transmute_num_to_bytes::check(cx, e, from_ty, to_ty, arg, const_context) |
| | (unsound_collection_transmute::check(cx, e, from_ty, to_ty) |
| || transmute_undefined_repr::check(cx, e, from_ty, to_ty)) |
| | (eager_transmute::check(cx, e, arg, from_ty, to_ty)); |
| |
| if !linted { |
| transmutes_expressible_as_ptr_casts::check(cx, e, from_ty, from_ty_adjusted, to_ty, arg, const_context); |
| } |
| } |
| } |
| |
| extract_msrv_attr!(LateContext); |
| } |