External Publication
Visit Post

Pre-RFC: Deprecation and separation of the dead_code lint

Rust Internals [Unofficial] March 4, 2026
Source

To me, the dead_code lint mostly does identify an interesting category, even if its name is odd. It’s the lint that tells you not just that you have superfluous things, but superfluous things you purposefully designed as meaningful API — not just unused lines of code, but unused function signatures. Unused imports are not interesting because you delete them and then if you need them, you just put them back; and unreachable code is most likely a simple logic bug or work in progress; but dead_code tells you something more big-picture about your application.

It wouldn’t necessarily be a good idea to fold unreachable_code into dead_code, for example, because allowing dead_code is something one might do, for example, when developing and testing functions before they're exported or used publicly in any way; in this situation, unreachable_code is still helping you see logic bugs.

Another nuance of the situation is that dead_code acts transitively (it reports all items not reachable even if they are mentioned by other unreachable items, and allowing it allows all the dependencies of the item it’s allowed for), and if (as the OP proposed) it were broken up into unused_functions and unused_compile_time_var, since both of those things can use each other, it would be less clear how the transitivity should work.

Discussion in the ATmosphere

Loading comments...