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: [email protected]
ReportedBy: [email protected]
--- Comment #0 from Kenji Hara <[email protected]> 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: -------
