It's only valid to reuse a client that is not showing an embedded page, however we only get the embedded flag when a client sends a "currentPage" event.
There is a period between a client connecting and sending this event where we would consider it reusable when it's not. This fixes that by keeping a flag to indicate if a client has completed initializing (that is, it has sent its initial page).
See https://github.com/Dart-Code/Dart-Code/issues/4832
Change-Id: I9f2d43d1537ee97e4e231a844831e7548cf07beb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336041
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Some of these tests failed if `Directory.systemTemp` had a lowercase drive letter because DAP always normalises outbound paths to uppercase and we were comparing them directly.
This updates offending tests to compare with uppercase drive letters as is expected, regardless of the original temp directory (used for "cwd" and "program").
Fixes https://github.com/dart-lang/sdk/issues/53949
Change-Id: Ibaa6b6ecfe3d77aeff5b806174167c9452167db6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334160
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This adds a check that scripts exist before we create a sourceReference to assume we can download them.
I don't have a good way to test this (in the Dart SDK) because this never happens for Dart - we can always download the scripts. However this code is triggered in Flutter because of https://github.com/flutter/flutter/issues/128880 - we can't find the source so we will try to set it up for downloading.
Fixing that would avoid the need for this change (and make the behaviour more consistent with Dart), but in the meantime I think it's better that we don't produce sourceReferences for sources that don't exist.
Change-Id: I4de3f6e87fe3ff867a1ff7e6d3a5d79f7bf9fa1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330780
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
To reduce the headache associated with adding parameters to VM service
APIs, VmServiceInterface has been removed from package:vm_service and
pulled into its own dedicated package:vm_service_interface. This will
help reduce the need for major version bumps of package:vm_service,
which requires manual version bumps through >8 packages in order to make
the latest version available to flutter_tools and DevTools.
This separation of the VmService client from the interface will reduce
the frequency of major version bumps to `package:vm_service` as adding
optional parameters to existing APIs would cause implementers of the
interface to break.
package:vm_service continues to expose a copy of the contents of package:vm_service_interface to avoid breaking google3 rolls until package:dwds can migrate to package:vm_service_interface. package:vm_service will not be published until this copy is removed.
This change also includes:
- some code cleanup and modernization to both the code generator and
generated code
- >=3.0.0 SDK version requirement to allow for new language features
Change-Id: Ib1859c1b4e153fef7ee1f91e67e881bbf42652c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330500
Reviewed-by: Derek Xu <derekx@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Normally in the debugger we return truncated values, but there are some cases where the user expects the full value. The legacy DAP handled these, but the new DAP did not.
With this change:
- "Copy Value" (context: clipboard) actions will always copy the full string (and without quotes)
- the REPL/Debug Console will include the full untruncated string
Fixes https://github.com/Dart-Code/Dart-Code/issues/4730
Change-Id: I6e43f8e21ca606d4ea1e9f1c30a111d7a4d82f20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326642
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL passes the offset and uri of the file (here called a script uri
as opposed to a library uri, the two will be different if we're in a
part) when doing expression compilation.
This CL only passes the data, but doesn't actually use it.
Future CL(s) will use this data to calculate the static type of
available variables which is needed for an upcomming feature.
TEST=Existing tests.
CoreLibraryReviewExempt: Not changing SDK APIs.
Change-Id: I67ead461ab4bb9341424e693946f3e4afe35ce92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329322
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This adds two custom requests to the DAP-over-DDS handler to translate between VM/DAP instance IDs:
- $/createVariableForInstance (String isolateId, String instanceId)
- $/getVariablesInstanceId (int variablesReference)
Because DAP's variables request only fetches _child_ variables (eg. fields) but we'd likely want to align the top-level string display of a variable, the wrapped variable will first be returned as a single variable named "value", which contains both the string display value and also a variablesReference to then get the child variables (usually invoked when expanded).
These methods currently live directly in the DDS DAP adapter since I figure they're only useful for clients using the VM Service, but we can move them to the base adapter if in future this turns out to not be the case.
Change-Id: I60f28edd86c3468cc592175cb665557a1fc85056
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312987
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This is for an internal debug adapter to extend the test debug adapter and provide a custom URI converter to provide internal local paths during breakpoints.
Change-Id: I3b61b70fe07e14f08ff37443ef87facc523bf7fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313000
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
We used to generate our own thread ID starting at 1 and counting up. There was always a 1:1 mapping from a DAP thread to a VM Isolate. With this change, we always use the Isolate number as the thread ID which makes it easier for tools using both VM Service and DAP at the same time.
Change-Id: Id8d82f6fd5134987f2ecfeaa761765d55999405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312906
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This fixes a bug where we'd produce the wrong absolute path for stack frames that had absolute paths (because `package:stack_trace` uses `path.absolute()` on them).
It also adds support for making stack frames in printed stack traces faded if they are not part of the users own code. This is something the legacy DAPs did. I've also made it possible to perform this stack parsing on non-error events because I'd like to use it on Flutter structured errors (again, something we supported in legacy adapters and was missing here).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4573,
Change-Id: I6c1c3ab69915eca9a1eeef5dcba7f1eb558086de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311842
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
When there are multiple isolates, we may get breakpoint responses/events like this:
- Request/Response to add breakpoint to Isolate 1
- Request/Response to add breakpoint to Isolate 2
- BreakpointAdded for Isolate 1
- BreakpointResolved for Isolate 1
- BreakpointAdded for Isolate 2
Because Isolate 2 did not load the script, the last breakpoint was never resolved. However because the breakpoint ID matched, we would forward this event to the client and un-resolve the previously resolved breakpoint. This would result in odd behaviour in VS Code.
Additionally, the VM may return the same BM breakpoint ID for what the client thinks are two breakpoints (they are on different lines, but resolve to the same location) so when we get a resolved breakpoint, we need to handle both:
- Client breakpoints that have already been transmitted
- Future client breakpoints that may resolve to this same VM breakpoint
The previous code assumed that a BreakpointResolved event could be handled just once. Either for an existing breakpoint, or a future one.
This change swaps from storing queued events to storing the resolution information for each breakpoint, and it does this even if there was an existing breakpoint (in case the breakpoint is reused in future).
Fixes at least some of https://github.com/Dart-Code/Dart-Code/issues/4598
Change-Id: I53b92debfaa0c8f538dc8d67966854bb89634708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311480
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The existing 'evaluateGettersInDebugViews' evaluates getters eagerly which can have side-effects. This adds a setting that allows showing getters in a way that can be shown lazily instead.
I added a new setting (instead of just making evaluateGettersInDebugViews=false be lazy) to preserve the ability to have getters not shown at all (since some users are using that today and might prefer this over lots of lazy getters showing up).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4234
Change-Id: I56c2a7c8f85aa8c4cc85cfb3120a8cfec6b54c70
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310164
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
When adding new breakpoints, DAP clients send a full new set of breakpoints which results in us removing and re-adding all breakpoints (for a file).
When we re-add a breakpoint that already existed, we would sometimes get the BreakpointAdded event _before_ the addBreakpointWithScriptUri request completed. We couldn't process the event because without the original request completing we could not map the VM breakpoint back to the clients breakpoint to generate the event.
This could result in resolution events being lost, and breakpoints becoming unresolved when you modified them (depending on timing).
This change collects queues and replays any BreakpointAdded/BreakpointResolved events that arrived when the breakpoint ID is unknown, and when `addBreakpointWithScriptUri` completes, it immediately processes any items in this queue.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4599
Change-Id: I11daaf99b786ab94f1cc93f9fd38a4f1e241320f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310620
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
When an isolate is paused, we store some data for things like variables, stack frames, etc. to round-trip an identifier to the client that it can ask about later.
Previously we never cleared these, so over time in a long debug session they could build up. The DAP spec says these references become invalid when execution is resumed:
> To simplify the management of object references in debug adapters, their lifetime is limited to the current suspended state. Once execution resumes, object references become invalid and DAP clients must not use them.
Because it's possible to resume one thread without another, I'm clearing up only the specific thread (isolate)s data when it resumes, rather than all of it.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4420
Change-Id: I2ba7d9cd3f23b5a628d9e279e49edf2bee5afd29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Currently when the user configures a Dart CLI program to be run in the terminal, we ask VS Code to launch it in the terminal before we respond to the launch request. This (depending on settings) can cause VS Code to show the terminal and then switch to the Debug Console (which is both confusing and frustrating for users that opt-in to do this to access stdin of the terminal process).
This change reverses the order when using `runInTerminal` so that `launch` is responded to first.
See https://github.com/microsoft/vscode/issues/168295
Fixes https://github.com/Dart-Code/Dart-Code/issues/4287
Change-Id: If9a221361cc3329fb86fb17ba532043266b3438c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307481
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Chingjun Lau