* do not mention any more that one might make analysis happen on Linux with
advanced setup
* say that outright Swift analysis is only supported on macOS, not just
autobuild.
* emit the error diagnostics even for traced builds, not only for autobuilds
(by using a dummy `extractor` executable).
Previously, we were using 8.0.0rc1.
In particular, this upgrade means we need to explicitly
import more rules, as they've been moved out of the core bazel repo.
This encapsulate arch specific logic, local installation and separation
of zip files into generic and arch-specific parts as required by the
internal build.
This introduces tooling and enforcement for formatting bazel files.
The tooling is provided as a bazel run target from
[keith/buildifier-prebuilt](https://github.com/keith/buildifier-prebuilt).
This is used in a [`pre-commit`](https://pre-commit.com/) hook for those
having that installed. In turn this is used in a CI check. Relying on a
`pre-commit` action gives us easy checking that buildifying did not
change anything in the files and printing the diff, without having to
hand-roll the check ourselves.
This enforcement will make usage of gazelle easier, as gazelle itself
might reformat files, even outside of `go`. Having them properly
formatted will allow gazelle to leave them unchanged, without needing
to configure awkward exclude directives.
These are currently added implicitly by the compiler in the context of
`if`/`switch` expressions. In the future, there might be explicit
`then <expr>` statement useful for cases where one would like to add
more than one statement in the branch, to mark what value to actually
use.
See https://forums.swift.org/t/pitch-multi-statement-if-switch-do-expressions/68443
