Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support virtual toolchains to "mix and match" components

Aperta
#4,636 2 commenti 4 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
tooling

Direzione di ricerca

Nell’issue non sono indicati file né test. Inizia esaminando il comportamento esistente di rustup per linked-toolchain e toolchain-override, quindi definisci l’ambito della configurazione, la denominazione, gli avvisi di compatibilità e le restrizioni di installazione per le toolchain virtuali. Il lavoro è completato quando esistono un design definito e un percorso di implementazione per combinare componenti diagnosticando al contempo le combinazioni incompatibili.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Motivation

There has been repeated requests about overriding specific components of a toolchain while keeping others intact:

(Or maybe we just don't have to be so strict about what "required" means and just allow people to mix and match components in ways that break).
@brson in https://github.com/rust-lang/rustup/issues/298#issuecomment-209596694

I'd like to install https://xous.xobs.io/dist/rust-std-1.91.0-riscv32imac-unknown-xous-elf.tar.gz or https://xous.xobs.io/dist/rust-std-1.91.0-riscv32imac-unknown-xous-elf.tar.xz with rustup.
@xobs in https://github.com/rust-lang/rustup/issues/4635#issuecomment-3631347115

My team prefers cargo +nightly fmt for formatting over stable.
@sajjon in https://github.com/rust-lang/rustup/issues/4391

one wants to use nightly features from rustfmt, while also keeping a stable version for builds + deploys
@CinchBlue in #3546

I think using nightly rustfmt together with stable rust is perfectly valid, so i was thinking about something along the lines of

[toolchain]
channel = "stable" # this is essentially the default toolchain

# channel for this component isn't specified, will use stable
[[toolchain.components]]
name = "clippy"

# channel is nightly, so nightly rust will be used for this component
[[toolchain.components]]
name = "rustfmt"
channel = "nightly"

@ghost in https://github.com/rust-lang/rustup/issues/3546#issuecomment-1879902334

Feasibility

This shouldn't be technically difficult to add in rustup, and @lynzrand has implemented exactly that in https://github.com/lynzrand/lunik, allowing the existence of overrides like the following (in a user-wide config):

{
  "toolchain": {
    "stable": {},
    "dev": {
      "fallback": "stable",
      "override": {
        "moon": "/home/rynco/.cargo/bin/moon"
      }
    }
  },
  ...
}

Also, as very well demonstrated in the above example, a special name must be assigned to the new virtual toolchain, which must not be confounded with its parents.

Challenges

  • One issue that I've had using lunik is that sometimes components from another toolchain might have compatibility issues with the current toolchain. To mitigate this situation, we have to at least properly inform the relevant users of this fact and help them diagnose issues related to this usage.

  • Another issue would be determining the scope of this new configuration option. Should this be project-wide, user-wide, or a full-fledged layered configuration system is required like with toolchain overrides? If a fully-layered implementation is required, wouldn't that cause problems regarding toolchain name shadowing?

  • Some operations are simply banned from virtual toolchains, such as the additional installation of components. Fortunately, this is the same for linked toolchains (e.g. system) so we should be able to handle the current case similarly.

  • Should we just forward the binaries while keeping little traces of this virtual toolchain on disk, or should we do links to existing toolchains to provide better flexibility beyond the binary invocations? For example, #4635 wants to inject support libraries into the toolchain installation.

Lingua principale
Rust
Stelle
7.1k
Fork
1.1k
Merge medio
1g 6h
PR unite (30g)
45

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rust-lang/rustup

Tutte le issue di rust-lang/rustup

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.