The original change is available in patchset 1.
The changes since then are just status file updates.
Change-Id: I0c45c4b09a187bdd60c6a38bf23f6b7a0cf80c97
Reviewed-on: https://dart-review.googlesource.com/34400
Reviewed-by: Jens Johansen <jensj@google.com>
Change Fasta type inference and Kernel type checking to use the new
definition for Future flattening, which is really unwrapping (peeling
off one layer of Future or FutureOr). Use this for inferring types of
`await` expressions and return types from `async` functions.
Ensure that we are using the same notion of flattening for inference
and checking. (Maybe it was a red flag that we weren't.)
This fixes await_test so that it produces a runtime error rather than
a compile time error - see #31541.
A similar change will need to be made to the analyzer - see #31887.
Change-Id: I7d936e9788969a48fdc216628eaa793389fb5e30
Reviewed-on: https://dart-review.googlesource.com/34504
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reland of https://dart-review.googlesource.com/c/sdk/+/29160
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: Id3b3b7f1fc6a101639fc908c90f3ec7d304a7b4b
Reviewed-on: https://dart-review.googlesource.com/32580
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: I6acea31b8cba7dec8b318e081d28f4eb4ebbf75c
Reviewed-on: https://dart-review.googlesource.com/29160
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Fixes#31586.
Note that none of the back-ends handle Instantiation nodes yet, so the
language_2 tests added in this CL
(instantiate_tearoff_after_contravariance_check_test,
instantiate_tearoff_of_call_test, and instantiate_tearoff_test) fail
pretty much across the board right now.
Includes two fixes to Instantiation.getStaticType and the kernel type checker:
- Previously, they attempted to perform substitution on the full
function type, which had no effect because the type parameters were
bound.
- The type checker was not checking that type parameter bounds were
satisfied.
Note that the front end doesn't yet check that type parameter bounds
are satisfied by the inferred type parameters. I will address that in
a follow-up CL.
Change-Id: Ib0ad7a5fc5f4a2fdc8c99abe1f2d3d15b21a4974
Reviewed-on: https://dart-review.googlesource.com/29744
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Fixes#21938 (Front end does not warn on function calls on Object).
A small number of tests begin failing with this change--these tests
have been marked with issue #31533 for later triage.
Change-Id: I3a956410a6780772fe90098d8604fb10718504df
Reviewed-on: https://dart-review.googlesource.com/26045
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, the front end recovered from an invalid assignment by
producing an "as" expression, e.g.:
int x;
String y;
x = y;
Would produce an "invalid assignment" error, as well as this kernel
code:
int x;
String y;
x = y as{TypeError} int;
The rationale was that the "as" check was guaranteed to fail, so this
code would produce a runtime error at the correct location. However,
there were two problems:
1. (Minor problem) the "as" doesn't actually fail if the RHS is null.
2. (Major problem) for type inference, the type of an assignment
expression is defined to be the type of the RHS. This means that if
the invalid assignment gets used for type inference, we generate
mal-typed kernel code, e.g.:
int x;
String y;
var z = (x = y);
Gets compiled to:
int x;
String y;
String z = (x = y as{TypeError} int);
This CL addresses both problems by changing the kernel representation
so that it evaluates the RHS and then throws an exception. Since a
"throw" expression has type Bottom, the kernel representation is
guaranteed to be properly typed. This also ensures that an exception
gets thrown if the RHS is null. Finally, as a side bonus, it makes
the error-recovered kernel code more similar to the kernel code we
generate in other error recovery scenarios.
Change-Id: Iac74e0c726ce029ac0560d271413e85c15bfec5c
Reviewed-on: https://dart-review.googlesource.com/24140
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Note that there are currently some inconsistencies between how
function expressions are inferred depending whether they are defined
using `{}` or `=>` (see issue #31436). This CL preserves the existing
inconsistencies. Once we decide how we want to resolve issue #31436,
I'll revisit this code to ensure that it is still correct.
Change-Id: I3926a4b3dc51155d8f03adaae380b50aab39ca60
Reviewed-on: https://dart-review.googlesource.com/24622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Note that this CL makes a minor change outside of type inference: it
changes the BodyBuilder so that when it desugars a for-in loop that
assigns to a variable declared elsewhere, the desugared assignment is
expressed using shadow objects; this is necessary to ensure that the
type inference engine can walk the desugared assignment and insert an
implicit downcast if necessary.
Change-Id: I4d87f83b8a4b3b72e7ba8042ccd711f0d012fac0
Reviewed-on: https://dart-review.googlesource.com/24340
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
No language_2 tests are added to validate this behavior yet, because
we are still deciding what we want the semantics to be. I will follow
up with language_2 tests once the semantics have been decided upon.
Tests that have begun failing due to this change are marked with a
reference to issue #31402.
Change-Id: Ia24c9789220d09682b4b3ade9374d279ff2a4b6e
Reviewed-on: https://dart-review.googlesource.com/24320
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
New type of AST nodes RedirectingFactoryConstructor is added to Kernel.
The goal is to keep the information about redirecting factory
constructors in the class for the linking phase.
Change-Id: I7477c617fa7fd4935ceb23098ec7c056d1f286ca
Reviewed-on: https://dart-review.googlesource.com/14740
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
We never need to add assignability checks when doing top level
inference; putting the check inside checkAssignability avoids the need
to remember to put it at every call site.
In order to keep type inference consistent between top level and local
type inference, I've modified the handling of assignments so that the
computations performed by checkAssignability do not influence the
inferred types. For example, when performing type inference on `a =
b`, we used to consider the resulting expression to have the type of
`a` if a downcast was required, otherwise the type of `b`. Now we
always consider the type of the assignment to be the type of `b`.
This is consistent with the informal spec of type inference. This
change introduces some mal-typed kernel nodes in error recovery
situations, which I will fix in a future CL--see issue #31417.
Change-Id: I02e8dff54e2184e6f059d1339e51edf42c4cd058
Reviewed-on: https://dart-review.googlesource.com/22260
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Aske Simon Christensen