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>
The code used to generate:
```
bool operator ==(Object other) {
if (Other is X) {
return a && b && c;
}
return false;
}
```
which is just simplified to the one expression:
```
bool operator ==(Object other) =>
other is X && a && b && c;
```
Change-Id: I0d1a80b57598bd8e840c0cd99304ace64f4cd786
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462740
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
One can see that we have bare HTML in these signature-in-comments,
like:
"contextMessages": optional List<DiagnosticMessage>
These are flagged by the unintended_html_in_doc_comment lint rule.
This CL solves this by indenting these signatures 4 spaces, making
them Markdown indented code blocks. Alternatively we could use
backticks. Backticks would make the comments taller; indenting makes
them wider. I would prioritize whichever style is less intrusive when
reading them in plain text, which I think would be to use
indentation.
Change-Id: I019d9073e994a505325194ceeac3c6e0635d947e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453642
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
When hitting a protocol error, I saw some errors that were confusing
for a moment because of the lack of quotes, for example:
> Invalid parameter 'params'. Expected to be files; found \"...
This CL doesn't actually improve the situation _much_, but it at least
puts quotes around `files`, to indicate it is a property or something
similar.
Change-Id: Ic12d063b427661025cd4418951c58abf3394df3f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449220
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Most calls to `jsonDecoder.mismatch` include the 3rd argument. I add
more here, so that the error can say, "I expected this field in some
JSON, but instead the JSON looks like this: ..."
Change-Id: I7d1944624e1fe758d9732d71db6571a579dc4690
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adding edits (e.g. via `dart fix --apply` are often done with
`List.insert(0, whatnot)` which takes O(n) time.
Here QueueList that can insert fast at both ends is used instead
(and we use `addFirst` instead of `insert(0)`.
On the example from
https://github.com/feinstein/google-i18n-address-dart.git we go from:
```
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m55.810s
user 4m1.209s
sys 0m3.714s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m33.966s
user 3m37.588s
sys 0m2.058s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m36.525s
user 3m40.083s
sys 0m1.907s
```
to:
```
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.970s
user 0m12.676s
sys 0m2.100s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.862s
user 0m12.926s
sys 0m1.797s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.612s
user 0m12.712s
sys 0m1.834s
```
Statistics on the `real` runtime:
```
N Min Max Median Avg Stddev
x 3 213.966 235.81 216.525 222.10033 11.941664
+ 3 9.612 9.97 9.862 9.8146667 0.18363369
Difference at 95.0% confidence
-212.286 +/- 19.1415
-95.581% +/- 8.61838%
(Student's t, pooled s = 8.44503)
```
For `lsp_many_prefer_single_quotes_violations_benchmark.dart --sizes=3200`:
Before from something like:
```
Initial analysis: 0.115654
First code action call: 0.835152
Subsequent action call 1: 0.538592
Subsequent action call 2: 0.561636
Select all code action call: 1.564402
```
After to something like:
```
Initial analysis: 0.086985
First code action call: 0.411660
Subsequent action call 1: 0.171566
Subsequent action call 2: 0.193708
Select all code action call: 1.107339
```
Statistics on 5 runs gives:
First code action call:
```
Difference at 95.0% confidence
-0.44381 +/- 0.0261597
-52.4602% +/- 3.09218%
(Student's t, pooled s = 0.0179367)
```
Subsequent action call 1:
```
Difference at 95.0% confidence
-0.381012 +/- 0.0195618
-69.9139% +/- 3.5895%
(Student's t, pooled s = 0.0134128)
```
Subsequent action call 2:
```
Difference at 95.0% confidence
-0.360077 +/- 0.0265277
-64.634% +/- 4.76173%
(Student's t, pooled s = 0.0181891)
```
Select all code action call:
```
Difference at 95.0% confidence
-0.405855 +/- 0.027662
-26.7277% +/- 1.82169%
(Student's t, pooled s = 0.0189668)
```
Change-Id: I3868afaa8c32a24c01c3a52bd8a53d5e8e4e3afe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427401
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
I wrote a test that generates 10,000 lines of code, each containing one
violation of `prefer_single_quotes`, computes the fixes for all of the
diagnostics, and applies the 20,000 edits, measuring how long the
application takes.
Before this change the average was 3355.0 ms.
After this change the average is 3.8 ms.
The change was inspired by Jens.
Change-Id: Icd54a81ca3848fd5f0168934f713a7be8caec359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425601
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: 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>
We take any `<tt>`-wrapped text, and keep it in some "monospaced" /
"teletype" format. For dartdoc we put it in backticks. For Javadoc
we put it in `<code></code>`, which looks standard for inline text.
This corrects some erroneous doc comment reference-looking text
(`offsets[i]`) which is not meant to be a doc comment.
Change-Id: I1d77a02368e3cde158ce95d3b0095ba09e071370
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
I'm still chasing down a couple of google3 failures, but this is ready for review so that I can get it approved and land it once the last couple of failures are fixed. Here is who I think should review what:
athom@ for:
- DEPS
johnniwinther@ for:
- pkg/_fe_analyzer_shared
- pkg/front_end
- pkg/kernel
brianwilkerson@ for:
- pkg/analysis_server
- pkg/analyzer_plugin
- pkg/analyzer_utilities
kenzieschmoll@ for:
- pkg/dartdev
pquitslund@ for:
- pkg/linter/lib/src/lint_codes.g.dart
If you're not the right person, feel free to summon someone else.
Most of the changes here are re-running code generators that auto-format the code they generate. The changes are:
Roll in the latest dart_style commit:
- DEPS
Manually updated these test expectations to expect the new style:
- pkg/analysis_server/test/lsp/format_test.dart
- pkg/analysis_server/test/services/refactoring/agnostic/change_method_signature_test.dart
- pkg/analysis_server/test/src/domains/flutter/set_property_value_test.dart
- pkg/analysis_server/test/src/services/flutter/container_properties_test.dart
- pkg/analysis_server/test/src/services/flutter/widget_descriptions_test.dart
- pkg/analysis_server/test/src/services/refactoring/convert_selected_formal_parameters_to_named_test.dart
- pkg/analysis_server/test/src/services/refactoring/move_selected_formal_parameters_left_test.dart
This was auto-generated by something, but I'm not sure why it thinks there is a diff:
- pkg/analyzer_plugin/doc/api.html
Updated to require a version of dart_style that accepts a language version in DartFormatter():
- pkg/analyzer_plugin/pubspec.yaml
Updated to always use the latest language version (and thus new style) when invoking the formatter:
- pkg/analyzer_utilities/lib/tools.dart
Manually updated the formatting in the code templates so that they matched the formatting expected by the tests, which implicitly format using the latest language version:
- pkg/dartdev/lib/src/templates/...
The rest are all generated files that are formatted so re-generated using the new style:
- pkg/_fe_analyzer_shared/lib/src/experiments/flags.dart
- pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart
- pkg/analysis_server_client/lib/handler/notification_handler.dart
- pkg/analysis_server_client/lib/src/protocol/...
- pkg/analysis_server/lib/protocol/protocol_generated.dart
- pkg/analysis_server/test/integration/support/integration_test_methods.dart
- pkg/analysis_server/test/integration/support/protocol_matchers.dart
- pkg/analyzer_plugin/lib/protocol/...
- pkg/analyzer_plugin/test/integration/support/integration_test_methods.dart
- pkg/analyzer_plugin/test/integration/support/protocol_matchers.dart
- pkg/analyzer/lib/src/analysis_options/error/option_codes.g.dart
- pkg/analyzer/lib/src/dart/error/...
- pkg/analyzer/lib/src/error/codes.g.dart
- pkg/analyzer/lib/src/manifest/manifest_warning_code.g.dart
- pkg/analyzer/lib/src/pubspec/pubspec_warning_code.g.dart
- pkg/analyzer/lib/src/summary/format.dart
- pkg/analyzer/lib/src/wolf/ir/ir.g.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_000_1.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_001_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_010_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_100_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/simple/...
- pkg/front_end/lib/src/api_prototype/experimental_flags_generated.dart
- pkg/front_end/lib/src/codes/cfe_codes_generated.dart
- pkg/front_end/lib/src/util/parser_ast_helper.dart
- pkg/front_end/test/parser_test_listener.dart
- pkg/front_end/test/parser_test_parser.dart
- pkg/front_end/testcases/...
- pkg/kernel/lib/src/coverage.dart generated
- pkg/kernel/lib/src/equivalence.dart generated
- pkg/linter/lib/src/lint_codes.g.dart
Change-Id: Ice0141b763e63b84f54692cd19a442a0719673c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391263
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@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 change shouldn't change any current behaviour, but means all "FilePath" types in the legacy protocol spec will go through a (currently no-op) conversion. The server will be able to replace this conversion based on client capabilities in a future CL.
Because a lot of the generated classes are in analyzer_plugin, this also moves the ClientUriConverter class there.
`pkg\analysis_server\test\src\utilities\json_test.dart` contains tests that the toJson/fromJson methods go through the converter recursively (inc. map keys/values/etc.).
Change-Id: If5aec884070128eea594540fd25a9017ada86079
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349060
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: 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>
This includes support for records, patterns, sealed classes, and class
modifiers. It also includes a fairly small number of style changes. The
one that will be most noticeable is more compact switch statements.
Change-Id: I9e89ba82d52bfa451fc54f9dd59048d72db48377
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285460
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
I am going to plumb some of this support through the flutter_tools
side, and want a consistent name for this port. 'servicePort' seems to
be more correct.
Change-Id: I73806e1d4c566a82605812504cb354c2b59710ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280562
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I don't think that there are any other highlight kinds we're going to
want to add, but if you can think of any please let me know.
I'll add code to actually associate the kind with record literals in the
next CL.
Change-Id: I15922984d96c2d0c7d97ea3f3832a95a68172968
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256524
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny