Unmarked type variables bounds in strict mode

[wmdietl]

Take

class UnmarkedBound<T> {}

Checking this in strict mode with ./demo -Astrict UnmarkedBound.java results in:

UnmarkedBound.java:1: error: [bound.type.incompatible] incompatible bounds in type parameter
class UnmarkedBound<T> {}
                    ^
  type: T
  upper bound: Object*
  lower bound: null*
UnmarkedBound.java:1: error: [bound.type.incompatible] incompatible bounds in type parameter
class UnmarkedBound<T> {}
                    ^
  type: T
  upper bound: Object*
  lower bound: null*
2 errors

The reason, I think, is the change in 9e27b8f

Both bounds are unspecified. In strict mode, two unspecified types are not subtypes, so the subtype test fails.

One simple option would be to override areBoundsValid and implement a more lenient check to validate bounds.

@cpovirk Do you see a nicer solution?

[cpovirk]

We might be able to override reportInvalidBounds to do nothing :) (Since JSpecify doesn't provide a way to annotate both bounds, anyway, that shouldn't cause any problems. I hope.)

Really, though, for an error in strict mode, I am fine with not worrying about it: I don't expect people to run in strict mode, and if anyone were to try it, I'd expect that person's goal to be to give every type a specified nullness (in which errors involving unspecified nullness are almost a feature :)). Strict mode exists largely so that we can make sure that it's possible and partially because the spec requires for lenient mode to implement one particular part of strict mode. So as long as we understand any problems that we encounter with strict mode (and we're clearly meeting that bar here), I'm not worried about fixing them if it's any trouble.

[wmdietl]

The conformance tests run in strict mode which is why I noticed this issue.

Overriding areBoundsValid seems to work nicely. I'm looking into another problem from #172. It looks like the return type of methods doesn't get defaulted correctly. If it's easy, I'll try to fix that and have proper lower bounds.