Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[MSYS2] Allow default host triple to be overridden by an environment variable

Abierto
  • ¿Algo no está bien?
#5,024 21 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
devtools

Línea de trabajo

Empieza por rastrear cómo rustup resuelve las especificaciones de toolchain no cualificadas y cómo se carga el host predeterminado configurado. Revisa la discusión en busca de restricciones de diseño existentes y, a continuación, verifica que un host proporcionado por el entorno solo afecte a las especificaciones no cualificadas, mientras que los hosts explícitos y la selección del canal permanezcan sin cambios.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Problem you are trying to solve

MSYS2 on Windows provides multiple development environments which can share the same $HOME and therefore the same rustup configuration, but which require different Rust host ABIs. For example:

native Windows → x86_64-pc-windows-msvc
UCRT64         → x86_64-pc-windows-gnu
CLANG64        → x86_64-pc-windows-gnullvm

The appropriate host is therefore a property of the current development environment rather than of the user, machine, or project.

At the same time, a project may want to pin its Rust version without pinning its host ABI:

[toolchain]
channel = "1.97"

Ideally, the same project would then resolve that partial toolchain specification according to the active environment:

native Windows → 1.97-x86_64-pc-windows-msvc
UCRT64         → 1.97-x86_64-pc-windows-gnu
CLANG64        → 1.97-x86_64-pc-windows-gnullvm

Rustup already supports this distinction conceptually: an unqualified toolchain such as 1.97 is completed using rustup's default host. However, the default host is persisted in rustup's configuration, so environments sharing the same rustup home cannot have different defaults.

RUSTUP_TOOLCHAIN does not solve the problem because it selects the complete toolchain and overrides rust-toolchain.toml. Using it to select the ABI would therefore also override the project's choice of Rust version.

Separate RUSTUP_HOMEs can provide separate persisted default hosts, but that makes the host choice a property of separate rustup installations. For environments such as MSYS2, the host choice is naturally a property of the currently active shell environment, while the environments otherwise share the same home directory, projects, and installed tooling.

Solution you'd like

Add an environment variable, perhaps RUSTUP_DEFAULT_HOST, which overrides rustup's configured default host when resolving a toolchain specification that does not contain an explicit host.

For example:

export RUSTUP_DEFAULT_HOST=x86_64-pc-windows-gnullvm

combined with:

[toolchain]
channel = "1.97"

would resolve to:

1.97-x86_64-pc-windows-gnullvm

This would allow environments such as MSYS2 UCRT64 and CLANG64 to set their appropriate default host during environment initialization while continuing to share the same RUSTUP_HOME.

The environment variable would affect only resolution of the omitted host component. It would not select or override the channel/version as RUSTUP_TOOLCHAIN does.

Conceptually, host resolution could follow:

explicit host in toolchain specification
    ↓
RUSTUP_DEFAULT_HOST
    ↓
configured default_host_triple
    ↓
normal rustup host detection/defaulting

An explicitly host-qualified toolchain would therefore remain authoritative, while an unqualified toolchain could inherit its host ABI from the current execution environment.

Notes

No response

Lenguaje dominante
Rust
Estrellas
7.1k
Forks
1.1k
Merge medio
1 d 11 h
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rust-lang/rustup

Todos los issues de rust-lang/rustup

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.