[extension types] Implement 'precludes' rule to eliminate method/setter conflicts

[eernstg]

Edit Nov 24 2023: The language team accepted a proposal to introduce the notion of a declaration that 'precludes' another declaration or member signature, see dart-lang/language#3470.

As a consequence of that spec change, this issue will now have a new purpose: Implement the 'precludes' behavior. I added the 'implementation' label.

The error messages that gave rise to this issue will then not be emitted, because there is no conflict when one of the conflicting declarations has been 'precluded'.

---

Consider the following program:

extension type E1(int i) {
  set m(_) {}
}

extension type E2(int i) implements E1 {
  void m() {}
}

void main() {
  E2(1).m = 10;
}

The analyzer (DartPad, Dart SDK 3.2.0-140.0.dev) reports an error at the declaration of the method m (as it should, cf. [1] and [2]), but the error message is somewhat confusing. The CFE does not report any errors.

Subtasks:

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

[lrhn]

As commented on the CFE issue, I think we should consider changing the specification, so that the void m() {} declarations replaces all the m-base-name inherited members that it would conflict with, not just the one named m.

Just feels more consistent. The m() method is completely unrelated to the m-members it shadows, and replaces them entirely, so sticks out that it can still conflict with an inherited m= setter, and with no possible way to avoid it.

[eernstg]

Note that in a similar situation with extension members, we do actually allow an extension method to "override" an extension setter with the same basename:

extension on num {
  set foo(_) {}
}

extension on int {
  void foo() {}
}

void main() {
  int i = 1;
  i.foo = 10; // Error, can't assign to a method.
  i.foo(); // OK.
}

I think we should consider changing the specification, so that the void m() {} declarations replaces all the m-base-name inherited members that it would conflict with, not just the one named m.

Right, it does seem more consistent to me as well, and the behavior of extension methods is yet another (fuzzy) reason why it could be considered more consistent.

[eernstg]

Here's a proposal that allows methods and setters to shadow each other: dart-lang/language#3470.

[eernstg]

The proposal was accepted. This means that the setter/method errors should no longer be reported: When E is an extension type with a superinterface S that has a setter named n=, and E declares a method named n, the setter is simply not "inherited" from S to E, and there is no conflict. Similarly for the converse where S has a method and E declares a setter. Spec change in dart-lang/language#3470 as mentioned.