Skip to content

Garbage collect whole target/ #13136

Open
@epage

Description

@epage

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 :

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

Metadata

Metadata

Assignees

Labels

C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewZ-gcNightly: garbage collectionZ-scriptNightly: cargo script

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions