Rust 1.100: memoria propia y control en Cargo

Rust 1.100.0: asignadores de memoria propios y control de dependencias en Cargo

La versión 1.100.0 de Rust ya está disponible y trae tres cambios que llevaban años en la lista de deseos de la comunidad: la estabilización de los asignadores de memoria personalizados, un sistema de lints propio para Cargo y una configuración para que el gestor de paquetes ignore versiones de dependencias publicadas demasiado recientemente. Para un equipo que mantiene servicios en producción con este lenguaje, la actualización toca tres frentes a la vez: control de memoria, higiene de dependencias y compatibilidad de código existente.

¿Qué se estabiliza en el lenguaje y la biblioteca estándar?

El cambio de mayor alcance es la estabilización de los asignadores personalizados: ahora es posible definir cómo pide y libera memoria el código, en lugar de depender únicamente del asignador global. Para proyectos que trabajan sin la biblioteca estándar completa, para firmware y sistemas embebidos, y para motores de videojuegos o servicios con patrones de memoria muy específicos, esto habilita estrategias de asignación propias sin salir del terreno seguro del lenguaje.

La biblioteca estándar suma además dos ajustes de calidad:

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

ENOTSUP ahora se mapea a ErrorKind::Unsupported, lo que hace más predecible el manejo de errores entre sistemas operativos.
Se corrigieron problemas de solidez (soundness) en std::sys::pal::sgx::waitqueue::unsafe_list, el tipo de fallo más difícil de diagnosticar cuando aparece en producción.

¿Por qué el enfriamiento de dependencias es la novedad más relevante para tu equipo?

Cargo estrena configuraciones de edad mínima de publicación, también conocidas como dependency cooldowns. Cuando se activa esta opción, el resolutor ignora las versiones publicadas más recientemente que el umbral definido, salvo que ya estén fijadas en Cargo.lock. La función llega a través de la propuesta RFC 3923.

El valor de esto es directo: el escenario de una versión maliciosa publicada en un paquete popular y adoptada en minutos por miles de proyectos deja de ser automático. Con un umbral configurado, tu pipeline espera antes de incorporar lo último publicado, y una versión comprometida tiene tiempo de ser detectada y retirada antes de llegar a tu build.

Es, además, una mitigación que no exige cambiar código de producto: se resuelve con configuración y afecta el comportamiento del resolutor de dependencias.

Cargo estrena su propio sistema de lints y detecta dependencias sin usar

La otra novedad de peso es que Cargo incorpora su propio sistema de lints. Algunas advertencias que antes no se podían silenciar de forma granular ahora se emiten como lints que se controlan desde la tabla [lints.cargo].

Dentro de ese sistema llega un chequeo integrado de dependencias sin usar a través del lint cargo::unused_dependencies. Para equipos que arrastran un Cargo.toml con años de historia, es una auditoría gratuita: cada dependencia declarada y no utilizada es superficie de ataque y tiempo de compilación que se puede eliminar.

¿Qué cambia en cargo install y en el directorio de compilación?

Dos cambios operativos que conviene conocer antes de actualizar:

cargo install ahora usa por defecto el lockfile que ya viene dentro del tarball .crate, y la bandera --locked pasa a ser un no-op. El resultado es más reproducibilidad con menos configuración: la instalación respeta las versiones exactas que el autor del paquete fijó.
Cargo estrena un nuevo layout de directorios para artefactos intermedios de compilación. Si tu equipo tiene scripts, imágenes de CI o herramientas internas que inspeccionan la carpeta de build esperando una estructura determinada, pueden romperse. La documentación recomienda usar los mensajes JSON de Cargo para localizar artefactos en lugar de asumir el layout, que no es una interfaz estable.

¿Qué cambia en plataformas y soporte de objetivos?

La versión mueve piezas en la matriz de soporte:

i686-pc-windows-gnu pasa a ser un objetivo de nivel 2 sin herramientas de host.
wasm32-wasip3 se promueve a nivel 2, una señal relevante si tu producto corre sobre WebAssembly.
Se agrega el objetivo de nivel 3 powerpc64-sony-ps3.
La biblioteca estándar usa ahora Unicode 18.0.0 y el SDK de WASI, la interfaz de sistema de WebAssembly, subió de la versión 33 a la 34.

En el frente de arquitecturas hay un detalle con consecuencias reales: entre las versiones 1.94 y 1.100, varios objetivos ARMv7-A hardfloat exigían como mínimo la FPU VFPv3-D32, porque tenían la característica d32 incluida por error en su lista base de características. La corrección de ese error puede romper builds, y el arreglo es pasar -Ctarget-feature=+d32 al compilador. Además, los valores de -Ctarget-feature y -Ctarget-cpu que alterarían el ABI en objetivos ARM ahora se rechazan como errores duros, y habilitar SSE o AVX en un objetivo x86 softfloat también genera error.

¿Qué se rompe y cómo migrar sin sustos?

Ninguna versión con este volumen de cambios es inocua. Los puntos de compatibilidad que más probabilidades tienen de aparecer en un proyecto real:

Los closures capturan con más precisión las variables usadas en un if let, lo que puede generar errores nuevos en código que antes compilaba.
Infallible ahora es un alias de tipo a ! y el fallback del tipo never cambió a ! en todas las ediciones.
Los box patterns ya no son válidos sintácticamente.
Algunas implementaciones de Box se generalizaron a asignadores arbitrarios, lo que puede producir nuevos errores de inferencia de tipos.
La compatibilidad de objetos de trait (dyn-compatibility) se verifica en más lugares, y Iterator::{min, max}(_by_key) cambiaron los métodos de Ord que utilizan.

¿Qué significa esto para tu startup?

Si tu producto corre sobre Rust, esta actualización es de las que conviene planificar y no dejar al azar de un rustup update en viernes.

Actualiza en una rama y compila todo el workspace con cargo clippy. El nuevo lint de dependencias sin usar te entrega, gratis, un inventario de paquetes que puedes eliminar. Menos dependencias es menos superficie de ataque y builds más rápidos.
Configura una edad mínima de publicación de dependencias en tu CI. Es la mitigación más barata contra una versión maliciosa recién publicada, y no requiere tocar una línea de código de producto.
Si tu equipo trabaja en embebidos, sin biblioteca estándar completa o con problemas de fragmentación de memoria, evalúa los asignadores personalizados. Es la funcionalidad que puede justificar la migración por sí sola.
Antes de actualizar, revisa si algo en tu pipeline lee el directorio de build. Si lo hace, migra a los mensajes JSON de Cargo en la misma ventana de mantenimiento.
Si compilas para ARMv7-A hardfloat, prueba el flag -Ctarget-feature=+d32 antes de dar por rota la actualización.

Conclusión

Rust 1.100.0 no es una versión de titulares vistosos, pero sí de las que cambian cómo se opera un proyecto: memoria bajo control explícito, dependencias con freno de mano y un Cargo que empieza a auditar el propio Cargo.toml. Para un equipo chico, el beneficio inmediato está en el control de dependencias y en el lint de paquetes sin usar: menos código de terceros en tu build y menos exposición al momento más peligroso de cualquier dependencia, que son sus primeras horas tras publicarse.