Skip to content
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

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

Closed
brendanzab opened this issue Jun 4, 2013 · 7 comments · Fixed by #21269
Closed
Assignees
Milestone

Comments

@brendanzab
Copy link
Member

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
Copy link
Member

emberian commented Aug 5, 2013

The test still passes

@emberian
Copy link
Member

Visiting for triage. Nominating for backwards compat.

@pnkfelix
Copy link
Member

accepted for P-backcompat-lang

@alexcrichton
Copy link
Member

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

@aturon
Copy link
Member

aturon commented Jan 8, 2015

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

@pnkfelix
Copy link
Member

pnkfelix commented Jan 8, 2015

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

@pnkfelix pnkfelix added this to the 1.0 beta milestone Jan 8, 2015
@nrc
Copy link
Member

nrc commented Jan 8, 2015

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

@alexcrichton alexcrichton self-assigned this Jan 16, 2015
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 19, 2015
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.

[breaking-change]
Closes rust-lang#6936
bors added a commit that referenced this issue Jan 19, 2015
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.

[breaking-change]
Closes #6936
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
Refactor types

r? `@flip1995`
This is the last PR to close rust-lang#6724 🎉
Also, this fixes rust-lang#6936.

changelog: `vec_box`: Fix FN in `const` or `static`
changelog: `linkedlist`: Fix FN in `const` or `static`
changelog: `option_option`: Fix FN in `const` or `static`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants