[bazel] Update Bazel to version 7.3.1

[jwnrt]

This is a major version upgrade from Bazel 6.1.1 to Bazel 7.3.1. This is the latest version.

This PR includes a couple of fixes required due to changes between versions:

1. The airgapped build no longer clones the Bazel Git repository to access its dependencies, it now uses the method described here in the Bazel documentation: https://bazel.build/run/build#repository_cache_with_bazel_7_or_later.
2. The fusesoc_build rule no longer outputs the whole of fusesoc's $X.build/ directory, it now only exposes the parts explicitly listed in output_groups. This is required because Bazel 7 does not allow rules to output both a directory and its contents at once.

This PR is motivated in part because some of our dependencies (e.g. rules_rust) no longer support version 6. Migrating to Bzlmod will also require Bazel 7 since version 6 is missing a couple of features we need.

Potential for breakage

CI should pick up any breakages, but we should also check that contributors using non-Ubuntu distributions can still use this new Bazel version.

Contributors using ./bazelisk.sh should not need to manually install the new Bazel version, it should be installed automatically. Those using a native Bazel will have to update, but Bazel will read the .bazelversion file and tell them how to do this.

[jwnrt]

I was too hasty in marking as ready for review. The strange license_checker breakage observed in #24216 has appeared here. I'll try work out what's going on.

[jwnrt]

The sw_build job in CI is finding a bunch of problems with our C code now. Not sure what changed in Bazel 7 to make these identified or why only sw_build is finding them. They don't appear when I bazel build the targets separately.

Some examples of new warnings (which it treats as errors):

1. Missing newlines at the end of files (e.g. the generated hw/ip/uart/data/uart_regs.h.
2. Semicolons repeated inside and outside a macro (e.g. with sw/device/lib/arch/device_fpga_cw305.c using CALCULATE_UART_NCO).
3. Enum values being out of range for int. We do this a lot. Usually it's for u32s.
   • Apparently ISO C requires they fit into int but GCC promises to using u32 if not signed. Not sure what Clang promises.
   • Not sure how to fix this. We use enums everywhere for constants. Do we change the style guide? Ignore this warning?

[a-will]

The sw_build job in CI is finding a bunch of problems with our C code now. Not sure what changed in Bazel 7 to make these identified or why only sw_build is finding them. They don't appear when I bazel build the targets separately.

Wrong target, probably (or more accurately, the wrong configuration). This target triggers errors, for example:

./bazelisk.sh build //sw/device/silicon_creator/manuf/base:ft_provision_fpga_cw340_rom_with_fake_keys

Some examples of new warnings (which it treats as errors):

1. Missing newlines at the end of files (e.g. the generated hw/ip/uart/data/uart_regs.h.

2. Semicolons repeated inside and outside a macro (e.g. with sw/device/lib/arch/device_fpga_cw305.c using CALCULATE_UART_NCO).

3. Enum values being out of range for int. We do this a lot. Usually it's for u32s.

   • Apparently ISO C requires they fit into int but GCC promises to using u32 if not signed. Not sure what Clang promises.
   • Not sure how to fix this. We use enums everywhere for constants. Do we change the style guide? Ignore this warning?

If you compare the subcommands, you'll notice that -Wpedantic got added. If we're going to use this style for enums, we really should either update to C23 or use one of the GNU --std modes.

Edit: Aww, bummer, I thought C23 was finalized already. In that case, for an ISO standard, we still only get sized enums in c++ compilation modes.

[jwnrt]

@pamaury and I found the cause of the pedantic errors: Bazel has changed --features to only apply to the exec target and not host. We set --features=-pedantic_warnings in .bazelrc, but bindgen builds our software with host so this wasn't being applied. See bazelbuild/bazel#13839.

Added a commit which adds --host_features flags to `.bazelrc.

We also found that the rules_rust we're currently using does not seem to properly support Bazel 7. bazel query 'deps(//some/rust/target)' was giving an unusual error:

$ bazel query 'deps(//sw/device/silicon_creator/manuf/base:ft_provision_fpga_cw340_rom_with_fake_keys)'

ERROR: Evaluation of query "deps(//sw/device/silicon_creator/manuf/base:ft_provision_fpga_cw340_rom_with_fake_keys)" failed: preloading transitive closure failed: no such package '@@rules_rust_util_import__syn-1.0.82//': The repository '@@rules_rust_util_import__syn-1.0.82' could not be resolved: Repository '@@rules_rust_util_import__syn-1.0.82' is not defined

To fix this, I have had to bundle the rules_rust upgrade into this PR which increases its size but hopefully we can still get this reviewed.

We cannot upgrade rules_rust first in a separate PR because new versions do not support Bazel 6. It's possible we could find a version that supports 6 and 7 which I will investigate if this PR is too large to review / merge.

[jwnrt]

Sorry for the spam, we found a simpler way to fix the Rust issue without upgrading the toolchain just yet.

[jwnrt]

Hmm, using symlinks doesn't seem to work because ctx.actions.symlink does not have an inputs parameter so Bazel just creates the symlink without building the thing it's linking to.

I guess target_file is supposed to be like inputs, but as previously mentioned we can't create a file to the targets because they're within a directory that is being output.

I can't think of a way to make this work, so reverting back to the previous implementation.

[pamaury]

That's great, thanks a lot @jwnrt for this work!