Support somewhat recent clang versions on Windows

[cmb69]

Prior to clang 10.0.0, clang-cl -v apparently always appended some fine grained version information in parentheses[1]; this is no longer the case, so the build fails early because the compiler version could not be detected. Since we never used this fine grained version info, we no longer check for it.

As of clang 13.0.0, the /fallback command option has been removed[2], so we only set the flag for older clang versions.

[1] #11313 (comment)
[2] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#removed-compiler-flags

---

With these changes I've managed to have a successful minimal build (--with-toolset=clang --disable-all --enable-cli) with clang 18.1.8 on x64 Windows (didn't try x86 so far), if I set CFLAGS=-Wno-implicit-function-declaration. I'm going to follow up with a patch for the undeclared functions.

[cmb69]

Note that all compilation errors with clang 18.1.8 (default configuration; full x64 snapshot build with all dependencies) have been fixed (PR #15329 is pending, but approved), except for a typedef redifinition (signed char vs. char) in the SNMP headers, but this library should be updated anyway.

[cmb69]

Oh, I've noticed that there are related issues regarding --enable-sanitizer. As of clang 16.0.0 (and maybe version 15; I haven't checked that), the libraries are in a folder which does no longer consist of the full version number (16.0.0), but only the major version (16). And for non-default installation folders of LLVM (e.g. used by the clang shipped with Visual Studio), we cannot assume PROGRAM_FILES as prefix; it might be possible to solve this by using the InstalledDir reported by clang-cl -v; that would need to be checked more thoroughly.

And not necessarily related: UBSan appears to broken; for standalone clang 18.1.8 it seems to report bogus undefined behavior when running nmake run ARGS=-v; and for clang shipped with VS, their are linker errors due to undefined symbols (__ubsan_*).

[ndossche]

Ah I read the code and tested it before I saw your latest message. Didn't check ubsan & co.

[cmb69]

No problem. We can merge this, and work on sanitizer support in another PR. :)

I'm already happy to be able to build with clang on Windows for the better (or more intuitive) errors/warnings. MSVC error codes are not nice to handle. Working ASan and UBSan support would be the icing on the cake.

[ndossche]

Agreed.