The kernel builder relied on only seeing expressions emitted by the
finalizable transform (variable get and this) as arguments to the fence.
However, other transforms can run later. In this case the expression
was turned into a constant.
This CL changes the implementation to accept any expression rather than
accepting a subset of expressions.
TEST=tests/ffi/regress_49402_test.dart
Closes: https://github.com/dart-lang/sdk/issues/49402
Change-Id: I1a962a5b7a38099eb5c3bbf5a5a8145b16727d97
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250744
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Related issue: #49301
We have an invariant to make sure stubs aren't created across other
libraries but really the invariant should test for other
components, as it's valid to have two libraries call each other's
factories. Similarly, stubs need to be added to the class before we
clone the body, as the body may mutually recurse. Tests are changed
to reflect this.
Change-Id: I529b682f107a55791a52fa79f082cc8ef5fce1f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249546
Reviewed-by: Riley Porter <rileyporter@google.com>
Weaken assertion in gen_snapshot requiring all libraries to have a loading unit as there can still be unreachable libraries:
- Google3 and Fuchsia will compile all the sources in a package to a single dill file, then present multiple input dill files to the AOT compilation. Since the set of libraries was derived from package membership instead of imports, many can be unreachable.
- When the root library's main comes from an export, the frontend's representation will incorrectly report the library containing main as the root library and the true root library may be unreachable from it.
Instead, assert only that surviving compiled code is assigned a loading unit.
TEST=gallery
Bug: https://github.com/flutter/gallery/issues/545
Bug: https://github.com/dart-lang/sdk/issues/49325
Bug: https://github.com/dart-lang/sdk/issues/41974
Bug: b/237016312
Change-Id: Ia52563a6f517308d041368be11dcc85270f19acc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249724
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit c97f7b7fad.
Reason for revert: Still breaking google3 (b/236665701)
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> This is a reland of commit a247b158d6
>
> Change-Id: Ieec74d6f93c57175c357ec18889144635f5bdca6
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249490
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
TBR=lrn@google.com,eernst@google.com,nbosch@google.com
Change-Id: I870285b03ec05803c5aaa6b66f9a6e6ea360d732
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249609
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
The tests are generally slow and sometimes hit the limit to a timout
(e.g. recently on win-debug-ia32)
TEST=Should fix flaky timeouts.
Change-Id: I8879d0e6df94046e79e43957877877a3458deb3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249607
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
This is a reland of commit a247b158d6
Change-Id: Ieec74d6f93c57175c357ec18889144635f5bdca6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249490
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This CL:
* Removed the redirect from .packages to .dart_tool/package_config.json
(whenever such a file existed).
* Removes support for the old format entirely.
* Updates all tests etc that were found.
Fixes https://github.com/dart-lang/sdk/issues/48939
TEST=Existing tests updated.
Change-Id: Iccf711c455ac1885189aa773ca74dd8f55012964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248603
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit 4d750a862d.
Reason for revert: breaks google3 (b/236665701)
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> This is a reland of commit a247b158d6
>
> Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: I02d62d58bae33d6a606a80eb3eee2e8e721a8e20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249620
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
This is a reland of commit a247b158d6
Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit a247b158d6.
Reason for revert: breaks google3. See b/236665701.
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: Ic765eb1401dbff4dea6c08c007c0bf9aff186684
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249188
Reviewed-by: Oleh Prypin <oprypin@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Correctness changes:
Fix SEGV by checking for overflow in computing the length of the
repeated string.
Performance changes:
Use unnested loops to fill the string instead of nested loops.
Implement `operator *` for _TwoByteString in the same way.
(The default implementation using StringBuffer causes a lot of
allocations. For example, `"α" * 10000` repeatedly adds the small
string to the StringBuffer, which repeatedly compresses a sequence of
small strings to make a bigger string to stop the list of parts
becoming too large. This compression creates a lot of small strings
with the same contents.)
Bug: 49289
Change-Id: I06c3d91b531d7e4fffc8de9f3bada3eb62ad185f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249122
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Fixes b/235393918
@staticInterop replaces factories with a new named node, a static
method. In order to persist this transformation in modular
compilation, this needs to be done to outlines that can then be
consumed by the source library. In order to allow erasure at the
time of 'performOutlineTransformations', coreTypes is added to that
API.
Change-Id: I90d17fff8bbe143982fcd12cfb06dc3e8d58781a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247928
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit 0f3dea33f9.
Reason for revert: breaks dart->engine roller as flutter still uses NullThrownError, fails analysis step
Original change's description:
> Deprecate outdated errors, drop `CastError` and `NullThrownError`.
>
> Both `CastError` and `NullThrownError` becomes just (deprecated) aliases for `TypeError`.
>
> `FallThroughError` becomes deprecated. Fall-through was made a compile-time error in Dart 2.0, the error should no longer be used.
>
> `CyclicInitializationError` is deprecated. Null safe Dart doesn't specify which error a late initialization error throws. We use internal errors now.
>
> These errors should not be needed in sound null-safe mode (if they are even needed now), and so should be removed in Dart 3.0.
>
> TEST= No new tests, should not change behavior in a significant way.
>
> Bug: https://github.com/dart-lang/sdk/issues/49141
> Change-Id: I636e9a0d0c32021d40bb819a88a1f57db6efc5a9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247384
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Brian Quinlan <bquinlan@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: https://github.com/dart-lang/sdk/issues/49141
Change-Id: I1b2802ec69fe654525e683527ff3554ff972f0c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248741
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The current implementation uses a specialized version of the
pending-event queue used by stream subscriptions to remember
pending events.
That makes the queue polymorphic, and slightly more complicated than
necessary, and that again makes further refactorings of the
Stream implementation harder.
This change moves the logic from the specialized pending-queue
into a simple function instead, so you only pay for it if you
actually use `Stream.fromIterable`.
Also allows `Stream.fromIterable` to be listened to more than once.
(It uses `Stream.multi` for the general async+sync controller API,
and it would cost extra code to make it only work once.)
Change-Id: I44b2010225cd3d32c2bcdb8a315c94881331bdae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248146
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Both `CastError` and `NullThrownError` becomes just (deprecated) aliases for `TypeError`.
`FallThroughError` becomes deprecated. Fall-through was made a compile-time error in Dart 2.0, the error should no longer be used.
`CyclicInitializationError` is deprecated. Null safe Dart doesn't specify which error a late initialization error throws. We use internal errors now.
These errors should not be needed in sound null-safe mode (if they are even needed now), and so should be removed in Dart 3.0.
TEST= No new tests, should not change behavior in a significant way.
Bug: https://github.com/dart-lang/sdk/issues/49141
Change-Id: I636e9a0d0c32021d40bb819a88a1f57db6efc5a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247384
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Fixes#49241
TEST=ci
Change-Id: I6117bf816fc8c4613cce66927f952fef75632725
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248120
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL fixes a number of minor JS interop issues.
* `dartify` was moved to Dart, so we can control implicit coercion from JS
* All JS types are 'correctly' handled in `dartify` though a few are boxed
as opaque types that could be exposed.
* The logic to convert a JS array is now driven from the Dart side.
* Function, Number, and Boolean can now make the roundtrip through Dart.
* The wrapper for Dart functions in JS is now a regular JS function.
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Change-Id: Ifcd7a447419bca2adf78070e07750c1b3c5c6a18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247925
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
This CL remove the support for mixing in classes that don't extend
Object. An error has been report by the analyzer for some time and
now also by the CFE.
This puts the breaking change https://github.com/dart-lang/sdk/issues/48167 into effect.
TEST=pkg/front_end/testcases/general/issue48167.dart
Change-Id: Ia7715a27dc1aa18a7c85b24ed86d19a91b6924d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247551
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This option was enabled by default in https://dart-review.googlesource.com/c/sdk/+/149288
This change removes old logic behind --no-lazy-async-stacks
and makes --lazy-async-stacks/--no-lazy-async-stacks options no-op.
TEST=ci
Change-Id: I5726690e90e78dd2ac37d8c5944e388042fc3acf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247780
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
C compilers don't enforce nesting rules. `dart:ffi` was enforcing these
rules causing issues for binding to C libraries having looser packing
for nested structs than outer structs.
This CL completely removes the error from the analyzer and CFE.
(As an alternative we could have kept a hint/lint, but this might create
more noise than value.)
TEST=pkg/analyzer/test/src/diagnostics/packed_nesting_non_packed_test.dart
Closes: https://github.com/dart-lang/sdk/issues/46644
Change-Id: Iae2d5c885546f7799bc6dea2f8cd7dd508216a0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247382
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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
69f32d6ad7
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>
This CL consists of:
1) Moving most of the contents of `js_util_wasm_patch` to
`js_util_patch` and `js_helper`.
2) Addressing the inconsistencies between `js_util` and `js_util_wasm`.
3) Fixing a minor bug with nested `allowInterop` in
`js_util_wasm_optimizer`.
4) Removing hardcoded eval.
Change-Id: Ie43cdc91d344745ef9b40e273192b34af2a84138
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246380
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Closes#49165
The empty string argument can be confusing to read since it is not clear
what it means. Allow omitting the argument entirely to default to an
empty path.
R=lrn@google.com
Change-Id: I05ca432a679a0df751a16d1beb241b14f80d4681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246988
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Static class members could technically be mapped to a name with dots,
but in the early days of JSInterop we thought this was not necessary
since it could also be modeled as a top-level member or by adding
additional classes and exposing the member as a simple name on a deeper
class.
This invariant was assumed by DDC (which crashed if this was not the
case) and ignored by dart2js.
This change adds a static check to ensure both compilers act
consistenlty.
Fixes https://github.com/dart-lang/sdk/issues/27926
Change-Id: I20e59fbb75f0378a58ca88dc3910e079b4eeb7a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247180
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
When generating the tear-off stub of a JSInterop method, dart2js
associated the full JSName as the target name, as opposed to a
target path. This meant that code like:
@JS('console.log')
external consoleLog(arg1, [arg2]);
main() => (consoleLog)(1);
Generated a tear-off with code like:
self[console.log](arg);
Instead of:
self.console.log(arg);
Fixes https://github.com/dart-lang/sdk/issues/49129
Change-Id: I7abb320ce790e2ce533031fefd3abc15f8958b5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246340
Reviewed-by: Stephen Adams <sra@google.com>
The new implementation is based on suspend/resume stubs and doesn't
use desugaring of async functions on kernel AST.
Previously, new implementation of async/async* was only supported in
AOT mode. This change adds all necessary bits for the JIT mode:
* Suspending variable-length frames (for unoptimized code).
* Handling of Code and pool pointers in Dart stack frames.
* OSR.
* Deoptimization.
* Hot reload.
* Debugger.
The new implementation is not enabled in JIT mode yet.
Design doc: go/compact-async-await.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I477d6684bdce7cbc1edb179ae2271ff598b7dcc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246081
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This is breaking change #45630.
The Dart VM has until now restored the terminal settings upon exit to
their initial values for stdin, stdout, and stderr. This change removes
that automatic behavior in favor of having the program do the
restoration. Previously the intention was that dart programs can
enable/disable echoing and line buffering and not worry about restoring
the original settings.
However, the VM doing so unconditionally leads to undesirable behavior
e.g. when the program does not care about terminal settings and is
sharing a process group with a program that does care. E.g. if dart's
output is piped into less(1), then there is a race condition where dart
might see the raw terminal settings set by less(1), and if the dart VM
exits after less(1) has exited, then it will restore the raw terminal
settings, leaving the user with a seemingly defective shell with echo
disabled. This race condition can be reproduced using:
cat > yes.dart << EOF
main() {
for (int i = 0; i < 1000000; i++) {
print("yes");
}
}
EOF
stty; (sleep 1 && dart yes.dart) | less; stty; stty sane
The user will end up with a shell with echo behavior disabled. The stty
command shows the current terminal settings, where the difference can be
seen, and 'stty sane' fixes the settings before returning to the shell
prompt. The 'stty sane' call can be omitted to see the defective shell
prompt.
This change removes the terminal restoring behavior (added in Dart
2.0.0) and instead asks applications to do the restoration themselves.
The new design matches how programs in other programming languages
implement interactive input that changes terminal settings.
Furthermore the `echoMode` setting now only controls the `echo` local
mode and no longer sets the `echonl` local mode on POSIX systems (which
controls whether newline are echoed even if the regular echo mode is
disabled). The `echonl` local mode is usually turned off in common shell
environments. Programs that wish to control the `echonl` local mode can
use the new `echoNewlineMode` setting. This change is required to
prevent the reoccurence of #30318 when programs manually restore
`echoMode`.
Windows has further considerations: It also saves the console code pages
and restore them if they were not UTF-8. This behavior is retained as it
is useful and needed for Dart's output to function properly. ANSI output
sequences are also turned on via ENABLE_VIRTUAL_TERMINAL_PROCESSING,
which is slightly changed in this change to only rsetore that setting if
it wasn't already on for consistency.
Closes https://github.com/dart-lang/sdk/issues/36453
Closes https://github.com/dart-lang/sdk/issues/45630
TEST=Reproduced with less as above
Change-Id: I2991f9c7f47b97fe475c1ad6edeb769024f8d0db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190484
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Fixes https://github.com/dart-lang/language/issues/731.
Change-Id: I5fee1470efe7b891b79dcfecd33bc3670590efb3
Tested: trybots, and global presubmit in the internal mono repo
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243530
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Creates a new 'dart:_js_shared_embedded_names' library for the names
accessed from the shared 'dart:_rti' library. Migrate all of the shared
symbols and uses to the new location.
Change-Id: Iaa72c4522888ad630782b921b0b70d7a2626d1b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241507
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This CL moves the bounds checking into the TypeBuilder instead of
performing it from the outside on the computed DartType node.
This solves several problems:
1) Errors are now reported on the type in the code instead of the
declaration which holds the type.
2) Checking of type aliases (both function and nonfunction type
aliases) is now handled correctly in all cases. This achieved by
computed the aliased type (containing TypedefType nodes)
internally and performing the checking on this type, and only
convert the type into the unaliased version (without TypedefType
nodes) after checks have been performed. Previously this handled
through the FunctionType.typedefType property for function type
aliases and through and incomplete work-around for nonfunction
type aliases.
3) With 2) FunctionType.typedefType is no longer needed and is
removed.
TEST=general/bounds_*
Change-Id: I7653bca5ccb0ebf4b3553828a298d1ad918ef235
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243722
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The file type of file backing unix domain sockets was being incorrectly
set as kDoesNotExist resulting in errors when operations like delete
on the file was done. File::Exists on the other hand returned true.
File rename and copyfile functionality have been fixed too.
TEST=new tests added
Please see https://github.com/dart-lang/sdk/issues/48569 for the original issue.
Change-Id: I28505236fbad2ea86ad65065e753b13fb7ff655a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240300
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This CL changes the IL building for reachability fences to their call
sites. This enables us to catch the field load and tell it to not emit
an initialization check for late fields.
The sentinel value will now flow into the ReachabilityFenceInstr, where
it will be discarded.
TEST=tests/language/vm/regress_49005_test.dart
Closes: https://github.com/dart-lang/sdk/issues/49005
Change-Id: Ic21c9905290925eb83860d8394b13be7dd7592c1
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm64c-try,vm-ffi-android-debug-arm-try,vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244628
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This achieves the same thing (test that `hashCode` is not called), but
avoids a costly timeout on failure. This drastically cuts down the total
testing time for the language and corelib suites for dart2wasm (which
intends not to implement a special case here, since it is going to be
illegal in the future anyway).
Change-Id: I040925ebd8271a5816c81bc16484c0a96626857d
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244061
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
As part of the implementation of
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.), I expanded the front end's type inference logic so
that instead of just having a downward phase and an upward phase, it
could have 3 or more phases. The function that previously did
downward inference became repurposed to do "partial inference" (which
could either be the first, downward stage, or a later, horizontal
stage). However, I failed to generalize the logic that prevents types
assigned by one inference stage from being refined by later
stages--previously this logic was only needed for upward inference,
but now it's needed for horizontal inference stages as well. (This
logic is needed because of Dart's "runtime checked covariance"
behavior--it means that we want to stick with the type from downward
inference, even if a later horizontal inference stage is able to find
a more precise type, because that more precise type may lead to
runtime failures).
As part of this change I've re-architected the inference methods so
that they are responsible for creating and returning the list of
inferred types. This makes the inference logic more similar between
the front end and analyzer, and is easier to read IMHO. The total
number of list allocations is the same as before.
Change-Id: I19bfcede9c2968e50f110b571164549f16495217
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243707
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The front end desugars extension methods by inserting a synthetic
`this` argument before all other arguments. But this synthetic
argument isn't included in the `formalTypes` and `actualTypes` arrays.
So when recording a value into
`_DeferredParamInfo.evaluationOrderIndex` we may need to subtract 1 in
order to ensure that later logic will find the correct argument.
Fixes a corner case of https://github.com/dart-lang/language/issues/731.
Change-Id: Idbf136195e40555199f7c5b61a575a430f6ec6bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243854
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This change allows function literals in invocations to be inferred in
dependency order. For example, given the following code:
U f<T, U>(T Function() g, U Function(T) h) => h(g());
test() {
var x = f(() => 0, (y) => [y]);
}
The function literal `() => 0` is inferred first, causing the type
parameter `T` to be assigned the type `int`. Then, `(y) => [x]` is
inferred with the benefit of this type assignment, so `y` gets the
type `int`, and consequently, `U` gets assigned the type `List<int>`.
This completes the support for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.)
Change-Id: I48c22693720a1cc8bbf435643e863834e07f02b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243002
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Don't emit dead code branches that are guarded by boolean literals.
Add a single level of simplification for !true -> false, and
!false -> true.
While this might not be very common in code, it does allow for a
useful pattern in the runtime libraries. Branches can be included
into the compiled code or not based on a compile time flag.
Change-Id: Ib90e1e951cea3ef8c75b944635776b292759594a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243363
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
This null char is inserted by _toNullTerminatedUtf8Array, and right
below that function is _toStringFromUtf8Array, which does the opposite.
But _toStringFromUtf8Array is currently dead code, so it looks like the
intent was always to use _toStringFromUtf8Array for this, and the fact
that utf8.decode was being used instead is just a mistake.
Bug: https://github.com/dart-lang/sdk/issues/34885
Change-Id: I1404c7783b055902b256176aa61971c0d6969f5e
Fixes: https://github.com/dart-lang/sdk/issues/34885
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243103
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
When a function literal is wrapped in parentheses, it shouldn't affect
how it interacts with type inference. This change ensures that
parenthesized function literals are treated the same as
unparenthesized ones by the logic that supports
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.)
Change-Id: I672787a31addbfe3f3282b6e638e00b693eea46f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243000
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The new implementation moves away from desugaring of async
functions on kernel AST, state machine generated in the flow graph and
capturing all local variables in the context.
Instead, async/await is implemented using a few stubs
(InitSuspendableFunction, Suspend, Resume, Return and
AsyncExceptionHandler). The stubs are implemented in a
platform-independent way using (macro-)assembler helpers.
When suspending a function, its frame is copied into a SuspendState
object, and when resuming a function it is copied back onto the stack.
No extra code is generated for accessing local variables.
Callback closures are created lazily on the first await.
Design doc: go/compact-async-await.
Part 1 (kernel): https://dart-review.googlesource.com/c/sdk/+/241842
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: Ibad757035b7cc438ebdff80b460728b1d3eff1f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242000
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Some JS functionality is only exposed through operators, such as
implicit type conversions and BigInt arithmetic. Other than requiring
some minor additions for the exponentiation (`**`) operator, supporting
these through `dart:js_util` is trivial.
Change-Id: I010674303e4f99b42d43b73095de69b8ddcdeb47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242680
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
In the definition of `_computeExplicitlyTypedParameterSet`, I
accidentally nested the declaration of `unnamedParameterIndex` inside
the `for` loop, defeating the increment and causing all parameters to
be considered to have index 0.
I've included a test case that would have caught the mistake.
Bug: https://github.com/dart-lang/language/issues/731
Change-Id: I0cd0e1e5b481313150e495d370af2477253d6637
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
These tests exercise the "deferred type inference of function
literals" part of https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.) for super-constructor invocations
and redirecting constructor invocations, both of which have their own
code paths in the analyzer.
Change-Id: I6877ac3c07a3cca31550ba74d941d250c8410cfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241987
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This fixes an issue where VM would run the async* generator after a
`yield` / `yield*` even though the subscription may be paused or
cancelled.
Furthermore this fixes an issue where `StackTrace.current` used
in async* generator crashes VM and/or produces truncated stack
trace.
This fixes the following existing tests that were failing before:
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t08
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t09
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t10
* language/async_star/async_star_cancel_test
* language/async_star/pause_test
New in reland: Allow the generator to to cause cancelling it's own consumer.
This addresses the issue of original revert
-> see https://github.com/flutter/flutter/issues/101514
Issue https://github.com/flutter/flutter/issues/100441
Issue https://github.com/dart-lang/sdk/issues/48695
Issue https://github.com/dart-lang/sdk/issues/34775
TEST=vm/dart{,_2}/causal_stacks/flutter_regress_100441_test
Change-Id: I091b7159d59ea15fc31162b4b6b17260d523d7cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242400
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This avoids json encoding that was otherwise happening even in product mode. JSON encoding shows up CPU profiling as taking significant time, particularly on low end devices.
TEST=runtime/observatory/tests/service/developer_extension_test.dart
Bug: https://github.com/dart-lang/sdk/issues/48860
Change-Id: I2cf4d949e85c0b23de01ec2033b04527d40c76fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242081
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Dan Field <dnfield@google.com>
Currently we do not collect constants from UnevaluatedContants.
Change-Id: Ie9ff2cd09cdd654f2294f4eee42edbfdc652695f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242220
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Previously the tear-offs created for the origin constructors were not
replaced with the tear-offs created for the patch constructors - as is
normally done for the constructors themselves. This lead the tear-offs
to refer to unlowered code, breaking dart2js.
Closes https://github.com/dart-lang/sdk/issues/48776
Change-Id: I1cb09c07bb2ac7fffb81acd31547ee96e7ecdc64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242284
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The `toString` used the sign of `hours` to get a leading `-`
when the duration is negative. However, a negative duration of
less than one hour would therefore miss out on the sign,
because `-0` is not an integer.
Now handles sign explicitly.
Fixes#48841.
Change-Id: I0ab6d451faf1c76b838fc35a692f07c5b035d2a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241748
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This fixes https://github.com/dart-lang/sdk/issues/48848
When the base URI is just a filename, then base was empty, and we accidentally
added a / in the first position. This made the deferred URI absolute by
mistake.
Change-Id: I4d6a773f6ef8bfefbbf61417bfe7c005aa5e63ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241990
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Adds an experimental `@trustTypes` annotation which can be used during
migration to static interop to preserve the older semantics for JS interop.
Change-Id: Ic00a6c968b15f8c8f5d0840b82db5a6670eaf0eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241362
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Having first-class Wasm function references makes it possible to call
JS function objects directly from Dart, and to call some Dart functions
(static functions with no optional parameters and no type parameters)
from JS as function objects.
Change-Id: I1c788338d418c8857493ec76560d74fdd17d5dd2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241001
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This extends the fix for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.) to cover situations where the function literal passed
to an invocation is enclosed in (unnecessary) parentheses.
Change-Id: I5eb40cf73336612e241a930122f8ae7b1c25bb2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The purpose of horizontal inference is to allow the types of closure
parameters to be inferred based on the static type of other arguments
in the same invocation. When the closure parameter in question
already has an explicit type, there is no benefit, and there are
potential drawbacks (because horizontal inference could infer too
narrow a type).
This change includes the explicitness/implicitness of closure
parameter types in the dependency analysis for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.) so that we won't do horizontal inference when it's not
needed.
Change-Id: I33781877685867a8fcb40de54fc055f6348c21b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240505
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change addresses a corner case discovered during internal testing
of the fix for https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.): if there is no order dependency
forcing us to do a round of horizontal inference between visiting
non-closure arguments and closure arguments, then it's important that
we *don't* do a round of horizontal inference before visiting the
closure, because there is a risk of inferring too narrow a type.
The new algorithm includes all the invocation arguments in dependency
analysis, and the dependency rules are structured such that
non-closure arguments always wind up in stage 1. If there is no
dependency between non-closure arguments and closure arguments, then
the closure arguments also wind up in stage 1, and no horizontal
inference occurs. If there is a dependency, then closure arguments
wind up in stage 2 or later, and horizontal inference occurs between
stages.
Change-Id: Ida0b28da211f63191c9c9c39e6004893617507bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240442
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This CL adds a test of the evaluation order in the case where a function
invocation `g(a)` or `r.g(a)` involves the invocation of a getter `g` that
returns a function object, and that function object is invoked with an
actual argument `a`.
The expectation in the test is that evaluation occurs left-to-right in
every case, with one exception: when `g` is a class instance getter (this
does not apply to extension instance getters) the actual argument list
is evaluated before the getter. This is the actually implemented behavior,
and the specification is being updated to specify this behavior
(cf. https://github.com/dart-lang/language/pull/2182).
------- Old description:
A piece of technical debt which has been around for several years is the
fact that the specified left-to-right evaluation order isn't implemented
everywhere.
In particular, with an ordinary invocation like `r.m(a)` where `m` is a
getter that returns a function, the argument is evaluated before the
getter is called, which is not a left-to-right ordering.
This CL adds a test (with 2 libraries) where the evaluation order is
detected, such that we can decide how to proceed.
Change-Id: Ia2619fe6b4c4cf4cec63bac9c9f834306bdefe52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238903
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This reverts commit 837ee17b43.
Reason for revert: Please see https://github.com/flutter/flutter/issues/101514
Original change's description:
> [vm] Fix some async* semantics issues: Only run generator if there's active subscription (not paused/cancelled)
>
> This fixes an issue where VM would run the async* generator after a
> `yield` / `yield*` even though the subscription may be paused or
> cancelled.
>
> Furthermore this fixes an issue where `StackTrace.current` used
> in async* generator crashes VM and/or produces truncated stack
> trace.
>
> This fixes the following existing tests that were failing before:
>
> * co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t08
> * co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t09
> * co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t10
> * language/async_star/async_star_cancel_test
> * language/async_star/pause_test
>
> Issue https://github.com/flutter/flutter/issues/100441
> Issue https://github.com/dart-lang/sdk/issues/48695
> Issue https://github.com/dart-lang/sdk/issues/34775
>
> TEST=vm/dart{,_2}/causal_stacks/flutter_regress_100441_test
>
> Change-Id: I73f7d0b70937a3e3766b992740fa6fe6e6d57cec
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239421
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Ic3d9c0508310a33a2aaee67860c0bb2ec83bab4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240506
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Global type inference incorrectly handles conditions nested within
subexpressions and accidentally carries information from those
in the context of outer conditions.
Change-Id: I99e0af3da65590acb9429771b318b7da8f3b7f14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240320
Reviewed-by: Stephen Adams <sra@google.com>
This fixes an issue where VM would run the async* generator after a
`yield` / `yield*` even though the subscription may be paused or
cancelled.
Furthermore this fixes an issue where `StackTrace.current` used
in async* generator crashes VM and/or produces truncated stack
trace.
This fixes the following existing tests that were failing before:
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t08
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t09
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t10
* language/async_star/async_star_cancel_test
* language/async_star/pause_test
Issue https://github.com/flutter/flutter/issues/100441
Issue https://github.com/dart-lang/sdk/issues/48695
Issue https://github.com/dart-lang/sdk/issues/34775
TEST=vm/dart{,_2}/causal_stacks/flutter_regress_100441_test
Change-Id: I73f7d0b70937a3e3766b992740fa6fe6e6d57cec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239421
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit dbe6d1d574.
Reason for revert: One of the new tests spawns a process and runs the script from source and so this test will fail on all AOT configurations, In addition it is failing on mac builds and needs investigation.
Original change's description:
> [VM/io] - Set correct file type for files backing unix domain sockets
>
> The file type of file backing unix domain sockets was being incorrectly
> set as kDoesNotExist resulting in errors when operations like delete
> on the file was done. File::Exists on the other hand returned true.
> File rename and copyfile functionality have been fixed too.
>
> TEST=new tests added
>
> Please see https://github.com/dart-lang/sdk/issues/48569 for the original issue.
> Change-Id: Ie9c716c84b1d818c906ecdb622ba930125f9ee30
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237745
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
TBR=rmacnak@google.com,asiva@google.com
Change-Id: I517896fb90b013af1ce9a6754442a922e2b7cda5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240149
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
The file type of file backing unix domain sockets was being incorrectly
set as kDoesNotExist resulting in errors when operations like delete
on the file was done. File::Exists on the other hand returned true.
File rename and copyfile functionality have been fixed too.
TEST=new tests added
Please see https://github.com/dart-lang/sdk/issues/48569 for the original issue.
Change-Id: Ie9c716c84b1d818c906ecdb622ba930125f9ee30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237745
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
OSError code of 0
One such example was _SecurityContext.setTrustedCertificatesBytes
TEST=new tests added
Change-Id: Ibc5d06b83bb1bb93e12f79100acc60546554c268
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239863
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
The updates the messaging for when experimental features are not
enabled to take into account whether the feature has been released
and whether an explicit or implicit language version opt out the
feature.
Change-Id: I77c31e7e327d1beca2dd4a82dbaf648711894e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239663
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This change enhances support for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.) by allowing closures in invocations to be inferred in
dependency order. For example, given the following code:
U f<T, U>(T Function() g, U Function(T) h) => h(g());
test() {
var x = f(() => 0, (y) => [y]);
}
The closure `() => 0` is inferred first, causing the type parameter
`T` to be assigned the type `int`. Then, `(y) => [x]` is inferred
with the benefit of this type assignment, so `y` gets the type `int`,
and consequently, `U` gets assigned the type `List<int>`.
Change-Id: Ia0028a7f3fc8cdc78fbdf2c10c3b8d7b82a9006a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239461
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The current VM closure serialization makes this function a foot-gun.
Revert until the supporting features are improved, so as to not give
users a bad experience.
Change-Id: I83b6b453ce5ab00d49ffbf36a5763119a6435352
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237940
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This is a fork of `js_util` to support the needs of Wasm. It is very
much a WIP. We're landing this now to facilitate prototyping, and so we
can get a sense of what the right JS interop API might look like for
Wasm.
Change-Id: I8b2ddda07e906f1938d4cd5fe0e63203e9cdd6d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230120
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Various cleanups to the TypeBuilder classes:
TypeBuilder:
* Remove `origin` parameter from TypeBuilder.build and instead make
FunctionType.typedefType mutable and set if after creation.
* Remove `charOffset` and `fileUri` parameters from
TypeBuilder.buildSupertype/buildMixedInType
* Remove `bind`, `resolveIn`, and `check` from TypeBuilder so that
these are only present on NamedTypeBuilder
* Remove TypeBuilder.buildTypeLiteralType and instead pass an
argument to NamedTypeBuilder that determines what type to create
on `build`.
NamedTypeBuilder:
* Make NamedTypeBuilder.instanceTypeVariableAccess private
* Add NamedTypeBuilder.forDartType for prebuilt types
* Add NamedTypeBuilder.forInvalidType for types created for errors
* Make NamedTypeBuilder.declaration private and corresponding getter
* Check most type use errors on NamedTypeBuilder.bind
* Make NamedTypeBuilder helper methods private
* Add `TypeVariableBuilder.isClassParameter` to support checking for
valid type variable use through the `NamedTypeBuilder.bind` method.
* Remove checking of type variable in static context from BodyBuilder
since it is now checking on `NamedTypeBuilder.bind`.
FunctionTypeBuilder:
* Cache result of FunctionTypeBuilder.build
TypeBuilderComputer:
* Cache "constant" type declarations in TypeBuilderComputer
Change-Id: Ibaedcb255487eecc5efe70b84e5cbd5a118c1e0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239023
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The co19 cipd packages are now made automatically.
Bug: b/218296230
Change-Id: I3fe051517bb6e1307204b28ba9c4eb6de440252f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239063
Reviewed-by: Alexander Thomas <athom@google.com>
The diff from
https://dart-review.googlesource.com/c/sdk/+/229156/1..3
This was blocked by https://github.com/timsneath/win32/issues/349
earlier. Now that that has been resolved, we should be able to land
this.
We should land this to make package:ffigen be able to bind to `char` in
Dart 2.17.
https://github.com/dart-lang/ffigen/pull/287#discussion_r835734993
TEST=tests/ffi/c_types_test.dart
Change-Id: Ia3bc3785a3d5c0c9f7475106eb77f944f2d0a838
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-ia32-try,vm-kernel-nnbd-mac-debug-arm64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-precomp-ffi-qemu-linux-release-riscv64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239020
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL implements `NativeFinalizer` in the GC.
`FinalizerEntry`s are extended to track `external_size` and in which
`Heap::Space` the finalizable value is.
On attaching a native finalizer, the external size is added to the
relevant heap. When the finalizable value is promoted from new to old
space, the external size is promoted as well. And when a native
finalizer is run or is detached, the external size is removed from the
relevant heap again.
In contrast to Dart `Finalizer`s, `NativeFinalizer`s are run on isolate
shutdown.
When the `NativeFinalizer`s themselves are collected, the finalizers are
not run. Users should stick the native finalizer in a global variable to
ensure finalization. We will revisit this design when we add send and
exit support, because there is a design space to explore what to do in
that case. This current solution promises the least to users.
In this implementation native finalizers have a Dart entry to clean up
the entries from the `all_entries` field of the finalizer. We should
consider using another data structure that avoids the need for this Dart
entry. See the TODO left in the code.
Bug: https://github.com/dart-lang/sdk/issues/47777
TEST=runtime/tests/vm/dart(_2)/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
TEST=tests/ffi(_2)/vmspecific_native_finalizer_*
Change-Id: I8f594c80c3c344ad83e1f2de10de028eb8456121
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-ffi-android-debug-arm64c-try,dart-sdk-mac-arm64-try,vm-kernel-mac-release-arm64-try,pkg-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-nnbd-win-release-ia32-try,vm-ffi-android-debug-arm-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,benchmark-linux-try,flutter-frontend-try,pkg-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The order of operations for type inference of a generic invocation is
now:
1. Create some constraints on type parameters by trying to match the
return type of the invocation target as a subtype of the incoming
type context. (For a constructor invocation, the return type of
the invocation target is considered the raw uninstantiated type of
the class enclosing the constructor declaration.)
2. Downwards inference: partially solve the set of type constraints
accumulated in step 1, to produce a preliminary mapping of type
parameters to type schemas.
3. Recursively infer all arguments to the invocation, except that if
experimental feature `inference-update-1` is enabled, skip any
arguments that are function literals (a.k.a. "closures"). Obtain
the type contexts for the recursive inference by substituting the
preliminary mapping (from step 2) into the corresponding parameter
types of the invocation target. For each argument that is
recursively inferred, create additional constraints on type
parameters using the resulting static type.
4. If no arguments were skipped during step 3, go to step 7 (this
always happens if `inference-update-1` is disabled).
5. Horizontal inference: partially solve the set of type constraints
accumulated so far, to produce an updated preliminary mapping of
type parameters to type schemas.
6. Recursively infer all of the invocation arguments that were
previously skipped. As in step 3, obtain the type contexts for the
recursive inference by substituting the preliminary mapping (this
time from step 5) into the corresponding parameter types of the
invocation target. Again, for each argument that is recursively
inferred, create additional constraints on type parameters using
the resulting static type.
7. Upwards inference: solve the set of type constraints accumulated so
far, to produce a final mapping of type parameters to types. Check
that each type is a subtype of the bound of its corresponding type
parameter.
8. Check that the static type of each argument is assignable to the
type obtained by substituting the final mapping (from step 7) into
the corresponding parameter type of the invocation target.
9. Finally, obtain the static type of the invocation by substituting
the final mapping (from step 7) into the return type of the
invocation target.
This addresses simpler cases of
https://github.com/dart-lang/language/issues/731. Note that if
experimental flag `inference-update-1` is disabled, the behavior is
unchanged.
Note that steps 2 and 5 use the same algorithm as each other (they
only differ in how many type constraints have been accumulated so
far), so I've renamed the function that performs it from
`downwardsInfer` to `partialInfer`.
Change-Id: I10d3288d4f4ba9e2b6bc18409186ddc67ca2ee9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238881
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In order to address https://github.com/dart-lang/language/issues/731
(improved type inference for `fold` etc.) we're going to need to
sometimes defer analysis of invocation arguments that are closures, so
that closure parameters can have their types inferred based on other
parameters. To avoid annoying the user with inconsistent behaviors,
we defer analysis of closures in all circumstances, even if it's not
necessary to do so for type inference purposes.
This has a minor user-visible effect: if an invocation contains some
closures and some non-closures, any demotions that happen due to write
captures in the closures are postponed until the end of the
invocation; this means that the write-captured variables remain
promoted for other invocation arguments, even if those arguments
appear after the closure. This is safe because there is no way for
the closure to be called until after all of the other invocation
arguments are evaluated. See the language tests in this CL for
details.
Note that this change only has an effect when the experimental feature
`inference-update-1` is enabled.
Change-Id: I283fc5eb07af2aeca0a06d523011d8c4617fbad7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237720
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This cl applies the mixin transform only on the full dill. In addition,
this cl also adds a concatenate dills step to more closely match
modular builds in production.
Change-Id: Icb37c5e2180c9e8246334143a6f772a203f80bf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238320
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Closes https://github.com/dart-lang/sdk/issues/48630
'mark' can return undefined in Firefox, and therefore needs to
return a nullable. Similarly, the different syntaxes of 'measure'
don't work in Firefox or Safari, so the incompatible ones are
removed from tests.
Change-Id: Ia137fe0d72ddbaad03ae8cf58c43736b128b3f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237930
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/48430
Adds overloads for both methods to accept additional/different options.
Also changes return types:
- mark returns a PerformanceEntry
- measure returns a PerformanceMeasure, but this may be undefined, so it's
marked as nullable
Change-Id: I189c4613b19e214a1f5bcc5bbd780d9dc447d9e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235286
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Optional arguments (positional and named) in @FfiNative
annotations are not meaningful, and should result in a
compile-time error.
TEST=tests/ffi/ffi_native_test.dart
Bug: https://github.com/dart-lang/sdk/issues/47169
Change-Id: I8896e6a43f9399b537e6ee7c7a0e2857a370203f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232622
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
Subclasses of the _Function class are generated on the fly as fields
with function types are encountered. Therefore, this class must be early
in the initialization order.
Change-Id: Ia0b998c443af9f6bdb4af512f6da99e6e3767c1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237681
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Should make this test run within the normal timeout period.
TEST=ci
Change-Id: Ie8048a6cc7c31b193cf326bf9742fad279411b44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237688
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
It had bit rotted slightly: we were not properly accounting for
variance when gathering type inference constraints from the comparison
of two interface types.
Also, some of the tests needed to be updated to account for follow-on
errors.
Change-Id: Ife9feae3e2180a179ebc8503751690789dc1483e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `regress` folder in tests/web and tests/web_2 has been renamed to
`issue`. All issue-numbered tests have been placed there; other tests
have been moved out of that folder.
Change-Id: I4534d34b2ef21f7accc45c3ce097d9be74845e4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235984
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Failed to close the receive-port if `Isolate.spawn` threw
asynchronously, which would keep the isolate alive forever.
Fixes#48516
BUG= http://dartbug.com/48516
Change-Id: If53a868bcc6a11aef9123e95a7dfe47d25932c4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235603
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Closes https://github.com/dart-lang/sdk/issues/48515
Expands existing checks for index operations to all operators. This
only affects instance members and not extension members.
Change-Id: I8cbb5b12a49539ea502e4396e1b469ffb0e17d5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235980
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Note that unlike x86 and ARM, RISC-V has no carry flag, so we must synthesize the carry in a GPR using sltu.
TEST=ci, RSA
Change-Id: I24898cb8b7166d5769ae98c535ec29b2206340d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235063
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
The tear-off lowering for a redirecting factory called the
immediate target (even when this was also a redirecting factory)
instead of the effective target. This caused problem in backends
that don't support redirecting factories directly.
Closes https://github.com/dart-lang/sdk/issues/47916
Change-Id: Iafb11c42c1e99e70ed44b0835473a8c69e995b01
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235780
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds formatting support for upcoming language features:
- Named arguments anywhere
- Enhanced enums
- "super." parameters
It doesn't change the formatting of any existing code, so it should be
safe to roll this in without coordinating a pre-built SDK roll.
I also went ahead and ran the formatter on the related language tests
since before now they couldn't be formatted. (And I incidentally ran
the formatter on the other enum tests sitting in the same directory.)
Edit: Actually there is one small change to existing formatting: enum
declarations will now get a blank line inserted before them. Most hand
authored enums already have this so will be unchanged but I see a few
diffs when formatting generated code.
Change-Id: Icefd9f10bedc589312396cf0ddb8eafc418f8dbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235284
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
The Selector computed for InstanceGetterInvocation used the name of
the getter eventhough the invocation is actually a .call invocation.
This lead the computation of whether type arguments need to be parsed
to fail because it queried with the wrong selector.
Closes https://github.com/dart-lang/sdk/issues/48304
Change-Id: Ia08fb91fa24b5b04eba850f75f9b66cb89494dda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/234288
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Unfortunately we have to give up on eager initialization of many maps
and sets due to unknown dependencies and effects in the hashCode
implemenation. Eager initialization of some cases could be recovered
as they are eligible to be `const` maps and sets.
Fixed: https://github.com/dart-lang/sdk/issues/48442
Change-Id: I6500123ff9d1fe42bacb53718a4b9e4e969ebc3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233942
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Currently, we decide whether to insert an implicit `.call` tearoff on
an expression based on the type the expression is being assigned to,
whereas the spec says that we decide it based on the context type.
In most cases, these are the same type, however when assigning to a
promoted variable, the context type is the promoted type, whereas the
"type being assigned to" is the unpromoted type.
Previously, we had no language tests of this behavior; it just emerged
naturally from the way it was implemented in the CFE. This test locks
down the behavior so that we won't change it by mistake.
We may, at some future time, decide to change it on purpose though.
Discussion about this behavior is ongoing on the langauge team.
Change-Id: I82f54c8875fd3b5829c5f75a676fdaf5eea64703
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233650
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add `isMimeType` method to `UriData` class, to allow case-insensitive
checking of the MIME type.
Add `isCharset` and `isEncoding` methods to `UriData` class,
to allow case-insensitive and alternative-encoding-name aware checking
of the MIME type "charset" parameter.
Make `UriData.fromString` and `UriData.fromBytes` recognize and omit
a "text/plain" `mimeType` even if it is not all lower-case.
Be case-insensitive in a few cases where we weren't before
(like the `charset` getter not recognizing `CHARSET=utf-8`.)
Fixes#28592
TEST=corelib/data_uri_test.dart updated
BUG= http://dartbug.com/28592
Change-Id: Ia885af69d271856af7fadfe93851e07eff6ddca2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217366
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This CL makes a lot of small corrections in enhanced_enums_basic_test,
e.g., references to variables whose name is slightly different in the
declaration and at the use site.
[Edit: This CL no longer adds a new test, `enhanced_enums_error_test`
already covers all the situations tested by that new test.]
Change-Id: I9d2aabd5ab740b91463eff12a5c676136bf4ec04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233384
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Previously, when inserting an implicit `.call` tearoff on the RHS of
an assignment, both the analyzer and the CFE failed to properly
propagate the type of the tearoff to the static type of the assignment
expression. This resulted in a soundness bug for compiled programs.
Fixes#48409.
Fixes#48410.
Bug: https://github.com/dart-lang/sdk/issues/48409, https://github.com/dart-lang/sdk/issues/48410
Change-Id: I489f38bd7cac4ebadd3746ec32c1ef0f73e18169
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233640
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tests check that expected errors actually happen.
There might be *too many* error markers in the tests,
since it's not clear *where* an error is reported.
Is a naming conflict reported for one or both conflicting declarations?
Is a conflict reported on the class declaration or on a conflicting
declaration?
The front-ends might need to remove themselves from some of the errors,
when the error reporting strategy is decided, but they should report
at least *one* error for each problem.
Also fixed bugs in the non-error `enhanced_enum_basic_test.dart` file.
Change-Id: I673244d1d5a8803e5b49d53150a2b3ab47522c89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231950
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Change-Id: Ibfff039ddbba1e805c07f6eeec75d959c607d196
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233162
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL
* Makes :async_op only have two parameters: We take advantage
of the fact that errors not only have exception != null but
also stacktrace != null.
* Makes :async_op have no optional parameters. This reduces
code size significantly.
* Removes unused parameter in _awaitHelper calls
* Wrap the then callback instead of the error callback. (needed
to make optional parameters required)
This results in 2% code savings on a big g3 app.
The size of :async_op shrinks on average by 11%
TEST=ci
Change-Id: I38d5fba4ebebc780b48dac5aa6a250d2c7952bfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233362
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>