Non-inline module is allowed inside other items

[huonw]

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.

static X: u8 = { mod foo; 0 };
fn foo() {
    mod foo;
}
fn main() {
    mod foo;
}

As one might expect, each of these is a distinct instance of foo (which can be verified by placing log_syntax(hello) in foo.rs: the compiler will greet you 3 times).

Noticed in https://users.rust-lang.org/t/are-module-declarations-allowed-inside-functions/3583 .

[nikomatsakis]

This seems weird to me. I think the intention is that the out-of-line syntax (mod foo;) should only work at the top-level.

[aturon]

I'd vote for allowing non-inline modules only at the top-level, to retain a clear mapping to the file system.

[nikomatsakis]

(Or nested inside modules.)

[nikomatsakis]

triage: P-medium

Backwards incompatible, but ... kind of a curiousity.

[matklad]

Found one more mod aliasing scenario. It involves several files, and is semi officially allowed by the reference.

The layout

src/
├─ bar.rs
├─ foo.rs
├─ inner
│  └── copy.rs
└─ main.rs

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 foo and bar are not directory owners, their inner modules are.

[matklad]

Upon reflecting more about this, I think that there are two questions here.

• should non inline modules be allowed (syntactically) inside items?
• should module aliasing (the same file representing two modules in the crate) be allowed?

The questions are independent because you can use #[path = ] attribute to create module aliasing manually.

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.

[nikomatsakis]

@matklad

I tend to believe it is fine to have aliasing if you write the #[path] yourself (you asked for it...), and that it would be ok to put a non-inline module inside an non-module, if you specify the path yourself, but that we should error out otherwise. However, there has definitely been confusion in the past about the role of mod as a declaration and not a use, and disallowing aliasing would prevent that confusion from leading to incorrect trees.

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 mod inner { mod copy; } to (by default) be found at foo/inner/copy. What happens if you don't have the mod inner, but just place mod copy in foo?

[matklad]

What happens if you don't have the mod inner, but just place mod copy in foo?

It is forbidden because foo is not a directory owner.

[matklad]

Just in case here is a repository with the example: https://github.com/matklad/nested-mod

I tend to believe it is fine to have aliasing if you write the #[path] yourself (you asked for it...)

I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical path attributes (copy paste problem)?

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.

[nikomatsakis]

@matklad

It is forbidden because foo is not a directory owner.

Ah, I see. So it seems to me that the problem is that mod inner { mod copy; } should not be allowed in contexts where mod copy; would be illegal. In other words, an inline module should only be considered a "directory owner" if it is located within a directory owner.

I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical path attributes (copy paste problem)?

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 #[path] lightly or frequently, so this seems unlikely to be a major source of confusion.

[matklad]

so this seems unlikely to be a major source of confusion.

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.