This adds support for the legacy server to switch to URIs using a client capability. In this mode, all "FilePaths" will be URI strings over the protocol (in both directions).
It also allows the server to send LSP notifications (wrapped inside an "lsp.notification" notification, matching how requests/responses work). Notifications are automatically enabled if the client uses any LSP methods or sends the new "supportsUris" capability.
Change-Id: I5d2b76e396862129c61de70d57397603c958a02d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349120
Reviewed-by: Jaime Wren <jwren@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
This is marked as experimental, and is only intended to be used by
`dart fix` as a way of formatting the files that were modified if the
analysis options file indicates that they ought to be formatted.
Change-Id: I288baebfc7cb3f82cc361bdc19835e43064eb0d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238921
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds quite a lot of information though, because we send many
strings.
Before: 20686 characters.
After: 55345 characters.
Theoretically we could do better, and send information about existing
imports only once as well, so when the user continues typing in a
single file, without touching imports, we don't send any new data
about imports (maybe just a confirmation that it is still the same).
But I'm not sure if this is a worthwhile optimization.
Actually, even included suggestion sets have similar property - they
don't change for a given file, unless there are changes to other
libraries which we might want to include.
R=brianwilkerson@google.com
Change-Id: I2f55e2dc85508849146aa39eb279beabaec937c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103561
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change adds a new, experimental completion domain request
`completion.listTokenDetails`. Its purpose is to allow
other programs to observe and make smarter decisions contingent
upon analyzer's internal knowledge of a Dart program.
Bug: 36083
Change-Id: I5ab477221efeac076eccc873a29cf6feae91052e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95100
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
interest in receiving not yet imported code completions from specific
packages and libraries.
The design of this interaction aims to avoid forcing analysis server
to send every public symbol from dependent packages at every completion.
Instead, clients express interest in certain packages and/or libraries
and analysis server will notify with the entire set of symbols for
each of them only once. Then it is the client's responsibility to save
these pre-computed completions in memory, and analysis server can
instruct the client on how to union them with the base set of completion
suggestions at code completion time.
Bug: https://github.com/dart-lang/sdk/issues/35680
Change-Id: I42c6fddc5d8daa2b546daa81456c0992e3ef547d
Reviewed-on: https://dart-review.googlesource.com/c/90125
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL extends the dartfix protocol to allow specifying which
fixes should be applied. In summary:
* includedFixes - list of fix names to be applied
* includeRequiredFixes - bool indicating required fixes should be applied
* excludedFixes - list of fix names that should not be applied
Given that the client can specify the fixes to be included/excluded,
then the dartfix cmdline help text should include the list of known fixes.
Rather than hard code this in the dartfix client, a new edit.getDartfix
request has been added to return the list of known fixes.
Change-Id: I319f6f405a5d29757bf28b70b778a449f901bbef
Reviewed-on: https://dart-review.googlesource.com/c/91700
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The goal is to provide clients (specifically VS Code) with API that
is fast, and can search top-level and class member declarations.
I'm not sure whether we want ElementKind, it has kinds that we will
not use, e.g. I don't think we will return local variables or
parameters.
It would be probably still a lot of information, maybe we should use
single string table in response?
R=brianwilkerson@google.com
Bug: https://github.com/dart-lang/sdk/issues/29510
Change-Id: Ie31bb398a08d462c1cb08c7d82c4443c0c09932a
Reviewed-on: https://dart-review.googlesource.com/42105
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov