Rust 1.100 cierra diez años de espera con el tipo never y frena los crates recién publicados

Diez años y cinco intentos fallidos después, el tipo never (!) es estable. Rust 1.100, publicado el 12 de noviembre de 2026, lo estabiliza junto con el núcleo de la API de asignadores, y Cargo estrena dos cambios que se notan en el día a día: avisa de dependencias que no usas y puede negarse a resolver versiones de crates publicadas hace menos de un plazo que tú eliges.

01El tipo never, por fin en cualquier posición

! es el tipo de lo que nunca devuelve un valor: return, break, std::process::exit. Hasta ahora solo podía escribirse como tipo de retorno (-> !). Desde 1.100 se puede nombrar en cualquier sitio, y eso hace legibles los tipos que no pueden fallar:

fn infallible_unwrap<T>(res: Result<T, !>) -> T {
    let Ok(v) = res;
    v
}

Además, Infallible pasa a ser un alias de !, así que las APIs que lo usaban son compatibles sin tocarlas.

Aquí está el único cambio incompatible de la versión: el fallback del tipo never pasa de () a ! también en las ediciones 2015, 2018 y 2021 (la 2024 ya lo tenía). El equipo de Rust espera que pase desapercibido, pero puede romper código en casos raros, como cuando se ignora el resultado de una función que devuelve un parámetro genérico, y el compilador puede marcar más código como inalcanzable. Si una dependencia deja de compilar por esto, lo primero es actualizarla: los crates públicos afectados ya recibieron parches.

02Asignadores propios y DropGuard

La otra estabilización grande es la parte central de allocator_api: el trait Allocator, Global, System y los constructores Vec::new_in, Box::new_in y compañía. De momento solo Vec y Box aceptan un asignador propio; el resto de colecciones llegará más adelante. Es la pieza que esperaban quienes usan arenas o asignadores por petición sin pasar a nightly.

Para el código de aplicación, lo más útil es core::mem::DropGuard: envuelve un valor y ejecuta un cierre al salir del ámbito, por cualquier camino (return, ? o pánico), salvo que lo desactives con dismiss. Encaja con operaciones de todo o nada:

use std::mem::DropGuard;
use std::num::ParseIntError;

fn parse_all(nums: &mut Vec<u32>, strings: &[&str]) -> Result<(), ParseIntError> {
    let len = nums.len();
    let mut nums = DropGuard::new(nums, move |nums| nums.truncate(len));
    for s in strings {
        nums.push(s.parse()?); // an error rolls the Vec back
    }
    DropGuard::dismiss(nums);
    Ok(())
}

Completan la lista std::mem::conjure_zst, la forma oficial (y unsafe) de crear tipos de tamaño cero, y utilidades pequeñas como bool::toggle, Vec::from_fn, str::trim_prefix y str::trim_suffix.

03Cargo: plazo mínimo para versiones nuevas

Las versiones maliciosas de un paquete suelen detectarse en horas o días. Con min-publish-age, Cargo puede esperar ese margen antes de resolverlas. Se activa en .cargo/config.toml:

[registry]
global-min-publish-age = "3 days"

Con eso, cargo update se salta las versiones más recientes que el plazo y dice qué ha dejado fuera. Si necesitas un parche urgente, puedes forzar una actualización concreta:

CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9

Hay dos límites que importan. cargo install ignora el plazo, tanto para el crate como para sus dependencias, así que ahí fija la versión (cargo install [email protected]). Y las versiones sin fecha de publicación en el índice nunca se retienen.

pnpm aplica la misma idea con minimumReleaseAge, pero con otra decisión de diseño: allí viene activado por defecto con un día de espera (1.440 minutos) y se aplica a todas las dependencias, también las transitivas. En Cargo es opcional; si quieres la misma protección, tienes que pedirla.

04Cargo: dependencias sin usar y un build-dir reorganizado

Cargo avisa ahora de dependencias declaradas que no usa ningún objetivo (cargo::unused_dependencies, en warn por defecto). Solo aparece cuando compilas todos los objetivos que podrían usarlas, así que cargo check --bin foo no lo mostrará, y nunca salta con las dev-dependencies.

El cambio con más riesgo para CI es interno: el build-dir se organiza ahora por paso de compilación y el hash de configuración pasa del nombre del fichero al directorio padre. Arregla recompilaciones de más o de menos al cambiar de --features o al compartir el directorio entre worktrees, pero puede romper scripts y tests que dependían de las rutas antiguas. La discusión y las soluciones están en cargo#17287.

05Cómo actualizar

Con rustup:

rustup update stable
rustc --version   # rustc 1.100.0

06Antes de llevarlo a producción

• Compila y pasa los tests con las ediciones 2015–2021 buscando errores nuevos de inferencia o código inalcanzable; si falla una dependencia, actualízala antes de investigar.
• Revisa los scripts de CI que leen artefactos dentro de target/ por ruta: el build-dir ha cambiado de estructura.
• Compila todos los objetivos (cargo build --all-targets) y limpia las dependencias que Cargo marque como sin usar.
• Decide un plazo para global-min-publish-age y cómo vas a saltártelo cuando llegue un parche de seguridad.

07Fuentes

• Announcing Rust 1.100.0, The Rust Release Team, 12 de noviembre de 2026.
• Settings: dependency resolution, minimumReleaseAge, documentación de pnpm.