Fix Unicode matching for regex options #26100
Conversation
github-actions
bot
added
team-Configurability
fmeum
force-pushed
the
26070-unicode-regex
branch
from
f70160b to
f478b87
Compare
tjgq
added
awaiting-PR-merge
|
We are encountering https://buildkite.com/bazel/google-bazel-presubmit/builds/92308#0196f4a3-acb1-44c4-8178-f3fa0130833d while importing this, @fmeum can you take a look what's missing? |
Is this running on more than just the Bazel source code? I can't reproduce this issue. My guess is that you might still be using |
|
The change is exported at https://bazel-review.git.corp.google.com/c/bazel/+/281454, but I'm not seeing any obvious difference. |
|
I can reproduce with |
|
Probably caused by https://cs.opensource.google/bazel/bazel/+/master:src/BUILD;l=549?q=java_tools_java8&ss=bazel, but not sure why presubmit on github didn't fail |
passes for me, but I agree that the Java 8 transition should cause compilation to fail for that archive. I can still build it locally, not sure why. is still corp-only, unfortunately. |
|
Looks like this change doesn't play well with cff5907 on the master branch. If you rebase, you'll see the failure in Github presubmit. |
|
Right, just found cff5907 as well. I will rebase and fix this. |
fmeum
force-pushed
the
26070-unicode-regex
branch
from
f478b87 to
de2c470
Compare
It redirect to the corp address for me, the original URL can be found in the Buildkite pipeline: 
https://bazel-review.googlesource.com/q/55b225e5e6a5c8aa33de575c840efd41983b0462 should probably work? |
|
Yes, that link works. While I can fix the CI failure quite easily, the java_tools setup still doesn't work properly: It forces the Java language level to 8 in a transition, but keeps the Java 21 runtime as the compilation target. This means that it won't detect usage of newer API, which makes the resulting java_tools incompatible with JDK 8. |
|
I will send a separate PR to fix the version confusion. CC @hvadehra |
Prebuilt Java tools meant to run on the user-specified `--java_{tool_,}runtime_version` must only use Java 8 language features and APIs. Previously, these tools were compiled with `--java_language_version=8`, but had access to a JDK 21 as the bootclasspath. In fact, `junitrunner` used `Stream#dropWhile`, which isn't available in a JDK 8.
Similarly, Java tools meant to run on the Java runtime provided by a Java (compilation) toolchain must only use Java 11 language features and APIs. This was the case, but they were in fact build with `--java_language_version=8` and a JDK 21, just like the other tools, thus lacking validation for this property.
This PR splits tools into two groups and enforces consistent Java language and bootclasspath runtime for them via `--@rules_java//toolchains:incompatible_language_version_bootclasspath`. Constants in `//src:release_archive.bzl` can be used to set the two minimum versions globally.
fmeum
force-pushed
the
26070-unicode-regex
branch
from
4c2058a to
f0dcdc3
Compare
|
I rebased onto #26126 and the issue should now be fixed. |
fmeum
force-pushed
the
26070-unicode-regex
branch
from
f0dcdc3 to
e1ee0fd
Compare
The `Pattern` class needs to operate on ordinary "Unicode" Java string, whereas both option values and strings matched against the pattern are in Bazel's internal string encoding. This requires reencoding in the right places. Along the way, optimize literal regex matches - this was missed in 662c0f0.
fmeum
force-pushed
the
26070-unicode-regex
branch
from
e1ee0fd to
88a4543
Compare
|
@fmeum Could you please take a look at the presubmit errors? Thanks! |
|
@iancha1992 Let's get #26126 reviewed and merged first, then CI can be fixed by rebasing. |
The
Patternclass needs to operate on ordinary "Unicode" Java string, whereas both option values and strings matched against the pattern are in Bazel's internal string encoding. This requires reencoding in the right places.Along the way, optimize literal regex matches - this was missed in 662c0f0.
Fixes #26070