This changes the reported failure from Crash to something more specific
to the encounter error, like ExpectationFileMismatch. Validation errors
for the .yaml file still produce Crash, and so does a couple of the
checks on Component integrity that were also used outside
incremental_load_from_dill_suite.dart
Change-Id: I48aa8cb25198d24e986b0f354db2b370dc9b8ac8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167565
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This increases our "local" coverage of the constant evaluator.
Run with something like
`pkg/front_end/test/fasta/strong_tester.dart -DupdateExpectations=true -DstressConstantEvaluator=true -DskipVm=true`
there is now almost coverage of everything (or a comment in the code
suggests that the path is probably unreachable).
Note that
`out/ReleaseX64/dart pkg/front_end/test/vm_service_coverage_constant_evaluator.dart pkg/front_end/test/fasta/strong_tester.dart -DupdateExpectations=true -DstressConstantEvaluator=true -DskipVm=true`
has erroneous misses, for instance (but not limited to) asserts.
These are caused by errors in the VM.
A follow-up CL will be created to turn on "stressConstantEvaluator" by
default and print out any sucesses in the expect files.
Change-Id: I837837be4f0487fdbe57c5107e4b3415de189177
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163060
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously the first file in the `Component.uriToSource` was used which
didn't work nicely with multifile tests.
Text outline expectations were already using the test description uri.
Change-Id: I0d4a7493cd1fa61beffba41f1ea859ca5e8ad08c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151825
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The support is added for the follwing statements:
* YieldStatement
* Block
* VariableDeclaration (as a statement)
* IfStatement
* EmptyStatement
+ improve diagnostics in related unit tests
Change-Id: Ib738227c6e8c1963aeaee52630953e07cef4b093
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146800
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The CL reduces the number of false positive cases in the round-trip
serialization unit testing by refining the verifier analysis. Not it
doesn't attempt to make the round trip over the sub-trees containing
free variables.
Change-Id: Ib6fb2e72f7543ea7d99c5273c337801f3ad1bec4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144285
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
This CL also includes the following changes:
- The .registerTags() method is added to the Case combinator.
- The actual canonical names' root is passed into the deserializer.
- Some text serialization failures are fixed and the corresponding
status entries in text_serialization.status removed.
Change-Id: I222dfa3fc348dddf83e0c6edb92f15d08b8e73e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143803
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
This CL gives the option to load classes lazily (on by default),
meaning that fields, procedures, constructors and redirecting
factory constructors of classes are not initially read,
but instead read when (or if) needed.
The idea being that many classes aren’t needed, and that
spending time on reading them is thus just a waste of time.
This is especially true in modular compilation where a lot
of modules needs to be given as input as the compilation at
hand might technically rely on it, but in practice only very
few of the classes are actually needed (or very few classes
actually need their members).
The below numbers are comparing a VM without this change and without
the lazy class hierarchy member lists change with
b31566b297 (the base change for those
two changes).
For running a simple hello-world script, on my machine 500 times
and doing statistics on it I can measure the following differences:
With verbose, from kernel_service startup to compile complete:
Difference at 95.0% confidence
-17.8 +/- 0.555817
-24.3455% +/- 0.760206%
(Student's t, pooled s = 4.48379)
With verbose, total runtime measure by `time`
Difference at 95.0% confidence
-19.346 +/- 0.905217
-12.0333% +/- 0.563051%
(Student's t, pooled s = 7.30242)
Without verbose, total runtime measure by `time`
Difference at 95.0% confidence
-17.862 +/- 0.842905
-12.0635% +/- 0.569276%
(Student's t, pooled s = 6.79974)
For running a number of modular compilations I’ve recorded an
improvement in actual runtime in the order of 20-37% depending
on the circumstance. In a real build system, though, the
difference seems to be more in the order of around 5%.
Change-Id: Id329bcf2b01d12c12d7a49f2b8abacd9c2447f05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115703
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Output from a comparison could be something like
Integers differ: 2 vs 3
Map with key 'nullability' has different values (tag 95, likely 'TypeParameterType')
Lists have different values at index 0
Map with key 'items' has different values
Map with key 'typeArguments' has different values (tag 93, likely 'InterfaceType')
Map with key 'returnType' has different values (tag 3, likely 'FunctionNode')
Map with key 'value' has different values (tag 1, likely 'Something<1>')
Map with key 'function' has different values (tag 6, likely 'Procedure')
Lists have different values at index 0
Map with key 'items' has different values
Map with key 'procedures' has different values (tag 2, likely 'Class')
Lists have different values at index 6
Map with key 'items' has different values
Map with key 'classes' has different values
Lists have different values at index 458
Map with key 'libraries' has different values
Which should be read bottom up as something like
Component -> the 458th library -> the 6th class ->
the 0th procedure -> function -> returnType (a InterfaceType) ->
0th type argument (a TypeParameterType) ->
nullability has value 2 in one input and 3 in the other.
Change-Id: I49007a80ddb53a0ba1fae04b22d6efeae3687724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114602
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Sam Rawlins