The term "CodeAction" is a bit overloaded. It could mean both an
individual result from the `textDocument/codeAction` request (which is a
`Command` or a `CodeAction`), or the `CodeAction` type defined in
the spec (which the spec refers to as a "Code Action literal").
To reduce confusion where we have similar APIs that operate on
"Code Actions" (CodeAction|Command), this renames the `CodeAction` class to
`CodeActionLiteral` and we will use the term `CodeAction` to mean either of
those types.
To make things simpler to review, this change _only_ renames the class, and also swaps the order of the types in some places that used `Either2<Command, CodeAction>` (which is opposite to the spec and some other code). Some further clean up will be done in a separate change.
Change-Id: Idcd8265f9229c3450004e68334e98a7b530330a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425300
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This lint rule is a core lint rule; we have suppressed it only for
pre-existing code reasons.
There are a few individual files which simply have a consistent pattern
of including underscores in some names, so I add inline ignores there.
Change-Id: I89e6010203868fc10fda12b15353de41881d9b15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Now that we have `defaultValue` against each argument, there was some redundancy here.
`isDefault` is redundant because if `hasArgument=false` it's always default, and if `hasArgument=true`, then `value` and `defaultValue` can be compared
When `hasArgument=false`, there's no value in duplicating `defaultValue` into `value`
Change-Id: I5cba055e56175565842efef815e08dd46e9ed36a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406621
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Parse errors for spec types were being reported twice - once by the containing object (in canParse()), and once by the nested canParse() call for the nested type.
This skips reporting the error for nested calls to a canParse() method, which will always report the error itself.
Change-Id: I03e4a9638fd6a3fc77eac918f6fd16def93327d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404105
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This moves completion resolution off `ElementLocation` onto the class recently created as `TypeHierarchyItemLocation`, which is now renamed to `ElementLocation2` and extracted to its own file.
Change-Id: I1f0b831ded7b08d6c09f97fcfd66f38f1dd4750e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This code generation was previously formatting generated files using the latest version. In 76feb10829 I re-ran the formatter to get the new formatting style.
However recently, a pre-submit hook to verify formatting was enabled and revealed that pkg:language_server_protocol still has an older SDK constraint, so the presubmit fails (if you modify these files).
There are two options:
1. Restore formatting to the previous version for pkg:language_server_protocol
2. Increase the SDK constraint for pkg:language_server_protocol
I picked the first for now, since analyzer_server_plugin also depends on pkg:language_server_protocol and currently has a constraint of 3.3, and I don't want to mess with that just to fix the format presubmit.
Change-Id: I2347577561e659825b444ef6622d646c6e513aea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401001
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This adds basic editing for the argument types supported by `textDocument/editableArguments`. It doesn't currently attempt to format code currently (or use multiline/raw strings where they might be more appropriate), and does not allow arbitrary values that don't match the type for the parameter.
Change-Id: Ied95d95c0de39310aef0a1153864e902d56e1910
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Some minor fixes/tweaks extracted from another CL
1. Fix tool/lsp_spec/codegen_dart to set `options` on `CodeStyleOptions` (a late field that needs to be set to the owning options file)
2. Fix a wrapped TODO to be indented so it's detected correctly
3. Move the custom `DartTextDocumentContentProviderHandler` handler into the `custom` folder
4. Merge `LspHandlerHelperMixin ` into `HandlerHelperMixin` since the APIs it uses are no longer LSP-specific and exist on the base server
Change-Id: Ie1b3a8057575346cf9bfb98465c0a3e330c28a82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392909
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Phil Quitslund <pquitslund@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>
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>
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>
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>
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>
No functional changes here but there have been some refactors inside the meta model that required some minor tweaks (URI moved from a type alias to string to a spec-defined base type).
I also improved the handling of some type references in the comments we bring in so they're clickable in more places.
Change-Id: I7c725d01b6d7bc0925979b8118dbfd8952f78724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297482
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny