Provide assistance in uninstalling unused toolchains, i.e. toolchain garbage collection

[kpreid]

Problem you are trying to solve

People who work on projects using pinned nightly (nightly-DDDD-MM-YY) or stable (1.XX.0) channels, or who perform bisection on toolchain bugs, may end up with many toolchains installed. It would be useful to help those users know when they can remove no-longer-used toolchains and reclaim disk space.

Solution you'd like

Whenever rustup runs a toolchain binary, update a “last used” timestamp for that toolchain (this could be as simple as touching a file kept with the toolchain, and could be kept at a coarse granularity of 1 day to reduce the cost of writes). Add the following UI features using this data:

• In rustup toolchain list, include last used dates.
• Add a command which may be run to uninstall all toolchains that have not been used recently.
• Whenever a new toolchain is manually or automatically installed, check how many old toolchains are installed and tell the user if there are a lot (perhaps with configurable thresholds).
• Optionally, automatically uninstall old toolchains to keep the count or age under configured limits.

(Another thing that would help is searching all rust-toolchain.toml files currently present for what channels they request, but that would either be costly or require integration with platform-specific filesystem search systems, so I do not recommend spending effort on this feature unless someone thinks it would be easy.)

Notes

I feel like this is obvious enough that it surely must have been suggested already, but I can't find any issue about it, using keywords like "automatically uninstall" and "toolchain garbage collection”. I apologize if this turns out to be a duplicate.

[rami3l]

@kpreid Many thanks!

We are aware of this issue and, your adding keywords to the search result also contributes a lot to triaging.

A related issue is #3919. Maybe we should call this issue "garbage collection" and that one "garbage detection"?

LRU may be a good enough heuristics but I think rustup has all information required to perfectly detect garbage since it will be able to know (from a point on) why each toolchain is installed.

PS: Personally I call it "the elan problem" since this lack of functionality has become a nightmare in our downstream elan, where somehow basically every Lean repo has it's own toolchain version toml which are regularly updated... I think you can fill in the rest.

[kpreid]

rustup has all information required to perfectly detect garbage since it will be able to know (from a point on) why each toolchain is installed.

I agree that tracking the cause of installation, and the paths of toolchain files previously encountered, would be useful, but it is not complete information. If I type cargo +1.83.0 test once, rustup cannot know whether I plan to type it again.

[rami3l]

@kpreid I think it still boils down to why you would use a toolchain as specific as 1.83.0. What do you have in mind to be more precise?

[RalfJung]

With stable toolchains this might be rare, but with nightly toolchains it's quite common to have to pin a specific one.

[djc]

I like the idea of tracking last use time. I do wonder what the cost will be in terms of proxy overhead.

[rami3l]

With stable toolchains this might be rare, but with nightly toolchains it's quite common to have to pin a specific one.

@RalfJung I still think nightly toolchain uses can mostly be tracked by reason of installation since they are pinned by per-project overrides most of the time?

IMHO the only remaining concern in the above discussion is whether LRU-based detection is necessary.

[kpreid]

@kpreid I think it still boils down to why you would use a toolchain as specific as 1.83.0. What do you have in mind to be more precise?

As I mentioned in the original issue, performing bisection on toolchain bugs — or other behavior changes (e.g. lint additions/removals/rescopes, or performance regressions) which are not bugs. This is more common with nightly but one might still need to do it on stable releases. One could also do it in order to test against a proposed lowered MSRV.

That said, the primary toolchains I would actually, personally, like cleaned up for me — the ones that prompted me to file this issue — are stable toolchains pinned by rust-toolchain.toml files. For that particular use case, tracking need for toolchains based on the continued presence of previously encountered rust-toolchain.toml files would be exactly what I want and an improvement on my date-based cleanup proposal.

But my point in what you were replying to is really that it is not true that those files constitute perfect information about toolchain usage. It may well be adequate information for practical purposes (the user could be told “these toolchains have no references to them in files, so you may want to uninstall them”), but it is not perfect.