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

Upgrade to v2.27.0 #86

Merged
merged 151 commits into from
Apr 29, 2024
Merged

Upgrade to v2.27.0 #86

merged 151 commits into from
Apr 29, 2024

Conversation

jaredstehler
Copy link

Upgrades to v2.27.0 from upstream

Error Prone 2.27.0 Latest

New checks:

ClassInitializationDeadlock detects class initializers that reference subtypes of the current class, which can result in deadlocks.
MockitoDoSetup suggests using when/thenReturn over doReturn/when for additional type safety.
VoidUsed suggests using a literal null instead of referring to a Void-typed variable.
Modified checks:

TruthSelfEquals has been renamed and generalized as SelfAssertion
RedundantSetterCall has been improved, and enabled as an error oby default
Closed issues: google#4291. google#4308, google#4343, google#4320

Full Changelog: google/error-prone@v2.26.1...v2.27.0

Error Prone 2.26.1

This release contains all of the changes in 2.26.0, plus a bug fix to the module name of the annotations artifact com.google.errorprone.annotations (google@9d99ee7)

Starting in 2.26.x, the 'annotations' artifact now includes a module-info.java for Java Platform Module System support, thanks to @sgammon in google#4311.

Compatibility note:

Now that the annotations artifact explicit declares a module instead of relying on Automatic-Module-Name, JDK 17 and newer perform stricter module encapsulation checks. Modularized libraries depending on Error Prone annotations 2.26.x and newer may see errors like:

error: package com.google.errorprone.annotations is not visible
import com.google.errorprone.annotations.CheckReturnValue;
^
(package com.google.errorprone.annotations is declared in module com.google.errorprone.annotations, but module ... does not read it)
The fix is to add requires static to the module declaration of modularized libraries that depend on Error Prone annotations:

