#2087. Add tests for parameters covariant-by-declaration

[sgrekhov]

No description provided.

[eernstg]

Looks good! We should have some extra cases, though: The modifier covariant should have the same effect if it is specified in the member declaration where the covariant change of the type actually occurs, but the entire set of tests should work the same when covariant is specified on a superinterface:

class A {
  void m1(covariant num n) {}
}

class C extends A {
  void m1(int n) {}
}

Similarly, it should also work the same when the modifier is added by some other superinterface; let's just do implements:

class A {
  void m1(num n) {}
}

abstract class B {
  void m1(covariant num n);
}

class C extends A implements B {
  void m1(int i) {}
}

[sgrekhov]

Tests updated. Please take another look

[eernstg]

Looks good! One little bit still missing:

I was worried when I saw that some tests have covariant in more than one location in the superinterface graph. The strongest test occurs when it is in just one place (the extends type, the implements type, the on type, or in the newly declared class itself), so we should cover the different kinds of locations with just one occurrence of covariant.

A couple of tests have multiple occurrences (Language/Classes/Instance_Methods/covariant_A01_t05.dart and Language/Classes/Instance_Methods/covariant_A01_t06.dart). It's fine to have that test case, too, but we should make sure that we're covering each location separately.

I think there's no occurrence of covariant in an on type?

[sgrekhov]

Updated. Excessive covariant were just a copy/paste effect. The intention was to left only one covariant in the superinterface graph. Thank you for noticing. Removed.

As for mixin M on I forgot about it. Added appropriate tests.

There will be one renaming PR after the merge to reorder these tests. It's much simpler to manage the tests if the similar tests are following each other

[eernstg]

Thanks, LGTM!

[eernstg]

Oh, one thing needs to be reconsidered after all:

I'm worried that we won't get the static analysis if there are syntax errors. But no_instance_t01.dart has a syntax error: Line 87 declares a setter as a local function, but that's a syntax error. The spec_parser complains about line 112-120 or so as well, but that disappears when the setter has been removed.

Also h2 needs to use parameter type int? or have a default value such that we get an error for the correct reason (everything other than the word covariant should be correct).

[sgrekhov]

Ups, sorry. Fixed.