With hot reload, a new module format is being introduced that's
repurposing the ddc module format. This will replace all other
existing formats long-term. For now, we want to enable some test
bots to start running with the new format, so we emit different
HTML based on the format in the test runner.
With these changes, all tests pass when using ddc module format
except for libraries_test. This is due to how DDC may lazily load
libraries with the new format, so this test is reordered to make
it work with the new format.
Change-Id: If52bb64977f96b4c4a287f142026412a4db558cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379750
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This is a reland of commit e7658520bb
Fixes in the reland + context:
Type parameters emitted in implicit type checks on covariant mixin forwarding stubs may reference type arguments in anonymous classes. We reduce this to their mixin's implementing subclass to avoid generating RTI rules for anonymous classes.
Previous implementations would 'translate' type parameters to that of their mixed in type, but that strategy fails if the implementing subtype shuffles the order of type arguments relative to its mixed in type (demonstrated in the test - though not actually relevant in the Flutter break).
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I9b6f69b7150631f28442675c4230e093e3b821d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379511
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This reverts commit e7658520bb.
Reason for revert: Causing failures in both Dart->Flutter roller and web_dev package.
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I8ea12847bb2a4d096db0799c85f3175f1c5df3be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379420
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Auto-Submit: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
Notable changes:
- Generic classes are now declared at top level (rather than within in closures).
- RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
- Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
- Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
- An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
- Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
- Certain debugger functions now require instances (e.g.,`getClassMetadata`).
- Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
It's possible with changes in how we handle generics in
DDC that T might not be the type we expect at runtime. So,
we should test to make sure that it is by doing some simple
type tests in the body of non-external methods of JS interop
classes.
Change-Id: I0220b2bced4e5769e3728833204dfb3ac19f26d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378572
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit d84f908641
Includes fixes:
--- Catch scope fix ---
Each catch block should define its own scope, but the compiler was not treating the body of these catch blocks as a scope. This was leading to incorrect variable renaming.
--- Duplicate label fix ---
Labels weren't being removed from the _labelNames Map after being used so multiple nodes were getting tagged with the same label. Note: This didn't actually cause any bugs because the label closer to the break statements using those labels was the correct one.
--- addAsyncCallback cleanup ---
The new async semantics actually don't require managing addAsyncCallback and removeAsyncCallback calls (proxies for async_helper.asyncStart and async_helper.asyncEnd). None of the other backends manage these themselves. It's up to tests to ensure they call async_helper.asyncStart and async_helper.asyncEnd.
Original change's description:
> [ddc] Update DDC compiler to start using the new async transform.
>
> Updates compiler.dart to use the new async transformation.
>
> Some key things to note:
> - Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
> - For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
> - We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
> - Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
>
>
> There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
>
> Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
Change-Id: Idfe05c0628b2b91f474d08d99427961381debeb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376000
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
--- Super fix ---
When the arguments to a call contain an async gap (an await in this case), the new lowering will save the receiver to a temp variable so it can be accessed on re-entry to the function body. This is skipped for literals as the literal does not need to be stored in a variable, it can simply be used as-is.
However, the DDC JS AST did not treat "this" or "super" as literals so we ended up with invalid JS like "let temp = super; // do await; temp.foo(...);". In this case "let temp = super;" is invalid, "super" cannot be used as a bare expression.
--- Function scope change ---
The original approach of using TemporaryIds for all the hoisted variables had a large flaw in that it didn't account for scopes captured by closures within async code. Hoisted variables were lifted out of their attached scope and so closures captured the single hoisted declaration and all modified the same variable. See async_scope_capture_test.dart for an example of this breaking.
To fix this we need to box any captured variables into a JS object. We then wrap any closures in an IIFE and pass the correct scope objects in as arguments to "capture" them. This is similar to dart2js's approach of boxing variables for closures. The approach is a little less fine-grained though and we simply box every variable. This makes the logic simpler and provides a better debug experience as users will just be able to look at the available "asyncScope" variables and see all the declarations in the original source code.
--- Add async callback ---
After further study, none of the other backends add implicit calls to 'async_helper.asyncStart' or 'async_helper.asyncEnd'. All the tests (with the exception of the hot_restart_timer_test updated below) are all set up to call asyncStart if they need it. As such we can simply remove and calls in the runtime/sdk to 'addAsyncCallback' (which is then calling 'async_helper.asyncStart'). Ditto with their remove/end counterparts.
Change-Id: Iac9a3774cc43fc2270e3bb2e992893358042e604
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376020
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This reverts commit d84f908641.
Reason for revert: Causing internal failures.
Original change's description:
> [ddc] Update DDC compiler to start using the new async transform.
>
> Updates compiler.dart to use the new async transformation.
>
> Some key things to note:
> - Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
> - For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
> - We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
> - Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
>
>
> There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
>
> Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
Change-Id: Ia939fe5a9dfd3a5031b06a7ea26c52e58b89f011
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375701
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Updates compiler.dart to use the new async transformation.
Some key things to note:
- Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
- For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
- We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
- Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This allows internal Set classes to be referenced by our runtime.
Context: incoming changes to our generic types (required for hot reload) requires that RTIs be passed to generic classes on instantiation. Moving our Set implementation into our private runtime and making their classes public allows us to directly reference them without clobbering names externally.
Change-Id: Ie47b3263ebbf2650d314b5285a2d50f3abd1a664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373327
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This reverts commit cd2c566bcf.
Reason for revert: Updating to not remove field used by Flutter engine.
Original change's description:
> Revert "Tweak `expect.dart` library."
>
> This reverts commit ff5f391c0a.
>
> Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
>
> Original change's description:
> > Tweak `expect.dart` library.
> >
> > Make API more consistent for a few methods.
> > Reduce the number of language features used in tests:
> > * Never iterating an iterable, always converting it
> > using `.toList()` first and iterating using indices
> > (fx `setEquals`).
> > Also require a `List` in places where an `Iterable`
> > wasn't necessary.
> > * Avoid doing complicated computations that are also
> > used for the error message. Do simple check first,
> > then recompute to get better error messages
> > (fx `allDistinct`).
> >
> > Renamed some rarely used members for consistency
> > (`stringContainsInOrder`->`containsInOrder`,
> > where other string-contains functions just start
> > with `contains`, and `containsOneOf` -> `containsAny`
> > to match `Iterable.any` phrasing, and also it accepts
> > if containing at least one, not precisely one.)
> >
> > Removed a function that wasn't used anywhere.
> >
> > Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> > Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
> >
> > Deprecates `package:expect/minitest.dart`. It was never intended
> > to be used for new tests, only as a help to convert existing tests
> > written against `package:unit_test`.
> > All existing imports marked as `// ignore: deprecated_member_use`.
> >
> > Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> > Reviewed-by: Slava Egorov <vegorov@google.com>
> > Reviewed-by: Ömer Ağacan <omersa@google.com>
> > Reviewed-by: Nate Bosch <nbosch@google.com>
> > Reviewed-by: Stephen Adams <sra@google.com>
> > Commit-Queue: Lasse Nielsen <lrn@google.com>
>
> Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: William Hesse <whesse@google.com>
CoreLibraryReviewExempt: Reland
Change-Id: I53db40edc0733842a008839c3913d51c885e39ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362502
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit ff5f391c0a.
Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
Original change's description:
> Tweak `expect.dart` library.
>
> Make API more consistent for a few methods.
> Reduce the number of language features used in tests:
> * Never iterating an iterable, always converting it
> using `.toList()` first and iterating using indices
> (fx `setEquals`).
> Also require a `List` in places where an `Iterable`
> wasn't necessary.
> * Avoid doing complicated computations that are also
> used for the error message. Do simple check first,
> then recompute to get better error messages
> (fx `allDistinct`).
>
> Renamed some rarely used members for consistency
> (`stringContainsInOrder`->`containsInOrder`,
> where other string-contains functions just start
> with `contains`, and `containsOneOf` -> `containsAny`
> to match `Iterable.any` phrasing, and also it accepts
> if containing at least one, not precisely one.)
>
> Removed a function that wasn't used anywhere.
>
> Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
>
> Deprecates `package:expect/minitest.dart`. It was never intended
> to be used for new tests, only as a help to convert existing tests
> written against `package:unit_test`.
> All existing imports marked as `// ignore: deprecated_member_use`.
>
> Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: William Hesse <whesse@google.com>
Make API more consistent for a few methods.
Reduce the number of language features used in tests:
* Never iterating an iterable, always converting it
using `.toList()` first and iterating using indices
(fx `setEquals`).
Also require a `List` in places where an `Iterable`
wasn't necessary.
* Avoid doing complicated computations that are also
used for the error message. Do simple check first,
then recompute to get better error messages
(fx `allDistinct`).
Renamed some rarely used members for consistency
(`stringContainsInOrder`->`containsInOrder`,
where other string-contains functions just start
with `contains`, and `containsOneOf` -> `containsAny`
to match `Iterable.any` phrasing, and also it accepts
if containing at least one, not precisely one.)
Removed a function that wasn't used anywhere.
Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
Deprecates `package:expect/minitest.dart`. It was never intended
to be used for new tests, only as a help to convert existing tests
written against `package:unit_test`.
All existing imports marked as `// ignore: deprecated_member_use`.
Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
- These tests rely on the internals of the old type system.
- Copy some expectations to the language suite when it looks like
there isn't already coverage for the same test.
Change-Id: I63bfa2bc94fb29b4e4f90c3c02cf0943d19764b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352463
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This happened to work in both type systems because the property of the
same name exists in both, but technically `unwrapType()` is part of
the old type system and will be deleted soon.
Change-Id: I5620c5f409f0c6fe486b9a4c7a6872ee8deabc09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348800
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Replaces all uses with the equivalent `TYPE_REF()` and
`LEGACY_TYPE_REF()` because they are used in the shared dart:_rti
library and there is no need to support both.
Change-Id: I8c04eb12856cf6933a168f3e63351a45cd5d704e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344608
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The test was relying on the runtime type representation to verify
that the library object returned from `getLibrary` was correct. Now
it uses the static `print()` method instead to avoid issues in the new
type system.
Change-Id: Iaa26427e46afd0e7f4ae0a84cb4c123755484647
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335023
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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>
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>
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>
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>
Ensure there are tests for all the different code paths that
throw `NoSuchMethodError` when making some kind of dynamic invocation.
Add tests to cover the name descriptors that appear as well. Some are
confusing and in need of improvement.
Null values in particular will cause a crash before correctly throwing
a `NoSuchMethodError`.
Change-Id: I54bbb91214e0d333b1a99abe455c8ff1a4df6cb9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297182
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Use "ddcOptions" in test files to closer resemble the name 'ddc-options'
from the test matrix or command line option.
I don't like that this option is in camelCase when written in a test
file but uses a dash when passed on the command line but that matches
all the other implementations (dart2jsOptions, sharedOptionn, etc).
Hopefully it is the most discoverable or least surprising choice.
Change-Id: I8f0d53d50416b952c9ea74406c18bb9c700f98dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281820
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Since we lower @staticInterop members differently, CFE expectations are
updated. A previous patchset updated tests to account for changes in
top-level external members, but those changes are now non-breaking.
This CL still keeps some of those fixes to tests since they are more
sound and correct:
- Debugger tests to allowInterop a function that wasn't caught before,
as DDC only adds checks for arguments whose static type is a Function,
whereas js_util does a runtime is check to determine if the argument is
a Function
- Interop tests that typed top-level externals unsoundly
- Interop tests that used tear-offs of top-level external methods
instead of getters
Change-Id: I46a5a1316db1dba38691efece075f9c34ac4b4e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277660
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Make sure that calls to super class methods from mixin application
stubs are always generated using `super` and not `this`.
Replacing `super` by `this` should not be used as non-virtual field access optimization in forwarding stubs that intend to redirect to the super class members (using `this` redirects to itself and causes infinite recursion).
Closes: https://github.com/dart-lang/sdk/issues/50119
Change-Id: Ib9c9aebdc88555518998db64aefa1fd0905c5b11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267822
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
This reverts commit 69f32d6ad7.
Reason for revert: We seem to have a number of tests failing with timeouts in CBUILD after this change, please see logs at
https://dart-in-g3-qa-prod.corp.google.com/dg3/Home#/cbuild/find/69f32d6ad7e724e3148cb2eb6601e63165e76ad3
Original change's description:
> Refactor `_Future`.
>
> This is a major rewrite of the `_Future` class,
> which is the default implementation of the `Future` interface.
>
> The main goal was to reduce the number of expensive type checks
> in the internal passing around of data.
> Expensive type checks are things like
> * `is _Future<T>` (more expensive than just `is _Future`, the latter
> can be a single class-ID check.
> * Covariant generic parameter checks (using `T` covariantly in a
> parameter forces a run-time type check).
>
> Also removed some plain unnecessary casts and turned some
> implicit casts from `dynamic` into `unsafeCast`s.
>
> This seems to be an success, at least on very primitive benchmarks, according to Golem:
> FutureCatchErrorTest 41.22% (1.9 noise)
> FutureValueTest 46.51% (2.8 noise)
> EmptyFutureTest 59.15% (3.1 noise)
> FutureWhenCompleteTest 51.10% (3.2 noise)
>
> A secondary goal was to clean up a very old and messy class,
> and make it clearer for other `dart:async` how to interact
> with the future.
>
> The change has a memory cost: The `_FutureListener<S,T>` class,
> which represents a `then`, `catchError` or `whenComplete`
> call on a `_Future`, now contains a reference to its source future,
> the one which provides the inputs to the callbacks,
> as well as the result future returned by the call.
> That's one extra memory slot per listener.
>
> In return, the `_FutureListener` now does not need to
> get its source future as an argument, which needs a covariant
> generic type check, and the methods of `_Future` can be written
> in a way which ignores the type parameters of both `_Future`
> and `_FutureListener`, which reduces complex type checks
> significantly.
>
> In general, typed code is in `_FutureListener`, which knows both
> the source and target types of the listener callbacks, and which
> contains the futures already at that type, so no extra type checking
> is needed.
> The `_Future` class is mostly untyped, except for its "public"
> API, called by other classes, which checks inputs,
> and code interacting with non-native futures.
> Invariants ensure that only correctly typed values
> are stored in the untyped shared `_resultOrListeners` field
> on `_Future`, as determined by its `_state` integer.
> (This was already partially true, and has simply been made
> more consistent.)
>
> Further, we now throw an error in a situation that was previously
> unhandled: When a `_Future` is completed with *itself*.
> That would ensure that the future would never complete
> (it waits for itself to complete before it can complete),
> and may potentially have caused weird loops in the representation.
> In practice, it probably never happens. Now it makes the error
> fail with an error.
> Currently a private `_FutureCyclicDependencyError` which presents
> as an `UnsupportedError`.
> That avoids code like
> ```dart
> import "dart:async";
> void main() {
> var c = Completer();
> c.complete(c.future); // bad.
> print("well!");
> var d = Completer();
> d.complete(c.future);
> print("shucks!");
> }
> ```
> from hanging the runtime by busily searching for the end of a cycle.
>
> See https://github.com/dart-lang/sdk/issues/48225
> Fixes#48225
>
> TEST= refactoring covered by existing tests, few new tests.
>
> Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,kustermann@google.com,sra@google.com,sigmund@google.com,nshahan@google.com
Change-Id: I455be5a04b4c346df26d4ded0fa7388baccb0f8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247762
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This is a major rewrite of the `_Future` class,
which is the default implementation of the `Future` interface.
The main goal was to reduce the number of expensive type checks
in the internal passing around of data.
Expensive type checks are things like
* `is _Future<T>` (more expensive than just `is _Future`, the latter
can be a single class-ID check.
* Covariant generic parameter checks (using `T` covariantly in a
parameter forces a run-time type check).
Also removed some plain unnecessary casts and turned some
implicit casts from `dynamic` into `unsafeCast`s.
This seems to be an success, at least on very primitive benchmarks, according to Golem:
FutureCatchErrorTest 41.22% (1.9 noise)
FutureValueTest 46.51% (2.8 noise)
EmptyFutureTest 59.15% (3.1 noise)
FutureWhenCompleteTest 51.10% (3.2 noise)
A secondary goal was to clean up a very old and messy class,
and make it clearer for other `dart:async` how to interact
with the future.
The change has a memory cost: The `_FutureListener<S,T>` class,
which represents a `then`, `catchError` or `whenComplete`
call on a `_Future`, now contains a reference to its source future,
the one which provides the inputs to the callbacks,
as well as the result future returned by the call.
That's one extra memory slot per listener.
In return, the `_FutureListener` now does not need to
get its source future as an argument, which needs a covariant
generic type check, and the methods of `_Future` can be written
in a way which ignores the type parameters of both `_Future`
and `_FutureListener`, which reduces complex type checks
significantly.
In general, typed code is in `_FutureListener`, which knows both
the source and target types of the listener callbacks, and which
contains the futures already at that type, so no extra type checking
is needed.
The `_Future` class is mostly untyped, except for its "public"
API, called by other classes, which checks inputs,
and code interacting with non-native futures.
Invariants ensure that only correctly typed values
are stored in the untyped shared `_resultOrListeners` field
on `_Future`, as determined by its `_state` integer.
(This was already partially true, and has simply been made
more consistent.)
Further, we now throw an error in a situation that was previously
unhandled: When a `_Future` is completed with *itself*.
That would ensure that the future would never complete
(it waits for itself to complete before it can complete),
and may potentially have caused weird loops in the representation.
In practice, it probably never happens. Now it makes the error
fail with an error.
Currently a private `_FutureCyclicDependencyError` which presents
as an `UnsupportedError`.
That avoids code like
```dart
import "dart:async";
void main() {
var c = Completer();
c.complete(c.future); // bad.
print("well!");
var d = Completer();
d.complete(c.future);
print("shucks!");
}
```
from hanging the runtime by busily searching for the end of a cycle.
See https://github.com/dart-lang/sdk/issues/48225Fixes#48225
TEST= refactoring covered by existing tests, few new tests.
Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Srujan Gaddam