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>
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>
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>
This flag was always true so we can remove it and specialize the
remaining code that used it. The only code that used it was in the
Dart VM's async transformation.
Specializing that code led to some unused fields in the async helper
class which were removed. This triggered me to look at core types
which seems to have a lot of unused stuff.
Change-Id: I7da800ca17ac05478149f4c90337a38d2c2b1459
Reviewed-on: https://dart-review.googlesource.com/c/87960
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Async transformation uses dynamic variables in few places (e.g.
for temporaries and for incomming arguments) - which creates
not strongly typed AST with method invocations having dynamic
receivers and non-null interface targets at the same time.
To maintain strong typedness of the AST we insert unsafeCast
when accessing the temporaries.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: I11e38c128645ebc8acb0c982a80fe4c5c4036673
Reviewed-on: https://dart-review.googlesource.com/75000
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The introduced "constants" transformation can evaluate constant expressions. The
original use-sites of constant expressions are replaced by a new [ConstantExpression]
node, which points to a subclass of a new [Constant] class hierarchy. Constant
[Field]s and [VariableDeclarations]s will be removed, since all use-sites are
re-written.
The [Constant] class hierarchy is, similarly to the [DartType] class hierarchy, not
part of the AST tree (also has no parent pointer). The constants form a
DAG (directed acyclic graph).
There is no canonicalization requirement of the [Constant] objects referenced by the
AST (via [ConstantExpression]). Although it is beneficial to canonicalize them during
construction, since it reduces time spent in operator==/hashCode.
This CL furthermore adds support for a constant table in the binary format. Similarly
to [String]s, we canonicalize the constants before writing the table to the binary.
The constant table entries in the binary are written in a post-order way, to ensure
easy construction on the backend side.
The text format will be augmented with a "constants { ... }" section at the end,
which lists the constants in the same order as in the binary format.
The transformation can be used by those backends who choose to do so. It is not
enabled by default atm. It should therefore not affect analyzer, fasta or other
components.
Change-Id: I57cd9624fedcf537ab6870db76246149647bed21
Reviewed-on: https://dart-review.googlesource.com/14382
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This will allow tests that use batch_util.dart to be run inside
google3, where package layout conventions are more strictly enforced
(files in test/ cannot import files in bin/ or vice versa).
Change-Id: I046b864bc3b1c4e78b984b0047b7567873146c52
Reviewed-on: https://dart-review.googlesource.com/7340
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Summary:
We use a modest set of annotations in ast.dart to describe how the Kernel AST
should be converted into Coq definitions.
We define a Kernel transformation that converts the kernel tree of ast.dart into
a valid Coq file containing the corresponding definitions.
Currently generating the Coq file is not done in the build system because
compiling it requires having Coq installed, and I don't want to introduce a
depedency on Coq into the build system.
Some parts of the AST are not represented because they don't significantly
contribute to the typing semantics:
- asserts
- typedefs
- most literals/basic types (excl. bool, which is needed for "is" tests)
- switch
- for-in
- parts
- yield/await
Test Plan:
Ran the output KernelSyntax.v file through "coqc".
Change-Id: Ic573163a017eaaf3759b741b9eec5ce3ce19225c
Reviewed-on: https://dart-review.googlesource.com/2960
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
This is the result of:
- taking the diff of the branch closure_conversion to master in the kernel
repository
- updating the file paths
- applying the diff to the Dart SDK
- fixing conflicts between the changes to pkg/kernel in the Dart SDK and the master branch in the kernel repository
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2561723003 .
This replaces the old --sanity-check flag from dartk. Some files have
been renamed to avoid the wording "sanity check".
Compared to --sanity-check, the following checks have been added:
- variables are not referenced out of scope
- variables are not redeclared
- class type parameters are not referenced from static context
A unit test has been added to check that the verifier rejects certain
invalid ASTs.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2531873002 .
Sanity checks now run in a single pass rather than two, and
instead of building a set consisting of all members, it uses
a bit from the transformer flags to remember which members are
not orphaned.
As an additional check, it now checks that members are not
declared more than once.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2529973002 .
This file is not strong-mode clean, but since a more recent version
of closure conversion still exists in a branch on the kernel github
repo, there is not much point in fixing this version of it.
BUG=
R=ahe@google.com
Review URL: https://codereview.chromium.org/2526793002 .
The concept of a binary library file no longer exists.
A kernel file can contain any number of libraries, and some of these
libraries can be "external". To reference a class or member from
another build, the class or member must be declared in an external
library.
Members in an external library contain all their type information,
but have no body.
Classes in an external library have their hierarchy information
present, but are not guaranteed to contain all their actual members.
The idea is that references themselves don't really cross module
boundaries, but rather refer to a local definition whose body is
contributed from elsewhere, much like 'external' members in Dart.
A modular backend such as DDC should be able to compile from one of
these kernel files without needing to load auxiliary information from
summaries or other kernel files.
For whole program transformations or backends, a linking step, which
is not yet implemented, must merge classes and members in external
libraries based on their name.
External libraries share the same IR and binary format as ordinary
libraries. Transformations that affect the interface for a member
or class should transform the external libraries alongside with the
internal ones, ideally without needing to treat them any different.
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/516847013 .
Allocate contexts to hold captured variables. Rewrite captured variable
access to context access. Outside of a local function, this is a single
indirection through a named context. Inside a local function it requires
traversing (a statically known number of) parent links.
R=ahe@google.com
Review URL: https://chromereviews.googleplex.com/507717013 .
This makes super calls name-based (no target) and add direct calls with
both receiver and explicit target.
Super call resolution translates the name-based super calls into direct
calls after they have been cloned into the mixin application.
For JS backends, it should suffice to clone mixed-in methods that
contain super calls, but that transformation is not part of this CL.
This also adds a --target option to dartk designating the target to
which the kernel IR should be specialized. The new transformation
is run when --target=vm.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/486537013 .
- Rewrite all expressions in functions, not only expression-statements.
- Inject :await_ctx_var and :await_jump_var into the wrapper.
- Don't use transformed expression directly as part of completer.complete call.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/468717014 .
Aske Simon Christensen