Add support for building with clang-cl

[solemnwarning]

Both x86_32 and x86_64 build using the appropriate toolchain from VS2022, all tests pass except for the following in both cases:

System Certificate Store - Find Certificate by UTF8 subject DN ran 1 tests in 1.04 msec 1 FAILED
Failure 1: found certificate was nullopt (at src/tests/test_certstor_system.cpp:306)

[coveralls]

coverage: 90.677%. remained the same when pulling 09544fbc30774221633c9d5276a34fd2a8dfbec9 on solemnwarning:clang-cl into 1f99875554c5f268c2703ad92618f6f50e7e8491 on randombit:master.

[solemnwarning]

It turns out the aforementioned test failure isn't specific to the clang-cl build - it happens with MSVC too, I think its failing because my Windows VM doesn't have the "D-TRUST Root Class 3 CA 2 EV 2009" certificate the tests are looking for.

[reneme]

That's certainly possible. If I recall correctly, the certstore tests are looking for more than one cert. so if it fails for just that one, you're probably right.

[reneme]

@solemnwarning could you rebase to master and see if the test succeeds on your platform now?

[solemnwarning]

@reneme

I rebased onto master and the tests still failed... they do pass if I import the "D-TRUST Root Class 3 CA 2 EV 2009" certificate into the trust store though, so clearly my test VM is lacking certificates that everyone else apparently has.

Regarding /Zc:preprocessor, it still builds okay, so I assume its fine without?

[reneme]

Regarding /Zc:preprocessor, it still builds okay, so I assume its fine without?

I added that for a change in the tests. So if the unit tests (make tests) still build fine, I'd also conclude that it's not needed.

they do pass if I import the "D-TRUST Root Class 3 CA 2 EV 2009"

:+1:

[solemnwarning]

@randombit @reneme

Are either of you anticipating me making any changes on this PR? The remaining points seem to be a bit "maybe do something".

[reneme]

Are either of you anticipating me making any changes on this PR?

This is awaiting approval by @randombit

[randombit]

@solemnwarning Sorry about the long wait here. This needs a rebase and squash but otherwise is probably ok to land. I'm not tremendously happy about the clang rt thing but it seems a longstanding issue and unlikely to be fixed anytime soon so I guess we have to just live with it. Once this is merged we can add a CI build and then iterate from there.

[solemnwarning]

@randombit I've merged the changes from master with mercifully few conflicts and made a couple of further changes:

• Updated src/build-data/cc/clangcl.txt per https://github.com/randombit/botan/pull/4255#discussion_r1860111585 and https://github.com/randombit/botan/pull/4255#discussion_r1740640307
• Removed BOTAN_PUBLIC_API from Botan::IPAddressBlocks::Version definition as per the earlier change to p11.h.

[randombit]

@solemnwarning I missed your message until now. There is another merge conflict 😅 hopefully minor. I will re-review asap.

[solemnwarning]

@randombit updated

[randombit]

@solemnwarning Last time I promise :sweat_smile: but can you rebase against master again [*] and also squash the commits? Just to a single commit with a reasonable description is fine. Beyond this LGTM/ready to merge for 3.10.

[*] There is no explicit merge conflict but there were a lot of changes to clang-tidy configuration in the last couple of months and I think it's possible to cause failures on master if we merge something that passes with the old clang-tidy config but causes errors in the new config.