In particular, we model Guava Functions as having a @NonNull return, but if you write (x) -> null and pass it as a Guava Function currently NullAway does not report an error. In contrast, writing (x) -> { return null; } yields an error. This should be relatively easy to fix, but it will lead to new errors when users do a NullAway update.
In our handling of lambdas, we immediately bail out of all checking if the corresponding functional interface method is unannotated:
https://github.com/uber/NullAway/blob/084bd96ff473252715229fc41e02ac11f6f2bfd1/nullaway/src/main/java/com/uber/nullaway/NullAway.java#L957-L959
But, this skips a check that is later performed for return types, where we allow library models to override return type nullability:
https://github.com/uber/NullAway/blob/084bd96ff473252715229fc41e02ac11f6f2bfd1/nullaway/src/main/java/com/uber/nullaway/NullAway.java#L875-L877
In particular, we model Guava
Functions as having a@NonNullreturn, but if you write(x) -> nulland pass it as a GuavaFunctioncurrently NullAway does not report an error. In contrast, writing(x) -> { return null; }yields an error. This should be relatively easy to fix, but it will lead to new errors when users do a NullAway update.