View mode: basic / threaded / horizontal-split · Log in · Help
August 08, 2004
import std conflicts with d.std
The following code gives this error message, but I think it should work:
v.d(3): import std conflicts with d.std at d.d(3)



[c.d]
module c;

import v;
import d;

V start;
std.stream.File file;



[d.d]
module d;

import std.c.windows.windows;



[v.d]
module v;

import std.stream;
struct V{}



[build.bat]
dmd c.d -c
pause



And, yes, it compiles fine if I change the last line of c.d to:
"File file;"

Workarounds are great, but I think it should either compile as written 
or give a more detailed explanation in the error message.

By the way, this is from an issue discovered by clayasaurus in 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423

I'm sure I posted an eerily similar bug report before, but I can't find 
it, so maybe I dreamed the whole thing.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 09, 2004
Re: import std conflicts with d.std
In module c, add an import std.stream; and it should work.

"J C Calvarese" <jcc7@cox.net> wrote in message
news:cf3s6f$2d84$1@digitaldaemon.com...
> The following code gives this error message, but I think it should work:
> v.d(3): import std conflicts with d.std at d.d(3)
>
>
>
> [c.d]
> module c;
>
> import v;
> import d;
>
> V start;
> std.stream.File file;
>
>
>
> [d.d]
> module d;
>
> import std.c.windows.windows;
>
>
>
> [v.d]
> module v;
>
> import std.stream;
> struct V{}
>
>
>
> [build.bat]
> dmd c.d -c
> pause
>
>
>
> And, yes, it compiles fine if I change the last line of c.d to:
> "File file;"
>
> Workarounds are great, but I think it should either compile as written
> or give a more detailed explanation in the error message.
>
> By the way, this is from an issue discovered by clayasaurus in
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>
> I'm sure I posted an eerily similar bug report before, but I can't find
> it, so maybe I dreamed the whole thing.
>
> -- 
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/
>
August 09, 2004
Re: import std conflicts with d.std
Walter wrote:
> In module c, add an import std.stream; and it should work.

Yes, that works. Thanks.

There are also two other ways to make it work. Change "std.stream.File" 
to either "File" or "c.std.stream.File" (of course if there's another 
File symbol hanging around, the short version isn't an option without 
using an alias).

Seems like 3 work-arounds to me, but I'm getting the impression this is 
how you intend for it to work. This wouldn't be any problem when all of 
files were 5 lines long and the importing only went 3 levels deep. But 
this example was culled from a much, much larger project (in fact two 
large projects were involved).

It'd help a lot if the error message would at least make a reference to 
the "std.stream.File file" line of c.d. The current message refers to 
the lines in v.d and d.d but in my experience, the line in c.d is the 
hardest to find. It took a lot of commenting out before I zeroed in on 
the std.stream.File reference. Seeing the v.d and d.d lines have only 
reinforced my confusion at the error.

Allow, the message could have mentioned that std.stream in particular 
was causing the problem, but I don't think that's as important.

Anyways, I hope you consider making a change regarding this issue (at 
least improve the error message) because I'm confident it'll become more 
prevalent as large projects become more common.

Thanks for your consideration.

> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:cf3s6f$2d84$1@digitaldaemon.com...
> 
>>The following code gives this error message, but I think it should work:
>>v.d(3): import std conflicts with d.std at d.d(3)
>>
>>
>>
>>[c.d]
>>module c;
>>
>>import v;
>>import d;
>>
>>V start;
>>std.stream.File file;
>>
>>
>>
>>[d.d]
>>module d;
>>
>>import std.c.windows.windows;
>>
>>
>>
>>[v.d]
>>module v;
>>
>>import std.stream;
>>struct V{}
>>
>>
>>
>>[build.bat]
>>dmd c.d -c
>>pause
>>
>>
>>
>>And, yes, it compiles fine if I change the last line of c.d to:
>>"File file;"
>>
>>Workarounds are great, but I think it should either compile as written
>>or give a more detailed explanation in the error message.
>>
>>By the way, this is from an issue discovered by clayasaurus in
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>>
>>I'm sure I posted an eerily similar bug report before, but I can't find
>>it, so maybe I dreamed the whole thing.
>>
>>-- 
>>Justin (a/k/a jcc7)
>>http://jcc_7.tripod.com/d/

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 09, 2004
Re: import std conflicts with d.std
On Mon, 09 Aug 2004 10:16:36 -0700, Walter wrote:

