-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
syntax: Tighten search paths for inner modules #14251
Conversation
if !self.owns_directory { | ||
self.span_err(id_sp, | ||
"cannot declare a new module at this location"); | ||
let this_module = match self.mod_path_stack.last() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When does the self.module_name
branch get taken? I.e. shouldn't mod_path_stack
always have the current module at the end?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see, it's just used for the recursive parse thing. Shouldn't the recursive parser just push to mod_path_stack
? (If not, could module_name
be changed to be called something slightly less general?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some comments to the field and renamed to root_module_name
. The recursive parser doesn't share the parent's mod_path_stack
, and pushing onto the stack would mess with further mod foo;
declarations (appending an extra component on the path).
This is an implementation of RFC 16. A module can now only be loaded if the module declaring `mod name;` "owns" the current directory. A module is considered as owning its directory if it meets one of the following criteria: * It is the top-level crate file * It is a `mod.rs` file * It was loaded via `#[path]` * It was loaded via `include!` * The module was declared via an inline `mod foo { ... }` statement For example, this directory structure is now invalid // lib.rs mod foo; // foo.rs mod bar; // bar.rs; fn bar() {} With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`, and can only be accessed through `foo`. RFC: 0016-module-file-system-hierarchy Closes rust-lang#14180 [breaking-change]
This is an implementation of RFC 16. A module can now only be loaded if the module declaring `mod name;` "owns" the current directory. A module is considered as owning its directory if it meets one of the following criteria: * It is the top-level crate file * It is a `mod.rs` file * It was loaded via `#[path]` * It was loaded via `include!` * The module was declared via an inline `mod foo { ... }` statement For example, this directory structure is now invalid // lib.rs mod foo; // foo.rs mod bar; // bar.rs; fn bar() {} With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`, and can only be accessed through `foo`. RFC: 0016-module-file-system-hierarchy Closes #14180 [breaking-change]
internal: Set expectation for no-semi expression statements to unit
…ykril fix: unify types in `infer_expr_coerce_never()` Fixes rust-lang#14506 rust-lang#14506 turned out to be a regression in type inference. `infer_expr_coerce_never()` added in rust-lang#14251 allows never-to-any coercion but should also perform ordinary type unification in other cases.
This is an implementation of RFC 16. A module can now only be loaded if the
module declaring
mod name;
"owns" the current directory. A module isconsidered as owning its directory if it meets one of the following criteria:
mod.rs
file#[path]
include!
mod foo { ... }
statementFor example, this directory structure is now invalid
With this change
foo.rs
must be renamed tofoo/mod.rs
, andbar.rs
must berenamed to
foo/bar.rs
. This makes it clear thatbar
is a submodule offoo
,and can only be accessed through
foo
.RFC: 0016-module-file-system-hierarchy
Closes #14180
[breaking-change]