www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Module name conflicts with field

reply Lionello Lunesu <lio lunesu.remove.com> writes:
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 {



#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.
Oct 16 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio lunesu.remove.com> wrote in message 
news:eh00d0$7gc$1 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 {



 #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.
Oct 16 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Jarrett Billingsley wrote:

 Strangely, what I thought would work, doesn't:
 
 struct A {}
 struct B
 {
     .test.A a;
     int test;
 }


Actually, that's exactly how I managed to fix it! Apparently it doesn't 
work in the simplified test case, but when using two files (as in my 
project) the leading dot fixes the problem:

[test.d]
struct A {}

[main.d]
import test;
struct B {
   .test.A a;
   int test;
}

I agree that there won't be many people with this problem, but I would 
expect types and field names / variables to be in separate name lookup 
lists.

L.
Oct 16 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Lionello Lunesu wrote:

 Jarrett Billingsley wrote:
 

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

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


 
 
 Actually, that's exactly how I managed to fix it! Apparently it doesn't 
 work in the simplified test case, but when using two files (as in my 
 project) the leading dot fixes the problem:
 
 [test.d]
 struct A {}
 
 [main.d]
 import test;
 struct B {
   .test.A a;
   int test;
 }
 
 I agree that there won't be many people with this problem, but I would 
 expect types and field names / variables to be in separate name lookup 
 lists.
 
 L.


Interesting.  So, the global-scope operator fails on the current module's
namespace, but 
succeeds on any other (thankfully).  Smells a little like a minor bug to me: it
should be 
perfectly happy with the current module.

-- Chris Nicholson-Sauls
Oct 19 2006