Description
Problem
With "cargo script", the target directory is "hidden" from the user, making it easy to leak when you delete your script.
If we move forward with rust-lang/rfcs#3371, a similar situation will happen for regular packages.
If I haven't touched a project in a long while but have run rustup update
, there might be nothing of use left in target/
, wasting space.
Sometimes I want to cargo clean
all projects on my system (see #11305).
Proposed Solution
We should track in the GC data base a list of
- Root-manifests (ie the
Cargo.toml
/ cargo script associated with the target directory) - Target directory
- (maybe) The path to the
Cargo.lock
for future potential work like Pin cache entries still in use #13137 without having to infer theCargo.lock
(special logic needed for cargo-script, feature requests exist for even weirder situations)
Note that neither of the two fields can serve as a unique / primary key. If people use CARGO_TARGET_DIR=/tmp/cargo
then multiple workspaces may point to the same target dir. Likewise, people may end up with multiple target dirs for one workspace.
We need to track the Cargo.toml
/ cargo script because the workspace root is ambiguous when it comes to cargo scripts.
Example entries for CARGO_TARGET_DIR=/tmp/cargo
:
id | workspace-manifest | target dir | timestamp |
---|---|---|---|
? | /foo/Cargo.toml | /tmp/cargo | ? |
? | /bar/Cargo.toml | /tmp/cargo | ? |
? | /baz/script.rs | /tmp/cargo | ? |
Example entries for rust-analyzer target dir
id | workspace-manifest | target dir | timestamp |
---|---|---|---|
? | /foo/Cargo.toml | /foo/target | ? |
? | /foo/Cargo.toml | /foo/target-ra | ? |
? | /bar/Cargo.toml | /bar/target | ? |
? | /bar/Cargo.toml | /bar/target-ra | ? |
? | /baz/script.rs | ~/.cargo/target/... | ? |
Forms of cleanup
- Delete
target/
if unused for X time (this is in the "locally recreatable" category) - Delete all
target/
(I just upgraded Rust, maybe rustup could suggest this) - Delete leaked
target/
(workspace doesn't exist)- However, it might be transient (on a thumb drive). Should we make this time based?
Notes
No response