-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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