Daniel Hillerström
2f77de53e2
This reverts commit 03c7184cca.
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. https://github.com/dart-lang/sdk/issues/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 https://github.com/dart-lang/sdk/issues/34235 and closes https://github.com/dart-lang/sdk/issues/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>
37 lines
880 B
Dart
37 lines
880 B
Dart
// Copyright (c) 2017, the Dart project authors. Please see the AUTHORS file
|
|
// for details. All rights reserved. Use of this source code is governed by a
|
|
// BSD-style license that can be found in the LICENSE file.
|
|
|
|
// This test exercises a corner case of override checking that is safe from a
|
|
// soundness perspective, but which we haven't decided whether or not to allow
|
|
// from a usability perspective.
|
|
|
|
class A {
|
|
void foo() {}
|
|
}
|
|
|
|
abstract class I {
|
|
void foo([x]);
|
|
}
|
|
|
|
abstract class B extends A implements I {
|
|
// If this class were concrete, there would be a problem, since `new
|
|
// B().foo(42)` would be statically allowed, but would lead to invalid
|
|
// arguments being passed to A.foo. But since the class is abstract, there is
|
|
// no problem.
|
|
}
|
|
|
|
class C extends B {
|
|
void foo([x]) {
|
|
super.foo();
|
|
}
|
|
}
|
|
|
|
void f(B b) {
|
|
b.foo(42);
|
|
}
|
|
|
|
main() {
|
|
f(new C());
|
|
}
|