Upgrade to Bazel 6, modern protobufs, etc

[neilconway]

• Upgrade to Protobuf 29.3 and fix resulting minor breakages to APIs and build rules. This is necessary in order for stout to be used with Bazel projects that depend on newer versions of Protobuf.

• Upgrade to recent abseil. This is necessary due to the protobuf upgrade.

• Upgrade to Bazel 6. This is necessary because recent abseil does not build with Bazel 5.

• Use proto_library and cc_proto_library from @com_google_protobuf, rather than rules_proto and rules_cc, respectively. The latter sources are deprecated.

[neilconway]

• Builds and passes bazel test //... on both Mac ARM64 (Apple clang) and Linux x86-64. It doesn't build with llvm@14 from brew on Mac for some reason (it doesn't like the chosen linker), I haven't had a chance to investigate why yet.
• CI check_code_style is broken because the upstream LLVM apt repo we're using doesn't package LLVM14 for the latest Ubuntu. I suppose in the short-term we should use an older runner, but medium-term it probably doesn't hurt to upgrade to a more recent LLVM, both here and for the mono repo.

[rjhuijsman]

• I suppose in the short-term we should use an older runner, but medium-term it probably doesn't hurt to upgrade to a more recent LLVM, both here and for the mono repo.

Yes, we should use an older ubuntu for now I guess. Upgrading to a newer LLVM will require some code changes, but yes, will be useful maintenance for us - but ideally as a separate lift!

[neilconway]

Yes, we should use an older ubuntu for now I guess. Upgrading to a newer LLVM will require some code changes, but yes, will be useful maintenance for us - but ideally as a separate lift!

I filed https://github.com/reboot-dev/mono/issues/4284 for the llvm-upgrade issue.

[rjhuijsman]

• Builds and passes bazel test //... on both Mac ARM64 (Apple clang) and Linux x86-64. It doesn't build with llvm@14 from brew on Mac for some reason (it doesn't like the chosen linker), I haven't had a chance to investigate why yet.

I ran into https://github.com/reboot-dev/mono/issues/4280 yesterday; could your version of Xcode be the issue?

[neilconway]

I ran into reboot-dev/mono#4280 yesterday; could your version of Xcode be the issue?

The issue I ran into is almost the opposite: stout builds fine with the latest XCode, but doesn't build with llvm@14 from brew (+ brew link):

ERROR: /private/var/tmp/_bazel_neilconway/a25a7bf1b93278d2299c396396750af6/external/com_google_protobuf/third_party/utf8_range/BUILD.bazel:42:11: Linking external/com_google_protobuf/third_party/utf8_range/libutf8_range.dylib failed: (Exit 1): cc_wrapper.sh failed: error executing command (from target @com_google_protobuf//third_party/utf8_range:utf8_range) external/local_config_cc/cc_wrapper.sh @bazel-out/darwin_arm64-fastbuild/bin/external/com_google_protobuf/third_party/utf8_range/libutf8_range.dylib-2.params

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
clang: error: invalid linker name in argument '-fuse-ld=ld64.lld:'

[rjhuijsman]

What version of OSX are you experiencing this on? It looks like ld64 may have been deprecated? But I also don't understand why LLVM wants to use that when it has its own..?

Aside from that, the Mac CI on this PR seems to be failing for yet another reason:

external/com_google_absl/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported."

[neilconway]

Aside from that, the Mac CI on this PR seems to be failing for yet another reason

I looked into this. For some reason that is not at all clear to me, on some platforms (e.g., macos-latest CI but not ubuntu-latest CI or my local Mac ARM laptop), Bazel uses host_cxxopt to compile abseil, not cxx_opt. Perhaps because there's some dependency that needs protobuf, to run protobuf we first need to build protobuf, and to build protobuf we first need to build abseil? And because protobuf is a tool, in this case we'd use host_cxxopt not cxxopt. Bizarre but at least plausible.

I fixed that by adding -std=c++17 to host_cxxopt as well. That fixes MacOS CI, but Windows CI is now broken 🙃

bazel-out/x64_windows-opt-exec-2B5CBBC6/bin/external/com_google_protobuf/src/google/protobuf/compiler/csharp/_virtual_includes/csharp\google/protobuf/compiler/csharp/csharp_field_base.h(19): fatal error C1083: Cannot open include file: 'google/protobuf/compiler/csharp/csharp_source_generator_base.h': No such file or directory

That sounds suspiciously like this protobuf issue, which arises because the combination of protobuf's source layout and how Bazel works means it is very easy to exceed the 260 character limit on MSVC filename lengths! It's not exactly clear why adding c++17 to host_cxxopt triggers this issue though.

Note that a comment in that GitHub issue helpfully notes:

The severe file length limits under by bazel+msvc are a known painpoint, not just for external users but also for the protobuf team's development itself (we have been warping our own file names and directory structure to keep our max length of paths to be approx 60 chars, with remainder of the 260 character limit is burned by other overhead).

Since we don't have any good way to mitigate this issue, and because bazel+msvc usage is low compared to other ways to build on Windows, we are planning to drop support for bazel+msvc in Protobuf 34 (the Q1 2026 release). Bazel 30 already disables support for this combination, with a flag to reenable support for it which gives time to gather feedback on this as well as give folks a longer horizon to migrate their builds to either make+msvc or bazel+clang-cl

So if we care about stout on Windows, we probably want to switch to clang instead of MSVC.

[neilconway]

@rjhuijsman wdyt about leaving CI on Windows broken for now? As mentioned above, longer-term we probably need to move stout to building with clang on Windows, but that doesn't seem worth my spending time on at the moment.

[rjhuijsman]

There's something in the back of my head saying Windows CI was already broken, even? @onelxj would know for sure. Or you can look at what an old PR looks like (I would, but I'm on my phone).

I'm ok with keeping Windows CI broken. And bonus points if you can comment out the Windows check before submitting so I don't have to try to remember for next time. 😄

[neilconway]

@rjhuijsman You might be referring to the fact that stout CI on windows-latest was previously broken because of a bug in Bazel 5, so we had to run on windows-2019. With this PR, moving to Bazel 6 should address the issue with windows-latest... but we are now suffering from this other issue 😅

[rjhuijsman]

Got it. But yes, your point stands, not worth your time right now maintaining support for a platform we don't build for.

[neilconway]

@rjhuijsman Can we land this now? It should be safe, as the submodule SHA in mono should still point at the previous commit. We should be close to landing B6 in mono anyway and we can then update the submodule SHA in mono at that point.

[neilconway]

OK, so we think Bazel 6 in mono is close enough to land this? Let's do it! 🎉

Yes, we are close!