> In module c, add an import std.stream; and it should work.

So, if you know this can you teach the compiler to tell it to us?
That would make possible to work on large applications.

beside the import on the v.d isn't private shouldn't it work as it is?

JCC, does it compile if all the modules are passed to the compiler at once?

> 
> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:cf3s6f$2d84$1@digitaldaemon.com...

>> Workarounds are great, but I think it should either compile as written
>> or give a more detailed explanation in the error message.

Ant
August 10, 2004
Re: import std conflicts with d.std
Walter,

I just distilled the same type of bug (attached)

I know it is a missing import, but all of my imports *ARE* private, so 
the compiler should just complain that it does not know anything about std.

Scott Sanders

J C Calvarese wrote:
> The following code gives this error message, but I think it should work:
> v.d(3): import std conflicts with d.std at d.d(3)
August 10, 2004
Re: import std conflicts with d.std
J C Calvarese wrote:
> Walter wrote:
> 
>> In module c, add an import std.stream; and it should work.
> 
> 
> Yes, that works. Thanks.
> 
> There are also two other ways to make it work. Change "std.stream.File" 
> to either "File" or "c.std.stream.File" (of course if there's another 

Oops, "c.std.stream.File" doesn't work. I meant to write 
"v.std.stream.File" which does work.

But "d.std.stream.File" works, too? That doesn't make any sense to me. 
How does "import std.c.windows.windows;" tell the compiler any thing 
about std.stream.File?

(Argggh! Just when I thought this was making some sense.)

> File symbol hanging around, the short version isn't an option without 
> using an alias).
> 
> Seems like 3 work-arounds to me, but I'm getting the impression this is 
> how you intend for it to work. This wouldn't be any problem when all of 
> files were 5 lines long and the importing only went 3 levels deep. But 
> this example was culled from a much, much larger project (in fact two 
> large projects were involved).
> 
> It'd help a lot if the error message would at least make a reference to 
> the "std.stream.File file" line of c.d. The current message refers to 
> the lines in v.d and d.d but in my experience, the line in c.d is the 
> hardest to find. It took a lot of commenting out before I zeroed in on 
> the std.stream.File reference. Seeing the v.d and d.d lines have only 
> reinforced my confusion at the error.
> 
> Allow, the message could have mentioned that std.stream in particular 
> was causing the problem, but I don't think that's as important.
> 
> Anyways, I hope you consider making a change regarding this issue (at 
> least improve the error message) because I'm confident it'll become more 
> prevalent as large projects become more common.
> 
> Thanks for your consideration.
> 
>> "J C Calvarese" <jcc7@cox.net> wrote in message
>> news:cf3s6f$2d84$1@digitaldaemon.com...
>>
>>> The following code gives this error message, but I think it should work:
>>> v.d(3): import std conflicts with d.std at d.d(3)
>>>
>>>
>>>
>>> [c.d]
>>> module c;
>>>
>>> import v;
>>> import d;
>>>
>>> V start;
>>> std.stream.File file;
>>>
>>>
>>>
>>> [d.d]
>>> module d;
>>>
>>> import std.c.windows.windows;
>>>
>>>
>>>
>>> [v.d]
>>> module v;
>>>
>>> import std.stream;
>>> struct V{}
>>>
>>>
>>>
>>> [build.bat]
>>> dmd c.d -c
>>> pause
>>>
>>>
>>>
>>> And, yes, it compiles fine if I change the last line of c.d to:
>>> "File file;"
>>>
>>> Workarounds are great, but I think it should either compile as written
>>> or give a more detailed explanation in the error message.
>>>
>>> By the way, this is from an issue discovered by clayasaurus in
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>>>
>>> I'm sure I posted an eerily similar bug report before, but I can't find
>>> it, so maybe I dreamed the whole thing.
>>>
>>> -- 
>>> Justin (a/k/a jcc7)
>>> http://jcc_7.tripod.com/d/
> 
> 


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 10, 2004
Re: import std conflicts with d.std
Ant wrote:
> On Mon, 09 Aug 2004 10:16:36 -0700, Walter wrote:
> 
> 
>>In module c, add an import std.stream; and it should work.
> 
> 
> So, if you know this can you teach the compiler to tell it to us?
> That would make possible to work on large applications.
> 
> beside the import on the v.d isn't private shouldn't it work as it is?
> 
> JCC, does it compile if all the modules are passed to the compiler at once?

