Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustup show fails with panic on Windows #1458

Closed
sprowell opened this issue Jul 6, 2018 · 10 comments
Closed

rustup show fails with panic on Windows #1458

sprowell opened this issue Jul 6, 2018 · 10 comments

Comments

@sprowell
Copy link

sprowell commented Jul 6, 2018

See also (closed) issue #1357 (which I cannot seem to re-open). This is the latest rustup (downloaded 7/1/2018). I get a panic with rustup show on Windows 10 after successful install of rust.

>rustup show
Default host: i686-pc-windows-msvc

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

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src\libcore\option.rs:335:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Other commands work.

>rustup update
info: syncing channel updates for 'stable-i686-pc-windows-msvc'
info: syncing channel updates for 'nightly-i686-pc-windows-msvc'
info: checking for self-updates

   stable-i686-pc-windows-msvc unchanged - rustc 1.27.0 (3eda71b00 2018-06-19)
  nightly-i686-pc-windows-msvc unchanged - rustc 1.28.0-nightly (e3bf634e0 2018-06-28)

Have repeated and confirmed that the problems seems to be the lack of a default toolchain.

@Diggsey
Copy link
Contributor

Diggsey commented Jul 8, 2018

Interesting, it should not be easy to get in a situation where there is no default toolchain. What steps did you take to get to that point? Also what is the contents of your ~/.rustup/settings.toml file?

@JustAPerson
Copy link

I'm hitting this and #1436. I tried using rustup-init.exe which got stuck at the installing component 'rust-docs'. Both rustup update and rustup toolchain install get stuck there.

~/.rustup/settings.toml:

default_host_triple = "x86_64-pc-windows-msvc"
telemetry = false
version = "12"

[overrides]

@dten
Copy link

dten commented Dec 14, 2018

rustup default stable-x86_64-pc-windows-msvc fixed it for me

@mati865
Copy link
Contributor

mati865 commented Dec 14, 2018

Rustup doesn't get stuck at installing component 'rust-docs' but it takes a lot time because of NTFS #1540.

@johnthagen
Copy link
Contributor

which got stuck at the installing component 'rust-docs'

Rustup doesn't get stuck at installing component 'rust-docs' but it takes a lot time because of NTFS

I reported added a progress bar to component installs to help solve this very case (#1557)

kinnison added a commit to kinnison/rustup that referenced this issue Dec 27, 2018
People have requested some indication of progress for long-running
install steps.  This commit re-uses the download tracker logic to
provide a progress bar (the length is the compressed component
tarball but should be good enough) to provide such feedback.

Fixes: rust-lang#1458, rust-lang#1557
@colindean
Copy link

I hit this just now after installing rustup via scoop. My settings.toml is the same as the previous comment's. When I run rustup default stable-x86_64-pc-windows-msvc, I get:

> rustup default stable-x86_64-pc-windows-msvc
?[1minfo: ?[0musing existing install for 'stable-x86_64-pc-windows-msvc'
?[1minfo: ?[0mdefault toolchain set to 'stable-x86_64-pc-windows-msvc'

  ?[1mstable-x86_64-pc-windows-msvc unchanged?[0m - rustc 1.32.0 (9fda7c223 2019-01-16)

This is after a little bit of thrashing, doing rustup install stable and rustup install 1.32.0 and having both do something even though I would think that stable would resolve to 1.32.0 right now.

It seems to work now, for reasons I don't comprehend. I'm able to cargo build.

@rbtcollins
Copy link
Contributor

So I think this should be broken into two problems:

I propose that we reopen 1450, fix that because its clear and simple, fix it (with the case that no default results in a link to this ticket), and then try to figure out the sporadic failure to have a default here)

@kinnison
Copy link
Contributor

kinnison commented May 9, 2019

We've not panic!()d on a lack of default toolchain for a few releases now, instead you get a well-formed error: no default toolchain configured though perhaps we could then offer a hint on how to fix that.

Regarding why there's no default toolchain, I'm not sure, so we can proceed with investigating that on this issue.

@kinnison
Copy link
Contributor

I'm not sure that this has been reproduced in the past 6 months. Does anyone have any way to reproduce this which they've not shared yet?

@kinnison kinnison reopened this Nov 10, 2019
@kinnison
Copy link
Contributor

Oops, mis-clicked

@kinnison kinnison closed this as completed Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants