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>
* 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>
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>
Previously if no Bazel/Blaze symlinks were present, we defaulted to the
`bazel-*` ones and never checked if that assumption was accurate. This
change starts watching the symlinks and recreates the analysis contexts
if a symlink gets added. This way we'll run the `BazelWorkspace` code
again and use the correct paths.
This is quite important since `bazel/blaze clean` does remove the
symlinks so if the analysis server starts at such a point, we would
never find any generated files if the workspaced turned out to be a
Blaze one.
Bug: http://b/175087705
Change-Id: If7bb21c7d69a3092832c18004691d56949e5af54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/197540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Michal Terepeta <michalt@google.com>
This should allow doing partial migration, specifically protocol files,
which are imported by other libraries, but are a small library cycle
that does not import much outside of it.
Change-Id: I904c05d6d5b444ee9a9dbd1f7ada12aabdcc5165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193583
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This does a few optimizations to improve the performance of the analyzer
when watching for generated files:
- We do all the polling in a separate isolate.
- We detect when Bazel finished running and only poll afterwards.
- We use a batch interface and deliver all changes at once (instead of
one by one). This allows us to avoid resetting caches more often than
necessary.
I had to remove one of the larger tests and created an integration test
instead, since the code for detecting the Bazel builds relies on
`dart:io` directly (`ResourceProvider` does not expose a way to
check for symlink targets).
Since this required a bit more code, I've decided to create a separate
file for it (`bazel_watcher.dart`).
Change-Id: I6c2383e7fd4348ab8af1af639b10db519c7a2f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183010
Commit-Queue: Michal Terepeta <michalt@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
AnalysisDriverResolutionTest is partially updated, about 30 failing
tests added. I will get back to it in a following CL, it is not
directly CFE integration, but updated understanding how we want to
resolve. For example we don't need types for non-expression identifiers.
Change-Id: I3daddbb6c66ffad7a726f3313a1199fd7387aa04
Reviewed-on: https://dart-review.googlesource.com/71883
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This gets the tests running again. I'll follow this up with CLs that
reshape the ResolutionStorer API to match the Factory API we're
building, and then after that we can transition the code over to
calling the Factory API directly.
Fixes#33504Fixes#32258
Change-Id: I105841ed5b2ed1198ec5e3e7387f694c61d36ca7
Reviewed-on: https://dart-review.googlesource.com/61101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
We have decided to move to a different API for Fasta/Analyzer
integration, one that doesn't involve compiling to Kernel or observing
type inference. The listener API will become broken, so let's just
remove it before that happens.
We lose the ability to trace type inference so let's restore that
ability next. The analyzer's resolution storer is not used, but that
code has been left. The resolution applier will no longer work
without the resolution storer, so those tests have been disabled.
Change-Id: If9ac5aba2d5de7788d8a65f7fa8410599e636d21
Reviewed-on: https://dart-review.googlesource.com/42400
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This required some changes to analysis_server, since analysis_server
used to have its own version of pumpEventQueue(). Since
pumpEventQueue() is now provided by the test package, I've removed
analysis_server's version, and I've updated some of the call sites to
pass in "times: 5000" to replicate the old analysis_server behavior.
This also required some changes to analyzer, since the fail() method
is now marked as @alwaysThrows, so no code may follow it without
producing a dead code hint.
Change-Id: Ie5ef3a5cc685c18da02de699e59f63f3bb8865f7
Reviewed-on: https://dart-review.googlesource.com/32683
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Keerti Parthasarathy