Every now and then (in particular just now) I spend a chunk of time trying to
track down import/alias conflicts. The latest one involved three modules, only
two of which appeared in the error message from running dmd -c display.d
empire.d(19): import empire.std conflicts with display.std at display.d(19)
Line 19 of empire.d is "private import std.random;"
Line 19 of display.d is "import std.c.stdlib;"
The error turned out to be in another module eplayer.d that was getting imported
by display before empire and it defined an alias
alias std.string.toupper toupper;
without first importing std.string. That appears to have the effect of defining
the symbol "std" so that it conflicted with the later import std.random.
Anyway, my request is that error message about conflicts give the source module
where the symbol was defined. That would have made debugging this issue much
faster. The kind of message I'm hoping for would be
empire.d(19): import empire.std conflicts with display.std at display.d(19)
defined at eplayer.d(32)
Of course there could be a compiler bug in there somewhere, too.

thanks,
-Ben

Ben Hinkle <Ben_member@pathlink.com> wrote:

[...]
> Of course there could be a compiler bug in there somewhere, too.

If the incriminated error message is the first error message I would agree that you detected a compiler bug, because there should be an earlier message

| eplayer.d(32): identifier 'std.string.toupper' is not defined

However, I am convinced that module tests should precede the integration test. Would you please explain the advantages of having an integration test without prior module tests?

-manfred

Ben Hinkle wrote:
> Every now and then (in particular just now) I spend a chunk of time trying to
> track down import/alias conflicts. The latest one involved three modules, only
> two of which appeared in the error message from running dmd -c display.d
> empire.d(19): import empire.std conflicts with display.std at display.d(19)
> Line 19 of empire.d is "private import std.random;"
> Line 19 of display.d is "import std.c.stdlib;"
> The error turned out to be in another module eplayer.d that was getting imported
> by display before empire and it defined an alias
> alias std.string.toupper toupper;
> without first importing std.string. That appears to have the effect of defining
> the symbol "std" so that it conflicted with the later import std.random.
> Anyway, my request is that error message about conflicts give the source module
> where the symbol was defined. That would have made debugging this issue much
> faster. The kind of message I'm hoping for would be
> empire.d(19): import empire.std conflicts with display.std at display.d(19)
> defined at eplayer.d(32)

Sounds like a good idea to me. I think I suggested something similar a while back.

From http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1315
<quote>
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.
</quote>

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

In article <d13a8s$ps1$1@digitaldaemon.com>, Manfred Nowak says...
>
>Ben Hinkle <Ben_member@pathlink.com> wrote:
>
>[...]
>> Of course there could be a compiler bug in there somewhere, too.
>
>If the incriminated error message is the first error message I would agree that you detected a compiler bug, because there should be an earlier message
>
>| eplayer.d(32): identifier 'std.string.toupper' is not defined

I agree that could be the real issue here. There might be good reasons for allowing that, though. I don't know what would happen if defining an "arbitrary" alias were made illegal.

>However, I am convinced that module tests should precede the integration test. Would you please explain the advantages of having an integration test without prior module tests?

By "you" do you mean me? If so then I don't know the answer to the question. I'm not sure what you mean by integration test and module test.

Ben Hinkle <Ben_member@pathlink.com> wrote:

[...]
>>| eplayer.d(32): identifier 'std.string.toupper' is not defined
> 
> I agree that could be the real issue here. There might be good reasons for allowing that, though. I don't know what would happen if defining an "arbitrary" alias were made illegal.

I see. So we have to nitpick on the words a little.

Although Walter used the words "is not defined" I argue that he
wanted to express "is not declared" because the semantic of
`alias' here is a declaration not a definition.
( http://www.digitalmars.com/d/declaration.html)

And the difference I see is, that indeed _arbitrary_ things can be defined but declarations are based on things that are declared already.

[...]
> By "you" do you mean me? If so then I don't know the answer to the question. I'm not sure what you mean by integration test and module test.

By "module test" I mean to compile and run for example the unittest of a single module. By "integration test" I mean the tests carried out, when more than one module is involved. Typically the modules are handed over to a coder who implemented a testbed for these modules or they are integrated into the modules they are planned for, which are usually in a higher layer.

-manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:d14ofb$2bm4$1@digitaldaemon.com...
> Ben Hinkle <Ben_member@pathlink.com> wrote:
>
> [...]
>>>| eplayer.d(32): identifier 'std.string.toupper' is not defined
>>
>> I agree that could be the real issue here. There might be good reasons for allowing that, though. I don't know what would happen if defining an "arbitrary" alias were made illegal.
>
> I see. So we have to nitpick on the words a little.
>
> Although Walter used the words "is not defined" I argue that he
> wanted to express "is not declared" because the semantic of
> `alias' here is a declaration not a definition.
> ( http://www.digitalmars.com/d/declaration.html)
>
> And the difference I see is, that indeed _arbitrary_ things can be defined but declarations are based on things that are declared already.

Seems reasonable. I hadn't thought about the define/declare differences.

> [...]
>> By "you" do you mean me? If so then I don't know the answer to the question. I'm not sure what you mean by integration test and module test.
>
> By "module test" I mean to compile and run for example the unittest of a single module. By "integration test" I mean the tests carried out, when more than one module is involved. Typically the modules are handed over to a coder who implemented a testbed for these modules or they are integrated into the modules they are planned for, which are usually in a higher layer.

Ok - I see what you mean now. The error happened at the compile phase before any tests (module or integration) can be compiled and run. I think another cause of my problem was the dependencies in the makefile I was using were out of whack so when I made a change and compiled it some dependent modules weren't recompiled. When I did a clean rebuild the display module, which had rebuilt successfully at one point, no longer compiled.