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

I think the suggestion to use EqualsTester is great (so belongs in a description), but the fix is almost always bad, for two reasons:

  1)  It's often just _wrong_; lots of these are bugs, not equals testing
  2)  Even when it's right, it's very incomplete. You'd want to factor some of the unequal cases into equality groups and go from there.

PiperOrigin-RevId: 583047109

…_USE` annotations on field types and method return types

This allows `ProvidesNull` to handle `TYPE_USE` `@Nullable` annotations.

Startblock:
  unknown commit is submitted
PiperOrigin-RevId: 583055698

- https://errorprone.info/bugpattern/NullableWildcard
- https://errorprone.info/bugpattern/NullableTypeParameter
- https://errorprone.info/bugpattern/ExtendsObject (The actual parenthetical in the title is fine; the problem is under "The problem.')

PiperOrigin-RevId: 583397840

PiperOrigin-RevId: 583995107

PiperOrigin-RevId: 584063431

… just private methods.

PiperOrigin-RevId: 584277317

Which is now enabled.

PiperOrigin-RevId: 584850701

…cked.

You need really weird circumstances to trigger this. Note the `if (false)` in the test, which renders `a` effectively final despite it having an assignment.

PiperOrigin-RevId: 585087842

PiperOrigin-RevId: 585729692

…nchecked) for parameter usage.

PiperOrigin-RevId: 587714550

PiperOrigin-RevId: 587898768

#MIGRATION_3P_JAVA_SRC_CHECKER_FRAMEWORK_DATAFLOW__DEFAULT_SERVICE

  - c9b1e103fbe5ea1a3fc5d8e52a16c9982ed0bc76 Prep for next release by Werner Dietl <wdietl@gmail.com>
  - 4f53c5bf42e357682104fd3cbf4878457d1d0e0d Extract version variable and update version (google#630) by Werner Dietl <wdietl@gmail.com>
  - 3c4dad383006e706dc102d4d835298e1e1e12114 Do not use `thisValue` when it is the NullType (google#636) by Werner Dietl <wdietl@gmail.com>
  - d7f9dabf1240e40484ce2b3c1c6e9feecaabe29c Generalize improvement of initialization type frames (google#642) by Florian Lanzinger <lanzinger@kit.edu>
  - a7b753565fe9843d5e5f1ade6564bab68fa266e9 Update dependency commons-io:commons-io to v2.15.1 (google#643) by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 3ed0c114c3d686eadc803207640487e86d1d086e Update dependency gradle to v8.5 (google#644) by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 5c59bff87210b78a7fc7f8cd7b7372d2d7e60981 Update dependency com.amazonaws:aws-java-sdk-bom to v1.12... by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 2170fdab53832a3b9016f200a78189c76298f87e Update dependency com.diffplug.spotless:spotless-plugin-g... by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 8eb212555daec5323fd1f1af786092cbbbeef8a0 Update dependency io.github.classgraph:classgraph to v4.8... by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 4c08ea3751b40620d20eb05ca85ead9a42f500f9 Update dependency org.checkerframework:stubparser to v3.2... by renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
  - 2dee1c3763640e4bec88bc0b8a11a9f6bad1a5ea Warn about redundant null cases in switch statements and ... by Aosen Xiong <82676488+Ao-senXiong@users.noreply.github.com>
  - 780fef9e0225761ba44000091a2f024a6ffbdecb typetools/checker-framework 3.41.0 release (google#650) by Werner Dietl <wdietl@gmail.com>
  - 9c804e41ed0f506713ac50224d2a63f2d2568dc2 Consistently spell it `JUnit` by Werner Dietl <wdietl@gmail.com>
  - 9ad831a2432ad5cbf6bb1a99dff4121f4a6dc4e3 Add missing import to stub file by Werner Dietl <wdietl@gmail.com>
  - 28f6b0fc670596c5943ca93e01b480429ef0a907 Remove warnings about junit-assertions.astub that do not ... by Werner Dietl <wdietl@gmail.com>
  - a4c50adad5e36bc746cfabddba41b5f661da54d5 Formatting tweak by Werner Dietl <wdietl@gmail.com>
  - 66bb90d7431427ed39f67d7a9899f93d430220c1 Make error keys consistent by Werner Dietl <wdietl@gmail.com>
  - 6be13eba81909bedc263c6b1a9d4c3583af556b7 Simplify code, suppress Optional Checker FP, code consist... by Werner Dietl <wdietl@gmail.com>
  - 011fbb759104d1277700a9e7893f435af00a5f90 Code comment formatting by Werner Dietl <wdietl@gmail.com>
  - 5b60183f3d3934dcb205adfb77c729399687c9bc Fix formatting by Werner Dietl <wdietl@gmail.com>
  - 13f7887e1941d0b6b18a9a9c85088e42fbb56c13 Fix error keys and warning texts by Werner Dietl <wdietl@gmail.com>
  - 084ca4b52ab4d067a93ae32ea04c892ec36bf72a Fix terminology and use EISOP website by Werner Dietl <wdietl@gmail.com>
  - f62005ea47ffe9bae7561d51ed9a0a2bed4f89c0 Skip try-with-resources test on Java 8 by Werner Dietl <wdietl@gmail.com>
  - 97af13821ff7ed86c6b5f3740799a28d2a054608 Add a note by Werner Dietl <wdietl@gmail.com>
  - c2df6d6cc48878b92970c568e5388ddafa60b60f Prep for release by Werner Dietl <wdietl@gmail.com>
  - c08538fbc8e167a931cbe405614b52663a8e67be new release 3.41.0-eisop1 by Werner Dietl <wdietl@gmail.com>

PiperOrigin-RevId: 588812139

And streamify the implementation a bit.

PiperOrigin-RevId: 589088083

PiperOrigin-RevId: 589128835

…foreClass` methods

