forked from google/error-prone
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
…ing). PiperOrigin-RevId: 578507433
Fixes google#4157 COPYBARA_INTEGRATE_REVIEW=google#4157 from PicnicSupermarket:sschroevers/avoid-CCE-in-UnnecessaryBoxedAssignment 73dc358 PiperOrigin-RevId: 578808258
PiperOrigin-RevId: 578989135
…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
PiperOrigin-RevId: 579780936
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
…selves PiperOrigin-RevId: 580288274
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
PiperOrigin-RevId: 580878430
PiperOrigin-RevId: 581190037
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
PiperOrigin-RevId: 618176103
PiperOrigin-RevId: 618828938
PiperOrigin-RevId: 618889679
Fixes google#4343 PiperOrigin-RevId: 618890911
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
PiperOrigin-RevId: 620003152
…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
PiperOrigin-RevId: 621319804
Fixes external google#4308. PiperOrigin-RevId: 621845649
Follow-up to google@9b2c2a9 PiperOrigin-RevId: 622020333
PiperOrigin-RevId: 624898303
PiperOrigin-RevId: 624922054
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upgrades to
v2.27.0
from upstreamError 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 {
...
}
Full Changelog: google/error-prone@v2.26.0...v2.26.1
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