Precluding methods / setters in extension types

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/337641 breaks a few co19/ tests.

co19/LanguageFeatures/Extension-types/static_analysis_extension_types_A03_t05
co19/LanguageFeatures/Extension-types/static_analysis_extension_types_A03_t08
co19/LanguageFeatures/Extension-types/static_analysis_extension_types_A30_t02
co19/LanguageFeatures/Extension-types/superinterfaces_of_extension_type_A05_t08

For example

extension type V(int id) {
  external int id2;
}

extension type ET(int id) implements V {
  int id2() => id;
//    ^^^
// [analyzer] unspecified
// [cfe] unspecified
}

Are these tests to be updated?

[sgrekhov]

Are these tests to be updated?

I'm working on this. #2388. Thank you for the list of the failing tests

[sgrekhov]

@scheglov #2392 fixes failing tests except co19/LanguageFeatures/Extension-types/static_analysis_extension_types_A03_t08

// SharedOptions=--enable-experiment=inline-class

extension type I(int id) {
  void set id(int i) {}
}

extension type ET1(int id) {
  void set id(int i) {}
}

extension type ET2(int id) implements I {}

main() {
  ET1 et1 = ET1(1);
  et1.id = 0;

  ET2 et2 = ET2(2);
  et2.id = 0;  // COMPILE_TIME_ERROR.ASSIGNMENT_TO_FINAL 'id' can't be used as a setter because it's final.
}

@eernstg confirmed that this error is wrong. The test should pass according to the new rules

[eernstg]

Yes, the intention is that the new rules must make it possible to redeclare a getter as a method (because we generally allow an instance member declaration named n to be redeclared by any kind of instance member declaration named n), and if there is an "inherited" setter that would create a method/setter conflict then we just don't "inherit" it. Similarly for a setter where an otherwise "inherited" method would create a method/setter conflict, we just don't "inherit" the method.

It is still a conflict if two (extension type or non-extension type or a mixture) superinterfaces have a setter and a method with the same basename, and it is not redeclared.

So the new rules are only relevant if the current extension type has a declaration, they don't apply when the conflict occurs exclusively because of declarations in superinterfaces (for that case we just have all the conflicts that we had already). Also, the new rules don't apply unless there is a method declaration somewhere (as long as we're talking about getters and setters there is no conflict about the kinds of declarations, only potentially about the getter return type vs. the setter parameter type).

[scheglov]

Ah, of course, only setters and methods.

I'm working on fixing the fix.
Found a failure that I don't understand, co19/LanguageFeatures/Extension-types/static_analysis_extension_types_A30_t02.

extension type I(int id) {
  void set x(String i) {}
}

extension type ET1(int id) {
  void set x(String i) {}
  int get x => 42;
//        ^
// [analyzer] unspecified
// [cfe] unspecified
}

extension type ET2(int id) implements I {
  int get x => 42; // no error, the getter precludes the setter
}

@eernstg Why no error? My current understanding is that only methods preclude setters.

[sgrekhov]

Looks like a bug in the test. There should be a compile-time error. See #2401

[eernstg]

only methods preclude setters.

True, and there's a setter/getter signature conflict. I just landed #2401, so it should be on track now.