`rustup default` no longer exits with `1` with no default toolchain is set

[weihanglo]

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

(Edited by @rami3l to better reflect the original issue)

Coming from https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-v1-28-0/22060.

With rustup v1.27.1, the following shell snippet can be used to force the installation of the default toolchain, or fall back on stable when none is present:

rustup default || rustup default stable

When testing out the upcoming 1.28 release, however, I found that rustup default is returning 0 even there's no such thing as the default toolchain, resulting in an unchanged default toolchain state.

I've noticed the suggestion provided in the post:

rustup show active-toolchain || rustup toolchain install

... but it doesn't really help with the use case above, since regardless in 1.27.1, the current stable branch (1.28-beta), it seems to always exit with code 0.

• 1.27.1

  rustup/src/cli/rustup_mode.rs

  Lines 1227 to 1257 in 54dd3d0

  	fn show_active_toolchain(cfg: &Cfg, m: &ArgMatches) -> Result<utils::ExitCode> {
  	let verbose = m.get_flag("verbose");
  	let cwd = utils::current_dir()?;
  	match cfg.find_or_install_override_toolchain_or_default(&cwd) {
  	Err(e) => {
  	let root_cause = e.root_cause();
  	if let Some(RustupError::ToolchainNotSelected) =
  	root_cause.downcast_ref::<RustupError>()
  	{
  	} else {
  	return Err(e);
  	}
  	}
  	Ok((toolchain, reason)) => {
  	if let Some(reason) = reason {
  	writeln!(
  	process().stdout().lock(),
  	"{} ({})",
  	toolchain.name(),
  	reason
  	)?;
  	} else {
  	writeln!(process().stdout().lock(), "{} (default)", toolchain.name())?;
  	}
  	if verbose {
  	writeln!(process().stdout().lock(), "{}", toolchain.rustc_version())?;
  	}
  	}
  	}
  	Ok(utils::ExitCode(0))
  	}

• stable

  rustup/src/cli/rustup_mode.rs

  Lines 1100 to 1105 in 7ccf717

  	None => writeln!(
  	cfg.process.stdout().lock(),
  	"There isn't an active toolchain"
  	)?,
  	}
  	Ok(utils::ExitCode(0))

Steps

1. rustup default none
2. rustup default || rustup default stable

Possible Solution(s)

Should we find another workaround?

Notes

No response

Rustup version

* rustup 1.27.1 (1980-01-01)
* rustup 1.28.0 (7ccf717e6e1aee46f65cc6fea4132a3f0e37593b)

Installed toolchains

rustup 1.27.1

installed toolchains
--------------------

error: no default toolchain configured

rustup 1.28.0

installed toolchains
--------------------

active toolchain
----------------
no active toolchain

OS version

Both Darwin and Linux

[weihanglo]

I figured out it is because I didn't have any default. Maybe we don't want to handle the missing default case?

[ChrisDenton]

I suspect this case had just never been considered. When can you end up with no default? Is it only after uninstalling all toolchains?

[ChrisDenton]

Edit: ah you already said, sorry. rustup default none. Hmm.

[weihanglo]

When can you end up with no default? Is it only after uninstalling all toolchains?

For normal users,

• During sh.rustup.rs installation, select none for the default toolchain.
• rustup default none

I believe this is rare, but some environments might have no default.

[ChrisDenton]

I think it may make sense to change it to an error if there is no active toolchain but then that won't help with migration. Unless we also backport the change.

[ChrisDenton]

Hm, rustup show does return an exit code of 1 on 1.27.1 but not on 1.28.

[rami3l]

@weihanglo @ChrisDenton I believe this is a bug on our side. Will fix.

[rami3l]

The only thing here is that we need to make sure that our command return 1 where it should.

This includes at least rustup show active-toolchain and rustup default.

[weihanglo]

Hm, rustup show does return an exit code of 1 on 1.27.1 but not on 1.28.

rustup default has changed its exit code as well when no default.

Should we have a small "compatibility notes" section for these changes in our changelog, just like how rust release does?

Anyway, thanks people for your help!
For my own usage, I can definitely find workarounds. I am good with any approach we take, or doing nothing :)

[rami3l]

@ChrisDenton A lot of these compat changes come from #3225. Apparently I was new to the team when reviewing this at the time and didn't understand the implications underneath... I'll try to do follow-up fixes for this.

[ChrisDenton]

I can definitely sympathize with being new! Do we need to add this as a release blocker somewhere?

[rami3l]

I can definitely sympathize with being new! Do we need to add this as a release blocker somewhere?

@ChrisDenton Added to #3998 (comment).