This reverts commit c81711bdda.
Reason for revert: `Internal Error: Runtime type information not available for type_variable_local` - b/295131730
Original change's description:
> [dart2js] Add runtime type check for `await`.
>
> See https://github.com/dart-lang/sdk/issues/49396 for details.
>
> Fixes: #50601
> Change-Id: Ie89130cffe642b3e4935d7d02fe2e34f7fc8b12e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316320
> Commit-Queue: Mayank Patke <fishythefish@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
Change-Id: I481b119b6569d1bc9cf2ab80d997a3eb6d06f674
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319421
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
This reverts commit 1948b0a9fe.
Reason for revert: causes `promiseToFuture` to become undefined - b/295129286
Original change's description:
> [analyzer] simplify the libraries.dart file
>
> Change-Id: I86bc196eaddd9a80c02f38c8d947d3c0f4c63394
> CoreLibraryReviewExempt: the sdk_library_metadata/libraries.dart is only used by the analyzer
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317803
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Commit-Queue: Devon Carew <devoncarew@google.com>
Change-Id: I4810c408b996cefd46c0a40cc36818d34aa86071
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319402
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This is mainly used in [1] to allow using unboxed int lists when a
factory type argument is `int`, which then allows inlining unboxed int
list `[]` and `[]=` and storing and loading `int` values unboxed.
This implementation is mostly a copy of VM's transformer with the same
name. However we can't reuse VM's pass as we do different
transformations in [1].
[1]: https://dart-review.googlesource.com/c/sdk/+/318680
Change-Id: I16c06fc2b2edb1a5498807fc5c0fee839c003965
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318921
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The Wasm validation rules state that the failure type is sharpened to
non-nullable if the cast target type is nullable.
Change-Id: I77596c31ea7443c5dace543d13024262879a5fb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318660
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Also renames 'removed' to 'removedIn' to better indicate it is looking for a version, not a boolean.
Change-Id: If3a6708ba32460305e89ba59c4a58ce2ad284e6a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319282
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Pull the error handling outwards to _InstanceCreationEvaluator.evaluate. All errors in const constructors should point to the location of the actual exception and provide more context.
Change-Id: Iafcf46182fab698f5546c63780de6dd9a605a51b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Change-Id: I86bc196eaddd9a80c02f38c8d947d3c0f4c63394
CoreLibraryReviewExempt: the sdk_library_metadata/libraries.dart is only used by the analyzer
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317803
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
`packge:native_assets_builder` had a number of breaking changes.
The most notable one: It now returns a data structure with a `success` boolean instead of throwing exceptions.
Also bumps Dart to 3.0 in Dartdev so we can use records.
Change-Id: Ic32d7c2dd58860883c10f42411b80e979df2a797
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318980
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Hossein Yousefi <yousefi@google.com>
Since user @staticInterop types are erased to JavaScriptObject, they
should only be able to subtype other types that are :> JavaScriptObject,
which are just JSObject and JSAny. Eventually all the other JS types
will move to extension types and we can remove this check.
Change-Id: If56b6770e141238b583937880ca87496780c8fac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316865
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, flow analysis used a hack to make it easy to generate "why
not promoted" messages when the user tried to promote a non-promotable
field: it treated all field accesses as stable for the purpose of
assigning SSA nodes, but avoided promoting non-promotable fields by
setting the `_Reference.isPromotable` flag to `false`. So, for
instance, in the following code, both subexpressions `c.i` got
assigned the same SSA node, even though there's no guarantee that
`C.x` will return the same value each time it's invoked.
class C {
int? get i => ...;
}
f(C c) {
if (c.i != null) {
var i = c.i; // Inferred type `int?`
}
}
This mostly worked, since the SSA node assigned by flow analysis is
only used for promotion, and promotion is disabled for non-promotable
fields. However, it broke when the field in question was used as the
target of a cascade, because fields within cascades always had their
`_Reference.isPromotable` flag set to `true` regardless of whether the
corresponding cascade target is promotable. For example:
class C {
D? get d => ...;
}
class D {
final E? _e;
...
}
class E {
m() { ... }
}
f(C c) {
(c.d)
.._e!.m() // OK; promotes _e
.._e.m(); // OK; _e is promoted now
(c.d)
.._e.m(); // OOPS, _e is still promoted; it shouldn't be
}
See
`tests/language/inference_update_2/cascaded_field_promotion_unstable_target_test.dart`
for a more detailed example.
This CL removes the hack; now, when a non-promotable property is
accessed more than once, flow analysis assignes a different SSA node
for each access. As a result, the `_Reference.isPromotable` is not
needed, because non-promotable fields simply never have the chance to
be promoted (since every field access gets a separate SSA node, so
type checking one field access has no effect on others).
To preserve the ability to generate "why not promoted" messages, the
`_PropertySsaNode` class now contains a `previousSsaNode` pointer,
which links together the separate SSA nodes allocated for
non-promotable properties, so that they form a linked list. The "why
not promoted" logic traverses this list to figure out which promotions
*would* have occurred if the property had been promotable.
In order to make it efficient to create this linked list, the
`SsaNode` class also had to acquire a `_nonPromotableProperties` map,
which records the SSA node that was allocated the last time each
property was accessed.
Fixes https://github.com/dart-lang/sdk/issues/52728.
Change-Id: I16a7b27f77c309bdccce86195a53398e32e8f75d
Bug: https://github.com/dart-lang/sdk/issues/52728
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318745
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a step towards detaching bodies of closures/local
functions from the enclosing functions in TFA, so closures
could be analyzed separately.
Also, this change allows TFA to accumulate types of captured local
variables among all invocations.
On a large Flutter app, this change doesn't cause noticeable compilation
time or snapshot size changes.
Issue: https://github.com/dart-lang/sdk/issues/39692
Issue: https://github.com/dart-lang/sdk/issues/51102
TEST=pkg/vm/testcases/transformations/type_flow/summary_collector/control_flow.dart
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-product-arm64-try
Change-Id: I785b15656df559a8cc80fcceea196b480ba7a91a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318021
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
- Allow running the tests with asserts enabled
- Allow running the tests in canary mode
- Unify common test code and remove duplication
- merge expression_compiler/setup_compiler_options.dart
into share_compiler_options.dart
- Merge TestCompiler code from expression evaluation and
expression compilation tests and move into
expression_compiler/test_compiler.dart
- Rename various TestDrivers so they have more descriptive names
- Remove 'golden' JS comparison tests from expression_compiler_test.dart
- replace by evaluation tests where needed
Closes: https://github.com/dart-lang/sdk/issues/53145
Change-Id: Ic797fa4ee9bfa6b858b924be9f9a53fd10ae1448
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318080
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Includes a fix for the serialization of the representation name found
through the update of the ast-to-text.
TEST=existing
Change-Id: Id741d66d8f43b5dc1d5e79f967b9625579539404
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318941
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
No functional changes here, I'm just trying to simplify the hover implementation a little as this method had gotten quite long and deeply nested. We've discussed improving hover support for patterns and keywords and hopefully this'll make that easier.
Change-Id: I974f7fb0fbb99a967b5970f99b36ef3601df4ea3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318701
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, just simplifies the tests a little by calling functions to set capabilities instead of having to nest them inside `initialize()` calls.
Change-Id: I1496da221b1802c3375c32c7e0d048310769bdf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317961
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Otherwise they'll be recorded as "lsp.handle".
Change-Id: I511d5eef44d6d647fef4d0347a03f6a7a9f88f9e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is just a little refactoring towards https://github.com/Dart-Code/Dart-Code/issues/2462. It doesn't change anything, it just makes the next CL (with the functional changes) simpler.
Change-Id: I98ed5991f1abb67f86f9d4d43c27ff6ccf21847c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317940
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Originally we didn't use the LSP Request/Response classes, and just exposed the handlers through the legacy request/response.
However there were some mismatches (such as legacy protocol always returns Map<String, Object?> but some LSP requests return Lists, LSP using int|String IDs, and LSP having numeric error codes that don't match legacy string error codes).
This change uses LSP's request and Response by wrapping them inside a standard (legacy) handler. The LSP-over-Legacy handler has become a standard handler, and the params contain an "lspMessage" field that holds an LSP message, and the result contains an "lspResponse" field that contains an LSP response.
If an LSP handler returns an error, it will be returned as an error inside the LSP response, which will be in a _successful_ legacy request (since that's how we can return an LSP response - as the result).
Change-Id: I67973590ab32f3543d1a6e1b7279974e5e8832bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315201
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I was trying out DCM and it found this bogus condition.
The only instance I can find where it triggered was adjacent interpolations in strings, and the fallback code (which compares by token type) would handle it correctly, but in case there are other cases (now or in future), I've added an assert to try to avoid reaching the fallback in case it doesn't produce the desired result.
Change-Id: I3092fa4892c812be7d3a91629c5f6ed3be627743
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315720
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Several changes are made:
- createDartExport now does not export methods that define type parameters.
- createStaticInteropMock adds conformance checks to make sure implementing
members can handle all possible values of a type parameter in an interop
member. An error is added to reduce confusion around this.
- Export creator now uses dart:js_interop_unsafe for a lot of its lowering
as the dart:js_util equivalents are buggy when it comes to calling exported
functions in JS with JS types.
- Small code changes are added to backends to handle the above changes.
Change-Id: Ie3b6b157930537267f270b60373b2b17e0a14344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316141
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
