This reverts commit f81a402aa1.
Reason for revert: golem benchmarks are failing to run
TEST=ci
Original change's description:
> "[SDK/VM] - Rename dart_precompiled_runtime to dartaotruntime, ensures we have a uniform name for the executable between the build directories and the SDK directory"
>
> Fixed golem breakage by temporarily copying dartaotruntime to dart_precompiled_runtime
>
> This reverts commit 75e6a748f7.
>
> TEST=ci
>
> Original change's description:
> > Revert "[SDK/VM] - Rename dart_precompiled_runtime to dartaotruntime, ensures we have a uniform name for the executable between the build directories and the SDK directory"
> >
> > This reverts commit 1b331d05c2.
> >
> > Reason for revert: golem builds are failing
> >
> > Original change's description:
> > > [SDK/VM] - Rename dart_precompiled_runtime to dartaotruntime, ensures we have a uniform name for the executable between the build directories and the SDK directory
> > >
> > > TEST=ci
> > >
>
> Change-Id: Id0f383eabb496c06c0acebc639c8e3b056ba82d0
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393781
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Change-Id: Iec494940412aa31dbefdc5280e35ae99e8cecb26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393764
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Fixed golem breakage by temporarily copying dartaotruntime to dart_precompiled_runtime
This reverts commit 75e6a748f7.
TEST=ci
Original change's description:
> Revert "[SDK/VM] - Rename dart_precompiled_runtime to dartaotruntime, ensures we have a uniform name for the executable between the build directories and the SDK directory"
>
> This reverts commit 1b331d05c2.
>
> Reason for revert: golem builds are failing
>
> Original change's description:
> > [SDK/VM] - Rename dart_precompiled_runtime to dartaotruntime, ensures we have a uniform name for the executable between the build directories and the SDK directory
> >
> > TEST=ci
> >
Change-Id: Id0f383eabb496c06c0acebc639c8e3b056ba82d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393781
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Fixes https://github.com/dart-lang/sdk/issues/57008
dart2js was mistakenly assuming the generated procedures for these
constructors are top-level external interop members and accidentally
generating invalid code. We should skip serializing these procedures.
This should be safe since any invocation of these procedures are
transformed in visitStaticInvocation.
Change-Id: If11c718bea8447b60de00b73f328a3cdd5544bda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393001
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Dart does not incorporate immutability into it's type system.
Though the WasmGC type system does have such a concept:
* mutable wasm arrays: they are invariant in the element type
* immutable wasm arrays: they are covariant in the element type
Currently we use the mutable wasm array types for e.g.
const foo = const WasmArray<WasmI32>.literal([0]);
which will be compiled to
(type $Array<WasmI32> () (array (field (mut i32))))
(global $globalFoo
(ref $Array<WasmI32>)
(i32.const 0)
(array.new_fixed $Array<WasmI32> 1
)
=> Notice the **mut** in `array (field (mut i32))`
This CL introduces a `ImmutableWasmArray` which is analogous to
`WasmArray`. The array supports only reading methods since the
contents of the array cannot be modified.
Future CLs will make use of this new array type in various places.
=> This will allow binaryen to optimize things better as it knows the
array contents cannot change.
=> So loads from a (final) global with immutable contents can be
folded away at compile time if the index is known at compile-time.
NOTE: The `WasmArray`& `ImmutableArray` classes are not related to
each other. The reason is that in WasmGC a mutable array isn't a
subtype of a immutable array.
Change-Id: I3a764b5aaa3ac47827332f3064035133ab01f1b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392900
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The old hot restart tests only tested DDC-internal state changes, not 'true' hot restart. The 'dart.hotRestart' runtime call is due to be deprecated.
Change-Id: I34e32342bca6fabc886d8283e32ae510f8d49874
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389400
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Appending a script to the DOM in Chrome causes microtasks to fire. This change makes the `hotRestart` pathway async and inserts an async callback at the hot restart boundary for d8.
Change-Id: Ib05e9e496b6313d861fb5cb691a5894beed62a6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389224
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- Since libraries can't be exposed anymore with the new module
format, relies on "this" and the JS foreign function to get the
current library so we can only test the formatting of libraries.
Patches in a link function to match the behavior of the new
module system.
- Cleans up some unnecessary code to support old type system.
- Adds a status file to skip this test in d8 (it's currently
failing).
Change-Id: Ib8c503c5971a96e459d952602ff0ce2004d72878
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389589
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Consider the following code:
void f<T extends void Function(int)>(List<T> x) {
x.first(0);
}
While analyzing the expression `x.first(0)`, the analyzer has to do two things:
- Convert the AST representation from a MethodInvocation (which is
what was initially parsed) to a FunctionExpressionInvocation
targeting a PrefixedIdentifier. This reflects the fact that the
invocation isn't a method invocation after all; it's a function call
invocation applied to a property get.
- Convert the static type of `x.first` from `T` to its bound, `void
Function(int)`, in order to type check the invocation. This is done
using the `TypeSystemImpl.resolveToBound` method.
Previously, `TypeSystemImpl.resolveToBound` was called as part of
converting the AST representation, and the resolved bound (`void
Function(int)` in this example) was stored as the static type of the
FunctionExpressionInvocation target. This led to some minor
inaccuracies in the AST representation (since the type returned by
`TypeSystemImpl.resolveToBound` is *not* the correct type of the
FunctionExpressionInvocation target).
With this change, the call to `TypeSystemImpl.resolveToBound` happens
during resolution of the FunctionExpressionInvocation instead,
allowing the target of the FunctionExpressionInvocation to retain its
correct static type.
I'm in the middle of a larger arc of work trying to introduce a new,
simpler mechanism for flow analysis to be told about the static types
of property gets, and part of that arc of work will involve
introducing a temporary check to verify that the old and new
mechanisms see the same static types. Fixing this incorrect type will
allow the temporary check to pass.
This change also has the side effect of fixing
https://github.com/dart-lang/sdk/issues/56907 (Analyzer fails to
propery type check invocations of complex expressions whose type is a
type parameter). This bug was happening in circumstances where a
FunctionExpressionInvocation arises directly from parsing (rather than
being created from a MethodInvocation), and the static type of the
target is a type variable. Previously, the analyzer was failing to
convert the static type to its bound when analyzing the
FunctionExpressionInvocation, so it was failing to type check the
invocation. Moving the call to `TypeSystemImpl.resolveToBound` into
FunctionExpressionInvocation resolution ensures that the type is
properly resolved to its bound in _all_ circumstances where a
FunctionExpressionInvocation occurs.
Fixes https://github.com/dart-lang/sdk/issues/56907.
Bug: https://github.com/dart-lang/sdk/issues/56907
Change-Id: Id648d5289a6cabe95b8410abd19898acb97fc5e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/390661
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Converts kernel_worker.dart.snapshot and dartdevc.dart.snapshot to
AOT snapshots. Fixes tests and paths in the code accordingly.
TESTS=ci
Change-Id: Ib99b2a3343e23252c3a6b5295b0d20f0f486aede
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381388
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This reverts commit cb9ecbc363.
Reason for revert: causes failures during Dart->Flutter roll and on Flutter HHH bots (see comments on the original CL).
Original change's description:
> [vm] Enforce that entry points must be annotated by default.
>
> Changes the default value of the --verify-entry-points flag
> to true.
>
> Changes the default value for the check_is_entrypoint argument to
> to the Invoke/InvokeGetter/InvokeSetter flags to true. The mirrors
> library implementation and calls via vm-service explicitly pass
> false for this argument now.
>
> Add annotations as needed, such as annotating classes with
> annotated generative constructors. In some cases, the annotations
> were more general than needed (e.g., annotating with a no-argument
> entry point annotation when only the setter is needed), so make
> those annotations more specific.
>
> As this pattern is already common in downstream code, allow
> Dart_Invoke on fields as long as the field is annotated for getter
> access. (That is, calling Dart_Invoke for a field is equivalent to
> retrieving the closure value via Dart_GetField and then calling
> Dart_InvokeClosure.)
>
> TEST=vm/cc/DartAPI_MissingEntryPoints
> vm/dart/entrypoints_verification_test
>
> Issue: https://github.com/dart-lang/sdk/issues/50649
> Issue: https://github.com/flutter/flutter/issues/118608
>
> Change-Id: Ibb3bf15632ab2958d8791b449af8651d47f871a5
> Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-product-arm64-try,vm-aot-dwarf-linux-product-x64-try
> CoreLibraryReviewExempt: adding/editing vm-only pragma annotations
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363566
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Tess Strickland <sstrickl@google.com>
Issue: https://github.com/dart-lang/sdk/issues/50649
Issue: https://github.com/flutter/flutter/issues/118608
Change-Id: Idba168f77b0636a50ad93309e29dc9989cc1f388
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-product-arm64-try,vm-aot-dwarf-linux-product-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391460
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Changes the default value of the --verify-entry-points flag
to true.
Changes the default value for the check_is_entrypoint argument to
to the Invoke/InvokeGetter/InvokeSetter flags to true. The mirrors
library implementation and calls via vm-service explicitly pass
false for this argument now.
Add annotations as needed, such as annotating classes with
annotated generative constructors. In some cases, the annotations
were more general than needed (e.g., annotating with a no-argument
entry point annotation when only the setter is needed), so make
those annotations more specific.
As this pattern is already common in downstream code, allow
Dart_Invoke on fields as long as the field is annotated for getter
access. (That is, calling Dart_Invoke for a field is equivalent to
retrieving the closure value via Dart_GetField and then calling
Dart_InvokeClosure.)
TEST=vm/cc/DartAPI_MissingEntryPoints
vm/dart/entrypoints_verification_test
Issue: https://github.com/dart-lang/sdk/issues/50649
Issue: https://github.com/flutter/flutter/issues/118608
Change-Id: Ibb3bf15632ab2958d8791b449af8651d47f871a5
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-product-arm64-try,vm-aot-dwarf-linux-product-x64-try
CoreLibraryReviewExempt: adding/editing vm-only pragma annotations
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363566
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This CL updates the constant verifier to account for the null-aware
elements and map entries. Namely, the following is done:
* The entries and elements that won't be added to the map or set
literal due to being both null-aware and `null` won't be included in
the uniqueness checks, since they aren't added into the literal.
* The type the null-aware entries and elements are checked against is
updated to be the nullable version of the corresponding type
argument of the enclosing literal.
Change-Id: I20661d84dc26ee87c3893afe294bae5e4274b75f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/390242
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Background: null-shorting is a feature of Dart in which an expression
might evaluate to `null` because a `null` was found deep in a
subexpression, skipping evaluation of the rest of the expression. For
example, in the expression `a?.b(c).d`, if `a` evaluates to `null`,
execution will skip the evaluation of `c`, the method call to `b`, and
the get of `d`, will be skipped, and the whole expression `a?.b(c).d`
will evaluate to `null`. The analyzer needs to account for this by
making the static type of `a?.b(c).d` nullable, even if the type of
the `d` getter is not nullable.
The analyzer's implementation of null shorting works like this:
- When visiting a null-aware expression (such as `a?.b(c)` in the
above example), the analyzer uses
`NullShortableExpression.nullShortingTermination` to find the "null
shorting termination expression". This is the expression that will
evaluate to `null` if the null-shorting code path is taken
(`a?.b(c).d` in the above example).
- The null shorting termination expression is pushed onto the stack
`ResolverVisitor._unfinishedNullShorts`.
- After visiting an expression that might be a null shorting
termination expression, the analyzer passes the node that was just
visited to `ResolverVisitor.nullShortingTermination`, which checks
whether it matches any nodes at the top of the
`ResolverVisitor._unfinishedNullShorts` stack. If any nodes match,
they are popped off the stack, and the static type of the null
shorting termination expression is made nullable.
A subtlety with this approach is that if the resolution process has
rewritten the null shorting termination expression, then there are two
expressions in play: the old one (from the original AST, before
rewriting) and the new one (after rewriting). The node in
`ResolverVisitor._unfinishedNullShorts` is the old one, because the
code that pushes nodes onto the stack happens before rewrites. But the
node that needs to have its static type changed is the new one,
because that's the one that will wind up in the final resolved AST. In
fact, trying to change the static type of the old node would lead to a
crash, because the old node doesn't have a static type assigned.
Previous to this CL, the analyzer dealt with this situation by having
`ResolverVisitor.visitMethodInvocation` pass `discardType: true` to
`ResolverVisitor.nullShortingTermination`. This disabled the logic for
changing the type of the null shorting termination expression, which
avoided a crash, but it meant that the type was never updated
properly, leading to https://github.com/dart-lang/sdk/issues/56896.
The proper solution is to pass both the old and new nodes to
`ResolverVisitor.nullShortingTermination`. The old node is matched up
against `ResolverVisitor._unfinishedNullShorts`, and the new node is
used for marking the static type as nullable.
As part of this fix, I've changed the return types of methods in
`MethodInvocationResolver` from `FunctionExpressionInvocation?` to
`FunctionExpressionInvocationImpl?`. This is a harmless change, since
all these methods are private to the analyzer, and it avoids some type
casts in `ResolverVisitor.nullShortingTermination`.
I also added an assertion to `ResolverVisitor.nullShortingTermination`
to verify that the correct rewritten node is passed in (this assertion
relies on the `ResolverVisitor._replacements` expando, which is only
populated when assertions are enabled). Adding this assertion exposed
two other call sites that had to be updated (in
`ResolverVisitor.visitIndexExpression` and
`ResolverVisitor.visitPropertyAccess`). I've added additional analyzer
tests to cover these cases.
Fixes https://github.com/dart-lang/sdk/issues/56896.
Bug: https://github.com/dart-lang/sdk/issues/56896
Change-Id: I8119a05b4d9f386b1129e5419b823a61677358c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/390560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Makes `whenComplete` create a new future with either the result of the
original, or the error of a future returned by the callback.
Until now it was returning the original future, causing it to be chained after
it was completed. That caused issue with `ignore()`.
(Which suggests that there is still something iffy about ignore and chaining.)
Combines `chainCoreFuture{Sync,Async}` into one function with boolean flag.
Most of the code is the same, and they had accidentally drifted apart.
Fixes#56806.
CoreLibraryReviewExempt: Should be simple refactoring.
Tested: Regression test added
Bug: http://dartbug.com/56806
Change-Id: I52751c078a4e26a10e9da0a64460e2c5c7f34ae5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387360
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When these tests were written
(https://dart-review.googlesource.com/c/sdk/+/178880), Dart did not
support field promotion. I was getting ready to add "why not promoted"
logic to flow analysis so that if a user tried and failed to promote a
field, and received an assignability error as a result, they would
receive a helpful error message explaining that field promotion was
not supported.
In order to generate this error message, flow analysis would have to
start keeping track of some *counterfactual* promoted types,
indicating what the type of certain expressions *would have been* if
field promotion had been supported. It was important to make sure that
these counterfactual promoted types were only used for error message
generation, and didn't actually change Dart semantics. So I wrote
these tests to help lock down the existing (non-promotion) behavior.
When field promotion was actually implemented in Dart 3.2, these tests
should have been given `@dart=3.1` annotations, since their purpose
was to validate the correct behavior of the implementation in
situations where field promotion *wasn't* enabled. I should have been
prompted to do this by a test failure, because when I enabled field
promotion by default in Dart 3.2, the behavior of the tests should
have changed. However, because of
https://github.com/dart-lang/language/issues/4127, the behavior didn't
change, so I didn't notice that these tests needed updating.
Now, I'm getting ready to fix
https://github.com/dart-lang/language/issues/4127, so in order to
prepare for that, I need to give these tests the proper `@dart=3.1`
annotations.
Bug: https://github.com/dart-lang/language/issues/4127
Change-Id: I59ad1eef7b01ccedcc8fb99e070a05273ac365e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389781
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Use JSAny for values returned by the devtoolsFormatter.
- Makes deliberate wherever we *have* to make unsafe casts from
Dart objects to a JS value
- Removes use of package:js (except to test a package:js class
for formatting) and dart:js_util
- Cleans up implicit dynamic in favor of Object/Object? and
void
- References dart:_debugger types to make it more clear what
types we're using
Change-Id: I1b388501a65984bfc92c298dbce9181951040c4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389588
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.
Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.
Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).
Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.
3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.
Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The CFE was passing the original LHS expression to
`flowAnalysis.ifNullExpression_rightBegin`. This was incorrect; it
needs to pass the rewritten LHS expression. Most of the time this was
harmless, since in most cases:
- The expression on the LHS of `??` was not promotable, in which case
passing the wrong expression didn't matter,
- Or the expression on the of `??` was a read of a local variable, in
which case there was no problem, since local variable reads don't
require rewriting.
However, in cases where the LHS of `??` is a read of a promotable
property, it does matter, since property reads are often rewritten
during inference.
Fixes https://github.com/dart-lang/sdk/issues/56874.
Bug: https://github.com/dart-lang/sdk/issues/56874
Change-Id: Ie42b96b0bc14faec38e8dbcb9e11534d4a1db0dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389140
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This allows tests that would fail in JS compatibility mode (e.g. tests that do a lot of string manipulation) to disable the mode for their own execution.
Also ensure dart2wasm-*-jscm-* builds do a "create_sdk" so that the dart2js platform dill is available for the test.
The alternative I considered was skipping the test but "--js-compatibility" is a dart2wasm-specific flag and the test infra is unaware of it so we can't skip the test via a status file.
Bug: https://github.com/dart-lang/sdk/issues/56858
Change-Id: I60179eaab2e4522acf1fe0b47c7c02ccb1ca957b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388644
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This CL implements type inference for null-aware colletion elements
and map entires in the Analyzer. The new functionality is dependent on
the `null-aware-elements` feature flag, since only when the flag is
enable, can the `keyQuestion` and `valueQuestion` properties of the
MapEntryLiteralEntry class be not null and the objects of the
`NullAwareElement` be created.
Part of https://github.com/dart-lang/sdk/issues/56836
Change-Id: I9243b01d5de097ae0d2ca3376807c6209ef0f830
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387980
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The way JS RegExps handle anchored matches is to have a separate RegExp
with `|()` added at the end, which means it either matches at that point,
or the `()` matches at that point, and that's visible in the captures
as a non-`null` last capture group.
The same RegExp is used to find the number of captures a RegExp has,
by running it on an empty string, and seeing the length of the capture
array, even if it contains nothing but `null` and `""` values.
The RegExp is as JS global regexp, which is what allows it to start matching
at a specific point, which we use for `startsWith(Pattern, start)`.
Every *normal* use of that RegExp remembers to set the `lastIndex` of the
regexp before using it, but the `regExpCaptureCount` used the "anchored
regexp" directly, and forgot to set the `lastIndex`, and since it had just
been used and failed to match at a position *later* than the current input
string's length, the "unfailable" test on the empty string failed, returning
`null` where no `null` was expected.
So now `regExpCaptureCount` sets `lastIndex` to zero before using the RegExp,
like every use of a shared RegExp should.
Fixes#56834
Bug: https://dartbug/com/56834
Change-Id: Ib649b70db5922c277950d7b7cfd4d157788d11cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388002
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This CL changes the specification parser grammar to support a switch
expression that has zero cases (this is a missing update, the feature
specification already has it). It also changes several language tests
such that they expect a 'syntax error' rather than a 'compile-time
error'. This makes no difference for any tool except the specification
parser, for which it is needed (in general, a test that is expected
to have a compile-time error will parse just fine, so we need a
separate test outcome expectation for syntax errors).
Change-Id: Ifa00c11ce6c57053bd490e11a41d6e8d7b82a2d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384600
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
After these changes the tests pass 100% of the time on all expected configurations.
- Emit 'unittest-suite-wait-for-done' at the start of tests to allow for async code loading. Tests must therefore emit 'unittest-suite-done' when they complete. Calling `asyncStart` and `asyncEnd` helpers will achieve this.
- Fix test_runner runtime.
- Add file deps on necessary files (dart2js platform dill & flute) to dart2wasm_hostasserts config.
- Mark dart2js compilation test as slow.
Change-Id: Iee993deb3905ccd50068325a5c5fd0bf0512a513
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386980
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Siva Annamalai