Implement the feature spec for checking returns against inferred
function return types:
https://github.com/dart-lang/sdk/blob/master/docs/language/informal/invalid_returns.md
with the change that an invalid return without a subexpression is
a warning, not an error. This is because it is a warning in the
analyzer and it would be a breaking change to turn it into an
error.
The check for valid returns is moved to exactly where we handle
returns, rather than in ensureAssignable which is used as a
helper in a lot of places. A bug in type inference was fixed: we
would use `void` for the type of return without a subexpression
instead of `null`. To accommodate that we would use a
non-standard subtyping relation for returns. This could lead to
us inferring a return type of `void` in cases where we should
not.
Change-Id: Iee9ece9c722f47efa305f49490d3022d0bbb9f44
Reviewed-on: https://dart-review.googlesource.com/72403
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The below code is not okay, even if we add a noSuchMethod to C.
```
class B {
foo(int x) => x;
}
class C extends B {
foo(int x, {int y});
}
```
Issue #32660.
Change-Id: I1ace4443c3732fdd5faefa50e0d2cb68023e97c4
Reviewed-on: https://dart-review.googlesource.com/72106
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
E.g. `new Map<String>` is now reported as an error.
Note that this does not add a check for whether correct types are given,
so e.g.
```
class Foo<X extends num> {}
main() {
new Foo<String>();
}
```
is not caught by this fix.
Fixes#32972, #32281.
Change-Id: I57513b5c13865a828890775c8e14f7433d00bdbe
Reviewed-on: https://dart-review.googlesource.com/72382
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
CallSpecializer::TryInlineInstanceSetter was using IsReceiver to determine
type check could be skipped. However it is incorrect to use IsReceiver,
because it uses SSA notion of the receiver - rather than a syntactic
notion and all strong mode guarantees apply at syntactic level.
Additionally this CL expands support for exactness tracking to PropertySet
operations and uses it to eliminate checks on setters.
Change-Id: Idce559c4ca4c88f5788d3b6b9955b5af076bd7eb
Reviewed-on: https://dart-review.googlesource.com/72442
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
When dynamically calling a generic function or method without passing
any explicit type arguments, the default bounds are used. The default
should be `dynamic` unless an explicit bound was provided for the type
parameter.
Change-Id: I82f7166303f936adbecedd0c633b518f2700def4
Reviewed-on: https://dart-review.googlesource.com/72081
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
When invoking an expression whose static type is not a function type,
signal an error. However, allow invocations of expressions with
static type `dynamic` or `Function`. Fixes#32975.
Change-Id: Ia54d8df650076ad5c9c9c3a2c6f79ea31acbbbfe
Reviewed-on: https://dart-review.googlesource.com/72082
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
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>
There should be no GCs between Instructions::New and
all write into the instructions object, because GC indiscriminately
write protects all code objects at the end of the GC.
In the previous version of the code assembler->GetCodeComments would
potentially trigger a GC and the code would crash trying to write
pointers into the code.
Also move FlushICache to the point after everything is written
into the code object.
Fixes#34030
Change-Id: I83742715f825f897a8612dda5ef7352c572517ee
Reviewed-on: https://dart-review.googlesource.com/72103
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Removed all sections labeled $compiler == dart2js and !$fasta.
Removed $fasta from all sections with $compiler == dart2js and merged
with existing sections as appropriate.
Some additional cleanup and normalization.
Change-Id: I8b93283a2cce22ce60e29d364c8d0e70dccbb6e3
Reviewed-on: https://dart-review.googlesource.com/71840
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
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>
When the superclass has a getter/setter pair, and the subclass only
overrides one of the pair, DDC will generate the other one to forward
to the superclass. However these should not be generated for abstract
accessors. This patch fixes the compiler so it skips abstract accessors.
Change-Id: I60fa83b57db2e42ab47b7f4f3c28ef2a56e324ec
Reviewed-on: https://dart-review.googlesource.com/72073
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
If a JS class is not found (because it's not loaded yet), dartdevc
should handle this gracefully. However the code assumed that the class
would not be nested in a module that itself has not been loaded. That's
fixed in this change.
Change-Id: I2de8f4b85e8063dea31ea257aca9721702c6ea7a
Reviewed-on: https://dart-review.googlesource.com/72065
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Generic closures should take delayed type arguments into account when
initializing type arguments in prologue.
Fixes language_2/instantiate_tearoff_test in bytecode mode.
Change-Id: I0ab07e759f3372ae9143a48f0b8b0fe4fab8a51a
Reviewed-on: https://dart-review.googlesource.com/71432
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Negative test cases
generic_function_type_as_type_argument_test/01
generic_function_type_as_type_argument_test/02
rely on a compile-time error, which is still missing in CFE.
Unlike default VM, bytecode pipeline does not flag this error.
Change-Id: I3c052b5ca6013ab0728ffc234b5ffbe2fddfec5d
Reviewed-on: https://dart-review.googlesource.com/71600
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
According to the specification (§10.9) it is a compile-time error to
extend, implement, or use FutureOr as a mixin.
Expands the "multiple implements" check to include a test for whether
a class attempts to extend or implement the 'FutureOr' class.
The mixin case is indirectly caught by another syntactic check for
mixed in types (c.f. checkSemantics method in source_loader.dart). It
verifies whether a mixin has zero constructors. Since FutureOr has a
constructor the check fails. This is technically enough to meet the
specification, but it leads to a confusing error message for this
particular case. To improve the quality of the error message, we may
want to merge some of the mixed in check into checkSupertypes in
kernel_class_builder.dart.
Closes https://github.com/dart-lang/sdk/issues/33744
Change-Id: I887ea9431fd50059399937f4236523ed917e3673
Reviewed-on: https://dart-review.googlesource.com/71141
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Konstantin Shcheglov