View mode: basic / threaded / horizontal-split · Log in · Help
March 13, 2005
import error message request
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
March 14, 2005
Re: import error message request
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
March 14, 2005
Re: import error message request
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/
March 14, 2005
Re: import error message request
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.
March 14, 2005
Re: import error message request
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
March 14, 2005
Re: import error message request
"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.
Top | Discussion index | About this forum | D home