Thread overview
[Issue 260] New: conflicting imports
Jul 20, 2006
d-bugmail
Jul 21, 2006
d-bugmail
Jul 21, 2006
d-bugmail
Jul 22, 2006
d-bugmail
Jul 22, 2006
d-bugmail
Jul 24, 2006
d-bugmail
Jul 25, 2006
d-bugmail
Jul 25, 2006
d-bugmail
Jul 29, 2006
d-bugmail
Jun 25, 2008
d-bugmail
July 20, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260

           Summary: conflicting imports
           Product: D
           Version: 0.163
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: benoit@tionex.de


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.


-- 

July 21, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #1 from chris@dprogramming.com  2006-07-21 11:04 -------
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.


-- 

July 21, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #2 from benoit@tionex.de  2006-07-21 17:33 -------
Yes, that is exactly the thing I had.
Thanks for your example.


-- 

July 22, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #3 from ddparnell@bigpond.com  2006-07-21 21:37 -------
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"


-- 

July 22, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #4 from ddparnell@bigpond.com  2006-07-21 21:39 -------
Oops, that line number was wrong. It should be "foo(5)" I guess, reflecting the line in which the named member was used.


-- 

July 24, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #5 from lio@lunesu.com  2006-07-24 06:52 -------
(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?


-- 

July 25, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #6 from daiphoenix@lycos.com  2006-07-25 15:25 -------
(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?


-- 

July 25, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #7 from ddparnell@bigpond.com  2006-07-25 16:54 -------
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.


-- 

July 29, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=260





------- Comment #8 from daiphoenix@lycos.com  2006-07-29 11:47 -------
(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.


-- 

June 25, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=260


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Comment #9 from bugzilla@digitalmars.com  2008-06-24 22:14 -------
This compiles successfully with dmd 1.031 and 2.015


--