Lit-test sanitizers/fuzz_asan.d works, while fuzz_{basic,mixin}.d fail
with linker errors, as (implied & apparently required)
`-fsanitize-coverage=inline-8bit-counters` isn't supported on Windows
yet, e.g.:
fuzz_basic.d.tmp.obj : error LNK2019: unresolved external symbol __start___sancov_cntrs referenced in function sancov.module_ctor_8bit_counters
fuzz_basic.d.tmp.obj : error LNK2019: unresolved external symbol __stop___sancov_cntrs referenced in function sancov.module_ctor_8bit_counters
fuzz_basic.d.tmp.obj : error LNK2019: unresolved external symbol __start___sancov_pcs referenced in function sancov.module_ctor_8bit_counters
fuzz_basic.d.tmp.obj : error LNK2019: unresolved external symbol __stop___sancov_pcs referenced in function sancov.module_ctor_8bit_counters
The ASan tests now work with LLVM 10 and the VS 2019 runtime at least,
so enabling the tests resolves#3566. Actual support was added with LDC
v1.8, see b7d12fe52f.
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like #3402.
The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
I got a std.stdio hello-world executable to work on Win64 using the
Visual C++ 2015 DLLs, with both MS linker and -link-internally, see
https://github.com/dlang/installer/pull/346.
It still requires a couple of extra command-line args, but will in the
end enable us to get rid of all external dependencies for building on
Windows (via -link-internally and the MinGW-w64-based import libs, which
will only add a few MB to the prebuilt packages).
The Visual C++ 2015 *runtime* will need to be installed when running
binaries linked against the MinGW libs.
In addition (and preferred over) the previous searched-for lib dir
(`<bin dir>/../lib<LIB_SUFFIX CMake var>`). [Incl. searching in some of
their subdirs, e.g., `clang/x.y.z/lib/<OS>`.]
I skipped that backwards-compatibility thingy for the builtins lib on
Windows (not crucial, only linked (if found) on Windows etc.).
And replace the default `-L-L<path>` LDC switches in the default config
accordingly.
The first advantage is for cross-compilation, where additional sections
should now mostly get away with overriding `lib-dirs` (and `rpath` if
need be) only; not just to specify the directory containing cross-
compiled druntime and Phobos, but also further dirs containing the C
libs. No need to override a whole `[post-]switches` array anymore just
to tweak the lib dirs.
The second advantage is that we can search these dirs for compiler-rt
libs instead of being limited to `<bin dir>/../lib<LIB_SUFFIX specified
in CMake command line>` or trying to guess distro-specific paths
=> easy-peasy for distros and users.
This isn't implemented yet.
The LLVM 5.0.1 ASan x64 lib doesn't work with VS 2017 v15.5.5; any
executable linked against it will hang at startup with the msg:
'ASan init calls itself!'
See https://github.com/google/sanitizers/issues/818.
Results in a 7.5% bigger RelWithDebInfo ldc2.exe on Win64 with LLVM 3.9.1.
LLD is currently enforced when building with LDC_WITH_LLD=ON. And LLD
still doesn't support debuginfo (.pdb) generation for MSVC targets.
