From 71080dd1d45007e9f806bb913cae47531c4dee12 Mon Sep 17 00:00:00 2001 From: Jake Goulding Date: Sat, 2 Mar 2024 09:55:06 -0500 Subject: [PATCH] Document how removing a type's field can be bad and what to do instead Related to #119645 --- compiler/rustc_lint_defs/src/builtin.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/compiler/rustc_lint_defs/src/builtin.rs b/compiler/rustc_lint_defs/src/builtin.rs index 94f8bbe2437..54b86ec39ab 100644 --- a/compiler/rustc_lint_defs/src/builtin.rs +++ b/compiler/rustc_lint_defs/src/builtin.rs @@ -702,6 +702,20 @@ declare_lint! { /// `PhantomData`. /// /// Otherwise consider removing the unused code. + /// + /// ### Limitations + /// + /// Removing fields that are only used for side-effects and never + /// read will result in behavioral changes. Examples of this + /// include: + /// + /// - If a field's value performs an action when it is dropped. + /// - If a field's type does not implement an auto trait + /// (e.g. `Send`, `Sync`, `Unpin`). + /// + /// For side-effects from dropping field values, this lint should + /// be allowed on those fields. For side-effects from containing + /// field types, `PhantomData` should be used. pub DEAD_CODE, Warn, "detect unused, unexported items"