holmgr / cargo-sweep Goto Github PK

Cargo no longer creates the native directory, which breaks cargo-sweep. The change happened in this commit rust-lang/cargo#7227

Would you consider adding a new flag for removing the binary and / or a "remove everything" flag?

Sometimes I am out of disk space, and I just want to nuke everything, but since I have several projects going at once, cargo-sweep will leave multiple files behind, some of which are several hundred megabytes (debug builds with debug symbols and sources for iOS).

I think it would be handy with a --nuke option (there's probably a better name....) to just remove everything from the /target folders.

Thanks

cargo-sweep … and cargo sweep … should be equivalent, with the possible (but not mandatory) exception of usage information differing by that one character.

Instead, cargo sweep … is equivalent to cargo-sweep sweep …. This leads to inconsistency with well-established conventions, and the help page being confusing, with cargo sweep --help referring to cargo-sweep-sweep and talking about running the command as cargo-sweep sweep.

atime is disabled by default but there is a registry key you can check to warn people it is disabled:

• Location: SYSTEM\CurrentControlSet\Control\FileSystem
• Key: NtfsDisableLastAccessUpdate
• Type: DWORD
• Values: 0 or 0x80000000, 1 or 0x80000001

In Win10 1803 they changed the value of the key which is why I listed two for true and two for false.

Cargo just merged a new fingerprint format in rust-lang/cargo#8210 (look for Fingerprint changes) We should make shure we are compatible with both the old and the new formats.

I ran cargo sweep -t 5 to clean up my target folder but now the build fails with:

 = note: LINK : fatal error LNK1201: error writing to program database 'D:\projects\myproject\target\debug\deps\myproject-fc1c31bb36e24a5b.pdb'; check for insufficient disk space, invalid path, or insufficient privilege

I'm on Windows 8.1 btw.

The pdb file exists and is 87 MB large, the other files with that hash in the name are 218 files named myproject-fc1c31bb36e24a5b.<some-hash>.rcgu.o and 1 file named myproject-fc1c31bb36e24a5b.d.

I have 165 GB free space on that disk and it worked before I did cargo sweep.

How can I get it to build again without having to rebuild everything (which would take ages)?

I (and many other people) configue cargo to use a single target dir shared between all projects, by putting something like this in ~/.cargo/config:

[build]
target-dir = "/Users/iyes/.cargo/target"

That way all projects put their build artifacts in the same place, allowing dependencies to be reused, etc. shortening clean build times.

However, currently there is no nice way to remove only outdated build artifacts from it (say, when updating a nightly toolchain), without outright deleting everything. cargo sweep could be the perfect tool for this. However, it is currently unsupported, as the tool expects to be run on project dirs.

I installed a custom version of rust from source (with x.py) and then cleaned the target directory. Now cargo sweep -i doesn't work. Instead of giving a hard error, it should just skip custom toolchains and continue sweeping all others.

$ cargo sweep -i
[INFO] Using all installed toolchains: ["stable-x86_64-unknown-linux-gnu", "beta-x86_64-unknown-linux-gnu", "nightly-2021-07-17-x86_64-unknown-linux-gnu", "nightly-2021-07-19-x86_64-unknown-linux-gnu", "nightly-2021-07-23-x86_64-unknown-linux-gnu", "nightly-2021-12-30-x86_64-unknown-linux-gnu", "nightly-x86_64-unknown-linux-gnu", "1.42-x86_64-unknown-linux-gnu", "1.43-x86_64-unknown-linux-gnu", "1.44-x86_64-unknown-linux-gnu", "1.45-x86_64-unknown-linux-gnu", "1.47-x86_64-unknown-linux-gnu", "1.50-x86_64-unknown-linux-gnu", "1.51-x86_64-unknown-linux-gnu", "1.54-x86_64-unknown-linux-gnu", "1.57-x86_64-unknown-linux-gnu", "wasi", "1.46.0-x86_64-unknown-linux-gnu", "1.49.0-x86_64-unknown-linux-gnu", "1.53.0-x86_64-unknown-linux-gnu", "1.55.0-x86_64-unknown-linux-gnu"]
[ERROR] Failed to clean "/home/jnelson/redacted/target": 
$ cargo +wasi -vV
error: toolchain 'wasi' is not installed
$ rustup toolchain list -v | grep -v -
wasi	/home/jnelson/src/rust/out

Should we add a Minimum Supported Rust Version notice to the readme?

I ran cargo-msrv in the project, at the time of writing (fd4dc55) this version is 1.60.0.

Version: 0.6.2.

I ran:

$ cargo sweep --toolchains asd

And expected cargo-sweep to report an error saying that asd not a valid/known toolchain.

Instead I got this:

[INFO] Cleaned 1.41 GiB from "/home/marcospb19/cargo-sweep/target"

And no error was reported.

I have a git with the following layout

.
├── Cargo.toml
├── app-wasm
│  ├── Cargo.toml
├── cli
│  ├── Cargo.toml
├── crates
│  ├── api
│  │  ├── Cargo.toml
│  ├── models
│  │  ├── Cargo.toml
...

Where the top-level Cargo.toml looks like:

[workspace]
members = [
    "crates/*",
]
exclude = [
    "cli",
    "app-wasm",
]

Where cli and app-wasm are standalone applications that use the workspace crates.

I used the following commands:

• After rustup update: cargo sweep -r --toolchains="stable" "$HOME/repos/"
• As well as cargo sweep -r -t 0 "$HOME/repos/"

Actual:

• Did not clean the incremental folder from the top-level workspace target folder.
• Did not clean any artifacts from cli or app-wasm.

Expected:

• All targets properly cleaned.

I am willing to work on a PR if this can be confirmed to be a bug.

Thanks!

Hello @holmgr, I noticed that there haven't been any PRs merged in the past year or so, even though there are a few useful and small PRs open. Are you still interested in maintaining this tool? If not, would you consider giving it to someone else to maintain? I'm happy to volunteer, or there's https://github.com/rust-bus which maintains several other popular crates.

I was making a contribution when I found this:

This TODO note is suggesting that we allow the --maxsize flag to expect
common byte-size units, like "300 MB", "10GB" and "10 GiB".

The parse-size crate already implements the parsing needed to make this work.

EDIT: Oops, seems like we are already using human_size::Size to do this kind of parsing.
EDIT2: Note that humansize and human-size are two different crates.

When running cargo sweep -i:

thread 'main' panicked at '--time argument missing', /home/lynne/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sweep-0.6.1/src/main.rs:232:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

When running cargo sweep -i -t 30:

error: The argument '--installed' cannot be used with one or more of the other specified arguments

USAGE:
    cargo-sweep sweep <--stamp|--file|--time <days>|--installed|--toolchains <toolchains>|--maxsize <maxsize>>

For more information try --help

It seems as though the issue is that the time argument is expect()ed here:

...even though the --installed flag never uses the value of keep_duration (and therefore it shouldn't be expect()ed):

This issue also occurs with the --toolchains flag and --maxsize flags.

I'd love to use this in my CI, but to use it, I'd need to do one of:

• add it to the main image in use (painful since I'm able to use vanilla rust:$ver containers now)
• add building cargo-sweep to my CI. This doesn't seem like it'd save me a lot of time (or ease of maintenance)

It'd be great if prebuilt binaries could be uploaded to the Releases page for use through a simple ( curl -O ... && verify && cargo sweep ) || :-like command chain in the CI script.

After running rustup update nightly, cargo sweep -i does nothing. I'm not sure if it's possible to do anything in this situation, but I figure it can't hurt to ask.

If you want to sweep everything, you might want to run cargo clean instead of sweep.

But cargo-sweep can be used as a cargo clean that runs recursively in a folder full of projects, here's how you do it:

$ cargo sweep --recursive --time 0

I suggest we add a --all flag to remove the need of using --time 0:

$ cargo sweep --recursive --all
$ cargo sweep --all

Current behavior

With the exception of this metadata error that usually occurs when you're not running inside a project:

For every possible error in cargo-sweep, it reports the error and exits with a success exit code.

Expected behavior

The cargo-sweep process should exit with an error exit code.

Not sure if this is actually a concern, of whether the atime is preserved on caches or not.

The goal would be for us to be able to run cargo-sweep before cache creation to remove everything unnecessary to make caches smaller so creation and load are faster (and because we'd be better citizens with Travis who gives this stuff to us for free)

The ANSI escape sequences for colors does not work on windows cmd.

In Cargo we use the termcolor crate for handling colors in a cross platform way.

This will be important for CIs, otherwise

• You are limited to what is in your cache
• You do extra work to be able to update it

For doing pre-build binaries, see trust. The WG-CLI is working on improving this

The default output listing every file to delete is quite noisy, since it prints every file that will be deleted.

We should by default no longer list each file being deleted for toolchain, just list the project path instead and the total size removed.

_Originally posted by @juhp in #60 (comment)

Here's the output of running cargo sweep -r -i:

[INFO] Using all installed toolchains: ["stable-2022-09-22-x86_64-unknown-linux-gnu", "stable-x86_64-unknown-linux-gnu", "nightly-2022-06-20-x86_64-unknown-linux-gnu", "nightly-2022-08-06-x86_64-unknown-linux-gnu", "nightly-x86_64-unknown-linux-gnu", "1.35.0-x86_64-unknown-linux-gnu", "1.57.0-x86_64-unknown-linux-gnu", "1.58.1-x86_64-unknown-linux-gnu", "1.59.0-x86_64-unknown-linux-gnu", "1.60.0-x86_64-unknown-linux-gnu", "1.61.0-x86_64-unknown-linux-gnu", "1.63.0-x86_64-unknown-linux-gnu", "1.64.0-x86_64-unknown-linux-gnu", "1.65.0-x86_64-unknown-linux-gnu"]
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/PROJECT_1/target"
[INFO] Using all installed toolchains: ["stable-2022-09-22-x86_64-unknown-linux-gnu", "stable-x86_64-unknown-linux-gnu", "nightly-2022-06-20-x86_64-unknown-linux-gnu", "nightly-2022-08-06-x86_64-unknown-linux-gnu", "nightly-x86_64-unknown-linux-gnu", "1.35.0-x86_64-unknown-linux-gnu", "1.57.0-x86_64-unknown-linux-gnu", "1.58.1-x86_64-unknown-linux-gnu", "1.59.0-x86_64-unknown-linux-gnu", "1.60.0-x86_64-unknown-linux-gnu", "1.61.0-x86_64-unknown-linux-gnu", "1.63.0-x86_64-unknown-linux-gnu", "1.64.0-x86_64-unknown-linux-gnu", "1.65.0-x86_64-unknown-linux-gnu"]
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/PROJECT_2/target"
... repeats for a total of 26 projects ...

But here's what the first line looks like in the terminal emulator:

[INFO] Using all installed toolchains: ["stable-2022-09-22-x86_64-unknown-linux-gnu", "stable-x86_64-unknown-linux-gnu", "nightly-2022-06-20-x86_64-unknown-linux-gnu", "nightly-2022-08-06-x86_64-unknown-linux-gnu", "nightly-x86_64-unknown-linux-gnu", "1.35.0-x86_64-unknown-linux-gnu", "1.57.0-x86_64-unknown-linux-gnu", "1.58.1-x86_64-unknown-linux-gnu", "1.59.0-x86_64-unknown-linux-gnu", "1.60.0-x86_64-unknown-linux-gnu", "1.61.0-x86_64-unknown-linux-gnu", "1.63.0-x86_64-unknown-linux-gnu", "1.64.0-x86_64-unknown-linux-gnu", "1.65.0-x86_64-unknown-linux-gnu"]

My home dir has 26 projects, so this gets shown 26 times, making the output unreadable.

IMHO the toolchain list should be shown only once if the -i/--installed flag is provided.

Since most likely this tool will get used in CI, it's really optimal to include built binaries in the releases.

and advise users to download binaries in the following way
wget -qO- https://github.com/holmgr/cargo-sweep/releases/download/${VERSION}/cargo-sweep-x86_64-unknown-linux-gnu.tar.gz | tar -xzf-

trunk is an excellent reference to the CI setup for prebuilt binaries.

How to keep only the last build's artifacts without having to rebuild everything?

Was looking into #8 and #9 when I seemed to discover an issue with access times on Windows.
After making sure that NtfsDisableLastAccessUpdate was disabled I did the following.

cargo clean
cargo build
// Now all build artifacts are the latest version, and that only.
cargo sweep -s
cargo build
// Now all build artifacts "should" have been accessed and thus be newer than the timestamp file
cargo sweep -f
// Now everything get removed :(

Will look into this more in the coming days when I have the time as this is quite the serious issue for the windows platform.

$ cargo sweep --help
...
    -t, --time <days>                Number of days backwards to keep. If no value is set uses 30.
...
$ cargo sweep -t
error: The argument '--time <days>' requires a value but none was supplied

USAGE:
    cargo-sweep.exe sweep <--stamp|--file|--time <days>|--installed|--toolchains <toolchains>|--maxsize <maxsize>>

Also it appears that the --version flag doesn't work:

$ cargo sweep -V
cargo-sweep.exe-sweep
$ cargo sweep --version
cargo-sweep.exe-sweep
$ cargo sweep --version -v
cargo-sweep.exe-sweep

I installed with cargo install minutes ago so I have version 0.5.0.

I don't use rustup and I was wondering if this tool could still work without it.

Hi,
support for non-rustup installs has arrived into master, but the released version does not yet contain it.

It would be cool to release a new version containing the support.

Thanks for this useful tool.

Some high profile projects have seen speed ups on CI by removing the final artifacts before caching. Specifically crates.io. However when crater tried a generalized version of this it broke a lot of things.

Plan of attack:

1. use cargo_metadata::Target to get the list of all names to remove.
2. look at cargos code to see how the name is normalized into the file structure. (crates.io is just replacing - with _, but we should make sure that is correct in general.)
3. add a sub command that removes the appropriate files.
4. test that it works on crates.io code.
5. test that it works on several of the crates that broke on crater.

I meant to look at this this past weekend but did not have time. This is mostly notes for when I next have time.

• -d should have --dry-run
• -r should have --recursive
• -v should have --verbose

All three of these long forms are well-established conventions. Amusingly, their short forms are actually not quite so universal. --dry-run is normally -n (for “no action”, I imagine; this is probably worth changing, though of course it’s a breaking change) or may even lack a short form, and --recursive and --verbose are occasionally capitalised where the lowercase was already used for something else (e.g. -v for --version).

I give this as a rule of thumb for CLI design: always start with a long form, and then consider whether to add a short form, erring on the side of not doing so.

What does this line mean?
Does cargo-sweep succeed or not?

Add a dry run flag to the CLI to enable users to preview what would be deleted before actually deleting any files.

Hi,

I everyday update my crate and do cargo sweep -i -r -v ~/.cargo without problems, but today I see this problem:
rustup update && cargo install cargo-update cargo-sweep cargo-todo gitoxide zellij && cargo sweep -i -r -v ~/.cargo
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

stable-x86_64-unknown-linux-gnu unchanged - rustc 1.52.1 (9bc8c42bb 2021-05-09)
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.54.0-nightly (40d230204 2021-05-20)

info: cleaning up downloads & tmp directories
Updating crates.io index
Ignored package cargo-update v7.0.0 is already installed, use --force to override
Ignored package cargo-sweep v0.6.1 is already installed, use --force to override
Ignored package cargo-todo v0.2.0 is already installed, use --force to override
Ignored package gitoxide v0.7.0 is already installed, use --force to override
Ignored package zellij v0.11.0 is already installed, use --force to override
Summary Successfully installed cargo-update, cargo-sweep, cargo-todo, gitoxide, zellij!
thread 'main' panicked at '--time argument missing', /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-sweep-0.6.1/src/main.rs:232:18
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Something changed in cargo-sweep?

How about making dry-run the default mode and instead having a --delete option say to enable actual deletion?

That might be a friendlier approach: generally I like to see the affect of running such a command first before doing the deleting.

(Also in the unix-like world -n is a common short form option for dry-run.)

I think it would be a good small improvement if cargo-sweep emitted a different message for when it cleans 0.00 bytes from a project.

After running this at my $HOME:

$ cargo sweep -t 100 -r

I got this:

[INFO] Cleaned 0.00 bytes from "/home/marcospb19/cargo-sweep/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/code/rust/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/client/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/file-backed-queue/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/gui/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/proto/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/recording-datatypes/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/scoring/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/server/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ds/server-store/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/cacau/target"
[INFO] Cleaned 70.13 KiB from "/home/marcospb19/languages/cocoa/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/dada/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/lalrpop/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/lox/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/rustfmt/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/languages/sushi/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ouch/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/ouch/target/package/ouch-0.4.0/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/rust-skeleton-hexagonal/target"
[INFO] Cleaned 23.63 KiB from "/home/marcospb19/stuff/dotao/target"
[INFO] Cleaned 23.88 KiB from "/home/marcospb19/stuff/fs-tree/target"
[INFO] Cleaned 6.48 GiB from "/home/marcospb19/stuff/keyrocky/target"
[INFO] Cleaned 0.00 bytes from "/home/marcospb19/stuff/reflect/target"
[INFO] Cleaned 3.04 KiB from "/home/marcospb19/stuff/wsid/target"

A lot of lines look like this:

[INFO] Cleaned 0.00 bytes from "/home/marcospb19/cargo-sweep/target"

Instead of "Cleaned 0.00 bytes from", it could tell something like "Did nothing on", "Cleaned nothing from" or "Nothing to do at".

I got some error when installing. Details as follow:

> rustc -V
rustc 1.29.0-nightly (54628c8ea 2018-07-30)

> cargo install cargo-sweep
......
error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  --> src/stamp.rs:24:24
   |
24 |         file.write_all(serde_json::to_string(&self)?.as_bytes())?;
   |                        ^^^^^^^^^^
   |
   = help: add #![feature(extern_prelude)] to the crate attributes to enable

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  --> src/stamp.rs:36:36
   |
36 |         let timestamp: Timestamp = serde_json::from_str(&contents)?;
   |                                    ^^^^^^^^^^
   |
   = help: add #![feature(extern_prelude)] to the crate attributes to enable

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0658`.

Currently, cargo sweep accepts one optional and positional argument as path to the project to sweep.

It would be good to have it accepting multiple paths.

cargo sweep [OPTS] project1 project2 project3

cargo-sweep is already capable of sweeping multiple projects (see --recursive implementation), so this should be easy to implement.

$ cargo install cargo-sweep
Ignored package `cargo-sweep v0.5.0` is already installed, use --force to override
$ cargo sweep -s
$ cat sweep.timestamp
{"secs_since_epoch":1616789097,"nanos_since_epoch":156271000}
$ cargo build
$ cargo sweep -f
cargo sweep [ERROR] Failed to clean "…": second time provided was later than self

Any ideas what went wrong here? I don't see this error message string second time provided was later than self in the source code.

This would allow cleaning of e.g. a project you mostly work with productively but you compile it in debug mode occasionally to fix some bugs or add small features.

The opposite mode would allow cleaning the occasional release build to e.g. benchmark in a project you mostly just develop in debug mode.

cargo sweep -r path leaves the target/<debug>/incremental directory as-is, which can amass a lot of redundant builds. I would expect sweep to clean this directory too.

Add a lastest flag to the CLI to enable cleaning of all build artifacts current not in use by making use of cargo check --message-format=json

cargo-sweep f7e4cfa
rustc 1.47.0-nightly (bf4342114 2020-08-25)
cargo 1.47.0-nightly (51b66125b 2020-08-19)
Windows 10 (19042.450)

Inside the cargo-sweep source directory (or any Rust project) I'm invoking cargo sweep -s and it panicks expecting -t to be provided, but those arguments are incompatible. -t alone seems to work fine, but I can't test -f since the timestamp file can't be created with -s.

This is my first time trying sweep so I'm not sure if this worked in any previous version. I'm also only a Rust user, I can't actually read or write it yet to figure out why it's going down the branch that tries to match against --time.
I included the trace but it doesn't look super helpful. Seems to only apply to the stdlib unless I missed something.

If I can help debug this somehow, let me know and I can try whatever to get more info.

cargo sweep -s
thread 'main' panicked at '--time argument missing', src\main.rs:208:18
stack backtrace:
   0:     0x7ff699c0f6e9 - std::backtrace_rs::backtrace::dbghelp::trace
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
   1:     0x7ff699c0f6e9 - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ff699c0f6e9 - std::sys_common::backtrace::_print_fmt
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\sys_common\backtrace.rs:79
   3:     0x7ff699c0f6e9 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\sys_common\backtrace.rs:58
   4:     0x7ff699c2c2ab - core::fmt::write
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\core\src\fmt\mod.rs:1082
   5:     0x7ff699c0a9b4 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\io\mod.rs:1514
   6:     0x7ff699c125fb - std::sys_common::backtrace::_print
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\sys_common\backtrace.rs:61
   7:     0x7ff699c125fb - std::sys_common::backtrace::print
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\sys_common\backtrace.rs:48
   8:     0x7ff699c125fb - std::panicking::default_hook::{{closure}}
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:200
   9:     0x7ff699c12239 - std::panicking::default_hook
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:219
  10:     0x7ff699c12ddf - std::panicking::rust_panic_with_hook
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:569
  11:     0x7ff699c12945 - std::panicking::begin_panic_handler::{{closure}}
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:476
  12:     0x7ff699c0ff9f - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\sys_common\backtrace.rs:153
  13:     0x7ff699c128f9 - std::panicking::begin_panic_handler
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:475
  14:     0x7ff699c2aa60 - core::panicking::panic_fmt
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\core\src\panicking.rs:85
  15:     0x7ff699c2a7f2 - core::option::expect_failed
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\core\src\option.rs:1213
  16:     0x7ff699b4545e - <alloc::string::String as core::fmt::Display>::fmt::hcd19413c2a09a7f1
  17:     0x7ff699b2d296 - <T as core::any::Any>::type_id::h05d4d92862220c80
  18:     0x7ff699b2d64c - std::rt::lang_start::{{closure}}::h55d0604f7eb97191
  19:     0x7ff699c12fe6 - core::ops::function::impls::{{impl}}::call_once
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\library\core\src\ops\function.rs:280
  20:     0x7ff699c12fe6 - std::panicking::try::do_call
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:373
  21:     0x7ff699c12fe6 - std::panicking::try
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panicking.rs:337
  22:     0x7ff699c12fe6 - std::panic::catch_unwind
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\panic.rs:379
  23:     0x7ff699c12fe6 - std::rt::lang_start_internal
                               at /rustc/bf4342114e357f2934d59e12e31e94532ddb2adf\/library\std\src\rt.rs:51
  24:     0x7ff699b46727 - main
  25:     0x7ff699c33344 - invoke_main
                               at D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  26:     0x7ff699c33344 - __scrt_common_main_seh
                               at D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  27:     0x7fff32b36fd4 - BaseThreadInitThunk
  28:     0x7fff3411cec1 - RtlUserThreadStart

For extra context, I'm trying to integrate this into an update script that updates Rust itself, then goes into each Rust project directory, pulls changes, then tries to rebuild it, using sweep to clean up and make timestamps before and after the build.

up.ps1:

& rustup update

Get-ChildItem -Directory | % {
    Write-Host Target: $_
    Push-Location $_
    & git pull
    & cargo sweep -f
    & cargo install --path="."
    & cargo sweep -s
    Pop-Location
}

It would be nice to see how much disk space is or would be saved by running a sweep. For example, you might keep fewer days (at the cost of more recompiling later) if you really need to save disk space.

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#mtime-on-use

What I mean is, in the README you should mention that this flags needs to be set. It takes a while to debug why it doesn't work, until finally someone on Discard could point me to that flag.

targets has a basic structure. Once you have the directory for a target, a lot of dependencies are kept in hashed folders. I suspect those hashes include the version and feature flags.

• This means for each of those folders, we can bail out at the first file that has too new of an atime.
• We probably want to keep these entire folders rather than delete only part of them

The problem is this becomes more brittle because it becomes dependent on how cargo works.

I expected it to be possible to do a dry-run, then an actual run afterwards, but the dry-run deleted the timestamp file so that the actual run didn't work.

Right now errors seem not to be printed correctly, and cargo-sweep exits with code 0 even on error.

$ cargo sweep --toolchains nightly-2019-13-13 # toolchain that does not exist
[INFO] Using specified installed toolchains: ["nightly-2019-13-13"]
[ERROR] Failed to clean "/project/target":

Running cargo sweep -i -r -d, I get "Would clean XXX MB" for each individual project.

It would be nice to cumulate those savings and display a total at the end.