Do not allow a module and tuple struct of the same name to coexist.

[nham]

Fixes #21546.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

This is unfortunately a breaking change, so we need to be sure to tread carefully here (especially in resolve).

cc @rust-lang/lang, @nrc, I forget if cases like this were intentional or not?
cc @brson, perhaps a crater run to see if this causes compiles to fail?

[brson]

I've started this on crater.

[pnkfelix]

given that [RFC 218]("empty struct with braces") was accepted, it would probably be a good idea to have both this test and a separate one of non-empty tuple structs, since I expect the code paths for how the two are handled to diverge somewhat in the future.

[nham]

done

[pnkfelix]

@alexcrichton asked:

cc @rust-lang/lang, @nrc, I forget if cases like this were intentional or not?

I'm pretty sure this was an oversight. Every kind of struct definition puts an entry into the type namespace (while only some put an entry into the value namespace, but this is not relevant). The collision at the type namespace level is what is problematic.

In other words, this errors today:

mod Foo {}
struct Foo { x: i32 }

fn main() {}

so there's no reason for these to be succeeding:

mod Foo {}
struct Foo(i32);

fn main() {}

and

mod Foo {}
struct Foo;

fn main() {}

[pnkfelix]

Here is a more concrete example of a problematic program this bug is exposing:

#[allow(non_snake_case)]
mod Foo { pub fn foo() -> i32 { 4 } }

struct Foo(i32);
impl Foo { fn foo() -> i32 { 3 } }

fn main() { println!("foo: {}", Foo::foo()); } // what does this print?

[pnkfelix]

Having said that, its not a soundness issue to my knowledge.

Fixing it would not break code that is following "usual" style conventions about struct and module names, but otherwise it is indeed a breaking change.

Does it qualify as a course correction, or just a bug fix? We could certainly employ the #[legacy(...)] flag idea here, I would imagine, but is it called for here, is my question. See also the recently accepted RFC 1122.

[nrc]

This was not intentional. I think it is definitely a bug fix, not a course correction or 'proper' breaking change.

[brson]

crater says no regressions

[alexcrichton]

Tagging with T-lang and I-nominated, just getting some broader visibility (and will be dealt with during triage)

[pnkfelix]

Similarly to #27026 (which was specifically mentioned during the last lang team meeting, where the response was "warning cycle first, then release the breaking change"), I am again wondering whether this needs to go through a warning cycle or not.

I interpret @nrc above as saying "no, it does not need a warning cycle." But if that is the case, then why apply a different policy to #27026 ? Are these two cases all that different?

cc @rust-lang/lang

[nrc]

I think it could (and probably should) get a warning cycle. I don't think it should get a legacy flag or anything more permanent than a warning cycle.

[nham]

So under this policy, does the change in #25993 need to be reverted and have a warning cycle added? The following program used to compile pre-patch, but does not after:

trait Foo {
    type Ty;
}

impl Foo for () {
    type Ty = ();
    type Ty = usize;
}

fn main() { 
    let _: <() as Foo>::Ty = ();
}

[nikomatsakis]

Triage: removing I-nominated as we've taken a look. Seems like a warning cycle makes sense, given how widely used tuple structs and modules are. With respect to #25993, I think we can let that go --- istm that overlap there is less likely, and of course we'll see if crater picks up anything.

[alexcrichton]

ping? @nham would you be ok implementing a warning for this change?

[bors]

☔️ The latest upstream changes (presumably #28816) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

Re assigning to myself, I will try to revise with warning cycle support if we see no response from @nham

[nham]

Sorry, I've been busy the past couple of weeks. I have some time to look at it this week, but I still need to figure out how the warning cycles work, so if you want to take it @pnkfelix that's okay with me.

[pnkfelix]

@nham oh I have plenty of other stuff on my plate, so you've got time to look at it this week if you like. :)

[nham]

I've made an attempt at adding warnings. The warnings address both the original issue and another issue mentioned by @james-darkfox in #29185, which is that programs like this currently compile:

struct Foo { x: i32 }
mod Foo { }
fn main() {}

This is slightly different from the original issue because it is allowed only when the module comes after the struct, and also because it works for all structs, not just unit/tuple structs.

I wasn't sure what to put for the warning message. Looking for feedback here!

[james-darkfox]

@nham Sidenote: I'm "abusing" this bug in #29182 due to a limitation in the test cases. Here in the module I have my #[test] fn .... My point here is that although this is a bug, it is a useful one until the #[test] cases can be implemented in impl blocks.

[pnkfelix]

Seems a shame to clone the child; I would have thought there was a way to structure this to avoid that.

[pnkfelix]

should we consider allocating a error number now for this?

I guess it can wait until we promote the warning into a proper error, since I don't know if our error number policy would allow us to reuse the same number for the warning and the error it is later promoted into.

[pnkfelix]

@nham this looks fine to me, apart from the clone, which I assume you tried to avoid and I must just be missing some reason why you found it necessary

[pnkfelix]

@bors r+

[bors]

📌 Commit f0af1eb has been approved by pnkfelix

[bors]

⌛️ Testing commit f0af1eb with merge a1e2a55...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt