This adds a new request `dart/connectToDtd` that lets a client pass a DTD URI to the server. The server will connect to DTD and provide a subset of LSP methods (those that are currently available over LSP-Over-Legacy, minus the `connectToDtd` method itself) to DTD clients.
This works for both LSP and Legacy servers, and the shared tests run against both (where for legacy, the `dart/connectToDtd` request uses the LSP-over-Legacy support).
This is not currently behind a flag, however it won't do much on its own because no clients will make this request. Once we're happy the functioanlity is good we can either agree an SDK version number for IDEs to gate calling this method on, or we can expose a flag in server capabilities (and some equiv for legacy) so the client knows the functionality is available.
Change-Id: I911d37745a1b2685249dd88e4b152c3196ba627c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379303
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
This change is just some refactoring and additional flags on handlers to reduce the size of a future CL that adds DTD support.
It:
- Slightly changes the meaning of `lspInitialized` in the server (to now mean the server is in the "initialized" state where it can handle the set of requests LSP allows after a server is initialized)
- Adds an additional future for `lspUninitialized` to track when the server moves _out_ of that state
- Removes an expando in LspOverLegacyHandler that tracked handlers against a server, because they're now available in the `lspInitialized` future (for DTD support, we need access to them without the LSP-over-Legacy handler, because we need to initialize DTD at startup regardless of whether a legacy client triggers LSP initialization)
- Adds a flag `requiresTrustedCaller` to handlers to indicate whether they can only be called by the native protocol clients. Tthis must be explicitly provided for shared handlers to ensure each choice is deliberate. The flag is unused in this CL but included here to reduce noise in the next (it touches many files)
- Changes the type of `toJson()` on generated enum clases to have the native type of the value that is returned
Change-Id: I0615cf4671b84887bf56c236d82d0fa3c26e6d87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379304
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Work towards https://github.com/dart-lang/sdk/issues/53402
I move them all out of static fields on FixProcessor to be instance
fields on a singleton class in a new file, fix_generators.dart. For
each one that ended in the word 'Map', I removed that.
I also move `_bulkFixableErrorCodes` and `canBulkFix` to
BulkFixProcessor, as it is the only caller, and holds onto the data.
I also correct some outdated doc comments.
I also make `_isFixableError` static.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: I01beccac4969f832941c75eb6d7b49b54a0b085c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377563
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We do this by passing a CorrectionProducerContext up each of the
constructors. We can then remove all `configure` methods. This
requires a few changes and allows a few changes:
* Remove ParsedCorrectionProducer. It does not seem to have served a
purpose.
* CorrectionProducerContext no longer needs to be generic.
* Add a public getter for `MultiCorrectionProducer._context`, so that
a multi correction producer can pass along its context to child
correction producers.
* Introduce a `CorrectionProducerContext.instance` dummy variable,
used when we need to check if a correction producer can be applied
in bulk.
* Make `CorrectionProducerContext._node` public, so that it can be
used in factory constructors.
* `BulkFixProcesor.correctionContext()` return type is non-nullable.
* Add a factory constructor for AddMissingParameter, and move the
`configure` logic there.
* Add a factory constructor for ConvertAddAllToSpread, and move the
`configure` logic there. Then make `_isInlineInvocation` and
`_invocation` final.
* Add a factory constructor for ReplaceFinalWithVar, and move the
`configure` logic there. Then make `_removeFinal` and
`_finalKeyword` final.
* Add a factory constructor for ReplaceWithIsEmpty, and move the
`configure` logic there. Then make `fixKind`, `multiFixKind`,
`_binary`, and `_replacement` final.
* Rename `_AddMissingParameter.context` to `_executableParameters`,
and make it final.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If0e9bc1cbf5c8e656938bc6cd4eb32a9d4f06b38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368760
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We decided that the existing mechanism, three bool values that can be
overridden by an AbstractProducer subclass, was confusing as it might
give the impression that they are independent, and that any of the 8
possible combinations are valid. But really each author of a
CorrectionProducer just needs to answer one question: how broadly can
this correction be applied?
So to answer that question we decided (loosely in emails) to offer an
enum of a few values that more-or-less represent the sensible
combinations of the bool getters. And more specifically I decided in
this CL what those values should be.
In this CL I also remove the notion of a default value. Each
CorrectionProducer must indicate specifically how broadly it can be
applied.
This PR should functionally be a no-op; no applicability was increased
or reduced. I left comments intact. I left `TODO(applicability)`
comments where no comment is made to justify why a correction cannot
be made any more broadly than "only at specific location."
Change-Id: I3e3a12ee811b2b08f276ff755e7ff638f4fffabf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366740
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
These are on by default but can be toggled in the client with the "dart.codeLens" setting, either by disabling entirely:
```
"dart.codeLens": false
```
Or individually
```
"dart.codeLens": {
"augmented": false,
"augmentation": false,
}
```
They require a client-provided command to handle the navigation, so this also adds a "commands" section to the client capabilities (in "experimental", because that's the extension point for non-standard LSP) that allows the client to inform the server that it handles such a command (which is documented in the readme and implemented in Dart-Code in https://github.com/Dart-Code/Dart-Code/commit/ebe029c3f9aca724d386b3da10f414f624bc705a).
Change-Id: I91791c9f4aa5957c4ab4b9c0c5bb4fcf8ebeb717
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359640
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This adds a custom command similar to `dart/textDocument/super` but for augmentations.
This won't show up anywhere on its own, but it will be added to the command palette in Dart-Code based on the server capabilities (and in the future, maybe CodeLens - although that will require some additional work in the server first since it will be the source of CodeLens even if they trigger client-side actions).
See https://github.com/dart-lang/sdk/issues/54742
Change-Id: Ib3a3fd08702e14b8bd251991035ef0b8d06ad996
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358452
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This adds a custom command similar to `dart/textDocument/super` but for augmentation targets ("augmented").
This won't show up anywhere on its own, but it will be added to the command palette in Dart-Code based on the server capabilities (and in the future, maybe CodeLens - although that will require some additional work in the server first since it will be the source of CodeLens even if they trigger client-side actions).
See https://github.com/dart-lang/sdk/issues/54742
Change-Id: I11ca115c61ade40bf51478f58b39b7caedac19c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358451
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Useful to focus on measuring performance of computing suggestions
only, without any overhead of resolution, protocol conversion, etc.
To be run as is, or with `--observe:xxxx` to see what to optimize.
You need to supply your own Flutter checkout.
Change-Id: Ie143b4ec9c24e05a0de2a14c1b8f0e1c20ef3a8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358222
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
For package:collection, computing measures.
Before: 0:01:00.236000
After: 0:00:55.977000
So, about 7% faster.
I think this translates into actual completion speed up.
Change-Id: I45f0c0186d5988e6e1b043d465030668cd61335b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357982
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, we only had descriptions of changes on a SourceChange. In order to support annotated edits over LSP for "Fix All in Workspace" we need to be able to track descriptions on each change within a file so that if we're fixing multiple different lints with a single SourceFileEdit they can be annotated/grouped in the UI.
In order to avoid every fix providing a description, ChangeBuilder has a field that allows recording the current change description and all builders created from it will use that description when creating their changes. This allows the BulkFixProcessor to set the description on behalf of each fix producer ensuring they all get descriptions (which is done in a follow-up CL along with Fix All in Workspace functionality).
Change-Id: Ie1c508056898bd4000a5505cf59a1e6d35d28da0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356160
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
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>
This change shouldn't change any current behaviour, but means all "FilePath" types in the legacy protocol spec will go through a (currently no-op) conversion. The server will be able to replace this conversion based on client capabilities in a future CL.
Because a lot of the generated classes are in analyzer_plugin, this also moves the ClientUriConverter class there.
`pkg\analysis_server\test\src\utilities\json_test.dart` contains tests that the toJson/fromJson methods go through the converter recursively (inc. map keys/values/etc.).
Change-Id: If5aec884070128eea594540fd25a9017ada86079
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349060
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds support for serving the contents of virtual files to the client over a custom LSP protocol (based on the VS Code API of the same name). This is currently a custom Dart protocol but hopefully very close to something that could become standard LSP in future.
If the client advertises support for this feature (currently with an experimental flag "supportsDartTextDocumentContentProviderEXP1") we will return the set of URI schemes we can provide content for (currently "dart-macro-file"). Additionally, we will map internal analyzer macro paths (like `/foo/bar.macro.dart`) onto that scheme (`dart-macro-file://foo/bar.dart`) instead of standard `file://` URIs.
Overlays are not created for these kinds of files (because they would override the server-generated content).
Some language functionality "just works" because we can get resolved ASTs for the macro files (and many LSP features operate on these), but more testing (and tests) are required.
Included are tests for the virtual file methods (and events) and Go-to-Definition. Tests for other features are outstanding.
Change-Id: I2056699652873a12b730f565b823f187f883a1ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345420
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a slight refactor that should not change any behaviour extracted to make a future CL smaller. It:
1. replaces the previous `dartFiles` filter that was specifically for the `file://` scheme with a `List` that can be added to in future.
2. wraps calls to pathContext.fromUri() and pathContext.toUri() in all LSP server to go through a new class (`ClientUriConverter`) that will be extended to support mapping between to custom URI schemes (instead of `file:///`) for generated files.
Change-Id: Ie8eadcca3cfd708e4dfde07c22d411101cc9ca0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346540
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
In order for CorrectionProducers to be used in analyzer plugins, we
need to access DartFixContributor which needs to compute fixes via
FixProcessor. So both DartFixContributor and FixProcessor need to be
moved into analyzer_plugin (eventually). For now, to support
prototyping, I am moving FixProcessor to its own library, and
separating all of the built in mappings (from diagnostic to producer
generators).
I think this separation actually stands on its own as being tidier,
simplifying fix_internal.dart, and separating code from data, as it
were.
Work towards https://github.com/dart-lang/sdk/issues/53402
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try
Change-Id: I3b4fadc7ed94c23597d72bef7dcd832380d34e9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345561
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
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 should have been a small change to keep us in-sync with small changes so when there are bigger changes (LSP 3.18.0) the change is less noisy.
However, it turns out the meta model is built from the latest version always, so it includes 3.18.0 proposed features.
So this change not only regenerates the code with the latest spec, it also adds some handling to exclude any types (and methods) marked as proposed.
It also includes a few minor fixes to things like re-wrapping of comments where there are references.
So, it should still essentially be a non-functional change, but the CL isn't as small as planned because of the cleanup.
- The lsp_meta_model.json file is downloaded and not changes I've made
- The protocol_generated.dart file is the output of the code-gen
- All other files are changes I made manually
Change-Id: I6380f86848d2799cf94d58a419ace0bf0d5a35ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This may seem to be a silly change, adding these lists only for the
error fix status file, but I claim this is a very pragmatic solution:
* It is important and beneficial to correctly track error fix
statuses; I was recently confused about these fix statuses because
the text in the fix status file was a lie.
* When fixes are added for more errors, you cannot forget to update
the codesWithFixes list because the fix won't apply (and no test
asserting the fix works would pass).
* Overhauling these FixGenerators to use maps like the others is maybe
a good change in the long run, but at this point might be
over-engineering; we only have fixes for 2-3 codes for each file
type.
Change-Id: Iaa902acf2401f97ff722e222910f5d6fcd00a5ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Danny Tuppeny