[Issue 15318] Templates not emitted for two "partial cycles"

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Thu Nov 12 18:33:20 PST 2015


https://issues.dlang.org/show_bug.cgi?id=15318

--- Comment #4 from Kenji Hara <k.hara.pg at gmail.com> ---
I don't think that the issue case is a bug in the current instantiation
strategy.

The codegen omission for non-root instances is designed for the compiling
applications which is using big template style libraries.
On the other hand, in the issue case, the non-root instance bar!5 is a part of
the build target, so no libraries can supply the missing symbol.

I think it could be resolved at compiler tool side.
If a module is imported, all of template instances in it could be handled
either:
  A. as non-root instances, because the module is a part of library.
  B. as speculative instances, because the module is a part of build target.
But currently, all of import directories are in a ordered flat list.
So, compiler cannot distinguish the two cases - today all of cases are treated
as case A.


My proposal is, adding a boundary between "build target" and "library".
By that, we can have a new behavior for the modules for the build target.

How to define the boundary? There's some ways I can think.

- Use the 'package' difference. For example:
  If none of root modules belong to 'std' package, then all of modules belongs
'std' can be handled as library modules.
- Use the found import directory. For example:
  The default import directly '.' can be handled as for the build-target
always.
- Use a new switch for the importing build-target modules. For example:
    dmd -buildTarget_I=...
  If compiler finds a module from that directory, the module will be handled as
build target module.

The approach would also fit to modern package system.

--


More information about the Digitalmars-d-bugs mailing list