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

Demoting severity level for PreferredInterfaceType bug pattern (aka MutableConstantField) doesn't have any effect #3872

Closed
davido opened this issue Apr 22, 2023 · 4 comments

Comments

@davido
Copy link
Contributor

davido commented Apr 22, 2023

After bumping java_tools in Bazel to the latest released version v12.1: [1],
that was updated to the latest EP release 2.18 in: [2],
the configuration of error prone bug patterns using CLI option,
e.g.: -Xep:PreferredInterfaceType:WARN stopped working:

  $ bazeldev build //java/com/google/gerrit/extensions:api
ERROR: /home/davido/projects/gerrit/java/com/google/gerrit/extensions/BUILD:29:13: Building java/com/google/gerrit/extensions/libapi.jar (359 source files) and running annotation processors (AutoAnnotationProcessor, AutoValueProcessor, AutoOneOfProcessor) failed: (Exit 1): java failed: error executing command (from target //java/com/google/gerrit/extensions:api) external/remotejdk11_linux/bin/java -XX:-CompactStrings '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' ... (remaining 16 arguments skipped)
java/com/google/gerrit/extensions/conditions/BooleanCondition.java:273: error: [PreferredInterfaceType] Method return type can use a more specific type to convey more information to callers. Note that it is possible to return a more specific type even when overriding a method.
    public <T> Iterable<T> children(Class<T> type) {
                       ^
    (see https://errorprone.info/bugpattern/PreferredInterfaceType)
  Did you mean 'public <T> List<T> children(Class<T> type) {'?
Target //java/com/google/gerrit/extensions:api failed to build

^^^ What is unclear is as why the above bug pattern is activated in the first place,
because looking at the source code: [3] it is included in DISABLED_CHECKS section.

It turns out, that the above bug pattern references alternate names:

https://github.com/google/error-prone/blob/master/core/src/main/java/com/google/errorprone/bugpatterns/PreferredInterfaceType.java#L79-L83

/** Tightens types which refer to an Iterable, Map, Multimap, etc. */
@BugPattern(
    altNames = {"MutableConstantField", "MutableMethodReturnType"},
    summary = "This type can be more specific.",
    severity = WARNING)

So that actually to demote the severity to the level WARN, a different bug pattern has to be demoted: from -Xep:MutableConstantField:ERROR to -Xep:MutableConstantField:WARN.

Also the documentation doesn't mention, that those two bug patterns are related: [4].

Reproducer is here: [5].

[1] https://github.com/bazelbuild/java_tools/releases/tag/java_v12.1
[2] bazelbuild/bazel#17470
[3] https://github.com/google/error-prone/blob/master/core/src/main/java/com/google/errorprone/scanner/BuiltInCheckerSuppliers.java#L1116
[4] https://github.com/google/error-prone/blob/master/docs/bugpattern/PreferredInterfaceType.md
[5] https://gerrit-review.googlesource.com/c/gerrit/+/370334

hanwen pushed a commit to GerritCodeReview/gerrit that referenced this issue Apr 24, 2023
After upgrading MacOS to 13.3.1 the gerrit build fails with the
following errors apparently caused by zlib:

$ bazelisk build release
...
external/remote_java_tools/java_tools/zlib/gzwrite.c:89:20: error: call
to undeclared function 'write'; ISO C99 and later do not support
implicit function declarations [-Wimplicit-function-declaration]
            writ = write(state->fd, strm->next_in, put);
                   ^
external/remote_java_tools/java_tools/zlib/gzwrite.c:89:20: note: did
you mean 'fwrite'?
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/stdio.h:165:9:
note: 'fwrite' declared here
size_t   fwrite(const void * __restrict __ptr, size_t __size, size_t __nitems, FILE * __restrict __stream) __DARWIN_ALIAS(fwrite);
         ^
external/remote_java_tools/java_tools/zlib/gzwrite.c:110:24: error: call
to undeclared function 'write'; ISO C99 and later do not support
implicit function declarations [-Wimplicit-function-declaration]
                writ = write(state->fd, state->x.next, put);
                       ^
external/remote_java_tools/java_tools/zlib/gzwrite.c:661:9: error: call
to undeclared function 'close'; ISO C99 and later do not support
implicit function declarations [-Wimplicit-function-declaration]
    if (close(state->fd) == -1)
        ^

To fix this
- revert "Work around build errors on MacOS 13.3 and XCode 14.3"
- and follow the advise in [1]:
  - update bazel to 6.1.2
  - update remote_java_tools to 12.1
    https://github.com/bazelbuild/java_tools/releases/tag/java_v12.1

Set new errorprone bug patterns to WARN until we fixed occurrences.
Also demote the severity for these bug patterns to warning:

o LiteProtoToString
o MutableConstantField
o ProvidesMethodOutsideOfModule

Also suppress warnings for the following bug patterns: DoNotCall,
MathAbsoluteNegative and Unused using @SuppressWarnings annotation.

Also note that PreferredInterfaceType bug pattern is reported, but can
only be demoted to warning severity using the MutableConstantField bug
pattern, see also [2].

[1] bazelbuild/bazel#17956
[2] google/error-prone#3872

Release-Notes: Update bazel to 6.2.1 and remote_java_tools to 12.1 to fix build on MacOS 13.3
Change-Id: Ib9d8d8be44a58c470f712d297c39518498c43dc2
@cushon
Copy link
Collaborator

cushon commented May 5, 2023

I may not have absorbed all of the details here, but this sounds like the expected result of 48bbef0, the -Xep:CheckName:OFF flags now affect checks based on altNames in addition to name.

So if you had -Xep:PrimaryName:WARN -Xep:AltNameOfSameCheck:ERROR, the second flag was previously ignored, and now it has an effect.

@davido
Copy link
Contributor Author

davido commented May 5, 2023

So if you had -Xep:PrimaryName:WARN -Xep:AltNameOfSameCheck:ERROR, the second flag was previously ignored, and now it has an effect.

No alternative names for PreferredInterfaceType are documented: [1].

Are you suggesting that users should dive into EP code to find out why demoting using the primary name -Xep:PrimaryName:WARN (that was reported in the breakage) doesn't work?

[1] https://github.com/google/error-prone/blob/master/docs/bugpattern/PreferredInterfaceType.md

@cushon
Copy link
Collaborator

cushon commented May 5, 2023

The alt names are documented in https://errorprone.info/bugpattern/PreferredInterfaceType

@davido
Copy link
Contributor Author

davido commented May 5, 2023

You are right, I missed this line:

PreferredInterfaceType
This type can be more specific.

Severity
    WARNING

Alternate names: MutableConstantField, MutableMethodReturnType

Thanks for clarifying!

@davido davido closed this as completed May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants