Rust 1.100 traz o tipo never, alocadores e lints do Cargo

O projeto Rust lançou o Rust 1.100.0 em 12 de novembro de 2026. A versão torna o tipo never estável, abre o núcleo da API de alocadores personalizados e ensina o Cargo a avisar sobre dependências não usadas. A mudança no tipo never também quebra a compatibilidade, e as notas da versão a listam em "Compatibility Notes". Projetos em qualquer edição podem agora falhar ao compilar onde antes compilavam.

O anúncio no Rust Blog diz que o tipo never levou 10 anos e 5 tentativas fracassadas para chegar ao estável. O LWN.net destacou as mesmas três mudanças: o tipo never, o núcleo da Allocator API e o relatório do Cargo sobre dependências não usadas. Quem usa Rust atualiza com rustup update stable.

O que há de novo no Rust 1.100

O tipo never, escrito !, é o tipo de um código que nunca termina, como um panic! ou um loop infinito. Até agora, ele só podia aparecer como tipo de retorno de uma função. Nosso guia sobre o tipo never do Rust explica tudo em detalhe, e nossa matéria de agosto cobriu o pull request que o tornou estável.

A tabela abaixo foi montada a partir do post do blog, das notas da versão no GitHub e do changelog do Cargo.

Mudança	O que faz	Quem percebe
Tipo never !	Pode ser usado em qualquer lugar, como em Result<T, !>; Infallible vira um alias de !	Código que dependia do antigo fallback
Fallback de tipo	Um tipo desconhecido num ramo divergente agora vira !, não (), em todas as edições	Crates antigos que nunca migraram para a edição 2024
Allocator API	Allocator, Global, System, além de Vec::new_in, Box::new_in e métodos parecidos	Código que gerencia a própria memória
cargo::unused_dependencies	Avisa quando uma dependência no Cargo.toml nunca é usada	Todo projeto Cargo
Idade mínima de publicação	O Cargo pode pular versões de crates mais novas que uma idade definida	Equipes preocupadas com ataques à cadeia de suprimentos
Estrutura do diretório de build	Os arquivos intermediários de build mudam de lugar	Scripts que leem diretamente a pasta target do Cargo
i686-pc-windows-gnu	Agora é Tier 2 sem ferramentas de host	Usuários do Windows de 32 bits

A mudança para o Windows de 32 bits foi anunciada em outubro, como explica nossa matéria sobre os targets i686. A versão também estabiliza utilitários menores, como bool::toggle, Vec::from_fn e str::trim_prefix.

Teste do Tech AI Wire: Rust 1.99.1 contra 1.100.0

Num teste do Tech AI Wire no macOS 26.6.2, os mesmos projetos pequenos rodaram nas imagens Docker oficiais rust:1.99-slim e rust:1.100-slim. As duas são Debian 13 em arm64. As imagens informaram rustc 1.99.1 e rustc 1.100.0.

O primeiro projeto usava a edição 2021 e este código:

fn make<T: Default>() -> Result<T, ()> {
    Ok(T::default())
}

fn main() -> Result<(), ()> {
    make()?;
    Ok(())
}

Nada diz ao compilador o que é T, então ele recorre a um tipo padrão. Veja o que cada versão fez:

Código	Rust 1.99.1	Rust 1.100.0
Como escrito	Erro do lint dependency_on_unit_never_type_fallback	Erro E0277: "the trait bound !: Default is not satisfied" (o limite de trait !: Default não é satisfeito)
Com #![allow(dependency_on_unit_never_type_fallback)]	Compila e roda	Ainda o erro E0277; o lint "has been removed" (foi removido)
Com make::<()>()?	Compila e roda	Compila e roda

A linha do meio é a armadilha. Um crate que silenciava o aviso no 1.99 compila ali e depois falha no 1.100. O Rust 1.100 diz que o lint foi removido porque "the code warned by this lint no longer compiles" (o código apontado por este lint não compila mais). Só nomear o tipo resolve.

O teste do alocador personalizado envolvia o alocador global para contar as requisições. No 1.99.1, falhou com o erro E0658, "use of unstable library feature allocator_api". No 1.100.0, rodou no stable. Um Vec de 1.000 números mais um Box fizeram 10 chamadas de alocação, somando 16.356 bytes.

Teste do Tech AI Wire: as duas novas verificações de segurança do Cargo

Um crate (um pacote Rust) listava itoa e memchr como dependências, mas usava só itoa. No 1.100, cargo build exibiu "warning: unused dependency memchr". Definir unused_dependencies = "deny" em [lints.cargo] transformou isso num erro, e o build parou. Uma dev-dependency que nunca foi usada não recebeu aviso. Nem cargo check --bin unused, que verifica um único target. Os dois casos batem com isenções que o post do blog lista. O Rust 1.99.1 ignorou a tabela [lints.cargo] com um aviso "unused manifest key".

A idade mínima de publicação atrasa versões de crates recém-publicadas, o que o post do blog chama de "dependency cooldowns". A espera dá tempo para outras pessoas detectarem uma versão ruim antes que o seu build a puxe. Com global-min-publish-age = "3 days" em [registry], o Cargo travou o cc na 1.11.1. Ele exibiu "available: v1.11.2, published 2 hours ago". Sem a configuração, o Cargo escolheu a 1.11.2. Com 30 dias, a resolução falhou, porque o cargo add já tinha gravado 1.11.1 como versão mínima. O Cargo sugeriu baixar o requisito para "1.8.0" ou definir CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow.

O que isso significa para desenvolvedores

• Compile cada crate no 1.100 antes de atualizar a CI. Código de edições mais antigas é o mais propenso a quebrar. Procure por allow(dependency_on_unit_never_type_fallback), porque esse código falha no 1.100.
• Corrija erros de fallback nomeando o tipo. A própria sugestão do compilador, como make::<()>(), funcionou nas duas versões no teste.
• Ative a idade mínima de publicação agora. Três dias de global-min-publish-age no .cargo/config.toml custam pouco. Defina-a antes de rodar cargo add, já que esse comando grava no Cargo.toml a versão que escolhe.
• Limpe as dependências não usadas antes de proibi-las. Comece no padrão warn, remova o que ele encontrar e depois mude para deny na CI.
• Leia as Compatibility Notes. Elas também listam a remoção de padrões box, o Unicode 18.0.0 e verificações mais rígidas de target features do ARM.
• Pare de ler diretamente as pastas de build do Cargo. A estrutura delas mudou no 1.100, e o changelog do Cargo diz que as ferramentas devem usar as mensagens JSON do Cargo em vez disso.