cmake: Adjust diagnostic flags for clang-cl

[hebasto]

When building with clang-cl on Windows, the output is cluttered with warning messages because compiler diagnostic flags are not applied correctly:

> cmake -B build -G Ninja -DCMAKE_C_COMPILER="C:\Users\hebasto\Downloads\clang+llvm-18.1.8-x86_64-pc-windows-msvc\bin\clang-cl.exe"
> cmake --build build
[1/16] Building C object src\CMakeFiles\bench.dir\bench.c.obj
In file included from C:\Users\hebasto\secp256k1\src\bench.c:11:
C:\Users\hebasto\secp256k1\src\util.h(34,13): warning: unused function 'print_buf_plain' [-Wunused-function]
   34 | static void print_buf_plain(const unsigned char *buf, size_t len) {
      |             ^~~~~~~~~~~~~~~
1 warning generated.
[2/16] Building C object src\CMakeFiles\secp256k1_precomputed.dir\precomputed_ecmult_gen.c.obj
In file included from C:\Users\hebasto\secp256k1\src\precomputed_ecmult_gen.c:3:
In file included from C:\Users\hebasto\secp256k1\src\group.h:10:
In file included from C:\Users\hebasto\secp256k1\src\field.h:10:
C:\Users\hebasto\secp256k1\src\util.h(34,13): warning: unused function 'print_buf_plain' [-Wunused-function]
   34 | static void print_buf_plain(const unsigned char *buf, size_t len) {
      |             ^~~~~~~~~~~~~~~

This PR resolves this issue.

---

Additional note for reviewers: The VS builtin clang can also be used assuming that the following VS components are installed:

The user can generate a build system on Windows as follows:

• Using the default "Visual Studio" generator:

cmake -B build -T ClangCL

• Using the "Ninja" generator:

cmake -B build -G Ninja -DCMAKE_C_COMPILER=clang-cl

---

Required for downstream projects which aim to build with clang-cl (see bitcoin/bitcoin#31456).

[real-or-random]

I guess the patch is trivial enough not to bother, but I'm not entirely sure if I understand the purpose of this. Couldn't you build using clang on Windows directly? Or is the purpose of this PR to help users who want to use Visual Studio but with clang instead of MSVC? My thinking is that if you use Visual Studio for an application that depends on libsecp256k1, you don't bother how libsecp256k1 itself is built.

[hebasto]

I guess the patch is trivial enough not to bother, but I'm not entirely sure if I understand the purpose of this. Couldn't you build using clang on Windows directly? Or is the purpose of this PR to help users who want to use Visual Studio but with clang instead of MSVC? My thinking is that if you use Visual Studio for an application that depends on libsecp256k1, you don't bother how libsecp256k1 itself is built.

My apologies for any confusion. The PR description has been reworked.

[real-or-random]

utACK 4c50d73

[theuni]

utACK other than the nit.

[theuni]

I'd prefer to set /W3 here and -Wall with the other try_append_c_flags for consistency, as I don't see why it needs to be special-cased.

Edit: Retracted, see below.

[hebasto]

According to the docs, the /Wall option in clang-cl, which is equivalent to -Wall, enables Clang's core -Weverything option.

We use /W3, which enables Clang's core -Wall option.

[theuni]

Wow. Confirmed: https://godbolt.org/z/WEr3qGeox

That's... hugely unexpected. It really doesn't give me much faith in the proper forwarding of other options :(

[real-or-random]

That's... hugely unexpected. It really doesn't give me much faith in the proper forwarding of other options :(

Hm, I see that it can be unexcepted, but I also understand why they do this, and mapping these generic warning options is only a best-effort thing. (I believe the objectively most confusing thing here is the existence of -Wall alongside -Weverything... It's just not confusing to us because we're familar with gcc.)

[hebasto]

@real-or-random @jonasnick

Ready to merge?