Change-Id: I785eae3d32363db95a3cad00ee3c2c827a5ec9da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319400
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
The [Environment] represents 2 different things:
* before (env, deopt-id): The state of unoptimized frame right before
the IL instruction is executed
* after (env, deopt-id): The state of unoptimized frame right after
the call machine instruction instruction (i.e. which may not be
after the IL instruction - as it may still have to drop arguments)
The environment's prune-count specifies the number of entries from the
[Environment] to be removed to get from before-env to after-env.
This prune-count includes generally most of `<IR>::InputCount()` - as
most IR instructions consume their inputs (which location summary may
e.g. require in registers) before doing any call. Though it doesn't include
arguments as we currently have a stack-based calling convention and both
optimized and unoptimized code will explicitly drop them after the machine
call instruction.
Our optimizing compiler may emit speculative instructions. Those will
receive an environment that makes before (env, deopt-id) and after (env,
deopt-id) the same - as both eager and lazy deopt will target a
before (env, deopt-id).
=> We should ensure that the prune-count is set to 0, ensuring we won't
prune anything in case an IL instruction was marked with
`MarkAsLazyDeoptToBeforeDeoptId`.
=> This is a preparation for inlining force-optimized functions: If we
inline them and some callee IL instruction performs lazy deopt it should
re-try the call without any pruned inputs.
TEST=ci
Change-Id: I091c9fa962b376200dc5cfb6ea8c9a47ef43810f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319440
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
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>
This test is flaky and timing out on hot reload bots.
Change-Id: If0c9574ac80405d14765e4ada4fdee8e6bce9d79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319001
Reviewed-by: Alexander Aprelev <aam@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Aprelev <aam@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>
The main purpose of the low-level [PortMap] is to coordinate between
ports being opened & closed and concurrent message senders. That's the
only thing it should do.
Each isolate owns [ReceivePort]s. Only the isolate mutator can create
ports, delete them or change their "keeps-isolate-alive" state. Right
now it requires going via [PortMap] (which acquires lock) and
[MessageHandler] (which acquires lock) to change the
"keeps-isolate-alive" state of a port.
We'll move information whether a dart [ReceivePort] is closed and
whether it keeps the isolate alive into the [ReceivePort] object itself.
=> Changing the "keeps-isolate-alive" state of the port no longer
requires any locks. We could even avoid the runtime call itself in a
future CL.
Isolates are kept alive if there's any open receive ports (that have not
been marked as "does not keep isolate alive"). This is a property of an
isolate not of the message handler. For native message handlers we do
have a 1<->1 correspondence between port and handler (i.e. there's no
"number of open ports" tracking needed).
=> We'll move the logic of counting open receive ports and ports that
keep the isolate alive to the [Isolate].
=> We'll also remove locking around incrementing/decrementing or
accessing the counts.
=> The [IsolateMessageHandler] will ask the [Isolate] whether there's
any open ports for determining whether to shut down.
=> For native ports, the `Dart_NewNativePort()` & `Dart_CloseNativePort()`
functions will manage the lifetime (as their name also suggests).
Overall this makes the [Isolate] responsible for creation of dart
[ReceivePort]s and tracking whether the isolate should be kept alive:
* Isolate::CreateReceivePort()
* Isolate::SetReceivePortKeepAliveState()
* Isolate::CloseReceivePort()
TEST=ci
Change-Id: I847ae357c26254d3810cc277962e05deca18a1de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317960
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If a thread owns a lock already before acquiring the safepoint
operation, it can re-acquire the same lock inside the safepoint
operation (as it's a NOP and canoot lead to deadlocks).
TEST=ci
Change-Id: I4a7c3526683e09d4408d97aca9e9b59d6ca53d19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318662
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
All uses of `PortMap::Create()` would call `PortMap::SetPortState()`
after creating the port. To avoid acquiring the port map lock twice, we
can initialize the state already in `PortMap::Create()`.
Additionally we fix an existing issue by making the isolate's main port
a control port (instead of leaving it as a `kNewPort`).
As a side-effect we'll no longer have any allocated ports with state
`kNewPort`.
We also remove the unused `PortMap::IsLocalPort()`
TEST=ci
Change-Id: I6198792a8e1132580b60262f10a807c5b12f9eaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317680
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
