www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10920] New: template instantiation order dependent link failure problem

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

           Summary: template instantiation order dependent link failure
                    problem
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: link-failure
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: k.hara.pg gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg gmail.com> 2013-08-29 00:52:52 PDT ---
Current dmd has an essential problem around template instantiation.
It is rely on the semantic order, and would cause "undefined symbol" error in
link phase.

Reduced code:

// foo.d
import bar;
void main() {
    BitArray ba;
    version(A) ba.toString();

    FormatSpec!char fs;
    fs.func();
}

// bar.d
struct FormatSpec(C) { void func() {} }
struct BitArray {
    auto toString() { FormatSpec!char fs; fs.func(); }
}

Command line:
$ dmd foo.d
--> OK

$ dmd -version=A foo.d
OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
 Error 42: Symbol Undefined _D3baz8BitArray8toStringMFZv
--- errorlevel 1
--> NG

When -version=A switch is not specified, FormatSpec!char is instantiated on the
function main in foo module at first. It would emit the the instance in the
member of foo module, then codegen phase would output the generated code
correctly.

When -version=A switch is specified, the ba.toString() call runs the semantic3
of the function BitArray.toString first. It would instantiate FormatSpec!char
in bar module, then emit the instance in the member of bar module.

This is a serious issue. If modules are separately compiled, and templates are
already instantiated in the imported module, it could cause the undefined
symbol errors.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 29 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10920



--- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2013-08-29 01:03:48 PDT ---
I think this is one of the cause of bug 10631.

And, unfortunately, long term bug fix around template opEquals/opAssign/opCmp -
e,g, fixing bug 3789, bug 4424, bug 3659, and others - had increased the
criticalness of this issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10920


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com


--- Comment #2 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2013-09-24
12:26:53 MSD ---
 ...and others - had increased the criticalness of this issue.
Filed particualr regression Issue 11114. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10920


Dicebot <public dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public dicebot.lv


--- Comment #3 from Dicebot <public dicebot.lv> 2013-09-24 09:53:39 PDT ---
I think it was already discussed in that Walters pull request and rejected as
invalid. If `foo.d` imports `bar.d` it MUST also compile `bar.d` too and link
into the final application.

In provided snippet `FormatSpec!char` should always be expected to be in
`bar.d` during separate compilation. It may also be _additionally_ emitted to
`foo.d` as a weak symbol if `foo.d` code flow runs semantic on it first, but
that will be taken care of by linker.

D does not have headers, every single module is expected to be compiled and
linked.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10920



--- Comment #4 from Kenji Hara <k.hara.pg gmail.com> 2013-09-24 18:56:59 PDT ---
(In reply to comment #3)
 I think it was already discussed in that Walters pull request and rejected as
 invalid. If `foo.d` imports `bar.d` it MUST also compile `bar.d` too and link
 into the final application.
My question and Walter's reply: https://github.com/D-Programming-Language/dmd/pull/2550#issuecomment-24296228 https://github.com/D-Programming-Language/dmd/pull/2550#issuecomment-24297212 But I still worries that the current design is difficult to understand. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 24 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10920



--- Comment #5 from Dicebot <public dicebot.lv> 2013-09-24 19:01:56 PDT ---
(In reply to comment #4)
 (In reply to comment #3)
 I think it was already discussed in that Walters pull request and rejected as
 invalid. If `foo.d` imports `bar.d` it MUST also compile `bar.d` too and link
 into the final application.
My question and Walter's reply: https://github.com/D-Programming-Language/dmd/pull/2550#issuecomment-24296228 https://github.com/D-Programming-Language/dmd/pull/2550#issuecomment-24297212 But I still worries that the current design is difficult to understand.
Yeah, that is exactly the comments I was referring to, thanks. And I completely agree with Walter here - this is difficult to understand only if you think about modules in a similar way as C headers, but those are not. Average programmer should care about internal design as much as he cares about exact optimization algorithms in backend. Omitting some modules during compilation is illegal and likely to break the program in some way (not only current one), that should be told explicitly in spec if it is not already. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 24 2013