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>
