The test language_2/built_in_identifier_prefix_test stated 'it is not
illegal to use a built-in identifier as a library prefix', which has
been untrue for quite a while, and then proceeded to check a number of
cases where said situation was used in practice. All of that is now
obsolete, so that test was split into several tests, each of which was
adjusted to test something which is relevant today.
The new tests include checks for the use of "known" identifiers (such
as `of`, `show`, `on` and a few more) which are mentioned explicitly
in the grammar, but which are neither built-in identifiers nor
reserved words.
The new tests gave rise to a number of status entries, including 25
crashes (so it is not just "expect `MissingCompileTimeError` here
because it's not strong mode").
Note that `Function` is considered to be a built-in identifier.
This makes no difference for the grammar, but it means that there
are no cases where `Function` is used as a library prefix.
If we insist that `Function` cannot be a built-in identifier then
we just need to add a few more grammar rules to all such things as
`import .. as Function;`, but I considered it less confusing to
include `Function` among the built-in identifiers and avoid adding
support for this.
Note that we haven't said anywhere that `Function` is a built-in
identifier, so we would need to adjust an informal/*.md file to say
that, to finish this off.
Change-Id: Ifa5bbd95022498480b7ee2e94605f81cd11d9696
Reviewed-on: https://dart-review.googlesource.com/21080
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The spec was not self-consistent with respect to the usage of various forms
of 'run time' and 'compile time', even when using them as formally defined
terms (e.g., compile-time error).
Consistently follow the conventions: that 'run-time' and 'compile-time' are
adjectives and not nouns; that 'run time' and 'compile time' are noun
phrases containing an adjective and not adjectives themselves; and that
'runtime' and 'compiletime' are nonsense or at least jargon and are avoided.
Fixes https://github.com/dart-lang/sdk/issues/25883
Bug:
Change-Id: I0a9eb524bb43ed6c3a74e6ef038184bcbe979966
Reviewed-on: https://dart-review.googlesource.com/21345
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Kevin Millikin <kmillikin@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>
FunctionExpression should have a low precedence to ensure that it is
properly parenthesized.
Fixes https://github.com/dart-lang/sdk/issues/31380
Bug:
Change-Id: I2ca2bb728973c5b374411dc07fdadc4dda8c707b
Reviewed-on: https://dart-review.googlesource.com/21343
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Kernel represents break and continue in Dart uniformly as break. When
compiling to JavaScript we would like to use continue where possible and
avoid labeling statements that do not need to be labeled.
The basic idea is: at compile time maintain a list of Kernel targets
(LabeledStatements) that can be compiled to JS break without a label at a
given point in the program, and a list of Kernel targets that can be
compiled to JS continue without a label, and a map from Kernel targets to
the 'effective' target that will be labeled if necessary when compiled to
JS, and a mapping from effective targets to their label names if they must
be labeled.
Change-Id: Ie660cf3dd68399ebff128116fe38c250cb6b7f35
Reviewed-on: https://dart-review.googlesource.com/21120
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This reverts commit 5f15867a47.
The recent renaming of constants had caused a lot of pain with this CL.
TBR=lrn@google.com
Bug:
Change-Id: I67a78fa09e15e95ea44fe18d9847fcfd9c61e043
Reviewed-on: https://dart-review.googlesource.com/21382
Reviewed-by: Stephen Adams <sra@google.com>
This lets us benchmark separately:
- IKG implementations (the default based on kernel-driver or the minimal implementation)
- strong and non-strong mode
This also adds commands to try_benchmarks that highlight how these options will be used.
Change-Id: I5ce2c4563b7e79c33d78df7fd87be76f5d47e3f4
Reviewed-on: https://dart-review.googlesource.com/21320
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This reverts commit d2579b6d3c.
Revert until I can figure out why co19/Language/Expressions/Identifier_Reference/syntax_t06 is failing.
Original change's description:
> Add fasta parser invalid method name recovery
>
> Fix https://github.com/dart-lang/sdk/issues/31183
>
> Change-Id: I1c3d0f5f665e8b1ab02901b470da0bf70871e5e1
> Reviewed-on: https://dart-review.googlesource.com/21261
> Commit-Queue: Dan Rubel <danrubel@google.com>
> Reviewed-by: Paul Berry <paulberry@google.com>
TBR=paulberry@google.com,danrubel@google.com
Change-Id: Ia1c1cc26b819f309bb6c2b603318904d0b786b56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/21360
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
- specify $strong in _kernel.status
- move status entries to the file they belong to (dartk/dartkp in
_kernel.status, none & app_jit in vm.status, dart_precompiled in
_precompiled.status)
Later: merge sections together (many expressions are equivalent or have
conditions that might not be relevant, like $strong && $checked).
Change-Id: Ia16817c2145f002ca210a218759c36c53bbe9ba9
Reviewed-on: https://dart-review.googlesource.com/21220
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reland 1d6c1020c9 with the fix for ASAN
bots.
* Test standalone_2/file_error_test is updated for Dart 2.0 fixed-size
integers.
* This update revealed that certain dart:io native methods do not handle
out-of-memory properly when I/O buffers are allocated.
This CL fixes this bug.
* Updated test point is extracted to a separate test
standalone_2/file_error2_test as it needs custom ASAN options.
Change-Id: Ifb1fa59828f36dc03d45c18a41d45da6b989d70a
Reviewed-on: https://dart-review.googlesource.com/20908
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Adding an explicit type to the local function `test` makes the call
`test([])` get type inferred as `test(<int>[])`. This ensures that it
is safe for `test` to pass the list to `Uint16List.setAll`.
Change-Id: Ib6c982db6c8210a76a69fc36c4eb400578f1b3ee
Reviewed-on: https://dart-review.googlesource.com/20940
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* consistently quote $BIN_DIR;
* remove convoluted logic that tries to guess DART_CONFIGURATION;
* fix issue with how $PACKAGES were passed to fasta in precompiler2.
Bug:
Change-Id: I3073330fe3397100406d9ad6dcab2a86f9e1825f
Reviewed-on: https://dart-review.googlesource.com/21082
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Previously we used FutureOr<T> by mistake.
This causes the code construct a much more meaningful type Future<T> not
Fixes https://github.com/dart-lang/sdk/issues/31324
Bug:
Change-Id: I38d4e4101b81bb33d53a87385ebcf60302f6764f
Reviewed-on: https://dart-review.googlesource.com/21081
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Kernel try and finally statements do not necessarily compile to JS
blocks, but the JS AST requires blocks for try and finally. Ensure
that these statements are blocks.
Bug:
Change-Id: I7abe6ae55650dc726cc89d86d12757d21a783064
Reviewed-on: https://dart-review.googlesource.com/20721
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
In many cases function bodies were a block containing a single nested
block. Flatten these cases.
Change the test for whether a lexically-scoped local variable clashes
with a parameter to work on the generated code, not the source.
Change-Id: I74d37fe686e481e3300bb9d37b30857e8e375cb5
Reviewed-on: https://dart-review.googlesource.com/20661
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
