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>
If we get an editArgument request (usually via DDS), we should verify the connected editor supports edits and return an explicit message if not.
Also adds a `setUp()` declaration to `SharedTestInterface` so shared tests can set client capabilities instead of them being duplicated in each test class (and moves the same for ApplyEdit tests to this).
Change-Id: Ie6a85620b3b53663ce92e55d93e3aefcaf4dc980
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405342
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is some minor refactoring to support the next CL that will enable the EditArgument request (the one that actually edits arguments, not the one that gets the list of arguments) over legacy.
It moves some code for sending LSP reverse-requests through the legacy server from test code into the actual server (and fixes that they weren't correctly wrapped in the 'lsp.handle' protocol classes) and updates the tests to use the shared interface ready.
Change-Id: I06492138645538072fb12f2fc2d424e214f8055b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404824
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The legacy protocol does not currently version documents, so this adds some additional tests for that.
The tests are in the Legacy class and not the shared class because in LSP versions are not optional for opening/changing documents (they are optional in some of the other APIs, but not for open/change).
Change-Id: I7e75b813025b3f67ed143e1b3a8b717224bfa80f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404820
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This moves all tests (without any changes) to a shared mixin, and then applies that mixin to the original test class. It also adds a new test class for LSP-over-Legacy, meaning the tests will now run for both protocols.
There are two failing tests when using LSP-over-Legacy so they are overridden with `@FailingTest()` temporarily.
Change-Id: I8c7efcf8f5d85d874b3483f4f3953d4d8b68a31a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404621
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This is refactor extracted from an upcoming change (to make property editor tests run against both servers) to make that change smaller and easier to review.
There are some existing shared tests that run for both LSP and Legacy servers, but they currently do not touch much server API (one is for DTD and one tests reverse-requests). Migrating other tests (such as EditableArguments) requires some additional API be the same between the different test/server base classes.
This change adds an `abstract interface class SharedTestInterface` to serve as a common interface for methods that shared tests need to use that have different implementations between LSP and Legacy. For example, updating the overlays in an LSP-over-Legacy test needs to use the Legacy APIs for updating the overlay and not the LSP ones (so we can't just use the LSP methods like we would for calling something like getHover for LSP-over-Legacy).
It also:
- adds some new futures to the LSP test base to match the behaviour of the legacy one (wait for in-progress analysis)
- replaces the shared mixins with real base classes that implement the shared interface (for ex. `abstract class SharedLspOverLegacyTest extends LspOverLegacyTest implements SharedTestInterface`) to make it easier to create shared tests
- renames `sendLspRequest` to `sendLspRequestToClient` to make it clearer what direction this method is for
Change-Id: I070c2c005b11b9afd8a87aa22b04972a9dde2320
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404680
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
This adds shared tests for sending workspace/applyEdit reverse-requests that run for both the LSP and Legacy servers.
It involved moving some code out of the base LSP test onto mixins to be used by LSP-over-Legacy tests and I extracted some mixins that can be used in tests to provide a common interface to both servers for writing shared tests.
Change-Id: I8c6d09f220b2593680547311a4fce66013f86e2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The DTD client requires that the `type` field is populated in DTD responses, but this code previously would omit it when the result was `null` (because it used `result?.runtimeType`).
Change-Id: I5a6e0927e9c02f2abb690aefceca8f8b003cd43b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/394484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Before exposing existing LSP methods we need to provide a way for DTD clients to always get the same format responses regardless of the client capabilities provided by the original server. Until then, add an allow-list for LSP methods that we can use to selectively enable specific methods that are not affected by client capabilities.
Change-Id: Ia1c994a50c9b94a91f4085c09f9d9d94c0fad79e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382401
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@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>
Danny Tuppeny