Change-Id: I7e5d2e63bfd018d21ff9587f178440da39a5078d
Reviewed-on: https://dart-review.googlesource.com/71232
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>

Change-Id: Icaf6329729a17b20a591ae6e9b8bf7c0d2e21265
Reviewed-on: https://dart-review.googlesource.com/71368
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>

The signature of the overridden method buildCompoundAssignment in
KernelUnresolvedNameGenerator (c.f. kernel_expression_generator.dart)
was illegal, because its (named parameter) arity was four, whilst the
same method in one of its supertypes has arity five.

Furthermore, there was a signature conflict for
buildCompoundAssignment amongst the supertypes of
KernelUnresolvedNameGenerator:

   KernelUnresolvedNameGenerator
   extends KernelGenerator
           |
           = Generator with KernelExpressionGenerator
                            |
                            arity(buildCompoundAssignment) = 5
   with    ErroneousExpressionGenerator, UnresolvedNameGenerator.
           |
           arity(buildCompoundAssignment) = 4

In this CL the conflict is resolved by the "greatest common
denominator" approach, that is, now each implementation of
buildCompoundAssignment has arity five.

This CL is a necessary step towards fixing
#34235

Related change: c95ef87

Change-Id: If1992b8fb2bb994f83557c48fb0ac276b2d1a8d3
Reviewed-on: https://dart-review.googlesource.com/71520
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>

…ixin."

This reverts commit 03c7184.

Reason for revert: Flutter doesn't build with after this CL because the following (kind of) program

  abstract class RenderObject {
  String toString({int minLevel}) => "foo";
  }
  abstract class ContainerRenderObjectMixin extends RenderObject {}
  abstract class RenderBoxContainerDefaultsMixin implements 
  ContainerRenderObjectMixin {}

is wrongfully rejected. In patching this, I stumbled upon what seems to be bug in Fasta where some concrete classes arising from mixed in applications are marked as abstract, which causes the patch to produce false-positives. This needs some more investigation.

Original change's description:
> Enables arity check for overridden methods inherited from a mixin.
> 
> The return type and parameter types checks are still disabled for
> mixins as there is an issue with type parameters being uninstantiated
> in mixin applications which causes the two checks to produce
> false-positives. As a result the SDK fails to compile with the two
> checks enabled because the libraries (such as collections) makes
> extensive use of mixin application with generic types. I've opened a
> separate ticket to track this issue [c.f. #34285].
> 
> Furthermore this CL abstracts the arity check, return type check, and
> method parameter type check in checkMethodOverride to make it easier
> to understand the logic of the method.
> 
> Closes #34235 and closes #32014
> 
> Change-Id: Iae224926c2e99e6e89ccc3c19ec4bc7919ee48a5
> Reviewed-on: https://dart-review.googlesource.com/71781
> Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>

TBR=askesc@google.com,hillerstrom@google.com

Change-Id: Idee6f53c2d6a17ea8a4103872b1183c01e4d30ce
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/72108
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>