The error still appears if they're compiled together. I've been thinking 
about the situation and I've beginning to convince myself that the 
compiler's behavior makes some sense. (I still think the error message 
needs more info.) At least it does work when "std.stream.File" is 
re-written as "v.std.stream.File".

(But there still seems to be something weird going on because 
"d.std.stream.File" compiles without error, too.)

If you've run into an issue like this in DUI, now would be a good time 
to mention it. This kind of problem is bound to be more common and 
troublesome in larger projects.

>>"J C Calvarese" <jcc7@cox.net> wrote in message
>>news:cf3s6f$2d84$1@digitaldaemon.com...
> 
> 
>>>Workarounds are great, but I think it should either compile as written
>>>or give a more detailed explanation in the error message.
> 
> 
> Ant

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 10, 2004
Re: import std conflicts with d.std
"J C Calvarese" <jcc7@cox.net> wrote in message
news:cf9689$14ql$1@digitaldaemon.com...
> to mention it. This kind of problem is bound to be more common and
> troublesome in larger projects.

Yes, it most certainly has been a troublesome for my (large-ish) project. I
resolved it in the following fashion: avoid using Phobos where at all
possible.

Inner imports resolved some problems, but ultimately it became a case of
'wrapping' the few remaining Phobos routines just to exorcise std imports
from the general codebase. Many other projects will undoubtedly (IMO) take a
similar approach ~ in my case, it was simply too much effort to resolve by
any other available means.
August 10, 2004
Re: import std conflicts with d.std
On Mon, 09 Aug 2004 19:52:24 -0500, J C Calvarese wrote:

> If you've run into an issue like this in DUI, now would be a good time 
> to mention it. This kind of problem is bound to be more common and 
> troublesome in larger projects.

I reported this the best I could about 6 times on the last year.
Walter said it's a low priority, I guess he is right.
only fools will start large projects with a beta version
of something (note that my projects aren't complex, just large).
As I see it dmd is not ready for large projects. The problem
is that you might miss something that the compiler will ignore
and sudenlly the error surfaces and it's impossible to find.
this is one of the reasons I started the lib dool:
dmd deals with objects in a more restricted way. The look up
rules was another and my preference for OO was the 3rd reason.

Ant
August 10, 2004
Re: import std conflicts with d.std
On Mon, 09 Aug 2004 18:45:51 -0700, antiAlias wrote:

> I resolved it in the following fashion: avoid using Phobos where at
> all possible.

that was my solution! I called it dool.

> 
> Inner imports resolved some problems,

in the class body? I still use that I see no problems with it,
in fact it make sense as we are using the imported classes inside
the body of the class, not outside (at least I have one class/file)

> but ultimately it became a case of
> 'wrapping' the few remaining Phobos routines just to exorcise std
> imports from the general codebase.

This is ridiculous, I bet it's a simple fix to dmd to be more carefull
using the imported declarations... well, Walter knows better.

Ant
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home