Low-priority main-eisop: [type.invalid.super.wildcard] bounds must have the same annotations.

[cpovirk]

I've seen this error exactly once for this line in TreeRangeMap.

TreeRangeMap.java:438: error: [type.invalid.super.wildcard] bounds must have the same annotations.
            BiFunction<? super Object, ? super @Nullable Object, ? extends @Nullable Object>
                       ^
  super bound  : Object?
  extends bound: Object

I have some memory that javac makes it impossible to represent a type like "upper bound of @Nullable Object, lower bound of @NonNull Object." Like, it collapses it down to just Object or to just ? or something?? I can't remember, even though I thought I might have filed an issue against typetools about this, which might have contributed to the error above? [edit: now discussed here]

Again, this is low-priority, since it comes up extremely rarely. I'm just filing the issue so that I can check it off my list. We will have bigger issues to look at before this one :)

[wmdietl]

#166 handles the EISOP error message in our tests and jspecify/jspecify#485 adapted some tests to have the issue less frequently.

I think with the defaulting changes in #165 this should only arise when it actually is an error.
Once #165 is merged, please see whether we need to change something about this.

[cpovirk]

(We still see this after #165, but I'm not worried about it for a single failure.)

[wmdietl]

It turns out that the error message was incorrect. I'm fixing that here: eisop/checker-framework#745

With the fixed message, it makes sense. In null-marked code, the "super" bound is non-null, whereas the implicit extends bound is nullable.

We would need to re-think how we default Object-bounded wildcards to avoid this problem. Please let me know whether I should look into this.

[cpovirk]

Ah, I'd missed that the message was backward :)

I think this is fine to leave alone. If it starts coming up often enough that we feel that we need to care, then maybe we can use unspecified nullness or find some deeper solution. But for one single error, let's not worry about it.