How to reproduce:
.
โโโ lib.rs
โโโ modname.rs
and lib.rs
looking like this
mod modname;
cargo build
.
โโโ lib.d
โโโ lib.rs
โโโ modname
โย ย โโโ mod.rs
โโโ modname.rs
cargo build
againIn theory, the second cargo build
should start running the build and report the error
error[E0584]: file for module `modname` found at both modname.rs and modname\mod.rs
but no build is started because Cargo thinks everything is up-to-date.
Cargo uses depinfo produced by rustc
to check file freshness and for this example depinfo produced during the first build looks like this
lib.d: lib.rs modname.rs
lib.rs:
modname.rs:
, so Cargo checks lib.rs
and modname.rs
for freshness, but it doesn't know anything modname/mod.rs
.
This can be fixed by issuing additional depinfo - modname/mod.rs
for each modname.rs
, and modname.rs
for each modname/mod.rs
.
The problem is that it will require build systems (including Cargo) spend roughly twice as much time on checking file freshness on rebuilds for all projects, even if none of them does the madness described in the reproduction paragraph.
So, it may be reasonable to close this as WONTFIX.
The issue itself may be esoteric, but I think it's interesting as a glimpse into the world of project structures inferred from filesystem, which is currently discussed in various module system reform proposals.
The "language lawyer" fix for the problem could look like
If
modname.rs
andmodname\mod.rs
both exist it's unspecified which one of them will be used, an error is reported on best effort basis.
Most helpful comment
The "language lawyer" fix for the problem could look like