-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Should modules with path attribute become directory owners automatically? #32401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
No matter what we decide here, I think its important that the following variation continue to work: // main.rs
#[path = "foo.rs"]
mod foo;
fn main() {}
// foo.rs
#[path = "bar.rs"]
mod bar;
// bar.rs
// empty That is, if the developer cares enough about their existing directory layout that they are willing to add (I don't have a strong opinion about disallowing the second form in the issue description.) |
triage: I-nominated |
Why |
I think the answer is that we should not accept this. If a module has a path attribute, it should be a directory owner if the path is a |
Discussed in @rust-lang/lang. Note that if we stop allowing out-of-line submodules from arbitrary named files, a warning period would be required. |
triage: P-medium This doesn't feel super urgent. If we end up keeping the current behavior, we can live with it. |
@KalitaAlexey while it should probably be avoided if possible, |
@Aatch Could you please describe situation when |
@KalitaAlexey for example stdlib uses path in conjunction with |
Help wanted. Just change the parser to disallow the behavior in the OP, add a compile-fail test. We will need to run it through crater to see if anybody depends on this, and maybe have a deprecation period. If people do depend on it, let's just add a test to the test suite and call it expected behavior. |
@jseyfried nice papercut |
Fixed in #37602. |
parser: simplify directory ownership semantics This PR simplifies the semantics of "directory ownership". After this PR, - a non-inline module without a `#[path]` attribute (e.g. `mod foo;`) is allowed iff its parent module/block (whichever is nearer) is a directory owner, - an non-inline module is a directory owner iff its corresponding file is named `mod.rs` (c.f. [comment](#32401 (comment))), - a block is never a directory owner (c.f. #31534), and - an inline module is a directory owner iff either - its parent module/block is a directory owner (again, c.f. #31534), or - it has a `#[path]` attribute (c.f. #36789). These semantics differ from today's in three orthogonal ways: - `#[path = "foo.rs"] mod foo;` is no longer a directory owner. This is a [breaking-change]. - #36789 is generalized to apply to modules that are not directory owners in addition to blocks. - A macro-expanded non-inline module is only allowed where an ordinary non-inline module would be allowed. Today, we incorrectly allow macro-expanded non-inline modules in modules that are not directory owners (but not in blocks). This is a [breaking-change]. Fixes #32401. r? @nikomatsakis
Now how do you create a module in a file that isn't named |
Consider this layout
It generates
cannot declare a new module at this location
error formod bar;
, which is good.However, If I explicitly specify
#[path = ]
formod foo;
it compiles:I don't know if this is expected behavior or not, but it looks suspicious to me .
The text was updated successfully, but these errors were encountered: