Part of the process to remove uses of
DartDevelopmentService.startDartDevelopmentService in favor of launching
with `dart development-service`.
Change-Id: I857aee932c0b2fc6ae2172eb106b78c76d536295
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/380760
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
With this roll, Chrome now triggers a dialog on MacOS requesting
credentials. This results in timeouts for
pkg/dds/test/devtools_server/remote_control_test. To avoid user
input, we use a mock keychain instead. The same change has gone
into browser_launcher_rev, and so we include that commit here.
Bug: https://github.com/dart-lang/sdk/issues/56519
Change-Id: I0e0733b658eb09b0775178e617e5ceb42e184ec4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381705
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Capturing debug logs that includes VM Service traffic is useful for debugging. Previously with the new DAPs, this could only be enabled at session start which meant users would have to capture very large log files.
This adds the ability to enable/disable this logging while a debug session is already running. A related change in Dart-Code will send this request when you use the "Capture Debugging Logs" command, so you can start a debug session, get to the point of reproducing an issue, and then just capture the relevant logs (VM Service traffic included).
Fixes https://github.com/Dart-Code/Dart-Code/issues/5197
Change-Id: I7e766e57bd80819eb5da164e544903fae23927ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377222
Commit-Queue: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
This moves the CLI logic into lib/src/dds_cli_entrypoint.dart so it can
be invoked by a custom google3 entrypoint (bin/dds.dart can't be
imported using a package: URI).
Since google3 will be able to perform some custom configuration of DDS,
google3 related logic (e.g., `BazelUriConverter`) is also removed. This
is technically a breaking change, but should be safe as this
functionality isn't currently being used.
Change-Id: I54d8a9927ff2df70e013ca5c8bc1d510b0b95f02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371520
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
When a class contains both a field and getter with the same name, we'd include both in the `variables` response. In most cases these are the same value (although it's not guaranteed).
I've chosen to just hide the field in this case and always show the result from evaluating the getter (since I think that's what the user would expect, even in the case where they happen to have different values). Another option could be to show both (but change the name so that fields/getters are shown differently), however in that would change the display (for example adding `get ` in front of all getters) we should probably only do that if it's clear there is demand for it.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5128
Change-Id: I9e23d22a844ee22c38988456b1f275422c5c9e04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370640
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
IntelliJ expects a "type" field for events; otherwise the JSON will not be parsed correctly. This came up as part of making the widget rebuild table in DevTools clickable (https://github.com/flutter/devtools/issues/4564)
I'm not totally sure this is the change I need, as I don't know how to test this out end-to-end (build Dart SDK and put into Flutter SDK, then run an app with these changes in DDS?). I think it's right because I'm modifying a spot that was first added in https://dart-review.googlesource.com/c/sdk/+/304981, which added `postEvent` in dds_service_extension.
Change-Id: I9a78903dca7855896b6a9b9c3f9e1d62dcb7099e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368202
Reviewed-by: Dan Chevalier <danchevalier@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Sometimes we see unhandled exceptions during this setup work, see:
- https://github.com/flutter/flutter/issues/148346
- https://github.com/flutter/flutter/issues/148348
Currently these are unhandled and bring the debug adapter down. In VS Code, the error (send to stderr) is not visible to the user so they just see a silent crash which makes it very difficult to report (and the Flutter crash reports don't have any context).
This change will send the exception to the client and then cleanly terminate, which should give the user more information to open a good bug report (assuming the issue wasn't just something like them terminating the app as it was starting).
Change-Id: I4aefbc278e6a0708924c6fa41c5179d581117689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366662
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
getObject and invoke would `throw` if the response was a sentinel and that wasn't handled correctly, which meant sometimes an entire variables request would fail instead of only the individual values (eg. in a map/list) being shown as erroring.
This improves https://github.com/dart-lang/sdk/issues/54897 (you'll no longer see the entire request fail), but it still needs paging adding too.
Change-Id: Ic3ed3bee7c1dd647ebae843007bd30b0e1fda590
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364860
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Breakpoint IDs were used in a few places here assuming they were globally unique, however they are per-isolate. If all isolates were given the same breakpoints this would work out fine, but when isolates were created/destroyed (eg. during hot reload) we could end up sending back the wrong resolution info to the client, resulting in breakpoints jumping to other locations (even though they were actually set in the correct locations).
Fixes at least some of the issues noted in https://github.com/dart-lang/sdk/issues/55268
Change-Id: I7acf93b99885c87ee0edd9ac1876f895c8943c51
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365041
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
Generally we don't untrucate values in the debugger in places where there might be lots of data (such as calling `toString()` on all variables) because it can cause performance issues if the variables are huge.
If you use the "Copy value" ("clipboard") or Debug Console evaluation ("repl") we _do_ always untruncate the values.
However, this code was always untruncating when we called `toString()` on custom classes. This changes it to no longer do so, making long string values consistent between what you see as the values of fields, and the `toString()` results against a class.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4986
Change-Id: Ica3c5ecfed9492ab76fbfa83d161765b3b24eb22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363320
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
The legacy debug adapters would scan all output for stack frames but when building the new adapters I only parsed stderr (because the stack frame parsing captures quite a lot and it seemed unnecessary). It turned out many users appreciated the IDE linking up stack traces in stdout too (because their exception logging framework may handle exceptions and print them this way, or they might have helpers to print the current stack trace to aid debugging).
This marks `parseStackFrames` as deprecated from `sendOutput` and scans all output for frames, while filtering out things that don't look like Dart URIs before calling `lookupResolvedUris` to try and avoid making general output async/slow.
If Flutter considers deprecations a bot failure, this will need to be rolled in manually.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5072
Change-Id: I8857281fb79ca69328074d6ad6a0c0a505e5c193
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362804
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
This upgrade requires adapting to breaking changes for the unified_analytics and DevTools extensions logic in `devtools_shared`.
unified_analytics:
- remove the `unified_analytics` dependency from DDS. The DevTools server handler no longer interacts with this package.
DevTools extensions:
- Serve DevTools extensions from their absolute location in the pub cache.
Bug: https://github.com/flutter/devtools/issues/7547
Change-Id: I13e08c48c5335cccbddecebe907ff9dcc337c461
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362062
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Kenzie Davisson <kenzieschmoll@google.com>
This reverts commit 023fd7f664.
Reason for revert: Appears to have broken a number of tests on Windows bots.
Original change's description:
> [ DDS ] Add support for google3 URI conversion
>
> Copied BazelUriConverter from google3 and added
> `--google3-workspace-root` option to `dart development-service` command
> to allow for mapping google3 URIs to local file paths. Moving this code
> into the SDK is necessary to avoid injecting custom logic into DDS in google3.
>
> TEST=Updated uri_converter_test.dart
>
> Change-Id: Ife55ba534c99498e471753043bb5c42715369622
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361440
> Reviewed-by: Helin Shiah <helinx@google.com>
> Reviewed-by: Derek Xu <derekx@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: Iaffc300fe2b12254471d9576e6d4880ef3ec3633
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361134
Reviewed-by: Alexander Aprelev <aam@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Copied BazelUriConverter from google3 and added
`--google3-workspace-root` option to `dart development-service` command
to allow for mapping google3 URIs to local file paths. Moving this code
into the SDK is necessary to avoid injecting custom logic into DDS in google3.
TEST=Updated uri_converter_test.dart
Change-Id: Ife55ba534c99498e471753043bb5c42715369622
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361440
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The `dart development-service` command will be used by tooling to launch
DDS from the SDK instead of shipping DDS via package:dds.
TEST=Existing service test suite
Change-Id: Ib928aa5b8961caf87d7074884c3d226b5c096ccd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361180
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This change reworks the client resume permissions API to make it easier
for clients to deal with user provided `--pause-isolates-on-start` and
`--pause-isolates-on-exit` flags.
`requireUserPermissionToResume` should be called by the tool that
launches the Dart process to indicate whether or not the user provided
`--pause-isolates-on-{start,exit}`. The default behavior is to assume
that a tool set these flags for its own use (e.g., resetting breakpoints
after a hot restart in Flutter), where isolates will resume immediately
after each client that has indicated interest in that pause event has
invoked `readyToResume`.
If a user provided one of the previously mentioned flags, isolates will
not immediately resume after each relevant client has invoked
`readyToResume`. Instead, a call to `resume()` must be made to indicate
the user has triggered the resume request instead of tooling. If the
user permissions to resume are changed while the isolate is paused and
all relevant clients have invoked `readyToResume`, the isolate will
automatically resume if the user no longer requires us to wait for a
user resume.
`resume()` now also acts as a "force resume", bypassing any required
permissions set by tooling.
This behavior change is breaking, so the DDS protocol version is being
bumped to 2.0.
`package:dds_service_extensions` has also been updated to include the
following DDS RPCs:
- `requireUserPermissionToResume`
- `readyToResume`
Change-Id: Id5f0806b3c56507d39eb00b6305b8896bab13ae7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357420
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This adds support for printing the DTD connection information to stdout
when --print-dtd-uri is passed.
This change also fixes an issue where DDS would fail to spawn an isolate
with the DTD snapshot when DDS was running in AOT mode. This means the
SDK must be shipped with both AppJIT and AOT DTD snapshots, at least
until dartdev is moved to run from AOT.
Fixes https://github.com/dart-lang/sdk/issues/55034
TEST=run_test.dart
Change-Id: I788ef9bfe76297a8d594992a2aac440ed9e2ecac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358541
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
The move to URIs introduced a subtle bug here - we would use the mapped URI (which is almost always `file:`) to decide whether to show a file path, instead of doing it only if the unmapped URI was a `file` (eg. it could have been `package:` or `dart:`.
This wasn't caught by any tests here, but was caught in the Flutter roll (https://github.com/flutter/flutter/pull/145235). This fixes it and adds a new test that we verify the Source names for local files, packages, and dart: URIs.
Change-Id: I282bf935b9fa4016abeafd556dfd368950ee9611
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357325
Commit-Queue: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
The VM service may now give us `dart-macro+package:` URIs in addition to normal `package:` URIs. These can be mapped to `dart-macro+file:` URIs in the same way that we map `package:` to `file:`.
If the client editor has advertised that they support our custom Dart URIs, we can send these through to the client and let them use the analyzer-provided local sources. Otherwise, we'll treat them like other unknown sources and download them from the VM.
Change-Id: If67523a615c66c469db7b1f52d281c63241eb859
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357143
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Fix an issue where DDS would fail to initialize when an isolate in the target process was unable to handle service requests (e.g., when executing FFI code or blocked on a system call).
Fixes b/323386606
Change-Id: I659ebaf750e2c800e9819809d1104e024cb059da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354681
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Derek Xu