This slightly improves the performance of applying edits in LSP tests. The previous code would sort the edits in reverse and then sequentially replace each edit into a string. With a large number of edits, both the string replacement and the subsequent rebuilding of LineInfo after each change could be quite slow.
With this change, we instead work through the edits forwards, appending the original text + new text into a StringBuffer to be combined once at the end.
Since most tests don't make large numbers of edits this only shaved a few seconds off the whole server test run, however when running a small benchmark of 20000 edits that Brian sent me recently, the time taken comes down from 42s (which hit the default test timeout) to 17s (which is not fast, but is faster).
Change-Id: Ia91937f4912b35ee1fe29f31157db3ef0e4bd79e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No current tests hit this, but if you call verifyCodeActionLiteralEdits without a "title", you could trigger a failed expectation here that you should not - the mismatched actions should just be filtered out.
Change-Id: I6962c9f99a7a3051afcf3f76ad90945cd1381e0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There are a few things in this CL that were difficult to separate testing of (because they're all part of the same feature):
1. sets `requiresTrustedCaller=false` on the `executeCommand` handler so that commands can be called over DTD. It adds the same flag to the command handlers themselves, so a command can control whether it can be called over DTD or not (right now we allow everything except `logAction` and `sendWorkspaceEdit` which are both commands used internally and not appropriate for DTD clients to call).
2. Removes the allow-list on DTD methods, allowing all LSP shared methods to be available over DTD
3. Extends the integration test classes to support reverse-requests so we can verify the edits being sent back to the editor when calling the code actions commands over DTD
4. It also fixes a few bugs where we read the callers capabilities instead of the editors capabilities (which until now would always be the same in those places, but with this change are not).
Change-Id: I6d271ddad6dc1b00a98b10b735763a368c91af7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428784
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
A minor refactor towards supporting CodeActions over DTD.
The (existing) `LspRequestHelpersMixin` is a collection of helper methods like `getHover()` that allow sharing strongly-typed access to LSP methods across different kinds of tests (LSP, LSP-over-Legacy, and in-process vs out-of-process).
This adds a class (`DtdHelper`) that allows those same helpers to be used to call LSP over DTD (it has to be a separate instance because these helpers already exist on the base test classes to communicate with the server directly without DTD).
As part of this, the mixin was split up to separate request, reverse-requests and notifications, since only outbound requests apply over DTD and it cannot provide an implementation for the others.
This change also adds `textDocument/hover` to the allow-list so that some of these tests can be unskipped (since in an upcoming change the allow-list will be removed entirely anyway).
Change-Id: Id7bf40020cb5397e4cb8bbdefeed71745f58c4cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428520
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is some more final (🙃) cleanup before having CodeActions work for LSP-over-Legacy and run all the same tests. Includes:
- Adding some additional signatures to the SharedTestInterface
- Moving some setup code (that uses those methods) into the shared test mixins
- Add a field for `testPackageName` to allow tests to handle differences between the test package name between LSP/Legacy (something that should probably consolidated but is probably not for this CL)
- Move plugin tests back out of the shared code action tests (these require some additional abstraction to work the same across both kinds of tests - TODO added)
Change-Id: Iad25f1ff1e141d3315e9b972a6d0850e71d4a4bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427443
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The next CL will make CodeActions a shared handler (so it can run for both LSP and legacy servers). This moves the tests to a shared mixin (without any changes) to keep that change smaller and easier to review if the tests do end up requiring changes.
Not all tests are moved yet - plugins are not (because the plugin code is not the same across server types), not "Fix All" (because it will require some additional changes to not be LSP-specific compared to others).
Change-Id: Ib4727ef1b1cc5b96d98cdbd6e17bf4b7b2791e3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428003
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, this is just a small refactor extracting from a future CL that makes the LSP CodeActions tests (and the supporting mixin) work against the `SharedTestInterface` so that they can be shared between the LSP server and Legacy server tests.
It also removes a redundant implementation of `verifyEdit` so both LSP+Legacy tests can use the same implementation, which required fixing the LspOverLegacy base test class to correctly set the local capabilities to match the default set the legacy server uses if the client doesn't provide any explicitly.
Change-Id: Ie6396a6425205aba9bfdcc3f08f34fdfa215ad92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428002
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This updates the `ApplyCodeActionCommandHandler` to be a "shared" command that can work for either kind of server (although it does not yet allow calling over DTD - the executeCommand handler still requires trusted callers).
It also moves all of the tests into a shared mixin so they will be run for both server kinds.
Change-Id: I831cc5a1a9feadc528e5b33b82e3469c60111dfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This changes two classes that were previously used as base classes for tests to mixins, which allows both of them to be applied to the same class (which is required for some upcoming shared Code Action tests, since one of the base classes provides the shared interface and the other provides CodeActions helpers).
As part of this, I also inlined the setUp() method from the original base class and reduced it to just what's required for each testing, including removing `failTestOnErrorDiagnostic = false` from some tests, and fixing up some unintended errors in them.
Change-Id: I92012d9fdd4df9f13912859c92c277154f297e8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427380
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This changes assist CodeActions to return Commands if the client does not support codeActionLiterals (code actions with inline edits). The implementation of "applyCodeAction" will just recompute the code action from the textDocument/range/codeActionKind and then send it to the editor via workspace/applyEdit.
On it's own, this only means that LSP clients that do not support codeActionLiterals will now get assists, but a future change will make the textDocument/codeAction request available over DTD allowing them to be invoked by clients other than the editor itself.
This is currently only assists and not fixes/refactors.
Change-Id: I8204a51303b048e3928d5cbadf5aca76e81c82f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427224
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, just some additional refactors extracted from an upcoming CL to make it easier to review. This updates the `CodeActionProducer`s (and related code in `CodeActionComputer`) so their signatures use `CodeAction` instead of `CodeActionLiteral`, which means this code will be able to support `Command` code actions in future.
Mostly it's trivial changes, but the code that de-dupes and merges actions needed a little more updating to handle the different kinds.
Change-Id: Ic2255b2d9864b6974a542d1d3ee3b099c4d5ea32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427222
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This removes a filter of CodeActionKinds from the final step (and a class named `_CodeActionSorter`!) and instead applies it earlier during building of the actions. This will help apply the filter in the case where we return bare Commands (which don't have `kind`s) instead of `CodeActionLiteral`s.
I added some TODOs because I still don't think this is filtering early enough (because in the case of invoking an action via the command, we need to not have to produce _all_ code actions just to locate the _one_ we want to execute), but it's a step closer (and easier to review this without it being lumped in with the CL that supports returning Commands).
Change-Id: Ibc73c4900d939ac833f6345e9e8f1fdf3f5d6823
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, just some refactoring of some test helpers to work on CodeActions (which are either CodeActionLiterals or Commands) instead of only CodeActionLiterals, to simplify reviewing a future CL with functional changes.
Change-Id: I40455cbaae7b924444a2f50fcdc3600d6953ecb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426940
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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>
As a pre-cursor to supporting `executeCommand()` over DTD, this converts the handler from an LspHandler to a SharedHandler so it can work with either a base LSP or Legacy server. Not all commands themselves work in both modes, but the executeCommand() handler itself and some basic commands (like `logAction`, which I used for testing) do.
Change-Id: I90de88a1870649fb121cc9fa45732b4d03a45504
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425263
Commit-Queue: Elliott Brooks <elliottbrooks@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
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>
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>
When the property experiment is enabled, we may evaluate getters in inline values. For some types, the chance of these having side effects are much higher (for example accessing `length`, `last`, `first` on `Iterable`s or `Stream`s.
This suppresses inline values on these types (both the variables themselves to avoid any `toString()`s, and any getters).
Fixes https://github.com/dart-lang/sdk/issues/60402
Change-Id: Ie9b524a679df5e39856ecd900d94f2fb41b779bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420703
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: 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>
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>
For convenience, we usually include Inline Values for the "current" line so that when stopped at an `if` statement, you can see their values:
```
if (foo == 1) { // [foo = 2]
```
We have an experiment that includes inline values for getters (since although they can have side-effects, users tend to expect to see them in debug views, especially when the getter/setter are implicit), but triggering them before the code ever would have may be more unexpected.
This change uses two different ranges so that only variables are included for the current line.
Change-Id: I19a129a28f7b5296281dbee139855c738cd37194
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418340
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Recently a bug was fixed in the formatter, regarding how declarations
preceded by an end-of-line comment are formatted. Good to just bundle
the formatting changes into one CL.
Change-Id: Ieab8ec3263932505f8b8da77fbe637dffc61b46d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is required so that an analyzer plugin can process producer generators that are registered in a plugin isolate.
* Change `AssistProcessor._generators` and
`AssistProcessor._multiGenerators` into private top-level variables
which are only used as "built-in" assist processor generators. They
must be explicitly registered, which we see much of in this change.
* Rename all of the lists of _generators_ and maps with lists of
_generators_, which were named "producers". The new names are
"generators." This leads to giant diffs because of alphabetizing.
Change-Id: Id4432737daaec1bb282f0b387619b23c18c0ea55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Danny Tuppeny