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>
This change takes advantage of the new --clean-exit and --silent-failures
options to test.py, which means the test.py native progress bar can be used.
test.py exiting 0 if results were written out, no matter the results, lets
us properly handle if the program failed.
The output is now sectioned to make it more readable, and if no tests
failed, then the program says so.
This change also fixes logs which were broken because the logs for the steps
weren't merged, and the main test.py run wasn't even being passed the
--write-logs option.
This change also fixes directly starting dart scripts as an executable
rather than using the platform resolved executable.
TBR=whesse@google.com
Bug: https://github.com/dart-lang/sdk/issues/35359
Change-Id: I7bed009475df3ffea01c9e805513d0e04e77427c
Reviewed-on: https://dart-review.googlesource.com/c/86568
Reviewed-by: Jonas Termansen <sortie@google.com>
This change renames the --no-status option to --clean-exit, as that better
describes what it does, which is useful. We'll want to add a proper option
--no-status-files in the future that ignores status file entries except skip
and slow, which will be useful for the reproduction commands provided by
test.dart in the transition period until the status files are deleted.
Bug: https://github.com/dart-lang/sdk/issues/35358
Change-Id: Idc22a6c1b109508dadafb8a225cb91ad06287c0b
Reviewed-on: https://dart-review.googlesource.com/c/86565
Reviewed-by: William Hesse <whesse@google.com>
Samir Jindel