This reverts commit 9db4119b67.
Revert "Change default of 'keepFields' in constant transformation to true"
This reverts commit b1e14cbe5f.
Revert "[fasta] Don't create forwarding stub if there's already a member"
This reverts commit 51da94da76.
These commits are reverted to unblock rolls into Flutter.
b1e14cbe5f is reverted because it contained
changes that prevented clean revert of the other CLs.
Change-Id: I8d3c00f0c1b146f4debe7f1a1a7de75be154e265
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97802
Commit-Queue: Alexander Aprelev <aam@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Remove instrumentation for diagnostic messages, forwarding stubs and
covariance, since all this information is present in the expectation
files already.
Change-Id: Idf6622f7eddba801761e13666b470ae6dcc9d59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97106
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change all the places that still used old-style asynchronous async in
Fasta. These were mostly in testing.
Change-Id: I102209aa54c7c6e658b9d6ec98167af62bf12f3e
Reviewed-on: https://dart-review.googlesource.com/c/87074
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Type variable bound violations on constructor/factory invocations
now mention just the class name (which is the one that has the type
variables) instead of the constructor/factory name.
Change-Id: I65330f1921451fef0157be01b4a5086855d80439
Reviewed-on: https://dart-review.googlesource.com/c/85291
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This gets rid of the useless '#lib1::' prefixes on types in error
messages and instead adds a line to the error message for each
interface type appearing in the message stating where that type
originates.
Name clashes are disambiguated by appending markers like '/*1*/' and
'/*2*/' to the types whenever two interface types with the same name
appear in the same message.
The commonly used core types 'bool', 'num', 'int', 'double', 'String'
and 'Null' are excluded from the origin list unless they take part in a
name clash.
Change-Id: I017ea376d4f6ff2d4f3b36487774463f03bb3301
Reviewed-on: https://dart-review.googlesource.com/c/84604
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL the return type of any constructor function was
always void. According to the specification §9.3 the return type of a
constructor function ought to be its enclosing class.
Change-Id: I70d76cc354b7f118ce96bf4954daf7fe535eb7be
Reviewed-on: https://dart-review.googlesource.com/76160
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Async transformation uses dynamic variables in few places (e.g.
for temporaries and for incomming arguments) - which creates
not strongly typed AST with method invocations having dynamic
receivers and non-null interface targets at the same time.
To maintain strong typedness of the AST we insert unsafeCast
when accessing the temporaries.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: I11e38c128645ebc8acb0c982a80fe4c5c4036673
Reviewed-on: https://dart-review.googlesource.com/75000
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The VM debugger expects _completeOnAsyncReturn to be called when
returning from an async function for stepping out of the async function
to work.
This CL does just that.
Note that `_completeOnAsyncReturn` only exists in the VM, but as
the async transformation is only run for the VM target that shouldn't
be a problem.
Change-Id: Id71344310de918f743dcb1ad66e165fc649516ba
Reviewed-on: https://dart-review.googlesource.com/63383
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
With this change debugger requests yield(await) positions from kernel builder so it can confirm which frame handles what exceptions.
This also renames ':completer' to ':async_completer' in constructed kernel, so it is compliant with what VM expects to see(and updates test expectations accordingly).
Further it fixes async stack navigation for sync-async that became default in dart vm since first version went for the review((uses `future` getter, rather than property).
It also makes `future` getter non-debuggable to allow stepping-out of async methods.
Make Handle zone-scoped. Clean up frame counter var name.
Bug: https://github.com/dart-lang/sdk/issues/29056
Change-Id: Ia71f3c851a6b313655b57dad28c296f5dd081eda
Reviewed-on: https://dart-review.googlesource.com/54640
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This changes wrapInCompileTimeError so we are certain that
compile-time errors are reported before the erroneous nodes.
We want to preserve erroneous nodes as, long term, this should help
with code completion.
Also introduce a located version as my next CL I'll have slightly
more accurate locations.
Change-Id: Id83d4b7a7d4fe260916816d72fac331251bad948
Reviewed-on: https://dart-review.googlesource.com/50422
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@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>
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>
Sigmund Cherem