These arise when the constant evaluator partially evaluates collections
containing spreads or control-flow constructs with unevaluated
subexpressions. They are removed by the final constant evaluation.
Change-Id: Icdd155c4805cbcefe6aa4b45c2f85ec258e7bd36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95760
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
- ForStatement and ForEachStatement will be replaced by ForStatement2.
- MapLiteral and SetLiteral will be replaced by SetOrMapLiteral.
To ease the transition, the old classes are subtypes of the new
classes, so even though the analyzer still creates instances of the
old classes, clients should be able to start referring to the new
classes in their code. The analyzer will stop creating instances of
MapLiteral and SetLiteral when the experimental flags for the "UI as
code" feature are turned on, and will stop creating instances of all 4
classes when we bump the major version number (which should happen
sometime in March).
For visitors, we've updated the base classes with the following default methods:
visitForStatement(node) => visitForStatement2(node);
visitForEachStatement(node) => visitForStatement2(node);
visitMapLiteral(node) => visitSetOrMapLiteral(node);
visitSetLiteral(node) => visitSetOrMapLiteral(node);
So clients should be able to start revising their visitors to override
the new visit methods rather than the old ones, and the visit methods
in the base classes will automatically forward to the new visit
methods.
Change-Id: Ifde3a2aa3c8c49ce4e65dfaabf086db4dabb73f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a reland of c2b466b09f
Original change's description:
> [CFE] Move constant evaluation number semantics handling to front end.
>
> JavaScript number semantics is currently implemented as the simplistic
> version previously present in DDC. This is a starting point for fully
> detailed JS number semantics.
>
> Change-Id: Id728b3dacec892a5cbf7ece0d9faea51427f5f9b
> Reviewed-on: https://dart-review.googlesource.com/c/94746
> Commit-Queue: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: I1a488ef41bda819d34cb45cd481fd8fd88bfb01e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95460
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This reverts commit c2b466b09f.
Reason for revert: Broke precompiled, DDC and others.
Original change's description:
> [CFE] Move constant evaluation number semantics handling to front end.
>
> JavaScript number semantics is currently implemented as the simplistic
> version previously present in DDC. This is a starting point for fully
> detailed JS number semantics.
>
> Change-Id: Id728b3dacec892a5cbf7ece0d9faea51427f5f9b
> Reviewed-on: https://dart-review.googlesource.com/c/94746
> Commit-Queue: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
TBR=sigmund@google.com,askesc@google.com
Change-Id: I732c75b72df0e0f084ad2784349bee346ae5b7ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/95027
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
JavaScript number semantics is currently implemented as the simplistic
version previously present in DDC. This is a starting point for fully
detailed JS number semantics.
Change-Id: Id728b3dacec892a5cbf7ece0d9faea51427f5f9b
Reviewed-on: https://dart-review.googlesource.com/c/94746
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Did a couple of sweeps to discover which parts of the code will be "safe" to remove when we commit to the change (but this is incomplete).
Note: these changes don't contain some backend const checks.
experimental flag: constant-update-2018
Change-Id: Ibe1e0bc530db21dac1d678f02610cc0070340776
Reviewed-on: https://dart-review.googlesource.com/c/93720
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Creates a single code path for the each of the "for loops" regardless if you are
running with one of the experiment flags to prevent regressions in existing
behavior.
The helpers will also be used in by implementation of control flow collections.
Issue: #36005
Change-Id: Ieb62dd76488386db2214b2b6d935fcfd6e7c56b9
Reviewed-on: https://dart-review.googlesource.com/c/93930
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Refactor to use a single code path for set and map literals regardless of running in an experiment mode.
Create helper method that will contain logic to handle the new control flow collections nodes.
Issue: #36005
Change-Id: I9b466bf7f987a00d3d630d7551bdc5f0b7c8a547
Reviewed-on: https://dart-review.googlesource.com/c/94041
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
When two non-generic class had supertypes with mutually recursive type
arguments, the resulting module failed at startup. The compiler detected
the recursion and attempted to defer the supertype type argument
evaluation, but did not defer it long enough. The fix is to move these
deferrals after all classes are declared.
Longer term, a better fix will be #31003 which removes the need to
evaluate supertype type arguments during module initialization.
Change-Id: Ic8c5819521b3fedfcc207e932f11ae11cb03222d
Reviewed-on: https://dart-review.googlesource.com/c/93924
Commit-Queue: Mark Zhou <markzipan@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Flutter uses continue labels (see
https://github.com/dart-lang/sdk/issues/29352), but only to the next
switch case - i.e., the fall through case.
The kernel backend already elides the continue here. This does the
same for the analyzer backend. This gets one co19 test passing on ddc
(was already passing on ddk).
Change-Id: Ifc085415e3d1735c1a534c0683a4c89289820ba0
Reviewed-on: https://dart-review.googlesource.com/c/93462
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
The old way is very ineffecient (many small writes to the file system).
Initial build time for (redacted?) goes from ~40 seconds to ~19 seconds.
Change-Id: Id098f51f43627c5b0768ab9686caab26ba946caa
Reviewed-on: https://dart-review.googlesource.com/c/93411
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This option was useful early in development of DDC's Kernel backend, but
it shouldn't be turned on for users (we may want to remove it entirely).
Change-Id: Ie89115f6d3b9884762968e8e40bffa67799af988
Reviewed-on: https://dart-review.googlesource.com/c/93463
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Make the constant evaluator take an explicit error reporter so we have
to opt in to using the "simple" one that reports errors in an ad hoc
way. This is the start of a change to use Fasta-controlled error
messages throughout and eventually get rid of the simple error
handler, and to continue constant evaluation after the first constant
error.
Change-Id: If6b1801edab6063754b642cf4a603abf9d63103a
Reviewed-on: https://dart-review.googlesource.com/c/89501
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Auto-Submit: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Add Kernel syntactic support for constants constructed by
bool.fromEnvironment, int.fromEnvironment, and String.fromEnvironment.
These values are not necessarily available at compile time. Because
constants can depend on these values, there is also an unevaluated constant
that represents an expression depending on environment values.
This syntax is not yet produced by the Fasta compiler.
Change-Id: Ie96ea7f60a7efcd35ac802b320a00f398d41232e
Reviewed-on: https://dart-review.googlesource.com/c/88827
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Validating the class hierarchy requires subtype tests. Previously,
Fasta has worked around this by computing the hierarchy twice, as
well as visiting the hierarchy several times. In order to improve
performance of modular compilation, we're working on changing this.
To enable creating a TypeEnvironment without a hierarchy, we're
removing the field from the API.
Change-Id: If1aa10598012e53455b92a63ebae12dbae316fc7
Reviewed-on: https://dart-review.googlesource.com/c/88822
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Kernel and Analyzer have slightly different rules for creating implicit
constructors, which DDC's kernel backend did not account for. This
resulted in a mismatch between which super constructor calls it thought
were necessary, vs which constructors were generated.
Both DDC backends are now less sensitive to the representations, and
the kernel backend checks for field initializers in mixin declarations,
rather than relying on the (nonexistent) implicit constructor node.
Change-Id: I01a6ae11ecf78193d7db227ba0b7adeb27d514d5
Reviewed-on: https://dart-review.googlesource.com/c/88432
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Mark Zhou