#2953. Add inference with bounds tests

[sgrekhov]

Added examples from appropriate SDK issues. These tests fail without inference-using-bounds flag and pass with it. @eernstg @chloestefantsova what else can be added to test the new fucntionlity? Any advices are wellcome!

[eernstg]

Looks good!

I think we should have a test that includes mutually dependent type variables, something like this:

class A1<X extends A1<X, Y>, Y extends A2<X, Y>> {}
class A2<X extends A1<X, Y>, Y extends A2<X, Y>> {}
class B1 extends A1<B1, B2> {}
class B2 extends A2<B1, B2> {}
class C1 extends B1 {}
class C2 extends B2 {}
class D implements B1, B2 {}

void f<X extends A1<X, Y>, Y extends A2<X, Y>>(X x, Y y) {}

void main() {
  f<B1, B2>(B1(), B2());
  f<B1, B2>(C1(), C2());

  f(B1(), B2()); // Can only be inferred with this feature.
  f(C1(), C2()); // Ditto.
}

Also two levels of "extract the bound" would be nice:

class A<X extends Iterable<Y>, Y extends Iterable<Z>, Z> {
  A(X x);
}

void main() {
  var a = A([[1]]);
  print(a.runtimeType);
}

This actually prints A<List<List<int>>, Iterable<Object?>, dynamic> without the feature and A<List<List<int>>, List<int>, int> with the feature, which illustrates how much typing precision we're preserving.

Also (which wasn't entirely obvious ;-), it's nice to see that it does work also in both the mutually recursive case and in the "repeated" case.

[eernstg]

This seems to be an issue comment which is found here: dart-lang/language#3009 (comment). However, that's not the actual new rules, it's just an early attempt to find a useful set of rules.

Chloe actually found a much more concise way to specify this, which is also a better solution, and it is the one which is implemented.

So I'd recommend that you use the change to inference.md in dart-lang/language#4140 as the @assertion.

The actual change is that one item in an itemized list is added.

Perhaps the most readable presentation of that change would be to list the algorithm as a whole (that is, line 719-738 of inference.md in that PR), and then inform the reader that the given item has been added.

I guess the extra information to the reader would not be given as part of the @assertion, given that the assertion is expected to be a verbatim excerpt from a specification document. However, I think we've had a similar situation earlier, and there was some kind of marker (@commentary, or something with a similar meaning) which could be used to say things that aren't taken from a spec.

[eernstg]

Right, we should definitely have this test, that was the starting point for the whole thing.

[eernstg]

I think we should just have this:

Suggested change

	A(X x) {
	print('A<$X, $Y>');
	}
	A(X x);

There is no need to include the print statement when we have a better solution: expectStaticType.

[sgrekhov]

  f(B1(), B2()); // Can only be inferred with this feature.
  f(C1(), C2()); // Ditto.

Only the second case cannot be inferred without the feature. Starting point (described in dart-lang/language#3009) is:

class A<X extends A<X>> {}
class B extends A<B> {}
class C extends B {}

void f<X extends A<X>>(X x) {}

void main() {
  f(B()); // OK.
  f(C()); // Inference fails, compile-time error.
  f<B>(C()); // OK.
}

f(B1(), B2()); and f(B()); seems similar and can be both inferred without the feature.

[sgrekhov]

Moved to type system and updated accordingly. PTAL.

[eernstg]

LGTM