https://issues.dlang.org/show_bug.cgi?id=15318
--- Comment #4 from Kenji Hara <[email protected]> --- 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. --