PiperOrigin-RevId: 590890283

I think this was introduced in google@88a224c, where we suddenly start considering some _effectively_ private abstract methods.

PiperOrigin-RevId: 590895990

I think this `return null`'d on the assumption that a `VariableTree` can't contain more variables to check... but of course it can, with anonymous classes etc.

PiperOrigin-RevId: 590929955

Not yet handling the Iterable overload; that's a bit more involved given the lack of prior art.

PiperOrigin-RevId: 591205788

*** Reason for rollback ***

That did not handle varargs well: specifically array arguments in a varargs position.

I'll fix and roll forward.

*** Original change description ***

Handle Joiner.on(...) in AbstractToString.

Not yet handling the Iterable overload; that's a bit more involved given the lack of prior art.

***

PiperOrigin-RevId: 591308763

…cumented element

PiperOrigin-RevId: 591893421

It does, but I got confused in google#4225.

PiperOrigin-RevId: 594123682

PiperOrigin-RevId: 594339474

…mmit

PiperOrigin-RevId: 595108607

…handle #formatted.

There are some ERROR-level checks under AbstractToString, but I think #formatted can't be used in the depot yet?

PiperOrigin-RevId: 595389167

PiperOrigin-RevId: 595414757

…`s to `CanIgnoreReturnValueSuggesterTest`.

#checkreturnvalue

PiperOrigin-RevId: 595426409

…der` or `@Subcomponent.Builder` methods (they will soon be treated as implicitly ignorable via a custom rule).

#checkreturnvalue

PiperOrigin-RevId: 595454660

…methods as ignorable.

#checkreturnvalue

PiperOrigin-RevId: 595505398

If a case contains a single block statement, skip past the braces of the block statement.

Enables fixes like:

```
      case 0 -> System.out.println("0");
```

Instead of:

```
      case 0 -> {
        {
          System.out.println("0");
          break;
        }
      }
```

Fixes google#4222

PiperOrigin-RevId: 595703319

PiperOrigin-RevId: 595809096

Fixes google#4242

PiperOrigin-RevId: 595991339

Prompted by google#4242

(`mvn org.codehaus.mojo:versions-maven-plugin:2.16.2:{update-properties,use-latest-releases} -DgenerateBackupPoms=false -f third_party/java_src/error_prone/project/pom.xml -Dexcludes=org.hamcrest:hamcrest-core,org.hamcrest:hamcrest-library,com.google.inject.extensions:guice-assistedinject,com.google.inject.extensions:guice-servlet,com.google.inject.extensions:guice-testlib`. Without the exclusions, I got test errors. The Hamcrest ones might be related to API changes? The Guice ones might be related to getting out of sync with `guice.version`, which the `mvn` command does not update?)

PiperOrigin-RevId: 596010863

…eType

PiperOrigin-RevId: 596602361

…thods.

PiperOrigin-RevId: 597548436

google#4248

Fixes google#4249

COPYBARA_INTEGRATE_REVIEW=google#4249 from elkkhan:doc-remove-bugpattern-examples-statement 8c7cf54
PiperOrigin-RevId: 597571000

Following the discussions in google#2236, this PR introduces the `BadImport:BadEnclosingTypes` flag to disallow nested types of specified enclosing type.

This PR also takes the flag into account in `UnnecessarilyFullyQualified` to suggest importing `EnclosingType.NestedType` when possible.

For instance, when `-XepOpt:BadImport:BadEnclosingTypes=org.immutables.value.Value` is set, it would suggest the following:

```java
final class Test {
  @org.immutables.value.Value.Immutable
  abstract class AbstractType {}
}
```
->
```java
final class Test {
  @Value.Immutable
  abstract class AbstractType {}
}
```

Also, it won't require suppressing `UnnecessarilyFullyQualified` in the example in google#2236.

```java
import org.springframework.beans.factory.annotation.Value;

final class Test {
  Demo(@value("some.property") String property) {}

  @org.immutables.value.Value.Immutable
  abstract class AbstractType {}
}
```

Closes google#2236.

Fixes google#4228

COPYBARA_INTEGRATE_REVIEW=google#4228 from hisener:halil.sener/bad-import-bad-enclosing-types 67aa36d
PiperOrigin-RevId: 597798125

PiperOrigin-RevId: 599119407

