Trying to use a component that is not installed runs for about a second before reporting an error

[saethlin]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed 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

I run into this all the time because my editor runs rustfmt --version on save to initialize the rust.vim extension's rustfmt support. If I am in a project that has set a toolchain override that doesn't have rustfmt, this makes vim hang for a second when I try to write-quit.

Steps

$ rustup component remove rustfmt
$ time rustfmt

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.28.2 (e4f3ad6f8 2025-04-28)

Installed toolchains

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/ben/.rustup

installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (active, default)
nightly-2025-05-22-x86_64-unknown-linux-gnu
nightly-2025-05-23-x86_64-unknown-linux-gnu
0c33fe2c3d3eecadd17a84b110bb067288a64f1c
2d5ffc513f1c56b7bc95bacb2519705096e8cc2b
45b94dd98018f2609b43a8d8e08ec5432b9e0647
55dc6112586ae887a7811648b0a8a05e1ac90162
6e23095adf9209614a45f7f75fea36dad7b92afb
8c46fcbb191b4a054f15dac8d411078faa679379
master-stage1
miri
stage1
stage2

active toolchain
----------------
name: nightly-x86_64-unknown-linux-gnu
active because: it's the default toolchain
installed targets:
  x86_64-unknown-linux-gnu

OS version

Linux archlinux 6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000 x86_64 GNU/Linux

[Nemo157]

By my reading of

rustup/src/toolchain.rs

Lines 449 to 478 in 06bf5c1

	} else {
	let recursion_count = self
	.cfg
	.process
	.var("RUST_RECURSION_COUNT")
	.ok()
	.and_then(|s| s.parse().ok())
	.unwrap_or(0);
	if recursion_count > env_var::RUST_RECURSION_COUNT_MAX - 1 {
	let binary_lossy: String = binary.to_string_lossy().into();
	if matches!(
	&self.name,
	LocalToolchainName::Named(ToolchainName::Official(_))
	) {
	let distributable = DistributableToolchain::try_from(self)?;
	// Design note: this is a bit of an awkward cast from
	// general (toolchain) to more specialised (distributable);
	// perhaps this function should something implemented on a
	// trait, permitting removal of that case.
	return Err(distributable.recursion_error(binary_lossy).unwrap_err());
	} else {
	let t = &self.name;
	return Err(anyhow!(
	"'{binary_lossy}' is not installed for the custom toolchain '{t}'.\nnote: this is a custom toolchain, which cannot use `rustup component add`\n\
	help: if you built this toolchain from source, and used `rustup toolchain link`, then you may be able to build the component with `x.py`"
	));
	}
	}
	Path::new(&binary)
	};

if the toolchain doesn't have the binary then it recurses by re-exec-ing the plain binary name, which would resolve to the rustup proxy on the PATH again, and only once it's 20 execs deep will it detect the recursion and error. Running with different initial RUST_RECURSION_COUNT does relatively linearly affect how long it takes to print the error.

[ChrisDenton]

@Diggsey, before I start suggesting fixes that might break things, would you happen to remember any context for the rustup behaviour shown in the post above?

[Diggsey]

I've been long out of the rustup codebase. I would avoid any fixes that involve changing PATH, as I know that will break things, but I don't see why it couldn't detect this type of error directly.

[ChrisDenton]

Thanks! Ok so one option would be to manually scan PATH and check if the found binary is the same file as the current process (i.e. it's rustup). There may be platform differences here and if our algorithm works slightly different from Command then it's possible we might have a false positive/negative in some edge case situations.

Otherwise we could do something about detecting a direct recursion. I.e. detect that rustup was run directly from rustup without passing through cargo or another binary first. This should be possible by detecting the parent process (though that's also a platform-specific thing).