JSpecify: support inference for calls to generic methods

[msridhar]

This will be a significant challenge in general, but maybe we can handle the common cases and do something useful without having a full technique. See here for one test case:

NullAway/nullaway/src/test/java/com/uber/nullaway/jspecify/GenericMethodTests.java

Lines 141 to 160 in 7a3d088

	"package com.uber;",
	"import org.jspecify.annotations.Nullable;",
	"class Test {",
	" static class Foo {",
	" <C extends @Nullable Object> void foo(C c, Visitor<C> visitor) {",
	" visitor.visit(this, c);",
	" }",
	" }",
	" static abstract class Visitor<C extends @Nullable Object> {",
	" abstract void visit(Foo foo, C c);",
	" }",
	" static class MyVisitor extends Visitor<@Nullable Void> {",
	" @Override",
	" void visit(Foo foo, @Nullable Void c) {}",
	" }",
	" static void test(Foo f) {",
	" // this is safe",
	" f.foo(null, new MyVisitor());",
	" }",
	"}")

[agrieve]

Hit this as well.

The specific case I ran into was in this form:

@NullMarked
public class Foo {
  public static class Key<T extends @Nullable Object> {}

  private static final Key<@Nullable Foo> KEY = new Key();

  public static <T extends @Nullable Object> void setValue(Key<T> key, T value) {
  }

  public static void main() {
    setValue(KEY, null);
  }
}

[msridhar]

Thanks for the example! We are working on this.

[cpovirk]

FYI, this (or something very similar) came up when Dropwizard upgraded to a new version of Caffeine. Fortunately, in their case, they appear to be better off just removing their usage of @Nullable.

[agrieve]

Heh, this is coming up more with the new release because now our annotations within generics are being noticed more :P.

Here's a simpler example:

import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

@NullMarked
public class Foo {

  public static void test(@Nullable Object foo) {
      helper(foo);
  }

  private static <T extends @Nullable Object> void helper(T value) {
      System.out.println(value);
  }
}

Foo.java:10: warning: [NullAway] passing @Nullable parameter 'foo' where @NonNull is required
      helper(foo);
             ^
    (see http://t.uber.com/nullaway )

The best work-arounds I've found so far are:

1. Use explicit generics at callsite:

  public static void test(@Nullable Object foo) {
      Foo.<@Nullable Object>helper(foo);
  }

2. Marking the helper as @NullUnmarked:

  @NullUnmarked
  private static <T extends @Nullable Object> void helper(T value) {
      System.out.println(value);
  }

Just sharing in case it's helpful to anyone else.

[msridhar]

I hope that #1131 will cover many common cases here, but it's a subtle change and we're still working on it. @agrieve once that PR is landed I may ask if you can test on Chromium with a snapshot build.

I'm glad to hear that explicit generics have worked for you. That what I would have hoped / expected, though we definitely aim to eliminate the need for these as much as possible.

[msridhar]

Actually, small correction, we will handle the specific case from #1075 (comment) in a follow-up to #1131