Feature request: `rustup toolchain rename`

[ketsuban]

This may be a bit niche but...

I was hit by the most recent nightly not including the RLS and had to downgrade, but I wanted to retain the name nightly (rather than nightly-2017-11-30). This turned out to need two different folders to be renamed:

$RUSTUP_HOME/toolchains/<toolchain> - so it'll show up as e.g. nightly-x86_64-pc-windows-msvc in rustup toolchain list.
$RUSTUP_HOME/update-hashes/<toolchain> - I initially installed nightly-2017-12-02, but that's the one that doesn't have the RLS! Trying to rustup toolchain uninstall it got me an error because I hadn't renamed this folder.

A single rustup command such as rustup toolchain rename could do this without needing me to know anything about the structure of $RUSTUP_HOME.

[yuyoyuppe]

Just stumbled upon this, and here's an easy fix - you can specify rust-client.rlsPath option in VSCode settings.json, e.g.:

"rust-client.rlsPath": "C:\Users\yuyoyuppe\.rustup\toolchains\nightly-2019-07-19-x86_64-pc-windows-msvc\bin\rls.exe"

[ketsuban]

I could also just have set my override to nightly-2017-12-02 rather than nightly; the problem was I wanted a specific nightly build but didn't want it to be permanently tagged with the date, so that later on I can update to a newer nightly if I want.

[kinnison]

There are a number of different solutions to the same sort of problem you describe in the original posting on this issue. We're not yet sure which we're going to take, so thank you for your suggestion, but I'm not able to say if it's something we're likely to merge yet.

[kinnison]

With Rustup 1.20 this situation should hopefully be less likely to occur. Is that sufficient to solve your problem or do you still want this feature as well?

[kinnison]

Is it okay if I close this?

[JoshLind]

FYI, this is still very much needed 😄 e.g., see: #3390

[rbtcollins]

I think with some safeguards this could be done.

Specifically: renaming a toolchain should check the toolchain is compatible with the new name.

stable -> specific version should check the version
nightly/beta/otherchannelsinfuture/custom -> specific version should error
any channel -> same-channel-date-based should check the date if possible, or we should prohibit it
any-channel-date-based-> same-channel-unqualified is ok
specific version -> stable is ok