libsyntax: Restrict where non-inline modules can appear (fixes #29765) #31534
Conversation
jseyfried
force-pushed
the
restrict_noninline_mod
branch
12 times, most recently
from
6ce1e4d
to
69f3a1b
Compare
|
Disallowing non-inline modules in blocks broke This doesn't look like it is a common pattern, but it may be a good idea to do a crater run to be sure. We could continue allowing non-inline modules in blocks (unless the containing file is not a directory owner, which would still be enforced by my first commit) or make it a warning/lint. I don't have a strong opinion on this issue, but it looks like the consensus in #29765 was to disallow non-inline modules in blocks. |
|
Should we do a crater run do you think? |
|
Or -- alternatively -- just start out with added a lint. |
|
(Seems like it's prob not needed here though.) |
|
OK well I kicked off a crater run just for kicks. This patch looks good though. r=me once the crater run is done. |
nikomatsakis
added
relnotes
|
cc @brson -- this is a bug fix but a breaking change, I'm not sure what tags we were supposed to use but I added some :) |
|
I got one regression from a crater run: https://gist.github.com/nikomatsakis/f30f5a095b4576411201 (cargo) |
|
@bors r+ |
|
📌 Commit 69f3a1b has been approved by |
|
:( |
|
I wrote a PR for cargo to fix the regression. |
|
☔ The latest upstream changes (presumably #31358) made this pull request unmergeable. Please resolve the merge conflicts. |
…n a directory owner
jseyfried
force-pushed
the
restrict_noninline_mod
branch
from
69f3a1b
to
d21e908
Compare
|
@nikomatsakis rebased |
|
@nikomatsakis Do you still want to merge this? |
|
@jseyfried sorry, didn't see the problem, yes I would like to merge |
I can't tell how to interpret this smiley... |
|
Ah yes, I can clarify! I saw that only Cargo was mentioned, and that felt like Cargo got some sort of prize or something, so I felt compelled to comment. After seeing the prize it won, however, I deleted the half-written essay of acceptance and felt compelled to continue writing something, so I settled for an emoticon, and ":(" seemed appropriate at the time. In other words, I wouldn't try to interpret :) |
|
@bors r+ |
|
📌 Commit d21e908 has been approved by |
|
⌛ Testing commit d21e908 with merge 45652d9... |
|
@bors: retry force |
This PR disallows non-inline modules without path annotations that are either in a block or in an inline module whose containing file is not a directory owner (fixes #29765). This is a [breaking-change]. r? @nikomatsakis
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
This PR disallows non-inline modules without path annotations that are either in a block or in an inline module whose containing file is not a directory owner (fixes #29765).
This is a [breaking-change].
r? @nikomatsakis