It is unclear if this will help reduce flakiness and timeouts. Until now
the test was setting the listener and making the transition on the same
microtask. If the transition were to complete before the listener is
fully set up, then that would explain the timeout: the transition event
is never fired at that point. Honestly, I find this scenario hard to
believe, but regardless it is worth a try.
This small refactor changes the order to ensure the listener is set up
upfront, and only later we initiate the transition.
Change-Id: I3ae2bfae210ef307935c3d7f2aec9af82df1ddd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332625
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This test appears to flake 88% of the time in FF. One
potential reason could be that FF requires user interaction
(similar to the notification_permissions test), however
I don't have an explanation why it doesn't consistently time-out.
One potential theory is whether this behavior is different depending on
which FF browser version is used, but I don't have the data at the
moment to confirm.
Change-Id: Ib5b2759e0d289e44ff06ab11345c597af6cab0f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332626
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Previously, if field promotion failed both because the language
version was less than 3.2, *and* for some other reason(s), the
analyzer and CFE only reported the other reason(s). The rationale was
that this was better than reporting just that the language version was
less than 3.2, because if a user upgraded their language version to
3.2 in an attempt to get field promotion to work, and *then* found out
that the property in question was unpromotable for some other reason,
that could be quite frustrating.
With this change, if field promotion fails both because the language
version is less than 3.2 and for some other reason, the analyzer and
CFE report *all* the reasons.
Change-Id: Ib5d3a4621273c1e80d66b66b456119f9053e18b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332485
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Update the type inference algorithm so that `FlowAnalysis.propertyGet`
is appropriately called when analyzing code that refers to the
representation variable of an extension type.
Flow analysis requires an arbitrary `Object` to represent the property
in question; this is later passed to
`OperationsCfe.isPropertyPromotable`. We use the synthetic
"representation field" (which is actually a `Procedure`) for this
purpose
(`ExtensionTypeRepresentationAccessTarget.representationField`).
Representation variables are considered promotable if they are public
(see
https://github.com/dart-lang/language/pull/3411). `OperationsCfe.isPropertyPromotable`
can tell if the representation variable is public by checking the name
of the synthetic representation field.
Fixes#53439.
Bug: https://github.com/dart-lang/sdk/issues/53439
Change-Id: I8f7ff8fcd8e5a43de419b8441951b52a555fda1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332480
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Change-Id: Ic5bbb5eb12259d076b697bce7624cde181d7beb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332484
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Add the "vm:keep-name" pragma to the class whose name is checked.
Add isObfuscated to guard the check that includes named parameter
names, since currently they are obfuscated, even if the function is
marked with the "vm:keep-name" pragma.
TEST=language/type_object/runtime_type_function on
vm-aot-obfuscate-linux-release-x64
Fixes: https://github.com/dart-lang/sdk/issues/53879
Cq-Include-Trybots: luci.dart.try:vm-aot-obfuscate-linux-release-x64-try
Change-Id: I7698607ed6e1c95860f2e26ede923320a409eba4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332425
Reviewed-by: Daco Harkes <dacoharkes@google.com>
TEST=Existing tests covers.
Change-Id: I161eefdc28c74f63ba1ee926800a01eea03d9930
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The test standalone/string_overflow_test.dart is causing crashes
and out-of-memory thrashing on some configurations. It was originally
a regression test that concatenating a string with 2^31 characters
did not overflow a 32-bit signed integer.
It was changed to exponentially grow a string until an out-of-memory
runtime exception is thrown in Dart. On some VM configurations,
this crashes the machine instead.
Restoring it to only check concatenating a string of 2^31 bytes.
Bug: https://github.com/dart-lang/sdk/issues/46225
Change-Id: Ib50625fe14be2613c907a7bc30cd57766693f6aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332423
Reviewed-by: Martin Kustermann <kustermann@google.com>
These tests had several issues. The fixes are aimed to reduce flakiness
and remove invalid configurations where tests are not providing any
value. Some of the issues include:
* some tests interferered with each other causing a 18% flakiness rate
in chrome: they used a common file system that ended up being shared
in a single browser instance. This is why some tests failed when they
find a file exists before it was created [1].
* some tests were not properly using async_helper/async_minitest, so
they may complete before they finish executing
* DDC no longer supports these APIs due to
https://github.com/dart-lang/sdk/issues/53864. We don't intend to fix
those issues, so there is no purpose in running these tests in DDC at this
time.
[1]: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8766313714239949697/+/u/test_results/ignored_flaky_test_failure_logs
Change-Id: I1dbb28eba2d962000a4d425563dbc1eb6b55dbed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332266
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Similar to the request_animation_test, it's unclear the reasons why this
test is hitting flaky timeouts (rate as high as 70% in DDC!).
This change can hopefully improve handling of
asynchrony in the test and help us investigate further.
Change-Id: I5c6023ccfaa7270b1d1e49d902fe9fa168d0d868
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332169
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test provides very little value. It requests the notification
permissions and waits for an answer. What's happening is that the test
launches a prompt and then waiting for a user to click on the browser
dialog to accept or reject the request.
On the bots, this is consistently timing out in chrome and safari.
Turns out this issue was [identified][1] 5 years ago and the test was marked
as Timeout in the status files for that reason (dart2js) or skipped
(DDC). Back then there were discussions
about whether we could make chrome automatically accept or reject the
request, but there was no traction on that.
If we thought this test was providing value, we could explore whether
there is a way to make bots automatically accept/reject the prompt by
saving some preferences on the test machines. That said, I'm honestly
not seeing much value here. For that reason, I'm inclined to delete the
test instead.
Other reasons to delete mentioned in the review:
* this API may require a secure context, but our test runner doesn't default to use https yet
* this API requires a [user gesture in FF][2]
[1]: https://github.com/dart-lang/sdk/issues/32002
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Notification/requestPermission_static
Change-Id: Ib8d372b2ebfb5859a0a9bc82d50a14ad8badeab1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332320
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test is flaky and causes timeouts 70% of the time in DDC.
The reasons are not clear at the moment, but I noticed that the
test was not properly using async-helper. This change may help
improve our investigation in the near future.
Change-Id: I834265dd6b898098ee7d5210ffe68ef0a6db74a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332280
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test is 61% flaky in dart2js-chrome and 73% flaky in DDC.
This test is almost identical to
lib/html/element_animate_simple_timing_test (long ago it was a separate
case in the same file that used the html multi test configuration). The
only difference is that this test has no deadline for the animation to
complete, while the other test (which passes consistently) does.
My theory is that not including a deadline is the cause of flakiness and
without it, there isn't ,uch we can control to recover consistency. As
such, I don't think we should be including this test anymore.
Change-Id: I5451dbc7053ba0280a64e1bef2e03cc20465ad88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332170
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
1. Add `Object` and `Map` to the very short list of names that are
unminified in the app.
2. Tweak test to avoid testing minified name.
Change-Id: Ide0cedc2950b5392eb6963403a48c0f89cd1b50a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332368
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This test has non-deterministic failures (rate 30% on mac, 10% on linux
and windows) caused likely by a data-race ([example log][1]). The test
has a write to set the contents of a file, and a corresponding read. The
error makes it appear as if the read occurred before the write
completed.
This API is part of the [createWriter][2] proposal, which was abandoned
early on (almost a decade ago) and documented as deprecated. As a result
I believe this test is providing coverage for obsolete functionality.
In fact, the API for the `write` returns void and appears synchronous,
but my guess is that it is not. There is no API to ensure the write
completes as far as I know. An alternative here would be to use timers
to add a significant delay between the operations.
It is also worth noting that the [requestFileSystem][3] API to access
the FileSystem (used here and in the fileapi tests) is also deprecated
and not supported in firefox or safari.
Given the flakiness issue and the fact that this API is already
deprecated, I'm not really seeing the value in keeping the test.
[1]: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8767600632278735009/+/u/test_results/ignored_flaky_test_failure_logs
[2]: https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileEntry/createWriter
[3]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestFileSystem
Change-Id: I92ad6399218c6a17cfa029a99b99afcfadde0035
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332282
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This add support for inherited combined member signatures, both from
source and from dill.
Change-Id: I163f2b30c3242ba98692d7e9b52ef93fd0d6a903
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332201
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This test has failed with a timeout in a flaky manner: 48% on windows,
13% on linux bots. Unlike other timeouts, this is a legit slow test
because the compiler takes too long to build it. That seems justified
given that this is a stress test for deferred loading, so it is expected
to be slow.
This CL updates the status file for non host-asserts configurations, since the
hostasserts configuration already has 4x budget.
Change-Id: Ie6b53a8c7ef5f6c9b9c6748386db2ae505c2eca2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332281
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
It seems to me that this test doesn't provide value for the JS backends.
The test was first introduced 11 years ago to investigate and fix GC
issues in Dartium that happened across the Dart/DOM boundary (see
https://github.com/dart-lang/sdk/issues/1448).
While the test works in many configurations, this test is flaky in
dart2js-firefox (37%) and DDC (8-14%). I haven't investigated the
reasons behind the timeouts, but given the origins of the test, it
doesn't seem worth fixing it.
Change-Id: I3eaf2273209b587ce5ecfcf4a2bbbd9cb8b990fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332167
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
If the user attempts to promote a property, and their language version
does not permit field promotion, the "why not promoted" logic now
checks whether the language version is the sole reason for the failure
in property promotion. In other words, it checks whether the property
would have been promotable *if* field promotion had been enabled. If
it would, then the context message displayed to the user explains that
the property did not promote because field promotion is not supported
by the current language version.
However, if there is some secondary reason why the property failed to
promote (in other words, if the property would not have been
promotable even if field promotion had been enabled), then the context
message now favors the secondary reason.
Rationale: imagine a user is maintaining a package that doesn't yet
support SDK version 3.2, and that package contains some property
that's non-promotable both because the language version is prior to
3.2 *and* for some other reason (e.g., because the property isn't a
private field). It would be quite frustrating if the user saw a
context message suggesting that the property would be promotable in
SDK 3.2, and then went to a lot of effort to bump their minimum SDK
version, only to discover *after* the bump that the property is still
not promotable.
In the process of making this change, I discovered that the CFE
doesn't support field promotion in patch files. This is because patch
files aren't listed in `SourceLoader.sourceLibraryBuilders`, so the
logic in the `FieldPromotability` is never invoked for those
files. Since patch files are an artifact of SDK development, and will
never be used by end users, it doesn't seem worth going to extra
effort to add this support. However, I've taken care to make sure that
the "why not promoted" logic recovers gracefully in patch files (by
simply not generating a context message).
Change-Id: I6c0d1c0f4b8a7690f6f775408cb5e857b2dd7b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330241
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
These tests had bugs intronduced during the the null-safety test
migration. Surprisingly the failures didn't show up on some
configurations because the tests were previosly not using the
async-helper wrapper. As a result, the test was logged as completed and
passing before it was done executing. Together this was the cause why
these tests failed in d8 and flaked in firefox.
This CL fixes both issues. A few notes:
* web_2 tests didn't have bugs, but this CL also adds asyncHelper to
match
* it's quite possible that many of these `is` tests are optimized away
in dart2js. I added a couple `confuse` calls when the trivial tests
were highlighted by the analyzer directly (not based on whether or not
dart2js optimized them away).
Change-Id: I8f58c0b0b850023764524f57201eada89a5c0d6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332062
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This create a stub for combined member signatures from multiple
inherited non-extension type members and adds these to the
extension type declaration.
A sealed [TypeDeclaration] superclass is added to [Class] and
[ExtensionTypeDeclaration] to support accessing the enclosing type
declaration from a [Member].
TEST=existing
Change-Id: Ic01535d27a14187d37b00868e7e90fe73558b051
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331181
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This test has flaked on our CI but actually it's consistently failing
because we do not represent `typedef`s in a reflective way in the VM
since switching to kernel (because they used to be desguared on kernel
level).
So this has not been working for a long time, let's remove this test.
Issue https://github.com/dart-lang/sdk/issues/44489
Change-Id: I36e8d8aee7a7736e8afc5741b01d10429ac0d7a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331941
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
When a field is declared in a mixin, the front end creates a synthetic
getter in the mixin application class that gets the value of the mixed
in field. So if a piece of code accesses the mixed in field through
the mixin application class rather than through the mixin directly,
the resolved member is the synthetic getter rather than a field.
In order to ensure that the field remains promotable even if it is
accessed through the mixin application, the logic in
`OperationsCfe.isPropertyPromotable` needs to be changed so that it
doesn't treat these synthetic getters as non-promotable. The old logic
was essentially this:
1. If the property is not private, it's not promotable.
2. Otherwise, if the property is listed in
`FieldNonPromotabilityInfo.fieldNameInfo`, it's not
promotable. (This happens either if the property is not promotable
for an intrinsic reason, such as being a non-final field or a
concrete getter, or if it has the same name as a non-promotable
property elsewhere in the library).
3. Otherwise, if the property is a getter that was lowered from an
abstract field, it's promotable.
4. Otherwise, if the property is a getter that was lowered from a late
field, it's promotable.
5. Otherwise, the property isn't promotable. (This was intended to
cover the case where the property is an abstract getter
declaration).
(Although conditions 3 and 4 were tested first, since they are more
efficient to test).
It turns out that once conditions 1-2 have been ruled out, the
property must have been declared as a method (which is being torn
off), a private abstract getter, or a (possibly abstract) non-external
private final field. Of these three possibilities, only the last is
promotable. So this can be simplified to:
(conditions 1-2 as above)
3. Otherwise, if the property is a method tear-off, it's not promotable.
4. Otherwise, if the property is an abstract getter, it's not promotable.
5. Otherwise, the property is promotable.
This makes the logic easier to follow, since conditions 1-4 are now
all reasons for non-promotability (rather than a mix of promotability
and non-promotability reasons). It also conveniently addresses the
problem with fields accessed through mixin applications, since they
aren't excluded by any of conditions 1-4.
(We still test conditions 3 and 4 first, since they are more efficient
to test.)
Fixes#53742.
Fixes#53617.
Fixes#53436.
Change-Id: I64df269c2a4a0714f9be239d832b61f4fb6a1a43
Bug: https://github.com/dart-lang/sdk/issues/53742
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330168
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit b657773d58.
Reason for revert: blocking Dart SDK -> Engine roll (https://github.com/flutter/flutter/issues/137054)
Original change's description:
> [typed_data] Deprecate UnmodifiableUint8ListView and friends
>
> This is the first of several steps to remove the unmodifiable views for typed data classes. The end goal is that dart2js has only one class implementing `Uint8List` so that `Uint8List` accesses can always be compiled down to JavaScript code that directly uses indexed property accesses (`a[i]`).
>
> This first step deprecates the unmodifiable view classes to help prevent their use in new code, and adds `asUnmodifiableView()` methods as a replacement for the small number of places that use the classes.
>
> The next steps (see #53785) are to remove uses of the unmodifiable view classes from the SDK. Once this is complete the classes themselves can be removed.
>
> TEST=ci
>
> Issue: #53218
> Issue: #53785
>
> Change-Id: I04d4feb0d9f1619e6eee65236e559f5e6adf2661
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321922
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
Issue: #53218
Issue: #53785
Change-Id: I0bb042269f9ff8e5cd69619cf97b60c79ea98cbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331680
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This is the first of several steps to remove the unmodifiable views for typed data classes. The end goal is that dart2js has only one class implementing `Uint8List` so that `Uint8List` accesses can always be compiled down to JavaScript code that directly uses indexed property accesses (`a[i]`).
This first step deprecates the unmodifiable view classes to help prevent their use in new code, and adds `asUnmodifiableView()` methods as a replacement for the small number of places that use the classes.
The next steps (see #53785) are to remove uses of the unmodifiable view classes from the SDK. Once this is complete the classes themselves can be removed.
TEST=ci
Issue: #53218
Issue: #53785
Change-Id: I04d4feb0d9f1619e6eee65236e559f5e6adf2661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321922
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
- In development mode (DDC) the extra null safety errors will be thrown.
- Remove extra code paths that called unsound helpers.
- Fix expectations in weak_null_safety_errors_test.dart.
Change-Id: I107c602b0ae38b13038e501564cba9b8cfc58e70
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329568
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
See 3ecf3a729a
Change-Id: If58e262fb913a11edd8f0ecf3f2dcba6879ee65b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331086
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
- Remove test directories standalone_2 and dart_2
- Remove all references to standalone_2 and dart_2 in test scripts
TEST=ci
Change-Id: I574868e274558efbbe12fe8b6408bbe77a888583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330982
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Add a few more parser tests.
Change-Id: I9ba22f0216cd3dcb2b104d8005429445c1e87637
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331083
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes an edge case on all ARM64 ABIs, when there is only one argument register remaining and the next argument is a 9-16 byte struct.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/52644
Change-Id: I40d962e6d1b3484dbfcf91f5d6baca0bfec76056
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330161
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Bug:https://github.com/dart-lang/sdk/issues/53161
Change-Id: I3f13af3cb852b3656341922b9656ec91fc413eed
Tested: documentation + unit test only
CoreLibraryReviewExempt: Only adds documentation and adds a unit test to verify existing behavior
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323426
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The front end handles mixin applications by synthesizing new fields
and procedures in the mixin application class to reflect the fields
and procedures from the mixin.
In order to ensure that the appropriate "why not promoted" context
messages are created for these synthesized fields and procedures,
entries need to be created for them in the
`FieldNonPromotabilityInfo.individualPropertyReasons` map.
Note that the source locations for these synthesized fields correspond
to the declaration of the mixin application rather than the original
field or procedure; to find the original field or procedure we use
`Procedure.stubTarget`.
Change-Id: Ib20d2514cb5aad8f95b93d26ad0e3917f1613db3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330246
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The type normalization rules specify that `FutureOr<T>?` is normalized
to `FutureOr<T>` when `T` is nullable. However, it's more practical
for subtype testing if the declared nullability on the runtime
representation of the `FutureOr` type reflects the true nullability
(nullable if the `FutureOr` is declared nullable or its type argument
is nullable), rather than being normalized as per the spec.
This changes the static and dynamic normalization rules in dart2wasm
thus and compensates by computing the proper spec normalization when
the type is converted to a string.
The added test exposed a number of bugs in DDC and the VM:
https://github.com/dart-lang/sdk/issues/53175https://github.com/dart-lang/sdk/issues/53737https://github.com/dart-lang/sdk/issues/53738
Change-Id: I0ad0a09fe935ccbd3eb65e6958c958d29e0bb088
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320821
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This test covers getters explicitly declared inside an extension type,
as well as getters and fields of the representation type, when they
are exposed via an "implements" clause.
Promotion of the representation variable of an extension type is not
yet implemented, so it is not tested yet.
Addresses code review comment
https://dart-review.googlesource.com/c/sdk/+/328060/comments/3c8783b0_7831982f.
Change-Id: I89683878e2105bebf3cf4888aab55870bfb9a572
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330027
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The existing usage will no longer work as expected once the security
measures to prevent native Object prototype pollution are enabled.
The recommended replacements are `Object.getPrototypeOf()` and
`Object.setPrototypeOf()`.
Change-Id: I0617233bd31ccd2afc9f94c527eecb31c5f1b340
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330047
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The default socket timeout is longer than the test timeout for some configurations.
Change-Id: Iddf60b6d40b8aa00115463fe76f1d924a93424bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329640
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Tests valid and invalid extension type representation type
and representation object reference declarations.
Bug: https://dartbug.com/53625
Change-Id: I56b61e4c7e691db975da286b31a93a0635257088
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328160
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
During summary generation for a library, when
`_FieldPromotability.perform` computes which fields are promotable,
the data computed by the shared method `computeNonPromotabilityInfo`
is serialized into the element model, in
`LibraryElementImpl.fieldNameNonPromotabilityInfo`. This data reports,
for each private getter name, precisely which declarations it
conflicts with. These declarations are explicit fields, explicit
getters, and classes that contain implicit `noSuchMethod`-forwarding
getters.
Later, if a compile-time error results from a failure in field
promotion due to a conflict between the field in question and another
field or getter of the same name elsewhere in the library,
`_WhyNotPromotedVisitor.visitPropertyNotPromotedDueToConflict` is
called. It iterates through the information stored in
`LibraryElementImpl.fieldNameNonPromotabilityInfo` and generates
context messages for each conflicting declaration.
Change-Id: I8f63425384c917db9bbc6e6dd5990a3d10a3a7ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328061
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Previously, when field promotion failed due to a conflict with another
declaration in the same library, the client (analyzer or front_end)
was responsible for returning a value of
`PropertyNonPromotabilityReason.isInterferedWith` from
`Operations.whyIsPropertyNotPromotable`. Flow analysis would propagate
this value into a `PropertyNotPromoted` object whose
`documentationLink` getter returned `null`. The client was then
responsible for tracking down all the conflicting fields and getters
and creating the appropriate context messages for them (but this
functionality wasn't implemented yet).
With this change, the `PropertyNotPromoted` is now abstract, with two
subclasses to represent the two cases the client has to handle:
- `PropertyNotPromotedForInherentReason` to cover the case where a
property cannot be promoted due to the fact that it is inherently
not promotable (i.e. it's not final, it's public, it's external,
it's not a field, or it's in a library where field promotion isn't
enabled). In this case the client simply has to generate the
appropriate context message and attach it to the site where the
property is declared, and it can rely on having access to a non-null
`documentationLink` to include in the context message.
- `PropertyNotPromotedDueToConflict` to cover the case where the
property cannot be promoted due to a conflict with some other
property in the same library. In this case the client has to
generate multiple context messages, one for each conflicting
declaration, and it has to associate each one with the appropriate
documentation link from the `NonPromotionDocumentationLink` enum.
The `NonPromotionReasonVisitor` base class has been updated to reflect
this split, so that the logic for handling these two cases is in
separate methods in the client.
The front_end logic for handling non-promotion due to conflict is now
fully implemented. The analyzer logic will be addressed in a follow-up
CL, since it's more complex (it requires plumbing additional data
through the summary file format).
Finally, the nomenclature in the `FieldNameNonPromotabilityInfo` is
adjusted to match the new context messages.
Change-Id: Ieed70d1a3572abbc726ae34584d85c7a8aee0732
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327712
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Context messages are added to clarify to the user the following
reasons why field promotion might fail:
- Field promotion is not supported prior to Dart 3.2.
- The property in question is not a field.
- The property in question is not private.
- The property in question is an external field.
- The property in question is not a final field.
The final reason why field promotion might fail (interference with
another field or getter of the same name) will be addressed in a
future CL.
Change-Id: Ic860af51d98d8bc84b1103d3ed353b0c4fed39b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327707
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- When the shared logic in `field_promotability.dart` decides that a
given field should be non-promotable based on attributes of the
field itself (i.e. because it's public, non-final, or external), it
returns information to the caller about the reason for
non-promotability.
- This information is recorded by the analyzer and CFE, and delivered
back to flow analysis in response to a new callback method,
`whyIsPropertyNotPromotable`. Flow analysis records this information
in the `PropertyNotPromoted`, which is delivered to clients when a
compile-time error occurs due to a property access not being
promotable. This ensures that the appropriate
`http://dart.dev/go/non-promo-...` link will be associated with the
context message. In a future CL, the context messages themselves
will be updated to match the link.
- The shared logic in `field_promotability.dart` also collects, for
each field name that isn't promotable, all the reasons why that
particular field name is non-promotable, in a new data structure,
`FieldNameNonPromotabilityInfo`. In a future CL, this data structure
will be used to explain to the caller situations in which a field is
non-promotable due to interference from other fields or getters with
the same name.
Change-Id: I89ad102a4bec071bf59374971a8d83b061d4ec1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327901
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The asyncStart/asyncEnd implementation maintains a counter that will
signify to the test framework the test is done as soon as the counter
reaches 0 again.
This means we have to ensure the counter is >0 as long as any test is
running.
The standalone/io/http_client_connect_test wasn't doing that as it has
code like this
main() async {
...
await foo();
await bar();
...
}
foo() async {
asyncStart();
...
asyncEnd();
}
bar() async {
asyncStart();
...
asyncEnd();
}
So the test is considered done after the `await foo()` decremented the
counter back to 0.
TEST=Fixes flaky standalone{,_2}/io/http_client_connect_test on iso-stress builder
Change-Id: I71a89d740a814df7364153ef79bad9dd85dc9b3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327862
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit 67f0d4daf0, and further optimises constructor contexts by preventing empty contexts.
Reason for revert: Includes fix for Flutter engine unit test failures.
Fixes https://github.com/dart-lang/sdk/issues/53506
Original change's description:
[dart2wasm] Replace `struct.new_default` with `struct.new` for object allocation.
When using the `struct.new_default` instruction for object allocation,
fields are always nullable and mutable. By using the `struct.new`
instruction instead, class fields can now have the same mutability and
nullability in Wasm as declared in Dart. In addition, the class ID and
type parameters (which are also stored in an object's struct), can now
be immutable and nonnullable as well.
To do this, object construction is now split into three functions:
(1) Initializer: evaluates initializers for instance fields and
constructor initializers (this constructor before super constructor).
(2) Constructor body: executes the constructor body (super constructor
before this constructor), with `this` pointed to the constructed object.
(3) Constructor allocator: which calls (1), allocates the object using
`struct.new`, then calls (2).
Because fields now have the correct mutability and nullability in Wasm,
this removes unnecessary null checks for nonnullable fields, and may
allow for better optimisations by Binaryen.
Fixes https://github.com/dart-lang/sdk/issues/51492
Change-Id: I13499bdc412f474bc76473115b6e63d6954f4d23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326080
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Jess Lally <jessicalally@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL introduces StructuralParameter and StructuralParameterType
classes. They are intended to replace TypeParameter and
TypeParameterType respectively where those were used as type
parameters defined by FunctionTypes. Previously, type parameters of
FunctionTypes were represented by TypeParameter objects with the
‘parent’ field set to null. By introducing StructuralParameter and
StructuralParameterType this CL unambiguously separates the two
notions of type parameters.
TEST=existing
Change-Id: Ida3feb7ad96a7b2acef55840eacba9e36bf2a3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312264
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Minus all the operator-related functionalities, members that
can be worked around using static interop e.g. getPrototypeOf,
and createDartExport/createStaticInteropMock, this bridges the
gap of js_util.
Adds:
- instanceOfString from js_util as an extension methods
- JSObject constructor to replace js_util.newObject
- Unnamed factory constructor to JSAny so users can't extend it
Fixes:
- JSArray.withLength to take an int
- typeofEquals to take a String and return a bool
- instanceof to return a bool
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I7db1651f641a4fc84392957dfa7ad64904f110e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326691
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
null and undefined cannot be distinguished on dart2wasm in its
current state, so these helpers should only work on the JS
compilers. Some comments are updated to reflect the current state
of this internalization. Also fixes a pending TODO in isNull and
isUndefined on the JS backends.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ic56e8aa346af99cb99d01fe3c7ac5e37e965db23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326690
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds Future.toJS that creates a Promise using a Dart callback.
Resolving is simple as we just pass the value (if any). Rejection
boxes the error and stack trace and sets them as properties of
a JSObject, which is then passed to the reject function.
Also adds:
- JSPromise constructor
- JSFunction.callAsFunction helper
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: If2ce8018a2c8b3c4dc5d5af710c9bb4c2f688f87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326689
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
We rely on the result of the `ConstantVisitor` to indicate whether we have an error or a valid constant value.
This CL changes `evaluationResult` to be a `Constant` and changes error reporting to occur at a POE for evaluating a constant.
Last few chunks of cleaning up the constant evaluator, woo!
Change-Id: Icd41a4fcbab0626df36c6a83cd60ecbb59c2dcf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324573
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Then callbacks should accept and return a JSAny?. Some JS types tests
were incomplete as well.
Change-Id: Id46e2a53f8f83ce17247fbd23d5be82f3f986f30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326688
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Now that the canary configurations are more reliable we can start
running these tests again. They were originally skipped when the
async implementation in the new type system was not working correctly.
The `web/async_stacktrace_test` has actually been timing out in the
stable configs as well. The timeout is consistent and reproducible
locally so I'm filing a new issue and skipping it on all DDC configs
for now.
Fixes: https://github.com/dart-lang/sdk/issues/50666
Issue: https://github.com/dart-lang/sdk/issues/53555
Change-Id: I7306ba66afe595fb213f06c0ad884d376240addc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326721
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is a reland of commit 54522db98f
Original change's description:
> [dart2wasm] Fix nullable JS type and int parameters in JSFunction
>
> When a callback is toJS'd with an int parameter, we should attempt
> a conversion to int if possible, similar to return values on
> external functions. Similarly, parameters where the expected type is
> a JS type should check to make the value isn't nullish before boxing,
> as JS null and undefined are converted to Dart null.
>
> Tests are added for conversion semantics of JSFunctions.
>
> Change-Id: I95566c2954d915b8cf31cdc55fed359c695404f2
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323445
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change-Id: I36ec7702b1e08fc9e4d6290952ae548b0e074ee3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325971
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit 2a669c571f.
External APIs when using dart:js_interop should only allow
primitives, JS types, and other static interop types. This
was previously checked in a more restrictive mode called
"strict mode" but is not checked everywhere where dart:js_interop
APIs exist.
Change-Id: I1a8d04071a519c4965b266eb2800bcc3c3bb8393
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325961
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Bug: b/286184681
Change-Id: I903528c4adfbc576644aec7541903df6b9633e26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325523
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Per breaking change request we are now disabling
waitFor by default.
Users can still enable it by passing the flag:
--enabled-deprecated-wait-for
Issue https://github.com/dart-lang/sdk/issues/52121
TEST=standalone/io/wait_for_deprecation_test
CoreLibraryReviewExempt: standalone VM only change
Change-Id: Ied78f91344d15cb77e932514e2b752bb6ac5dc5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326021
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Revert submission 323446
Reason for revert: This breaks flutter web engine unit tests. See https://github.com/dart-lang/sdk/issues/53521
Reverted changes: /q/submissionid:323446
Change-Id: I9095f0791a556d4bc912e29fde274f3cb8824317
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325964
Commit-Queue: Jackson Gardner <jacksongardner@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Strings are the most likely use case of getting and setting
properties, and therefore we should make that easier to use.
This CL also renames the extensions in dart:js_interop_unsafe
to a more relevant name and to avoid conflicts in dart:js_interop.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ia8ce6593167c648f9710b47cfe27f80c854be407
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324572
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The library code and the intrisic code disagreed about the capacity of the result digits array. Compare similar adjustment for <<.
TEST=ci
Change-Id: I81395a242965d53de3a30f87637a6f1588300969
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325122
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 2a669c571f.
Reason for revert: Failing dart -> Flutter Engine roller. We need to make some changes on the engine side to prepare for re-enabling these checks.
Original change's description:
> [dart:js_interop] Re-enable type checks on external APIs
>
> External APIs when using dart:js_interop should only allow
> primitives, JS types, and other static interop types. This
> was previously checked in a more restrictive mode called
> "strict mode" but is not checked everywhere where dart:js_interop
> APIs exist.
>
> Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I54caf06976e215b2b576cedfc0013ee79c6682f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324902
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Optimize repetitive calls to isSubtype with a caches to store pairwise
results.
There are currently two caches for sound and unsound results but in the
future that can be combined into a single cache once the library is
aware of error reporting. That single cache could stores "pass", "fail",
or "fails when sound mode but passes in unsound null safety".
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I49e5794703fd58f1b2bba50e426e25146800fbb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323707
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
When the CFE compiles code for DDC or dart2wasm, it lowers late final
fields to synthetic getters. In order to ensure that accesses to these
fields can still be type promoted, a flag is added to the kernel
`Procedure` class, to indicate that a getter was produced by lowering
a late final field. When deciding whether a property access is
promotable, the CFE checks this flag; if it's set, it treats the
getter like a field.
Includes a language test validating the fix.
Fixes https://github.com/dart-lang/sdk/issues/53462.
TEST=tests/language/inference_update_2/late_field_test.dart
Change-Id: I98b81f04a3342d851060e5b2a7265323b93bb4e3
Bug: https://github.com/dart-lang/sdk/issues/53462
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324767
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Adds a conversion function on List<JSAny?> so that users can
modify the original list and have those changes carry forward
to the array. Creates a proxy object for dart2wasm when the
list is not a JSArrayImpl. This proxy uses handler methods and
the fact that Array methods are generic to provide an Array
interface. Also fixes a small issue in the exporting so that
toJS'd function types have a valid return type.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I00f453aa82dd19f2913820579eb2675b799288d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323446
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When a callback is toJS'd with an int parameter, we should attempt
a conversion to int if possible, similar to return values on
external functions. Similarly, parameters where the expected type is
a JS type should check to make the value isn't nullish before boxing,
as JS null and undefined are converted to Dart null.
Tests are added for conversion semantics of JSFunctions.
Change-Id: I95566c2954d915b8cf31cdc55fed359c695404f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323445
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This is a reland of commit ebc96ecb83
Angular codegen emits members that are external so DDC's external
checks need to be more specific to only focus on JS interop. This
also modifies some code logic around whether a member is JS interop
to be less permissive. Before, it claimed that any member is JS
interop if it's external and the enclosing library has a @JS
annotation, but this is only true if there is no surrounding class.
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id48337ac4980d9de5de03d895d93cad3ab3a1808
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324542
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit ebc96ecb83.
Reason for revert: breaks G3, b/299279625
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id1af7f71e80b22b48343c1d918b9431afaf6aaf4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324521
Commit-Queue: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
External final fields are equivalent to getters whose implementation
is provided outside of Dart code. As such they're not guaranteed to be
stable, so they shouldn't be promotable.
It turns out that the CFE was already correctly classifying them as
non-promotable (because it de-sugars them into getters prior to
computing promotability). This CL fixes the analyzer.
Fixes https://github.com/dart-lang/sdk/issues/53426.
Bug: https://github.com/dart-lang/sdk/issues/53426
Change-Id: Icdd897cdbdf0da0a69ea704a245c0b428070b95e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324340
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
DDC passes type args as the first args for a generic function
invocation, but interop functions should be excluded from doing
so, as this leads to passing type args to JS functions.
Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
External APIs when using dart:js_interop should only allow
primitives, JS types, and other static interop types. This
was previously checked in a more restrictive mode called
"strict mode" but is not checked everywhere where dart:js_interop
APIs exist.
Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Static invocations of external factories are casted so that the
result, which is a @staticInterop type, can be treated as the erased
type instead. This CL fixes the issue where the type that it was
casted to was never replaced with the erased type.
Change-Id: Ic6eb529349ea2b5c42f91c2740d501d4f81bc38e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323505
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Add a more specific, but for general use, diagnostic for when the evaluator encounters a type parameter. The errors should match more closely to the CFE errors now.
This CL also tidies up some other areas like `_evaluatePropertyAccess` and produces a better error than `INVALID_CONSTANT` when you try to access something that's not String.length.
Change-Id: I4780e6e52049887a0ee44cdf046968f332527079
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322364
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Cycles were not previously reported because constructors don't have an
evaluation result (since it depends on the invocation arguments).
This CL uses the ConstantVerifier to check every constant constructor.
Fixes https://github.com/dart-lang/sdk/issues/46735
Bug: https://github.com/dart-lang/sdk/issues/46735
Change-Id: Ie8419787b621abb303ecc738aa36f2e7abf96a38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317841
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When entering visiting a subpattern of an object pattern, the flow
analysis engine now updates `_FlowAnalysisImpl._scrutineeReference` to
a `_PropertyReference` referring to the property being matched; this
ensures that if the subpattern match implies a type promotion, and the
property in question is promotable, the type promotion will be applied
to the property.
Also, if the property has already been promoted at the time of entry
to the subpattern, the promoted property type is used as the matched
value type.
Includes unit tests and language tests for the new functionality.
Fixes#53100.
Change-Id: I6d28e9a7d188bf1136e8517d6aa06af3b4c31c69
Bug: https://github.com/dart-lang/sdk/issues/53100
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Treat the loop update marker more like an ordinary symbolic value. The old symbolic marker attempted to do widening 'on the fly', which could lead to incorrect results when the update could reset the value to a constant lower than the starting value. The new version moves the widening to a single place, at the loop update.
Fix#53355 by caching intermediate results so that long chains of diamond control flow are not explored exponentially.
There are very few changes in apps. There is one change in a Flutter app that is like the changed codegen/value_range_test where the bounds check can be eliminated because the loop index may be decremented, but not more than the increment, so is still weakly monotonic. There is one change in a large ACX app where a lower bounds check is no longer removed but I *think* it was previously removed incorrectly, though it is hard to tell since it is in a huge function.
Issue: #48465
Issue: #53078
Issue: #53355
Change-Id: Ib125cd6bb30cef52f8dfcd53eaa13e439f26316c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322594
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The CFE's lowering for record patterns can sometimes make use of late local fields. Dart2JS's late lowerer assumes that all late local fields live in the scope of some function body. Record patterns allow late locals to be created in other contexts though. Some examples that break this assumption include field initializers and expressions in constructor initializer lists.
To fix this we add a late local scope in some extra contexts where these record patterns can show up.
Fixes: 53358
Change-Id: If43b4dd393d0249e6557a54e6e455d52b39e97c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323020
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Prior to this change, the SSA node stored in `PromotionModel.ssaNode`
was only correct for promotion models that represented variable
references. If a promotion model represented a promotable field, its
`ssaNode` pointed to a bogus SSA node. This had two undesirable
effects:
- It meant that `FlowModel.rebaseForward` needed to contain a hack to
prevent it from looking at the bogus SSA node for a promotable
field, and falsely concluding that the field's value had been
reassigned (which is impossible for promotable fields)--see
https://dart-review.googlesource.com/c/sdk/+/321752.
- It meant that if a promotable field was used as a scrutinee in a
refutable pattern match, the promotion logic would look at the bogus
SSA node for the field, and falsely conclude that its value had been
reassigned, preventing field promotion from working during pattern
matching.
This change ensures that the correct SSA node is always stored in
`PromotionModel.ssaNode`, and removes the hack in
`FlowModel.rebaseForward`. This required some re-ordering some of the
logic for control flow joins, to ensure that when a join creates a
fresh promotion model for a property, it has already created the
corresponding `_PropertySsaNode` (previously, it created the
`_PropertySsaNode` afterwards, but that is too late since the
`PromotionModel` class is immutable).
Unit tests and language tests are introduced to validate the newly
fixed behavior for promotable fields used as a scrutinee in a
refutable pattern match.
Also, the uses of `FlowModel.infoFor` in queries such as
`getMatchedValueType`, `isAssigned`, `isUnassigned`, and
`promotedType` were changed to simple map lookups, to prevent bogus
SSA nodes from being created and then immediately discarded. This
resulted in a fairly significant boost to CFE compilation speed:
page-faults:u: -1.2664% +/- 0.1535% (-2531.33 +/- 306.73)
instructions:u: -0.6210% +/- 0.0009% (-119891846.00 +/- 180585.35)
branches:u: -0.6765% +/- 0.0014% (-26637478.67 +/- 54272.64)
branch-misses:u: -0.9562% +/- 0.8909% (-548444.00 +/- 510991.65)
Change-Id: I30f82e8a4ba11236735258077d61d36717fa32c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322443
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Skip `_NativeCallableIsolateLocal` in the fuzz test so that we have
coverage for the other things again while investigating.
Bug: https://github.com/dart-lang/sdk/issues/53350
Change-Id: I67d8657f965dee5338fd9286a9f1fd935559d585
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322662
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
When the result of an `is` test or null check is stored in a boolean
variable, and later recalled for use in flow control, the flow models
that were computed at the time the variable was stored need to be
updated to reflect any further change to flow state that happened
between the test and the usage. This is done by
`FlowModel.rebaseForward` method. `rebaseForward` takes two flow
models as input: `this`, which represents the flow state that was
computed at the time the condition variable was stored, and `base`,
which represents the flow state at the time the condition variable is
recalled.
Flow analysis adds promotion keys for variables to the flow state at
the time their declarations are encountered, and in certain
circumstances removes them after they go out of scope. But for
properties, it only adds promotion keys when the promotion occurs. So
prior to the addition of field promotion, if `this` contained a
promotion key that wasn't present in `base`, that could only mean that
the promotion key was associated with a variable that had gone out of
scope; accordingly, it was safe for `rebaseForward` to simply ignore
that key. (It did so implicitly, by only ever examining the promotion
keys in `this`). But with the addition of field promotion, it is now
possible that the promotion key represents a property that was
promoted in `this`, and hence the promotion needs to be kept. This CL
adds the necessary logic to keep the promotion.
In addition, there is a subtle difference in the relationship between
the `PromotionModel` and `SsaNode` data structures for local variables
versus properties. For local variables, the promotion key is
determined solely from the variable name; then, this promotion key is
looked up in the current `FlowModel` to obtain a `PromotionModel`, and
the `PromotionModel` contains a prointer to the `SsaNode`. For
properties, the property name is looked up in the
`promotableProperties` map of the parent `SsaNode`; this points to a
`_PropertySsaNode`, which contains the promotion key, and when this
promotion key is looked up in the current `FlowModel` to obtain a
`PromotionModel`, that `PromotionModel` contains a pointer to a bogus
`SsaNode`.
For local variables, the `SsaNode` pointed to by the `PromotionModel`
is important, because if it's different between `this` and `base`,
then the variable in question received a new value between the time
the condition variable was stored and the time the condition variable
was recalled; therefore the promotion should be disregarded. However,
for properties, the `SsaNode` pointed to by the `PromotionModel` is
bogus, so if it's different between `this` and `base`, that shouldn't
block promotion. This CL adds the necessary logic to avoid the
`SsaNode` check for properties.
This situation is very confusing so I've added more detail to the
comment above `PromotionModel.SsaNode` explaining it. In a future CL I
will try to clean up the confusing situation by eliminating the bogus
`SsaNode`s pointed to by `PromotionModel`s for properties.
Fixes https://github.com/dart-lang/sdk/issues/53273.
Bug: https://github.com/dart-lang/sdk/issues/53273
Change-Id: I1d528e25de1eb2ed63d0ee1a00faa5ad5b5061ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321752
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that ddc, dart2js, and dart2wasm are consistent on toString outputs
for JS objects, we should test to make sure this behavior doesn't
regress.
Change-Id: I2b1b4819e5a2425ae813dc944a4dea7b2147d5bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322365
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Some errors like type checking of fields should be reported directly, so this CL separates these errors from evaluation exception errors. This reverts some changes we have before.
Additionally, we move error reporting for the constructors to an outer-most method to avoid reporting multiple times.
Change-Id: Ie2fde0ea7d389a633051cb106012a0738354f821
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319911
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Some of these is checks can be optimized away by dart2js.
Change-Id: I76b5b253a24a4ded2394664985665fc875b60f52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321750
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds JSSymbol and JSBigInt and erases to either their respective
interceptor types in the JS backends or JSValue in dart2wasm.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ib2c70d22a70c6308733cd170b91eafa8ec3b3aeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321749
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds the same interceptors from dart2js as JsPeerInterfaces
and handles typeof differences in getReifiedType. These must
be JsPeerInterfaces so that Object members can be stored in
their prototype. Tests are added so that dart2js and ddc are
consistent.
Change-Id: Iadc3dd26957c0a21b4039c49c1c1ff162ae286e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321748
Reviewed-by: Stephen Adams <sra@google.com>
Try/finally statements have an unusual property that needs to be
handled in a special way by flow analysis: within the `finally` block,
the `try` block might not have run to completion, but after the
try/finally statement, the `try` block is known to have run to
completion. Therefore, even though the code that follows the
try/finally statement is immediately preceded by the end of the
`finally` block, the flow states of those two control flow points
might not be the same.
Flow analysis accounts for this situation by analyzing the `finally`
block as though it started executing right after the beginning of the
`try` block, but with all variables that are written within the `try`
block demoted. Then, after it finishes analyzing the `finally` block,
it builds a fresh flow model by starting with the flow state after the
end of the `try` block, and then applying any promotions that were
performed within the `finally` block. This is accomplished by the
`FlowModel.attachFinally` method.
The following changes had to be made to make this work with field
promotion:
- If a given promotion key appears in the "after try" model but not
the "after finally" model, it might represent a field that was
promoted during the `try` block, so the promotion needs to be
preserved. Previously, this situation could only occur if the
promotion key represented a variable declared in the `try` block
(and therefore the variable would not be accessible after the
try/finally statement), so the promotion could be safely dropped.
- If a given promotion key appears in the "after try" model and the
"after finally" model, but not the "before finally" model, it might
represent a field that was promoted within both the `try` and
`finally` blocks, so the promotions need to be combined. Previously,
this situation could not occur, so the promotion could be safely
dropped.
- If a given promotion key is associated with the same SSA node in the
"before finally" and "after finally" models, but a different SSA
node in the "after try" model, that means that the corresponding
variable was assigned in the `try` block but not in the `finally`
block. If any properties of the variable were promoted within the
`finally` block, those promotions were applied to the SSA nodes used
by the `finally` block, and don't appear in the SSA nodes used in
the "after try" model. So those promotions need to be
transferred. This is accomplished by the new
`SsaNode._applyPropertyPromotions` method.
- If a given promotion key appears in the "after finally" model but
not the "after try" model, it might represent a field that was
promoted during the `finally` block, so the promotion needs to be
preserved. Previously, this situation could only occur if the
promotion key represented a variable declared in the `finally` block
(and therefore the variable would not be accessible after the
try/finally statement), so the promotion could be safely dropped.
Fixes https://github.com/dart-lang/sdk/issues/53225.
Bug: https://github.com/dart-lang/sdk/issues/53225
Change-Id: Ie4b635dbf838447d6964c326e1ecebfff99bed8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320961
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The underlying subscription would invoke the `onDone` handler even
after a `cancel`.
It also forgot to register the `onDone` callback in the zone before
running it.
Tweaked the behavior of `pause` and `resume` to make sure they make
no difference after `cancel` or after a done event has been omitted.
(Test now checks that the behavior matches other streams.)
Fixes#53201
Bug: https://dartbug.com/53201
Change-Id: Iba35be2c4b44b5c4ec97d5a4dbcd3aff7fee8b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320561
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
We seem to be overreporting these two errors in the const case. I'm changing it so we don't report the general field initializer error when there's a const constructor.
Change-Id: Ib7ad3be2cace08cb6c9374fa71263155497a908f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320940
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This is likely more useful than returning globalThis always. It
allows users to workaround issues with lowerings without having
to worry about browser compatibility differences.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I01479211fe6b573c845de5b134d36338c40fc10d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319301
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Extension type factories are added to the language, so they
should be tested. Also fixes a small issue on detecting
tear-offs.
Change-Id: I8d2b374830e4ac11783d10d3b75221544ee9ef3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318160
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Does several refactorings now that inline class -> extension type:
- InlineExtensionIndex becomes ExtensionIndex
- Comments mentioning inline classes now reference extension types
- Tests are moved to extension types
- Errors now reference extension types instead of inline classes
Change-Id: I26ede8e3aaf6bba5f73847238edeed266fc6a043
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317805
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Tests class type parameters and local type parameters that are
bound to both JS types and static interop types.
Also moves and refactors a test on external extension members to
static_interop_test so that dart2wasm runs it now.
Change-Id: I6b407455d853d3d85b3d58abafdd23e6b2a03977
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316866
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Flow analysis implements field promotion using an extension of SSA
(static single assignment) analysis.
In traditional SSA, an analysis phase assigns a collection of SSA
nodes to each local variable in the program, such that each SSA node
represents a region of control flow in which there are no assignments
to the variable, and no control flow joins that might affect the
variable's value. Each local variable read expression is therefore
associated with an SSA node, establishing the invariant that two reads
that share the same SSA node are known to produce identical results.
In flow analysis, SSA nodes are also assigned to property get
expressions, with a similar invariant: two property gets that share
the same SSA node are known to produce identical results. To ensure
soundness, flow analysis generally only considers a property get
expression to be promoted if the get has the same SSA node as a
previous type test.
There's an exception, though: if a property get is associated with an
SSA node that arose from a control flow join, it may be appropriate to
consider it promoted, if the SSA nodes that were joined are both
considered to be promoted. For example, consider the code below:
class C {
final int? _i;
C(this._i);
}
f(bool b, C c1, C c2) {
C c3;
if (b) {
c3 = c1;
if (c3._i == null) return;
} else {
c3 = c2;
if (c3._i == null) return;
} // (1)
print(c3._i + 1); // (2)
}
At (2), it makes sense to consider `c3._i` to be promoted, because
`c3._i` was type checked in both control flow paths leading up to the
join point at (1). However, since those two control flow paths contain
different assignments to `c3`, at the time that the join point (1) is
analyzed, flow analysis assigns a fresh SSA node to `c3._i`, distinct
from the two SSA nodes that were type checked.
To ensure that the promotion is preserved, a new method is introduced,
`SsaNode._join`, which creates the fresh SSA node and updates the
newly created flow model to preserve the promotion. The bulk of the
heavy lifting is done by `SsaNode._joinProperties`, which recursively
walks the `_promotableProperties` maps of the two SSA nodes being
joined, creating fresh promotions for all the properties that should
have their promotions preserved.
This required plumbing some new parameters through
`VariableModel.join` (which calls `SsaNode._join`), so that
`SsaNode._joinProperties` can find the promotion information along the
two incoming control flow paths, and can create fresh promotions for
the outgoing control flow path.
Fixes https://github.com/dart-lang/sdk/issues/53146.
Change-Id: I6e53b3363ab5d769bef1b96f0ccd380fa2ca39df
Bug: https://github.com/dart-lang/sdk/issues/53146
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
There are many failing Dart2JS language/library tests due to differences in backend implementations.
We want to adopt a strategy that allows us to make explicit the different expectations we have of each backend.
This adds logic for the 2 most common causes of these backend related failures (numbers and implicit checks) but we can add more of these as we discover more use cases.
This is an iteration on https://dart-review.googlesource.com/c/sdk/+/293463 attempting to integrate feedback from that change.
Change-Id: Ie3a1954066199695d92881497e940385467c9a12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311780
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Previously, the flow control logic for patterns didn't use the
`FlowModel.split` or `FlowModel.unsplit` methods at all. This meant
that if a control flow join point occurred in pattern logic, flow
analysis would consider the split point to be whatever split point was
established by the enclosing expression or statement. In the case of
an if-case statement, it would consider the split point to be at the
beginning of the scrutinee expression.
Split points are used by flow analysis for the sole purpose of
ensuring that joins propagate type promotions the same way in dead
code as they do in live code (so that users introducing temporary
`throw` expressions or `return` statements into their code do not have
to deal with nuisance compile errors in the (now dead) code that
follows. The consequence of flow analysis considering the split point
to be at the beginning of the scrutinee expression is that if the
scrutinee expression is proven to always throw, then joins that arise
from the pattern or guard may not behave consistently with how they
would have behaved otherwise. For example:
int getInt(Object o) => ...;
void consumeInt(int i) { ... }
test(int? i) {
if (
// (1)
getInt('foo')
case
// (2)
int()
// (3)
when i == null) {
} else {
// (4)
consumeInt(i);
}
}
In the above code, there is a join point at (4), joining control flows
from (a) the situation where the pattern `int()` failed to match, and
(b) the situation where `i == null` evaluated to `false` (and hence
`i` is promoted to non-nullable `int`). Since the return type of
`getInt` is `int`, it's impossible for the pattern `int()` to fail, so
at the join point, control flow path (a) is considered
unreacable. Therefore the promotion from control flow path (b) is
kept, and so the call to `consumeInt` is valid.
In order to decide whether to preserve promotions from one of the
control flow paths leading up to a join, flow analysis only considers
reachability relative to the corresponding split point. Prior to this
change, the split point in question occurred at (1), so if the
expression `getInt('foo')` had been replaced with `getInt(throw
UnimplementedError())`, flow analysis would have considered both
control flow paths (a) and (b) to be unreachable relative to the split
point, so it would not have preserved the promotion from (b), and
there would have been a compile time error in the (now dead) call to
`consumeInt`.
This change moves the split point from (1) to (2), so that changing
`getInt('foo')` to `getInt(throw UnimplementedError())` no longer
causes any change in type promotion behavior.
The implementation of this change is to add calls to `FlowModel.split`
and `FlowModel.unsplit` around all top-level patterns. At first glance
this might appear to affect the behavior of all patterns, but actually
the only user-visible effect is on patterns in if-case statements,
because:
- In switch statements and switch expressions, there is already a
split point before each case.
- In irrefutable patterns, there is no user-visible effect, because
irrefutable patterns cannot fail to match, and therefore don't do
any control flow joins.
This change allows the split points for patterns to be determined by a
simple syntactic rule, which will facilitate some refactoring of split
points that I am currently working on.
Change-Id: I55573ba5c28b2f2e6bba8731f9e3b02613b6beb2
Bug: https://github.com/dart-lang/sdk/issues/53167
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319381
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With this change the Dart Core Object members (`.hashCode`,
`.runtimeType`, `.noSuchMethod()`, `.toString()`, and
`operator ==`) are no longer installed onto the native JavaScript
Object prototype. This is done because the Object prototype will be
sealed as a security precaution in some environments to avoid
prototype pollution exploits.
This means that dispatching to these APIs will change when the
compiler cannot know if the receiver may be null or a value from
JavaScript interop. In those cases a call to a helper method is
inserted instead. The helpers will probe for the API on the value,
call it if available or execute a default version.
NOTE: Many other native JavaScript prototypes are still modified. This
change is only for the Object prototype.
Issue: https://github.com/dart-lang/sdk/issues/49670
Change-Id: Iddb3a48e790dd414aa3254d729535c4408e99b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310971
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The interceptors provide a Dart `toString` method that uses the JavaScript `toString` method.
Issue: #53106
Change-Id: I1cf1df9e24fb4fd2d79679f1f014f39f083be7e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319563
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@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>
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>
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>
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>
Using setProperty triggers assertInterop, which prevents a Dart
Function from being boxed.
Change-Id: Ifa8a068abb7191ccb1c50f2733e6d85df411c945
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317847
Commit-Queue: Joshua Litt <joshualitt@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The uses the #type handle to pass the DartType in the message rather
than using the toString() method which doesn't give the desired result.
Change-Id: Iac17507643a9932570d5975a106a3ededc03f58c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316585
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Since external APIs can only use primitives and JS types in static interop,
we should require that all type parameters on static interop APIs extend
another static interop type. This is the minimum required to ensure all
type parameters can be erased to JSValue. This only affects dart:js_interop
users and replaces the previous type parameter static error check.
Change-Id: Ia546874da73c808aa25deb8d54d581db783987df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316140
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This change is almost trivial. The closure is stored on the callback's
RawReceivePort, not in the VM. So we can basically just remove the CFE
check and it pretty much works. The only problem is that we can't set
function.FfiCallbackTarget anymore, so most of the CL is dealing with
that.
A few places were deciding whether an FFI trampoline was a call or a
callback based on whether function.FfiCallbackTarget() was null. But
now the target will be null for async callbacks. So instead I've added
a new value to the FfiCallbackKind enum (and renamed it), and changed
those checks.
Sync callback closures will be a separate CL, because they're more
complicated.
Bug: https://github.com/dart-lang/sdk/issues/52689
Change-Id: I8e5dfb557362e679f66195b735c3c382e6792840
TEST=async_void_function_callbacks_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316160
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
evaluateConstructorCall now returns a Constant, which means evaluation may be cut early in some places if there's an error. However, some code generators rely on _InstanceCreationEvaluator to complete, and so there's no _major_ changes to the design right now (and some small additions to avoid breaking many tests).
This CL is just the framework for the "return Constant" design and will be the base for reporting better errors in constructor invocations.
These changes already show that we cut some amount of over-reporting in our existing language and unit tests, which is a step in the right direction.
Bug: https://github.com/dart-lang/sdk/issues/47603, https://github.com/dart-lang/sdk/issues/47351, https://github.com/dart-lang/sdk/issues/49389
Change-Id: I5ba7f1282658884c18a32d5e98c7804bbfeac0f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312347
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The tests `variable_property_not_promoted_test` and
`this_property_not_promoted_test` verify that fields are _not_
promoted. To prevent them from failing when we enable the language
feature `inference-update-2` (which provides field promotion), they
need `@dart=3.0` directives. This ensures that we will continue to
have coverage of the old (non-promoting) behavior after field
promotion is switched on.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I376da01dfe4223f17ae4863e4460b4f1a0708dc6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314760
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the new type system, allow native types that have a "peer" on
the Dart side to use that Dart type as their reified type.
This matches the semantics of the old type system for these types.
Change-Id: I62bf6cb1654d33549a6ea2c757e7e65fa81677a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313700
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is a reland of commit 16fcfe7eae
Original change's description:
> [dart:js_interop] Remove Object.toJS and JSNumber.toDart
>
> Modifies JSBoxedDartObject reified type on JS backends and also
> modifies JSBoxedDartObject.toDart now that a proper box is introduced.
> Also uses a JS symbol in JSBoxedDartObject.toDart for a property
> check so that different Dart apps don't accidentally share Dart
> objects. It's now an error to call this function on non-boxed objects.
>
> Fixes a type issue where creating a new object literal with the JS
> foreign function was resulting in dart2js thinking toJSBox would
> always throw. Changing the typeDescription to PlainJavaScriptObject
> instead of =Object fixes that issue.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: If6b190f12bdf840b0259c5739f50d9bdcd27fd47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313600
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
While rereading the analyzer logic that decides whether to suppress
field promotion due to the presence of a `noSuchMethod` forwarder, I
found a few corner cases that aren't handled correctly:
- The logic for deciding which fields are included in a class's
implementation currently doesn't understand that an abstract field
is abstract; it treats it as a concrete field, therefore if a
concrete subclass implements of `noSuchMethod`, but fails to
implement the field, the analyzer fails to detect that there will be
a `noSuchMethod` forwarder (and thus fails to suppress promotion).
- The logic for collecting the set of fields (and getters) that are
included in a class's interface (or implementation) currently stops
at a library boundary, so it doesn't properly handle the situation
where there is a library cycle, and two classes in one library are
related through an intermediate class in some other library.
- The logic for collecting the set of getters that are included in a
class's interface currently ignores the `on` clauses of mixins.
This CL includes tests for all these corner cases; I will fix them in
a follow-up CL.
Change-Id: I92d73c0643f1ab89144feefab68779418a2c7a35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313840
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change doesn't seem to have a significant impact on most compilation results:
- Golem results show no significant difference in microbenchmarks.
- For a medium and large app tested, while we see a small change in the actual inference results, the generated code is identical before/after this change.
- Timing and memory usage on internal compilations seem comparable before/after this change.
Note: This replaces the need for any notion of "invalid" refines so I will clean up that code in a follow up change.
Change-Id: I2a293eacd944fc17ee2dab97d3d947c042b4038f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313720
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This reverts commit 16fcfe7eae.
Reason for revert: Flutter changes haven't landed to google3 yet.
Original change's description:
> [dart:js_interop] Remove Object.toJS and JSNumber.toDart
>
> Modifies JSBoxedDartObject reified type on JS backends and also
> modifies JSBoxedDartObject.toDart now that a proper box is introduced.
> Also uses a JS symbol in JSBoxedDartObject.toDart for a property
> check so that different Dart apps don't accidentally share Dart
> objects. It's now an error to call this function on non-boxed objects.
>
> Fixes a type issue where creating a new object literal with the JS
> foreign function was resulting in dart2js thinking toJSBox would
> always throw. Changing the typeDescription to PlainJavaScriptObject
> instead of =Object fixes that issue.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I469ad04db7b49ffef47a46ccac97e909e4865719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313580
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Modifies JSBoxedDartObject reified type on JS backends and also
modifies JSBoxedDartObject.toDart now that a proper box is introduced.
Also uses a JS symbol in JSBoxedDartObject.toDart for a property
check so that different Dart apps don't accidentally share Dart
objects. It's now an error to call this function on non-boxed objects.
Fixes a type issue where creating a new object literal with the JS
foreign function was resulting in dart2js thinking toJSBox would
always throw. Changing the typeDescription to PlainJavaScriptObject
instead of =Object fixes that issue.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
A user found another case where this fails (b/290868787).
In this case a ForwardingTypeMask is delegating the subtyping checks to its `forwardTo` mask which ends up saying the masks are equal even though the wrapper around the forwarded masks means they are not equal.
Change-Id: I015f2faf57557ff4189acb6c7144d09cf1ae6bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313341
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
And give test more time in tsan.
Bug: https://github.com/dart-lang/sdk/issues/52917
Change-Id: I1342612470d63233b265dc9063b0335ec8bef760
Cq-Include-Trybots: luci.dart.try:vm-tsan-linux-release-x64-try,vm-aot-tsan-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313383
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Currently this throws a Wasm RuntimeError, which is difficult to
recover from.
Change-Id: I747682d6959b19746d6c98f2ea1b3fefd1ed2d03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312891
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Makes the TSAN skips apply to
`test.py -mrelease --sanitizer=tsan`
and not just
`test.py -n vm-tsan-linux-release-x64`.
Also makes the timeouts agree.
Change-Id: I10315e754a4ebb3020f3c2f6cecfac6b77e77a9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311828
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
I still haven't found yet the fix for this, but might as well add the regression
test for it.
Change-Id: I84821f6615a26faf95e6f7c498aa3670f5d48a54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312701
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
