When one of the parameter types needs to be type inferred, don't also
try to use ordinary method type inference for the return type; it is
still inferred as `void`.
Add a test to make sure this corner case works, as well as a similar
corner case for setters (which did not require fixing).
Fixes#31779.
Change-Id: Id443260a12e44f88d9dadbbf916c13be3cc303b9
Reviewed-on: https://dart-review.googlesource.com/37300
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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>
Before: Kernel static errors were represented by throwing a distinguished
error or else by calling a distinguished library const constructor.
Now: Kernel static errors are represented by InvalidExpression. To support
error reporting, InvalidExpression has an optional message and a file
offset. A back end can choose to signal these errors at any time; for
example, when deserializing the binary, or when compiling the procedure
containing the static error, or when the erroneous expression is evaluated
at run time.
InvalidStatement is removed because it can be encoded as ExpressionStatement
of InvalidExpression.
Future work:
* supporting static errors where an expression cannot appear in the AST
* allowing InvalidExpression to contain an Expression for error recovery
* adding a top-level list of static errors and warnings to the binary
Bug: https://github.com/dart-lang/sdk/issues/29840
Change-Id: Ifdfe9a76cee6cefed28061bf245be70531d2f413
Reviewed-on: https://dart-review.googlesource.com/31320
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
This CL fixes type inference of closures using '=>' syntax so that
they infer consistently with an equivalent closure defined using block
syntax ('{}').
Fixes#31436.
Change-Id: I5463dd0ba986e9953ebabbc24ce3ced9a7220007
Reviewed-on: https://dart-review.googlesource.com/27084
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When an implicit cast can be proven by the front end to always fail,
due to the form of the expression being cast, the front end now
reports this as a compile-time error. (This feature is not new--it is
part of the analyzer's implementation of strong mode).
Newly failing tests are marked with issue #31537.
Change-Id: Ib3fc068352bb91dd283fa4b81d8104fa213eafe9
Reviewed-on: https://dart-review.googlesource.com/26420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previous to this CL, if a setter had an implicit return type, we
inferred both the return type of the setter and the parameter type,
even if the parameter type was specified.
Change-Id: I24ca8ceddbe021f0d779ffcad4bc63052ed5d87b
Reviewed-on: https://dart-review.googlesource.com/26565
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
This reverts commit 8e4b0bda23.
Reason for revert: Failures on most kernel bots
Original change's description:
> Route all messages through Loader.
>
> This ensures that all messages are passed to instrumentation.
>
> Issues addressed in this CL:
>
> * When I added addCompileTimeError, I forgot to remove addError.
>
> * All messages now all arrive in a single location (Loader). SourceLoader adds instrumentation by overriding recordMessage.
>
> * As I changed the type inferrer to use addCompileTimeError, I broke DDC. This is because the front_end API (generateKernelInternal in kernel_generator_impl.dart) returns null if there are any errors reported via addCompileTimeError (and this didn't happen with addError, that shouldn't have been there anyways).
>
> * Due to the previous problem, I changed generateKernelInternal to ignore errors, but then I started getting missing compile-time errors. This turned out to be due to the the silent parameter used during outline- and diet-parsing.
>
> * I've removed all the "silent" parameters. This didn't work reliably and have been confusing Brian, Dan, and me several times when making parser changes. Instead we detect duplicated messages and avoid reporting them more than once.
>
> * Types in error messages got names that where using a global object (globalDebuggingNames in pkg/kernel/lib/text/ast_to_text.dart). This meant that the #lib prefix would vary depending on how many tests were run which affected the serialized error message in pkg/front_end/testcases/invalid_assignment.dart.strong.expect.
>
> Change-Id: I3d89372d6593a6e7e50cce733f61eedb881e15ed
> Reviewed-on: https://dart-review.googlesource.com/24481
> Commit-Queue: Peter von der Ahé <ahe@google.com>
> Reviewed-by: Paul Berry <paulberry@google.com>
> Reviewed-by: Kevin Millikin <kmillikin@google.com>
TBR=paulberry@google.com,ahe@google.com,kmillikin@google.com
Change-Id: I9f7b345a8ff040fc7aa73c5cb605190e47fd284b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/25660
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Fixes#31440.
There is a minor change outside of type inference: the body builder
now stores the synthetic assignment (used for for-in loops that don't
declare their own variable) in ShadowForInStatement so that type
inference doesn't have to dig through the desugared kernel objects in
order to find it.
Change-Id: I6520695336560883e2aa07bb110378b7846c2e11
Reviewed-on: https://dart-review.googlesource.com/25040
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Assert initializers in Dart may be compiled directly to this form of initializer,
rather than through local initializers as is done now.
Bug:
Change-Id: Ia149ea3d1df5d1dc18be5636801604ffaf7ca7d8
Reviewed-on: https://dart-review.googlesource.com/14760
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This ensures that all messages are passed to instrumentation.
Issues addressed in this CL:
* When I added addCompileTimeError, I forgot to remove addError.
* All messages now all arrive in a single location (Loader). SourceLoader adds instrumentation by overriding recordMessage.
* As I changed the type inferrer to use addCompileTimeError, I broke DDC. This is because the front_end API (generateKernelInternal in kernel_generator_impl.dart) returns null if there are any errors reported via addCompileTimeError (and this didn't happen with addError, that shouldn't have been there anyways).
* Due to the previous problem, I changed generateKernelInternal to ignore errors, but then I started getting missing compile-time errors. This turned out to be due to the the silent parameter used during outline- and diet-parsing.
* I've removed all the "silent" parameters. This didn't work reliably and have been confusing Brian, Dan, and me several times when making parser changes. Instead we detect duplicated messages and avoid reporting them more than once.
* Types in error messages got names that where using a global object (globalDebuggingNames in pkg/kernel/lib/text/ast_to_text.dart). This meant that the #lib prefix would vary depending on how many tests were run which affected the serialized error message in pkg/front_end/testcases/invalid_assignment.dart.strong.expect.
Change-Id: I3d89372d6593a6e7e50cce733f61eedb881e15ed
Reviewed-on: https://dart-review.googlesource.com/24481
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
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>
Previously, a ShadowSyntheticExpression was its own kind of Expression
unrelated to any of the Expression types defined in the kernel. It
responded to visit requests by forwarding the visit request to the
desugared expression. This had the advantage that for serialization
purposes, ShadowSyntheticExpressions would automatically disappear.
But it had the disadvantage that if a ShadowSyntheticExpression ever
needed to be replaced with another node (e.g. because an implicit
downcast was needed), the _ChildReplacer would get confused by the
visitor forwarding and fail to replace the node properly.
This CL fixes the problem by changing ShadowSyntheticExpression to a
Let node of the form `let _ = null in desugaredExpression`. Since
this is a genuine kernel expression, it no longer needs special
visiting semantics, and node replacement works properly.
In most circumstances, we replace the ShadowSyntheticExpression with
its desugared equivalent during type inference, so the final
serialized kernel representation is unchanged. However, in a few rare
circumstances involving error recovery, a ShadowSyntheticExpression
remains in the tree. Semantically this shouldn't be a problem, since
the behavior of `let _ = null in x` is the same as the behavior of
`x`. Nonetheless, I hope to get rid of these rare circumstances in
follow up CLs.
Change-Id: Iacf8c0028c424ac9ef98ef8302680e289bf7a017
Reviewed-on: https://dart-review.googlesource.com/21571
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
kmillikin