https://issues.dlang.org/show_bug.cgi?id=14901
--- Comment #1 from Kenji Hara <[email protected]> --- The bug behavior has introduced by the excessive instantiation and codegen for the non-root instances. From 2.067, the make!"bar" instance code which aliased in b.d will be instantiated and stored into [bcde].obj. With 2.066 and earlier, it had stored only into b.obj. Those regressions have the same root: Issue 14431 - [REG 2.067.0] huge slowdown of compilation speed Issue 14508 - [REG2.067.0] compiling with -unittest instantiates templates in non-root modules Issue 14564 - [REG2.067] dmd -property -unittest combination causes compiler error and it will be fixed by: https://github.com/D-Programming-Language/dmd/pull/4784 But unfortunately, my PR is not released into 2.068.0, because Walter couldn't understand the fix. David, I wish to you to join its code review, if you have a time. ---- > As far as the cause for this goes, for reasons I'm not entirely clear about a > unique identifier is used for function name of the static ctor (e.g. > _sharedStaticCtor55). For (amongst others) -unittest builds, the ctor > function is always emitted to fix issue 11239. Thus, different object files > end up with differently named copies of the same function, which consequently > also gets run multiple times. That's an another, fragile naming mechanism issue in current dmd front-end. Some unnamed symbols (static this, unittest, anonymous class, etc) are numbered by the `Identifier::generateId()`. It's result not *stable* because it fully depends on the order of semantic analysis and it will be changed by the conditional compilation. For lambdas and unnamed mixin declarations, I added "scope local unique number" (See FuncExp::genIdent and TemplateMixin::semantic). For them, the frequency of the issue has been reduced by them, but it's not yet perfect answer... --
