Pre-RFC: Deprecation and separation of the dead_code lint

• Feature Name: dead-code-lint-deprecation
• Start Date: 2/28/2026
• RFC PR: rust-lang/rfcs#0000
• Rust Issue: rust-lang/rust#0000

Summary

Deprecate the dead_code lint and give each item linted by dead_code its own item-specific unused lint.

Motivation

In 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.

For 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.

The 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.

There 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.

Guide-level explanation

For 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. (The dead code lint docs would be updated to have a table with each thing covered and what now covers that).

For 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. (There'd be nothing to distinguish between unused lints currently under dead_code and ones not under it).

Reference-level explanation

The proposed list of items linted and the lint:

Modules......................................unused_module Functions....................................unused_functions Type Aliases...............................unused_type_alias Structs, Enums, Unions..........unused_data_structures Consts/Statics............................unused_compile_time_var Traits..............................................unused_traits Macros.........................................unused_macros

During the transition period, dead_code would be changed to act as a subcategory of unused that contains these lints and emit a deprecation warning.

Drawbacks

More lint names for everyone to remember, though this can be mostly negated by adding the name to warning.

There 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.

Rationale and alternatives

Deprecation 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.

Provide a way of applying a lint to a block/item itself rather than the item and everything inside of it.

This would also be useful outside of this but doesn't address most of the other motivations.

Use 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.

Prior art

I have not found anything notable in my research.

Unresolved questions

• 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?

Future possibilities

• 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.