www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - import error message request

reply Ben Hinkle <Ben_member pathlink.com> writes:
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
Mar 13 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Mar 13 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
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.
Mar 14 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Mar 14 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Mar 14 2005
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
Mar 13 2005