- Fixed HTML API's with callback typedef to correctly convert Dart function to JS function.
- Expose HttpStatus from dart:html
- Expose DomName ondblclick and dblclickEvent for Angular analyzer.
- Fixed removeAll should be Iterable<Object> to match Set's removeAll not Iterable<E>.
- Fixed a number of DataTransferItem, Entry, FileEntry and DiretoryEntry returning NativeJavaScriptObject needed type registered in DDC.
- Added ability to allow local file access from Chrome browser added -local in ddb.
R=vsm@google.comFixes#30278Fixes#35484Fixes#34318Fixes#35510
Change-Id: Ide8c04716c54045e837781d489562f27b694b109
Reviewed-on: https://dart-review.googlesource.com/c/89340
Commit-Queue: Terry Lucas <terry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This reverts commit 8044e32fc5.
Reason for revert: The device was fixed, and there is now one device per bot. Blacklisting a single device is no longer the right approach because it effectively destroys a bot.
Original change's description:
> [infra] Blacklist android device id in attempt to make buildbot builder more stable
>
> This particular device sometimes fails with errors such as:
>
> * "protocol error"
> * "protocol error (no status)"
> * "device not found"
>
> Change-Id: Iced97ae8f5e891c43436a3d745004517dc59b42c
> Reviewed-on: https://dart-review.googlesource.com/c/84905
> Reviewed-by: Alexander Thomas <athom@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
TBR=whesse@google.com,vegorov@google.com,kustermann@google.com,athom@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I8422a75d10518ec06de737a0a719f9648279fbf8
Reviewed-on: https://dart-review.googlesource.com/c/89500
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Context: we finally removed the old emitter and fast startup is on by default.
This CL removes from the test matrix duplicate steps that now are doing the same
thing and the faststartup builders that are no longer needed.
Change-Id: Id65ea3178bcd7a9554bfa127a09938ca910c57e8
Reviewed-on: https://dart-review.googlesource.com/c/89181
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This reverts commit 4afb45f5b8.
Reason for revert: Going to instead file a bug to get the `all' target appropriately fixed, if possible.
Original change's description:
> Change default target to "create_sdk".
>
> Currently the "all" target can lead to build errors and is unsupported,
> so fall back to a supported target instead.
>
> Change-Id: I925a785e4b81ab92e99c3842cb81c338c5a1d990
> Reviewed-on: https://dart-review.googlesource.com/c/87403
> Auto-Submit: Stevie Strickland <sstrickl@google.com>
> Reviewed-by: Zach Anderson <zra@google.com>
> Commit-Queue: Stevie Strickland <sstrickl@google.com>
TBR=zra@google.com,sstrickl@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I27c567ad61e54bd2916027b6e27406bd67eb8330
Reviewed-on: https://dart-review.googlesource.com/c/89140
Reviewed-by: Stevie Strickland <sstrickl@google.com>
Commit-Queue: Stevie Strickland <sstrickl@google.com>
Make sure the architectures listed by --help for the -a command
line option reflect all currently available architectures + 'all'.
Change-Id: I2759c7c7e846d38fce5afde1854bfd2db0dd8b70
Reviewed-on: https://dart-review.googlesource.com/c/88821
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Stevie Strickland <sstrickl@google.com>
It's simply an alias for `dartdevc --kernel`, and now that build_runner
is switching to that, there's no reason to keep it around anymore.
Change-Id: I43d30a582314a236bcfa2e3a0b50bb48ddac79f8
Reviewed-on: https://dart-review.googlesource.com/c/88281
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
The buildbucket API is not always reliable and responds within 30 seconds.
Rather than spuriously failing, try again. This should improve the
reliability of the base branch update bot.
Change-Id: Iade2d78372743b8d843c0dead591c28f8ee8f3ae
Reviewed-on: https://dart-review.googlesource.com/c/88445
Reviewed-by: William Hesse <whesse@google.com>
Batch mode crashes were treated as if they exited -10 (SIGUSR1 on Linux),
however these are all Dart unhandled exceptions, and no crash dumps were
produced. Exit 253 instead, which dart2js uses to signify an internal
compiler error, which is considered a crash but inhibits uploading crash
reports.
Change-Id: I3779ec1c511c1bcd31967254d3e0cee9a347a9bd
Reviewed-on: https://dart-review.googlesource.com/c/87440
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This will result in:
tools/test.py -n foobar
The named configuration "foobar" does not exist. The following configurations are available:
* analyzer-asserts-linux
* analyzer-asserts-mac
* analyzer-asserts-win
* ...
Change-Id: I2fadc2ab3ae6f2b34dd373d84365d44ef27c7b8b
Reviewed-on: https://dart-review.googlesource.com/c/87325
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart2js internal compiler errors exit 253 and don't produce a core dump, but
rather dump the relevant debug information as a stacktrace on stdio. This
change disables uploading crashes in that case, which would otherwise fail
because core dumps can't be located for the dart2js process, causing the test
step to fail.
Change-Id: I6154bd205c8cccb9c62d007e6071fea8b4196a96
Reviewed-on: https://dart-review.googlesource.com/c/87075
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
We prevent our crashing tests from hitting timeouts on the bots
by disabling Windows Error Reporting UI via SetErrorMode.
However this also disables builtin crash dump generation functionality
that WER has.
This change moves WER suppression for GP faults under a flag to
make sure that we can collect crash dumps when VM crashes on
user machines.
We also make sure that our exception handler call abort()
instead of calling exit() - because exit would not cause
WER to generate a dump.
Bug: https://github.com/flutter/flutter/issues/22558
Change-Id: I42f3e31cfaaa578f6a040b8f10621e5663cddc09
Reviewed-on: https://dart-review.googlesource.com/c/87061
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This can happen if a test is approved as failing, it then is fixed, and a
changelist needs to break it again, and the new failure is pre-approved.
This causes approve_results to warn that it can't properly change an approval
from one outcome to the exact same outcome, which is of course wrong, it can
do that.
Change-Id: Ib9ea1d4ea5a204b66808a1789c31fe6ec9c2c9d2
Reviewed-on: https://dart-review.googlesource.com/c/86920
Reviewed-by: William Hesse <whesse@google.com>
The output of a compare-results run showing logs will enclose
the failing test name in a box, as in:
/=======================================================================================\
| dart2js_extra/no_such_method_test is new and failed (CompileTimeError, expected Pass) |
\=======================================================================================/
--- Command "dart2js" (took 244ms):
DART_CONFIGURATION=ReleaseX64 out/ReleaseX64/dart-sdk/bin/dart2js --generate-code-with-compile-time-errors --test-mode --packages=/b/s/w/ir/cache/builder/sdk/.packages --out=/b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dart2js-sdk/tests_compiler_dart2js_extra_no_such_method_test/test.js /b/s/w/ir/cache/builder/sdk/tests/compiler/dart2js_extra/no_such_method_test.dart --preview-dart-2
exit code:
1
Change-Id: Ic63fa41381bab320636340c1e7919e22cd424c1d
Reviewed-on: https://dart-review.googlesource.com/c/86925
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Rationale:
With 100 machines, 8 isolates each, we get a theoretical
peak of 100,000 fuzzing tests per nightly run (actual
number depends on time-based execution mode run).
Change-Id: I5872f681a636e6b5369f684ceef0f37f2311c8d7
Reviewed-on: https://dart-review.googlesource.com/c/84664
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Sam Rawlins