[6.3.0] nullaway plugin stops compiling

[dmivankov]

Description of the bug:

Nullaway error-prone plugin doesn't work with 6.3.0 but did work with 6.1.2

What goes wrong is either

1. --when set javaopts= setting is present in bazel-out/.../....jar-0.params.out but nullaway plugin can't see it--
2. or error-prone version bundled in 6.3.0 is somehow 2.19.1 with a bug ErrorProneInjector incorrectly picks up the no-args constructor google/error-prone#3931 rather than 2.20.0

2.19.1 comes from remote_java_tools-v12.5

     Please report this at https://github.com/google/error-prone/issues/new and include the following:
  
     error-prone version: 2.19.1
     BugPattern: NullAway
     Stack Trace:
     java.lang.IllegalStateException: To run the NullAway analysis plugin please specify analysis options with -XepOpt:NullAway:[...]. You should at least specify annotated packages, using the -XepOpt:NullAway:AnnotatedPackages=[...] flag.

and the error message it not wrong

java_library(
  plugins = ["@maven//:com_uber_nullaway_nullaway"],
  javacopts = ["-Xep:NullAway:ERROR", "-XepOpt:NullAway:AnnotatedPackages=something",
  ...
)

bazel build --verbose_failures ... ; cat bazel-out/....jar-0.params shows -XepOpt:NullAway:AnnotatedPackages present

Difference in .params from 6.1.2 to 6.3.0 seems to be just

> -Xep:IgnoredPureGetter:OFF
> -Xep:EmptyTopLevelDeclaration:OFF
> -Xep:LenientFormatStringValidation:OFF
> -Xep:ReturnMissingNullable:OFF
> -Xep:UseCorrectAssertInTests:OFF

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

WORKSPACE:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

RULES_JVM_EXTERNAL_TAG = "5.3"
RULES_JVM_EXTERNAL_SHA ="d31e369b854322ca5098ea12c69d7175ded971435e55c18dd9dd5f29cc5249ac"

http_archive(
    name = "rules_jvm_external",
    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
    sha256 = RULES_JVM_EXTERNAL_SHA,
    url = "https://github.com/bazelbuild/rules_jvm_external/releases/download/%s/rules_jvm_external-%s.tar.gz" % (RULES_JVM_EXTERNAL_TAG, RULES_JVM_EXTERNAL_TAG)
)

load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")

rules_jvm_external_deps()

load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")

rules_jvm_external_setup()

load("@rules_jvm_external//:defs.bzl", "maven_install")

maven_install(
    name = "nullaway",
    artifacts = [
        "com.uber.nullaway:nullaway:0.10.11",
    ],
    repositories = [
        "https://repo1.maven.org/maven2",
    ],
)

BUILD

java_plugin(
    name = "nullaway",
    visibility = ["//visibility:public"],
    deps = [
        "@nullaway//:com_uber_nullaway_nullaway",
    ],
)

java_library(
  name = "a",
  javacopts = ["-Xep:NullAway:ERROR", "-XepOpt:NullAway:AnnotatedPackages=something"],
  plugins = [":nullaway"],
  srcs = ["A.java"],
)

A.java

class A {
}

Command

$ bazel build a --verbose_failures -s
...
...
A.java:1: error: An unhandled exception was thrown by the Error Prone static analysis plugin.
class A {
^
     Please report this at https://github.com/google/error-prone/issues/new and include the following:
  
     error-prone version: 2.19.1
     BugPattern: NullAway
     Stack Trace:
     java.lang.IllegalStateException: To run the NullAway analysis plugin please specify analysis options with -XepOpt:NullAway:[...]. You should at least specify annotated packages, using the -XepOpt:NullAway:AnnotatedPackages=[...] flag.
...

Which operating system are you running Bazel on?

NixOS

What is the output of bazel info release?

release 6.3.0- (@non-git)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Didn't find any obviously related change between 6.1.2 and 6.3.0 yet

Have you found anything relevant by searching the web?

No response

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

Would be good to fix in 6.3.1 #19045

[fmeum]

I tested this by adding javacopts = ["-foobar"] to some java_library target, but got the expected java.lang.IllegalArgumentException: error: invalid flag: -foobar failure.

Could you provide a reproducer? It's quite possible that something else broke, but it's unlikely that javacopts is literally ignored.

[dmivankov]

Updated the description, wasn't looking at correct place for javacopts, they aren't on cmdline args but rather in a .params file.
Trying to narrow it down more, looks like it's specific either to plugins or to some incompatibility with nullaway

[dmivankov]

Likely a regression/incompatibility between error-prone going 2.11.0 -> 2.20.0
Nullaway has fake default constructor that will error out (seems to be a requirement to have it in some error-prone versions) https://github.com/uber/NullAway/blob/master/nullaway/src/main/java/com/uber/nullaway/NullAway.java#L268
And a flags-aware constructor that is not used, sounds like error-prone 2.19 bug google/error-prone#3931

What is weird is that it should be 2.20 https://github.com/bazelbuild/bazel/tree/release-6.3.0/third_party/error_prone
but logs say 2.19.1

     error-prone version: 2.19.1

META-INF/maven/com.google.errorprone/error_prone_core/pom.properties in third_party/error_prone/error_prone_core-2.20.0.jar also says 2.20.0

[dmivankov]

Added repro case to description. Wasn't able to validate which error-prone version is bundled in 6.3.0 release. Dist file seems to have 2.20.0 (both jar name and META-INF/maven/com.google.errorprone/error_prone_core/pom.properties resource inside jar match it) but not seeing where it goes in bazel install_base, $(bazel info install_base)/A-server.jar doesn't have it inside

[dmivankov]

Found where it comes from

# /DEFAULT.WORKSPACE.SUFFIX:364:6
http_archive(
  name = "remote_java_tools",
  generator_name = "remote_java_tools",
  generator_function = "maybe",
  urls = ["https://mirror.bazel.build/bazel_java_tools/releases/java/v12.5/java_tools-v12.5.zip", "https://github.com/bazelbuild/java_tools/releases/download/java_v12.5/java_tools-v12.5.zip"],
  sha256 = "942b3d88ebd785a5face38049077a1f8dab5a3500f5ebd0c0df090244acc4e16",
)

inside that archive java_tools/JavaBuilder_deploy.jar contains bundled 2.19.1 error-prone
as seen in following files inside the jar

./META-INF/maven/com.google.errorprone/error_prone_annotation/pom.properties
artifactId=error_prone_annotation
groupId=com.google.errorprone
version=2.19.1
./META-INF/maven/com.google.errorprone/error_prone_type_annotations/pom.properties
artifactId=error_prone_type_annotations
groupId=com.google.errorprone
version=2.19.1
./META-INF/maven/com.google.errorprone/error_prone_check_api/pom.properties
artifactId=error_prone_check_api
groupId=com.google.errorprone
version=2.19.1
./META-INF/maven/com.google.errorprone/error_prone_core/pom.properties
artifactId=error_prone_core
groupId=com.google.errorprone
version=2.19.1

[meteorcloudy]

/cc @cushon @hvadehra

[dmivankov]

My guess is latest java_tools 12.5 was published from older 6.3.0 (-rc) version when error-prone was only at 2.19.1 and wasn't updated on error-prone update to 2.20.0

[keertk]

@bazel-io fork 6.3.1

[meteorcloudy]

I think it's the opposite, java_tools 12.5 was built from sources of Bazel@HEAD, which still has errorprone 2.19.1:

bazel/WORKSPACE

Lines 422 to 426 in 6eb7dbb

	"com.google.errorprone:error_prone_annotation:2.19.1",
	"com.google.errorprone:error_prone_annotations:2.19.1",
	"com.google.errorprone:error_prone_check_api:2.19.1",
	"com.google.errorprone:error_prone_core:2.19.1",
	"com.google.errorprone:error_prone_type_annotations:2.19.1",

[keertk]

@bazel-io fork 6.4.0

[keertk]

Closing this one since it has been addressed here: #19066
We'll cherry-pick this into the release branch.

[keertk]

Actually, leaving it open until the corresponding java_tools/rules_java update is also complete. Sorry!

[keertk]

Done - #19085

@dmivankov Thank you for reporting this issue.
We're looking to improve our release process so that we can catch more issues early on in the cycle (before the final release) and would love your input. What can we do to make it easier for you to test release candidates in the future?

[meteorcloudy]

@dmivankov Can you please confirm if this issue has been fixed in 6.3.1rc1?

[dmivankov]

@meteorcloudy run it on some of the targets and looks like it got resolved 🎉