-
Notifications
You must be signed in to change notification settings - Fork 299
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
Adding support for nullable type upper bounds considering Library models #903
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another issue, see below
nullaway/src/test/java/com/uber/nullaway/NullAwayJSpecifyGenericsTests.java
Show resolved
Hide resolved
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #903 +/- ##
============================================
+ Coverage 86.98% 87.05% +0.07%
- Complexity 1959 1988 +29
============================================
Files 77 77
Lines 6330 6414 +84
Branches 1223 1245 +22
============================================
+ Hits 5506 5584 +78
- Misses 420 422 +2
- Partials 404 408 +4 ☔ View full report in Codecov by Sentry. |
Going ahead and merging this one. Thanks again @akulk022! |
The below line previously reported an error considering the upperbound of the generic type parameter couldn't be Nullable, adding it into library models to allow it to be Nullable passes the test case.
We now have library model methods for treating a type as
@NullMarked
and also for making the upper bound of type variables@Nullable
. We use these new methods to modeljava.util.function.Function
as@NullMarked
, in JSpecify mode only.We fixed a related issue with unwanted errors when passing a lambda / method reference to
@NullUnmarked
code; this was necessary to get NullAway itself to still build with NullAway checking enabled.(Due to issues with the branch this PR was recreated from the original #893)