To stay up to date

We need to handle wildcards eventually, but in the meantime, avoid
reporting false positives.

Fixes #1126

…ment (#1140)

Fixes #1127 

Our previous (hacky) logic for determining the type of a conditional
expression on the RHS of an assignment did not account for the
expression possibly being enclosed in parentheses.

Fixes #1139. There are real scenarios where projects may not want to
ship with a JSpecify dependence; see
#1139 (comment).
So, we remove any cases where we were specifically checking for or using
JSpecify's `@Nullable` annotation.

Most of the code changes are due to the fact that now, we check if an
annotation is a `@Nullable` annotation using
`Nullness.hasNullableAnnotation`, which requires a `Config` object as a
parameter. So we need to thread a `Config` object as a parameter through
a bunch of methods.

Before we would not print nullability of the top-level array type. Also
improve spacing.

Previously, we neglected to acknowledge explicit `@Nullable` return
types and `@NonNull` parameter types in `@NullUnmarked` code unless the
`AcknowledgeRestrictiveAnnotations` setting was passed. But, the
JSpecify spec requires acknowledging restrictive annotations in
`@NullUnmarked` code. So now, in JSpecify mode, we always acknowledge
restrictive annotations.

Note that in JSpecify mode, this change will also impact handling of
other "unannotated" code that is not explicitly annotated
`@NullUnmarked`. But, as discussed in #978, we want to switch to
acknowledging restrictive annotations by default anyway. It seems
reasonable to go ahead and make this change in JSpecify mode, to ensure
greater spec compliance.

… when performing substitutions (#1143)

Fixes #1091 

Consider the following code:
```java
abstract class Test {
  abstract <V> @nullable V foo(Function<@nullable V, @nullable V> f);
  void testPositive(Function<String, String> f) {
     this.<String>foo(f); // error
  }
} 
```
The call to `foo` should not type check. Since the type of its parameter
`f` is `Function<@nullable V, @nullable V>`, with explicit `@Nullable`
annotations on the type variables, any `Function` passed to `foo` must
have `@Nullable` type arguments. In typechecking this code, NullAway
previously substituted the type arguments for the type variables in
`foo` just using built-in `javac` routines. But, this would yield a
formal parameter type `Function<String, String>`, as the `javac` routine
would not retain the explicit type arguments in the right places. So we
would miss reporting an error. This PR fixes the substitutions and
re-introduces the annotations on type variables, so we get the type
`Function<@nullable String, @nullable String>` for the formal parameter
at the call, and report an error correctly. Substitutions were broken in
other cases as well; substituting `@Nullable V` for `@Nullable V` (where
`V` is a type variable) yielded just `V`, which led to false positives
(like #1091).

The main logic changes are in `TypeSubstitutionUtils`. We add a new
`RestoreNullnessAnnotationsVisitor` and use it to restore nullability
annotations from type variables after performing a substitution.

We also extract the `TypeMetadataBuilder` logic to a top-level source
file, and add new methods as needed for this PR. Some of this could have
been split into a separate PR but it's a bit of a pain to extract it
now.

…1147)

Spring Framework 6.2 introduced two annotations, `@MockitoBean` and
`@MockitoSpyBean`, that supersede Spring Boot's `@MockBean` and
`@SpyBean`. Add these annotations to the field ignore list.

I added changes to support local variables specifically for arrays.
Added a new class `LocalVariableLocation` that will contain location
details in the scenario when the target is a local variable.

---------

Co-authored-by: Manu Sridharan <msridhar@gmail.com>

Fixes #1148 

We add explicit support for any annotation named `@MonotonicNonNull` and
add our own version of the annotation to our annotations package. The
main additional support is that we now reason that once assigned a
non-null value, `@MonotonicNull` fields remain non-null when accessed
from subsequent lambdas, even if the lambdas are invoked asynchronously.