rustup 1.29.3: actualiza el gestor sin cambiar tu toolchain
Guía práctica para actualizar rustup 1.29.3, separar self update de update y comprobar overrides y toolchains sin prometer compatibilidad universal.
4 de noviembre de 2026 · Leopoldo Benavente Cadena · 5 min de lectura
rustup administra instalaciones de Rust; no es rustc, no es Cargo y tampoco es una versión del lenguaje. Esa separación importa cuando aparece un error al iniciar el gestor o cuando un runner tiene una toolchain distinta de la estación de desarrollo.
El equipo de Rust publicó rustup 1.29.3 el 3 de noviembre de 2026 como una actualización de corrección. La nota oficial enumera dos regresiones de la versión anterior: una instrucción ilegal en algunos procesadores x86_64 que no disponen de SSE4.1 y el error lock() not supported en Solaris. No es una release de rustc, no cambia el lenguaje y no es un parche de seguridad/CVE.
Self update no es update
Para actualizar solo el gestor, el comando normal es:
rustup self updateLa documentación de rustup indica que este comando solicita la versión más reciente de rustup y no descarga nuevas toolchains. Es la opción acotada para corregir el binario gestor sin convertir la operación en una actualización de stable, beta o nightly.
En cambio:
rustup updatesin argumentos trata las toolchains instaladas y sus componentes. En una configuración normal también comprueba la autoactualización de rustup al final. Por eso no uses rustup update como sustituto silencioso de self update: puede cambiar rustc, Cargo, la biblioteca estándar o componentes de un canal que el proyecto necesita conservar.
La propia nota de 1.29.3 recomienda cerrar IDEs y programas que estén usando rustup antes de ejecutar self update. En un runner, hazlo en una imagen o paso controlado y registra la versión antes y después.
Inventario mínimo
Ejecuta el inventario dentro del mismo repositorio, contenedor o runner que quieres diagnosticar:
rustup --version
rustup show active-toolchain
rustc -Vv
cargo -VCada salida responde una pregunta distinta:
| Comando | Qué identifica |
|---|---|
rustup --version |
El gestor y su versión propia |
rustup show active-toolchain |
La toolchain elegida para ese directorio/entorno |
rustc -Vv |
El compilador activo, host, commit y versión LLVM |
cargo -V |
Cargo asociado a la toolchain en uso |
Guarda también el origen de la instalación: rustup-init, gestor de paquetes, imagen base o distribución de terceros. Un número correcto en el portátil no demuestra que el runner use el mismo binario.
Una comprobación reproducible y prudente es capturar el inventario, ejecutar rustup self update en una estación de prueba y capturarlo de nuevo:
rustup --version
rustup show active-toolchain
rustup self update
rustup --version
rustup show active-toolchain
rustc -Vv
cargo -VEl criterio es que el gestor reporte 1.29.3 y que la toolchain activa siga siendo la esperada. No atribuyas a esta secuencia una mejora de rendimiento ni una reproducción del fallo de Solaris o de una CPU sin SSE4.1 si no dispones de esos entornos. Después ejecuta las pruebas normales del proyecto; el resultado pertenece a tu código, no a la nota de lanzamiento.
Overrides que pueden sorprender
Actualizar rustup no elimina la selección de toolchain del proyecto. rustup resuelve la toolchain con una precedencia que incluye el shorthand de comando (cargo +beta), RUSTUP_TOOLCHAIN, un override de directorio, rust-toolchain.toml/rust-toolchain y, al final, la toolchain predeterminada.
Desde la raíz del repositorio, revisa:
rustup showSi existe rust-toolchain.toml, su channel, profile, components y targets forman parte del contrato del proyecto. Un archivo rust-toolchain antiguo puede contener solo el nombre del canal. Un override configurado con rustup override set también se aplica al directorio y sus descendientes. No cambies esos archivos ni ejecutes rustup override set como parte de la corrección del gestor sin una decisión del proyecto.
La toolchain puede ser stable, una versión concreta, una nightly fechada o una ruta local. Por eso “rustup se actualizó” y “el proyecto ahora compila con otra versión” son afirmaciones distintas que deben comprobarse por separado.
Instalaciones de terceros y excepciones
La autoactualización no está disponible si rustup fue compilado con la característica no-self-update; la documentación también menciona distribuidores que la deshabilitan. En ese caso, rustup self update puede no ser la vía apropiada. Identifica primero quién suministra el binario y sigue su mecanismo de actualización, dejando un respaldo y un rollback verificables.
La nota 1.29.3 describe como posibilidad que un escáner antimalware bloquee rustup o la creación de muchos archivos de rust-docs. No desactives el antivirus por una actualización: conserva el diagnóstico, revisa la política del equipo y coordina una excepción solo si el responsable de seguridad la autoriza. Si el gestor no puede iniciar, no reemplaces binarios con una ruta genérica copiada de otro sistema; la entrada oficial contempla el uso del rustup-init correspondiente a la plataforma, pero la procedencia, arquitectura y rollback deben quedar comprobados.
Cerrar el cambio en CI
Repite el inventario en cada imagen o runner relevante. Fija el canal mediante el archivo del proyecto cuando necesites reproducibilidad, registra la versión de rustup separadamente y ejecuta la compilación o las pruebas del repositorio después de la actualización. No asumas que un contenedor heredará el RUSTUP_TOOLCHAIN de tu estación ni que una instalación de distribución soportará el mismo flujo de autoactualización.
El mantenimiento queda bien delimitado cuando puedes responder cuatro preguntas: ¿qué rustup corre?, ¿qué toolchain está activa?, ¿qué rustc y Cargo se ejecutan?, y ¿quién suministra el binario? rustup 1.29.3 corrige dos regresiones concretas; decidir cuándo actualizar toolchains, componentes o overrides sigue siendo responsabilidad del proyecto.
Comentarios