_yieldControlToDDS
Instead of DDS failing to connect when there are existing clients
connected to the VM service, the VM service will now disconnect these
clients when _yieldControlToDDS is invoked.
If an existing DDS instance is already connected, existing clients will *not*
be disconnected and instead an error will be returned containing the URI of
the existing DDS instance.
TEST= runtime/observatory/tests/service/dds_disconnects_existing_clients_test.dart
Change-Id: I08e126d99f51ff14205f359a60ca802c27fd206d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178725
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Add extra digit after period when there is only one before.
"1.21GB" is more helpful than "1.2GB", where an 8% change is needed to
make a visible difference.
TEST=Manual
Change-Id: Ib3e645245f57459fbdb0dc9cba2194fd8e634865
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176840
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
All existing embedders have been opted into --lazy-async-stacks, the
VM also uses it as it's default in all configurations.
After this CL, any user of --causal-async-stacks will get an error
message when trying to use it.
=> In any such case, please simply remove the flag.
TEST=Exhaustive CQ.
Bug: https://github.com/dart-lang/sdk/issues/37668
Change-Id: Ia440afcf2dba464aa8b8cf381b93bbac8eb9f8dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172564
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
prevent repeated port allocations
Flutter makes heavy use of short-lived Timers which currently causes
repeated opening/closing of the Timer port. This change allows for
RawReceivePorts to be set active / inactive, allowing for a port to be
kept open but not considered alive.
Flutter benchmark changes:
Before dart-lang/sdk@d5118d5: "notifyListener2_iteration": 545.0
After dart-lang/sdk@d5118d5: "notifyListener2_iteration": 1639.0
With fix: "notifyListener2_iteration": 629.0
Fixes https://github.com/flutter/flutter/issues/69583
TEST=Updated port state tests and verified change against Flutter's microbenchmarks
Change-Id: I50ff1a1b0f1f29bcdac958e41c66429e9586fba2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171628
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This test, it turns out, only works for these particular flags.
Any other combination of causal/lazy-async-stacks will make it break.
Change-Id: I03efa5c28f49e6bbdb9da359270a0f7eff072924
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170436
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
This reverts commit 5bf9163e1b.
Reason for revert: Tests failing on bots.
Original change's description:
> [ Service / dart:isolate ] Added getPorts RPC and 'debugName' optional
> parameter for ReceivePort and RawReceivePort
>
> This change collects additional information related to ReceivePort
> allocation locations and an optional debug name that will be displayed
> by tooling. ReceivePort is now a special InstanceKind and a ReceivePort
> @Instance will include the port ID, allocation stack trace, and debug
> name.
>
> Change-Id: I003cfff2b7649218e37d9b653c0e953df5d992e7
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167902
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I39c3abb07c8c40c158eb4549749b076399bccce9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169160
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
parameter for ReceivePort and RawReceivePort
This change collects additional information related to ReceivePort
allocation locations and an optional debug name that will be displayed
by tooling. ReceivePort is now a special InstanceKind and a ReceivePort
@Instance will include the port ID, allocation stack trace, and debug
name.
Change-Id: I003cfff2b7649218e37d9b653c0e953df5d992e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167902
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This test has been failing on vm-kernel-precomp-win-release-x64 bot as
it was getting only 3-10 samples, while expecting >10.
The expectation doesn't look reliable as we cannot guarantee that
profiler would collect enough samples.
Changed the expectation to >0 samples, in an attempt to make this test
less flaky.
Issue: https://github.com/dart-lang/sdk/issues/43713
Change-Id: I3a8a3854f3828d39eb409b1b540f29a34fe9e6b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167043
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The debugger async function handling has been moved to allow handling
of stepping_fp_ and async_stepping_fp_.
Previously the presence of an async function would take precedence over
the *stepping_fp while stepping, resulting in nested asyncs to
incorrectly re-trigger the insertion of synthetic breakpoints.
This fix revealed three tests that were still testing for unintentional
inconsistencies between causal and lazy async.
Note that there are still tests that branch on `useCausalAsyncStacks`
though these all test for known differences - namely that lazy async
cannot traverse unawaited future calls.
Cq-Include-Trybots: luci.dart.try:app-kernel-linux-debug-x64-try,vm-kernel-linux-debug-x64-try
Change-Id: I5f74db18086a90828024dbb461759869531d478f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164781
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
We create the parameter names array when loading the
FunctionDeclaration, but the required parameter flags are only set later
when we load the Code declaration. If there's an intermediate use of the
Function object that copies the required parameter flags, like creating
an ImplicitClosureFunction when loading a tearoff stored in the object
pool, there will be no set flags at that point.
Add a copy of the parameter flags to the FunctionDeclaration so the
required flags can be set at the same time as the parameter name and
type to avoid this scenario.
To avoid adding unneeded flags to the kernel bytecode, we only serialize
the parameter flags needed for each declaration, so FunctionDeclaration
and ClosureDeclaration only contain the required flag, and Code contains
all flags _but_ the required flag.
There are no trybots for strong mode + bytecode, but manually checked
by running the following on the main branch (cherry-picking the
test_matrix.json changes) and this branch:
python tools/test.py \
-n dartkb-mixed-strong-linux-release-x64,dartkb-interpret-strong-linux-release-x64 \
tests/language/nnbd/required_named_parameters/missing_required_argument_dynamic_test.dart
Cq-Include-Trybots: luci.dart.try:vm-dartkb-linux-release-simarm64-try,vm-dartkb-linux-release-x64-try
Change-Id: Ic75b831d5ceed08154e2c61b8f64461705558653
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162501
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
The major revision bump is causing Intellij users to be unable to debug
as the Dart and Flutter plugins both bail out if the VM service major
revision is not 3. This change will allow for these plugins to keep
working.
This is technically breaking the semver contract as the following RPCs
and objects have been removed:
- getClientName
- getWebSocketTarget
- setClientName
- requireResumeApproval
- ClientName
- WebSocketTarget
However, these RPCs were never used by first party tooling and it's
highly unlikely that they were used externally, so removing these RPCs
is unlikely to break anyone.
Change-Id: Ie8e2705545682e96c3dab4c0787a1e88cd8a19d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162240
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Clement Skau