| commit | 5cb3b37c74c4e8033c36e8a82adff05b8d05fdeb | [log] [tgz] |
|---|---|---|
| author | Siva Annamalai <asiva@google.com> | Thu Jun 09 16:51:55 2022 +0000 |
| committer | Commit Bot <commit-bot@chromium.org> | Thu Jun 09 16:51:55 2022 +0000 |
| tree | 1ed731b31a6641def4a5f8b0cbb404a09320fa2c | |
| parent | 83b50a70c8ac8e7d22e8b10d7326ea0c4da93b1e [diff] |
Revert "Refactor `_Future`." This reverts commit 69f32d6ad7e724e3148cb2eb6601e63165e76ad3. Reason for revert: We seem to have a number of tests failing with timeouts in CBUILD after this change, please see logs at https://dart-in-g3-qa-prod.corp.google.com/dg3/Home#/cbuild/find/69f32d6ad7e724e3148cb2eb6601e63165e76ad3 Original change's description: > Refactor `_Future`. > > This is a major rewrite of the `_Future` class, > which is the default implementation of the `Future` interface. > > The main goal was to reduce the number of expensive type checks > in the internal passing around of data. > Expensive type checks are things like > * `is _Future<T>` (more expensive than just `is _Future`, the latter > can be a single class-ID check. > * Covariant generic parameter checks (using `T` covariantly in a > parameter forces a run-time type check). > > Also removed some plain unnecessary casts and turned some > implicit casts from `dynamic` into `unsafeCast`s. > > This seems to be an success, at least on very primitive benchmarks, according to Golem: > FutureCatchErrorTest 41.22% (1.9 noise) > FutureValueTest 46.51% (2.8 noise) > EmptyFutureTest 59.15% (3.1 noise) > FutureWhenCompleteTest 51.10% (3.2 noise) > > A secondary goal was to clean up a very old and messy class, > and make it clearer for other `dart:async` how to interact > with the future. > > The change has a memory cost: The `_FutureListener<S,T>` class, > which represents a `then`, `catchError` or `whenComplete` > call on a `_Future`, now contains a reference to its source future, > the one which provides the inputs to the callbacks, > as well as the result future returned by the call. > That's one extra memory slot per listener. > > In return, the `_FutureListener` now does not need to > get its source future as an argument, which needs a covariant > generic type check, and the methods of `_Future` can be written > in a way which ignores the type parameters of both `_Future` > and `_FutureListener`, which reduces complex type checks > significantly. > > In general, typed code is in `_FutureListener`, which knows both > the source and target types of the listener callbacks, and which > contains the futures already at that type, so no extra type checking > is needed. > The `_Future` class is mostly untyped, except for its "public" > API, called by other classes, which checks inputs, > and code interacting with non-native futures. > Invariants ensure that only correctly typed values > are stored in the untyped shared `_resultOrListeners` field > on `_Future`, as determined by its `_state` integer. > (This was already partially true, and has simply been made > more consistent.) > > Further, we now throw an error in a situation that was previously > unhandled: When a `_Future` is completed with *itself*. > That would ensure that the future would never complete > (it waits for itself to complete before it can complete), > and may potentially have caused weird loops in the representation. > In practice, it probably never happens. Now it makes the error > fail with an error. > Currently a private `_FutureCyclicDependencyError` which presents > as an `UnsupportedError`. > That avoids code like > ```dart > import "dart:async"; > void main() { > var c = Completer(); > c.complete(c.future); // bad. > print("well!"); > var d = Completer(); > d.complete(c.future); > print("shucks!"); > } > ``` > from hanging the runtime by busily searching for the end of a cycle. > > See https://github.com/dart-lang/sdk/issues/48225 > Fixes #48225 > > TEST= refactoring covered by existing tests, few new tests. > > Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4 > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241 > Reviewed-by: Martin Kustermann <kustermann@google.com> > Commit-Queue: Lasse Nielsen <lrn@google.com> TBR=lrn@google.com,kustermann@google.com,sra@google.com,sigmund@google.com,nshahan@google.com Change-Id: I455be5a04b4c346df26d4ded0fa7388baccb0f8c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247762 Reviewed-by: Siva Annamalai <asiva@google.com> Reviewed-by: Alexander Aprelev <aam@google.com> Commit-Queue: Alexander Aprelev <aam@google.com>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.