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>
... and no longer generate handleLiteralSet or handleLiteralMap.
In addition, a new hasSetEntry parameter has been added to the
handleLiteralSetOrMap event generated by the parser to support
existing behavior. Once all listeners have implemented
unified collections and that feature is enabled by default,
the hasSetEntry parameter can be removed.
This is the third of several CLs updating the parser and its listeners
to conform to the unified collection spec:
https://github.com/dart-lang/language/pull/200
Change-Id: Ia305eab1f720658f357ac4102b0b0c8128d16997
Reviewed-on: https://dart-review.googlesource.com/c/93963
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Use the constants in pkg/front_end/lib/src/scanner/token.dart. This
ensures that if the precedence numbers ever change (e.g. because we
need to insert a new expression type into the precedence table), it
won't cause any breakages.
Change-Id: Ie90122435c65dd51fe9be96afe0a8890cc245b55
Reviewed-on: https://dart-review.googlesource.com/c/93931
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Several places in the analyzer and the analysis server were using
hardcoded integers to represent precedence, rather than referring to
constants defined in the front_end. This led to some subtle
off-by-one errors, because the old analyzer convention (prior to
integration with the front_end parser) used 0 to represent the lowest
precedence of an expression (and -1000 to represent the precedence of
non-expressions), whereas the front_end convention is for 1 to
represent the lowest precedence of an expression. As far as I can
tell there was no user visible impact, but it made it very difficult
to reason about operator precedence.
This CL updates the analyzer and the analysis server so that they
don't hardcode any precedence values; instead they refer to named
constants in the front end.
In a follow-up CL I'll reduce some hardcoded precedence numbers in the
front end itself.
Change-Id: Id3869afeb83042cc7d6630a0a4a0533a07058736
Reviewed-on: https://dart-review.googlesource.com/c/93964
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
For initializeFromComponent to work correctly the platform has to be
provided (as the other libraries provided are linked to some platform,
and loading another one is thus no good).
This CL changes it so we don't load another one, and checks that the
component we're trying to initialize from actually contains dart:core.
Change-Id: I88d30436c101c589b0555ff70ae21297ed665d7b
Reviewed-on: https://dart-review.googlesource.com/c/93435
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Boolean operations are translated into explicit kernel nodes, so they
will not appear as method calls during constant evaluation.
Change-Id: I30a0abfe37989228d5cff4b3fa3ff5407404e747
Reviewed-on: https://dart-review.googlesource.com/c/93980
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
In the incremental compiler we used to invalidate the entry point for
every invocation. This is no longer necessary, and we should stop.
Change-Id: I563bdea53c8ec85657fbb8be96d15ba3a7b57e3c
Reviewed-on: https://dart-review.googlesource.com/c/91824
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@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>
- We get simplification from running after removal of HTypeKnown.
- Added chaining when the chain is used several times.
The best size improvement on apps I tested is 0.25% (minified).
Change-Id: If2c50dea5899efb402782ea92c76c4fe628e1c1d
Reviewed-on: https://dart-review.googlesource.com/c/93800
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
All of DDC's supported platforms have Promises, so we can use them
instead of MutationObservers (web) and timers (node.js).
See issue #20055 (same issue, but for dart2js).
Change-Id: Id635a4a9fa104a2ab19dd20824d209f682f831f9
Reviewed-on: https://dart-review.googlesource.com/c/91765
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
We continue to accept `--dump-info`, but now also accept `--dump-info=binary` so
we can use the new cheaper encoding.
Change-Id: I971cb9a3634ae1a333cfee14b2927c0e25000a01
Reviewed-on: https://dart-review.googlesource.com/c/93823
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The first code is HintCode.INFERENCE_FAILURE_ON_UNINITIALIZED_VARIABLE:
```dart
var a; // Hint: The type of v1 cannot be inferred without a type or initializer
dynamic b; // OK
var c = 7; // OK
```
This is currently only enabled via an analysis options file:
```yaml
analyzer:
language:
strict-inference: true
```
I could add it as a flag as well, but to start using this internally at Google,
we only need support in the analysis options file.
Bug: https://github.com/dart-lang/sdk/issues/33749
Change-Id: Id2a6afa7c3d724b44c20576c7f48869abcf4255c
Reviewed-on: https://dart-review.googlesource.com/c/93700
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We already can store List<double>, but not `double` itself.
The LinkedConstantValue data structure I'm working on will have a
field of type `double`, so I need to support in in the generator.
R=paulberry@google.com
Change-Id: Ic5aa3a9a7266afabe6c64214fd68097fbebda4e8
Reviewed-on: https://dart-review.googlesource.com/c/93820
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Mayank Patke