module your.module {
...

Error Prone 2.26.0

Warning: This release contains a bug, please use 2.26.1 or newer instead.

Changes:

The 'annotations' artifact now includes a module-info.java for Java Platform Module System support, thanks to @sgammon in google#4311.
Disabled checks passed to -XepPatchChecks are now ignored, instead of causing a crash. Thanks to @oxkitsune in google#4028.
New checks:

SystemConsoleNull: Null-checking System.console() is not a reliable way to detect if the console is connected to a terminal.
EnumOrdinal: Discourage uses of Enum.ordinal()
Closed issues: google#2649, google#3908, google#4028, google#4311, google#4314

Full Changelog: google/error-prone@v2.25.0...v2.26.0

Error Prone 2.25.0

New checks:

JUnitIncompatibleType: Detects incompatible types passed to an assertion, similar to TruthIncompatibleType
RedundantSetterCall: Detects fields set twice in the same chained expression. Generalization of previous ProtoRedundantSet check to also handle AutoValue.
Closed issues: google#4195, google#4224, google#4228, google#4248, google#4249, google#4251

Full Changelog: google/error-prone@v2.24.1...v2.25.0

Error Prone 2.24.1

Changes:

Add an assertion to try to help debug google#4225
Full Changelog: google/error-prone@v2.24.0...v2.24.1

Error Prone 2.24.0

New checks:

MultipleNullnessAnnotations: Discourage multiple nullness annotations
NullableTypeParameter: Discourage nullness annotations on type parameters
NullableWildcard: Discourage nullness annotations on wildcards
SuperCallToObjectMethod: Generalization of SuperEqualsIsObjectEquals, now covers hashCode
Full Changelog: google/error-prone@v2.23.0...v2.24.0

cpovirk and others added 30 commits October 19, 2023 03:09
Obviously we could do even better by generating `this != obj`. But in practice, all the code that contains this check is buggy and needs to be more substantially rewritten. So our goal here is just to avoid generating invalid Java.

(credit to emcmanus@ for catching this bug)

PiperOrigin-RevId: 574798017
google#4153

PiperOrigin-RevId: 574883084
…o "`SuperCallToObjectMethod`."

...as suggested by @Marcono1234 in google#4147 (comment).

Also, add docs.

PiperOrigin-RevId: 574898389
(pointed out [by @Stephan202](google#4155 (comment)))

PiperOrigin-RevId: 575004527
…es, it's surely a test.

Or a style violation, of course.

PiperOrigin-RevId: 576120741
I'm taking over from copybara and merging this into one CL, since there were
some breaking changes.

PiperOrigin-RevId: 576589485
PiperOrigin-RevId: 576849175
…ting something onto it in some paths.

PiperOrigin-RevId: 576864540
**A typo has been fixed.**

Fixes google#4166

COPYBARA_INTEGRATE_REVIEW=google#4166 from khalid586:master 010e48a
PiperOrigin-RevId: 577858113
Fixes google#4157

COPYBARA_INTEGRATE_REVIEW=google#4157 from PicnicSupermarket:sschroevers/avoid-CCE-in-UnnecessaryBoxedAssignment 73dc358
PiperOrigin-RevId: 578808258
…tialized.

We can't only include TestParameterInjector, because other frameworks are adopting its annotation for injecting parameters. But these are other parameterising frameworks you _might_ guess would work with @TestParameter, but don't.

PiperOrigin-RevId: 579143309
…instead of strings

PiperOrigin-RevId: 579319948
…ndTypeAttributes`

PiperOrigin-RevId: 579345191
Follow-up to google@c83ba54

PiperOrigin-RevId: 580124237
…s that are being moved

PiperOrigin-RevId: 580185539
…blePrimitiveArray`, not just `@Nullable`

PiperOrigin-RevId: 580206745
This is already covered by tests, such as `negativeCases_suppressionForMethodTreeBased()`.

(`SuppressibleTreePathScanner` might actually correct some edge cases somewhere, even.)

PiperOrigin-RevId: 580260707
PiperOrigin-RevId: 580315454
…assertThat`, not just the Truth ones.

That way, we catch `ProtoTruth` too.

PiperOrigin-RevId: 580504931
Flume: unknown commit
PiperOrigin-RevId: 580526558
And warn about a similar pitfall in the already deprecated `ASTHelpers.getAnnotation`.

And add some tests, which show that we already had this right for `SuppressibleTreePathScanner` and for the automatic `BugChecker` behavior (from unknown commit), just not for manual `isSuppressed` calls.

Add a couple TODOs about:
- the kinds of trees on which suppressions are valid
- whether the non-deprecated `BugChecker.isSuppressed(Symbol, VisitorState)` might be a footgun.

Compare:
- https://github.com/google/error-prone/blob/18d5cdf10ec1cc798a588d5c48a9e02a8888c6a1/check_api/src/main/java/com/google/errorprone/scanner/Scanner.java#L91
- https://github.com/google/error-prone/blob/18d5cdf10ec1cc798a588d5c48a9e02a8888c6a1/core/src/main/java/com/google/errorprone/refaster/RefasterSuppressionHelper.java#L43
PiperOrigin-RevId: 580619965
The colon winds up appearing in the generated docs in the summary.

PiperOrigin-RevId: 581238725
… stuff like

`assertThat(fooProto.getField()).isEqualTo(fooProto.getField());`

But avoids massively over-matching on expressions which _aren't_ known to be pure.

Flume: unknown commit
PiperOrigin-RevId: 581934324
I did some testing and some digging in the Kotlin issue tracker ([1](https://youtrack.jetbrains.com/issue/KT-40498/Nullability-annotations-on-Java-wildcard-itself), [2](https://youtrack.jetbrains.com/issue/KT-53836/In-type-parameter-declarations-recognize-JSpecify-annotations-only-on-bounds#focus=Comments-27-6427080.0-0)), and everything I found suggests that Kotlin ignores annotations on wildcards entirely.

This actually provides an even better case for the NullableWildcard check.

PiperOrigin-RevId: 582331851
graememorgan and others added 28 commits March 22, 2024 07:51
I added a `toBuilder` method to avoid the `SuggestedFix.builder().merge(x)` dance, and made use of the newer static `merge` method in a few places.

PiperOrigin-RevId: 619220321
Ironically, this is stopping the class being thread-safe.

PiperOrigin-RevId: 619256145
… be constant.

Motivated by `Boolean.TRUE`, but that seemed a bit special-casey.

PiperOrigin-RevId: 619497318
…er.join(Object, Object, Object...)`

google#4233 (review)

PiperOrigin-RevId: 619537499
…ernally.

I added the third_party exemption proactively, and had to hardcode _one last annoying exemption_.

PiperOrigin-RevId: 621130845
Previously unqualified methods names were being handled using logic intended for local variables, which failed to match them.

Unqualified instance method names are relatively rare in templates. The motivating example was a template intended to match on an anonymous class creation, where code in the class called a method from a superclass by its simple name.

PiperOrigin-RevId: 621197168
PiperOrigin-RevId: 621206548
Fixes external google#4308.

PiperOrigin-RevId: 621845649
Follow-up to google@9b2c2a9

PiperOrigin-RevId: 622020333
Fixes google#4291

PiperOrigin-RevId: 625359890
Contrary to the current text, blaze test actually does enable asserts, in both dbg and opt modes. I've verified this by running a JUnit test containing "assert false" with "blaze test -c opt" and "blaze test -c dbg".

My tests use a java_library BUILD rule that includes all the *Test.java files, and a GenTestRules to create the actual test targets.

PiperOrigin-RevId: 626049936
PiperOrigin-RevId: 626072465
I've been very over-conservative about the heuristics on what to avoid, but nonetheless here's a huge sample flume: unknown commit

PiperOrigin-RevId: 627396784
[]

PiperOrigin-RevId: 627663284
… be replaced with a literal `null`.

Findings here (unknown commit) before I fixed the bug with assignments.

PiperOrigin-RevId: 627676095
…he production code (which seems more discoverable).

PiperOrigin-RevId: 627693317
@jaredstehler jaredstehler merged commit 02e0b65 into hubspot Apr 29, 2024
1 check passed
@jaredstehler jaredstehler deleted the js-update-to-2-27-0 branch April 29, 2024 12:40
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.