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

Fix logic for @Nullable annotation on type parameter #702

Merged
merged 3 commits into from
Dec 23, 2022

Conversation

msridhar
Copy link
Collaborator

We had logic to not consider type use annotations on type parameters when they appeared in return types, but not parameter types or field types.

Fixes #701

@coveralls
Copy link

coveralls commented Dec 22, 2022

Pull Request Test Coverage Report for Build #1015

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.04%) to 92.954%

Files with Coverage Reduction New Missed Lines %
../nullaway/src/main/java/com/uber/nullaway/NullabilityUtil.java 2 93.0%
Totals Coverage Status
Change from base Build #1012: 0.04%
Covered Lines: 5132
Relevant Lines: 5521

💛 - Coveralls

Copy link
Collaborator

@lazaroclapp lazaroclapp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🚀

@msridhar msridhar merged commit 5ccffb5 into master Dec 23, 2022
@msridhar msridhar deleted the nullable-annot-on-type-param branch December 23, 2022 18:31
lazaroclapp added a commit that referenced this pull request Jan 4, 2023
This resolves #705 by broadening our slightly overzealous filtering from #702.

We still want to filter type use annotations out when they happen on wildcards or
type parameters. However, we can handle annotations on inner types (i.e. `Foo.@nullable Bar`).
More importantly, these inner types appear implicitly in natural code involving inner classes,
such as:

```
class Bar {
   @nullable Foo foo; // <- this is, implicitly Bar.@nullable Foo !!
   class Foo { }
}
```

Not handling this case leads to confusing an unintuitive errors where a `@Nullable` annotation
with a type use location will seemingly stop working for certain fields at random, if those fields
are of an inner type.

Additionally, as part of this fix, we restore the handling of type use annotations at the start of
an array type as meaning the array object itself is `@Nullable` (i.e. `@Nullable Foo[] arr`, in
addition to the correct type use form `Foo @nullable[] arr`). This is technically incorrect, but
prohibiting it would break backwards compatibility with older versions of NullAway and surprise
users, specially those switching from declaration annotations to type use annotations.

See #708 for a full discussion of the tradeoffs and the path forward towards the proper semantics
for type use annotations.

Co-authored-by: Manu Sridharan <msridhar@gmail.com>
msridhar added a commit to msridhar/NullAway that referenced this pull request Jul 18, 2023
msridhar added a commit to msridhar/NullAway that referenced this pull request Jul 19, 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

Successfully merging this pull request may close these issues.

@Nullable annotation on type argument is interpreted as making the top-level type @Nullable
3 participants