Fails to add component on Windows

[lnicola]

We're also seeing some breakage for rustup component add --toolchain nightly rustfmt, but only on Windows:

error: invalid value 'C:\Users\runneradmin\.cargo\bin\rustup.exe' for '[+toolchain]': error: "C:\Users\runneradmin\.cargo\bin\rustup.exe" is not a valid subcommand, so it was interpreted as a toolchain name, but it is also invalid. To override the toolchain using the 'rustup +toolchain' syntax, make sure to prefix the toolchain override with a '+'

It's similar, but not the same as marmeladema's error from above.

EDIT: this fixed it:

-          rustup toolchain add nightly --profile minimal
-          rustup component add --toolchain nightly rustfmt
+          rustup toolchain install nightly --profile minimal --component rustfmt

Originally posted by @lnicola in #4220

[lnicola]

@djc humbly nominating this for 1.28.2.

[djc]

@djc humbly nominating this for 1.28.2.

Added it to the list! No guarantee about making it in, of course...

[ChrisDenton]

I'm struggling to repo this locally on 1.28.1. Might be something about CI that I'm not replicating?

The full CI script seems to be:

  rustup update --no-self-update nightly
  rustup default nightly
  rustup component add --toolchain nightly rust-src
  # We always use a nightly rustfmt, regardless of channel, because we need
  # --file-lines.
  rustup toolchain add nightly --profile minimal
  rustup component add --toolchain nightly rustfmt

And the output in CI is:

  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
  env:
    CARGO_INCREMENTAL: 0
    CARGO_NET_RETRY: 10
    CI: 1
    RUST_BACKTRACE: short
    RUSTFLAGS: -D warnings -D elided_lifetimes_in_paths -D explicit_outlives_requirements -D unsafe_op_in_unsafe_fn -D unused_extern_crates -D unused_lifetimes -D unreachable_pub
    RUSTUP_MAX_RETRIES: 10
    CC: deny_c
    RUST_CHANNEL: nightly
    USE_SYSROOT_ABI: --features sysroot-abi
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2025-03-04, rust version 1.87.0-nightly (e16a049ad 2025-03-03)
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: installing component 'cargo'
info: installing component 'rust-std'
info: installing component 'rustc'

  nightly-x86_64-pc-windows-msvc installed - rustc 1.87.0-nightly (e16a049ad 2025-03-03)

info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: default toolchain set to 'nightly-x86_64-pc-windows-msvc'

  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.87.0-nightly (e16a049ad 2025-03-03)

info: downloading component 'rust-src'
info: installing component 'rust-src'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'

  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.87.0-nightly (e16a049ad 2025-03-03)

info: checking for self-update
info: downloading self-update
warn: tool `rust-analyzer` is already installed, remove it from `C:\Users\runneradmin\.cargo\bin`, then run `rustup update` to have rustup manage this tool.
warn: tool `rustfmt` is already installed, remove it from `C:\Users\runneradmin\.cargo\bin`, then run `rustup update` to have rustup manage this tool.
warn: tool `cargo-fmt` is already installed, remove it from `C:\Users\runneradmin\.cargo\bin`, then run `rustup update` to have rustup manage this tool.
error: invalid value 'C:\Users\runneradmin\.cargo\bin\rustup.exe' for '[+toolchain]': error: "C:\Users\runneradmin\.cargo\bin\rustup.exe" is not a valid subcommand, so it was interpreted as a toolchain name, but it is also invalid. To override the toolchain using the 'rustup +toolchain' syntax, make sure to prefix the toolchain override with a '+'

Notable is the "info: downloading self-update" (and the warnings). Might be something to do with the self update in CI? I'll need to investigate more.

[ChrisDenton]

Quick test is CI was unable to reproduce this: https://github.com/ChrisDenton/rustuptest/actions/runs/13689198328/job/38279145390

Might have been fixed by 1.28.1 though so when I have mo I'll see if I can repo locally with 1.28.0.

[lnicola]

Still fails in rust-lang/rust-analyzer#19301. One difference might be the fact that the GHA runners already have an older rustup and Rust toolchain installed.

[ChrisDenton]

Ok I can reproduce it in CI but it doesn't fail 100% of the time. If I run it five times then it seems to fail at least once:

jobs:
  rust:
    name: Rust
    runs-on: ${{ matrix.os }}
    env:
      CI: 'true'

    strategy:
      matrix:
        os: [windows-latest, windows-latest, windows-latest, windows-latest, windows-latest]

    steps:
      - name: Install Rust toolchain
        run: |
          rustup toolchain add nightly --profile minimal
          rustup component add --toolchain nightly rustfmt

Weirdly I need to set the CI environment variable for it to fail. Which is weird because github already sets that.

If I add rustup self update anywhere before rustup component ... then it works consistently (even though doing it after rustup toolchain is essentially a no-op).

My best guess for why this happens on Windows is some kind of filesystem-based concurrency issue.

[rami3l]

@ChrisDenton Would that be related to some sort of fslinking change?

@lnicola We do know that GitHub Actions installs rustup a bit differently from you'd usually do. That's why we have disabled automatic rustup updates when CI is present...

[ChrisDenton]

Just pausing for a second before doing rustup component seems to make it work: https://github.com/ChrisDenton/rustuptest/actions/runs/13699673535/workflow

[kanru]

Hit this issue https://github.com/chewing/libchewing/actions/runs/13700035109/job/38311241787

[rami3l]

Just pausing for a second before doing rustup component seems to make it work: ChrisDenton/rustuptest/actions/runs/13699673535/workflow

Hmmm, in that case it looks increasingly like #988...

[ChrisDenton]

In any case I'm pretty sure that without the self-update CI wouldn't fail (even if CI was using 1.28.1). So I'd urge people to do this before anything else:

rustup set auto-self-update disable

This won't be necessary for 1.28+ but for 1.27.1 it is.