[extension types] Specify that a method shadows an "inherited" setter, and vice versa

[eernstg]

Background: See dart-lang/sdk#53717, dart-lang/sdk#53719, dart-lang/sdk#53720.

This PR changes the extension types feature specification such that a method declaration in an extension type will shadow an "inherited" setter, and vice versa. This eliminates a setter/method conflict which couldn't otherwise be resolved.

For example:

extension type E1(int i) {
  set m1(_) {}
  void m2() {} 
  get m3 => 1;
  set m4(_) {}
}

extension type E2(int i) implements E1 {
  void m1() {} // OK, and `E2` does not have a setter named `m1=`.
  set m2(_) {} // OK, and `E2` does not have a method named `m2`.
  set m3(_) {} // OK, and `E2` has the full getter/setter pair.
  get m4 => 1; // OK, and `E2` has the full getter/setter pair.
}

void main() {
  var e2 = E2(1);
  e2.m1(); // OK.
  e2.m1 = 10; // Compile-time error.
  e2.m2 = 10; // OK.
  e2.m2(); // Compile-time error.
}

This PR has been accepted, so we need to reconsider dart-lang/sdk#53717 and its subtasks. They have been repurposed to get this spec change implemented:

• [analyzer] [extension types] Implement 'precludes' rule to eliminate method/setter conflicts sdk#53719
• [cfe] [extension types] Implement 'precludes' rule to eliminate method/setter conflicts sdk#53720

[eernstg]

I think the text has been clarified substantially, PTAL.

[eernstg]

Thanks!

[eernstg]

@johnniwinther, this spec change is being implemented in the analyzer as tracked by dart-lang/sdk#53719 and done in https://dart-review.googlesource.com/c/sdk/+/337641. Is there a need for an implementation issue and an implementation effort for the CFE as well, or is this already on track?

Just a quick check: The current version of the CFE (2534859b418898024576014b2ca99d379c3ccc3a) does not seem to have been updated to use the new 'precludes' rule, it still reports the method/setter conflicts.

[eernstg]

@johnniwinther, I just learned that the CFE implementation issue for this task could be dart-lang/sdk#53720 (OK, I forgot about that and then rediscovered it ;-). I added a comment there about the fact that the specification changed, and hence the issue is about implementing 'precludes' as specified in this PR, not about changing a confusing CFE error message.