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...

"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?

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

> 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

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?
>
>

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