- Updated conditional compilation flags throughout the runtime codebase to transition from DART_DYNAMIC_MODULES to DART_BYTECODE_INTERPRETER.
- Adjusted logic in various files including object_graph_copy.cc, object_reload.cc, profiler.cc, and others to ensure compatibility with the new interpreter model.
- Ensured that all references to dynamic modules are replaced with bytecode interpreter checks, maintaining functionality for interpreted code execution.
- Modified stack frame handling and service-related code to align with the new interpreter architecture.
- Updated tests and service implementations to reflect the changes in the runtime environment.
Signed-off-by: Tony <tonylu@tony-cloud.com>
Also load/store canonical hashes in the heap for non-empty TypedData
instances in the same manner as canonical hashes for Arrays.
TEST=ci (refactoring only)
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try
Change-Id: I54274b558fa9f0c8e304198b18cb3f0e9c3e0dfb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504600
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Coverage information for enhanced enums should not include initializer
functions for enum elements or the values field, so skip over these when
the enum is defined in bytecode.
TEST=vm/cc/SourceReport_Coverage_IssueCov386_EnhancedEnums
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try
Change-Id: I1dba3c87fdfcc39762bba5f0c35cfd061ec76371
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/504240
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The RecordCoverage instruction has an A/E encoding. The A argument
is the type of coverage being recorded, whereas the E argument is
the logical index into the coverage array for updating whether that
source position has been hit.
Also adds new metadata to the bytecode component for the coverage
arrays associated with bytecode containing RecordCoverage instructions
and a new runtime entry for lazily allocate the coverage array for
an interpreted function when needed.
The type of coverage is encoded in the RecordCoverage instruction,
despite being redundant with the information in the coverage array, so that checking whether that type of coverage is currently enabled at
runtime doesn't require either accessing the coverage array (which may
be lazily allocated), forcing allocation of the coverage array just to
discover that type of coverage is currently disabled, or reading the
serialized bytecode component to avoid that forced allocation.
------
Other changes:
Source reporting now treats unexecuted interpreted functions when
not forcing compilation as if they were uncompiled native functions,
so that the source report from running the same code gives the same
result whether using the interpreter or the native compiler.
Bytecode closures are no longer skipped in source reports. Previously
any closure without a context scope was skipped, but bytecode closures
don't have those.
TEST=vm/cc/SourceReport_Coverage
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try
Change-Id: I7557e5dd4c98331c7ca2f5c867dd5f6d03e9d756
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501520
Reviewed-by: Alexander Markov <alexmarkov@google.com>
To support checking for dynamically-callable targets in dart dynamic
modules, we need to use a bit in the Function header in AOT. Currently
all 32 bits of `kind_tags_` are in use. To make space for that new bit,
we need to evict one of the current properties that is not needed by AOT.
Among them, `IsRedirectingFactory` made the top of the list. It has only
one use in non-AOT logic.
TEST=existing
Bug: b/448095881
Change-Id: I3112d8865523696ed8e906a6c59f53c23db3090a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498281
Auto-Submit: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The front end may desugar some const constructors into procedures, so be
less strict with what is expected in the list of const constructors.
Also updates SourceReport to check all Functions with is_const() true
against the collected const constructor hits and not just Constructors.
TEST=ci
Fixes: https://github.com/dart-lang/sdk/issues/61947
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: I092938eeeb0459de9b3d95400a538ec6528c43fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462442
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Add a flag to SourceFile which is true if the associated script
contains a list of covered const constructors, and serialize said
list if true.
Delay reading and resolving the list of covered const constructors in
the bytecode reader until code is read.
Update usage counters for interpreted functions in Entry instructions.
Fix up cases where SourceReport assumed compiled code as appropriate.
Remaining:
* Record call and assert coverage information if the current isolate
group has coverage enabled.
* Record branch coverage information if the current isolate group
has branch coverage enabled.
TEST=pkg/vm_service pkg/dart2bytecode
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-mac-debug-arm64-try
Change-Id: I14b6ffba1e175993e992c0fe939473557303bfeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449900
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
The way coverage collection was implemented for const constructors was a bit of a hack. After ordinary coverage collection was complete and all ordinary source ranges had been added to the report, SourceReport::CollectConstConstructorCoverageFromScripts would iterate through all the const constructors and add extra ranges to the source report that reported them as being hit. The old ranges were still in the report, reporting the constructors as missed, but the miss was overwritten by the hit when package:coverage turned the source report into a coverage report. That hacky approach didn't work for branch coverage.
I've refactored it to gather all those const constructor hits before ordinary coverage gathering, and store the hits in the script table. Then during the ordinary coverage collection flow, when we see one of those const constructors, we mark everything inside the function as hit.
This also fixes a related bug that we hadn't noticed before, where calls inside the const constructor were treated as missed.
Note: If there are dozens of const constructors in a single script, it might be worth sorting ScriptTableEntry.const_constructor_hits and then binary searching it, but I don't think that's worth doing atm.
Bug: https://github.com/dart-lang/tools/issues/513
Fixes: https://github.com/dart-lang/tools/issues/513
Change-Id: Ie66a153fbeaac5b3ecfc9a28a7f8d129ab61114a
TEST=source_report_test.cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421720
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Before this CL, becase of optimizations, coverage of some of these goes
away, making coverage unreliable.
I believe this fixes the issues for "regular" runs (at least it seems to
be stable on the CFE coverage tests).
If setting `--optimization-counter-threshold=-1` there'll still be
trouble though and we would have to also insert these calls in the start
of FunctionBody and the start of FieldInitializer for it to produce the
same results.
TEST=pkg/vm_service/test/coverage_instance_call_after_optimization_test.dart,pkg/vm_service/test/coverage_static_call_after_optimization_test.dart
Bug: https://github.com/dart-lang/sdk/issues/42061
Bug: https://github.com/dart-lang/sdk/issues/55959
Bug: https://github.com/dart-lang/sdk/issues/56018
Change-Id: I34947f0d4b123e52ce67b71a195782d31e4bda16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370501
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Lookup in the library import can be very slow and it is not needed
most of the time. This change makes Library::Lookup{Class,Function,Field}[AllowPrivate]
lookups local in the library and cleans up related or unused code.
TEST=ci
Change-Id: If5a99bce7d712ce3a898395f74d4febac0311048
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323221
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
** KernelProgramInfo
The VM can load multiple kernel files into an isolate. Each kernel file
is represented as a [KernelProgramInfo] object. Loading a kernel blob
will result in a tree of objects
Library
- TopLevelClass
+ Field
+ Function
+ Class
+ Field
+ Function
+ ... closure functions ...
The entire tree belongs to one [KernelProgramInfo] object. There are
two exceptions
* after a hot-reload we inject [PatchClass]es (as owners of
old [Field]/[Function] objects) that identify the old kernel data
* expression evaluation functions will get a special data array with
information about the expression evaluation kernel data
=> We attach the [KernelProgramInfo] to the root of the tree, namely
the [Library]
=> We introduce `{Field,Function,Class,Library}::KernelProgramInfo()`
that will get that object - by walking up the chain.
=> We introduce `UntaggedPatchClass::kernel_program_info_` field that
allows saving the old [KernelProgramInfo] (on which the old
[Field]/[Function] objects are based upon) in the [PatchClass].
=> We include the [KernelProgramInfo] in the expression evaluation
data array.
** Scripts
A [Script] object should represent a .dart source file. It contains the
source, line offsets, etc. of that dart source file. The contents of a
dart source file may be used by many classes/libraries or even many
kernel blobs (e.g. via our copying mixin application).
When we build a tree like above, we'll attach a reference to a
[Script] object to [Class] objects. But members of a class may come from
a different script, in which case we inject an intermediary [PatchClass]
that references that other script.
When the compiler frontend loads kernel, builds flow graph, etc we walk
down the kernel binary (the tree above) - all belonging to the same
[KernelProgramInfo] object, but sub-parts may belong to different
[Script]s.
=> We use the existing [ActiveClass] class that keeps track of the
current class & member inside the class we're operating on.
=> Whenever we need the script we get it from the active member
function/class.
** Misc
We make kernel related classes (e.g. [KernelReaderHelper]) independent
of [Script].
We make the [Script] objects hold on to the [KernelProgramInfo] they are
based upon (e.g. for lazy source reading). But since a given [Script]
doesn't belong to a particular kernel blob (multiple kernel blobs may
contain information about the same script) we don't expose this in the
public API.
=> In the future we could have a unique [Script] object per url (instead
of having several as we do now)
TEST=ci
Change-Id: I7bd698f497b0bd8ab8e546540bb1dad5b5a6dd48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313381
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
When library_filters were given, we used to prefill the script_table_,
then just assume that any scripts not in the script_table_ must have
been filtered out. We wrote it this way to avoid checking the filters
in every GetScriptIndex call. But in some cases (eg mixins),
lib.LoadedScripts() can miss some scripts, so they'd be incorrectly
omitted from the table.
The new implementation lazy loads the scripts, the same way it works
when there are no library_filters. Skipped scripts are still placed in
the script_table_, but given an index of -1, and omitted from
script_table_entries_.
Bug: https://github.com/dart-lang/sdk/issues/49887
Change-Id: Ide938ddfa9a3750c72c615e296b1a23875e46ab8
TEST=CI (also manually tested that the bug is fixed, but it's a really fiddly setup and I'm not sure how to put it in a unit test. See bug for details)
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260076
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
The source report RPC needs to be able to distinguish branch coverage vs
normal coverage token positions. So encode normal positions as 2 * pos
and branch positions as 2 * pos + 1.
TEST=CI
Change-Id: I247796d1eb4c97947f9b38aa56bc318ecea09425
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224320
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Redirecting factories are never hit in source coverage report because
front-end replaces calls to redirecting factories with calls to their
targets. This change excludes redirecting factories from source
coverage reports.
TEST=vm/cc/SourceReport_Regress95008_RedirectingFactory
Fixes https://github.com/flutter/flutter/issues/95008
Change-Id: I0f6af291f7ee0c042521c92063092f990426b995
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/223600
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Sets and gets to late variables count as uncovered even when they are
covered, because they have internal branches that throw exceptions.
These exceptions should not be hit in well formed code, so they
shouldn't count towards coverage totals.
These exceptions are all thrown using static functions on the internal
LateError class, so we can just ignore any calls that target a function
on this class.
Bug: https://github.com/dart-lang/coverage/issues/341
Fixes: https://github.com/dart-lang/coverage/issues/341
Change-Id: I1dfa5d64b7a2030121d84d7aad7c7a1649b900a8
TEST=Added a unit test
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221740
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
More precisely, ignore private constructors with no parameters, on
abstract classes with no subclasses, no non-static members, and no
non-static functions (other than the constructor).
This is an idiom used to make static utility classes, and these
constructors are not intended to be used. So counting them as coverage
misses incorrectly lowers the coverage percentage.
Fixes: https://github.com/dart-lang/sdk/issues/47021
TEST=Added unit test
Change-Id: Ib94dd939c4637d5c04fe45009fc92be435e164da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220225
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Every known user of the coverage report just wants the line numbers. At
the moment they have to do a second RPC to get the Script object, so
they can translate the token positions into line numbers.
Slower test times with coverage are usually caused by the extra time it
takes to run the RPCs. So reporting the line number directly will halve
the time it takes to get coverage, for most users.
Bug: https://github.com/flutter/flutter/issues/86722
Change-Id: I7b8d436669713ebc7b7096790a02593b9cb94dda
TEST=CI
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211081
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Currently we have things called XPtr which are not what you get from ptr().
Old world:
handle->raw() returns RawObject* (tagged)
raw_obj->ptr() returns RawObject* (untagged)
After 6fe15f6df9:
handle->raw() returns ObjectPtr
obj_ptr->ptr() returns ObjectLayout*
New world:
handle->ptr() returns ObjectPtr
obj_ptr->untag() returns UntaggedObject*
TEST=ci
Change-Id: I6c7f34014cf20737607caaf84979838300d12df2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149367
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup` (or to another place).
The access of `ObjectStore::closure_functions()` was spread out over our
codebase, including from `Isolate`. This CL moves it to a centralized
place - ClosureFunctionsCache.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I3b282623f07614cdc2c2a863bd5b9d6c7748d36f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177130
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup`.
The class_table and object_store were already moved to `IsolateGroup`.
This CL only replaces usages of `Isolate::{object_store,class_table}`
with the equivalent in `IsolateGroup`.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I34a0682d715b054d6c5faff077a513980f59a348
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177126
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Instead, split each old use into the following cases:
* If the TokenPosition value is expected to be a real token position,
then use TokenPosition::Pos().
* If the TokenPosition is being serialized in some way, then use
TokenPosition::Serialize() and change the place where the
TokenPosition is recreated to use TokenPosition::Deserialize().
* If the value of the TokenPosition is being printed for debugging
purposes, then just use TokenPosition::ToCString() instead.
That is, we try to pin down when token positions are expected to
be real vs. when other types of token positions can be found.
Another source of possible error when using token positions is to
convert between synthetic and real token positions. In the past,
synthetic token positions may have been based off real token positions,
but that is no longer the case. Thus, all methods that allow
that conversion have been removed, and instead there is a new static
method for constructing synthetic tokens from valid nonces.
This CL also makes it so that Pos() and relational operators on token
positions are only defined on real token positions, to avoid any
assumptions about what the value encoded in synthetic positions mean. To
help with cases where non-real token positions may occur, four helper
methods are added:
* TokenPosition::Min(a, b): A static method that returns the smallest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::Max(a, b): A static method that returns the largest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::IsWithin(start, end): Determines whether `this` falls
between `start` and `end` (inclusive). If `this` is non-real, then it
must be either `start` or `end` if synthetic, otherwise false.
Otherwise, we mimic the old style of range checking, which means that
non-real starts and ends are treated as less than every real token.
* TokenPosition::CompareForSorting(other): Unlike the relational
operators, provides a comparison between any types of token positions
for purposes such as sorting. Currently only used in the profiler.
It also changes TokenPosition::ToCString() to tag synthetic token
positions, so they can be distinguished from real ones at a glance.
TEST=Existing test suite on trybots, especially the observatory tests
which make heavy use of the debugger and the unit tests for the
profiler/source report modules.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: Ic06aa0bc7a1f0fbac7257ed22ca5e7e0ccd7f3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174924
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
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: I29531247a4b91a99d9a459cfdefbb9798e9c948f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175246
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit 5370c56c80.
Reason for revert: Failures on
dartk-android-product-arm
dartk-android-product-arm
dartkp-linux-release-arm-qemu
like this:
sizeof(ScriptLayout) got 64, Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
sizeof(ScriptLayout) got 64, AOT_Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
Original change's description:
> [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>
TBR=vegorov@google.com,bkonyi@google.com,jensj@google.com
Change-Id: I5187e6749d59ded250ec0933a94db0536485b70a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174470
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
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>
Since the transition from Source based to Kernel based frontend to the
Dart VM, we have not supported callable redirecting factories. This has
caused all removed code in this CL to be unused and untested!
The support for reifing redirection related information would mainly be
used by embedder / dart:mirrors. Right now its not used by anyone and
the kernel support was never implemented.
I suggest we remove the unused and untested code until a decision has
been made that we actually want to support it - in which case it can be
properly implemented, possibly by re-using some of the deleted code in
this CL.
TEST=CL removes unused code, no test result changes.
Change-Id: I7ed45c85b4efcc1e81ce44cbe08bb555e52101b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166853
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Tony