Como desativar avisos de código morto em Rust no nível do crate: guia 2025

Código morto em Rust: quando o compilador é seu professor rigoroso

Todo desenvolvedor Rust, mais cedo ou mais tarde, se depara com este momento: você escreve código, tudo parece lógico, mas o compilador de repente exibe dezenas de avisos amarelos warning: dead code. É como se um professor estivesse corrigindo seu dever de casa e sublinhando cada variável não utilizada. Por um lado, é útil; por outro, às vezes irrita.

Imagine: você está trabalhando em um grande projeto, onde parte das funções está reservada para funcionalidades futuras, ou está experimentando uma nova API. Em Rust, os avisos de código morto são ativados por padrão no nível #![deny(dead_code)]? Não, mas o compilador é muito insistente. A pergunta que atormenta milhares de desenvolvedores no Stack Overflow: como desativar esses avisos no nível de todo o crate?

Neste artigo, vamos abordar as melhores práticas de 2025: desde a desativação simples até a configuração refinada usando atributos, macros e ferramentas como o Clippy. Vamos nessa!

Por que o Rust é tão rigoroso com código morto?

Rust foi criado como uma linguagem para programação de sistemas, onde desempenho e segurança são importantes. Código morto não é apenas um defeito estilístico. São potenciais erros, dependências desnecessárias e aumento do tempo de compilação. O compilador ativa por padrão o lint dead_code para que você não se esqueça de remover partes desnecessárias.

Mas na vida real, acontece o seguinte:

\n
• Você está escrevendo uma biblioteca, e parte das funções públicas ainda não é usada nos exemplos.
\n
• Você está desenvolvendo um protótipo e não quer se distrair com avisos.
\n
• Você tem configurações para diferentes plataformas (cfg), e o código para outras arquiteturas fica apenas como peso morto.
\n

Ignorar os avisos de código morto é possível, mas é melhor controlar o processo. Vamos ver como fazer isso corretamente.

Método padrão: o atributo #[allow(dead_code)]

O método mais simples e popular é adicionar o atributo no nível do crate. Para isso, no início do arquivo lib.rs ou main.rs, escrevemos:

// lib.rs\n#![allow(dead_code)]\n\npub fn unused_function() {\n    println!("Não sou chamado em lugar nenhum, mas o compilador fica em silêncio!");\n}\n\nfn main() {\n    println!("Hello, world!");\n}

O atributo #![allow(dead_code)] (observe o ponto de exclamação — é um atributo interno, aplicado ao módulo atual) desativa os avisos para todo o crate. Mas isso é adequado para produção? Nem sempre.

Desvantagens:

\n
• Você desativa a verificação para todo o crate, incluindo código que você escreveu acidentalmente e esqueceu de remover.
\n
• Em projetos grandes, isso mascara problemas reais.
\n

Vantagens:

\n
• Solução rápida para protótipos.
\n
• Adequado para projetos de estudo.
\n

Desativação pontual: atributos em funções

A melhor prática é não desativar tudo globalmente, mas marcar partes específicas. Rust permite colocar #[allow(dead_code)] diretamente sobre uma função, estrutura ou módulo:

#[allow(dead_code)]\nfn helper_function() {\n    // Esta função ainda não é usada, mas a mantemos para uma futura refatoração\n}\n\nstruct MyStruct {\n    #[allow(dead_code)]\n    field1: u32, // O campo não é usado, mas pode ser necessário\n    field2: u32,\n}

Esta abordagem é considerada best practice em 2025: você diz explicitamente ao compilador e a outros desenvolvedores: "Eu sei que este código está morto, mas preciso dele". Transparência e controle — é isso que é valorizado na comunidade Rust.

Atributos no nível do módulo

Se você tem um módulo inteiro com código experimental, pode desativar os avisos para ele, sem afetar o resto do crate: