Following on from a previous change to use the term `CodeAction` (an item returned from a `textDocument/codeAction` request) to mean either a `CodeActionLiteral` (which contains inline edits and/or a command) or a base `Command`, this adds a typedef describing the same and updates all code that used `Either2<CodeActionLiteral, Command>` to instead use the typedef.
It also renames a few additional methods/functions to be more consistent with these terms and adds a `CodeActionExtension` to simplify extracting fields like `command` and `title` from either kind of code action.
Change-Id: Iad5f77ef21229fc5c9738527f98ccf7202f83bd8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425863
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
There are no functional changes, just changes to the way the logging
functionality is implemented. The motivation for the changes is to
allow future CLs to explore ways of changing the expectations so that
async handling of messages won't produce flaky tests.
All references to the 'messageLog' outside the class have been replaced
by higher-level methods with a semantic meaning.
The class has been split into an interface and an implementation, which
allows the test-specific aspects to be in the `test` directory.
Some additional code cleanup was also done.
Change-Id: Ie515f71153a96fb6e92eb8e2eb05f4b5e064bbd7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421965
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This CL makes three changes:
- moves the message scheduler into a new directory,
- splits the implementation into two files,
- and renames `MessageObject` to `ScheduledMessage`.
It does not make any semantic changes to the code.
The expectation is that we will need to make the message scheduler more
complex as part of improving the performance of the server, and that it
will be easier to do this if the code is structured differently.
Change-Id: I3f8741cadceb34c69fd45c1bf21f331d15824565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420500
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is some minor refactoring to support the next CL that will enable the EditArgument request (the one that actually edits arguments, not the one that gets the list of arguments) over legacy.
It moves some code for sending LSP reverse-requests through the legacy server from test code into the actual server (and fixes that they weren't correctly wrapped in the 'lsp.handle' protocol classes) and updates the tests to use the shared interface ready.
Change-Id: I06492138645538072fb12f2fc2d424e214f8055b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404824
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
* 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>
Danny Tuppeny