v1.25+: -linkonce-templates miscompiles wrt. nested lambdas

[kinke]

I haven't been able to nicely reduce this yet, but host compilers v1.25+ miscompile the v2.096 frontend with -linkonce-templates. The &fad address in the lambda in https://github.com/dlang/dmd/blob/9191fdc12266cd3191d9d51c44e5a9d98b583745/src/dmd/root/file.d#L292 is null when compiling with -linkonce-templates (non-optimized too), so it looks like the context pointer is lost somewhere in the chain of lambdas, probably related to semantic order.

The symptom only shows up on Windows because it's some Windows-specific code construct newly added in v2.096.0. E.g., trying to create any .di file via -Hd=. makes the compiler segfault.

[kinke]

I think I found the cause in the IR:

-define weak_odr x86_vectorcallcc i32 @"\01_D3dmd4root8filename__T16extendedPathThenSQBoQBn4file4File6updateFNbPxaxAvZ9__lambda6ZQClMFNbAxaZi"(i8* nonnull %.nest_arg, { i64, i8* } %path_arg) #1 comdat {
+define linkonce_odr x86_vectorcallcc i32 @"\01_D3dmd4root8filename__T16extendedPathThenSQBoQBn4file4File6updateFNbPxaxAvZ9__lambda6ZQClMFNbAxaZi"(i8* nonnull %.nest_arg, { i64, i8* } %path_arg) #1 comdat {
   %path = alloca { i64, i8* }, align 8            ; [#uses = 3, size/byte = 16]
   store { i64, i8* } %path_arg, { i64, i8* }* %path, align 8
   %1 = getelementptr inbounds { i64, i8* }, { i64, i8* }* %path, i32 0, i32 0 ; [#uses = 1, type = i64*]
   %.len = load i64, i64* %1, align 8              ; [#uses = 1]
   %2 = icmp ne i64 %.len, 0                       ; [#uses = 1]
   %3 = icmp eq i1 %2, false                       ; [#uses = 1]
   br i1 %3, label %if, label %endif

 if:                                               ; preds = %0
   %4 = call x86_vectorcallcc i32 @"\01_D3dmd4root4file4File6updateFNbPxaxAvZ__T9__lambda6TAuZQoMFNbNiQlZi"(i8* nonnull %.nest_arg, { i64, i16* } zeroinitializer) #1 ; [#uses = 1]
   ret i32 %4

 dummy.afterreturn:                                ; No predecessors!
   br label %endif

 endif:                                            ; preds = %dummy.afterreturn, %0
   %5 = load { i64, i8* }, { i64, i8* }* %path, align 8 ; [#uses = 1]
-  %6 = call x86_vectorcallcc i32 @"\01_D3dmd4root8filename__T14toWStringzThenSQBmQBlQBj__T16extendedPathThenSQCrQCq4file4File6updateFNbPxaxAvZ9__lambda6ZQClMFAxaZ9__lambda2ZQEiMFNbQwZi"(i8* nonnull %.nest_arg, { i64, i8* } %5) #1 ; [#uses = 1]
+  %6 = call x86_vectorcallcc i32 @"\01_D3dmd4root8filename__T14toWStringzThenSQBmQBlQBj__T16extendedPathThenSQCrQCq4file4File6updateFNbPxaxAvZ9__lambda6ZQClMFAxaZ9__lambda2ZQEiMFNbQwZi"(i8* nonnull null, { i64, i8* } %5) #1 ; [#uses = 1]
   ret i32 %6
 }

I'm thinking the actual reason might have to do with an assumption that the stack of currently codegen'd functions (gIR->funcGenStates) reflects parent/child relationships, which breaks down when defining a function when it is referenced (e.g., some call in another function) and not already defined. I've only found that assumption in ToElemVisitor::visit(ThisExp*), but there might be more subtle ones hidden somewhere.

[kinke]

DtoCreateNestedContextType() for the called toWStringzThen function seems to wrongly infer an IrFunction::depth of -1 instead of 0.