Progress indication missing entirely when a shim forces a download

[bjorn3]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

$ rustc
info: syncing channel updates for nightly-2026-03-20-aarch64-unknown-linux-gnu
info: latest update on 2026-03-20 for version 1.96.0-nightly (bcf3d36c9 2026-03-19)
info: downloading 7 components

and then there is no indication of progress anymore until after it has finished downloading everything, which could take minutes depending on the internet speed.

Steps

1. Put some not yet installed toolchain in rust-toolchain.toml
2. Run rustc

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.29.0 (28d1352db 2026-03-05)

Installed toolchains

Not relevant

OS version

Linux

[rami3l]

Root cause: in proxy_mode the dispatch function is called with quiet: true.

Also since v1.29 the progress bar has been a part of the verbosity system; before it was shown unconditionally upon is_a_tty.

rustup/src/cli/proxy_mode.rs

Line 35 in 5d3dee3

let cfg = Cfg::from_env(current_dir, true, process)?;

[djc]

Is this a regression from 1.28, or was that true before as well?

[rami3l]

Is this a regression from 1.28, or was that true before as well?

@djc Yes, this is a regression from v1.28. I'm evaluating whether we should flip that flag here or just decouple the progress bar from the verbosity system.

Ideally it does look right that if I pass --quiet the progress bar is not shown (not necessarily proxy_mode)...

[rami3l]

@djc Hmmm I had another look; the current verbosity system is still a mess. I guess we should pass an enum instead of going quiet: true or verbose: false in a lot of functions which is not super clear. For the proxy_mode case we'd normally want neither --quiet nor --verbose.

But for this particular case it is possible that we can end up with a very local fix by just flipping to quiet: false. I'm checking whether that's possible...