When classes are loaded from a VM-specific .dill file, mixin
applications have been translated into normal classes. In that case
the mixin class will be found as the only implemented type.
Change-Id: I6543f1e0bad72d351efb0a768f2c9c8967b8a196
Reviewed-on: https://dart-review.googlesource.com/43965
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
We want the implicit tear-off of a `call` method to succeed even if
the value is `null`, so we need the implicit tear-off to be equivalent
to `?.call`.
Change-Id: I5134858b84e501081a52d59b78b101597bdfcc4a
Reviewed-on: https://dart-review.googlesource.com/43480
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the AstBuilder and OutlineBuilder
to generate the following errors:
* ConstConstructorWithBody
* ConstMethod
* ConstructorWithReturnType
* FieldInitializerOutsideConstructor
In order to get the necessary state in OutlineBuilder so that I could
report these errors, I extracted SourceLibraryBuilder.addConstructor
from addProcedure.
In addition, I updated AstBuilder to use handleRecoverableError
rather than parser.reportRecoverableError.
Change-Id: I8b5517ec2ab44ff13a65628c594f803138cad6f5
Reviewed-on: https://dart-review.googlesource.com/43800
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This refactors how modifiers are passed to listener so that the
OutlineBuilder can report a static constructor error.
* Remove handleModifier/s calls from parseMethod
* Pass name and modifiers in beginMethod event
* Update listeners to process method modifiers in beginMethod event
* AstBuilder
* NodeListener
* OutlineBuilder
* Address comment in https://dart-review.googlesource.com/c/sdk/+/42800
Change-Id: Iabd4a18613c1814eb5a157df4acf60dd9060d5eb
Reviewed-on: https://dart-review.googlesource.com/43120
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
We have decided to move to a different API for Fasta/Analyzer
integration, one that doesn't involve compiling to Kernel or observing
type inference. The listener API will become broken, so let's just
remove it before that happens.
We lose the ability to trace type inference so let's restore that
ability next. The analyzer's resolution storer is not used, but that
code has been left. The resolution applier will no longer work
without the resolution storer, so those tests have been disabled.
Change-Id: If9ac5aba2d5de7788d8a65f7fa8410599e636d21
Reviewed-on: https://dart-review.googlesource.com/42400
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This CL adds a test that bootstraps from a dill with a deferred library
in it. Before this CL it crashed, see bug #32245.
This CL "double fixes" the problem:
a) When lazy loading a dill file the _currentLibrary variable wasn't set
properly. This has been fixed.
b) When bootstrapping from a dill file, (almost) everything in the dill
will be included in the output so lazy loading it doesn't make sense.
Bug: 32245.
Change-Id: I94980608e19633fd31b522651a4a05b9cf7beabd
Reviewed-on: https://dart-review.googlesource.com/42600
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
When bootstrapping from an existing dill file, the incremental compiler
tries to create a bit-perfect output in the case where nothing has
changed (even if something had been marked as changed).
To do this it has to ensure that the order of the libraries doesn't
change. The previous implementation of this just inserted a library with
the same url as before at the exact same index as in the original dill
file which works fine (and is linear time) in the case where there are
no old libraries that dissappear. When for instance the first library
disappear, though, things go awry.
This CL introduces a test for it and fixes the issue by simply sorting
the libaries based on the original placement instead.
Fixes#32197.
Bug: 32197
Change-Id: I57bf20d7b8ec9232844d52d9e3a28cad474a5311
Reviewed-on: https://dart-review.googlesource.com/42401
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, importing a nonexisting "dart:" uri resulted in a crash in
fasta. This CL introduces a test and fixes the problem.
Fixes#31172.
Change-Id: I61b2668466f2567e5e5dcaff3203f0c5ee9a885f
Reviewed-on: https://dart-review.googlesource.com/36401
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This CL updates the fasta parser to report more errors
and have improved recovery. The new errors reported include:
* IllegalAssignmentToNonAssignable
* MissingAssignableSelector
* StaticConstructor
In addition, a number of test expectations were updated
to match the errors already produced by the fasta parser.
Change-Id: I99889e8e64663ca5b81a5d5d8f5e5241d049a0a2
Reviewed-on: https://dart-review.googlesource.com/41100
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Previously the everything between parentheses was considered as condition which
is incorrect.
This fixes test failures on Flutter test/foundation/error_reporting_test.dart.
Change-Id: Icce41f0fbb44e38d2f49b60dfc0dc52881d2e4d2
Reviewed-on: https://dart-review.googlesource.com/40521
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Dan Rubel