This updates the interactive forms classes to reflect recent changes.
Previously, we would only send back the outstanding fields to the client, and it would only provide answers for the same.
Now, the server will always send all fields to the client, and the client will always provide all answers. Answers are looked up IDs (a new field on `FormField`, and `FormAnswer` which wraps the answer) rather than rely on indexes.
Fields can also now be required.
Change-Id: If4aa1f9a18fa873e83cb0ea1fd74c2e42cd2fa1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508103
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This adds some classes for processing interactive forms (I'm splitting this from the CL that updates refactorings to simplify reviewing).
The `InteractiveForm` class managers a whole form (all fields), and processes a set of fields/answers that come back from the client (which may be the full set, or a subset). It produces a list of the outstanding fields (which need to be go back to the client) as well as maintaining the full set of answers for the master field list (to use as arguments for a command, for example).
I've also commented out enums/lists from the protocol code for now, because I made the field kinds `sealed` so we get exhaustiveness checking in the validation, but want to delay fully implementing those for now.
See https://github.com/dart-lang/sdk/issues/63371
Change-Id: Icc4dcea8c9eab20ffbdd19ebbc69e1285464f7ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505683
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
In the new interactive forms, some of the enums can be combined (eg. `FileExistence.New | FileExisting.Existing`). This adds a flag that produces some helper functions for `hasFlag()` and `combine()`.
These helpers are not used outside of tests in this CL but will be used in a future CL (which I'm trying to avoid getting too big to simplify reviewing).
Change-Id: I1b5f06f05d96781c4bc6a246a0a9309a786c1987
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505320
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
This some basic scaffolding for the migrate tool. We'll add a protocol to the analysis server with the following parameters and result:
Parameters
- `uris`: Workspaces/packages to be migrated
Result
- `summary`: Information about fixes that could not be applied automatically. (e.g. if there was a conflict) or information about what fixes were applied and what SDK version the pubspec has been changed to.
- `edit`: A list of edits to be applied.
There are no interesting tests yet, but I hope to have a suite of tests for the next change.
Fixes: https://github.com/dart-lang/sdk/issues/63247
Change-Id: I77508720acb17af5ec86675fd3f3045e2a610bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The Flutter Widget Preview feature is currently implemented within
Flutter Tools, which is responsible for detecting widget preview
annotations in the user's project. When previews are detected, the
Flutter Tool injects code generated based on the detected previews into an artificial widget_preview_scaffold project and performs a hot reload to render updates to the preview set in the scaffold application.
`package:analyzer` is currently being used to detect previews, but this comes with a significant amount of memory overhead. Since widget
previews are mostly being used from within IDEs which already have an
active analysis server, moving widget preview detection into the DAS
will remove the need for creating an additional analysis context in the Flutter Tool itself.
This change includes the initial work to move widget preview detection
into the DAS. It utilizes a pull-based mechanism, where the Flutter Tool listens for file system events and then queries the DAS using the `dart/textDocument/getFlutterWidgetPreviews` and `dart/workspace/getFlutterWidgetPreviews` LSP methods.
Each reported preview contains some generated code based on the annotation used to define the preview. This code has all constants from the original annotation evaluated to either primitive values or constant expressions with namespaces applied to each symbol, allowing for the Flutter Tool to inject this code directly when updating the generated code in the scaffold project.
Towards https://github.com/flutter/flutter/issues/179584
Change-Id: I043cb3235a66b25dda3f852ca7f147bff0e1e537
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478100
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
My previous CL made some LSP tests run with String IDs instead of ints, but those tests don't appear to go through the session logger so did not fail with the casts here.
This change adds a base integration test that also uses string IDs, which did fail on the cast, so I've updated the session logger to use `Either2<int, String>` for IDs instead.
Fixes https://github.com/dart-lang/sdk/issues/62442
Change-Id: Iee582e9ce2b8b5a1127120c987670a679d2ca76c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/473260
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, the result of calling `toJson()` could still include some classes (like `List` and `EitherX<>` unions). This didn't cause issues because `jsonEncode()` would handle those types anyway (calling `toJson()` recursively), however changes to support the log replay are looking inside the returned Map and should see consistent types.
Change-Id: Ie52a7251ee10579de8ce605584feb82abc15eb8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/472900
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This removes all code related to handling requests for (and sending notifications of modifications of) the virtual files for macros.
Clients would never call this handler unless the analysis server had previously told them about these virtual files with the `dart-macro+file` scheme, which never happens because the implementation was previously removed.
This does not remove the `clientUriConverter` (which as well as handling conversions to/from the macro scheme, also handles conversions between URIs and Paths to support using URIs in the legacy protocol) because I'm not yet certain that is unused.
Change-Id: I148e2383a48b5f6e3a28eff3dd11506fc86353b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461120
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The exact format of the summary is yet to be decided, but at the moment
it's producing an abbreviated form of Dart that doesn't include function
bodies or documentation comments.
No attempt is made to remove in-line comments, but we might want to
consider doing that.
Change-Id: Iec6e27c54e3099a596d50d5c461356006694690b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/440682
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@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>
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 is a reland of commit b9b77058a9
Original change's description:
> Migrate to use pub workspace
>
> Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
>
> All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
>
> All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
>
> Bug: https://github.com/dart-lang/sdk/issues/56220
> Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
> Tested: relies on CQ of existing tests. Should have no effect on functionality
> CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I29afabade2d2447dea05121cb87ff50bb21a4b76
Cq-Include-Trybots: luci.dart.try:flutter-linux-try,flutter-web-try
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `//
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415561
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit b9b77058a9.
Revert "Add missing sample pubspec to workspace"
This reverts commit 892ea15ac7.
These seem to break the engine.
Change-Id: Ieee26deb7928c3869a1b6265326c3ce568ffe731
Tested: this is a revert.
CoreLibraryReviewExempt: this is a revert
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415582
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The code that was previously owned by the analyzer team
(OWNERS_ANALYZER) is now owned by either the Dart Model team
(OWNERS_MODEL) or the developer experience team
(OWNERS_DEVELOPER_EXPERIENCE). Accordingly, we don't need
OWNERS_ANALYZER anymore.
Change-Id: I9a4d2e2462a15ba9ec8f3046cdca77ba9d3af13c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410564
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moving forward, the Developer Experience team will own the following
packages:
- analysis_server
- analysis_server_client
- analysis_server_plugin
- analyzer_plugin
- language_server_protocol
- linter
- meta
- server_plugin
- telemetry
In follow-up CLs I will create an OWNERS file for the Dart Model team,
and then remove the OWNERS files for the old analyzer and CFE teams.
Change-Id: Icc52ca75e92baf9d05de211e9e3f6c36fb19b71e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Kevin Moore <kevmoo@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>
We run the formatter as part of generating these files. This just regenerates them (to get the new formatting) with no changes so that future changes to the generated files don't produce a huge unrelated diff.
Change-Id: I27e73c800c6f0a918adf29d6106e7c2985dd6241
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393862
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@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>
ErrorOr is not related to (or used by) the spec or generated spec classes. It's a utility class for the server implementations of LSP handlers.
I'd like to extend this class and add some extensions (that require access to private fields) and don't feel it belongs in `package:language_server_protocol`.
(note: `package:language_server_protocol` is not published so I believe removing it from there is not a breaking change)
Change-Id: I06799b18d61d123364711a549231134c792e70e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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 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>
Danny Tuppeny