Comment désactiver les avertissements de code mort dans Rust au niveau de la crate : guide 2025

Code mort dans Rust : quand le compilateur est votre professeur strict

Chaque développeur Rust rencontre tôt ou tard ce moment : vous écrivez du code, tout est logique, mais le compilateur affiche soudainement des dizaines d'avertissements jaunes warning: dead code. C'est comme si un professeur vérifiait votre devoir et soulignait chaque variable inutilisée. D'un côté, c'est utile, de l'autre, c'est parfois agaçant.

Imaginez : vous travaillez sur un grand projet où certaines fonctions sont réservées pour de futures fonctionnalités, ou vous expérimentez avec une nouvelle API. Dans Rust, les avertissements de code mort sont-ils activés par défaut au niveau #![deny(dead_code)] ? Non, mais le compilateur est très insistant. La question qui hante des milliers de développeurs sur Stack Overflow : comment désactiver ces avertissements au niveau de toute la crate ?

Dans cet article, nous allons analyser les meilleures pratiques de 2025 : de la simple désactivation au réglage fin avec des attributs, des macros et des outils comme Clippy. C'est parti !

Pourquoi Rust est-il si strict avec le code mort ?

Rust a été créé comme un langage de programmation système où la performance et la sécurité sont importantes. Le code mort n'est pas simplement un défaut stylistique. Ce sont des erreurs potentielles, des dépendances inutiles et une augmentation du temps de compilation. Le compilateur active par défaut le lint dead_code pour que vous n'oubliiez pas de supprimer les parties inutiles.

Mais dans la vie réelle, il arrive que :

\n
• Vous écriviez une bibliothèque et que certaines fonctions publiques ne soient pas encore utilisées dans les exemples.
\n
• Vous développiez un prototype et ne vouliez pas être distrait par les avertissements.
\n
• Vous ayez des configurations pour différentes plateformes (cfg) et que le code pour d'autres architectures reste inutilisé.
\n

Ignorer les avertissements de code mort est possible, mais il est préférable de contrôler le processus. Voyons comment faire correctement.

Méthode standard : l'attribut #[allow(dead_code)]

La méthode la plus simple et la plus populaire consiste à ajouter un attribut au niveau de la crate. Pour cela, au tout début du fichier lib.rs ou main.rs, on écrit :

// lib.rs\n#![allow(dead_code)]\n\npub fn unused_function() {\n    println!("Je ne suis jamais appelée, mais le compilateur se tait !");\n}\n\nfn main() {\n    println!("Hello, world!");\n}

L'attribut #![allow(dead_code)] (notez le point d'exclamation — c'est un attribut interne, appliqué au module courant) désactive les avertissements pour toute la crate. Mais est-ce adapté à la production ? Pas toujours.

Inconvénients :

\n
• Vous désactivez la vérification pour tout la crate, y compris le code que vous avez écrit par hasard et oublié de supprimer.
\n
• Dans les grands projets, cela masque de vrais problèmes.
\n

Avantages :

\n
• Solution rapide pour les prototypes.
\n
• Adapté aux projets d'apprentissage.
\n

Désactivation ciblée : attributs sur les fonctions

La meilleure pratique n'est pas de tout désactiver globalement, mais de marquer des zones spécifiques. Rust permet de placer #[allow(dead_code)] directement au-dessus d'une fonction, d'une structure ou d'un module :

#[allow(dead_code)]\nfn helper_function() {\n    // Cette fonction n'est pas encore utilisée, mais nous la conservons pour un futur refactoring\n}\n\nstruct MyStruct {\n    #[allow(dead_code)]\n    field1: u32, // Le champ n'est pas utilisé, mais pourrait être nécessaire\n    field2: u32,\n}

Cette approche est considérée comme une best practice en 2025 : vous dites explicitement au compilateur et aux autres développeurs : « Je sais que ce code est mort, mais j'en ai besoin ». Transparence et contrôle — voilà ce qui est valorisé dans la communauté Rust.

Attributs au niveau du module

Si vous avez un module entier avec du code expérimental, vous pouvez désactiver les avertissements pour celui-ci sans toucher au reste de la crate :