…@BeforeAll` methods

Analogous to google#4215.

Resolves google#4239.

Fixes google#4251

COPYBARA_INTEGRATE_REVIEW=google#4251 from DataDog:halil.sener/4239-non-final-static-field-junit-5-before-all 8a109a8
PiperOrigin-RevId: 600484897

See https://bugs.openjdk.org/browse/JDK-8324736

Fixes google#4245

PiperOrigin-RevId: 601554857

PiperOrigin-RevId: 601751926

Fixes external google#4195

PiperOrigin-RevId: 601777043

The methods there will be moving into the main `Truth` class. Users will have various options for how to migrate, but one option involves avoiding static imports. We will provide more instructions as part of our Truth releases. (See, e.g., [the release notes for Truth 1.3.0](https://github.com/google/truth/releases/tag/v1.3.0).)

Rough outline of the option that involves avoiding static imports:

- The problem with adding `Truth8.assertThat(OptionalInt)` (or a similar overload) to `Truth` is that anyone who static imports both `Truth.assertThat` and `Truth8.assertThat` will see ambiguity errors if they use that method.
- The solution is to stop using static import for `Truth8.assertThat`. Once all its static imports are gone, we can add the new methods to `Truth` without breaking anyone, and then we can migrate users.
- Avoiding static import for `Truth8.assertThat` would be tough to swallow for the most common types, `Stream` and `Optional`. Luckily, I found an alternative approach that works for those, as discussed in the linked release notes. (That approach works for those types because they're generic types.)

PiperOrigin-RevId: 601863378

PiperOrigin-RevId: 601904095

…y are called reflectively by the Apache Beam framework.

https://beam.apache.org/releases/javadoc/current/org/apache/beam/sdk/transforms/DoFn.html

PiperOrigin-RevId: 602412808

https://github.com/google/truth/releases/tag/v1.3.0

PiperOrigin-RevId: 602804747

PiperOrigin-RevId: 602812366

PiperOrigin-RevId: 602812834

…assertThat`.

The `Truth8` methods will be hidden in the future. All callers will use `Truth`.

To make that migration possible, upgrade Truth to 1.3.0.

(progress toward google/truth#746)

PiperOrigin-RevId: 603108718

Tested:
    TAP for global presubmit queue
    []
PiperOrigin-RevId: 603189890

…er` is a subclass.

We accomplish this by calling `baseSymbol()` on the initial `Symbol`.

(We likely should do this in more places in Error Prone, including the location in `ASTHelpers.getSymbol` that I've flagged and perhaps anywhere else that we directly access `tree.sym`.)

Thanks to @msridhar for links to relevant JDK discussions, notably [JDK-8293890](https://bugs.openjdk.org/browse/JDK-8293890).

Effects:
- This change definitely helps with [static imports](uber/NullAway#764), as demonstrated in a new test in `ParameterNameTest`, which fails before this change. (I didn't actually look into why the test fails before. Maybe the "fake" `Symbol` lacks the parameter names of the original?)
- I didn't check whether it helps with [`someSerializable.equals`](uber/NullAway#897). It seems likely to, but _shrug_ for now.
- I had expected this to help with the `TestCase.fail` handling in `ReturnMissingNullable`, but it turns out that I'm wrong on multiple levels. I updated its comments and tests accordingly:
   - `TestCase.fail` _does_ exist as a declared method nowadays; it's not merely inherited from `Assert`. I must have been looking at [quite an old version](junit-team/junit4@dde798f#diff-f9834c0e0ef1d54e1757e221b7b4248c2ba8e0de41d2f0fadac5927b906edd85R226).
   - The problem there comes not from the need for `ASTHelpers.getSymbol` to use `baseSymbol()` but instead for the need for `MethodMatchState.ownerType` to look at the actual `owner` instead of the type of the receiver tree. (If it started to do that, it would then benefit from this change to produce the correct `owner`.) I added a link to the appropriate bug there.
PiperOrigin-RevId: 603374262

PiperOrigin-RevId: 603821511

…v1.4.0).

PiperOrigin-RevId: 604375179

PiperOrigin-RevId: 604449600

This PR fixes a few typos I spotted in the documentation of the project.

Fixes google#4224

COPYBARA_INTEGRATE_REVIEW=google#4224 from deining:fix-typos 25978d6
PiperOrigin-RevId: 604736232

…ing.

Not yet handling the Iterable overload; that's a bit more involved given the lack of prior art.

Handily there was a 'isInVarargsPosition' _right there_.

PiperOrigin-RevId: 604758974

PiperOrigin-RevId: 605025464

This is to unblock unknown commit

PiperOrigin-RevId: 605082043

PiperOrigin-RevId: 605217009

PiperOrigin-RevId: 606334307

javac's tokenize now emits some diagnostics (including the `text-blocks` lint
warnings), and this can result in ErrorProneTokens causing bogus diagnostics to
be logged.

PiperOrigin-RevId: 607014734

PiperOrigin-RevId: 607088772

These types are already in []

TAP train ticket - []

PiperOrigin-RevId: 607088877

See https://bugs.openjdk.org/browse/JDK-8309155

PiperOrigin-RevId: 608688611