Module name conflicts with field

[Jarrett Billingsley]

"Lionello Lunesu" <lio at lunesu.remove.com> wrote in message 
news:eh00d0$7gc$1 at digitaldaemon.com...
> Hi,
>
> I got an unexpected error message ("no property X for type Y") and got it 
> down to the following minimal test case:
>
> #module test;
> #struct A { }
> #struct B {
> #  test.A a;
> #  int test;
> #}
> #void main() {}
>
> Compiling with DMD 0.169 gives:
>
> test.d(4): no property 'A' for type 'int'
> test.d(4): test.A is used as a type
> test.d(4): variable test.B.a voids have no value
>
> The "test" on line 4 is interpreted as a field name (strange place for a 
> field name) instead of the module name. Commenting either line 4 or 5 gets 
> rid of the errors.
>
> Obviously, using "test.A" makes no sense here, but in the original project 
> an imported module conflicted with a field of the struct.
>
> I think the code is valid, since there seems to be no conflict between a 
> module name and field names if I comment only one of the lines in the 
> struct.
>
> L.

I can understand why this happens, but I don't know if there'd be an easy 
fix (in the compiler) for it.  Basically, the names of the struct members 
are added to the struct's symbol table before their types are checked for 
correctness.  So by the time a's type is checked, "test" has already been 
added to B's symbol table, so it finds B.test before it goes to the 
module-level scope.  This cannot really be changed without introducing some 
very weird symbol lookup rules into the compiler.

Strangely, what I thought would work, doesn't:

struct A {}
struct B
{
    .test.A a;
    int test;
}

now it gives the error "identifier 'test' of 'test.A' is not defined."  I 
don't know what that means.  But in any case, you wouldn't really be 
accessing FQNs of current module members that much, so I guess not many 
people would run into this.

I don't know if it's a bug so much as just a weird issue.