Turbine error: unexpected input: when using Java 21 String Templates in java_library with javacopts = ["--enable-preview"], #21119
Comments
FYI 7.0.2 still seems to have this problem as well (change |
|
Adding this (found in bazelbuild/rules_java#141) to I'm now experimenting with using |
I had hoped this may fix bazelbuild/bazel#21119, it unfortunately does not - but I'll still keep it.
I had hoped this may fix bazelbuild/bazel#21119, it unfortunately does not - but I'll still keep it.
I had hoped this may fix bazelbuild/bazel#21119, it unfortunately does not - but I'll still keep it.
done in https://github.com/enola-dev/enola/pull/436/files - but that does not fix this. With that, I'm out of depth, and moving on for now without using Java String Templates... 😭 |
|
Huh, this is fun - with some more trial and error, I was able to see that Java 21 String Templates do work for |
|
Thanks for the report, the underlying problem is that turbine doesn't support string templates yet. I filed google/turbine#303 to track that.
That's consistent with any turbine issue, header compilation only happens for targets that are dependencies of other targets. It doesn't run when compiling a top-level target like |
|
ACK! FYI https://github.com/vorburger/bazel-multiline-problem created for standalone reproducer, if useful. |
Actuallly it's slightly different - that initial one was just for a multiline string, without variable, this is about with a variable. |
https://github.com/google/turbine/releases/tag/v0.4.0 ``` REPIN=1 bazel run @unpinned_maven//:pin bazel mod deps --lockfile_mode=update ``` bazelbuild#21119
|
Using the latest turbine version from #21128 fixes the original repro for me. I used the steps in bazelbuild/java_tools#43 (comment) to build a version of the prebuilt tools. Passing The test subsequently fails because Passing |
https://github.com/google/turbine/releases/tag/v0.4.0 ``` REPIN=1 bazel run @unpinned_maven//:pin bazel mod deps --lockfile_mode=update ``` bazelbuild#21119
https://github.com/google/turbine/releases/tag/v0.4.0 ``` $ REPIN=1 bazel run @unpinned_maven//:pin $ bazel mod deps --lockfile_mode=update ``` #21119 Closes #21128. PiperOrigin-RevId: 602978649 Change-Id: I22d6987bd68ee661e7183dae1396c6426c695ce8
|
I think it would be good to get this into a |
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
@bazel-io fork 7.1.0 |
bazel-io
removed
the
potential release blocker
|
@iancha1992 This will require not just a cherry-pick, but also a Since bazelbuild/java_tools#87 (comment) got stuck anyway, retrying it should pick up this change. cc @hvadehra |
Cherry-pick of f697132 bazelbuild#21119
|
Yep, that's the commit. I might be easier to just re-create it against 7.1.0 because of the lockfile changes, I created #21161 |
Cherry-pick of f697132 bazelbuild#21119
|
Thanks! |
Cherry-pick of f697132 bazelbuild#21119
|
java_tools & rules_java releases are done. |
Description of the bug:
#15083 -like, looks like that isn't quite working with Bazel 7.0.0 ?
@cushon FYI
Which category does this issue belong to?
Java Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release?release 7.0.0
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.N/A
What's the output of
git remote get-url origin; git rev-parse HEAD?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: