Provide a checker for JSpecify annotations in unrecognized locations #883

JSpecify defines recognized locations for @Nullable and @NonNull and states that annotations in other locations have no meaning. The specification also encourages source-analysis tools to offer an option that reports such annotations.

Could JSpecify provide a reusable checker, or more concrete guidance for tool authors, to diagnose these cases?

For example, a checker could report @Nullable int count = 0; because annotations on primitive type usages are unrecognized and cannot affect nullness semantics.

The diagnostic should include an Error Prone-style replacement when the intended recognized location is unambiguous:

Test.java:12: error: [JSpecifyUnrecognizedAnnotationLocation] A nullness annotation directly on a wildcard has no meaning under JSpecify.
    List<@Nullable ? extends Foo> values;
         ^
    Write the annotation on the wildcard bound instead:
    List<? extends @Nullable Foo> values;

For cases without an unambiguous replacement, the diagnostic should still show the desired valid form by recommending removal:

Test.java:8: error: [JSpecifyUnrecognizedAnnotationLocation] A nullness annotation on a primitive type has no meaning under JSpecify.
    @Nullable int count = 0;
    ^
    Remove the annotation:
    int count = 0;

This lets developers and automated refactoring agents apply the intended correction without having to infer it from the specification.

Other useful diagnostics would cover annotations on local-variable root types, receiver parameters, instanceof and pattern types, cast root types, object-creation root types, direct wildcard annotations, class declarations, type-parameter declarations, and other unrecognized declaration or type-use locations.

A source-level check seems preferable to bytecode validation, consistent with the specification’s guidance that bytecode readers may ignore annotations in unrecognized locations.

Reference: https://jspecify.dev/docs/spec/#recognized-type-use