I have not tried them on Windows, hopefully it will help.
R=brianwilkerson@google.com
Change-Id: I1446a834f95398979337db4b887e3d76c3ec164f
Reviewed-on: https://dart-review.googlesource.com/48880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is a preparatory step before adding a flag that signals
that the error code represents an unresolved identifier situation.
R=brianwilkerson@google.com
Change-Id: Ic3b30e2efae7ee0c12a40d1cc2bd48c14185d926
Reviewed-on: https://dart-review.googlesource.com/48763
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL changes the way linker type inference works. Instead of
walking the operations in an UnlinkedExpr in order and inferring types
directly, it first builds an AST for the expression using ExprBuilder,
then uses ResolverVisitor to resolve the AST and perform type
inference.
This helps ensure that summary type inference and ordinary AST-based
type inference produce the same result, since they now use the same
core algorithm. In particular, this means that summary type inference
now does downwards inference properly.
Since the ResolverVisitor makes greater use of the element model than
the rest of the linker, this required implementing additional methods
in the linker's element model.
This CL includes some minor fixes to ExprBuilder that were uncovered
during testing. It also contains some minor changes to
ResolverVisitor to make it work during linking.
Fixes#32525.
Fixes#32394.
Change-Id: I5ec9b2bf5565ad30b8cc856475334323dc118da8
Reviewed-on: https://dart-review.googlesource.com/48741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL refactors the bodies of the following methods so that they can
be re-used by the summary linker:
- CompilationUnitElementImpl.getType
- LibraryElementImpl.createLoadLibraryFunction
- LibraryElementImpl.getImportsWithPrefix
- LibraryElementImpl.getType
Change-Id: I9b398d87323eb9ec6deb9a9a76bd6e9a1aa6bb76
Reviewed-on: https://dart-review.googlesource.com/48740
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This disables most runtime features of dart:isolate, similar to dart:io.
For now, this supports `new ReceivePort()` and `ReceivePort.close` as
those are used by async tests to keep the Dart VM alive. Those are
no-ops in DDC. Also removes most of dart:_isolate_helper, except for
the JS API that's used to bootstrap DDC `main()`.
Change-Id: I84eab6cd39d05a70a6afe982e952076ddaaa8c0f
Reviewed-on: https://dart-review.googlesource.com/45754
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This CL makes the following improvements:
- Makes ParameterElementImpl._unlinkedParam public so that it can be
used by the ExprBuilder.
- Adds logic to ExprBuilder to create elements for closure parameters
and to resolve references to those elements.
- Adds support for async closures.
- Adds support for nested closures.
Change-Id: I4b2c2271dac44bb54eb12049de7143b14adef84a
Reviewed-on: https://dart-review.googlesource.com/48680
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
See #32525.
This CL makes the following changes:
- Extracts the logic from AbstractClassElementImpl.getSetter to a
static method so it can be re-used by the summary linker.
- Modifies ParameterElementImpl._resynthesizeTypeAndParameters so that
it avoids unnecessary calls to resolveLinkedType. This is crucial
because resolveLinkedType is not available when linking.
- Makes it possible to suppress reporting of const evaluation errors
when doing resolution. This is necessary because in order to report
these errors we must do constant evaluation, which is not possible
during summary linking.
- Modifies ResolverVisitor._hasSerializedConstantInitializer to avoid
unnecessary calls to LibraryElementImpl.hasResolutionCapability.
This is crucial because the linker contains an implementation of
LibraryElementImpl that's incompatible with
LibraryElementImpl.hasResolutionCapability.
Change-Id: Iec91bd8d6a68193e091c2438bafcd7cb15488d89
Reviewed-on: https://dart-review.googlesource.com/48681
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL is the first in a multi-part effort to remove the `previous`
field from the Token class. This first step introduces a new findPrevious
utility method that finds the the token before a given token in a token stream,
and then replaces usages of token.previous with calls to this
new findPrevious utility.
Change-Id: I57de4e542adb5950f1bddd951ff555dd98b19b3b
Reviewed-on: https://dart-review.googlesource.com/48461
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* preserve-comments: unused, only used for source-mirrors & dartdoc long long ago
* preserve-uris: ignored, mirrors-only flag
* allow-native-extensions: error, was only used for analyze-only with the old FE
Change-Id: Ic93c31edf188cdab3aa658c13018a432baf14742
Reviewed-on: https://dart-review.googlesource.com/48457
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* remove serialization options
* remove checks that are only for the old FE (e.g. checks about imply compilation and --analyze-*)
Change-Id: I148025a7158340339bba4205f3b961b3c9902e47
Reviewed-on: https://dart-review.googlesource.com/48453
Reviewed-by: Johnni Winther <johnniwinther@google.com>
One thing that occurred to me is that maybe we don't need precise
resynthesis of some expressions, e.g. `a is T`, because it does not
have dependencies, and has known type. Thoughts?
We already kind of went this way by not serializing arguments of
invocations with type arguments, and cascades.
OTOH, it might be simplier to resynthesize where it is easy.
R=brianwilkerson@google.com, paulberry@google.com
Bug: https://github.com/dart-lang/sdk/issues/32525
Change-Id: I742b1adc6ae22d8743ef127af7d6a33446e53449
Reviewed-on: https://dart-review.googlesource.com/48466
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This CL moves _ConstExprBuilder to its own file, renames it to
ExprBuilder (so that it can be re-used for non-const expressions), and
begins adding support for expression types that can appear in
non-const expressions.
It also introduces an expr_builder_test.dart file to make testing of
ExprBuilder easier.
See #32674.
Change-Id: I5a3d91408c51770ee8f70621032a2f0767eaea55
Reviewed-on: https://dart-review.googlesource.com/48462
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
There is already a Quick Assist to convert StatelessWidget to StatefulWidget,
and duplicating implementation is not very nice.
R=brianwilkerson@google.com, devoncarew@google.com
Change-Id: Iacbe58c9d05359ec96a86affc774c83532f7456f
Reviewed-on: https://dart-review.googlesource.com/48451
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Using immutable options objects was nice, but it came with a tax every time we added or modified
options (often having to edit 5 locations). I'm now using a mutable object and
default values are inline with the field declaration.
Change-Id: I92768f0ff50a4140271dc0ebfa3b615c94a57e4d
Reviewed-on: https://dart-review.googlesource.com/48446
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
