The whereType method silently does the wrong thing without methods,
so make it throw until we turn them on everywhere.
Change-Id: Id934c8bdb4f682dbc3560d78fbca580e37297e2d
Reviewed-on: https://dart-review.googlesource.com/45744
Reviewed-by: Nate Bosch <nbosch@google.com>
Add `typeArguments` to Invocation.
Add constructors to Invocation, making it less necessary for users to create their own implementations.
Add tests.
Add Symbol.unaryMinus and Symbol.empty constants.
Change-Id: I70cb3265f9413617cf57fce1297e393a29eeb26a
Reviewed-on: https://dart-review.googlesource.com/40741
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Note: $fasta is true when passing --dart2js-with-kernel. This change will make it
easier to flip the default: the plan is that $fasta will be true by default
later on, and passing --dart2js-old-frontend will make it false.
TBR=sra@google.com
Change-Id: Ib917d55b2d14db954c56513af057dd9a37b9c825
Reviewed-on: https://dart-review.googlesource.com/44601
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Some legacy libraries may import dart:mirrors, but not use it. This CL turns them
into a runtime error temporarily to give some time for the library
maintainers to remove the import to dart:mirrors in the future.
Change-Id: I876133908d2a61300256915aab54730bdff51649
Reviewed-on: https://dart-review.googlesource.com/43640
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Emily Fortuna <efortuna@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 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>
Zach Anderson