inference of generic method's type argument leads to false negative

[theosotr]

Command

javac \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
  -J--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED \
  -J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED \
-processor org.checkerframework.checker.nullness.NullnessChecker \
-cp checker-framework-3.42.0-eisop4/checker/dist/checker.jar  Test.java

Program

import org.checkerframework.checker.nullness.qual.*;


public class Test {
    public static <T> T m(T x) { return x; }

    public static void main(String[] args) {
        @Nullable String p2 = null;
        var x = m(p2);
        @Nullable String y = x;
        y.replace("", "");
    }
}

Actual behavior

The code passes the checks, but I get NPE at runtime

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.replace(java.lang.CharSequence, java.lang.CharSequence)" because "<local3>" is null
        at Test.main(Test.java:11)

Expected behavior

The code should have been rejected.

[wmdietl]

Thanks for the report! I can reproduce the problem.

public class Test {
    public static <T> T m(T x) { return x; }

    public static void main(String[] args) {
        String p2 = null;
        var x = m(p2);
        String y = x;
        y.replace("", "");
    }
}

produces no warning. Changing the type of x from var to the supposedly equal String gives the expected warning.

[wmdietl]

As you didn't file this issue with typetools, I assume that it was fixed in a release we haven't pulled into eisop yet.
We'll verify this before working on a fix.

[theosotr]

Yes, you are right! It seems it has been fixed in typetools, because typetools 3.42.0 fails to identify the error, but typetoools 3.47.0 detects it! Next time, I will proceed with this verification step before opening an issue here. Thanks