Type aliases and mods of the same name in the same namespace should be forbidden

[brendanzab]

The tests for this crate compile ok:

#[link(name = "complex", vers = "test")];
#[crate_type = "lib"];

pub struct ComplexT<T> { x: T, y: T, z: T }

impl<T> ComplexT<T> {
    pub fn new(x: T, y: T, z: T) -> ComplexT<T> {
        ComplexT { x: x, y: y, z: z }
    }
}

pub type Complex32 = ComplexT<f32>;

pub mod Complex32 {
    use super::*;
    pub fn new(x: f32, y: f32, z: f32) -> Complex32 {
        ComplexT::new(x, y, z)
    }
}

#[test]
fn test_Complex() {
    let v = Complex32::new(1.0, 2.0, 3.0);
    println(fmt!("%?", v));
}

This is incompatible with #6894, and should probably be forbidden.

[emberian]

The test still passes

[emberian]

Visiting for triage. Nominating for backwards compat.

[pnkfelix]

accepted for P-backcompat-lang

[alexcrichton]

cc @aturon and rust-lang/rfcs#195, this looks like it may have interesting interactions with associated items and/or UFCS

[aturon]

Nominating. This was marked P-backcompat-lang but not previously placed on a milestone. Do we need to do something here for beta?

[pnkfelix]

assigning to 1.0-beta milestone: we need to make a decision here and firm up our story about the namespace conflicts.

[nrc]

Note that currently other types and modules don't clash, so that might be a bug too.