False negative with type argument inference?

[msridhar]

import java.util.*;
import org.jspecify.annotations.*;
@NullMarked
class Test {
  public static <T extends @Nullable Object> T firstOrDefault(List<T> list, T defaultValue) {
    return list.isEmpty() ? defaultValue : list.get(0);
  }

  // expected an error here
  String field = firstOrDefault(Collections.singletonList(null), "hello");

  void takesNonNullString(String s) {}

  void test() {
    // expected an error here
    takesNonNullString(firstOrDefault(Collections.singletonList(null), "hello"));
  }
}

I would expect an error since at both call sites, making the type argument @Nullable doesn't work (since call result is assigned to a @NonNull location), but making it @NonNull doesn't work either (since we're putting null in the singleton List). Am I missing something?

[msridhar]

If I do:

  String field2 = firstOrDefault(new ArrayList<@Nullable String>(), "hello");

Then I get an error as expected.

I still don't get an error If I copy over singletonList so I'm not relying on the JDK library model:

  public static <U extends @Nullable Object> List<U> singletonList(U o) {
    throw new RuntimeException();
  }

  String field = firstOrDefault(singletonList(null), "hello");

[msridhar]

This version is rejected by the latest Checker Framework Nullness Checker:

import java.util.*;
import org.checkerframework.checker.nullness.qual.*;
class Test {
  public static <T extends @Nullable Object> T firstOrDefault(List<T> list, T defaultValue) {
    return list.isEmpty() ? defaultValue : list.get(0);
  }
  public static <U extends @Nullable Object> List<U> singletonList(U o) {
    throw new RuntimeException();
  }
  String field = firstOrDefault(singletonList(null), "hello");
}

So I think I'm not completely nuts 🙂

[msridhar]

@cpovirk @netdpb no urgency to address this one, but would love a sanity check that this is in fact a bug, as I'm doing some work on generic type argument inference for NullAway and checking my understanding.

[cpovirk]

I'm sorry, I see that I starred this when it first came in over a month ago, but I buried it in some other starred items, a few of which I feel almost as guilty about as this one... :)

I agree that the lack of errors at both call sites is a bug.

(The implementation details are not directly relevant to you, but: The most likely culprit is that we still use the Checker Framework's old implementation of type inference, which lets through some code even when it can't figure out the proper types. That behavior should improve once we're able to pick up the upstream changes.)

Thanks for continuing to plug away at generics support!