On shards, the files don't need to be tar.gz'ed because the isolate
server will zip them and there aren't many files so tar'ing them doesn't
add much.
Change-Id: I696fe4c64fcee879bb9240e9d1990d2053aa8346
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96655
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This option makes the available named configurations much more discoverable.
Additionally this change expands the available named configurations by
generalizing the operating system and processor architecture patterns
in the named configurations. This change should ensure that nobody is doing
any local testing that isn't covered by a named configuration.
Change-Id: I776105955a86e9f0403ce07a3cdf971e4213646f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96320
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
* Run Debian package creation in a Docker container.
* Upload archives from Docker host (the container lacks credentials).
* Remove BUILDBOT_BUILDERNAME environment variables from test matrix:
They are overwritten in the recipe.
Change-Id: I90d7747e64231bdb745c85030a9cecf256adbaf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/94542
Reviewed-by: William Hesse <whesse@google.com>
This change lets one download the results for one named configuration but do
the local testing with another named configuration. This change addresses
the issue of developers needing to do local testing where there is no
builder matching their local environment. This allows e.g. a dart2js
developer on Windows to use the results for the Linux variant of the same
named configuration, which should be identical or close enough for the
comparison to be meaningful.
Fixes https://github.com/dart-lang/sdk/issues/36151
Change-Id: I1a387a9767cdf5ba99964535478201c0142f15e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96102
Reviewed-by: William Hesse <whesse@google.com>
The tool can be used to diff the results of two commits on a set of builders.
The user has to pick the revisions to ensure that both of them have results for the given revisions.
Unfortunately it currently seems to also give false-positive because of flaky tests.
Usage:
sdk % dart tools/diff_results.dart -b 'vm-*' 6cf71022a8 \
7df88e5755
...
language_2/control_flow_collections/if_promotion_test/none null -> (expected: Pass, actual: CompileTimeError)
on vm-dartkb-linux-{debug,release}-x64
on vm-kernel-asan-linux-release-x64
on vm-kernel-checked-linux-release-x64
on vm-kernel-linux-release-{simarm,simarm64}
on vm-kernel-optcounter-threshold-linux-release-{ia32,x64}
on vm-kernel-precomp-android-release-arm
on vm-kernel-precomp-bare-linux-release-{x64,simarm,simarm64}
on vm-kernel-precomp-linux-release-simarm
on vm-kernel-precomp-linux-{debug,release,product}-x64
on vm-kernel-precomp-obfuscate-linux-release-x64
on vm-kernel-precomp-win-release-x64
on vm-kernel-precomp-{mac,linux,win}-release-simarm64
on vm-kernel-reload-linux-{debug,release}-x64
on vm-kernel-reload-mac-{debug,release}-simdbc64
on vm-kernel-reload-rollback-linux-{debug,release}-x64
on vm-kernel-{linux,win}-{debug,release}-ia32
on vm-kernel-{mac,linux,win}-{debug,release,product}-x64
on vm-kernel-{mac,linux}-{debug,release}-simdbc64
Change-Id: Ibd3a0bdcec238c1fc0d147147b6fe4a7bb74819d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/93954
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
It was using the wrong 'expectation' field instead of the correct 'expected'
field. This change uses the right field. However as the matches field has
now been initialized, this change forcefully recomputes it instead of
politely using putIfAbsent. The matches result for the current result will
still take precedence.
Change-Id: I0775c1ff43b8f6691e457b5155ac9335338b209d
Reviewed-on: https://dart-review.googlesource.com/c/95182
Reviewed-by: William Hesse <whesse@google.com>
The expected field can be used to be displayed in the flakiness dashboard.
The matches fields can be used in the flakiness dashboards to decide whether
to include links to logs for a given outcome.
Change-Id: I19454e7cc8fb49871dbb0e7a11478d8888b56662
Reviewed-on: https://dart-review.googlesource.com/c/95024
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: William Hesse <whesse@google.com>
* no longer narrow by selector use, only narrow by type and non-null
* check for narrow nesting
* add non-null in a couple known places
One large apps, I compared the type-masks in dump-info and all differences were improvements with non-null. We weren't doing any narrowing based on the possible targets of a selector.
Change-Id: I270f360f70fbe3171d09ccd71d10517be9140194
Reviewed-on: https://dart-review.googlesource.com/c/90340
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Previously, messages would contain "Warning:" twice and failed to print
which file the errors came from.
Removed newlines from messages because the logger only prints the first
line.
Fixes#34405
Change-Id: I34d3679a4d769d7c7e2488ca55ffd15f08af9b16
Reviewed-on: https://dart-review.googlesource.com/c/93990
Commit-Queue: Alexander Thomas <athom@google.com>
Auto-Submit: Alexander Thomas <athom@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
All of DDC's supported platforms have Promises, so we can use them
instead of MutationObservers (web) and timers (node.js).
See issue #20055 (same issue, but for dart2js).
Change-Id: Id635a4a9fa104a2ab19dd20824d209f682f831f9
Reviewed-on: https://dart-review.googlesource.com/c/91765
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Specify extra shared options to the compiler and runtime via the
--shared-options= commandline option to test.py. For instance,
--shared-options=--enable-experiment=constant-update-2018 will enable
the front-end constant evaluation experiment for all tests run.
To avoid conflicts with tests explicitly enabling experiments, the
front-end parsing of experimental flags is changed to allow the same
flag to be mentioned several times, as long as the value is the same.
This matches the existing behavior of the analyzer.
Change-Id: I0c79e62b0b23ec7bc3824064dd27ef86b4451f9a
Reviewed-on: https://dart-review.googlesource.com/c/93501
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>