| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #289
Checker Framework 3.21.0 added support for switch expressions; we build on that to support the expressions in NullAway. We also add a `jdk17-unit-tests` module to test the support (which requires a JDK 12+ compiler).
|
|
Before, if a ternary expression was directly dereferenced, we wouldn't report an error if its type was `@Nullable`, which is a soundness issue.
|
|
* Cancel outdated jobs using the GitHub Actions [`concurrency` feature](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#concurrency). Apart from reducing wasted CI resources, I think we definitely want this on the main branch, as otherwise if we merged two PRs close together, there could possibly be weird race conditions with uploading snapshots (not 100% sure but better to be safe I think).
* Change the JDK 11 and 17 CI job config to _exclude_ building of certain submodules, rather than only _including_ a few tasks. This way we will see if we break new stuff on these JDK versions in the future.
|
|
* Make the `test-java-lib-lombok` code compile on JDK 17
* Test that all Java code compiles on JDK 11 and 17 in CI (with related cleanup in `continuous-integration.yml`)
* Minor cleanup in `build.gradle`
|
|
This change adds a CI job so we run the same tests on JDK 17 that we currently run on JDK 11. Currently we only test using the latest version of Error Prone; we could also test using 2.4.0 if desired. In either case, the new job(s) should be added as "required" for future changes to land.
|
|
The key new feature here is that the dataflow library no longer crashes on switch expressions / arrow case labels in switch statements:
https://github.com/typetools/checker-framework/blob/checker-framework-3.20.0/docs/CHANGELOG.md#version-3200-december-6-2021
This is an initial step toward fixing #289, though we will need precise control-flow graphs (which is still a WIP in Checker dataflow) to really handle these constructs properly.
|
|
|
|
One new checker [MemoizeConstantVisitorStateLookups](http://errorprone.info/bugpattern/MemoizeConstantVisitorStateLookups) pointed out some inefficient code in our checkers. Otherwise, a standard update.
|
|
The primary goal of this PR is to support the usage of the class `io.grpc.Metadata` in a way that feels natural to how NullAway already handles maps.
Handling `io.grpc.Metadata` is complicated by two factors:
* It implements `containsKey(...)` and `get(...)` methods that appear similar to the API of java maps, without actually implementing `java.util.Map`. Thus our existing support for maps can't handle this class, and this likely breaks developer expectations unless they are familiar with the implementation of both the grpc library and NullAway.
* Keys for `io.grpc.Metadata` aren't ever primitive types, but instead are usually references to fields of type `io.grpc.Metadata.Key<T>`. These fields are usually static and final (and the type is immutable), so they can safely be treated as constants, but our existing handling of compile-time constants in access paths is not enough here.
To solve this, we:
1) Implement equivalent logic to our usual map handling as a handler (`GrpcHandler`), which sets `x.y.z.get($foo)` as `@NonNull` on the then-branch whenever it sees a method node representing `x.y.z.containsKey($foo)`.
2) Improve on our handling of AccessPaths which include methods whose arguments point to static final fields of structurally immutable types (i.e. initialization-time constants, as opposed to compile-time). We allow handlers to declare the structurally immutable types they know (and care) about, rather than try to prove immutability as part of NullAway's analysis.
Note that a significant part of the code for implementing (2) involves threading knowledge of immutable types through the stateless AccessPath APIs. We accomplish this by creating a new `AccessPath.APContext` class, which is initialized by collecting information from all handlers whenever the dataflow analysis is initialized, and passed through all the operations manipulating access paths.
|
|
This builds upon PR #285 by adding support to code like:
```
if (x.get(ZERO) != null && x.get(ZERO).foo() != null) {
return x.get(ZERO).foo().bar();
}
```
Where `ZERO` is a compile-time evaluated constant. That is,
a `static final` variable or field of primitive or string type.
|
|
call (#503)
Fixes #502
Previously, we would just report the first error, even if there were issues at multiple parameter positions.
|
|
|
|
Note that with two benchmarks now, running `./gradlew jmh` will take around 25 minutes (this does _not_ run as part of `./gradlew build`).
|
|
|
|
|
|
|
|
Link to FB Infer Eradicate documentation was pointing to an outdated
and insecure (http) URL. Updated to the current upstream link.
|
|
|
|
The JMH tests only pass on JDK 11+. This makes `./gradlew build` pass again on JDK 8.
|
|
|
|
|
|
Also bump the EP version used to check NullAway.
|
|
|
|
With this change, the `:jmh:jmh` task will never appear "up to date" to Gradle, so it will never get skipped as such.
|
|
This is a first crack at creating a jmh module for benchmarking NullAway, so we can more easily detect performance regressions. We have a single benchmark for now, Caffeine 3.0.2. `./gradlew jmh` runs the benchmark. This is an MVP: in the future, we should add more benchmarks, make the benchmark runner more versatile, etc.
For now, running benchmarks only works on JDK 11. We can add support for JDK 8 in the future if we want (by adding EP javac to bootclasspaths, etc.).
|
|
|
|
specific to NullAway (#485)
Currently, NullAway uses the "dataflow" Maven artifact:
https://mvnrepository.com/artifact/org.checkerframework/dataflow
NullAway conflicts with other tools that also use the `dataflow` artifact. Therefore, the Checker Framework team has created a new shaded dataflow artifact just for NullAway to use:
https://mvnrepository.com/artifact/org.checkerframework/dataflow-nullaway
This pull request updates NullAway to use that artifact.
Also updates NullAway for API changes in the latest Checker Framework version; see https://github.com/uber/NullAway/pull/468 for further discussion.
Fixes #462
Co-authored-by: Manu Sridharan <msridhar@gmail.com>
|
|
`Supplier` (#483)
Fixes #479
|
|
Had to do a couple of other version updates to avoid use of removed features. Also, removed the EP 2.6.0 CI job.
|
|
Just needed to suppress one new check that crashes on Lombok code. Also added a (non-blocking for now) CI job to test NullAway running on EP 2.7.1.
|
|
This adds support for spring's `@Autowired` annotation as both a way to exclude fields from initialization checking (since Spring will inject them before any methods are called), and to mark methods as initializers. See [Spring's documentation](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/annotation/Autowired.html) and the discussion in #396
This is based on the original PR #475 contributed by @chat-eau-lumi (note CLA signature in that PR). It adds fixes to test cases, particularly around importing Spring classes and the constructor usage of `@Autowired`, contributed by @lazaroclapp.
|
|
This was surprisingly painless. We just had to suppress one new Error Prone check on a Lombok class, as it crashes. I tested locally that adding a buggy pattern for a new EP 2.6.0 check yields a warning as expected.
|
|
This adds a CLI parameter (`-XepOpt:NullAway:CustomContractAnnotations=`) to allow specifying names for Contract annotations to use instead of Jetbrains.
The structure of the spec string inside the annotation must still be the sub-set of Jetbrains' Contract spec currently supported by NullAway, and it must be available as the `value`/default argument to the annotation. The rationale is to support `@Contract` on codebases that do not wish to add the external Jetbrains dependency.
This implements #474.
|
|
Leveraging #470, add a CI job to build and test NullAway on Error Prone 2.6.0 (the latest release). Getting our tests to pass required adjusting to some API changes in the Error Prone test helpers APIs. Now, all tests pass on EP 2.6.0 and 2.4.0
|
|
With this change, the version of Error Prone that NullAway is compiled and tested against in a build can be changed via a project property `epApiVersion`. E.g., to compile and test against Error Prone 2.6.0 you can run:
```
./gradlew -PepApiVersion=2.6.0 build
```
When the property is not set, we default to the oldest currently-supported version of Error Prone (currently 2.4.0).
This change will enable running separate CI jobs to test NullAway against different Error Prone versions; that change (along with some test fixes) will come in a follow-up PR.
|
|
1. jcenter will been [sunset](https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/) so we shouldn't rely on it anymore as a repository.
2. Our `errorProneTestHelpers` dependence should be based on the `errorProneAPI` version that we are building against, not the `errorProne` version controlling how our own code gets checked.
|
|
See #463. `Path.getParent()` is a common JDK API and can return `null` when called on the root path.
|
|
|
|
|
|
This is a new NullAway artifact to serve as platform models
for the `android.jar` classes for SDK level 30 / Android 11,
providing nullability information for Android platform classes
as determined by the JarInfer tool.
The binary model jarinfer.astubx produced from AOSP tag
`android-11.0.0_r34` by running JarInfer on it as
described in `RELEASING.md`.
|
|
The Gradle plugin switch from `maven` to `maven-publish` caused
by #457 broke our setup for publishing `jar-infer-cli` as a far jar.
Since the jarinfer CLI is used for processing arbitrary jars inside
other builds, including jars that it depends on (e.g. guava), it
must be a fat jar with no dependencies.
Unfortunately, so far, the best way we've found to make this work
is to skip the default `maven` publication, then make a new publication
using the result of the `shadow` plugin, and re-add to it the
sources and javadoc artifacts from the original `maven` publication.
We also had to manually set up the pom file settings for this custom
publication. It is bit of a hack, but the end result is a fat jar with a sane,
dependency-free, pom file, and passes SonaType repository closing
validation.
|
|
|
|
Minor fix to the snapshot release command.
Also, we take the opportunity to:
- Remove `.travis.yml` and associated scripts
- Change the badge in `README` to point to the GitHub
Actions build.
|
|
Fixes #374
Avoid throwing exceptions when the source code contains records. Since
records are a new kind of class, refactor the switch statements that
make assertions about which elements and trees represent classes. Use
general purpose `isClassElement` and `isClassTree` methods that are
forward-compatible with records instead of enumerating `ElementKind` or
`Tree.Kind` constants.
Refactor `checkFieldInitialization` to ignore final fields. This check
was wrongly flagging records because it couldn't analyze record
constructors properly. Without the change to ignore final fields, this
check runs into two kinds of trouble with records:
1. It doesn't inspect record constructors at all because they are
generated. `NullAway.isConstructor(MethodTree)` returns false and
so those trees are skipped.
2. The trees for the generated constructors don't contain explicit
field assignments. That's just not how those were implemented.
Something else is responsible for assigning the fields at runtime,
apparently.
Rather than trying to teach NullAway about record constructors
specifically, count on javac to verify that all final fields are
initialized. Presumably, if NullAway were to complain that a constructor
did not initialize a final field, that complaint would be redundant (with
the error that javac would produce) at best and incorrect otherwise.
Co-authored-by: Manu Sridharan <msridhar@gmail.com>
|
|
Rather than maintaining our own `gradle-mvn-push.gradle` copy,
let's depend upon an existing plug-in, should help avoid
common issues when publishing maven artifacts (such as #456).
|
|
(#455)
|
|
|
|
|
|
|
|
|
