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
- [ ] https://github.com/rust-lang/rustup/pull/3938

[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.

[rami3l]

Also, now that we're at it, maybe you can send a PR over if that is indeed the root cause? By adding a Windows-exclusive fallback to USERPROFILE for example.

The relevant code is here...

rustup/src/currentprocess.rs

Line 133 in 79ba44c

Process::OSProcess(_) => self.var("HOME").ok().map(|v| v.into()),

... and probably add a .context() call here:

rustup/src/currentprocess.rs

Line 51 in 79ba44c

home::env::home_dir_with_env(self)

... similar to what has been done below:

rustup/src/currentprocess.rs

Line 55 in 79ba44c

home::env::cargo_home_with_env(self).context("failed to determine cargo home")

Many thanks in advance 🙇!

PS: Windows ARM64 is still a tier 2 target by far, meaning we still don't have the means to test it with our CI, we currently can only know that it builds correctly for Windows ARM64 (which it does).

[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.