Currently, dart:_js_types types are all typedefs in the web backends.
This leads to inconsistent semantics, since you can statically pass
Strings to JSString, for example. You cannot do this in dart2wasm.
In order to ensure consistent semantics, we reify these types using
a custom @staticInterop lowering. They all get erased to their
respective Dart type. When we have inline classes, these types
should be implemented using inline classes.
Note that Interceptor will not work for this use case. The reified
type of JS primitives are Dart types e.g. String, bool, and therefore
can not be casted to Interceptor.
In order to do this, the eraser is refactored and the JS backends use
shared erasure code to either erase/emit types.
Tests are added to make sure you need to go through a conversion or
cast to pass Dart objects to JS types.
CoreLibraryReviewExempt: Backend-specific internal library changes.
Change-Id: I5942be628102919ec167f094cfe10fced606363c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295105
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These tests have been broken (and disabled) for a while. This pull-request fixes the tests and re-enables them.
Bug: #47052
Change-Id: Ib8c83959e5f00a2a5dc29959f87adbaa963385fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296863
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
current library which itself extends a base declaration from another
library.
Change-Id: I3caf125de528d5c082c825c02055a114f732f385
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298040
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This test was inadvertently broken when automatically migrated from a
multitest to a static error test.
The original intent of the test was to ensure that web compilers
reported compile-time errors on integer literals that couldn't be
represented as JS doubles. The migrated static error test doesn't have
any web expectations and thus doesn't get run on web compilers at all.
Instead, all it does is validate that the one non-web error in there is
reported.
This turns the test into a proper *web* static error test with the
web-specific test expectations in there. That ensures the test is run
on web compilers and validates that the web compilers produce those
expected errors.
Also removed the corresponding runtime test since it doesn't do
anything. There's no runtime behavior to test, and the static error
test also correctly validates that the *valid* integer literals do *not*
produce compile errors.
Removed the status file entries because they're no longer needed. Since
this is a static error test, the runtime platforms already skip it
implicitly.
Change-Id: I2776847e1acb88b1f761efb43e7bb528b27d0eee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297840
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Previously this step happened during `buildOutlineNodes`, but since
`buildOutlineNodes` happens in source order, this means that anonymous
mixins would only get their sealed and final attributes properly
inferred if they appeared *after* their immediate supertypes in source
order. By moving this step to `checkSupertypes`, we ensure that the
computation is correct regardless of source order, because
`checkSupertypes` happens in class hierarchy order.
Fixes#52048.
Bug: https://github.com/dart-lang/sdk/issues/52048
Change-Id: Ib9f1f3dafded88681a26f09e4d21dfd44e70dfd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297901
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL replaces https://dart-review.googlesource.com/c/sdk/+/296900
The `List` constructor is removed in Dart 3.0.
Some of the `@patch` implementations were not removed.
This is *high priority*. It seems the left-over `@patch factory List` constructor did not cause any errors, instead it *added* a constructor to `List` that can be used in web compiled code. Even if `List` doesn't have such a constructor in the SDK code proper.
The VM and analyzer will say the invocation is an error, but dart2js happily compiles it and runs.
(It used to be that patches couldn't add public members, that security seems to have been removed.)
Also removes code which tries to detect "the unnamed List constructor",
which is no longer a thing, and a number of invocations of the constructor, where it's not clear that the test is aware that the constructor no longer exists, and is not marked as `@dart=2.x` with x < 12.
TEST=ci
Change-Id: I4ffaf3ae2c4e75ca06e7ba0bf19187b6376f3888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297100
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I3a41bb83767052abda1fdfc77e21bd1a83188482
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296441
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I35d4a7c7ad09cb77ff379af036180794d8b6afbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296403
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: Idf9012cb8c213b523d1c8bb827e530e0d2cf6609
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296407
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I4c2840deffe5d790a22facebbcc8a02c1cb98020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296425
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
State more explicitly that sealed classes are abstract and lead the
user to a better fix with the error message.
Bug: https://github.com/dart-lang/sdk/issues/52073
Change-Id: Id24c6cb187ee5497ca2819f930c48ff5aa8d07fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296025
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I3e10209e78e48893d2f2df7f8af7963d319efd9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296405
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I6218c6ea339b6c19c1495b1db9b2da3fe1654718
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296440
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
Change-Id: I6564643302f66c5920b38d2269c160099322560b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296421
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
Also fix a test to use a mixin declaration instead of a class for declaring a mixin. This was
broken by class modifiers but the breakage was masked by @compile-error treating a test as
passing if any compile error, even an unrelated one, is reported.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I5d1d387002d886cb87340e2559bf8ed01c3f2d6a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296409
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I5dd012381390ef2c00d674308db3fe099ecc6a4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296423
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I65c446e00b25239960d421489e6cf87a88d875d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296408
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Since we no longer only do lowerings at the declaration site, the
InlineExtensionIndex class needs to handle libraries besides the
current library. This is because when lowering at the invocation
site, the target might not be in the current library.
Change-Id: Ifcf6cc63ce7e6f86b3408c9830e1244215598bf6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296381
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
Note that the behavior of the code under test here had changed
significantly, but the test didn't catch it at all because
"@compile-error" is too coarse-grained.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I4b6c4e1fd36770e13f7b5ca100b42b0b8b2983ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296121
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
DDC passes, dart2js and VM fail.
----
The dart2js and VM fringe-following scheme could be modified to call
`.iterator` at the `yield*` site and use the Iterator instead of the Iterable.
Calling `.iterator` at the `yield*` site would move the exception to the right place. It might also present an optimization opportunity where the call might be inlined, or the entry into the fringe-following algorithm could be made more efficient based on the type of the iterator.
Change-Id: Icfb6f7ca0b92cbeea1349ce138e469cfa707f571
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295200
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Otherwise, in its current state, there's no clear error for any modifiers when used before an enum declaration.
This follows the same format to FINAL_MIXIN_CLASS and those groups of errors.
Bug: https://github.com/dart-lang/sdk/issues/51935
Change-Id: I8174b6894c95fef5c0f4704927b161942c19d3ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294122
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
For applications that want to have arbitrary number of isolates call
into native code that may be blocking, we expose the API functions that
allows those native threads to exit an isolate before running
long/blocking code.
Without the ability to exit/re-enter isolate, one may experience
deadlocks as we have a fixed limit on the number of concurrently
executing isolates atm.
In the longer term we may find a way to do this automatically
with low overhead, see [0]. But since those API functions are quite
stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
see a reason not to expose `Dart_{Enter,Exit}Isolate`.
Difference to original CL:
Do use STL synchronization primitives (as the ones in runtime/bin
are not always available in shared libraries)
[0] Issue https://github.com/dart-lang/sdk/issues/51261
Issue https://github.com/dart-lang/sdk/issues/51254
TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
Change-Id: Id817e8d4edb3db35f029248d62388cbd0682001d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294980
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This reverts commit df761ba9e7.
This also rebases the original CL onto HEAD so it can be landed first.
CoreLibraryReviewExempt: Reland of backend-specific library changes.
Change-Id: I4f9a017be3ec1924c021f941291d79d7aee06663
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294131
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This reverts commit a2512819f8.
Reason for revert: FFI tests fail to link on Windows, fail to load on product-mode Android
Original change's description:
> [vm] Expose Dart_{CurrentIsolate,ExitIsolate,EnterIsolate}
>
> For applications that want to have arbitrary number of isolates call
> into native code that may be blocking, we expose the API functions that
> allows those native threads to exit an isolate before running
> long/blocking code.
>
> Without the ability to exit/re-enter isolate, one may experience
> deadlocks as we have a fixed limit on the number of concurrently
> executing isolates atm.
>
> In the longer term we may find a way to do this automatically
> with low overhead, see [0]. But since those API functions are quite
> stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
> see a reason not to expose `Dart_{Enter,Exit}Isolate`.
>
> [0] Issue https://github.com/dart-lang/sdk/issues/51261
>
> Issue https://github.com/dart-lang/sdk/issues/51254
>
> TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
>
> Change-Id: I91c772ca962fddb87919663fea07939a498fa205
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292722
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Daco Harkes <dacoharkes@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Change-Id: I05ad5b9ce24754a68693160e470f8eb71a812c75
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294860
Auto-Submit: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
For applications that want to have arbitrary number of isolates call
into native code that may be blocking, we expose the API functions that
allows those native threads to exit an isolate before running
long/blocking code.
Without the ability to exit/re-enter isolate, one may experience
deadlocks as we have a fixed limit on the number of concurrently
executing isolates atm.
In the longer term we may find a way to do this automatically
with low overhead, see [0]. But since those API functions are quite
stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
see a reason not to expose `Dart_{Enter,Exit}Isolate`.
[0] Issue https://github.com/dart-lang/sdk/issues/51261
Issue https://github.com/dart-lang/sdk/issues/51254
TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
Change-Id: I91c772ca962fddb87919663fea07939a498fa205
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292722
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
If a list pattern consists of a single rest pattern, and that rest
pattern is guaranteed to match, then the whole list pattern is
guaranteed to match as well (provided that the matched value type is a
subtype of the list pattern's required type).
Bug: https://github.com/dart-lang/language/issues/2980
Change-Id: I316cc93d4e696f094716be92e1fbc1cd3a43a73c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change adds x64 unwinding information for generated code allowing Windows to actually call registered unhandled exception filters(Crashpad or dart-builtin crash handler).
BUG=https://github.com/dart-lang/sdk/issues/51726
TEST=ffi\ffi_induce_a_crash_test.dart
Change-Id: I1d9dd208f2c030b51a1146afa1048d419847fef7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294129
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This reverts commit 9e1997971e.
Reason for revert: Breaks Dart -> Engine roll?
See:
https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20linux_web_engine/1821/overviewhttps://ci.chromium.org/ui/p/flutter/builders/try/Linux%20Engine%20Drone/666824/overview
Original change's description:
> Reland "[pkg:js/dart:js_interop] Move annotations to dart:_js_annotations"
>
> This is a reland of commit fbe9c21972
>
> This fixes the issue with the duplicate allowPlatformPrivateLibraryAccess.
>
> Original change's description:
> > [pkg:js/dart:js_interop] Move annotations to dart:_js_annotations
> >
> > This moves package:js annotations to the internal library that
> > Flutter has been using already. This gives us a single location
> > for all package:js annotations. We also introduce a @JS annotation
> > in dart:js_interop since we can no longer use dart:_js_annotations
> > to avoid the breaking change in semantics.
> >
> > CoreLibraryReviewExempt: Backend-specific internal library.
> > Change-Id: I9ca55c807d7d192004a6da99f63a72d598fe4f12
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284760
> > Commit-Queue: Srujan Gaddam <srujzs@google.com>
> > Reviewed-by: Samuel Rawlins <srawlins@google.com>
> > Reviewed-by: Johnni Winther <johnniwinther@google.com>
> > Reviewed-by: Joshua Litt <joshualitt@google.com>
>
> CoreLibraryReviewExempt: Relanding.
> Change-Id: I40ff2a00682fccbd7dd44a364b5046aaac0f3bac
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293203
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Samuel Rawlins <srawlins@google.com>
Change-Id: Ide8609575c73d714f3ae4f9ea9ffc74e228fa189
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293962
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
This reverts commit ef7d8d3f9a.
Reason for revert: Breaks Dart -> Engine roll?
See:
https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20linux_web_engine/1821/overviewhttps://ci.chromium.org/ui/p/flutter/builders/try/Linux%20Engine%20Drone/666824/overview
Original change's description:
> [dart:js_interop] Export some package:js annotations and check them
>
> To disallow package:js on dart2wasm, we need to export @staticInterop
> and @anonymous through dart:js_interop. However, users should not mix
> the two @JS annotations, so we add some static checks for that. We also
> export @JSExport to support export classes with dart:js_interop.
>
> CoreLibraryReviewExempt: Reexporting annotations through backend-specific library.
> Change-Id: I54610965da332320170d991d785192341049607e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293500
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I2af0755e054a1b0452a5fc617a93257209703793
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293961
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
To disallow package:js on dart2wasm, we need to export @staticInterop
and @anonymous through dart:js_interop. However, users should not mix
the two @JS annotations, so we add some static checks for that. We also
export @JSExport to support export classes with dart:js_interop.
CoreLibraryReviewExempt: Reexporting annotations through backend-specific library.
Change-Id: I54610965da332320170d991d785192341049607e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293500
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This fixes a minor bug in flow analysis which was preventing it from
recognizing when a switch statement was trivially exhaustive, meaning
one of its reachable cases was guaranteed to always match.
This mostly addresses
https://github.com/dart-lang/language/issues/2980, but flow analysis
still fails to recognize that:
- A list pattern containing a just a single rest pattern always
matches (unless the rest pattern has a subpattern that may fail to
match).
- A null check pattern always matches if its subpattern always matches
and the matched value type is non-nullable.
- The relational pattern `!= null` always matches if its subpattern
always matches and the matched value type is non-nullable.
Fortunately, these drawbacks are small and don't lead to unsoundness.
I'll try to address them in follow up CLs.
Bug: https://github.com/dart-lang/language/issues/2980
Change-Id: Ie9f8564cde66a5a2c41114033ca3ff0e1a0f139a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293860
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is a reland of commit fbe9c21972
This fixes the issue with the duplicate allowPlatformPrivateLibraryAccess.
Original change's description:
> [pkg:js/dart:js_interop] Move annotations to dart:_js_annotations
>
> This moves package:js annotations to the internal library that
> Flutter has been using already. This gives us a single location
> for all package:js annotations. We also introduce a @JS annotation
> in dart:js_interop since we can no longer use dart:_js_annotations
> to avoid the breaking change in semantics.
>
> CoreLibraryReviewExempt: Backend-specific internal library.
> Change-Id: I9ca55c807d7d192004a6da99f63a72d598fe4f12
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284760
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Samuel Rawlins <srawlins@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Joshua Litt <joshualitt@google.com>
CoreLibraryReviewExempt: Relanding.
Change-Id: I40ff2a00682fccbd7dd44a364b5046aaac0f3bac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293203
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This reverts commit a289c4d848.
Reason for revert: https://github.com/flutter/flutter/issues/124282
Original change's description:
> [dart2wasm] Fix runtime type tests
>
> emitTypeTest optimizes a test like `x is List<T>` where `x :
> Iterable<T>`, i.e. tested-against type is a subtype of the operand's
> static type. In these cases we can check just the class ID of the
> operand without checking the type arguments.
>
> However this optimization cannot be done when the types don't have same
> number of type arguments. Example:
>
> class H1<T> {}
>
> bool test(Object o) {
> return o is H1<num>;
> }
>
> void main() {
> print(test(H1<Object>()));
> }
>
> Here `H1<num> <: Object`, but we still need to check the type parameter.
>
> This CL checks that the types have the same number of type arguments
> before optimizing the test.
>
> Fixes#51187.
>
> This fix reveals another bug in `static_interop_test`, which is tracked
> in #51200. The test is updated to work around the bug for now.
>
> New passing tests:
>
> - co19/LanguageFeatures/Patterns/matching_cast_A01_t01
> - co19/LanguageFeatures/Patterns/matching_list_A01_t01
> - co19/LanguageFeatures/Patterns/matching_list_A01_t02
> - co19/LanguageFeatures/Patterns/matching_object_A01_t01
> - co19/LanguageFeatures/Patterns/matching_object_A01_t02
> - co19/LanguageFeatures/Patterns/record_A01_t03
> - co19/LanguageFeatures/Patterns/record_A01_t06
> - co19/LanguageFeatures/Patterns/record_A01_t07
> - co19/LanguageFeatures/Patterns/record_A01_t08
> - co19/LanguageFeatures/Patterns/record_A01_t09
> - language/generic/deep_test
> - language/generic_methods/type_expression_test
> - language/patterns/object_pattern_inference_test
>
> Change-Id: Ibd9615666b7f7538c2a3f03fb7f5ebe9b16c3d54
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292881
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Ömer Ağacan <omersa@google.com>
Change-Id: Ieb222c086864744d33b77de69882e805981f1953
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293891
Commit-Queue: Zach Anderson <zra@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
