Two follow-on optimization would reduce the generated code to closer to the original size:
- It would be profitable to write an optimization the removes the type
information from any list when it can be proven the type information
is not used.
- Provided the split result list is not modified, we can strengthen
accesses to be non-null Strings.
Bug: https://github.com/dart-lang/sdk/issues/30548
Change-Id: I87ecdd129ec0227f982bd2e1f34193b3d6b0d81b
Reviewed-on: https://dart-review.googlesource.com/35081
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: Idf83e7f5dfb95e0097fa73fa0a0ecd68c76d2ac9
Reviewed-on: https://dart-review.googlesource.com/35381
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Change Fasta type inference and Kernel type checking to use the new
definition for Future flattening, which is really unwrapping (peeling
off one layer of Future or FutureOr). Use this for inferring types of
`await` expressions and return types from `async` functions.
Ensure that we are using the same notion of flattening for inference
and checking. (Maybe it was a red flag that we weren't.)
This fixes await_test so that it produces a runtime error rather than
a compile time error - see #31541.
A similar change will need to be made to the analyzer - see #31887.
Change-Id: I7d936e9788969a48fdc216628eaa793389fb5e30
Reviewed-on: https://dart-review.googlesource.com/34504
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Remove use of castTo, which is not yet available in the prebuilt SDK used to build Observatory.
Bug: https://github.com/dart-lang/sdk/issues/31587
Change-Id: Ia118710a2c4dca1851935d284e1a78a9c6517256
Reviewed-on: https://dart-review.googlesource.com/34022
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- Added JS_GET_FLAG('STRONG_MODE') allow the code to be tailored to
the type system version.
- Split type stringifying code into V1 (existing logic) and V2
(strong mode Dart 2.0 logic).
The V1 code will eventually be deleted.
Change-Id: I78db91796040b6ecfa1bd5d6a9d64bd4c2bc4bcf
Reviewed-on: https://dart-review.googlesource.com/33680
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
I also added safe-printed irritant to the message, which in the case
of a primitive value or closure would tell you what value is causing
the problem.
Bug:
Change-Id: I530f5185f06d54ddc2ad4d45e11fa08b71213338
Reviewed-on: https://dart-review.googlesource.com/33260
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Update some documentation.
Change-Id: I4e05d89e84bd35068ca57917e752af235c62b647
Reviewed-on: https://dart-review.googlesource.com/32762
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
'Normalize' the data used for loading deferred libraries. Replace
URIs and SHA1 hashes with indexes so that the URIs and hashes occur
once.
Bug: https://github.com/dart-lang/sdk/issues/29635
Change-Id: I3ac8791ad44ca588cbb1bd7d86f18243c956a04a
Reviewed-on: https://dart-review.googlesource.com/32505
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Start by adding static castTo method to the interfaces. This provides everybody with the
desired implementation without exposing the classes.
When implementing the cast method, the recommended way is to (extend the base class,
but if you choose not to ...) use the castTo method.
If we ever get a language feature, we can implement the castTo method using that,
without being stuck with an unnecessary class.
Change-Id: I53274e60c88a4de519bead85d2ca44c1065a9c1a
Reviewed-on: https://dart-review.googlesource.com/26620
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Also, updated status files to correctly fix failures in FF, IE and removed other spurious status entries.
R=alanknight@google.com,vsm@google.com
Change-Id: Ic965103d892ff4d5d119712e3187e829f57cd022
Reviewed-on: https://dart-review.googlesource.com/31800
Reviewed-by: Terry Lucas <terry@google.com>
This reverts commit 0c8294e4a0.
Bug:
Change-Id: Idb35c64fd5365f2669e8aff45765fed74e0f0766
Reviewed-on: https://dart-review.googlesource.com/31440
Commit-Queue: Terry Lucas <terry@google.com>
Reviewed-by: Terry Lucas <terry@google.com>
@Experimental is already defined in dart:html. Adding the same
annotation to dart:core breaks the build. Removing the annotation from
dart:html and adding it to dart:core is a breaking change, e.g.
if someone has said "import 'dart:html' show Experimental".
This annotation is for use in the upcoming dart:standalone with
the waitFor(Future f) function:
https://dart-review.googlesource.com/c/sdk/+/29449
Change-Id: Iea2f537a2ae89a6097c4284084a2a168e833bb04
Reviewed-on: https://dart-review.googlesource.com/30261
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
In 5a44162c97 in attempt to adhere to declared
method signatures we lost zero-copying JSON decoding of responses from
VM: `Message.sendToVM` was changed to always decode the response into
string before passing it to the caller and the logic to use fused
JSON decoding was removed. This increased peak memory consumption by
the VM Service.
This commit addresses the issue by restoring the zero-copying JSON decoding
logic while adding a wrapper around responses that make it clear what kind
of data is passed around and how that data is encoded and handled.
We introduce a class `Response` which can contain either a Dart string, a
binary data (represented as a Uint8List) or utf8 encoded string (represented
as a Uint8List). This class is used in all places where previously a String
or dynamic were used, e.g. MessageRouter.routeRequest is changed to return
Future<Response> rather than Future<String>. This allows callees to
decode JSON responses without copying them into Dart heap while
maintaining sufficient level of typing to make the code easy to reason about.
This commit also removes some dead code from the VM service related to old
Service API and TAR assets unpacking (which has been long done in C++).
Bug: https://github.com/flutter/flutter/issues/13626
Change-Id: Ifbba56944a552034a0f802a965a313326a1236e7
Reviewed-on: https://dart-review.googlesource.com/30280
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
These members were defined as returning Future<Socket>, but the
implementation in _Socket didn't conform to the interface. There's no
reason these members need to return Future<Socket> anyway, so just
change them to return Future<dynamic>.
Avoids a strong mode error in socket_patch.dart.
Change-Id: Icdda5c7880daf0241e36f1d35e61d171f1694409
Reviewed-on: https://dart-review.googlesource.com/29741
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change-Id: I3f90979fad2681775cae56d499f3ff5968ea6485
Reviewed-on: https://dart-review.googlesource.com/29545
Commit-Queue: Terry Lucas <terry@google.com>
Reviewed-by: Terry Lucas <terry@google.com>
Moved `parseRadix` into a separate test where it doesn't do 10 iterations.
This reverts commit ab4061471b.
Change-Id: Ie48216c2f4f077dc86f915a54021c39706c432e8
Reviewed-on: https://dart-review.googlesource.com/29593
Reviewed-by: Florian Loitsch <floitsch@google.com>
Commit-Queue: Florian Loitsch <floitsch@google.com>
The only fix needed for relanding is adding _ensureScheduleImmediate
to the list of vm entrypoints in //runtime/vm/compiler/aot/precompiler.cc
Original commit message:
Adds a top-level call waitForEventSync to dart:io that blocks the
thread an Isolate is running on until messages are available.
Before the thread blocks, the microtask queue is drained.
Before waitForEventSync returns, all messages are handled.
Lifting this up from a comment:
This is apropos of the request that nweiz@ sent to the mailing list a
couple weeks back. I'm not sure we should land this. We certainly
shouldn't land it without some annotations that will make the analyzer
complain a lot in most configurations, but I don't know what those
annotations are.
fixes#31102
Change-Id: Id96de46cc5f10e1847045cfafb7cfed6a38bce16
Reviewed-on: https://dart-review.googlesource.com/28920
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
There were two situations where this could get into a bad state:
* If the sink already had an error, _isBound would be set to true and
never unset. This is fixed by not setting it at all if an error
already exists.
* If _controllerCompleter completed to an error, _isBound would never
get set back to false. This is fixed by refactoring the code so that
the appropriate whenComplete() is always run.
Change-Id: Ia511fa3e2345213ff8e56dc4fae6f397b84257d1
Reviewed-on: https://dart-review.googlesource.com/26981
Commit-Queue: Natalie Weizenbaum <nweiz@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This reverts commit 2aed87a133.
Reverting for failures on precompiled bots.
Change-Id: I758bfc72d8f5e67b0e5e12a7367a47f1df9364e2
Reviewed-on: https://dart-review.googlesource.com/28900
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Adds a top-level call waitForEventSync to dart:io that blocks the
thread an Isolate is running on until messages are available.
Before the thread blocks, the microtask queue is drained.
Before waitForEventSync returns, all messages are handled.
Lifting this up from a comment:
This is apropos of the request that nweiz@ sent to the mailing list a
couple weeks back. I'm not sure we should land this. We certainly
shouldn't land it without some annotations that will make the analyzer
complain a lot in most configurations, but I don't know what those
annotations are.
Change-Id: If8286f4525994a162dd4f4563fefccb9d0984f7c
Reviewed-on: https://dart-review.googlesource.com/25281
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Without strong mode, a "good enough" implementation is to simply call
the generic method with "dynamic" for the type arguments, which is what
this does. That should be enough to unblock our internal users.
We also need to not report a compile error when
dart_internal/extract_type_arguments.dart imports the hidden
"dart:_internal" library.
This patch does both of those for the VM and dart2js (using its old
front end).
Note that the test still fails because the test is more particular than
most actual user code would be -- it validates that the instantiated
type arguments are *exactly* correct, and not that the returned object
is merely subtype compatible.
Bug:
Change-Id: I0343beace4991861b29712b3fd7067ec8dc8f8ba
Reviewed-on: https://dart-review.googlesource.com/28020
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
VMService.routeRequest of type Future Function(Message) overrides
MessageRouter.routeRequest of type Future<String> Function(Message).
It not enough to just fix VMService.routeRequest's return type because
Message.sendToVM() violates its type signature: it declares to
return Future<String> but in reality it returns Future<dynamic>
which can complete with either String or List. This CL addresses
this issue as well.
Bug:
Change-Id: I8240113d3e13d67c4e9a59db4250132a2077a4ec
Reviewed-on: https://dart-review.googlesource.com/26701
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The informal spec for strong mode top level inference
(https://github.com/dart-lang/sdk/pull/28218) says "If there are
multiple overridden/implemented methods, and any two of them have
non-equal types (declared or inferred) for a parameter position which
is being inferred for the overriding method, it is an error."
This CL fixes several SDK errors that arise from this rule. For
example, the classes _Closure, Function, and Object contained members
declared as follows:
class _Closure implements Function {
bool operator ==(other) ...
}
class Function {
bool operator ==(Object other) ...
}
class Object {
bool operator ==(other) ...
}
The type of Object's operator == was (dynamic) -> bool; the type of
Function's operator == was (Object) -> bool; therefore the type of
_Closure's operator == (which overrides both, since _Closure extends
Object and implements Function) cannot be inferred and must be
specified.
A similar situation exists for _Double and _IntegerImplementation
(both implement num, which declares operator == to have type (Object)
-> bool), and _Uri (which implements Uri, which declares operator ==
to have type (Object) -> bool).
This CL fixes the error by specifying the type explicitly in the
classes _Closure, _Double, _IntegerImplementation, and _Uri.
Change-Id: I91f7ceef8549399d438ba4be8c408493b3f338db
Reviewed-on: https://dart-review.googlesource.com/28100
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
We don't have a good place to pull this from on Android, but the
Flutter engine gets notifications when it is updated, etc., so don't
cache the value, and let the embedder supply a closure.
fixes#29211
Change-Id: I18e322fffb5212d9dbe154bc8628f817ba070237
Reviewed-on: https://dart-review.googlesource.com/27924
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
