www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - what is import conflicts with... ?

reply bobef <bobef_member pathlink.com> writes:
thirdparty\win32.d(55): import ak.ide.thirdparty.win32.std conflicts with
ak.xml.base.std at ../../\ak\xml\base.d(6)

What does that mean?

win32.d imports std.c.windows.windows only (at line 55)
and base.d imports other std.things (line 6 is private import std.file) which
are not included by win32.d nor std.c.windows.windows...
I can't understand it. It suddenly broke down with these errors...
When I compile I get this error few times...
Feb 01 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message 
news:ctnucp$bf3$1 digitaldaemon.com...

 thirdparty\win32.d(55): import ak.ide.thirdparty.win32.std conflicts with
 ak.xml.base.std at ../../\ak\xml\base.d(6)

 What does that mean?

 win32.d imports std.c.windows.windows only (at line 55)
 and base.d imports other std.things (line 6 is private import std.file) 
 which
 are not included by win32.d nor std.c.windows.windows...
 I can't understand it. It suddenly broke down with these errors...
 When I compile I get this error few times...


It looks to me like the compiler is trying to interpret 
"std.c.windows.windows" as an expression instead of an import statement. 
Most likely because you define the symbol "std" in ak.xml.base.

Here's a simpler example of the error:

  class std {};
  import std.c.windows.windows;
  int main() { return 0; }

compiling gives:

badimport.d(2): import badimport.std conflicts with badimport.std at 
badimport.d(1)

It could be a compiler bug in import statements. Either that or another 
nasty side effect of including module and package names in the same 
namespace as other symbols. If Walter did change the compiler to use 
different namespaces for packages/modules and classes then what would happen 
with expressions "std.foo" where foo is defined in both module std and class 
std?
Feb 01 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <cto93j$ngi$1 digitaldaemon.com>, Ben Hinkle says...

"bobef" <bobef_member pathlink.com> wrote in message 
news:ctnucp$bf3$1 digitaldaemon.com...

 thirdparty\win32.d(55): import ak.ide.thirdparty.win32.std conflicts with
 ak.xml.base.std at ../../\ak\xml\base.d(6)

 What does that mean?

 win32.d imports std.c.windows.windows only (at line 55)
 and base.d imports other std.things (line 6 is private import std.file) 
 which
 are not included by win32.d nor std.c.windows.windows...
 I can't understand it. It suddenly broke down with these errors...
 When I compile I get this error few times...


It looks to me like the compiler is trying to interpret 
"std.c.windows.windows" as an expression instead of an import statement. 
Most likely because you define the symbol "std" in ak.xml.base.

Here's a simpler example of the error:

  class std {};
  import std.c.windows.windows;
  int main() { return 0; }

compiling gives:

badimport.d(2): import badimport.std conflicts with badimport.std at 
badimport.d(1)

It could be a compiler bug in import statements. Either that or another 
nasty side effect of including module and package names in the same 
namespace as other symbols. If Walter did change the compiler to use 
different namespaces for packages/modules and classes then what would happen 
with expressions "std.foo" where foo is defined in both module std and class 
std?


Without seeing the code, I agree that it could be something like that, but my
guess would be that the problem would be something like this one:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307

It can probably be solved just by adding a particular import statement at the
top of a particular file, but that's just a guess.

jcc7
Feb 01 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 Without seeing the code, I agree that it could be something like that, but 
 my
 guess would be that the problem would be something like this one:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307

 It can probably be solved just by adding a particular import statement at 
 the
 top of a particular file, but that's just a guess.


You're probably right that bobef's code looks like that. I tried changing
std.stream.File file;
to
v.std.stream.File file;
and it worked. Oddly enough it also works if I change it to
d.std.stream.File file;
The odd part about that is that d doesn't ever import std.stream anywhere. 
Hmmm. Something is fishy in there. For those playing at home here are some 
examples:
module a.d:
  import b;
  import c;
  b.std.stream.File f;
  int main(){return 0;}
module b.d:
  import std.stream;
module c.d:
  import std.gc;

dmd a.d

Everything works if you put anything in front of std.stream.File in a.d
Feb 01 2005
prev sibling parent reply bobef <bobef_member pathlink.com> writes:
The problem is that I do not define std anywhere it just broke
when I imported std.c.stdlib... I tried to fix it... changed some imports
now I can't get it back working...

In article <cto93j$ngi$1 digitaldaemon.com>, Ben Hinkle says...

"bobef" <bobef_member pathlink.com> wrote in message 
news:ctnucp$bf3$1 digitaldaemon.com...

 thirdparty\win32.d(55): import ak.ide.thirdparty.win32.std conflicts with
 ak.xml.base.std at ../../\ak\xml\base.d(6)

 What does that mean?

 win32.d imports std.c.windows.windows only (at line 55)
 and base.d imports other std.things (line 6 is private import std.file) 
 which
 are not included by win32.d nor std.c.windows.windows...
 I can't understand it. It suddenly broke down with these errors...
 When I compile I get this error few times...


It looks to me like the compiler is trying to interpret 
"std.c.windows.windows" as an expression instead of an import statement. 
Most likely because you define the symbol "std" in ak.xml.base.

Here's a simpler example of the error:

  class std {};
  import std.c.windows.windows;
  int main() { return 0; }

compiling gives:

badimport.d(2): import badimport.std conflicts with badimport.std at 
badimport.d(1)

It could be a compiler bug in import statements. Either that or another 
nasty side effect of including module and package names in the same 
namespace as other symbols. If Walter did change the compiler to use 
different namespaces for packages/modules and classes then what would happen 
with expressions "std.foo" where foo is defined in both module std and class 
std?
Feb 01 2005
parent J C Calvarese <jcc7 cox.net> writes:
In article <ctolh7$14e1$1 digitaldaemon.com>, bobef says...

The problem is that I do not define std anywhere it just broke
when I imported std.c.stdlib... I tried to fix it... changed some imports
now I can't get it back working...


There's only so much that we can do to help without seeing your code.

Try this tip: 

"From my experience, you can usually see the conflicting file by looking at the
compile command (assuming you only build one source file at a time). The
conflicting source file is usually the one that is currently being compiled. An
import of the module the compiler complained about should be added there."



jcc7
Feb 01 2005