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>
(was reverted in https://dart-review.googlesource.com/c/sdk/+/40980
due to an analyzer bot breakage)
Original commit message:
Implement proper checking for callability of Function class.
There was some old (incorrect) logic for doing this, behind the flag
enableStrictCallChecks. This flag has been removed, since the new
behavior is now standard in Dart 2.0.
Fixes#31509
Change-Id: Ice5cf38bbc648badf7f2563ff930b69f9a799635
Reviewed-on: https://dart-review.googlesource.com/41120
Reviewed-by: Jonas Termansen <sortie@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>
The class hierarchy analysis maintains, for each class, a map from raw
supertypes to actual, parameterized supertypes. As an optimization, it
can share these maps between a class and one of its subclasses.
However, the sharing/copying mechanism sometimes ends up with entries
in the map that should not have been there.
This commit removes the optimization and always uses a separate map
for each class.
Closes https://github.com/dart-lang/sdk/issues/31996
Change-Id: I4c641d9c7d15706035791dd2b586a24045afceaa
Reviewed-on: https://dart-review.googlesource.com/39765
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
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>
This CL finishes the process of removing findMemberName from parsing
class members and sets the stage for improved recovery.
In addition, this CL:
* Revises the `endMethod` event to include a beforeParam token
so that the parser can revise the token stream before the parameters
during recovery.
* Reworks insertSyntheticIdentifer for use in more places
Change-Id: If5bcd6f554053f72429e938b5cd5e7021e03d5b3
Reviewed-on: https://dart-review.googlesource.com/39320
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@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>
The latter was already passing (because FutureOr<void>.isVoid is true
already, which was a condition of early bailout for MISSING_RETURN).
The former was not working, but is now handled.
Unit tests for each.
Change-Id: I0f6e7ddc71940517c5746c1a5431f4491ee2eef3
Reviewed-on: https://dart-review.googlesource.com/37440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
In addition to updating the fasta parser error messages, this CL
updates the recovery tests to automatically allow break/continue errors
in the valid and recovery code if those errors appear in the
base code being tested. For example, if the base code is
main() { break; }
the invalid code is
main() { var a break; }
and the expected recovery code is
main() { var a; break; }
then because the base code has a break-error, then that error
is allowed/expected in both the invalid and recovery code
without being explicitly listed in the test.
Change-Id: Ic7c188d6e6fb506ee83b8c99175caab3a82444f2
Reviewed-on: https://dart-review.googlesource.com/38500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
* Update expectations for 40+ recovery tests based upon the current
fasta parser code recovery and error messages so that those
recovery tests now pass
* Improve test failure message when comparing NodeLists
* Validate expected recovery code as the first step when running
the test and print an error message when the expected code is invalid.
* Compare the expected and actual AST structures before asserting
expected errors
Change-Id: I824d72939fb665c3e2f83cfbbdf9c313c8ca508a
Reviewed-on: https://dart-review.googlesource.com/38460
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This adds checks for allocations and type values, and provides a compile
time error for type declarations, is-checks, and as-casts.
Change-Id: I3bfed41b0dd45abeb02158f0537102c779511998
Reviewed-on: https://dart-review.googlesource.com/36383
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Konstantin Shcheglov