{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicekwnh3yjhbuwz473iygqwmugsbjyxuqm6vbtso35bm5npp763mu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfygru7tilb2"
  },
  "path": "/t/pre-rfc-deprecation-and-separation-of-the-dead-code-lint/24045#post_1",
  "publishedAt": "2026-03-01T03:03:39.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "rust-lang/rfcs#0000",
    "rust-lang/rust#0000",
    "expect(unused_data_structures)]` to expect that instead of `dead_code`. The exact list can be found [here",
    "here"
  ],
  "textContent": "  * Feature Name: dead-code-lint-deprecation\n  * Start Date: 2/28/2026\n  * RFC PR: rust-lang/rfcs#0000\n  * Rust Issue: rust-lang/rust#0000\n\n\n\n## Summary\n\nDeprecate the `dead_code` lint and give each item linted by `dead_code` its own item-specific `unused` lint.\n\n## Motivation\n\nIn many cases, a user will want to silence a `dead_code` warning for a specific category of items, such as all imports while refactoring or dead variants of not dead functions. Since this is not possible, they will have to choose between allowing all things covered by `dead_code` or in that context or not silencing the warning.\n\nFor functions specifically, it is very rare to wish to silence all `dead_code` lints inside the function, most often it is the function itself that it is dead and silencing all `dead_code` lints on its interior is a negative side-effect. The same is likely true for dead modules but they are far rarer so there is little to say either way.\n\nThe reason for deprecation and not giving dead code its own category, is that many, if not most programmers new to Rust but not programming in general, upon seeing a `dead_code` lint name, will assume it covers many, if not all, of the things in the `unused` category, especially so for the `unreachable_code` lint.\n\nThere is also no apparent rhyme or reason as to why a certain items get their own `unused` lint right now or is grouped in with `dead_code`, i.e. why are imports not in `dead_code`? It makes it clear what kind of `dead_code` is expected in a given context when reading code.\n\n## Guide-level explanation\n\nFor existing Rust programmers: The `dead_code` lint is now deprecated, each of the different items it covered have their own lints now so if you have a dead `struct` you'd use an `#expect(unused_data_structures)]` to expect that instead of `dead_code`. The exact list can be found [here.\n(The dead code lint docs would be updated to have a table with each thing covered and what now covers that).\n\nFor new Rust programmers: Each type of unused code has its own lint, but they can be collectively toggled by the `unused` lint, the exact list of lints for unused code can be found here.\n(There'd be nothing to distinguish between `unused` lints currently under `dead_code` and ones not under it).\n\n## Reference-level explanation\n\nThe proposed list of items linted and the lint:\n\nModules......................................`unused_module`\nFunctions....................................`unused_functions`\nType Aliases...............................`unused_type_alias`\nStructs, Enums, Unions..........`unused_data_structures`\nConsts/Statics............................`unused_compile_time_var`\nTraits..............................................`unused_traits`\nMacros.........................................`unused_macros`\n\n\nDuring the transition period, `dead_code` would be changed to act as a subcategory of `unused` that contains these lints and emit a deprecation warning.\n\n## Drawbacks\n\nMore lint names for everyone to remember, though this can be mostly negated by adding the name to warning.\n\nThere is no way at this time to silence a warning on an attribute, so it would be impossible to silence the deprecation warning without silencing all deprecation warnings in the context. Given that the codebase would be a legacy codebase, it is likely that it'd already make sense to silence deprecations or there is little concern in doing so. There would be no other solution for this in versions of Rust with this deprecation, as an individual version of Rust can't get an update, that'd be a different version of Rust.\n\n## Rationale and alternatives\n\nDeprecation rather than simply splitting `dead_code` and allowing people to choose between using the specific one or `dead_code` will ensure code readability by letting readers know what is `dead` and also reduces confusion for new rust users that expect it to include things like `unreachable_code` or `unused_assignments`.\n\nProvide a way of applying a lint to a block/item itself rather than the item and everything inside of it.\n\nThis would also be useful outside of this but doesn't address most of the other motivations.\n\nUse `unused_type` for type aliases, structs, enums and unions instead of `unused_type_alias` for the former and `unused_data_structure` for the latter 3.\n\n## Prior art\n\nI have not found anything notable in my research.\n\n## Unresolved questions\n\n  * What should the name of the lint for const and static variables be, given the currently proposed name is not very good? Or should they be separated instead?\n\n\n\n## Future possibilities\n\n  * Allow applying a lint to a block itself without applying to all statements/items in the block. applying a lint to a block itself without applying to all statements/items in the block.\n\n",
  "title": "Pre-RFC: Deprecation and separation of the dead_code lint"
}