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>
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>
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>
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>
It's simply an alias for `dartdevc --kernel`, and now that build_runner
is switching to that, there's no reason to keep it around anymore.
Change-Id: I43d30a582314a236bcfa2e3a0b50bb48ddac79f8
Reviewed-on: https://dart-review.googlesource.com/c/88281
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This improves the default JS display of exceptions/errors from DDC
compiled code. This gives a better "default" experience if JS code
(or a JS engine, like browers/Node.js) ends up catching Dart exceptions.
Change-Id: Ib2dda6eee710f8b536d5ed7223e0101310a137b3
Reviewed-on: https://dart-review.googlesource.com/c/84446
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This uncovered a bug in dev_compiler that was showing up at compile
time--it was defaulting the enableAsserts flag to null, causing a null
pointer exception during kernel constant evaluation.
Change-Id: I2c75ffdc494f8d768aa98d67ef8257a20e74b9cd
Reviewed-on: https://dart-review.googlesource.com/c/86982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The front_end code was sorting the summary URI list, which caused DDC to
find the wrong JS module import for a given summary (Components do not
store the URI they were loaded from, so DDC has to track that.)
Change-Id: Ief29c790d7303c8f290c6c669af2e1b34bc5bffb
Reviewed-on: https://dart-review.googlesource.com/c/84581
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
This is similar to the analyzer backend's optimization for fields, but
it also supports private methods and accessors.
Also fixes#34769, checks were missing for explicit covariant fields
and those are now generated (this is for fields of the form
`covariant SomeType fieldName`--implicitly covariant fields in generic
classes were already checked correctly).
Change-Id: I5ce3ed7944bdc5a9799c731c5f95e199b461b079
Reviewed-on: https://dart-review.googlesource.com/c/79432
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
Original commit message:
[dartdevc] fix#35013, move DDC off Analyzer task model
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I8d1855c27f9976cad6fd9ccb567b75a613e6048c
Reviewed-on: https://dart-review.googlesource.com/c/83060
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I7bf1ce1eca73fd036002e498de5924c488b534dc
Reviewed-on: https://dart-review.googlesource.com/c/82469
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Analyzer does not put mixin declarations in the `.types` getter, which
broke DDC's assumption that it contained all of the class/interface
types in the compilation unit. Kernel backend was not affected.
Change-Id: I219d814766fb97ef81920d0150cb1dfbbc6087f5
Reviewed-on: https://dart-review.googlesource.com/c/82022
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
Mark Zhou