Bug 9922 – Improve symbol emitting for templates for better separate compilation support

Currently all of them are generated to object file associated with module supplied to the command line. For separate compilation scenario that means that ALL template symbols from ALL imported modules are emitted into compiled single module. Most time it is just extra job for linker, but sometimes this results in nasty bugs when resulting symbols are not weak ones. Desired behavior: dmd will tries to find root module where template instantiation chain has started via call from non-templated scope.

(In reply to comment #0) > Most time it is just extra job for linker, but sometimes this results in nasty > bugs when resulting symbols are not weak ones. > I'd say this is a bug, any templated symbol must be weak. Do you have a test case for this.

(In reply to comment #1) > (In reply to comment #0) > > Most time it is just extra job for linker, but sometimes this results in nasty > > bugs when resulting symbols are not weak ones. > > > I'd say this is a bug, any templated symbol must be weak. > Do you have a test case for this. Please correct me if I am mistaken, but this is one of the issues causing http://d.puremagic.com/issues/show_bug.cgi?id=9571 as far as I am understand. When auto return type is used, foo is processed as a template instance and all symbols it uses, including problematic lambda, come to a.o via MapResult. There are plenty of reason that make problem observable : wrong id for funcliteral, fact that foo is treated as template instance when it is actually not, fact that all symbols used from templates go to command-line supplied module. Well, that is my interpretation of what gdb has told me, I am complete and utter noob in dmd internals, so please object. And yes, this behavior is a bug for sure on its own. That is why I have marked this issues as an enhancement and not a bug.

We had another Bugzilla for link errors with separate compilation but I can't find it. There I mentioned that the correct compiler behavior would be to emit a weak template instance to each object file that references that instance. This has some performance issues but it only affects separate compilation with multiple object files. One approach to mitigate the performance impact would be something like partial linking, i.e. producing the duplicated template instances at binary level not at AST level.

(In reply to comment #3) > There I mentioned that the correct compiler behavior would be to emit a weak > template instance to each object file that references that instance. > This has some performance issues but it only affects separate compilation with > multiple object files. Yes, that is my understanding too. However, implementing this may be much trickier than it sounds because currently DMD front-end does not really track object files that need to reference instance in any convenient fashion. At least I could not find a straightforward way. Another issue is that template instances are re-used and only context of first usage gets fully saved (again, that is what trial-and-error have shown to me). We have discussed that briefly in matching (failed) pull request by eskimor. However, I expect in the end performance to actually improve because those few extra weak symbols per module object file are minority comparing to all templates that get used only by constraints and CTFE and can be completely ignored during symbol emitting. If compiler becomes more aware of actual template usage (from ABI point of view), some useful optimizations can be done here. Are you referring to this "won't fix" issue http://d.puremagic.com/issues/show_bug.cgi?id=3274 ? Anyway, I am trying to hack together some proper solution here, to address both separate compilation and template bloat issues, but it is likely to take hell of a long time, dmd code in this part is far from obvious.

I feel as though this is the issue I'm hitting with compiling with Dub and compiling Juno. I haven't been able to create an appropriate reduced test case. https://github.com/JesseKPhillips/Juno-Windows-Class-Library at Commit: 174fc19d3e2c91134392d98c9738f335560e55c3 This code will compile with DMD 2.065 and 2.066, but in 2.066 it errors with many linker messages e.g. juno.lib: Error: multiple definition of core: _D4juno3com4core7__arrayZ and xsl: _D4juno3com4core7__arrayZ juno.lib: Error: multiple definition of core: _D4juno3com4core8__assertFiZv and xsl: _D4juno3com4core8__assertFiZv

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18561 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB