[jira] [Updated] (GROOVY-12252) NullChecker: honour @Nullable type arguments reaching results via generics (get(0), xs[0], head())

["Paul King (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-12252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King updated GROOVY-12252:
-------------------------------
    Description: 
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.


> 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
>
> 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)