cargo-miri fails when cargo uses argfiles

[nazar-pc]

I just tried upgrading from nightly-2026-07-22 to nightly-2026-07-31 and on Windows specifically one of the crates produced this surprising set of errors:

error[E0463]: can't find crate for `libp2p`
 --> crates\shared\ab-networking\src\protocols\autonat_wrapper.rs:2:5
  |
2 | use libp2p::autonat::{Behaviour as Autonat, Config as AutonatConfig, Event as AutonatEvent};
  |     ^^^^^^ can't find crate

error[E0463]: can't find crate for `tracing`
  --> crates\shared\ab-networking\src\protocols\autonat_wrapper.rs:13:5
   |
13 | use tracing::debug;
   |     ^^^^^^^ can't find crate

error[E0463]: can't find crate for `void`
 --> crates\shared\ab-networking\src\protocols\reserved_peers\handler.rs:5:5
  |
5 | use void::Void;
  |     ^^^^ can't find crate

...

CI run: https://github.com/nazar-pc/abundance/actions/runs/30605181115/job/91075860190?pr=747
And the commit with toolchain update: nazar-pc/abundance@243f243

But nothing has changed in terms of dependencies, Linux and macOS are unaffected and older toolchain was fine too.

I kind of suspect this might be related to rust-lang/cargo#17258, but I didn't dig into it yet and I'm running Linux, so cross-compiling is a bit difficult with crates like ring unfortunately.

[RalfJung]

Is it possible for you to bisect this down to a specific nightly where things regressed?

I kind of suspect this might be related to rust-lang/cargo#17258, but I didn't dig into it yet and I'm running Linux, so cross-compiling is a bit difficult with crates like ring unfortunately.

We are using the new build dir layout in our CI here, so it should work, even on Windows... but maybe there's something specific to your dependency tree that causes trouble. A smaller reproducer would help nail this down.

[nazar-pc]

nightly-2026-07-31 is the first broken nightly, nightly-2026-07-30 works fine. I tried to reduce the example, but at least on Linux machine wasn't able to. It might be that having ring in the dependencies is crucial and without it I can't reproduce on Linux, or maybe it is host-specific.

cd crates\shared\ab-networking && cargo miri t should be sufficient at nazar-pc/abundance@243f243.

[RalfJung]

nightly-2026-07-31 is the first broken nightly, nightly-2026-07-30 works fine.

Thanks!
Do you have the rustc -V output for both of these? (Mostly I am looking for the exact commits.)

[nazar-pc]

rustc 1.99.0-nightly (1a833e165 2026-07-29)
rustc 1.99.0-nightly (8ab9fdff5 2026-07-30)

[bjorn3]

rust-lang/rust#159857 maybe? In particular rust-lang/cargo#17272. Does it work with __CARGO_TEMPORARY_BUILD_DIR_NEW_LAYOUT_OPT_OUT=1?

[nazar-pc]

Does it work with __CARGO_TEMPORARY_BUILD_DIR_NEW_LAYOUT_OPT_OUT=1?

Yes, it does

[RalfJung]

That's rust-lang/rust@1a833e1...8ab9fdf.

So yeah it's probably the cargo update. But apparently it's something that our CI doesn't catch. Or does the export CARGO_UNSTABLE_BUILD_DIR_NEW_LAYOUT=true we have in CI not do anything any more?
Cc @weihanglo

[RalfJung]

Do you have any non-default setup on your CI, like a non-default cargo target dir or anything like that?

[weihanglo]

Okay. First victim 😞.

Thanks for the ping and the investigation. Let me take a look.

cc @ranger-ross

[nazar-pc]

Do you have any non-default setup on your CI, like a non-default cargo target dir or anything like that?

You can inspect the complete workflow and environment variables used in the CI run I linked originally. In that particular case the default target directory is used with incremental compilation disabled. I do set up an interceptor for Miri commands as described here, but it only affects running tests, not initial compilation.

I'll try to narrow it down later.