This is a step towards removing the option --strong-mode because
it's supposed to be on by default.
Change-Id: I25da0038d12e359f9c628beb2f92293295f00185
Reviewed-on: https://dart-review.googlesource.com/39983
Reviewed-by: Jens Johansen <jensj@google.com>
It's no longer necessary to guard against $runtime != none in most
cases because running test.py with --runtime=none will treat runtime
failure expectations as Pass.
Change-Id: Ieaff9957ad951066d93a3303af5499c7655d67a6
Reviewed-on: https://dart-review.googlesource.com/41567
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This gets DDC and DDK to handle the block body of functions/methods in a
similar way, eliminating it from the JS if it is not necessary, and fixes
a bug in DDC for cases where we do need to emit a nested block scope.
Change-Id: I37d3d69bfcf9b1204385cca7785601fb7d6edfc3
Reviewed-on: https://dart-review.googlesource.com/41565
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
snapshot is a Dart2 snapshot or a Dart1 snapshot.
This will be used by the flutter engine to initialize itself
correctly based on the snapshot provided.
Change-Id: I06adaac74b350f96aa6ebb55887e4a81f09fbd14
Reviewed-on: https://dart-review.googlesource.com/41082
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Two comments.
1. We need also to change the Dart plugin for IntelliJ to not select
the whole line when selection if empty. The whole line is almost
never a good choice for Flutter.
2. This is not fully consistent with "Extract Lolal" where we give the
client the list of possible expressions to extract and the user can
then choose. Here we use just the smallest one. If we want to make
it consistent, we will need to enchance the protocol and the plugin.
R=brianwilkerson@google.com, devoncarew@google.com
Change-Id: I87a752234d9c825d78a6d787d2b21d1b252166c2
Reviewed-on: https://dart-review.googlesource.com/41520
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
The list of recognized methods in the VM includes information about
result type. If there is no known/concrete result cid, the list
contains dynamic. When StaticCallInstr for recognized method is created,
its result type was pulled from the list even if it was dynamic.
This change avoids setting result type to dynamic in such case
and fixes the assertion for conflicting result types from the list of
recognized methods and from global type inference.
Now, if list of recognized methods has dynamic, and inferred type
is available, the latter will be used.
Change-Id: I7da7313f93ca08a142226026a4645124c30cfd8f
Reviewed-on: https://dart-review.googlesource.com/41080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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>
Non-strong semantics are no longer supported in the analyzer. Testing
the old (non-strong) co19 suite with the analyzer just leads to
unnecessary status file churn.
Change-Id: I490dd9fee9a7916184c09c27883f8e7c1df5486c
Reviewed-on: https://dart-review.googlesource.com/41201
Reviewed-by: Brian Wilkerson <brianwilkerson@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 the second part of fixing #32077 - dealing with mints.
Example:
The runtime of a program adding 100,000 different mints to
a list and prints the last one:
Before: ~12.5 seconds
Now: ~1.2 seconds.
Change-Id: Iad6da1749886bab4e4d3941748cdbab51661c2c3
Reviewed-on: https://dart-review.googlesource.com/41161
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The language team several times agreed to make it an error when a
non-void expression `e` is used in `return e;` in the body of a
function whose return type is `void`.
When `void` is changed from a near-bottom type to a top type, the
wording in the language specification (dartLangSpec.tex) does _not_
ensure that this is an error, because all types are assignable to
`void`, so we need a specific rule saying that it is an error.
This CL adds such a rule to the feature spec for generalized void.
It also adds a rule that makes it an error to have return type `void`
in a function marked `async*` or `sync*`, based on the reasoning
that they "are returning a Future/Stream/Iterable semantically",
and it would now be an error if they did that explicitly.
Change-Id: I22fed9e9fc6097bb50100a151b964045e41ef173
Reviewed-on: https://dart-review.googlesource.com/35680
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@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>
Peter von der Ahé