Fix bugs in reading varargs annotations from bytecodes

[msridhar]

For the case of declaration annotations, we were using Flags.VARARGS to check if a Symbol represented a varargs parameter, but this only works if the method is defined in source code. We add new methods for varargs parameters that may be defined in bytecodes, and always check for declaration annotations in such cases.

For type use annotations on parameters, for a method from bytecodes the annotation info is stored on the method's symbol, not the parameter's. We borrow some Error Prone code to handle this case.

[codecov]

Codecov Report

Attention: Patch coverage is 75.67568% with 9 lines in your changes missing coverage. Please review.

Project coverage is 87.60%. Comparing base (2a9188b) to head (f30299a).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...c/main/java/com/uber/nullaway/NullabilityUtil.java	72.72%	5 Missing and 4 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1055      +/-   ##
============================================
- Coverage     87.61%   87.60%   -0.02%     
- Complexity     2183     2203      +20     
============================================
  Files            85       85              
  Lines          7161     7187      +26     
  Branches       1404     1415      +11     
============================================
+ Hits           6274     6296      +22     
- Misses          453      456       +3     
- Partials        434      435       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[msridhar]

Found another bug, will try to fix it as part of this PR

[msridhar]

Now ready for review again 🙂

[lazaroclapp]

Some nits, but overall LGTM

[lazaroclapp]

Do we have the true positive case test somewhere? E.g. something showing that:

NonNullParamFunctionTypeUse n3 = (@Nullable Object x) -> (x == null) ? \"null\" : x.toString();",

Fails if NonNullParamFunctionTypeUse is equivalent to NonNullParamFunctionTypeUse but without @Nullable on takeVal.

Also, how about assigning a lambda that doesn't check for null?

Feel free to ignore if these tests already exist somewhere (they well might), just checking since this test below implies those cases too.

[msridhar]

I think those tests exist here:

https://github.com/uber/NullAway/blob/master/nullaway/src/test/resources/com/uber/nullaway/testdata/NullAwayJava8NegativeCases.java
https://github.com/uber/NullAway/blob/master/nullaway/src/test/resources/com/uber/nullaway/testdata/NullAwayJava8PositiveCases.java

The key difference in the new unit test is that @Nullable is a type-use annotation rather than a declaration annotation, and with our new logic we initially weren't reading it out correctly. I added a comment in a59a7a8

[lazaroclapp]

Can we add the case passing new Varargs(x, y) where x is non-null but y is @Nullable?

[msridhar]

0abca22

[lazaroclapp]

Is there a way to annotate varargs as non-null array of non-null elements? Do we want a test case for that? (separate from RestrictivelyAnnotatedVarargs.test)

I'd even argue that it is exceedingly rare for the intention of a varargs argument to be "a potentially nullable array of non-null elements", but I guess we should follow JSpecify here either way.

[msridhar]

I added this test in f30299a and it exposed a bug which I fixed! We still don't report an error when passing a @Nullable array for this case; that requires a full and proper fix for #1027

[lazaroclapp]

If we care only about one case, why is this a switch and not an if?

[msridhar]

dac889d