given the following files:
File a.d in package A
File b.d, c.d in package BC
I got the error message
in b.d line... BC.b.A conflicts with BC.c.A in c.d line ...
After stumbling around and using the -v option, it turns out, this message was generated while processing file BC.x and there were missing imports. Fixing this, make the error go away.
Sorry, I don't have code to show this. But please make the message in a way it also points to the file x.
Comment #1 by chris — 2006-07-21T11:04:32Z
Here's a simple example of the issue:
// -- foo.d --
private import std.stdio;
// -- bar.d --
private import std.stdio;
// -- test.d --
import foo, bar;
void main()
{
char[] hi = std.string.toString(3);
}
DMD:
foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
Of course, the code in test.d is a mistake, but look how unhelpful the error message is. It will blame a library's code for a mistake the library-user made.
Comment #2 by benoit — 2006-07-21T17:33:50Z
Yes, that is exactly the thing I had.
Thanks for your example.
Comment #3 by ddparnell — 2006-07-21T21:37:39Z
I have recommend in the past that this message be change to read something more like ...
"foo.d(1): Cannot find an accessible member called std.string.toString"
Comment #4 by ddparnell — 2006-07-21T21:39:30Z
Oops, that line number was wrong. It should be "foo(5)" I guess, reflecting the line in which the named member was used.
Comment #5 by lio+bugzilla — 2006-07-24T06:52:35Z
(In reply to comment #4)
> Oops, that line number was wrong. It should be "foo(5)" I guess, reflecting the
> line in which the named member was used.
Shouldn't it also refer to test.d, rather than foo.d?
Comment #6 by bruno.do.medeiros+deebugz — 2006-07-25T15:25:56Z
(In reply to comment #1)
> Here's a simple example of the issue:
> // -- foo.d --
> private import std.stdio;
> // -- bar.d --
> private import std.stdio;
> // -- test.d --
> import foo, bar;
> void main()
> {
> char[] hi = std.string.toString(3);
> }
> DMD:
> foo.d(1): import foo.std conflicts with bar.std at bar.d(1)
> Of course, the code in test.d is a mistake, but look how unhelpful the error
> message is. It will blame a library's code for a mistake the library-user made.
I've run that example and I get no error (DMD.163, no extra switches). Did you run that test case in the latest DMDs?
Comment #7 by ddparnell — 2006-07-25T16:54:34Z
But it should give an error something like ...
test.d(4): undefined identifier std
because it didn't import std.stdio and both foo.d and bar.d imported that as private, so test.d shouldn't use those imports.
Comment #8 by bruno.do.medeiros+deebugz — 2006-07-29T11:47:44Z
(In reply to comment #7)
> But it should give an error something like ...
> test.d(4): undefined identifier std
> because it didn't import std.stdio and both foo.d and bar.d imported that as
> private, so test.d shouldn't use those imports.
Well then, maybe it should give such error, but that's another bug altogether. This error is not related to protection attributes: when it appeared, it appeared even when public imports were used.
This bug report, besides being mildly malformed IMO, is a duplicate of bug #209.
Comment #9 by bugzilla — 2008-06-24T22:14:28Z
This compiles successfully with dmd 1.031 and 2.015