Dependency info issue for modules loaded from files with mod modname;

[petrochenkov]

How to reproduce:

• Create a Cargo project with source tree looking like this

.
├── lib.rs
└── modname.rs

and lib.rs looking like this

mod modname;

• run cargo build
• add a new directory and file so the source tree becomes

.
├── lib.d
├── lib.rs
├── modname
│   └── mod.rs
└── modname.rs

• run cargo build again

---

In 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.

[petrochenkov]

The "language lawyer" fix for the problem could look like

If modname.rs and modname\mod.rs both exist it's unspecified which one of them will be used, an error is reported on best effort basis.

[Enselic]

So, it may be reasonable to close this as WONTFIX.

Triage: No one argued against this for 6 years, so let's close as WONTFIX .