Replaced clang-cl for MSVC Compiler on Windows

[corco]

MSVC is the default compiler on Windows and switching verible to use it would alleviate some pain points of using bazel on Windows.

For context, clang-cl was originally used because designated identifiers are used in the codebase, which are only supported by C++20 in MSVC, which was not available at the time. Also, MSVC would crash on the codebase, which is no longer the case.

I left the option to use clang-cl, but this is theory as I don't have a Windows system to verify. I removed reference to clang-cl from the doc, so this support is only for devs actively looking for it. It could be removed from .bazelrc if you prefer. As a side note, I don't think adding clang-cl to CI has value since we already build with clang on Linux.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: corco / name: Jonathan Drolet (77178ce, a5b4b19, d6d3a94, f7da6ef)

[hzeller]

Were you able to resolve the compile issue in the CI ? (i can't see the log anymore, so maybe you have to rebase and re-trigger).

It would be interesting to see if we can also make
#2524
working with this change, then we can avoid the extra work with the flex/bison to be installed.

[corco]

I don't remember where it failed, it was either on tests or other platforms.

I don't have a Windows box anymore, and the main issue (tree-operations.h) is still beyond my comprehension. I am putting AI to the task, it seems to have a reasonable fix for it.

[hzeller]

Uh, I wonder what is up with the protobuf include in the context of rust that is breaking...
But overall looks like you're making good progrress, thanks!

[corco]

Uh, I wonder what is up with the protobuf include in the context of rust that is breaking...

But overall looks like you're making good progrress, thanks!

That's the reason MSVC was deprecated (protocolbuffers/protobuf#20085). A newer bazel version is required to compile without error.

I think we have a path forward with MSVC, the code change is minimal. However, it requires updating bazel in order to compile protobuf. The update to protobuf itself is optional, we can keep the current version if we add the right compile flag.

Updating bazel should be a separate task, once it's done we can merge MSVC support.

[hzeller]

So to move to bazel 8, we need to solve the flex-bison issue #2435

I have two solutions, somewhat sitting as drafts, that should be re-activated.

• Make biso/flex work with local and BCR tools work with bazel 8 #2520 that works, but is ugly
• Use flex and bison directly instead from toolchain. #2524 which is nicer, but currently does not work yet on Windows (some autoconf issue of sorts).

So to resolve this, we might start with #2520 which allows to move to bazel8.
Then get your Windows change in, and then see if we get more luck with driving forward #2524 with MSVC.

So here might be a sequence:

• Please break this change here into independent parts that should work in any case, the iterator and template changes in editscript, tree utils and such. That we then can get in independently. That leaves us to hopefully only needing to then later update the .bazelrc
• I submit Make biso/flex work with local and BCR tools work with bazel 8 #2520 moving us to bazel8+ (I'll add you as reviewer)
• ^^ The above two can be done in parallel.
• You can add the change that changes the compiler in .bazelrc (essentially this PR, but only the compiler change)
• At that point, we can build everything with bazel 8 and bazel 9 on all operating systems and in particular with msvc on Windows.
• then I can re-tackle Use flex and bison directly instead from toolchain. #2524 and see if this will be easier or harder.

[hzeller]

Added you as reviewer of #2520 so that we can get bazel 8+ unlocked.

[corco]

Added you as reviewer of #2520 so that we can get bazel 8+ unlocked.

I will modify the PR to only include code changes.

Meanwhile, have you looked at the changes in bazel/ directory from this PR? This is what the AI came up with (along with --action_env=PATH line in .bazelrc). I don't mind either that or #2520, but I think the no_toolchain is a little cleaner.

[hzeller]

ah, nice. I agree, the no-toolchain solution looks better.

[corco]

Alright, I split this PR and the other section are merged. All left is update to .bazelrc and ci to actually use msvc!

[hzeller]

Nice, thank you!