Windows: "called Option::unwrap() on a None value"

[Baiyuetribe]

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

windows on Arm64 still not work.

thread 'main' panicked at src\cli\self_update.rs:652:45:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps

reproduce

# my device: windows arm64
git clone https://github.com/rust-lang/rustup.git
cargo build --release

after,i got rustup-init.exe.

Possible Solution(s)

No response

Notes

No response

Rustup version

latest

Installed toolchains

none

OS version

windows arm64

Tasks

Beta Give feedback

1. Fix home_dir() and current_dir() regression #3938
   +0

[rami3l]

@Baiyuetribe Sorry for your bad experience!

Do you have the HOME environment variable set (https://superuser.com/a/1617017)? Rustup depends on that to work.

[ChrisDenton]

Do you have the HOME environment variable set (https://superuser.com/a/1617017)? Rustup depends on that to work.

Wait, why is rustup doing this directly? I thought it used the home crate? Did this change?

[ChrisDenton]

Needing the HOME environment variable seems like a regression.

[rami3l]

Do you have the HOME environment variable set (https://superuser.com/a/1617017)? Rustup depends on that to work.

Wait, why is rustup doing this directly? I thought it used the home crate? Did this change?

@ChrisDenton Blame: Introduced in 0997247, four years ago.

[ChrisDenton]

That's super weird because I have installed it within that time without having HOME. I mean, it doesn't exist by default.

[ChrisDenton]

It seems like we have two home_dir functions that do different things:

rustup/src/currentprocess.rs

Lines 50 to 53 in 79ba44c

	pub(crate) fn home_dir(&self) -> Option<PathBuf> {
	home::env::home_dir_with_env(self)
	}

rustup/src/currentprocess.rs

Lines 130 to 133 in 79ba44c

	impl home::env::Env for Process {
	fn home_dir(&self) -> Option<PathBuf> {
	match self {
	Process::OSProcess(_) => self.var("HOME").ok().map(|v| v.into()),

[rami3l]

It seems like we have two home_dir functions that do different things:

rustup/src/currentprocess.rs

Lines 50 to 53 in 79ba44c

	pub(crate) fn home_dir(&self) -> Option<PathBuf> {
	home::env::home_dir_with_env(self)
	}

rustup/src/currentprocess.rs

Lines 130 to 133 in 79ba44c

	impl home::env::Env for Process {
	fn home_dir(&self) -> Option<PathBuf> {
	match self {
	Process::OSProcess(_) => self.var("HOME").ok().map(|v| v.into()),

@ChrisDenton My theory is that the former calls the latter with an indirection, in that home_dir_with_env() accepts a home::env::Env and calls its home_dir():

/// Returns the path of the current user's home directory from [`Env::home_dir`].
pub fn home_dir_with_env(env: &dyn Env) -> Option<PathBuf> {
    env.home_dir()
}

[ChrisDenton]

Then I'm super confused why this isn't a problem for x86_64.

[rami3l]

Then I'm super confused why this isn't a problem for x86_64.

@ChrisDenton I believe it should be, but we shouldn't trust the CI runner because from its POV setting HOME doesn't break anything.

[ChrisDenton]

Ah, I see. From testing it seems the published x86_64 installer works but not if I build from master. So it seems like this did regress at some point. I'm less confused now. This is a major regression because it means rustup-init is broken by default on Windows.

It also seems weird that we have two ways of getting rustup home that are implemented completely differently. In some places we use home::rustup_home and in other places it's manually implemented using process.home_dir().unwrap().join(".rustup")

[rami3l]

Ah, I see. From testing it seems the published x86_64 installer works but not if I build from master. So it seems like this did regress at some point. I'm less confused now. This is a major regression because it means rustup-init is broken by default on Windows.

@ChrisDenton You mean somewhere between master and the v1.27.1 tag? Could you do a bisect in addition since I don't have a Windows machine near me, many thanks in advance 🙇

It also seems weird that we have two ways of getting rustup home that are implemented completely differently. In some places we use home::rustup_home and in other places it's manually implemented using process.home_dir().unwrap().join(".rustup")

That'll be a very good place to improve indeed.

[ChrisDenton]

Could you do a bisect

Sure. It regressed in 204c8a9.

That'll be a very good place to improve indeed.

I think we should calculate rustup/cargo home once then cache it somewhere. Also those sanity checks look very unix-specific (unix paths and bash scripts). Not sure if they're relevant to Windows. Maybe there should be greater separation between platform specific bits. But that's a bigger job.

[rami3l]

@ChrisDenton Thanks a lot for helping out!

Also those sanity checks look very unix-specific (unix paths and bash scripts). Not sure if they're relevant to Windows.

Rustup used to have runtime detection of OS instead of conditional compilation. The idea of this check is that it should be a no-op on Windows... I've set it as a part of #2424.

It regressed in 204c8a9.

cc @djc (Looks like OS_ENV should be used for OSProcess. The two branches are written in the wrong order.)

[rami3l]

@Baiyuetribe Given @ChrisDenton's analysis, https://win.rustup.rs/aarch64 should work for you without problems.

[rami3l]

Please note that #3938 does NOT close this.

We'll still need to:

• Refine the usages of process.home_dir().unwrap().join(".rustup");
• Make the sanity check function platform-aware.

Looks like do_pre_install_sanity_checks() dates back from prehistoric times (v0.1.9, 0080271), to defend against the old Rust distribution tools (namely "multirust.sh, rustc tarballs, and rustup.sh").

Now let's look at the files it verifies:

• manifest-rustc (without any prefix) is almost certainly gone: I cannot see this on my machine.
• uninstall.sh is... gone as well? Not quite sure, but a solution like this will definitely not work with Windows.
• ~/.rustup/rustup-version is not for the Rust version of rustup, but rather its prototype rustup.sh (so there's no point in changing this to rustup_home()!), implemented in shell script, so is Unix only.

... so this function serves no purpose, at least not on Windows. My suggestion for now is to revert 0080271 completely. @djc @ChrisDenton what do you think?

[Baiyuetribe]

@Baiyuetribe Given @ChrisDenton's analysis, https://win.rustup.rs/aarch64 should work for you without problems.

thanks,it works 👍🏻

[ChrisDenton]

My suggestion for now is to revert 0080271 completely

Makes sense to me! I think it served it's purpose in helping migration to rustup in ancient times but I don't think we still need to handle pre-1.0 stuff.