clang-cl CI

[nico-abram]

This adds a new windows CI configuration for clang-cl

clang-cl.exe is a driver/frontend for clang that ships with the windows clang binaries that LLVM distributes that accepts the same command line arguments as cl.exe(the MSVC compiler).

I had to comment a "MANIFEST:NO" linker flag that seems to be unsupported by clang, and disable /GL (LTO) for crashpad.

I'm not sure if this is worth adding but it might be nice to track support so we don't break it, since some people might want to develop on windows using clang, and we could also consider using clang-cl as the compiler for releases after testing how the resulting binaries compare (performance, size, etc)

[nico-abram]

To run locally, just download the latest LLVM for windows from https://github.com/llvm/llvm-project/releases (LLVM-X.X.X-win64.exe) , make sure it's /bin folder is in your path, then set these 4 env vars in your shell:

set CC=clang-cl
set CXX=clang-cl
set CFLAGS=-m64
set CXXFLAGS=-m64

And run cmake as usual i.e cmake -G "Ninja" -DWITH_CRASHPAD=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo ..

To make sure clang-cl is being used, you can either check the cmake output which should say

-- The C compiler identification is Clang 13.0.0 with MSVC-like command-line
-- The CXX compiler identification is Clang 13.0.0 with MSVC-like command-line
-- The ASM compiler identification is Clang with MSVC-like command-line
-- Found assembler: D:/LLVM13/bin/clang-cl.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: D:/LLVM13/bin/clang-cl.exe - skipped

Or run ninja in verbose mode ninja Etterna -v and make sure the compiler being used is clang-cl.

[poco0317]

Mergeable but concerned about cmakelist changes having unintended effects

[nico-abram]

The /MANIFEST:NO option is documented here

Specifies whether the linker should create a side-by-side manifest file.
A manifest file isn't created if you specify /MANIFEST:NO.

I don't see how removing it and making it use the default (Which creates the file) would have unintended side effects. I removed it since the clang linker doesn't understand the option.

The /GL- change is a bit more subtle: /GL is whole program optimization, also known as "LTO". As I understand it, this makes the compiler (cl.exe) generate a compiler-specific intermediate representation in the object files it outputs instead of machine code, which the linker later uses to actually generate the machine code (Allowing more optimizations to happen in the linker). I think using this option (Which crashpad does) resulted in a linker error about an invalid object file. /GL- just disables /GL . My understanding is that should, at most, affect performance, which is a reasonable concern. I'll see if I can figure out a way to only apply it when building for clang-cl.

cc @jameskr97 in case you have the time to give the 2 small cmake changes in this PR a lookover

[poco0317]

Wondering if manifest related changes has anything to do with #1204

[graemephi]

Yeah I noticed that--that makes me wonder why #1204 worked at all. By the way, I tried /GL a few years ago and it reduced performance