I opened several issues for missing errors and providing actual source
span, not just single offset. We need them anyway, and it is better to
let the FrontEnd know about them sooner, so that they have time to
plan implementing them.
https://github.com/dart-lang/sdk/issues/31626R=brianwilkerson@google.com
Bug:
Change-Id: I9238a06c8489679fa2a19f853ead2a2b93c39e39
Reviewed-on: https://dart-review.googlesource.com/29042
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We don't generate these. Rather than do that, this CL forwards to the
actual JS method instead.
This is the diff on the generated dart_sdk.js:
59732c59732
< return html$.LengthValue._fromDictionary_1(dictionary_1);
---
> return dart.global.LengthValue.fromDictionary(dictionary_1);
59894c59894
< html$.MediaStreamTrack._getSources(dart.fn(value => {
---
> dart.global.MediaStreamTrack.getSources(dart.fn(value => {
80232c80232
< html$.Notification._requestPermission(dart.fn(value => {
---
> dart.global.Notification.requestPermission(dart.fn(value => {
Change-Id: I9e857a808557e4702fb2b99aa518c25b49ff3db7
Reviewed-on: https://dart-review.googlesource.com/29020
Reviewed-by: Terry Lucas <terry@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
When building source maps it is currently assumed that the fileUri is
non-null (or at least that the location extracted from the Uri and
offset is non-null.
That might not always be the case (e.g. see CL 29003).
Bug:
Change-Id: I29c928a0d5fcd2bd5e1d1ef6c6d6ac97d2e7408c
Reviewed-on: https://dart-review.googlesource.com/29120
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Some tests are run via createCommand, some via
computeCompilationArtifact. This meant that some tests got an
environment and some didn't, resulting in the batch workers
getting restarted all the time.
This CL fixes the issue by passing the environment to createCommand as
well, meaning that the batch workers doesn't restart unnecessarily.
Before:
$ cls; xvfb-run -a '--server-args=-screen 0 1024x768x24' python -u ./tools/test.py -mrelease --checked --strong --use-sdk -rchrome -cdartdevk language_2
[03:09 | 100% | + 5171 | - 0]
$ cls; xvfb-run -a '--server-args=-screen 0 1024x768x24' python -u ./tools/test.py -mrelease --checked --strong --use-sdk -rchrome -cdartdevc language_2
[02:33 | 100% | + 5170 | - 0]
Now:
$ cls; xvfb-run -a '--server-args=-screen 0 1024x768x24' python -u ./tools/test.py -mrelease --checked --strong --use-sdk -rchrome -cdartdevk language_2
[01:41 | 100% | + 5171 | - 0]
$ cls; xvfb-run -a '--server-args=-screen 0 1024x768x24' python -u ./tools/test.py -mrelease --checked --strong --use-sdk -rchrome -cdartdevc language_2
[01:59 | 100% | + 5170 | - 0]
I.e. dartdevk tests are now almost twice as fast (on my machine).
Bug:
Change-Id: I15111436d3411b6ba85209950e4a5f20ee515539
Reviewed-on: https://dart-review.googlesource.com/29100
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The previous situtation of training it by running "--help" doesn't
give much.
This trains it on a small input file (i.e. theoretically not as good as
training it on big input file, but better than the --help situation).
On a local hack where I "forced" the compilation of dartdevc.dart itself
(i.e. a big input ifle) as the training, it shaved off a few extra
seconds, but nothing major.
This CL, running language_2 locally this takes it from
[04:08 | 100% | + 5171 | - 0]
to
[03:12 | 100% | + 5171 | - 0]
Bug:
Change-Id: I9397e11027be3dee3c080be7cdff22ea2f64b654
Reviewed-on: https://dart-review.googlesource.com/28622
Reviewed-by: Karl Klose <karlklose@google.com>
Commit-Queue: Jens Johansen <jensj@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>
* CompileStaticInitializer() should check result of Compile()
and should not leave sticky error. If left, this sticky error
could be picked up by compilation of some unrelated static
initializer. Also, assertions are added to make sure that code
which explicitly or implicitly relies on sticky errors is not
getting an error on entry.
* CompileStaticInitializerIgnoreErrors() clears sticky errors to
ignore them.
* Added inline bailout reason for cyclic static fields.
This guards against inlining of code which uses a field into static
initializer. This code might not be called so it should not trigger
compilation error eagerly.
Change-Id: I52da6f4cd05556125fd1a628b665dcc11621a4f7
Reviewed-on: https://dart-review.googlesource.com/28523
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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 batch runner uses an exitCode of 1 to signal compile-time errors,
which we need to support in the VMKernelCompilationCommandOutput.
Furthermore allow running the output of a dart -> kernel compilation on
the VM even though we expect an compile-time error (sometimes the
frontend has bugs and doesn't emit the compile-time errors and we need
to run the VM to get them)
Issue https://github.com/dart-lang/sdk/issues/31585
Change-Id: I8b4c34557dbf3de487247d75b02777bacbd452c1
Reviewed-on: https://dart-review.googlesource.com/28642
Reviewed-by: Martin Kustermann <kustermann@google.com>
is specified as we will only support Dart 2.0 in kernel mode.
Change-Id: I712fa6e0f733738e4b722aeb10b5eba6a64316c5
Reviewed-on: https://dart-review.googlesource.com/28520
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Change-Id: I6c500f977498b5e54e581273bf3a3b171fc2e61b
Reviewed-on: https://dart-review.googlesource.com/28720
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
This makes isolate tests fail, since we no longer run from "source" (or
rather use the kernel-isolate to to "source -> dill" for us).
The special vm/cc suite will continue to be run via the kerne-isolate, so we
have the coverage for these (which probably include reload tests).
Issue https://github.com/dart-lang/sdk/issues/31585
Change-Id: I51bd2f9345d650b4ff2a98aa1c8365c765e0d013
Reviewed-on: https://dart-review.googlesource.com/28722
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Change-Id: Ib7db1a7e48b48f2137edacd921b35d5c86313419
Reviewed-on: https://dart-review.googlesource.com/28521
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Apart from removing almost 1000 lines of very repetitive code, the idea here is
to change the assembler from a huge pile of arbitrary code into something that
can be used to generate tables of opcodes and their structure. Later, I'd like to
use this to make the disassembler more table driven and less arbitrary, and
perhaps build an x86 simulator in the same vein as the ARM simulator, which
would help me debug (I find the ARM simulator very useful when making low level
changes to the VM and miss its functionality on x86).
R=vegorov@google.com
Bug:
Change-Id: I1ae2c1696f88b67862843c9ac05c827a7c9b9a6e
Reviewed-on: https://dart-review.googlesource.com/25241
Commit-Queue: Erik Corry <erikcorry@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
