Non-inline module is allowed inside other items #29765
Comments
huonw
added
A-parser
|
This seems weird to me. I think the intention is that the out-of-line syntax ( |
|
I'd vote for allowing non-inline modules only at the top-level, to retain a clear mapping to the file system. |
|
(Or nested inside modules.) |
|
triage: P-medium Backwards incompatible, but ... kind of a curiousity. |
|
Found one more mod aliasing scenario. It involves several files, and is semi officially allowed by the reference. The layout The files //main.rs
mod foo;
mod bar;
fn main() {}
//foo.rs
mod inner { mod copy; }
//bar.rs
mod inner { mod copy; }The copy module will be aliased. The problem is that although |
When we see `mod foo;` we should try to find a file corresponding to
`foo`. It is possible only if a parent module is a directory owner.
A module is a directory owner if it is either
* a crate root
* a nested inline module
* called `mod.rs`
It is an error to have `mod foo;` in a non directory owning module.
The file name for `foo` is (modulo #[path = ] attribute) a directory
name of the parent module plus either `/foo.rs` or `/foo/mod.rs`.
Example 1
```Rust
// file src/main.rs, a crate root
mod foo; // src/foo.rs
mod inner {
mod foo; // src/inner/foo.rs
}
```
Example 2
```Rust
// file src/foo.rs
mod bar; // forbidden
mod inner {
mod foo; // src/inner/foo.rs
}
```
The semantics of `mod foo;` nested inside a function is not fully
specified at the moment: rust-lang/rust#29765
When we see `mod foo;` we should try to find a file corresponding to
`foo`. It is possible only if a parent module is a directory owner.
A module is a directory owner if it is either
* a crate root
* a nested inline module
* called `mod.rs`
It is an error to have `mod foo;` in a non directory owning module.
The file name for `foo` is (modulo #[path = ] attribute) a directory
name of the parent module plus either `/foo.rs` or `/foo/mod.rs`.
Example 1
```Rust
// file src/main.rs, a crate root
mod foo; // src/foo.rs
mod inner {
mod foo; // src/inner/foo.rs
}
```
Example 2
```Rust
// file src/foo.rs
mod bar; // forbidden
mod inner {
mod foo; // src/inner/foo.rs
}
```
The semantics of `mod foo;` nested inside a function is not fully
specified at the moment: rust-lang/rust#29765
When we see `mod foo;` we should try to find a file corresponding to
`foo`. It is possible only if a parent module is a directory owner.
A module is a directory owner if it is either
* a crate root
* a nested inline module
* called `mod.rs`
It is an error to have `mod foo;` in a non directory owning module.
The file name for `foo` is (modulo #[path = ] attribute) a directory
name of the parent module plus either `/foo.rs` or `/foo/mod.rs`.
Example 1
```Rust
// file src/main.rs, a crate root
mod foo; // src/foo.rs
mod inner {
mod foo; // src/inner/foo.rs
}
```
Example 2
```Rust
// file src/foo.rs
mod bar; // forbidden
mod inner {
mod foo; // src/inner/foo.rs
}
```
The semantics of `mod foo;` nested inside a function is not fully
specified at the moment: rust-lang/rust#29765
|
Upon reflecting more about this, I think that there are two questions here.
The questions are independent because you can use I would prefer if the answer to the second question is not. I'm contributing to the Rust plugin for IntelliJ IDEA, and one of the tasks there is mapping files to modules (for example, to go to the parent module). I would much prefer just to highlight module aliasing as an error, rather then to deal with non one-to-one mapping between files and modules. As a side note, if a user does want aliasing for some reason, she can always use symbolic link for the same effect. |
|
I tend to believe it is fine to have aliasing if you write the Your example however is disconcerting, and suggests that perhaps the code has a slightly different model in mind than I do in my head. :) That is, I strongly expect |
It is forbidden because |
|
Just in case here is a repository with the example: https://github.com/matklad/nested-mod
I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical My main concern though is that non injective file to module mapping may complicate the implementation of some rust tools. Here is another hypothetical example of this. Suppose you implement incremental compilation for rustc. You will need a mapping from files to modules. If mod aliasing is alowed, then you will need a multimapping. So you end up with more complex code which is used only in a tiny fraction of projects and because of this probably contains some bugs. |
Ah, I see. So it seems to me that the problem is that
A compromise might be Yet Another Lint Warning. ;) I agree with you about preventing people from shooting themselves in the leg, but I guess I think people don't use |
I totally agree that this curiosity is insignificant for users. But I still worry more about the implementation side of the issue, and a lint warning does not help here. |
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
Fix conflicting link identifiers Caused "Errors for non-exhaustive match patterns now list up to 3 missing variants while also indicating the total number of missing variants if more than 3." to link to "libsyntax: Restrict where non-inline modules can appear (fixes rust-lang#29765)"
These are all legal, and somewhat strange, since they're not really following the file-system analogy that modules are typically explained with. I expect this behaviour is just whatever happens to fall out of the current implementation strategy, so let's make a more explicit decision one way or another.
As one might expect, each of these is a distinct instance of
foo(which can be verified by placinglog_syntax(hello)infoo.rs: the compiler will greet you 3 times).Noticed in https://users.rust-lang.org/t/are-module-declarations-allowed-inside-functions/3583 .
The text was updated successfully, but these errors were encountered: