This is used in constant evaluation to represent const constructor
invocations with unevaluated field values or asserts.
Change-Id: I1d2d60a18f967a4dd195b3b5895db9a126c47803
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98561
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This allows dartdevc and the bazel worker to user
the incremental compiler with kernel.
Use --reuse-compiler-result --use-incremental-compiler to run in this mode.
Change-Id: I9189ce5f1a51320d9d96e071f8c95c80fe6fca84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95386
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Also fixes DDC's Kernel backend to emit source maps. There's also
some refactoring to move shared code to the shared_compiler, to unblock
hot reload implementation work and other fixes (such as exporting
private names from the module).
Change-Id: I872e221d9f266198fcc220900146c1c9c5503acb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97553
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Dart interfaces can contain private member names that aren't accessible
in the current library. This is represented in Kernel as a stub that
throws (similar to the stubs used when noSuchMethod is present on a
class, typically used for mocks). DDC's Kernel backend did not
understsand that private members could belong to a different library.
This CL addresses it.
Note, this fix does not fix private names across modules. That is
covered by issue #36252 and will be addressed on top of this fix.
Change-Id: Id77d5de15d8d7ec5e44fc0f1264ced5e786636ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97441
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
It looks like this code was implemented in the wrong place. At some
point reading the code (possibly during Kernel backend port), I noticed
this and left a TODO. This CL implements the solution described in it.
Change-Id: Iff837d471c87ec2fdb8f1a9a4afdb025af1a726f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97262
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This moves the code into a shared location (instead of being copied to
both of the Analyzer/Kernel-based backends), and removes support for
detecting type parameters in constants, which was allowed by strong
mode but is not legal in Dart 2.
Change-Id: Ic8bcf0aa1107bbb7147fd15b648a45e39478cef5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96839
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The constant evaluator now generates all errors as Fasta diagnostic
messages. The ErrorReporter is simplified to just accept a diagnostic
message, or a notification that the constant evaluator encountered an
invalid expression (presumably put there due to an earlier error).
Also, the flow of control between the error reporter and the internal
abort exceptions is reversed, so the error reporter is now called as a
result of an abort exception being caught by the evaluate method.
Reland of https://dart-review.googlesource.com/c/sdk/+/96300
Change-Id: I7d32b6e98962b6ee781a6c96b593b00ee7fd8a89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97225
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
TBR=askesc@google.com
Revert "[CFE] Move constant evaluator to Fasta."
This reverts commit 845b5b2df1.
Revert "[CFE] Always call the constant evaluator by the evaluate method."
This reverts commit 91bc4ec2b9.
Revert "[CFE] Use Fasta diagnostics in the constant evaluator."
This reverts commit c7b572aa29.
Revert "[CFE] Check for null in constant evaluation"
This reverts commit e6d2751e9c.
Revert "Rename import after moving file."
This reverts commit a6e2c5eb4c.
Change-Id: Iadfe087c0110f6f331b82d990213f95d3ef4541b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97223
Reviewed-by: William Hesse <whesse@google.com>
The constant evaluator now generates all errors as Fasta diagnostic
messages. The ErrorReporter is simplified to just accept a diagnostic
message, or a notification that the constant evaluator encountered an
invalid expression (presumably put there due to an earlier error).
Also, the flow of control between the error reporter and the internal
abort exceptions is reversed, so the error reporter is now called as a
result of an abort exception being caught by the evaluate method.
Change-Id: I66f148cc4e202e328f895ae0b770f9b68c9f3c8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96300
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This is in preparation for recognizing Fasta-specific nodes in the
constant evaluator, and for using the Fasta diagnostics framework.
Change-Id: I8535fbb68e622f1814a1d577c348d87e573b6b34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96081
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This is a temporary workaround to copy this file into DDC, based on
jacobr@'s suggestion. I tried to keep changes minimal.
Eventually this transform should be injected when Flutter SDK builds
DDC, rather than including it here. The transform is guarded behind
a flag, so build runner can decide whether to pass it (for now, it
could be hardcoded).
Change-Id: Id9d36456a726e6abb46b904321bc31db136d1c2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97022
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jacob Richman <jacobr@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
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>
Mark Zhou