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

[eernstg]

This is the CFE specific issue for #53717. Consider the following example (which was taken from #53717):

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

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

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

The common front end does not report any errors for this program, but it should report a compile-time error at the declaration of void m() {} (or nearby), because E2 has a setter named m= and an instance method named m, cf. [1] and [2]).

[lrhn]

There are two possible behaviors here, both make sense:

• The one you describe, and currently specified, makes E2 nvalid because its member signatures contain both an m= setter and an m() method.
• Alternatively, we could let the m() method shadow both an m and an m= member from the super-extension-type, instead of just the m name.

I think we should go for that latter. We allow completely unrelated declarations to shadow super-interface members, so it seems a little off to not allow you to explicitly add a completely unrelated m method when it would conflict with an inherited m= setter. When a declared method conflicts with another method or getter, it just wins, so maybe it should also win in the conflict with an inherited m=.

(In which case the example program still has an error, at the E2(1).m = 10;, because E2 doesn't have an m= setter.

[eernstg]

I think we should go for that latter

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

@johnniwinther, I'm afraid we will need another update to the CFE if the language team prefers to accept dart-lang/language#3470. Sorry about the twisted path that this topic is following.

[eernstg]

dart-lang/language#3470 has been accepted by the language team, so we do indeed need to revisit this topic and get the 'precludes' behavior implemented.

I'll reopen this issue for that purpose. @johnniwinther, if you wish to handle this in a different issue then it would be great if you could change the subtask link in #53717 that currently points to this issue such that it points to the new issue that you will create.