This CL completes the migration of the first wave of
interdependent libraries in package:kernel, including ast.dart.
In order to ensure non-nullability on AST properties, the Transformer
has been split in 2 variants: Transformer which doesn't support
removal of nodes and RemovingTransformer which supports removal where
allowed by the context using 'removal sentinels'.
Start reviewing Transformer and RemovingTransformer in visitors.dart
since many of the changes are caused by the changes here.
Included in the migration are the mixin_deduplication.dart and
unreachable_code_elimination.dart since these needed porting to
the RemovingTransformer which was aided by opting in the libraries
which only depended on ast.dart.
TEST=existing
Change-Id: I9e63b985bd24896c25edd4ee51e37770187bcc17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184786
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
For a method invocation temps might get allocated for both the receiver
and argument(s) so that:
A().foo(await null)
becomes:
Future<void> tmp0
...
tmp0 = A() // <- Type mismatch.
yield ...
tmp0 = tmp0.foo(:result) // <- Correct type.
This happens because the liveness analysis finds that the (previously
dynamic) temps can be reused.
Unfortunately 121988 added typing information to these temps, which
means they can't be simply reused in all cases.
This fix makes the temps dynamic again (by removing the type) but adds
unsafecasts to all VariableGets to propagate the know type.
Bug: https://github.com/flutter/flutter/issues/51828
Change-Id: I89c82763e0d4f8b102bb55dec3b694d017345517
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138500
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
Nullability.legacy is replaced with an appropriate invocation of a
method on Library to retrieve the appropriate nullability. Only
transformers in pkg/kernel and pkg/front_end are affected. The
inference transformers are excluded from the scope of this CL.
Change-Id: I691c4343def913388a1277227b760fd7e1aa194c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125666
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
In the VM-specific async transformation, an index is used to generate
fresh temporary names for values that are live across an await.
Before it was always 0 when translating a statement because there are
no live values on entry or exit to a statement.
When translating statements nested inside block expressions there can
be live values, so the index should not be reset.
Closes https://github.com/dart-lang/sdk/issues/36466
Change-Id: I6103d75c25f312ab1538a7c0f8fee0fea9f01b27
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98664
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This flag was always true so we can remove it and specialize the
remaining code that used it. The only code that used it was in the
Dart VM's async transformation.
Specializing that code led to some unused fields in the async helper
class which were removed. This triggered me to look at core types
which seems to have a lot of unused stuff.
Change-Id: I7da800ca17ac05478149f4c90337a38d2c2b1459
Reviewed-on: https://dart-review.googlesource.com/c/87960
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@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 transformation worked as if there was never an await "to the
right" of the body of a let expression (i.e., an expression evaluated
after the let expression's body but before the value of the let
expression's body is used). This is obviously not right.
Fixes https://github.com/dart-lang/sdk/issues/33206
Change-Id: Idc175dc8c65f3d520de8b65f2285164d361ff38e
Reviewed-on: https://dart-review.googlesource.com/56492
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Slightly alter async/await transformation in such a way that
:await_jump_var/:await_ctx_var are set before _awaitHelper(...) is invoked -
just like in the AST transformer used by the legacy pipeline. This guarantees
that recursive invocations will continue from the right "jump" point (instead of
continuing from the current jump point).
Fixes https://github.com/dart-lang/sdk/issues/32098
Change-Id: I8899669ceefe3f2edba6531897834b2c275efada
Reviewed-on: https://dart-review.googlesource.com/40520
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Original CL: https://codereview.chromium.org/2692803006/
Original commit message:
Tracking the awaiter return call stack:
- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.
Detecting uncaught exceptions in async functions:
- [x] Code object keeps a map from :await_jump_var to token position
- [x] Exception Handlers keep track if they are generated (as part of compilation) or directly from user code
- [x] Debugger maps :await_jump_var to a specific try index
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2725623003 .
Updates to kernel that sets more offsets (and introduces end offests
and 'debuggability') - but doesn't necessarily persist them,
i.e. the format doesn't change and no C++ changes are neccessary yet.
This is step #1 in introducing these things, next step(s) will be
persisting the new stuff and using it on the C++ side.
R=asgerf@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2610133002 .
This is the result of:
- taking the diff of the branch closure_conversion to master in the kernel
repository
- updating the file paths
- applying the diff to the Dart SDK
- fixing conflicts between the changes to pkg/kernel in the Dart SDK and the master branch in the kernel repository
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2561723003 .
If the body of a let expression contains an await, the translation could
hoist statements that contain references to the let-bound variable out
of its scope.
Instead split by cases on whether the body contains an await. If so, we
hoist let-bound variables to the statement level. If not, we produce a
let expression.
BUG=
R=asgerf@google.com
Review URL: https://codereview.chromium.org/2480743002 .
BlockExpression allowed statements to appear in an expression context.
It is unsafe for its original use case, allowing 'yield' to appear as an
expression, because the VM's yield implementation does not work when
there are live expression intermediate values.
Eliminate it by changing the async ExpressionLifter to return a
transformed expression and emit statements into a given list as a side
effect. This requires implementing the transformation for all
statements to account for how they may contain a nested expression.
BUG=
R=asgerf@google.com
Review URL: https://codereview.chromium.org/2460373002 .
Block expressions are expressions and so can be arbitrarily nested.
They can contain statements, including yield statements. The VM's
implementation of yield assumes that it can only occur when there are no
live intermediate values. It is not generally safe to allow
yield-containing block expressions to appear as arbitrary
subexpressions.
As a first step toward eliminating block expressions, this change
flattens the ones produced by the async transformation so that they can
only occur as the children of statements.
BUG=
R=asgerf@google.com
Review URL: https://chromereviews.googleplex.com/517457014 .
The interface target can now be stored on PropertyGet, PropertySet, and
MethodInvocation If set, we know the concrete target overrides or
implements that member.
All expressions have a method getStaticType for computing its type,
which relies on interface targets for the expressions that have one.
Expressions whose type is a least upper bound have the type stored
explicitly, so the definition of least upper bounds is contained only
in the frontend.
This is a work in progress towards strong mode support, it is still
not complete.
Still missing in the frontend:
- checks from implicit downcasts
- parameter checks from covariant override or covariant generics
Implemented but not part of this CL:
- subtype tests
- IR type checker (for debugging)
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/496717014 .
Transformer lifts try/catch auxiliary variables that need to survive across
yield points into the context.
Drive by fix: we were calling asyncThenWrapper to create an :async_op_error
callback by mistake.
R=kustermann@google.com
BUG=
Review URL: https://chromereviews.googleplex.com/466247013 .
- Rewrite all expressions in functions, not only expression-statements.
- Inject :await_ctx_var and :await_jump_var into the wrapper.
- Don't use transformed expression directly as part of completer.complete call.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/468717014 .
This transformer is responsible for lifting subexpression into temporary variables preserved across yield points.
To maintain AST validity I introduced an expression that can contain a block of statements inside called BlockExpression.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/458577014 .