linking obj files compiled with LDC2 1.20.0 on Win64

[realhet]

On Sunday, 22 March 2020 at 20:20:17 UTC, Steven Schveighoffer 
wrote:
> Make sure you don't have any stale objects left over in your 
> project from the older build. Build everything clean from 
> scratch.
>
> -Steve

After narrowing the problem, I fixed all warnings, and 
deprecations, and I have only one linker error now:

Compiler command line (LDC 1.20.0 Win64):
ldmd2 -vcolumns -c -op -allinst -Ic:\D\libs\ -m64 
-mcpu=athlon64-sse3 -mattr=+ssse3 -release -O -inline 
-boundscheck=off c:\D\libs\jsonizer\exceptions.d

Linker command line:
link /LIBPATH:c:\D\ldc2\lib64 /OUT:c:\D\libs\het\hdmd\hdmd.exe 
/MACHINE:X64 kernel32.lib user32.lib legacy_stdio_definitions.lib 
***All the required obj files*** druntime-ldc.lib phobos2-ldc.lib 
msvcrt.lib

Linker response (after demangling):
Microsoft (R) Incremental Linker Version 14.23.28105.4
Copyright (C) Microsoft Corporation.  All rights reserved.

---------------------------------------------

exceptions.obj : error LNK2019: unresolved external symbol

pure nothrow @nogc @safe void 
std.format.hasToString!(std.json.JSONValue, 
char).__lambda2().S.put(char)

referenced in function

pure nothrow @nogc @safe void 
std.range.primitives.put!(std.format.hasToString!(std.json.JSONValue, char).__lambda2().S, char).put(ref std.format.hasToString!(std.json.JSONValue, char).__lambda2().S, char)

---------------------------------------------

I've searched for the hasToString template, but this seems way 
too complicated for me.
This nested lambda template thing o.O

Here is the source code for the exceptions.obj file: 
https://github.com/rcorre/jsonizer/blob/master/src/jsonizer/exceptions.d

These are caused by some format() calls, I don't know why it is a 
problem now and it's totally OK with a 2017 version.

This nested std.range.primitives.put is weird for me. Maybe it's 
a bug because by the -CompileAllTemplateInstances flag? (That's 
not the normal use, I know: I comile all the objs, and while I 
work, I only compile the ones that changed (recursively ofc), and 
finally link. It's much faster this way on a 8 core machine.).