D109708 added "DIA SDK" to our win sysroot for hermetic builds
that use LLVM_ENABLE_DIA_SDK. But the build system still has to
manually pass flags pointing to it.
Since we have a /winsysroot flag, make it look at DIA SDK in
the sysroot.
With this, the following is enough to compile the DIA2Dump example:
out\gn\bin\clang-cl ^
"sysroot\DIA SDK\Samples\DIA2Dump\DIA2Dump.cpp" ^ "sysroot\DIA SDK\Samples\DIA2Dump\PrintSymbol.cpp" ^ "sysroot\DIA SDK\Samples\DIA2Dump\regs.cpp" ^ /diasdkdir "sysroot\DIA SDK" ^ ole32.lib oleaut32.lib diaguids.lib
Given that the DIA SDK is part of the MSVC installation (at C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\DIA SDK on my machine), I think there's a case for letting clang-cl know about it. Arguably, adding /I sysroot\DIA SDK\include to your cflags isn't super difficult, but one day we'll teach lld-link about /winsysroot too, and then it means you don't need to know about the lib\ folder layout inside DIA SDK. Also, if you link through clang-cl instead of calling the linker directly, you get that simplification with this change already. That's nice for local one-off commands, but in practice most projects admittedly call link.exe directly.
So all-in-all, I think this is a good idea, but I could be convinced otherwise if others disagree.
Maybe move the arch functions up to before visualstudio::Linker::ConstructJob instead?
The file is already kind of organized in that way, with lots of static helper functions on top, and then the implementations of the member functions.