Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make patching API public #4318

Closed
wants to merge 1 commit into from

Conversation

rsalvador
Copy link
Contributor

@rsalvador rsalvador commented Mar 12, 2024

to be used by bazel’s error prone plugin: bazelbuild/bazel#21640

raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Mar 28, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Mar 28, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Mar 29, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Mar 30, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Mar 30, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Apr 23, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Apr 23, 2024
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
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Apr 23, 2024
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
@msridhar
Copy link
Contributor

msridhar commented May 1, 2024

@cushon this change is being successfully used at Uber to enable Error Prone auto-patching to work with Bazel, along with bazelbuild/bazel#21640. I have a follow-on Error Prone fix that makes auto-patching also work for plug-in checks, which I'm happy to contribute as a PR as well (though it makes more sense to land after this one).

Independent of the Bazel change, this PR seems straightforward and could be helpful for any build system trying to integrate Error Prone. So, it'd be great if someone from the EP team could review it sometime. Thanks!

.customRefactorer()
.or(
() -> {
ScannerSupplier toUse =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This un-does some changes from 9da2d55 compared to the original code, I wonder if that was just an oversight when picking up 9da2d55?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, was an oversight, re-pushed the changes using the latest code.

@rsalvador rsalvador force-pushed the make-patching-api-public branch from 6036b81 to 905d626 Compare May 6, 2024 06:01
@msridhar
Copy link
Contributor

@cushon are any other steps required for this one to land? Thanks for the help!

raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Jul 1, 2024
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

Update Error Prone jar in Bazel java_tools with further fix

Summary: Jar now includes the fix in https://code.uberinternal.com/D13331711?vs=37208341&id=37966971

JIRA Issues: JAVADEVX-8326

Differential Revision: https://code.uberinternal.com/D13628673
copybara-service bot pushed a commit that referenced this pull request Jul 15, 2024
to be used by bazel’s error prone plugin: bazelbuild/bazel#21640

Fixes #4318

FUTURE_COPYBARA_INTEGRATE_REVIEW=#4318 from rsalvador:make-patching-api-public 905d626
PiperOrigin-RevId: 634811351
benkard pushed a commit to benkard/jgvariant that referenced this pull request Jul 19, 2024
This MR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [com.google.errorprone:error_prone_core](https://errorprone.info) ([source](https://github.com/google/error-prone)) |  | minor | `2.28.0` -> `2.29.2` |
| [com.google.errorprone:error_prone_annotations](https://errorprone.info) ([source](https://github.com/google/error-prone)) | compile | minor | `2.28.0` -> `2.29.2` |

---

### Release Notes

<details>
<summary>google/error-prone</summary>

### [`v2.29.2`](https://github.com/google/error-prone/releases/tag/v2.29.2): Error Prone 2.29.2

[Compare Source](google/error-prone@v2.29.1...v2.29.2)

This release contains all of the changes in [2.29.0](https://github.com/google/error-prone/releases/tag/v2.29.0) and [2.29.1](https://github.com/google/error-prone/releases/tag/v2.29.1), plus:

-   a bug fix for a crash in `TraditionalSwitchExpression` (google/error-prone#4479)
-   restores the `module-info` for the annotations jar, which was accidentally removed (google/error-prone#4480)

Full Changelog: google/error-prone@v2.29.1...v2.29.2

### [`v2.29.1`](https://github.com/google/error-prone/releases/tag/v2.29.1): Error Prone 2.29.1

[Compare Source](google/error-prone@v2.29.0...v2.29.1)

This release contains all of the changes in [2.29.0](https://github.com/google/error-prone/releases/tag/v2.29.0), plus:

-   a bug fix to `UnusedVariable` to handle unnamed `_` variables (google/error-prone#4451)
-   a bug fix for a crash in `SetUnrecognized` (google/error-prone#4475)

Full Changelog: google/error-prone@v2.29.0...v2.29.1

### [`v2.29.0`](https://github.com/google/error-prone/releases/tag/v2.29.0): Error Prone 2.29.0

[Compare Source](google/error-prone@v2.28.0...v2.29.0)

New checks:

-   [`MissingRuntimeRetention`](https://errorprone.info/bugpattern/MissingRuntimeRetention)
-   [`SetUnrecognized`](https://errorprone.info/bugpattern/SetUnrecognized)
-   [`StatementSwitchToExpressionSwitch`](https://errorprone.info/bugpattern/StatementSwitchToExpressionSwitch)

Closed issues: [#&#8203;4318](google/error-prone#4318), [#&#8203;4429](google/error-prone#4429), [#&#8203;4467](google/error-prone#4467)

Full Changelog: google/error-prone@v2.28.0...v2.29.0

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about these updates again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNC4yNC4wIiwidXBkYXRlZEluVmVyIjoiMzQuMjQuMCJ9-->
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Aug 14, 2024
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

Update Error Prone jar in Bazel java_tools with further fix

Summary: Jar now includes the fix in https://code.uberinternal.com/D13331711?vs=37208341&id=37966971

JIRA Issues: JAVADEVX-8326

Differential Revision: https://code.uberinternal.com/D13628673
raviagarwal7 pushed a commit to uber-common/bazel that referenced this pull request Aug 20, 2024
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

Update Error Prone jar in Bazel java_tools with further fix

Summary: Jar now includes the fix in https://code.uberinternal.com/D13331711?vs=37208341&id=37966971

JIRA Issues: JAVADEVX-8326

Differential Revision: https://code.uberinternal.com/D13628673
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants