This reverts commit 3e967d3d76.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Create isolate from the platform kernel when running VM tests under dartk.
>
> Status of tests which now start failing has been updated.
>
> Ability to run the vm tests in strong mode has also been added. The
> status of tests which fail in strong mode will be updated when the vm
> tests are moved under the strong mode tests on the bots.
>
> Change-Id: I95f94c09dd0ebbf1fe661ee1f6e0c3e7b07509bd
> Reviewed-on: https://dart-review.googlesource.com/40642
> Commit-Queue: Siva Chandra <sivachandra@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=sivachandra@google.com,asiva@google.com
Change-Id: I6144bbe882cdf56ee6be3132c6f9dec2cbafcb47
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/41026
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Status of tests which now start failing has been updated.
Ability to run the vm tests in strong mode has also been added. The
status of tests which fail in strong mode will be updated when the vm
tests are moved under the strong mode tests on the bots.
Change-Id: I95f94c09dd0ebbf1fe661ee1f6e0c3e7b07509bd
Reviewed-on: https://dart-review.googlesource.com/40642
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This change helps in confining flag manipulation to just the embedder.
When we are ready to turn all dart 2 flags to true by default, the
change can be confined to just the VM.
Change-Id: I4ac550c331b1f236a2bd9d0453b7c567eb0c05d3
Reviewed-on: https://dart-review.googlesource.com/38881
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
With the old implementation, looking up the expectations for a single
test was O(n) in the number of status file entries in all status files
(!). That means getting the status of m tests was O(n * m). :(
This parses entry paths into a tree and only traverses the branches of
that the test patch matches. On my script that determines the
expectation of every test on every configuration, it changes the runtime
from ~30s to ~1.5.
On my laptop, this change also takes this:
time ./tools/test.py -m release --list -c dartdevc language_2
From about ~4.5s to ~3.5.
Storing the expectations in a more structured way also opens the door
to some other changes we could do:
- Separate out the configuration from ExpectationSet so that you can
use a single ExpectationSet for multiple configurations.
- Determining which status entries are pointless because they are
covered by a similar expectation higher up the file system tree.
- Determining which status entries collide and hit the same test.
Change-Id: I121bca34b68e1e6bb45edb59bd3cfe95d37e6bef
Reviewed-on: https://dart-review.googlesource.com/38382
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This is a branch of co19 tests where the tests have been
made strong mode compliant. A co19_2_analyzer.status file
has been added with the current statuses of the tests when
run on dartanalyzer --strong. We expect more Dart 2 configurations
to start running these tests and adding status files.
Change-Id: I22077272707620b92dd1092c38bbb4f3d5964493
Reviewed-on: https://dart-review.googlesource.com/37743
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Dart 2 has no notion of "checked mode", so a failed assertion in a
const constructor should always be a compile error.
Change-Id: I02227c03613346918de1e3a7f7c70d209a940b90
Reviewed-on: https://dart-review.googlesource.com/37647
Reviewed-by: Leaf Petersen <leafp@google.com>
test.py looks at the status code to find out if a test crashed or not.
On linux everything < 0 is a crash, but on Windows a bit pattern is
in play.
It is unclear why this is the case, but some test currently 'Fail'
(instead of the expected 'Crash') on Windows because of exit code
-1073740791 (aka 3221226505 aka 0xC0000409 aka
STATUS_STACK_BUFFER_OVERRUN
(https://msdn.microsoft.com/en-us/library/cc704588.aspx)) indicating
that something isn't quite right with the crash-sniffing on Windows.
This CL changes it to indicate a crash if the exit-code is "0xC0...",
"0x80..." or "0x40..." as listed by
https://msdn.microsoft.com/en-us/library/cc704588.aspx.
Change-Id: I6c692173c3c3b5fb6c857a55a739d8f136d662bf
Reviewed-on: https://dart-review.googlesource.com/36261
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit 87a009422e.
Reason for revert: Doesn't cover 0x80 and 0x40. Upcomming CL will do that.
Original change's description:
> [test.py] Refactor and change crash-sniffing
>
> test.py looks at the status code to find out if a test crashed or not.
> On linux everything < 0 is a crash, but on Windows a bit pattern is
> in play.
> It is unclear why this is the case, but some test currently 'Fail'
> (instead of the expected 'Crash') on Windows because of exit code
> -1073740791 (aka 3221226505 aka 0xC0000409 aka
> STATUS_STACK_BUFFER_OVERRUN
> (https://msdn.microsoft.com/en-us/library/cc704588.aspx)) indicating
> that something isn't quite right with the crash-sniffing on Windows.
>
> This CL changes it to indicate a crash if the exit-code is "0xC00..." as
> this is a "NTSTATUS code" (which must mean crash) according to
> https://blogs.msdn.microsoft.com/joshpoley/2011/06/13/common-process-termination-values/.
>
> Change-Id: Ie7e1a00b3b870ea176dbdc4db41dc458e61e9a28
> Reviewed-on: https://dart-review.googlesource.com/36240
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Jens Johansen <jensj@google.com>
TBR=jensj@google.com,johnniwinther@google.com
Change-Id: Iba1d3e1aa1c7525e374e2d0763926b13a67169ad
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/36260
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
test.py looks at the status code to find out if a test crashed or not.
On linux everything < 0 is a crash, but on Windows a bit pattern is
in play.
It is unclear why this is the case, but some test currently 'Fail'
(instead of the expected 'Crash') on Windows because of exit code
-1073740791 (aka 3221226505 aka 0xC0000409 aka
STATUS_STACK_BUFFER_OVERRUN
(https://msdn.microsoft.com/en-us/library/cc704588.aspx)) indicating
that something isn't quite right with the crash-sniffing on Windows.
This CL changes it to indicate a crash if the exit-code is "0xC00..." as
this is a "NTSTATUS code" (which must mean crash) according to
https://blogs.msdn.microsoft.com/joshpoley/2011/06/13/common-process-termination-values/.
Change-Id: Ie7e1a00b3b870ea176dbdc4db41dc458e61e9a28
Reviewed-on: https://dart-review.googlesource.com/36240
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
- I beleive create_snapshot.dart is no longer in use: it was replaced by
create_snapshot_entry + GN application snapshot rules.
- utils_wrapper seems to be something really historical (maybe we thought we
were going to only have a single wrapper for all of our tools back in the
day). The only use of it is to track build dependencies in test.py, which I
think we can do by directly using dart2js.dart.snapshot instead.
Change-Id: I6e32403eb8c5d40f0b58e48ae5ff6fb60fd855b3
Reviewed-on: https://dart-review.googlesource.com/34923
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This makes it easier to run DDC tests, and fixes a bug where DDC+Kernel
tests could be run without setting the strong mode flag.
Change-Id: I7b0632d903050c7385c553ba8d4562062084df28
Reviewed-on: https://dart-review.googlesource.com/34024
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
When testing multitests needed files are copied, but some files are
copied multiple times, creating race conditions that might cause tests
to fail because incomplete files are read.
For instance running
"python tools/test.py -m release -c dartk --strong language_2"
is fine (i.e. everything passes), but running
"python tools/test.py -m release -c dartk --strong language_2/generic_constructor_mixin3_test"
can get 0, 1 or 2 errors depending on the computers mood...
This fixes the problem by introducing a map from copied-to-path to Future,
so the same Future is returned when asked to copy a file subsequent times,
thus avoiding the race condition.
Fixes#31368.
Bug:
Change-Id: Id7d4a12424085c75f3543bd06a617121ad5eff35
Reviewed-on: https://dart-review.googlesource.com/32282
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This includes two fixes that only caused problems in windows:
- we assumed file-uris in other parts of DDK, and this caused problems with sourcemaps
- we generated module names containing a leading "./" (e.g. "./expect"), this didn't cause trouble in linux, but it is incorrect.
Bug:
Change-Id: Id3c363670544ed0a8373184ec5445549346fc7bf
Reviewed-on: https://dart-review.googlesource.com/31748
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This adds the basic support for using the path to the .dill file as a module
name. The main difference between this and Jake's original CL is that we now
hide the multi-root as an implementation detail.
Change-Id: If24af1aaefa5c1445c7c84bd9ff4a7a4d738a320
Reviewed-on: https://dart-review.googlesource.com/31283
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
* Enable --limit-ints-to-64-bits for CFE when it is used to generate
kernel for VM as CFE relies on int.parse being able to parse correct
literals and reject incorrect.
* Pass --limit-ints-to-64-bits to gen_kernel via environment
variable to support batch mode compilation.
Issue: https://github.com/dart-lang/sdk/issues/31339
Re-landing https://dart-review.googlesource.com/29941 with the fix:
* Use checked-in SDK to avoid timeouts on SIMARM bots.
Checked-in SDK was updated and now includes necessary fixes.
Change-Id: I4a5a99455b60204572f3d619d7eb374035b03e40
Reviewed-on: https://dart-review.googlesource.com/30640
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Strong mode types are queried from:
* Return types of interface targets of instance calls.
* Return types of static calls.
* Types of instance and static fields.
* Types of local variables (for initial types of phis).
The strong mode types are used to specialize int and double operations
and optimize 'is' checks.
https://github.com/dart-lang/sdk/issues/30480
Change-Id: I2302509f396eacfcab8ed41e3f50e8c74dd662fd
Reviewed-on: https://dart-review.googlesource.com/30386
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
* Enable --limit-ints-to-64-bits for CFE when it is used to generate
kernel for VM as CFE relies on int.parse being able to parse correct
literals and reject incorrect.
* Pass --limit-ints-to-64-bits to gen_kernel via environment
variable to support batch mode compilation.
* Use current Dart SDK instead of checked-in Dart SDK to run CFE
in gen_kernel as checked-in Dart SDK is old and it doesn't have
int.parse fix yet.
Issue: https://github.com/dart-lang/sdk/issues/31339
Change-Id: Iaba2a7945a3faa9427f9aab1e9f2b907fa2246a3
Reviewed-on: https://dart-review.googlesource.com/29941
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@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 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>
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>
Switch it to use pkg/vm/tool/dart2 which is the source of truth for what
Dart 2 VM configuration means. Don't pass any additional flags from
tools/test.py itself.
Align pkg/vm/tool/dart2 with what tools/test.py was passing to VM on _2 suites.
Make default invocation `tools/test.py -c dartk --strong -m release,debug`
green by updating status files and skipping suites that are not Dart 2.0
compliant. I have filed issues #31588 for isolate suite and #31587 for
service suite.
Reland of https://dart-review.googlesource.com/27820
Change-Id: I49400fae716f75425e70bf1e561b3375ba39157e
Reviewed-on: https://dart-review.googlesource.com/28565
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Siva Chandra