uber / NullAway / #790 / 1
93%
master: 93%

DEFAULT BRANCH: master
Ran
Files 73
Run time 9s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 92.575% (+0.03%) from 92.55%
#790.1

push

github-actions

web-flow 
Fix bug in handling of TreatGeneratedAsUnannotated. (#580)

There was a bug introduced in #493 (and thus not part of our last release),
which caused `@Generated` annotations on inner classes to be ignored for
the purposes of the `TreatGeneratedAsUnannotated=true` option.

This is of particular relevance to Lombok builders, where the `@Builder`
annotation on clas `Foo`, will produce an inner `@Generated Foo.Builder`.

However, note that NullAway can handle checking of such generated code, as
Lombok will correctly propagate nullability annotations in fields to the arguments
of it's builder methods. 

Thus, for Lombok builders alone, the use of
`TreatGeneratedAsUnannotated=true` is not recommended.

Still, ignoring such annotation on inner classes - thus requiring annotation
of Lombok DTO fields - is inconsistent with the documentation and intended
effect of `TreatGeneratedAsUnannotated=true`. Additionally, other tools
might produce `@Generated` inner classes without suitable nullability info.

This PR fixes the bug by acknowledging `@Generated` on inner classes,
and treating it the same as for top-level classes.

In the future, we might want to make the distinction between "generated code
with nullability annotations" and "generated code without nullability annotations".
We could do this based on the annotation name, or allowing handlers to
override `shouldTreatAsUnannotated` below.

Note that the `shouldTreatAsUnannotated` method is also a good candidate for
part of our `@NullUnmarked` support, should that annotation become part
of JSpecify.

4763 of 5145 relevant lines covered (92.58%)

0.93 hits per line

Source Files on job #790.1