| commit | 5370c56c8098ce563be50d27a55e64efff9bdfe5 | [log] [tgz] |
|---|---|---|
| author | Jens Johansen <jensj@google.com> | Tue Dec 01 12:32:15 2020 +0000 |
| committer | commit-bot@chromium.org <commit-bot@chromium.org> | Tue Dec 01 12:32:15 2020 +0000 |
| tree | 0d40d2e195e188753da25176bad3923d5bc7c4a3 | |
| parent | 27ed7912af86426288107bfaa09b31c36099e4ba [diff] |
[VM] Read and report constant constructor coverage from dill This CL makes use of the now included constant constructor coverage in the dill file. It works like this: * When the CFE evaluates constants, every constant constructor invocation evaluated saves the reference to the constructor in the `Source` (from the Components uri to source table) for the callers Library. * This data is loaded into the VM in a "raw" format. * When a request for coverage comes in, the VM - on top of the normal coverage processing - goes through all scripts to find constant constructor coverage for the requested script and offset. Note that all scripts must be checked because library A can have evaluated a constructor from library B - so even if only coverage for library B was requested, library A has to be checked. For all constructors found the start and end position is reported as covered. Note that this does not mark any initializes and there are (at least currently) no good way of marking which initializes were evaluated (because it has to be stable across edits even when the `advanced invalidation feature` is enabled). * Note that the reason for the coverage to work on references - as hinted above - is because we want it to be stable across hot reloads even if/when advanced invalidation is enabled. This means, that library A cannot record "positional coverage" for library B because library B might get (for instance) new comments that will make any old offsets invalid. By using references we always lookup in the current world and use the correct offsets. https://github.com/dart-lang/sdk/issues/38934 TEST=Existing test suite, new tests for the new coverage added. Change-Id: I925963d1a9b9907efe621c72deb7348fa3be5ae8 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171949 Commit-Queue: Jens Johansen <jensj@google.com> Reviewed-by: Ben Konyi <bkonyi@google.com> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, getting started, and more.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.