Rustup: On Linux, after upgrade from pre-1.31, clippy, rustfmt and rls can't be installed, unless stable is reinstalled and set as default

[eddyp]

It seems I have found a similar issue as the one I found initially on Windows and reported in https://github.com/rust-lang/www.rust-lang.org/issues/591, but the this time on Linux and the workaround does not seem to be complete - see below for complete workaround.

Please note that I had installed rustfmt-preview, rls-preview before trying to update.

eddy@feodora:~$ rustup self update
info: checking for self-updates
eddy@feodora:~$ rustup -V
rustup 1.16.0 (beab5ac2b 2018-12-06)
eddy@feodora:~$ rustup toolchain list
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
eddy@feodora:~$ rustup component add rustfmt
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download
eddy@feodora:~$ rustup component list | grep ' ('
cargo-x86_64-unknown-linux-gnu (default)
rust-analysis-x86_64-unknown-linux-gnu (installed)
rust-docs-x86_64-unknown-linux-gnu (default)
rust-src (installed)
rust-std-thumbv6m-none-eabi (installed)
rust-std-thumbv7em-none-eabi (installed)
rust-std-thumbv7m-none-eabi (installed)
rust-std-x86_64-pc-windows-msvc (installed)
rust-std-x86_64-unknown-linux-gnu (default)
rustc-x86_64-unknown-linux-gnu (default)

I even tried uninstalling stable and reinstalling, but had no success.

eddy@feodora:~$ rustup toolchain uninstall stable
info: uninstalling toolchain 'stable-x86_64-unknown-linux-gnu'
info: toolchain 'stable-x86_64-unknown-linux-gnu' uninstalled
eddy@feodora:~$ rustup toolchain list
nightly-x86_64-unknown-linux-gnu (default)
eddy@feodora:~$ rustup update
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: checking for self-updates

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.32.0-nightly (4a45578bc 2018-12-07)

eddy@feodora:~$ rustup component add rustfmt
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download
eddy@feodora:~$ rustup toolchain install stable
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2018-12-06, rust version 1.31.0 (abe02cefd 2018-12-04)
info: downloading component 'rustc'
 77.7 MiB /  77.7 MiB (100 %)  24.0 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 54.2 MiB /  54.2 MiB (100 %)  25.5 MiB/s ETA:   0 s                
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'

  stable-x86_64-unknown-linux-gnu installed - rustc 1.31.0 (abe02cefd 2018-12-04)

eddy@feodora:~$ rustup component add rustfmt
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download

Only after setting stable as default I could install rustfmt, clippy and rls:

eddy@feodora:~$ rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.31.0 (abe02cefd 2018-12-04)

eddy@feodora:~$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu
eddy@feodora:~$ rustup component add rustfmt
info: downloading component 'rustfmt'
info: installing component 'rustfmt'
eddy@feodora:~$ rustup component add clippy
info: downloading component 'clippy'
info: installing component 'clippy'
eddy@feodora:~$ rustup component add rls
info: downloading component 'rls'
info: installing component 'rls'

I suspect this issue is known, but I wanted to make sure at least the complete solution is listed and the tracker contains the complete workaround somewhere.

Is it expected for this to work out of the box after the next rust/rustup release?

[eminence]

I can reproduce this issue on Windows as well (using rustup 1.16.0 (beab5ac2b 2018-12-06)), so it's probably not platform-specific.

[eddyp]

@eminence can you work around it with the mentioned steps?

[eminence]

Yes. Switching my default toolchain to stable allows me to install clippy and rustfmt:

C:\>rustup default nightly
info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: default toolchain set to 'nightly-x86_64-pc-windows-msvc'

  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.32.0-nightly (4a45578bc 2018-12-07)


C:\>rustup component add clippy
error: component 'clippy' for target 'x86_64-pc-windows-msvc' is unavailable for download

C:\>rustup default stable
info: using existing install for 'stable-x86_64-pc-windows-msvc'
info: default toolchain set to 'stable-x86_64-pc-windows-msvc'

  stable-x86_64-pc-windows-msvc unchanged - rustc 1.31.0 (abe02cefd 2018-12-04)


C:\>rustup component add clippy
info: downloading component 'clippy'
info: installing component 'clippy'

[nrc]

I think the bug here is that the tools were missing from nightly, and Rustup only checks for a component using the default toolchain.

[eddyp]

@nrc does 'tools were missing' means now they are in nighty, too? Or are you unsure, too? Adding @steveklabnik, maybe he knows the details, since he suggested the initial workaround.

[eminence]

@eddyp -- are you still seeing this problem? things seem to be working OK for me today.

[eddyp]

@eminence not sure if I can reproduce the problem, since once I applied the workaround I was effectively hiding any fix. Thinking about it, I don't think I know a way to get to that state since installing a particular version of the compiler would be a separate update channel from stable.

[eminence]

Nevermind, the problem is still there. Is there anything the community can do to help fix this? Is the problem client-side (rustup-side), or server-side?

[lambda-fairy]

It's normal for nightly to omit the tools sometimes, since the tools are developed out-of-tree and sometimes fail to build with the latest compiler. I'll leave it to someone closer to the project to explain why it's set up this way, but that's how it works now.

I think the error message could be improved though -- maybe point to stable or an earlier nightly for the required components. But I don't think the behavior is otherwise incorrect.

[mijoharas]

just to mention, I hadn't used rust for a fair while, and ran into this bug while trying to set up a new computer with a working rust installation. Had me very confused as I'm essentially a beginner.

A better error message would definitely be helpful.

[kinnison]

I'm not sure that there's really much to do here, what would you suggest the error message might look like @mijoharas ?

[mijoharas]

Hi @kinnison. Just re-acquainting myself with this issue, and maybe a better error message isn't the thing needed. I think what was needed might have been some documentation or something.

It's normal for nightly to omit the tools sometimes, since the tools are developed out-of-tree and sometimes fail to build with the latest compiler. I'll leave it to someone closer to the project to explain why it's set up this way, but that's how it works now.

Knowing this is what solved the issue for me. It allowed me to transition from thinking "is my rustup broken", "did I use the incorrect way of adding a component" to "I am looking at a different channel that these tools are not available on".

An error message that would get me directly to the correct understanding of the problem would be something like:

$ rustup component add rustfmt
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download on channel 'nightly' it is available on the following channels: 'stable', 'foobar'

(Note: the default error message doesn't mention the channel which it is trying to find the components on, but my understanding is that this is a key issue).

[kinnison]

Wow, thanks for the detailed response so quickly.

Determining the available channels might be difficult if they're not currently installed, but perhaps a nightly specific extension to the error message to say "Sometimes not all components are available on nightly" would be plausible. Would that be sufficient?

[mijoharas]

That would have solved it for me @kinnison. :+1: