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

[6.3.0] nullaway plugin stops compiling #19054

Closed
dmivankov opened this issue Jul 25, 2023 · 15 comments
Closed

[6.3.0] nullaway plugin stops compiling #19054

dmivankov opened this issue Jul 25, 2023 · 15 comments
Labels
P1 I'll work on this now. (Assignee required) team-Rules-Java Issues for Java rules type: bug

Comments

@dmivankov
Copy link
Contributor

dmivankov commented Jul 25, 2023

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
Copy link
Collaborator

fmeum commented Jul 25, 2023

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 dmivankov changed the title [6.3.0] javacopts= aren't applied [6.3.0] nullaway plugin stops compiling Jul 25, 2023
@dmivankov
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

/cc @cushon @hvadehra

@meteorcloudy meteorcloudy added P1 I'll work on this now. (Assignee required) and removed untriaged labels Jul 25, 2023
@dmivankov
Copy link
Contributor Author

dmivankov commented Jul 25, 2023

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
Copy link
Member

keertk commented Jul 25, 2023

@bazel-io fork 6.3.1

@meteorcloudy
Copy link
Member

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
Copy link
Member

keertk commented Jul 25, 2023

@bazel-io fork 6.4.0

cushon added a commit to cushon/bazel that referenced this issue Jul 25, 2023
@iancha1992 iancha1992 changed the title [6.3.0] nullaway plugin stops compiling [6.3.1] nullaway plugin stops compiling Jul 25, 2023
@iancha1992 iancha1992 changed the title [6.3.1] nullaway plugin stops compiling [6.3.0] nullaway plugin stops compiling Jul 25, 2023
copybara-service bot pushed a commit that referenced this issue Jul 26, 2023
#19054

Closes #19066.

PiperOrigin-RevId: 551150162
Change-Id: I433e4b72fce4625acffd87388da9dcfbf4b23c42
@keertk
Copy link
Member

keertk commented Jul 26, 2023

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

@keertk keertk closed this as completed Jul 26, 2023
@keertk
Copy link
Member

keertk commented Jul 26, 2023

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

@keertk keertk reopened this Jul 26, 2023
@keertk
Copy link
Member

keertk commented Jul 26, 2023

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?

@keertk keertk closed this as completed Jul 26, 2023
@meteorcloudy
Copy link
Member

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

@dmivankov
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 I'll work on this now. (Assignee required) team-Rules-Java Issues for Java rules type: bug
Projects
None yet
Development

No branches or pull requests

7 participants