Modules loaded using #[path] are seemingly treated like mod.rs files even when they're not

[ilyvion]

Assume the following file structure:

src
  bin
    foo.rs
  bar
    baz.rs
  bar.rs
  main.rs

where bar.rs has a mod baz; in it.

When doing

mod bar;

in main.rs, everything works like expected. The bar module is loaded from bar.rs and its baz module gets loaded from bar/baz.rs. Smooth sailing.

Now try adding

#[path = "../bar.rs"]
mod bar;

to bin/foo.rs. What I expected was that this would behave exactly identical to mod bar in main.rs; after all, I've just changed the implicit location of bar.rs to an explicit one.

Instead, this happens:

error[E0583]: file not found for module `baz`
 --> src\bin\..\bar.rs:1:1
  |
1 | mod baz;
  | ^^^^^^^^
  |
  = help: to create the module `baz`, create file "src\bin\..\baz.rs" or "src\bin\..\baz\mod.rs"

For more information about this error, try `rustc --explain E0583`.

Why is it looking for src\bin\..\baz.rs? It should be looking for src\bin\..\bar\baz.rs, since bar.rs is not a root module like lib.rs or main.rs, nor is it a mod.rs file.

If this behavior is expected, it's not very well documented, I certainly couldn't find anything explaining this behavior in the documentation.

Meta

rustc --version --verbose:

rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-pc-windows-msvc
release: 1.65.0
LLVM version: 15.0.0

[ehuss]

I believe this is the behavior that has been around I think since path has been around (or if not, at least since the 2018 edition). Modules loaded from a path included module will be located relative to that path's location.

There is an open issue at rust-lang/reference#573 for updating the documentation.

[Enselic]

Triage: Thanks for reporting. Let's close as duplicate to rust-lang/reference#573 however.

[ilyvion]

It's too bad that the intended resolution to this issue will be "we'll leave it as is, and just document it" instead of fixing it, because this behavior makes the attribute much less useful, since, as I showed in my original report, the expected module resolution behavior breaks.

mod bar, whether annotated with #[path] or not, should be able to find its inner mod baz in the same place, not in two different places based on the scenario. If it isn't bar\baz.rs in both cases, you can't easily make "reusable" modules when module resolution is inconsistent like this.

[Enselic]

If you strongly disagree with closing as duplicate, let's reopen. Changes to the mod system is likely required to go through the RFC process though.

[ilyvion]

That makes sense. If I had the spoons to do it myself, I would draft up an RFC, but for various personal reasons, I don't have that in me right now. It's probably not something many people need or care about, though, so it probably won't go anywhere without my efforts.