We've long had the ability to load a combined dill file both in the dart
code and in the VM.
Largely this has been untested though - this CL adds a test.
Change-Id: I7cf03911d716999c2bdb407b256a064d84a385ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117152
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
The original change is in Patchset 1.
The dependency contains the fix for the non-bare-instructions bot.
Change-Id: Iab02ab0736a2ee9144b667d2777ca526341b2a36
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-android-release-arm-try,vm-dartkb-linux-release-x64-abi-try,vm-kernel-precomp-bare-linux-release-x64-try,vm-kernel-precomp-mac-debug-simarm_x64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115241
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously we were doing a deep comparison, but this wasn't
sustainable. The reason _variableInfosEqual exists is to verify the
logic used by FlowModel.restrict() to determine whether to re-use a
previous variableInfo structure. Since that logic is based on a
shallow comparison, the logic in _variableInfosEqual needs to do a
shallow comparison as well.
Change-Id: Id0f48a3f450a9210d4f6e6d919bb7a3e311ad458
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115621
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Two changes:
- Rather than remember to call `FlowAnalysis.finish` at the end of
each test, we now have a `_Harness.run` method that calls it
automatically.
- Variables are created using `_Harness.addVar` and their declarations
are reported to flow analysis using `_Harness.declare`. This allows
us to more easily test scenarios where a variable might be
referenced before its declaration site is encountered (which might
occur due to analyzer error recovery).
Change-Id: I0eff619840aeb057dcce8d64b6c6d23a265f81bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115421
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The test `pkg/front_end/test/flow_analysis/type_promotion/switch.dart`
wasn't running because it was declared in the wrong place (it should
have been inside the `data` directory). Merge it with the existing
test file `pkg/front_end/test/flow_analysis/type_promotion/data/switch.dart`.
Change-Id: Idc98464d88001ce68274a29ed73d02f6c378abc8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115263
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The crash occurred when:
- The body of the for-loop contained a write to a variable that was
declared inside the body of the loop.
- At least one variable was declared outside the for-loop.
Fixes#37983.
Change-Id: I241312e1f1c9efb879bbff93fc0ca569d8ec8370
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115262
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The nullability on the LHS of type-parameter types is assumed to be set
explicitly, at the moment of creation of the type or some time after
that. The latter case is needed for when the bound of the corresponding
type parameter is not yet set.
The second change is that the overall nullability is not stored in a
field, but is computed as a getter.
Change-Id: Ifbe6922c3a17943dd6c4f054976516c4f6bfc96d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115209
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit ecbea5a58e.
Reason for revert: broken with bare instructions and ABI bot
Original change's description:
> [vm/ffi] Implement FFI callbacks on AOT for ELF and Asm snapshots (excl. blobs).
>
> To do this, we add writable data sections (currently uninitialzed) to ELF and Asm snapshots
> and allow Instructions to have patchable relocations against (the start of) these sections.
>
> Issue https://github.com/dart-lang/sdk/issues/37295 (see also for design & discussion).
>
> Change-Id: If20bfa55776f4044aaa6bb8ea2101d2ada41842c
> Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-android-release-arm-try
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110221
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
TBR=kustermann@google.com,rmacnak@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: I9787da6d42575ca4f5ae0a698052a19ac4275afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-product-x64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-android-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115240
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
To do this, we add writable data sections (currently uninitialzed) to ELF and Asm snapshots
and allow Instructions to have patchable relocations against (the start of) these sections.
Issue https://github.com/dart-lang/sdk/issues/37295 (see also for design & discussion).
Change-Id: If20bfa55776f4044aaa6bb8ea2101d2ada41842c
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-android-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110221
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
If errors are caused by some file (say "a.dart") but are reported in
another library (say "b.dart") we are going to re-issue errors we
shouldn't have in the incremental compiler.
This CL introduces some test cases that currently fail.
Bug: 38167
Change-Id: I3c82fa72dab7c4714974c9caedc1906bead143ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115202
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
* Max and default for language version controllable via language options
* Default (if not set) comes from kernel static fields
* Kernel static fields updated to 2.6
* (Also set version for debug expression library)
* Test added that checks that the kernel static fields aren't out-of-date
(checked against python script "tools/make_version.py").
Change-Id: I65f26053081e4c55c215b677128f37fa970693c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114944
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
In the feature specification v1.2 libraries in a package with a default
version wasn't allowed to specify a language version higher than that.
In v1.3 thats allowed as long as its below the sdk limit.
Change-Id: I85f5c36a9c9c427da03fc540f9175195134ad47f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114604
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Johnni Winther