Running `cargo build` after fresh clone generates numerous untracked `target/` and `Cargo.lock` files in tests, cluttering `git status`

[baoyachi]

Problem

Description

When cloning the Cargo repository and running cargo build for the first time, it generates a large number of untracked files and directories (primarily Cargo.lock files and target/ directories) within the tests/testsuite/cargo_add/ subdirectories. These files are not managed by Git, which makes git status output very noisy and interferes with debugging workflows, as it clutters the view of actual changes.

This seems to occur because the build process (possibly during compilation of tests or integration test setup) generates lockfiles and build artifacts in the test input directories (in/ folders), but these are not cleaned up or ignored by default.

Steps to Reproduce

1. Clone the repository: git clone https://github.com/rust-lang/cargo.git
2. Navigate to the repo: cd cargo
3. Run cargo build (or cargo b for short).
4. Run git status to observe the clutter.

Expected Behavior

• Not be generated during a simple cargo build (if they're only needed for running tests).
• Be automatically cleaned up after the build.
• Be added to .gitignore to prevent them from appearing as untracked.
• git status should remain clean (or show only relevant changes) after a fresh build.

Actual Behavior

After cargo build, git status shows dozens of untracked files, mostly in paths like:

• tests/testsuite/cargo_add/[test-name]/in/Cargo.lock
• tests/testsuite/cargo_add/[test-name]/in/target/
• And similar for dependency/primary/ subdirs.

Output from git status

On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   tests/testsuite/cargo_add/normalize_name_path_existing/in/Cargo.lock

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        tests/testsuite/cargo_add/dev_existing_path_base/in/dependency/Cargo.lock
        tests/testsuite/cargo_add/dev_existing_path_base/in/dependency/target/
        tests/testsuite/cargo_add/dev_prefer_existing_version/in/dependency/Cargo.lock
        tests/testsuite/cargo_add/dev_prefer_existing_version/in/dependency/target/
        tests/testsuite/cargo_add/feature_suggestion_multiple/in/Cargo.lock
        tests/testsuite/cargo_add/feature_suggestion_multiple/in/target/
        tests/testsuite/cargo_add/feature_suggestion_none/in/Cargo.lock
        tests/testsuite/cargo_add/feature_suggestion_none/in/target/
        tests/testsuite/cargo_add/feature_suggestion_single/in/Cargo.lock
        tests/testsuite/cargo_add/feature_suggestion_single/in/target/
        tests/testsuite/cargo_add/features_activated_over_limit/in/Cargo.lock
        tests/testsuite/cargo_add/features_activated_over_limit/in/target/
        tests/testsuite/cargo_add/features_deactivated_over_limit/in/Cargo.lock
        tests/testsuite/cargo_add/features_deactivated_over_limit/in/target/
        ...
        ...
        tests/testsuite/cargo_add/path/in/primary/target/
        tests/testsuite/cargo_add/path_base/in/dependency/Cargo.lock
        tests/testsuite/cargo_add/path_base/in/dependency/target/

no changes added to commit (use "git add" and/or "git commit -a")

Possible Workarounds

• Manually run git clean -fd to remove untracked files (but this is destructive and not ideal for ongoing development).
• Add patterns like tests/testsuite/cargo_add/**/target/ and tests/testsuite/cargo_add/**/Cargo.lock to .gitignore.

This issue makes initial setup and debugging more cumbersome. Any guidance on why this happens during cargo build (and not just cargo test) would be appreciated!

Proposed Solution

No response

Notes

No response

[epage]

I'm not able to reproduce this, either with cargo build or cargo test. I wonder whats different.

[ehuss]

Can you say if you have any kind of IDE (or something similar) running that might be scanning the directory in the background? I have not seen this before, either.

[baoyachi]

@ehuss Rustrover. 2025.2.3

[weihanglo]

Can't reproduce with fresh installed RustRover fresh cloned cargo repo on macOS with 1.90 toolchain.

[baoyachi]

@weihanglo By the way, The current environment is in Macos