View mode: basic / threaded / horizontal-split · Log in · Help
February 01, 2005
what is import conflicts with... ?
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...
February 01, 2005
Re: what is import conflicts with... ?
"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?
February 01, 2005
Re: what is import conflicts with... ?
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
February 01, 2005
Re: what is import conflicts with... ?
> 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
February 01, 2005
Re: what is import conflicts with... ?
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?
>
>
February 01, 2005
Re: what is import conflicts with... ?
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."

(posted by randomZ, http://www.dsource.org/forums/viewtopic.php?p=2830#2830)

jcc7
Top | Discussion index | About this forum | D home