rules_android has repository visibility issues with Bazel 9 when the
Android SDK is present. Since we don't use Android, disable detection
by setting ANDROID_HOME to empty.
Bazel 9 moves the C++ runfiles library from @bazel_tools to @rules_cc.
Update zipmerge_test.cpp:
- Change include from tools/cpp/runfiles to rules_cc/cc/runfiles
- Update namespace from bazel::tools::cpp::runfiles to rules_cc::cc::runfiles
Note: The BUILD.bazel dependency change is in a separate commit.
Add explicit load statements for java_library and java_test from
@rules_java//java:defs.bzl in:
- javascript/extractor/BUILD.bazel
- javascript/extractor/test/com/semmle/js/extractor/test/BUILD.bazel
Add +@rules_cc to --incompatible_autoload_externally to enable
graceful migration path for cc_* rule usages before all files
are updated with explicit imports.
rules_python 1.x requires explicit toolchain setup and no longer
auto-registers toolchains. Register Python 3.12 toolchain to ensure
Python tools work correctly with Bazel 9.
Handle crate versions containing `+` build metadata (e.g., `0.9.11+spec-1.1.0`).
Bazel repo names use `-` instead of `+`, so the generated labels need patching
to reference the correct repo name.
Also adds documentation for both patching issues handled by patch_defs.py.
An example (provided by @redsun82) is the string `f"{x:=^20}"`. Parsing
this (with unnamed nodes shown) illustrates the problem:
```
module [0, 0] - [2, 0]
expression_statement [0, 0] - [0, 11]
string [0, 0] - [0, 11]
string_start [0, 0] - [0, 2]
interpolation [0, 2] - [0, 10]
"{" [0, 2] - [0, 3]
expression: named_expression [0, 3] - [0, 9]
name: identifier [0, 3] - [0, 4]
":=" [0, 4] - [0, 6]
ERROR [0, 6] - [0, 7]
"^" [0, 6] - [0, 7]
value: integer [0, 7] - [0, 9]
"}" [0, 9] - [0, 10]
string_end [0, 10] - [0, 11]
```
Observe that we've managed to combine the format specifier token `:` and
the fill character `=` in a single token (which doesn't match the `:` we
expect in the grammar rule), and hence we get a syntax error.
If we change the `=` to some other character (e.g. a `-`), we instead
get
```
module [0, 0] - [2, 0]
expression_statement [0, 0] - [0, 11]
string [0, 0] - [0, 11]
string_start [0, 0] - [0, 2]
interpolation [0, 2] - [0, 10]
"{" [0, 2] - [0, 3]
expression: identifier [0, 3] - [0, 4]
format_specifier: format_specifier [0, 4] - [0, 9]
":" [0, 4] - [0, 5]
"}" [0, 9] - [0, 10]
string_end [0, 10] - [0, 11]
```
and in particular no syntax error.
To fix this, we want to ensure that the `:` is lexed on its own, and the
`token(prec(1, ...))` construction can be used to do exactly this.
Finally, you may wonder why `=` is special here. I think what's going on
is that the lexer knows that `:=` is a token on its own (because it's
used in the walrus operator), and so it greedily consumes the following
`=` with this in mind.
