www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2500] New: template struct methods are left unresolved if imported from multiple modules

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500

           Summary: template struct methods are left unresolved if imported
                    from multiple modules
           Product: D
           Version: 1.037
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: 2korden gmail.com


The smallest test case I could find that fails for both D1 and D2 follows:

module A;

import B;
import C;

public class A
{
    T!(A) c;
}

void main()
{
    A a = new A();
    a.c.foo();
}

// B.d
module B;

import A;
import C;

class B
{
    T!(A) t;
}

// C.d
module C;

struct T(Type)
{
    void foo(){}
}

If anyone knows a workaround *please* let me know.


-- 
Dec 08 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500






Oopps, I forgot to add some importannt information...

The compilation command sequence I used is:





Error 42: Symbol Undefined _D1C12__T1TTC1A1AZ1T3fooMFZv
--- errorlevel 1


-- 
Dec 08 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500


schveiguy yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Windows                     |All





Confirmed on Linux as well.

Note that the following commands work ok:

dmd A.d B.d C.d

or

dmd -c A.d B.d C.d
dmd A.o B.o C.o

It seems that in the first (without -c), the symbol is defined in A.o

In the second case, now B.o has the symbol defined, whereas if you compile B.d
separate, it is not defined.  There is definitely a bug if compiling the files
into objects separately generates different code than compiling them in to
objects in one line.


-- 
Dec 09 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500






What's happening is A.d thinks that T!(int) is instantiated by B, and B thinks
it is instantiated in A. (T!(A) can be T!(int), the A just confuses things.)
The workaround is:

1. compile A and B on the same command, instead of separately.

2. structure A and B so they don't import each other.


-- 
Dec 11 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500


bugzilla digitalmars.com changed:

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





Fixed dmd 1.038 amd 2.022


-- 
Dec 25 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2500


wbaxter gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |





Fix was reverted in 1.039 because it was causing hideously slow compile times
for some code.


-- 
Jan 07 2009