JSpecify big wave 2 #4184
JSpecify big wave 2 #4184
Conversation
| "graphql.validation.ValidationError", | ||
| "graphql.validation.ValidationErrorClassification", | ||
| "graphql.validation.ValidationErrorType", | ||
| // These classes will not be public API later, exempt here while marked as experimental |
There was a problem hiding this comment.
There is an edge case where some classes have been annotated with "Experimental API" for the purposes of the defer work. They won't become public API later so I made a note in the JSpecify exemption rule
| private final List<SourceLocation> locations; | ||
| private final Map<String, Object> extensions; | ||
| private final List<Object> path; | ||
| private final @Nullable List<SourceLocation> locations; |
There was a problem hiding this comment.
The builder creates a non-nullable list, but that's only if the builder is called
| * @return a value or null | ||
| */ | ||
| public <T> T get(Object key) { | ||
| public <T> @Nullable T get(Object key) { |
There was a problem hiding this comment.
TODO: another case of the nullable generic issue
There was a problem hiding this comment.
Update - all values stored in the GraphQLContext are non-null. It's only going to return null if the key is not found. Let's keep it like this.
| */ | ||
| @SuppressWarnings("unchecked") | ||
| public <T> T getObject() { | ||
| public @Nullable <T> T getObject() { |
There was a problem hiding this comment.
TODO: another generic nullable check
There was a problem hiding this comment.
Edit: object should also be nullable
There was a problem hiding this comment.
I updated the prompt with more information on generics
|
I had a fix a bunch of tests when I changed Validation Error messages to be non-nullable This is as per the spec - messages in GraphQL errors must be present |
# Conflicts: # src/main/java/graphql/schema/GraphQLSchema.java
|
Special note for release notes: ValidationError technically has a breaking change, now a description must be not-nullable, which is consistent with the specification Previously there was a mismatch that ValidationError didn't enforce description. However that doesn't make much sense, if a user receives a validation error they should also receive a description to help explain and diagnose the error |
| @@ -0,0 +1,59 @@ | |||
| The task is to annotate public API classes (marked with `@PublicAPI`) with JSpecify nullability annotations. | |||
There was a problem hiding this comment.
This prompt is checked in so subagents can all share this context
This prompt will be deleted after this series of JSpecify annotations is completed
1 participant
We have many classes left to go for JSpecify, so rather than one class at a time I will do the remainder in large bundles. This adds annotations on ~50 classes.
The general recipe here is
What will be in a future PR: better Kotlin tooling as reported recently in #4179