Copy excluding .gitignore files causes failure without --in-place

[ASuciuX]

Hello @sourcefrog, hope you’re doing well!

I’ve seen some great updates since I last implemented cargo-mutants in different workflows.

I ran into an issue where cargo-mutants fails when working with a copied version of the project. The error appears to be a binding issue—multiple dependencies rely on the same library but with different versions, causing cargo build to be unable to resolve them correctly. However, using the --in-place flag works fine.

I haven’t fully investigated the root cause or a potential underlying solution, but I found that using --in-place is preferable for CI regardless. The main concern is that, locally, running cargo-mutants requires a cloned version of the repository, which isn’t ideal. Given this, I wanted to open this issue and share my findings, especially since I noticed specified in the documentation to also share cases like this.

Here’s the failing CI action log when running cargo-mutants without --in-place: https://github.com/hirosystems/ordhook/actions/runs/13164203008/job/36740241226#step:9:986

And here’s a related discussion on the dependency issue: https://github.com/hirosystems/ordhook/issues/395

[sourcefrog]

Hi @ASuciuX

This sounds like https://github.com/sourcefrog/cargo-mutants/issues/117 but I guess you are already using >25.0.0 that includes that fix?

If you can narrow this down to a specific failure that will help.

Some things to try:

1. If you manually copy the tree with cp -r does it work?
2. If you manually copy the tree and then delete target does it work?

[ASuciuX]

Yes, I am using 25.0.0.

1. The copy containing the target still fails without --in-place. and works with --in-place`.
2. Same

I've copied the codebase to a random user location. Should I copy it to a temp root location?

[sourcefrog]

I haven’t fully investigated the root cause or a potential underlying solution, but I found that using --in-place is preferable for CI regardless.

Separately from this bug: yes, that is better for CI. There's no point spending time copying to a temp directory if the source is itself a disposable temp directory.

[sourcefrog]

• The copy containing the target still fails without --in-place and works with --in-place.

Interesting. If it's not the copying then I guess the problem is with the manifest and cargo config fixups done in https://github.com/sourcefrog/cargo-mutants/blob/main/src/manifest.rs after the copy.

https://github.com/sourcefrog/cargo-mutants/blob/8c9f6487a4a4ca55b0e6578662c03040daab5db9/src/build_dir.rs#L55-L77

A good next step would be to find the specific failing cargo command and its output.

[sourcefrog]

OK the failure is pretty apparent in https://github.com/hirosystems/ordhook/actions/runs/13164203008/job/36740241226#step:9:986,

--> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/p256k1-7.2.2/src/_rename.rs:10:5 error[E0432]: unresolved imports crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_clone, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_clone_size, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_create, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_destroy, crate::bindings::s2bca0a5cbf756dd4ff1f0bda4585a7d3c64e1480_secp256k1_context_preallocated_size

These names come from https://github.com/Trust-Machines/p256k1/blob/master/p256k1/src/bindings.rs

I notice that in this tree, src/bindings.rs is both checked in, and also in .gitignore. By default cargo-mutants skips gitignored files, so that might be what's breaking it.

I would try with --gitignore=false and that will probably fix it? At least, let me know?

https://github.com/Trust-Machines/p256k1 itself seems to run OK under mutants, although finding some gaps.

[sourcefrog]

#454 says we perhaps shouldn't skip gitignored files by default, because it saves a bit of time copying but might cause confusing errors when the tree depends on gitignored files. Maybe this is more evidence for it.

[ASuciuX]

Nice, thank you! It works with --gitignore=false. Indeed it was because of that bindings.

How does it skip the gitignored files? Doesn’t it copy them to the temporary runs after building the project?

[sourcefrog]

With --gitignore=true (currently the default) it just does not copy them into the temp dirs:

https://github.com/sourcefrog/cargo-mutants/blob/debd7cbb5e8a95353e008246139333aacc8269a3/src/copy_tree.rs#L46-L60

[ASuciuX]

Thank you

[sourcefrog]

gitignore filtering is now off by default (through #454) so I think this is closed.