Remove detection of rustup and cargo in 'missing extern crate' diagnostics

[jyn514]

Previously, this would change the test output when RUSTUP_HOME was set:

---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ----
diff of stderr:

1       error[E0463]: can't find crate for `core`
2          |
3          = note: the `thumbv7em-none-eabihf` target may not be installed
+          = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf`
4
5       error: aborting due to previous error
6

Originally, I fixed it by explicitly unsetting RUSTUP_HOME in
compiletest. Then I realized that almost no one has RUSTUP_HOME set,
since rustup doesn't set it itself. It does set RUST_RECURSION_COUNT
whenever it launches a proxy, though - use that instead.

r? @estebank cc @petrochenkov @kinnison

[crlf0710]

I have RUSTUP_HOME set to move all rust related things to a directory under D:\ disk. I didn't really realize the test suite difference is because of this... (and didn't investigate) Thank you for fixing it!

[estebank]

An option would be to use the env var only to be more specific on the help:

Suggested change

	if missing_core && std::env::var("RUST_RECURSION_COUNT").is_ok() {
	err.help(&format!(
	"consider downloading the target with `rustup target add {}`",
	locator.triple
	if missing_core {
	err.help(&format!(
	"{}consider downloading the target with `rustup target add {}`",
	if std::env::var("RUST_RECURSION_COUNT").is_ok() {
	"if you have installed `rustc` with `rustup`,
	} else {
	""
	},
	locator.triple

An even better check would be to use which (or similar) to see if rustup is available at all before giving the suggestion (but then we could get in the weird situation where rustc was installed by, let's say apt, but rustup is available and the suggestion would be wrong).

[estebank]

r=me if noone objects to this approach

[Mark-Simulacrum]

It looks like this detection was added in #84450 without any discussion that I can see on the appropriateness of doing this sort of runtime detection to vary error output.

I am curious about the motivation to only expose this if rustup is installed. In practice, even if the user did install with apt or some other tool, the pointer to rustup target install may still be quite helpful (perhaps they should switch to rustup for example). And if they're not running with rustup and don't want to be, the diagnostic is not really misleading IMO -- it may still be helpful to let them find the appropriate target-specific package in their distro's toolchain for example.

So I'd suggest just dropping the env variable check entirely here, rather than trying to change it to a different one. It seems annoying that rerunning tests with and without rustup wrappers will produce potentially different results; it's not something I at least would expect.

[jyn514]

I am curious about the motivation to only expose this if rustup is installed. In practice, even if the user did install with apt or some other tool, the pointer to rustup target install may still be quite helpful (perhaps they should switch to rustup for example). And if they're not running with rustup and don't want to be, the diagnostic is not really misleading IMO -- it may still be helpful to let them find the appropriate target-specific package in their distro's toolchain for example.

So I'd suggest just dropping the env variable check entirely here, rather than trying to change it to a different one.

Hmm, ok. That makes sense to me.

It seems annoying that rerunning tests with and without rustup wrappers will produce potentially different results; it's not something I at least would expect.

Well, the idea is that you would never run tests with rustup wrappers, since x.py controls the toolchain you use and it always goes through build/stageN. But I agree that saying this unconditionally is probably a better approach.

[jyn514]

By that logic, do you want me to also remove the runtime checking for cargo? https://github.com/rust-lang/rust/blob/32373c40a9781cbbd7ed292a299b28258b2910a8/compiler/rustc_metadata/src/locator.rs#L1100-L1102

[Mark-Simulacrum]

I think it's a good idea, yes, for similar reasons.

[estebank]

@bors r+ rollup

[bors]

📌 Commit 17f7536 has been approved by estebank