Split "paradox" into 3 categories.

[cpovirk]

No description provided.

[cpovirk]

I had a realization about the new categories: Only one is purely "about" nullness:

• @Nullable int i

The others are more general:

• @Nullable @NullnessUnspecified Foo: This is a general category of "mutually incompatible" annotations. If we provided enough metadata, it could be checked by a tool that knows nothing about nullness (A meta-annotation to express "incompatible with <other annotations>" #101).

• class @Nullable Foo {}: This is a general category of "unrecognized TYPE_USE locations." Again, with enough metadata, it could be checked by a tool that knows nothing about nullness (A meta-annotation to express which TYPE_USE locations are recognized #136).

Based on that, I have tentatively named those 2 categories "jspecify_multiple_annotations" and "jspecify_unrecognized_location," without putting "nullness" in the name as I've been doing for the others (including new "jspecify_nullness_intrinsically_not_nullable"). @kevin1e100 , I think you may have been the one to suggest including "nullness" in the name of the initial tokens. Does omitting it from those 2 categories make sense to you? (Not that I want to overthink this :))

Once there is agreement on the names, I can update the sample inputs themselves accordingly.

[mernst]

This could also be "conflicting". When Jspecify expands, it may permit multiple annotations at a single location, such as int @NonNull @NonEmpty [].

[cpovirk]

Makes sense. Done.

(Mike and I had talked elsewhere about using the term "inconsistent." We set it aside because readers might also conclude that an annotation can be "inconsistent" with a corresponding annotation on a supermethod, for example. While we could have the same concern about "conflicting," I feel that it's clearer somehow. Perhaps it's more natural to assume that a "conflict" occurs between two things that are sitting right next to one another in the source file, whereas "inconsistency" is the kind of thing that you might see even between 2 completely separate codebases.)

I'll leave this PR open for a couple days to collect feedback from @kevin1e100 and other interested parties. After that, I'll make the changes to the sample inputs themselves and merge the PR. As always, we can revisit as needed.

[mernst]

This looks good, thanks.