4.0.0: StackOverflowError in error-prone

Description of the problem / feature request:

Trying out bazel 4.0.0, with --javabase=@bazel_tools//tools/jdk:remote_jdk11 --java_toolchain=@bazel_tools//tools/jdk:toolchain_java11 and hit a bug in error-prone 2.4.0 (bazel 3.3.1 has 2.3.2 I think, and it works)

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Haven’t yet reproduced in a small setup but likely is triggered by code generated by https://github.com/immutables/immutables 2.8.8

Any other information, logs, or outputs that you want to share?

Most recent error_prone is 2.5.1, but haven’t tested if it’d fix the issue https://github.com/google/error-prone/releases

some_class.java:192: error: An unhandled exception was thrown by the Error Prone static analysis plugin.
                    SomeClass.builder().from(someInstance).build())
     Please report this at https://github.com/google/error-prone/issues/new and include the following:
  
     error-prone version: 2.4.0
     BugPattern: ArrayToString
     Stack Trace:
     java.lang.StackOverflowError
  	at jdk.compiler/com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:4937)
  	at jdk.compiler/com.sun.tools.javac.code.Types.supertype(Types.java:2462)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2128)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
  	at jdk.compiler/com.sun.tools.javac.code.Types.asSuper(Types.java:2114)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2130)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
  	at jdk.compiler/com.sun.tools.javac.code.Types.asSuper(Types.java:2114)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2130)
  	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2117)
  	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:993)
  	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4857)
...

Not sure if there’s an easy way to upgrade error_prone version without the need to rebuild bazel itself

Bump of error_prone commit https://github.com/bazelbuild/bazel/commit/239b2aab17cc1f007b2221ada9074bbe0c58db88 Some issues with earlies attempts of upgrade 2.3.2->2.3.3 https://github.com/bazelbuild/bazel/issues/9286

[cushon]

Thanks, taking a close look I see that immutables is generating a class that completes a cyclic type hierarchy:

$ javap -cp bazel-bin/liba-hjar.jar A\$Builder ImmutableA\$BuilderImpl
public class A$Builder extends ImmutableA$BuilderImpl {
  public A$Builder();
}
public final class ImmutableA$BuilderImpl extends A$Builder {
  public final ImmutableA$BuilderImpl from(A);
  public ImmutableA build();
}

This is an interaction between immutables and https://github.com/google/turbine’s implementation of annotation processing.

This logic is relying on the toString() representation of ImmutableA.BuilderImpl in class Builder extends ImmutableA.BuilderImpl { before the code has been generated yet, while ImmutableA.BuilderImpl is still being modelled as an error type: https://github.com/immutables/immutables/blob/dd249064688af65ee3ff00fa5819e9deeb1bcf67/generator/src/org/immutables/generator/SourceExtraction.java#L396-L406

[cushon]

bazel annotation processing (something changed there?)

This is the thing that actually changed in Bazel–as of https://github.com/bazelbuild/bazel/commit/10ffddb13ac070f2c6b9d64cb927ab3b659c0b72 Bazel uses a different annotation processing implementation by default (https://github.com/google/turbine).

The way errors are modeled in the annotation processing API isn’t very well specified, but I think improving turbine here is a good resolution, I don’t see anything in particular immutables should be doing differently.

Ideally javac would detect the cycle and not crash, but there are a lot of ways that invalid class files can cause problems for javac, so I’m not sure it’s worth trying to handle that better.

The mention of Error Prone in the stack trace is a red herring, it just catches top-level exceptions and tries to log additional information.