This makes the string (de)serialization independent of the core library
UTF-8 encoder/decoder so we can change that without affecting kernel
serialization.
It also speeds up serialization and deserialization by a few percent.
Change-Id: I347e471ed0174cc5cb191335dd7c47e6eb3dad59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140293
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
* Throw a specific error on mixed compilation mode; let the incremental
compiler ignore that error when trying to initialize (i.e. it doesn't
initialize from it, but it doesn't show any warning either).
* Allow some mixed mode stuff: Eventually the SDK should be in agnostic
mode, so we should allow mixing agnostic with non-agnostic.
Fixes#41493.
Change-Id: Idb33fb31afe6bbba6d74134cb722ca825751898b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143583
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This bit is required to support synthesized field used for the late
lowering. These fields should not be seen as part of the interface,
that is, classes that implement the class declaring the late field should
not be required to override these fields.
Closes#41436
Change-Id: I9a98322bdd1842b46bde34fff1176a7577672e0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142998
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL investigates some properties around the BinaryPrinter in the form
of non-optional-assert-like-things.
Said another way, if the assumptions added here are wrong, we'll crash,
but if the bots doesn't explode the assumptions are probably true and
we can procede from there.
Change-Id: Ia366be0e81164a4004f6d6764002cbb0f7383008
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137978
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
index to fix VMs coverage issue
This CL fixes the VM not always reporting coverage for mixin usages
properly.
* When asking the VM for coverage you can do it in one of two ways
* Ask the VM for coverage for everything; or
* Ask the VM for coverage for a specific script
* Asking the VM for coverage for everything works perfectly fine.
The VM goes through everything and reports coverage correctly.
* Asking the VM for coverage for a specific script (which is, at least
now, what the flutter tools does) doesn't work in the simple mixin
case described at http://dartbug.com/39779: The VM goes through the
libraries, asking for the list of scripts they "know about",
and checks for matches against what you asked for.
In this case, when asking for 'master.dart', the library for
'lib.dart' says no when it shouldn't --- because of the way the mixin
transformation works the content is actually in lib.dart.
This CL updates the content of the field 'sourceReferences' on Library
to fix the issue.
Fixes#39779
Change-Id: I0c38a323c81d1784ade704837b67ece549fc95d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128585
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Used to separate the behaviour without the variance experiment flag
turned off and with the flag turned on. Allows for more specific error
descriptions and allows the backend to avoid emitting variance
annotations for legacy covariance and only when the experiment is
enabled, otherwise there is no way of knowing whether the variance is
user specified.
Change-Id: Ia3070a1358e9b0fef10a3ce5057df881b9659832
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121140
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Add an incremental serializer that can be used to avoid re-serializing
the same thing again and again.
It does this by grouping libraries into Components / bundles,
serializing them individually and using the concatenated dill feature to
output the wanted data --- just potentially faster if we had the data
in cache.
Note that the serialized output might contain *more* than the input given
if we cached the wanted data into a bigger bundle.
The output will always be "closed" though, i.e. if the stuff that is
included that is too much added a new dependency, that dependency will be
included as well.
This should generally make it safe, although one can imagine situations
where it could pull in lots of dependencies that it wouldn't otherwise
have.
It is being driven by the incremental compiler which makes sure to
invalidate the cache when the data changes.
Except for situations where the libraries are changed externally after
being serialized, but before being serialized again, where one then wants
the updated library serialized, the feature should be safe.
Change-Id: I2a504abe6dbb68434c3b04abff13480ef72a6a6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120786
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Prior to this change, loading the sdk dill twice for instance would
result in additional exports as well as parameter counts doubling,
essentially destroying the result.
Change-Id: I4d694bec1926d6df6572e9bb36e8a88ec0822e27
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120785
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
In my measurements this changes the time it takes to write the sdk by
-11.1274% +/- 0.624366% (via slightly modified
pkg/kernel/test/binary_bench.dart AstToBinary out/ReleaseX64/vm_platform_strong.dill)
Change-Id: I4c5cbe17f42b70ef361b2edda0b33c8fc1727b63
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We have two layers of laziness.
Lazy loading functions (the old one) disables itself when loading a
concatenated dill file.
Lazy loading class content (the new one) forgot to do that while not
being geared towards it either.
This means that it - when loading lazily - can look into the wrong
string table, the wrong link table etc.
This CL brings the laziness for classes on par with the laziness for
functions in that it is now disabled when loading a concatenated dill
file.
Change-Id: If3449d5aff34287221a14fb7e940779d93b1e7b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117145
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>
Add support for the `late` modifier on fields and local variables in
CFE, and `required` on named parameters When using the option
--enable-experiment=non-nullable the `isLate` and `isRequired` flags will be set
accordingly on Field and VariableDeclaration nodes.
Closes#37686Closes#37684
Change-Id: If37fc93defdabc5cc974f3f068f57752a665f4cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113036
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Adds Extension node to kernel/ast, currently with serialization. This
is needed to support resolution of extension methods through dill
boundaries.
Adds (Source)ExtensionBuilder for build Extension nodes and
DeclarationBuilder as common superclass of ClassBuilder and
ExtensionBuilder.
Change-Id: Id945a40452f2729f9a4f390477dd6c76f9030eaa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112256
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
A kernel library will say it has the newest language version if no
language version is set.
This basically preserves the current semantics of always being on the
newest version (if nothing is explicitly done), e.g. if creating a kernel
library by hand and not setting it.
The front_end also utilize this and just doesn't set it, if it isn't set.
Change-Id: I033fef13626ee034030ba8fc9d141b182ba1a5ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111739
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Aske Simon Christensen