[
https://issues.apache.org/jira/browse/GROOVY-12252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-12252.
--------------------------------
Fix Version/s: 6.0.0-beta-2
Resolution: Fixed
> NullChecker: honour @Nullable type arguments reaching results via generics
> (get(0), xs[0], head())
> --------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12252
> URL: https://issues.apache.org/jira/browse/GROOVY-12252
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-typecheckers
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Fix For: 6.0.0-beta-2
>
>
> GROOVY-12206 and GROOVY-12207 made type-use nullability annotations available
> from compiled dependencies, and the parser attaches them within source type
> arguments (GROOVY-11178) — but the {{NullChecker}} type-checking extension
> never looked _inside_ type arguments. Calling {{get(0)}} on a
> {{List<@Nullable String>}} — JSpecify's headline capability, generics
> nullness — passed silently.
> This issue teaches the checker to honour {{@Nullable}} type arguments
> wherever the static type checker's generics inference carries them through a
> *class or method level type variable*:
> * {{get(0)}} on a {{List<@Nullable String>}}, including subtype receivers
> such as {{ArrayList<@Nullable String>}}
> * the idiomatic subscript {{xs\[0]}} and GDK calls like {{head()}} /
> {{first()}}
> * {{get(key)}} and {{m\[key]}} on a {{Map<String, @Nullable Integer>}}
> The nullable result participates in the checker's existing analyses:
> unguarded dereference is an error, safe navigation and the recognised guard
> patterns are accepted, passing the result to a {{@NonNull}} parameter or
> returning it from a {{@NonNull}} method is an error, and in flow-sensitive
> mode ({{NullChecker(strict: true)}}) the nullness is tracked through
> assignments to unannotated variables. It works whether the annotated type
> appears in source or is read from a compiled dependency, and — consistent
> with the checker's design — with {{@Nullable}} annotations from any library,
> matched by simple name.
> Example:
> {code:groovy}
> import groovy.transform.TypeChecked
> import org.jspecify.annotations.Nullable
> @TypeChecked(extensions = 'groovy.typecheckers.NullChecker')
> class Catalog {
> static int firstTitleLength(List<@Nullable String> titles) {
> titles.get(0).length() // also flagged:
> titles[0].length()
> }
> }
> {code}
> {noformat}
> [Static type checking] - Potential null dereference: 'get()' may return null
> {noformat}
> Implementation note: the static type checker's generics inference preserves
> type-use annotations when instantiating class and method level type
> variables, so the check reads the {{@Nullable}} annotation directly off an
> expression's inferred type — no separate substitution machinery, and
> method-level type variables (the DGM/subscript cases) come along for free.
> Not yet covered, left for a follow-up umbrella issue: nullable type
> parameters and bounds ({{<T extends @Nullable Object>}}), wildcards at use
> sites, {{@Nullable}} checking of arguments against instantiated parameter
> types (e.g. {{add(null)}} on a {{List<@NonNull String>}}), and array
> component positions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
