This does not remove the computation of available declarations. This CL
seemed big enough without that, so I (or someone else) can get that in
the next CL.
Change-Id: I67ab49b75c8a415ccfaef16c4e49a00026a6091f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341160
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit d032598d26.
Reason for revert: SDK build is broken if the checkout path includes "build" as a path segment.
Original change's description:
> Support multiple packages in a PubWorkspace.
>
> A PubWorkspace is now
> - rooted at package config, or the outermost pubspec if there is no package config
> - packages are identified by pubspec
> - all packages are considered to be package build packages
>
> Change-Id: Id1552ab584ccedf60a482b93b375d1c4c7da6796
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337607
> Commit-Queue: Keerti Parthasarathy <keertip@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Reviewed-by: Samuel Rawlins <srawlins@google.com>
Change-Id: I2ecda907b8bb6164c7cc5446aceff1f168810341
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338560
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Auto-Submit: William Hesse <whesse@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
A PubWorkspace is now
- rooted at package config, or the outermost pubspec if there is no package config
- packages are identified by pubspec
- all packages are considered to be package build packages
Change-Id: Id1552ab584ccedf60a482b93b375d1c4c7da6796
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337607
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
No functional changes, just some refactoring extracted from another change to simplify reviewing.
This just:
- adds an `initialAnalysis` getter for tests since it's very common to wait for
- adds a `diagnostics` map that tracks the current state of diagnostics in a test (to avoid tests setting up their own tracking)
- removes some duplicating code for sending diagnostics by having NotificationManager call LspAnalysisServer to send them
- removes unnecessary experiment flags from LSP tests
Change-Id: I1811f393a6d3446550f9007ede926f9ca4556563
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337580
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, just moves the snippets tests and a few others off the old marker functions to the new TestCode class for consistency.
With this change, there are approximately 15 remaining instances of "withoutMarkers" to remove (inc. the declaration).
Change-Id: I7f11992bb9ce47740adf6972ed097cabbd011607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333520
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is a minor refactor that adds an explicit test for generating minimal edits without going through the formatter.
There's no change in behaviour - this is just to reduce the noise in a future CL for inserted/deleted commas to be supported in computing minimal diffs.
Change-Id: I3d254bd7a90ccc7b11700b54110ece040e837363
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329601
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Originally we didn't use the LSP Request/Response classes, and just exposed the handlers through the legacy request/response.
However there were some mismatches (such as legacy protocol always returns Map<String, Object?> but some LSP requests return Lists, LSP using int|String IDs, and LSP having numeric error codes that don't match legacy string error codes).
This change uses LSP's request and Response by wrapping them inside a standard (legacy) handler. The LSP-over-Legacy handler has become a standard handler, and the params contain an "lspMessage" field that holds an LSP message, and the result contains an "lspResponse" field that contains an LSP response.
If an LSP handler returns an error, it will be returned as an error inside the LSP response, which will be in a _successful_ legacy request (since that's how we can return an LSP response - as the result).
Change-Id: I67973590ab32f3543d1a6e1b7279974e5e8832bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315201
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The mixin `LspAnalysisServerTestMixin` contains a lot of helpers for interacting with the LSP server in tests and is used by both the in-process tests and the out-of-process integration tests.
We now have a third category of LSP tests that would benefit from many of these helpers (such as "getHover()") but are not talking to a native LSP server.
This change splits those helpers out into `LspRequestHelpersMixin` which contains only the request helpers without any code assuming a native LSP server, so they can be used by LSP-over-Legacy tests.
All code in `request_helpers_mixin.dart` was lifted directly from `server_abstract.dart` with no changes.
It also adds a test that error responses in LSP-over-Legacy are handled appropriately.
Change-Id: I847855a5314b5b04d700c6400b67e76e5f0d3402
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This currently only allows "textDocument/hover". Handlers may need some tweaks to remove any dependencies on LspAnalysisServer before they can be enabled.
Capabilities and config are hard-coded to a very basic set (which I suspect will expand as new handlers are added). Reverse requests and notifications are not currently supported (I suspect these will be added when there are more concrete use cases for them because they may need to be conditional based on real client capabilities/needs).
Change-Id: I8a096f9530ad1518ac5ee876aea2560d269a27ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312303
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The goal here is to ensure tests can't accidentally check only a subset of edits made during the command execution.
Not all tests have been migrated (only refactorings and a few that happened to use some of the same methods for verification).
Change-Id: I5589e8e667e957aee3ea55f741b1b49a3859d6bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312304
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- Adds a new flag, `--suppress-analytics` to the `dart` command to
disable both the unified and the legacy analytics for a single
session while deprecating the existing flag, `--[no-]analytics` used
for disabling the legacy analytics on a single pass.
- Pipelines the flag from `dart` through `dart analyze` and `dart fix`
to the execution of the analysis server.
- Updates all applicable uses of `dart analyze`, `dart fix`, and the
analysis_server binary entry points in the SDK to disable analytics
for the test infrastructure.
Bug: https://github.com/dart-lang/sdk/issues/49445
Change-Id: I1302cad7e04b21454aa7d9e8ee72a876b231377d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287661
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Janice Collins <jcollins@google.com>
* 99% of these are `Future ` --> `Future<void> `
* There are some `test_` methods which declare a return type of `Future` which
is non-idiomatic, I think, but in order to create a pragmatic consistency, I
added `<void>` to the few test methods in these libraries. Later if we
desire, we can remove all of the return types.
* Also a few `Completer ` --> `Completer<void> ` and
`Stream ` --> `Stream<Object?> `
* There are many remaining cases in `lib/`
Change-Id: I41cd51bab6886788e15ac7065dd21e95e789d09f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
* Add a type argument to raw `Future` types (typically `Future<void>`)
* Add type arguments to raw `Map` types (typically Map<String, Object?>`)
* Add a type argument to raw `Completer` constructor calls.
* Use collection-elements in more places.
* Replace an implementation of `String.padLeft` and `String.padRight` with
StringBuffer extension methods that use `String.padLeft` and
`String.padRight`.
* Rename many `sb` variables to `buffer`, which is more idiomatic.
* Move some StringBuffer helper methods to be extensions on StringBuffer.
* Use constructor tear-offs instead of closures which call a constructor.
* Use single quotes where we can.
* Do not prefix constant names with the letter 'k' [1].
* In IntegrationTestMixin:
* Rename to `IntegrationTest`, as it is never used as a mixin.
* Public Stream fields are converted to be getters.
* Private StreamController fields are initialized at their declaration [2],
instead of an initialization method.
* Remove empty zero-parameter constructors.
[1] https://dart.dev/guides/language/effective-dart/style#dont-use-prefix-letters
[2] https://dart.dev/guides/language/effective-dart/usage#do-initialize-fields-at-their-declaration-when-possible
Change-Id: I7a923a80d32f74fbecf42a0fa35ae25285994097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281874
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
I am going to plumb some of this support through the flutter_tools
side, and want a consistent name for this port. 'servicePort' seems to
be more correct.
Change-Id: I73806e1d4c566a82605812504cb354c2b59710ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280562
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This requires some tweaks to to/from JSON code, and some handling for Maps that previously could be serialised directly but now may contain `Uri`s in keys and need to be converted to strings explicitly (since Uri has no toJson method).
Change-Id: I61358d8198ac1da322fae98d6c40747ad08754b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258927
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I don't think that there are any other highlight kinds we're going to
want to add, but if you can think of any please let me know.
I'll add code to actually associate the kind with record literals in the
next CL.
Change-Id: I15922984d96c2d0c7d97ea3f3832a95a68172968
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256524
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson