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

enum struct variants can mask regular struct constructors #5792

Closed
erickt opened this issue Apr 9, 2013 · 6 comments
Closed

enum struct variants can mask regular struct constructors #5792

erickt opened this issue Apr 9, 2013 · 6 comments
Labels
A-resolve Area: Name resolution

Comments

@erickt
Copy link
Contributor

erickt commented Apr 9, 2013

@thestinger found this odd bug. This code:

enum Foo { C { a: int, b: int } }
struct C { a: int, b: int }
fn main() { }

properly errors out with:

test.rs:2:0: 2:27 error: duplicate definition of type C
test.rs:2 struct C { a: int, b: int }
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
test.rs:1:11: 1:31 note: first definition of type C here:
test.rs:1 enum Foo { C { a: int, b: int } }
                     ^~~~~~~~~~~~~~~~~~~~

However, if you swap the enum and struct definition, it compiles fine with rust HEAD:

struct C { a: int, b: int }
enum Foo { C { a: int, b: int } }
fn main() { }
@pnkfelix
Copy link
Member

still reproduces. Looks like there are a couple bugs here:

  • The error messages talk about duplicate type definitions, but the enum is not declaring a type C; it is declaring a constructor named C, which belongs to a different namespace.
  • On a related note: I'm not sure yet whether our intention is to allow the shadowing of the constructor names (which means we should not be signaling an error in either case), or if the bug really is as described in the description.

@sanxiyn
Copy link
Member

sanxiyn commented Jun 15, 2013

See #7044.

@luqmana
Copy link
Member

luqmana commented Jun 15, 2013

So, the reason why swapping the order works is because in resolve struct C { ... } by itself checks for any duplicate names, but struct C { ... } as an enum variant doesn't.

Also, the reason why the error messages refer to duplicate type definitions is because they're added to the Type namespace as opposed to the Value namespace. (Though, new type and unit structs are added to both the type and value namespaces.)

@luqmana
Copy link
Member

luqmana commented Jun 15, 2013

Oh and rustc doesn't actually consider struct C { ... } as having a constructor. (i.e. the ctor_id field on the struct_def is None).

@pnkfelix
Copy link
Member

I came out of the meeting from 2013-06-18 thinking that we might want to allow the shadowing here, but the meeting notes don't actually reflect much/any justification for that conclusion that I can see. I guess its good to be consistent, in any case.

@luqmana
Copy link
Member

luqmana commented Jun 24, 2013

Oh, I had thought the consensus was it should be an error given pcwalton's comment.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2020
Rollup of 5 pull requests

Successful merges:

 - rust-lang#5443 (Some accuracy lints for floating point operations)
 - rust-lang#5752 (Move range_minus_one to pedantic)
 - rust-lang#5756 (unnecessary_sort_by: avoid linting if key borrows)
 - rust-lang#5784 (Fix out of bounds access by checking length equality BEFORE accessing by index.)
 - rust-lang#5786 (fix phrase in new_lint issue template)

Failed merges:

r? @ghost

changelog: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants