MCP: Change path attribute behavior of modules.

Proposal

Summary and problem statement

Change the file lookup rules of path attributes on modules to better align with current Rust module hierarchy organization.

Motivation, use-cases, and solution sketches

Currently path attribute behavior is explained in the two tables in reference. One thing that is not explained on the page is where will mod c 's child module be lookuped at.

#[path = "foo.rs"]
mod c;

////////////
// foo.rs
mod d;

Source File	c’s File Location	c’s Module Path	c’s child file location
src/a/b.rs	src/a/foo.rs	crate::a::b::c	src/a/d.rs
src/a/mod.rs	src/a/foo.rs	crate::a::c	src/a/d.rs

mod inline {
    #[path = "foo.rs"]
    mod c;
}

////////////
// foo.rs
mod d;

Source File	c’s File Location	c’s Module Path	c’s child file location
src/a/b.rs	src/a/b/inline/foo.rs	crate::a::b::inline::c	src/a/b/inline/d.rs
src/a/mod.rs	src/a/inline/foo.rs	crate::a::inline::c	src/a/inline/d.rs

I believe this is due to heritage of edition 2015, where mod c should actually be an mod.rs file if it has non-inline child modules. However this seems really strange under 2018 edition. I hope this could be fixed under 2021 edition.

One possible solution:

• Find mod c’s child modules at the current location only when c is a “mod-rs” source file. Otherwise find its child within “foo” subdirectory.

Another possible solution:

• Always find its child within “foo” subdirectory
• Add a “foo/” (ends with slash) grammar for path attribute, find mod.rs and its children following 2015 edition from there.

Prioritization

• Not very urgent, but current behavior seems inconsistent and changing it is a breaking change, so it might be nice if such changes are done during an edition boundary.

Links and related work

• https://github.com/rust-lang/rust/issues/59345
• https://github.com/rust-lang/reference/issues/573

Initial people involved

<TBD>

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

@crlf0710 we did discuss this latter point: we were wondering if it was even worth trying to make a feature just for this case. That said, the question is— how often do those scenarios arise inside of an inline module? (And how problematic is the current behavior in that case? After all, if one knows what to expect, they can do ../ if desired…)

[nikomatsakis]

The FCP has expired, so I’ve closed the issue. Thanks @crlf0710 for the suggestion.