Note: for cleaning individual build units within a build-dir, see #6229

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 the Cargo.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 :

Example entries for rust-analyzer target dir

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