Some legacy VM configurations, i.e. non-strong mode VM configurations, will no
longer run the `language_2` tests after this CL, since
* these configurations run already on the legacy `language`
* we have many status file entries which are due to legacy mode not
supporting Dart 2.0 semantics
* people get regularly beaten by this when adding new tests, which
usually just results in more status file entries
* nobody is looking at these status file entries
Change-Id: Ief92d1da616a62572fb20c6c1198bbe818ea180a
Reviewed-on: https://dart-review.googlesource.com/55168
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is complicated by the fact that the normal factory method for creating
Invocation objects references the arguments descriptor to determine how many
type arguments are passed. This doesn't work for partially instantiated
closures, because the arguments descriptor will say "0" type arguments even when
there may be delayed type arguments attached to the closure from partial
instantiation. The arguments descriptor can't be modified, so we have a new
factory method which takes the number of delayed type arguments directly.
Change-Id: Ic9a35a482b3b7ef80564e674cc6207873e255111
Reviewed-on: https://dart-review.googlesource.com/54245
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Also fix the type inference algorithm so that when it explores
multiple alternatives (as a result of the use of FutureOr<>), if one
alternative generated some constraints but failed to produce a match,
it rewinds those constraints and tries the other alternative.
(Previously, it erroneously assumed that if any constraints were
generated, the alternative matched successfully).
Also add unit tests to verify the proper operation of the subtype
match algorithm.
Fixes#32305.
Change-Id: I060b5d6d5247a68d2b27bba78819bae172e43d97
Reviewed-on: https://dart-review.googlesource.com/53685
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Since there were already non-negative tests with the same numbers, I
gave them meaningful names.
Merged a couple of tests into the same file when it made sense since
multitests let us do that.
Deleted prefix1_negative_test, because it essentially tested only that
a random identifier does not resolve, which is not particularly related
to prefixes.
Change-Id: I91718f6df5126f123d9a8ea3abbc6898797db2db
Reviewed-on: https://dart-review.googlesource.com/52985
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In the process, I discovered multitests can't handle imports to
non-existent libraries. So I fixed that and cleaned up the code.
Change-Id: I9a8557e84f91ba7858bdf98f8732cd0ded55aa1a
Reviewed-on: https://dart-review.googlesource.com/52869
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
All fixes are related to the requirement that a concrete class must
implement its entire interface or have a non-trivial noSuchMethod
implementation.
Change-Id: I015e0565e5dd9cfa324c38bb43696e365c58329a
Reviewed-on: https://dart-review.googlesource.com/51880
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
* Preserve empty lines in the file header.
* Add empty entry to the tool's newly created sections.
* Remove extra empty line at the end of the file.
Change-Id: I271583774d5f5497025a9d85bcadf8b0b9e39e81
Reviewed-on: https://dart-review.googlesource.com/37600
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This is a "small" CL: Only comments in status files are changed.
Issue 31359 was split into a meta-bug 32782 and several other tool
specific issues, because 31359 was reported for dart2js-with-kernel,
but the problem affects several tools.
Change-Id: Ib47032aa622e232f24348bb55bc17d39a971cc2f
Reviewed-on: https://dart-review.googlesource.com/49701
Reviewed-by: Erik Ernst <eernst@google.com>
This fixes a problem where a defaulted optional argument
would cause the passed type parameters to be replace with dynamic.
Change-Id: I32cf327b3a4b6176f199164c840a1114fc302205
Reviewed-on: https://dart-review.googlesource.com/49081
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Note that this is a multi-test, which is helpful in order to make it visible which situations are covered and which ones are not, but when it all works it would make sense to just run everything in one step, in order to get better performance.
Change-Id: Ifab94f7ad369a7c76bab3337eabf2ddd22821b04
Reviewed-on: https://dart-review.googlesource.com/47882
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Hide private class _Future and map it to core lib class Future.
In Dart 2, show dynamic as type argument(s) of raw generic types.
Change-Id: I70b0e1707bc767d04838ac12d16b3ad15623f51f
Reviewed-on: https://dart-review.googlesource.com/48502
Reviewed-by: Siva Annamalai <asiva@google.com>
As tests/language_2/tearoff_dynamic_test.dart shows, it is perfectly
valid to take a tear-off of an instance method from null, and then call
hashCode from such tear-off.
The implementation of hashCode for closures, Closure::ComputeHash()
was calling Instance::Cast(receiver) which asserts for null.
This code is revised to allow null receiver.
Change-Id: I85cc7abf25aab99590b53403904e8bac25328308
Reviewed-on: https://dart-review.googlesource.com/45749
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously, we were setting `expression` incorrectly after generating
the implicit tear-off of .call, so if an implicit downcast was needed
as well, it was not attached to the proper kernel node, and the
resulting kernel representation was invalid.
Addresses the front end manifestation of #32426.
Change-Id: Ibd86b75c54a53db1fc4606b7583910c57e1c4aae
Reviewed-on: https://dart-review.googlesource.com/45522
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
In the VM, TypeRef (extending AbstractType) did _not_ implement
error(), meaning that callong error() on such a type would call it in
AbstractType which basically just says `UNREACHABLE();`.
This fixes the issue.
Change-Id: I6cb9ebe8f814296db8383c187c880f367b096312
Reviewed-on: https://dart-review.googlesource.com/44420
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This should be safe since the purpose of the inference is to find an
exact match for each type parameter; if an exact match is found but it
doesn't satisfy the "extends" constraint, that will be detected and
reported later. If an exact match isn't found, the type bound will be
filled in my instantiate-to-bounds.
Addresses the analyzer portion of issue #32353.
Change-Id: Ic9f71eefac2fa3f6f126957b9d1652ca1d990b89
Reviewed-on: https://dart-review.googlesource.com/44220
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Original description:
Change front_end handling of callable classes.
This CL is the first in a series of CLs to change the handling of
callable classes in Dart 2.0.
For purposes of this description, a "callable class" is a class whose
interface contains a `.call` method.
In Dart 1.0, a callable class was considered to be a subtype of the
`.call` method's function type. This allowed the user to create
custom objects with similar behavior to closures, but with additional
fields and methods.
In Dart 2.0, a callable class is just an ordinary class, with no
subtype relation to any particular function type. (Note however that
it is still permissible for a class to declare that it "implements
Function").
To reduce the amount of code broken by this change, a piece of
syntactic sugar is being added: if an expression whose static type is
a callable class appears where a function type is expected, an
implicit tear-off of the `.call` method is inserted.
Note that it is still possible at compile time to invoke an expression
whose static type is a callable class, and it is still possible at
runtime to invoke an expression whose runtime type is a callable
class; in both cases, this is considered an implicit invocation of the
class's `.call` method. This is unchanged from Dart 1.0 behavior.
This CL introduces test cases for the new behavior, and implements the
implicit tear-off of `.call` in the front end.
Still to be implemented in future CLs:
- Spec text needs to be written.
- DDC/analyzer code needs to be written to perform implicit tear-offs
of `.call`.
- The subtyping algorithm in DDC, analyzer, VM, and dart2js needs to
be changed so that callable classes are no longer considered
subtypes of any particular function type.
- A small corner case involving type parameters still needs to be
addressed (see TODO in
pkg/front_end/lib/src/fasta/type_inference/type_inferrer.dart).
Fixes#32064.
Change-Id: I0d397c608321e25ba42cc02aa8a516aa77aa7c9d
Reviewed-on: https://dart-review.googlesource.com/41280
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit f0a6330db0.
Reason for revert: Broken bots
Original change's description:
> Change front_end handling of callable classes.
>
> This CL is the first in a series of CLs to change the handling of
> callable classes in Dart 2.0.
>
> For purposes of this description, a "callable class" is a class whose
> interface contains a `.call` method.
>
> In Dart 1.0, a callable class was considered to be a subtype of the
> `.call` method's function type. This allowed the user to create
> custom objects with similar behavior to closures, but with additional
> fields and methods.
>
> In Dart 2.0, a callable class is just an ordinary class, with no
> subtype relation to any particular function type. (Note however that
> it is still permissible for a class to declare that it "implements
> Function").
>
> To reduce the amount of code broken by this change, a piece of
> syntactic sugar is being added: if an expression whose static type is
> a callable class appears where a function type is expected, an
> implicit tear-off of the `.call` method is inserted.
>
> Note that it is still possible at compile time to invoke an expression
> whose static type is a callable class, and it is still possible at
> runtime to invoke an expression whose runtime type is a callable
> class; in both cases, this is considered an implicit invocation of the
> class's `.call` method. This is unchanged from Dart 1.0 behavior.
>
> This CL introduces test cases for the new behavior, and implements the
> implicit tear-off of `.call` in the front end.
>
> Still to be implemented in future CLs:
>
> - Spec text needs to be written.
>
> - DDC/analyzer code needs to be written to perform implicit tear-offs
> of `.call`.
>
> - The subtyping algorithm in DDC, analyzer, VM, and dart2js needs to
> be changed so that callable classes are no longer considered
> subtypes of any particular function type.
>
> - A small corner case involving type parameters still needs to be
> addressed (see TODO in
> pkg/front_end/lib/src/fasta/type_inference/type_inferrer.dart).
>
> Fixes#32064.
>
> Change-Id: I6a86491047ae467a5e767cb3cc7cecb570b29308
> Reviewed-on: https://dart-review.googlesource.com/40508
> Commit-Queue: Paul Berry <paulberry@google.com>
> Reviewed-by: Kevin Millikin <kmillikin@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
TBR=paulberry@google.com,lrn@google.com,leafp@google.com,dmitryas@google.com,eernst@google.com,kmillikin@google.com
Change-Id: Ia3d3a6e46ceee2b2c55938bec95d09d50bbf06a7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/41240
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL is the first in a series of CLs to change the handling of
callable classes in Dart 2.0.
For purposes of this description, a "callable class" is a class whose
interface contains a `.call` method.
In Dart 1.0, a callable class was considered to be a subtype of the
`.call` method's function type. This allowed the user to create
custom objects with similar behavior to closures, but with additional
fields and methods.
In Dart 2.0, a callable class is just an ordinary class, with no
subtype relation to any particular function type. (Note however that
it is still permissible for a class to declare that it "implements
Function").
To reduce the amount of code broken by this change, a piece of
syntactic sugar is being added: if an expression whose static type is
a callable class appears where a function type is expected, an
implicit tear-off of the `.call` method is inserted.
Note that it is still possible at compile time to invoke an expression
whose static type is a callable class, and it is still possible at
runtime to invoke an expression whose runtime type is a callable
class; in both cases, this is considered an implicit invocation of the
class's `.call` method. This is unchanged from Dart 1.0 behavior.
This CL introduces test cases for the new behavior, and implements the
implicit tear-off of `.call` in the front end.
Still to be implemented in future CLs:
- Spec text needs to be written.
- DDC/analyzer code needs to be written to perform implicit tear-offs
of `.call`.
- The subtyping algorithm in DDC, analyzer, VM, and dart2js needs to
be changed so that callable classes are no longer considered
subtypes of any particular function type.
- A small corner case involving type parameters still needs to be
addressed (see TODO in
pkg/front_end/lib/src/fasta/type_inference/type_inferrer.dart).
Fixes#32064.
Change-Id: I6a86491047ae467a5e767cb3cc7cecb570b29308
Reviewed-on: https://dart-review.googlesource.com/40508
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This follows Leaf's simplified suggestion. As a temporary hack it
assumes that the mixin passes its type parameters through to its
superclass constraint unchanged.
Change-Id: I091b44005d6364a91e20578f2ff6340334b1fab6
Reviewed-on: https://dart-review.googlesource.com/38040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
'void' is now allowed as type annotation for locals, fields, and formal
parameters, in addition to being previously allowed as type argument.
Update status files.
Change-Id: I6459f56824dc0a695615d8dc87c9a8a1f9be29ef
Reviewed-on: https://dart-review.googlesource.com/37651
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
Martin Kustermann