Also add `legacyTypeRep<T>()` that is similar but performs
a shallow conversion to a legacy type.
Using this in compiler/dartdevc_native/ tests gives a better usability
instead of constantly wrapping and unwrapping types. It allows us to
avoid stripping off the legacy from a type when calling `wrapType()`.
Issue: https://github.com/dart-lang/sdk/issues/40266
Change-Id: I07225f18c253222b31203b0b110233a3e018a7d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142547
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This test isn't running in any configuration because the filename
doesn't end with "_test.dart".
Change-Id: Idf38c9dd643da36ce6b6cc587d609d7d9e707af2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142781
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- Apply formatter.
- Use Expect.listEquals() to compare lists. Reverse the order of
arguments to account for the expected value coming first.
Issue: https://github.com/dart-lang/sdk/issues/40266
Change-Id: I35961729bdc4aad5337361e5df445a11ac03b2bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141909
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
These changes are also being back ported into the existing SDK
with minimal differences that will be gone when we unfork the
dart:_runtime library. In the current back port:
* FutureOr<Null>? is normalized to Future<Null>* instead of
Future<Null>?.
* There is no runtime normalization of FutureOr<T?>?. This
should have no effect since nullable types can not yet
appear.
Fixes: #40611, #40720
Change-Id: Ib3ddffbf3778f0f571cf95f58b6142d3ee0bf59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136160
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Fix instance checks for types that are internal to the type system.
Fixes: #40610
Change-Id: I0c6c1bb4d64f25a97c53bd64a3940cf3e9f45c88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135580
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
dartdevc_native tests also have to be updated to not wrap/unwrap generic function types.
Change-Id: I4115db483bb6668c171ec29ca7483dfabc470df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133285
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Fixes a missing case where DDC allows unwrapped functions to flow to
JavaScript through constructor calls or anonymous object instantiation.
- Pass the `Member` through to `_emitArgumentList` in the case of
constructor calls and object literals so that `isJsInterop` can be
determined.
- Pass an optional `isJsArgument` member through for emitting named
expressions. Previously I thought that no named arguments would be
used for javascript calls, but they are used to create object literals
for anonymous JS types.
- Add both anonymous and non-anonymous constructor invocation examples
to the JS interop test.
Change-Id: I004642f3b2caccc0d8c26786f2bdcb081d135898
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/131462
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Wrapping a legacy type will cause the legacy-ness to be stripped off by design.
This causes confusion when trying to unit test the runtime subtype checks so we
are now simply avoiding it here.
Introduce a `unwrap()` helper method that will attempt to upwrap any type that
isn't legacy. Legacy types are simply returned unchanged because they are
already unwrapped.
Copies the other helper methods from runtime_utils.dart to
runtime_utils_nnbd.dart so they can be updated with the special unwrapping logic
for legacy types.
Change-Id: I21ff24b766a1f7a569181a2e1c47233320751c66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/131707
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Fixes#39074
DDC emits Dart code that can usually be called with the same semantics
as JS there is no guarantee that a function passed to JS and then
invoked successfully was wrapped with `allowInterop`. The wrapping is
always required in Dart2JS. To make DDC more strict, add interceptors
that check for the usage of `allowInterop`.
Whenever a JS interop function or setter is passed an argument which is
statically typed as a Function, but not wrapped with `allowInterop` at
the call site, wrap it with `assertInterop` which will check the
argument at call time and fail with a clear error if it was not wrapped.
Whenever a JS interop function is torn off, either at the top level or
from an instance, wrap it with a function that will also inject these
checks at runtime.
There are still holes where we can't catch the mistake:
- An argument which is statically dynamic and a Function at runtime
won't be caught.
- A Function which is stored in a collection won't be caught.
- A JS interop definition where a getter returns a Function which takes
a Function as an argument is not checked.
- A dynamic call through to javascript is not checked.
Changes:
- Refactor `_isJsLibrary` and add `isJsMember`, and `isAllowInterop`
utilities to determine what needs wrapping.
- Update `assertInterop` to give a more clear error when it fails, and
to ignore non function arguments.
- Add `tearoffInterop` to wrap a function an ensure that any function
typed arguments are wrapped.
- Inject `assertInterop` around Function arguments passed to JS methods.
- Inject `assertInterop` around Function arguments passed to static or
instance JS setters.
- Inject a runtime wrapper around static or instance Function tearoffs.
- Add a test covering all flavors of checks that are supported.
- Change the interop expando to an `Expando<dynamic>` in the NNBD SDK to work
around a stricter type check. https://github.com/dart-lang/sdk/issues/39971
Potential improvements:
If the `tearoffInterop` turns out to be too heavy, we could loosen it so
that we only wrap methods if any of their argument types are statically
declared to be a Function.
Change-Id: Ibc92df5b54e1a041b4102a07b8398b774b6bd1d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128462
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
All of these tests are now running under the regular test infrastructure.
The only reason they were created as modular tests was because we wanted more
control over the SDK sources used.
Change-Id: I2ad5aa616ff8bccd10cfac2d49bfaa39ab50c192
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128801
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
* Treat the assertion condition offset as a character offset in the file.
* Allow unrecognized characters to be replaced by a placeholder character. This
is unrelated to the fix but is just a precautionary measure.
Fixed: 39271
Change-Id: I4871ea41d3a46d26ecac5047265a1dbc1c889350
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124602
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
In weak mode when a subtype check fails it is performed again with more lenient
rules. If the second check passes a warning is printed to the console and it is
allowed to pass. If the second check fails it is treated as a failure.
- Add a method to set the runtime mode.
- Update test expectations for more permissive subtype checks.
Issue: #38128
Change-Id: I7d55bfffad16077c50b6b2c3bf6df8367e6f7785
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123300
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
- The strong and weak tests are still identical because weak mode still executes
with the strong mode semantics.
- This is organization prep to make it easier to all what cases are covered and
what changes when I land the weak mode support.
Change-Id: I4b067cee9a4f88b417587f1bf6a42c15fa4f624e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123005
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- Copy the strong mode subtype test and change the requirement to weak mode.
Later commits will update the test to add extra weak mode expectations.
- Update the normalization tests to run in both modes.
Change-Id: I5ccff181f12756aab003c2e6db43b52ead257b19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122589
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Allows for reuse of the standard helpers that create types with and without
NNBD.
Change-Id: I8e16483e704efb47173f56c126311f7d57ece8a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122487
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- Save the canonical instance of a nullable or legacy types on the canonical
instance of the non-nullable type.
- Add additional normalization when creating nullable and legacy types.
Issue: #38109
Change-Id: I1132917965db3b00f87b891a0800da46e2cc6b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122061
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Will be used for runtime subtype changes in future CLs.
Change-Id: I53ba10c994f13300541b3ae7a9e14d52c3836771
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121821
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Remove shards from builder configuration for now because there is currently only
one test.
Change-Id: I5dcce5601ed46e36b28f9cab9bede1d81c1a42ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121865
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
As I understand in early versions of strong mode generic function subtypes could
have contra-variance in the bounds of the type parameters. Now the spec states
they must be equal.
Fixes#36501
Tested and passing with the fixed language_2/generic_function_bounds_test
https://dart-review.googlesource.com/c/sdk/+/109726
Change-Id: Ie11d6318a542867e0541d81e2a18e5e25d3f0d9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110361
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This is a somewhat roundabout way to prevent a hot restart from redefining these types.
This fixes the issues arising: https://github.com/dart-lang/sdk/issues/37259.
Should more cleanly separate fields reset on a hot restart from ones preserved.
Change-Id: Id0c45cbeed67b574c3259e1f87a405137ae93575
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111315
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
The combination of type expression hoisting, hot restart, and generic cache
reset triggers occasional breakage (see #37259). Not clearing the generic
cache should be safe, but will some leak memory: unloaded types will
pollute the cache. References to those unloaded types in user code,
however, should be cleared.
Bug: https://github.com/dart-lang/sdk/issues/37259
Change-Id: Ia15115a41556db7a19109f0178baa63ec0cfcb9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/109100
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Next step is the inject this in DDC generated code on Dart/JS boundaries.
Change-Id: If15ff1389b2ce5f6c264e3e31bddaade7f7687e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108943
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Allows the dart:_debugger import to work as it is white-listed in this
directory.
Reveals that DDK is not passing this test. The status changes from a
compile-time to a run-time error.
Change-Id: I3703496a4ede7d155a4d82286040f1a73be677ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106360
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
These are now represented as named functions. This will also help the
debug tools give more information.
Tested with three applications and adding the names caused a code size increases
of less than 1%.
|Total App JS size | Increase |
|------------------|----------|
| 24.7 MB | 0.06% |
| 242 MB | 0.14% |
| 327 MB | 0.19% |
Fixes: #37118
Change-Id: I89a259215ceb8b9e559a190dbd521c923d4c55c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105546
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
