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>
For troubleshooting, this allows the client to override this flag.
I'd originally planned to use ClientConfiguration for this and allow it to be changed on-the-fly, however this can result in a mix of requests and therefore I decided it best to only support setting once during startup (which is part of initialization, and therefore before general requests start being sent).
This will require some Dart-Code work to provide a value here (and without a value, it will always be the servers default).
See https://github.com/dart-lang/sdk/issues/60440
Change-Id: Ie9843543d6d491afb046f3d1106211b7db852605
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/419541
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This adds support for LSP's "Inline Values" for variables and properties, allowing their values to be seen floating in the editor while stepping with a debugger without having to hover.
Including property access/getters may be useful too, but that can be added in a future CL (and perhaps initially behind a flag to get feedback, in case it turns out to bee too noisy).
Fixes https://github.com/dart-lang/sdk/issues/59891
Change-Id: I6305cfa9a7583c30500b90ee3b29852c82cc2494
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/412080
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In the upcoming LSP 3.18 spec, many types that were previously inline literal types with no names (that resulted in us auto-generating names) have been made real types with names.
In order to reduce the size of the change when LSP 3.18 arrives, this change renames some of our existing types to match the new names that they will get with LSP 3.18.
There are no functional changes here, I simple added the names to the rename list (removing any redundant values that were previously being renamed differently), regenerated the code, and then updated any remaining references (in non-generated code) to those types to match.
Change-Id: Ic556ce6e52ba94a8d42099371be18288230cd5ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389160
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Previously if you sent values in experimental capabilities that are different types to what we'd expect, in some cases we'd throw an exception and fail to initialize the server.
Since the experimental section is not specified (it's specifically for off-spec things) the behaviour of sending values should (IMO) be considered server-specific. However, reporting a useful message and continuing to function is clearly better than reporting a cryptic error and failing to initialize.
At least one client (`kak-lsp`) appears to be sending values in `"commands"` intended for the Rust LSP server which uses a different format to we're using (a nested Map where we use a List). This change will prevent the failure for them and instead report a warning. My recommendation is that their client is also updated to not send Rust experimental capabilities to non-Rust servers.
Fixes https://github.com/dart-lang/sdk/issues/55935
Change-Id: I8cba1aa3a5beebf884ff247180f809ffd33b3111
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371400
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Sam Rawlins <srawlins@google.com>
Commit-Queue: 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>
If you open VS Code and have some Dart files open, it may send requests to the analysis server before we have (asynchronously) set up the analysis roots. This often results in "File not analyzed" errors in the console, but until now I had believed these errors to not cause any visible issues.
However, https://github.com/Dart-Code/Dart-Code/issues/5030 had a good repro for where this is visible - the Outline view would never populate for these open files.
We had some existing code to wait for in-progress context rebuilds to complete when fetching a resolved unit in a request handler, but requests could still get in before that started.
This change also waits for the client to send Initialized, which is when we start the analysis root build, so this bridges that gap and ensures the initial analysis roots are set before any handlers get to run.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5030
Change-Id: I4b2d936f533f0696e3e363972faa82a2304276c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356722
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a non-functional refactor that extracts the growing set of capabilities and options from ServerCapabilitiesComputer into files alongside the handlers they relate to.
The motivation for this is that for LSP-over-Legacy we'll need to accept client capabilities (and return server capabilities). The server capabilities will be different to the standard LSP ones (they will be a subset, and we might not support dynamic registration - at least initially). However the features we do support will have the same registration options, so to avoid duplicating them this moves the registration options away from the creation of the ServerCapabilities.
In future, we might consider further wrapping up a "feature" (which consists of these registration options, and the related handlers), but this change is already quite large and I just wanted to progress capabilities for LSP-over-Legacy so we can handle things like Code Actions (which require executeCommand and possible reverse-requests for applyEdit).
Change-Id: Iecd0aa36626fa44826f7d4dbd6e6c0d758075239
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319840
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This simplifies an upcoming change switching from parsing LSP TypeScript definitions to using a new JSON definition (where items are not all in the same order).
Change-Id: I773ce9ab174288ef5226b5f82f8ad7b8fb5f3693
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244245
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In an upcoming change some types will between these files. To reduce the size of that (already very large) CL and because the distinction between spec-generated/custom-generated types was unnecessary anyway, this adds a single import for LSP protocol-related types.
Change-Id: I322447d6c979538c12014d87875176e1bf2adca7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244244
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson