Lázaro Clapp
Lázaro Clapp
(There has to be a better way of doing this, just making a PR so we can track this and a possible solution)
And, ideally, a configurable list of annotations denoting generated source or AST structures. See #105 for the kind of issue this seeks to avoid, and the limitations of this fix.
See #1 comment on the `PiranhaUtils` class.
This change removes the short-lived `AcknowledgeLibraryModelsOfAnnotatedCode` configuration flag. It sets the behavior of NullAway to always allow library models to override the nullability of annotated code, with an important caveat...
Semantics of this method are fairly clear, it's `@Contract("!null -> !null)` for each element of its varargs. Is this something our library models already support? If not, we probably should....
This shouldn't be the case, as `Void` values are nullable, but see #608 and the suppression at `NullAwayCFGBuilder.NullAwayCFGTranslationPhaseOne.scanWithVoid(...)`
Follow up to #600. These values are already `ImmutableSet` at runtime (except one which was still used strictly as read-only). This change just makes it explicit.
We had to roll back the change in #586 . The primary reason was to support the following pattern, in the absence of full support for nullability of generics: Consider...
A `castToNonNull` as defined in the docs is simply an identity function annotated as `@Nullable -> @NonNull`, with a NullAway suppression, used to cast values we know must be non-null...
The following code is very natural to write, with unexpected nullability implications: ``` import java.util.stream.Stream; import javax.annotation.Nullable; public class Test { @Nullable String prefix = null; public void test(Stream suffixes)...