Rustup: Rustup is going to break in 2026

[carols10cents]

Problem

A clone of Alex Crichton just time-travelled back from the year 2026 to tell me to file this issue (they can't file the issue themselves or they risk causing a paradox).

They said we just released 1.100.0, and everyone was all excited, but as soon as it was released, everyone was all sad because this happened:

rustup toolchain install 1.100.0
error: invalid toolchain name: '1.100.0'

Everyone expected rustup to download and install the 1.100.0 version, but instead they got this error message, despite the version being released.

Steps

1. Wait until 2026
2. Release 1.100.0
3. rustup toolchain install 1.100.0

Possible Solution(s)

One of the Alex Crichton clones in 2026 was able to quickly track down the issue to this regex: https://github.com/rust-lang/rustup/blob/9309d66429a879e3c1e919f410593627df69d32d/src/dist/dist.rs#L285-L286

Is there a reason we can't change these two regexen to \d+\.\d+\.\d+ to be future-proof into 2130 and also support the unfortunate case that we might need to release 10 patch versions in a cycle?

I have not yet been visited by any clones from any alternate futures in which we make this fix, so it seems fine.

Notes

Output of rustup --version: The Alex Crichton clone didn't want to reveal any more information than absolutely necessary to avoid polluting the timeline
Output of rustup show: ditto

[Diggsey]

Looks like it will also need changing here: https://github.com/rust-lang/rustup/blob/9309d66429a879e3c1e919f410593627df69d32d/src/dist/dist.rs#L379

(Or better yet, the two methods refactored to share that parsing code)

I believe this would technically be a breaking change because those toolchain names would currently be considered "custom" toolchains. and theoretically someone could have created a custom toolchain with a name that conflicts with this, but in practice, I think it's a non-issue.

[kinnison]

Never one to ignore portents of the future, especially ones where brave rustaceans risk the timeline to correct a fatal flaw in their ecosystem I shall do my best to ensure that Alex need never risk his personal timeline again on this matter. I'm not sure I quite like the idea of \d+ since that opens a risk of people thinking 2020.12.14 might be a valid version number and then be confused about date stamps; but I think allowing up to 9.999.99 seems reasonable.

[vks]

Wouldn't it be better to use the semver crate instead of a regex for parsing the version?

[kinnison]

This is not about parsing version numbers, but about matching toolchain specifications which happen to be able to contain version numbers. In reality rustup does not care about versions :D