Generate error-prone patches #21640
Generate error-prone patches #21640
Conversation
github-actions
bot
added
team-Rules-Java
sgowroji
added
awaiting-user-response
|
Hi @sgowroji, I see you changed the status to awaiting-user-response, but I don't see any question directed to me. |
| @@ -121,6 +127,9 @@ public void postFlow(Env<AttrContext> env) { | |||
| elapsed.start(); | |||
| try { | |||
| errorProneAnalyzer.finished(new TaskEvent(Kind.ANALYZE, env.toplevel, env.enclClass.sym)); | |||
| if (refactoringTask != null) { | |||
| refactoringTask.finished(new TaskEvent(Kind.GENERATE, env.toplevel, env.enclClass.sym)); | |||
There was a problem hiding this comment.
With this call here, the refactoring task won't actually run after the GENERATE phase is completed. Assuming that it is important to run the task at that time, an alternative is to register the task as a TaskListener with the compiler. To do this, around line 115 where the RefactoringTask is created, you can do:
MultiTaskListener.instance(context).add(refactoringTask);Then you won't need this call. Not sure if it's important or not.
There was a problem hiding this comment.
Thanks @msridhar, I implemented your suggestion.
sgowroji
added
awaiting-review
|
Hi @rsalvador, Thanks for sharing details on above failures. |
|
@rsalvador have you explored how this change interacts with sandboxing for your use case? With weaker sandboxes, I found that the original source files do get modified with the |
|
Hi @sgowroji, the error-prone PR (google/error-prone#4318) has been in a "1 workflow awaiting approval. This workflow requires approval from a maintainer" state since it was opened last week and it has not had any activity or checks run. Do you know how to get the error-prone PR moving forward? |
For local builds, we tried both IN_PLACE and dynamically generating a javacopts with a different -XepPatchLocation for each java target and both worked well, didn't try stronger sandboxing. We used it to perform a mass fixing of wildcard imports by running a full local build with patching enabled and plan to use it for similar use cases only for now. |
@rsalvador we don't Triage or manage above mentioned repository. |
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.java_bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=cme/clients/flipr-java-client/flipr-client tools/bazel build //cme/clients/flipr-java-client/flipr-client:src_main ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
Summary: This diff contains the changes in bazelbuild#21640, ported to the uber/java/7.0.2.001 branch. We also commit a modified version of the Error Prone check_api jar. The modifications in that jar are those changes in google/error-prone#4318 applied to Error Prone 2.22.0 (the version used in our branch). Probably, rather than committing the modified jar, we could upload the modified jar to artifactory and change the version we depend on here. I have tested that these changes work locally on a devpod. `IN_PLACE` patching will most likely not work under stronger sandboxes, as it relies on modifying the source files in the sandbox (which, by default on a devpod, are just symlinks to the original source files). Also, there seem to be some weird interactions with the Bazel cache, such that when I tried to run the same autopatch twice (after undoing the initial changes), I had to blow away my local `~/.bazelcache` directory to make it work. Test Plan: Tested locally by copying over the built java_tools jars and running: ``` EP_PATCH_CHECK=MissingOverride EP_PATCH_CHECK_PATH_ONLY=a/b/c tools/bazel build //a/b/c:src ``` It would be good to write an integration test for this at some point, since it hasn't been upstreamed. Reviewers: cjk Subscribers: ravirajj, ravi Revert Plan: n/a JIRA Issues: JAVADEVX-8326 Differential Revision: https://code.uberinternal.com/D13309409
|
Just adding support for One alternative would be to add support for this to Bazel, so it could handle setting up the additional output for the action and passing that path through to JavaBuilder. At Google we're generating Error Prone patches by using an aspect to create an additional action to run Error Prone for refactoring (instead of re-using the same invocation that happens in JavaBuilder), and having the aspect handle collecting all of the transitive refactoring outputs. |
Another option could be to use a wrapper rule for java_library that declares the output. Agreed that the way this PR allows patching is not ideal, but modifying the native bazel rules seemed too involved, maybe it will be better to do once the java rules are refactored to Starlark? |
The current error-prone integration doesn't generate patches: #5729 (comment)
This PR enables error-prone patch generation and relies on making some existing error-prone members public: google/error-prone#4318
Error-prone requires the caller to specify the location of the generated error-prone.patch files: https://errorprone.info/docs/patching, callers can handle this by for example dynamically generating a javacopts with a different -XepPatchLocation for each java target rule. Another option is to use the IN_PLACE option:
-XepPatchLocation:IN_PLACE