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 change adds most of Dart 2 subtype checking to js_runtime.
The main observable change is the stronger subtyping of function types.
The subtype code is split into V1 and V2 methods with the intention to
eventually remove the V1 paths.
There is a lot of minor details that are still TODO:
- TODO: generalized void
- TODO: comparison on type variable by it's bound
- TODO: FutureOr
Change-Id: Id05db0aef5ce0d58416a72f1538a90ed67436b3e
Reviewed-on: https://dart-review.googlesource.com/37960
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
According to Leaf, Dart 2 type inference prefers to infer type
which is asked for, even if a more specific type can be inferred
from arguments.
It means that for
testIterable({"x": 1, "y": 1}.keys, ["x", "y"]);
where
testIterable(Iterable iterable, List expected, [int depth = 0])
the inferred type of map is Map<String, int>, but inferred type
of list is List (as testIterable argument type is List).
So this test is fixed by specifying type arguments of 'expected'
lists explicitly.
Change-Id: I2deab160038ee7abaad587920cb8fc620e09ebdf
Reviewed-on: https://dart-review.googlesource.com/39441
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This reverts commit 09eed74a8a.
Reason for revert: Too much SDK code is not yet compliant.
Original change's description:
> Make `void` a static warning to use almost everywhere.
>
> Changed the hint to a StaticWarningCode, since that's the new spec'd
> error type and the hint is no longer needed.
>
> Added a new set of methods to test the cases.
>
> Didn't try to solve the problem generally ("all usages except ... are
> errors" means it easier, in theory, to make a ReportVoidExpressions
> style visitor that catches absolutely all types) because most of the
> work is actually about suppressing errors that are no longer needed.
> Ie, from NO_SUCH_METHOD to USAGE_OF_VOID_RESULT which means we have to
> put the void handling logic into each AST method specially anyway.
>
> Some redundant tests removed.
>
> Don't flag: ternaries, void -> void assignments, void returns in
> dynamic.
>
> Change-Id: Ief8035dcfe582b36b6372180ddcf4e453d320d9c
> Reviewed-on: https://dart-review.googlesource.com/37441
> Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
TBR=leafp@google.com,scheglov@google.com,mfairhurst@google.com
Change-Id: I13ee4c6939468d35506779ade637a040833632f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/39848
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Changed the hint to a StaticWarningCode, since that's the new spec'd
error type and the hint is no longer needed.
Added a new set of methods to test the cases.
Didn't try to solve the problem generally ("all usages except ... are
errors" means it easier, in theory, to make a ReportVoidExpressions
style visitor that catches absolutely all types) because most of the
work is actually about suppressing errors that are no longer needed.
Ie, from NO_SUCH_METHOD to USAGE_OF_VOID_RESULT which means we have to
put the void handling logic into each AST method specially anyway.
Some redundant tests removed.
Don't flag: ternaries, void -> void assignments, void returns in
dynamic.
Change-Id: Ief8035dcfe582b36b6372180ddcf4e453d320d9c
Reviewed-on: https://dart-review.googlesource.com/37441
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Changes signature of Iterable.singleWhere.
Makes LinkedHashMap no longer be a HashMap.
Change-Id: Ibd7e56e1ac03cb9fb10d19d1328d452fcd06d89f
Reviewed-on: https://dart-review.googlesource.com/32541
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
From the docs of mixedInClass and mixin: the former is the direct thing that is
mixed in, but if it is a named mixin application it may not contain the actual
fields and procedures, instead the `.mixin` class does.
Change-Id: I049ced771925431d613b0b661154c1761fbe0a51
Reviewed-on: https://dart-review.googlesource.com/38161
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Emily Fortuna <efortuna@google.com>
* Change 'var iterable' to dynamic as type inference can only
infer Object type.
* Explicitly set result type of closures passed to reduce() to
make closure type compatible with parameter type expected by reduce().
* To modify List of Lists of int, add '[4]' instead of '4' to trigger
expected ConcurrentModificationError instead of type error.
* Remove splitting to multi-test.
* Format with dartfmt.
Change-Id: Ie1a35eececbf1133cb2384afad10e9d355016abe
Reviewed-on: https://dart-review.googlesource.com/36300
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The _2.status files are not normalized properly, so our script missed this.
We need to follow up with some additional fixes to the .status files and to add
to our script a way to detect these issues (typically whenever we have a "Pass"
and can't find the line that said otherwise).
TBR=johnniwinther@google.com
Change-Id: Icd4a6c003df86c0bf5c0894e971be13bc927f4ba
Reviewed-on: https://dart-review.googlesource.com/36480
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* double.compareTo(int) is fixed to handle integers which are not
precisely representable as doubles.
* int.compareTo(double) is fixed to properly handle doubles which
are clamped when converted to integers (with Dart 2.0 fixed-size
integers).
* Test for num.compareTo is updated for fixed-size integers; more corner
cases added.
Closes https://github.com/dart-lang/sdk/issues/31917
Change-Id: I8e98c3627f032082ab6a397713dece436585afd1
Reviewed-on: https://dart-review.googlesource.com/35004
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Two follow-on optimization would reduce the generated code to closer to the original size:
- It would be profitable to write an optimization the removes the type
information from any list when it can be proven the type information
is not used.
- Provided the split result list is not modified, we can strengthen
accesses to be non-null Strings.
Bug: https://github.com/dart-lang/sdk/issues/30548
Change-Id: I87ecdd129ec0227f982bd2e1f34193b3d6b0d81b
Reviewed-on: https://dart-review.googlesource.com/35081
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Régis Crelier