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