Populates the `kind` on the Document Highlights we return. This allows colouring reads and writes differently (which it turns out VS Code does by default).
The options are a bit limited (Read/Write/Text) and using Read/Write for things like type names feels slightly odd, but the spec does seem to encourage this and it's what TypeScript is doing.
Fixes https://github.com/dart-lang/sdk/issues/62929
Change-Id: I6a53450038cde31b399b5b1aca5f964083106763
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503060
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
An attempt to capture some of the conclusions from recent discussions.
Please let me know if this doesn't sound reasonable or if there are
pieces I've missed (such as other exceptions to the general rule).
Change-Id: I2520a768de116be5d9a86f9cb4494dcad7d88f5c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/497780
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I have attempted to make the doc more clear about the differences
between the different kinds of refactors.
I have also attempted to capture some of the conditions under which I
think it's reasonable for refactors to introduce diagnostics.
Let me know if it needs more work.
Change-Id: I2307f9e5eb9d3c0daa0b584dcde65b2c3d652f81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491342
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/61868
This adds a new notification type, 'PluginPrint'. There are several
fields and variables then named 'pluginPrint' or 'print', and I am
definitely open to changing these names, but this is the best one that
I thought of.
PluginPrint has three fields: The name of the plugin that printed, the
message that was printed, and the timestamp.
We wrap each plugin's AnalysisRule invocations with a zone, so that
the `print` handler can know the name of the plugin. The prints are
caught and sent to the server isolate as Notifications. The
PluginIsolate then stores the collected prints. The Plugins Insights
page can then retrieve them and display them.
Manual testing, with 1000 libraries that get new lint reported once per
file, I did not observe a negative performance impact.
Change-Id: Id800ae41781c15ce89d06b563878c2b0edae43d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486827
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The question was raised recently about whether refactors should change
the semantics of the code, and if so under what conditions. There aren't
any hard-and-fast rules, but I wanted to capture the criteria I believe
we've generally used when making this decision.
Let me know if you think I've missed, or misrepresented, something.
Change-Id: I2d02dc35aa17386ff2ae8aa73ff0dc1271170ba4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487220
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
We previously just showed "<unnamed extension>" for extensions without names, but in some files I noticed we have a lot of these, and the outline/symbols list looks awful (just "<unnamed extension>" repeated many times).
This changes it to instead show "extension on FooClass" instead (if there is a valid type name). I added a new field to the protocol to support this because the LSP classes convert from those classes (something we've discussed changing, but might be easier later).
Screenshots of before/after are in https://github.com/Dart-Code/Dart-Code/issues/5818
Fixes https://github.com/Dart-Code/Dart-Code/issues/5818
Change-Id: I3885a722443291bfa2419514841469c862b74450
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464560
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There are a couple of questions about the design of the analysis
server's features that have come up over the years. I think we want to
capture our decisions and the reasons for them so that we can refer
back to a doc rather than retyping the whole description over and over.
This is an attempt to capture a couple of those topics as a first step.
I'm not completely happy with the structure of the doc. I had originally
thought that I'd have a 'principles' directory to discuss the design
principles we follow, and a 'features' directory to discuss how those
principles are applied to the design of each feature. This initial doc
has both in one file because it wasn't clear how best to split it up.
It's hard to talk about principles in the absence of concrete examples.
I'll probably re-organize the text later, and am hoping you have some
ideas.
By writing this down I'm not trying to stop the discussion of how the
features should be designed. I'm just trying to capture the current
state of the design. Design is, and should be, fluid, and I'm happy to
update these docs as our design changes. So, please review this more
from a perspective of whether the current state is correctly represented
and less from a perspective of whether the current state is what it
ought to be.
Change-Id: I8e3e1de2ca01f3e18fdacc89317ddb0e5a98484e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/460904
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This renames the old screen, "Legacy plugins" and adds a new screen,
"Plugins". On the new plugins screen, we ask the plugins isolate(s) for
their plugins details, and print the following, for eadh plugin:
* the plugin's name
* the names of the registered lint rules
* the names of the registered warning rules
* the IDs and "messages" of the registered assists
* the IDs and "messages" and associated diagnostic codes of the
registered quick fixes
More to come in follow ups:
* The resolved versions of plugin packages (coming from package_config.json)
Change-Id: Ic3dc4c5bffa64fd4da4097c042a847cc064e41ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447763
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is awkward as there are some packages which are co-developed like
analyzer_testing and analyzer_utilities. But broadly speaking, this
style guide is used for the "analysis-related" packages that the Dash
Developer Experience team maintains. So we can move it to live with the
other docs in pkg/analysis_server.
Change-Id: Ic94cfe1d16288ec707c96a42c7a18788e9f8b7d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435220
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The bullets on this doc were bugging me because they were confusing which tasks were subtasks of one another. I made them all into checklist bullets (since that's what's most useful for me anyways) and it looks much better.
Change-Id: I593ceb7db5ae39ffda52a2a2e481b1c53a5a7784
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This adds an optional version number to AddContentOverlay and UpdateContentOverlay in the legacy protocol.
It also moves some code (such as the `Map` that stores the current document versions) from the LSP server into the base class, and updates the overlay handlers to update it.
And finally, it removes the FailingTest() annotations on the versioned EditArguments test since they now work.
Change-Id: Icf2a2825eb6227f5faa3e21ae6c3a7d15997ef5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404821
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds a new field to the existing (legacy) setClientCapabilities parameters that accepts an LSP ClientCapabilities.
This will allow a legacy client to indicate that it supports things like the `workspace/applyEdit` reverse-request.
Change-Id: Ia3b75c701f1699c92f902e058daec4844ce664fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404106
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
This changes Go-to-Super to handle augmentations (jumping to a super-member will go the last augmentation in the chain) and constructors (will jump to the actual super constructor that is called, regardless of name).
Change-Id: I7439fd42ef81983e7a052f250f7ba272fe8c2c86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357608
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, we only had descriptions of changes on a SourceChange. In order to support annotated edits over LSP for "Fix All in Workspace" we need to be able to track descriptions on each change within a file so that if we're fixing multiple different lints with a single SourceFileEdit they can be annotated/grouped in the UI.
In order to avoid every fix providing a description, ChangeBuilder has a field that allows recording the current change description and all builders created from it will use that description when creating their changes. This allows the BulkFixProcessor to set the description on behalf of each fix producer ensuring they all get descriptions (which is done in a follow-up CL along with Fix All in Workspace functionality).
Change-Id: Ie1c508056898bd4000a5505cf59a1e6d35d28da0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356160
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds support for the legacy server to switch to URIs using a client capability. In this mode, all "FilePaths" will be URI strings over the protocol (in both directions).
It also allows the server to send LSP notifications (wrapped inside an "lsp.notification" notification, matching how requests/responses work). Notifications are automatically enabled if the client uses any LSP methods or sends the new "supportsUris" capability.
Change-Id: I5d2b76e396862129c61de70d57397603c958a02d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349120
Reviewed-by: Jaime Wren <jwren@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This does not remove the computation of available declarations. This CL
seemed big enough without that, so I (or someone else) can get that in
the next CL.
Change-Id: I67ab49b75c8a415ccfaef16c4e49a00026a6091f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341160
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Originally we didn't use the LSP Request/Response classes, and just exposed the handlers through the legacy request/response.
However there were some mismatches (such as legacy protocol always returns Map<String, Object?> but some LSP requests return Lists, LSP using int|String IDs, and LSP having numeric error codes that don't match legacy string error codes).
This change uses LSP's request and Response by wrapping them inside a standard (legacy) handler. The LSP-over-Legacy handler has become a standard handler, and the params contain an "lspMessage" field that holds an LSP message, and the result contains an "lspResponse" field that contains an LSP response.
If an LSP handler returns an error, it will be returned as an error inside the LSP response, which will be in a _successful_ legacy request (since that's how we can return an LSP response - as the result).
Change-Id: I67973590ab32f3543d1a6e1b7279974e5e8832bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315201
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Let me know if any of this is unclear or if there's missing information.
Of course, you might not know that until you start trying to enhance the
support, but we can also refine the doc when issues are discovered. I'm
mostly just interested in helping you get started.
Change-Id: Ib48a8ce46af7b6cc37a27508c81df03bfd2093e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295040
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson