These files had comments indicating that running
`pkg/analysis_server/tool/spec/generate_files` would regenerate them,
but that was not the case.
Change-Id: I6ceb6352edf6eab5e746276a0a2f33b16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
Updates the `CodeGenerator` mixin so that it outputs `ignore_for_file`
comments to ignore the following lints:
- unnecessary_type_name_in_constructor
- unnecessary_ignore
- duplicate_ignore
This mixin is used by the code generators that produce the Dart
wrappers for the analysis server and analyzer plugin wire protocols.
This is a first step towards migrating the packages `analysis_server`,
`analysis_server_client`, and `analyzer_plugin` packages to use the
new constructor declaration syntax, since it will allow the
`unnecessary_type_name_in_constructor` lint to be enabled without
breaking generated code.
Once all the packages have had their SDK constraints bumped to a
language version that supports the new syntax, I'll update the code
generator to use the new syntax, and remove the ignores.
For more information about the new constructor declaration syntax, see
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
Change-Id: Ied17e3ea772546675aad48efc324f6f16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505521
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This avoids a second Map access for retrieving every value in every
message from a plugin.
This also extracts out the `if (json is Map)` case outside of a block,
by short-circuiting when `json` is not a Map.
Change-Id: I962511d44ea797a0105901510a9182b5811b0230
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: 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>
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>
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>
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 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 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 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>
In https://dart-review.googlesource.com/c/sdk/+/191862 we added two new
required fields to `Location`. Unfortunately this was a breaking change
because plugins using an older version of the `analyzer_plugin` produce
location objects without those fields, leading to deserialization failures.
This CL makes those fields optional in order to fix the deserialization
issue.
Unfortunately, the `analyzer_plugin` package was published after the
required fields were added. Making them optional is a breaking change
because the constructor parameters go from being positional to being
named parameters.
We also neglected to update the version number of the protocol as part
of the previous CL. Technically this is also a breaking change for clients
of the analysis server, but given that they had no way to test to see
whether these fields existed they would need to have been written as if
the fields were optional in order to reference them at all, so I think
that from a practical standpoint it isn't a breaking change. That does,
however, raise the question of whether we should increment the version
numbers as part of this CL.
Change-Id: I35fc1f8e950669a3d8dd33cee6b81890261b5c47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206942
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Paul Berry