During constant evaluation, unused arguments to a const constructor are
thrown away after evaluation, since their values do not affect the
resulting instance constant. If such an unused argument ends up
unevaluated, any errors that would arise in the final evaluation are
not reported.
This CL adds space in the Kernel AST for saving these unevaluated
expressions so they can be checked during final constant evaluation.
Even though this is an incompatible change, no update is needed to the
VM code (except for the version bump), since the VM does not support
InstanceCreation nodes in the first place.
Change-Id: I4752562c1164efbba79eb018c15b07ed8354ce5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105761
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
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 change replaces kernel AST declarations of fields and functions
with bytecode declarations.
Size of dilp files is reduced by 11-12%.
Startup latency:
Time to the first full frame: 1.945s -> 1.687s
FinalizeClass: 554ms -> 277ms
FinishClassLoading: 296ms -> 156ms
There are following regressions in bytecode mode, which will be fixed
in future:
* dart:mirrors are not supported yet (implementation of mirrors relies
on reading kernel AST in certain cases).
As the result, lib_2/mirrors/* tests fail.
* native extensions are not supported yet (annotations on libraries
and classes in AST are cleaned up as they could reference members
which are now removed from AST).
As the result, standalone_2/entrypoints_verification_test test fails.
* language_2/spread_collections/const_error_test/* tests fail
due to https://github.com/dart-lang/sdk/issues/36286.
Change-Id: I5130f401fd7b84038b136136e7ccc1a6e51b6cea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97561
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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>
Having a block as body instead of a list of expressions simplifies
code handling block expressions. Since it is always a block, it can
be left untagged in the serialized representation so the serialized
representation is not changed with this change.
Change-Id: I3c34f663041ff8cb4a530c2d6a148343e59c68fe
Reviewed-on: https://dart-review.googlesource.com/c/94223
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Auto-Submit: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Prior to this change, old problems (warnings, errors, etc) would not be
re-issued for files not actually recompiled when recompiling.
As an example, not making any change and recompiling it would seem like
everything was good.
With this change, all problems should be issued again.
Change-Id: Ia410edba27438d8a2f1842d9f4d81d0592571101
Reviewed-on: https://dart-review.googlesource.com/c/91747
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This achieves consistency with similar getters in the API.
This is technically a breaking change, since it changes a published
part of the Kernel API. Since the constants API is relatively new and
so far only used internally in the AOT compiler, the change is
expected to be unproblematic.
Closes https://github.com/dart-lang/sdk/issues/35696
Change-Id: I3ca30922580d226ccbdb6f77496983c21ef2102b
Reviewed-on: https://dart-review.googlesource.com/c/90220
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Fasta allows some non-const static field access in constant contexts
which leads to the constant evaluator trying to evaluate them. Signal
an error instead of crashing. This will double-report errors for the
cases that Fasta already catches, and we should fix that
double-reporting.
Fix unbounded recursion in printing unevaluated constants (writeNode
called visitUnevaluatedConstant which called defaultConstant which
called writeNode...).
Fix a spurious trailing comma in printing of instance constants.
Change-Id: Idff3169a3a56432ad67c27ff9c267ef355c4c1dc
Reviewed-on: https://dart-review.googlesource.com/c/89514
Commit-Queue: Kevin Millikin <kmillikin@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>
This is a major revamp of bytecode metadata format. Now bytecode has
its own serialization mechanisms.
This CL adds 'bytecode component' metadata, which contains bytecode
object table and string table. All references from bytecode (constant
pools) to libraries, classes, members, types and strings now have a new
format. References to frequently used objects are represented as indices
in object table, while rarely used objects are written inline.
This allows VM to cache frequently used objects while reading bytecode.
Representation of strings is aligned with VM - string characters are
stored in separate pools of one-byte and two-byte strings. This allows
VM to avoid UTF-8 decoding and extra copying.
Closure declarations are now explicit. Type parameters no longer require
enslosing scopes when reading/writing them.
Benchmarks:
GenKernelKernelReadAllBytecode (Intel Core i5) +29.84%
GenKernelKernelReadAllBytecode (Intel Xeon) +28.74%
Change-Id: I4b80009733a8f8c038264af74f97c4e094b9e311
Reviewed-on: https://dart-review.googlesource.com/c/85469
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Before this CL we could get a dill file out of compiling
tests/language_2/import_nonexisting_dart_uri_test.dart
but we couldn't load it back in again.
Change-Id: I05b6b8d6368c7ed03dbb798535ea03e0493df780
Reviewed-on: https://dart-review.googlesource.com/c/79220
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Translate assert statements in async functions. The translation of
the condition subexpression can produce a sequence of statements that
have been hoisted out of it. These need to be guarded so they are
executed only when asserts are enabled.
For this purpose, we introduce an AssertBlock. The semantics of the
assert block:
assert { s0; ...; sn; }
is the same as:
if (assertsEnabled) { s0; ...; sn; }
where assertsEnabled is a more primitive nullary expression that is
true iff. assertions are enabled. We chose not to encode this using a
construct like assertsEnabled because (1) we would have to support it
appearing as an arbitrary expression which we don't currently need
and (2) it requires deeper pattern matching to detect and skip the
guarded code when desired.
The translation is more complicated because if there is a message
subexpression in an assert, it is conditionally evaluated only if the
assert's condition is false.
Fixes https://github.com/dart-lang/sdk/issues/28498
Change-Id: I0912a57104ede3160533e49f65b6fb79b76f1500
Reviewed-on: https://dart-review.googlesource.com/46442
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Before: Kernel static errors were represented by throwing a distinguished
error or else by calling a distinguished library const constructor.
Now: Kernel static errors are represented by InvalidExpression. To support
error reporting, InvalidExpression has an optional message and a file
offset. A back end can choose to signal these errors at any time; for
example, when deserializing the binary, or when compiling the procedure
containing the static error, or when the erroneous expression is evaluated
at run time.
InvalidStatement is removed because it can be encoded as ExpressionStatement
of InvalidExpression.
Future work:
* supporting static errors where an expression cannot appear in the AST
* allowing InvalidExpression to contain an Expression for error recovery
* adding a top-level list of static errors and warnings to the binary
Bug: https://github.com/dart-lang/sdk/issues/29840
Change-Id: Ifdfe9a76cee6cefed28061bf245be70531d2f413
Reviewed-on: https://dart-review.googlesource.com/31320
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Also, use more descriptive "redirecting_factory" instead of "factory"
in the textual representation of RedirectingFactoryConstructors.
Bug:
Change-Id: Ib01e21107b86e55a10721dde551e802ef3230c80
Reviewed-on: https://dart-review.googlesource.com/24400
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Assert initializers in Dart may be compiled directly to this form of initializer,
rather than through local initializers as is done now.
Bug:
Change-Id: Ia149ea3d1df5d1dc18be5636801604ffaf7ca7d8
Reviewed-on: https://dart-review.googlesource.com/14760
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
New type of AST nodes RedirectingFactoryConstructor is added to Kernel.
The goal is to keep the information about redirecting factory
constructors in the class for the linking phase.
Change-Id: I7477c617fa7fd4935ceb23098ec7c056d1f286ca
Reviewed-on: https://dart-review.googlesource.com/14740
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Currently we produce 'partial dills' for the VM when compiling through
kernel, i.e. we only include the user-code and whatever canonical names
the user refers to. That's perfectly fine for the VM as it always loads
the platform.dill file too.
We cannot currently print it though.
(Technically we should be able to concatenate it with platform.dill and
print that).
This CL allows us to print these partial dills without concatenating
anything first.
Bug:
Change-Id: I7d5f12332e16623d02531ad46e2dc103222f59e9
Reviewed-on: https://dart-review.googlesource.com/19002
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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>