There is no code in this CL that _uses_ the new AnalysisStatus
Notification or type, but landing it is important, so that I can test
plugins which will use the analyzer_plugin package from pub.
Change-Id: I31f835d5f7b8bda3781a6962d37f1f769b22852e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404702
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
Some of the parameters noted can be required and/or non-nullable as
per our internal usage, but this is all public API, so I'm just leaving
a note.
Mainly just simplify the implementation of ErrorProcessor.getProcessor.
Change-Id: Idebcf4a2485029c914d495cabfa3a1e98824c72c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396360
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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, the fields in an AnalysisOptionsImpl were primarily
arranged by an extension method, declared externally, called
`applyOptions`. It seemed very odd that this wasn't just a method on
AnalysisOptionsImpl; the "Impl" class is already private.
But it turns out that an AnalysisOptionsImpl is _mostly_ not mutated
in practice; the class wants to be immutable, with final fields.
In this change, I make AnalysisOptionsImpl mostly immutable, and
convert the `applyOptions` extension method, and all of its helper
code, into a builder class, AnalysisOptionsBuilder. While we don't
use a lot of builders in analyzer packages, this is a much more common
and idiomatic pattern for setting up complicated data, multiple values,
and then finalizing it all into an object that will not be changed
again during it's lifetime.
One big benefit of this refactoring is that most fields in AnalysisOptionsImpl are now final:
* sourceLanguageConstraint
* errorProcessors
* excludePatterns
* file
* strictCasts
* strictInference
* strictRawTypes
* chromeOsManifestChecks
* codeStyleOptions
* formatterOptions
* unignorableNames
Whereas before, they _all_ had to be mutable, as `applyOptions`, the
primary mechanism for setting up an AnalysisOptionsImpl, had to able
to write any field.
Other changes:
* Flip the instantiation of AnalysisOptionsImpl and CodeStyleOptions;
now CodeStyleOptions is instatiated first, and AnalysisOptionsImpl
sets itself as `codeStyleOptions.options`.
* Remove the private, deprecated, `applyToAnalysisOptions` function.
Change-Id: I6595d88aa5721e4f9a8b2b987482f9f43d27efd1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/390660
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When adding imports for elements, we could leave unnecessary imports because the first element is imported through one library, and then a subsequent element is imported through a library that _also_ includes the first element.
With this change, any time we add a new element import, we will check the existing pending imports to see if any of those can be satisfied by this new import, and if so map it over and check whether the old import is now unused by any element imports (and not an explicit import), in which case it can be removed.
Fixes https://github.com/dart-lang/sdk/issues/56627
Change-Id: I82b638dfd2a36a72e5c7c55cae73842907ea3896
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384780
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Previously any pending imports added by DartFileEditBuilder would just be sorted by their text ignoring the kind of import. If there were existing imports for dart, package, relative then they might be inserted in the right places, but if there were not (or not the right kind) of existing imports, they would be just be added in alphabetical order (rather than dart, then package, then relative).
This change extracts some of the rules for sorting directives from analysis_server's ImportOrganizer into analyzer_plugin/src so that they can be reused by the DartFileEditBuilder that lives there.
Fixes https://github.com/dart-lang/sdk/issues/56657
Change-Id: I6dc5476add2b7b1804080ffdc8270d0bb80597db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384284
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
`DartFileEditBuilder._importLibrary says "If [prefix] is an empty string, adds the import without a prefix", however the handling of an empty string would not match with prefixless imports due to an equality check (null vs empty string).
There was already a correct check further down, so this change moves that check further up and removes the bad condition from the earlier check.
Change-Id: I6a3a38cf9cae23e0d5e07804ef262d515af741f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383322
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is the core implementation of the "plugin server" that will support the API described at https://docs.google.com/document/d/1T8P323DJxsc3YPzveNIaSKWFkrJp9ydTR4jp_XFb7XQ/edit?resourcekey=0-f8Ue29KMUizqXNGhATp1tg#heading=h.23fjh5hfm2is
This is heavily curbed from the ServerPlugin class at
`package:analyzer_plugin/plugin/plugin.dart`, but does not depend on it.
It depends on two concepts from the analyzer_plugin package: (1) the
protocol used for de/serializing requests, responses, etc. And (2) the
`PluginCommunicationChannel` class. This is also just a utility for
communicating between the analysis server and the plugin server.
This plugin server is capable of "registering" individual "plugins",
which allows plugins to register individual (maybe multiple) lint rules,
and individual (maybe multiple) quick fixes.
The plugin server for now only responds essentially to three requests:
* `ANALYSIS_REQUEST_SET_CONTEXT_ROOTS`
* `EDIT_REQUEST_GET_FIXES`
* `PLUGIN_REQUEST_VERSION_CHECK`
All files are analyzed during `handleAnalysisSetContextRoots`, and
quick fixes are calculated during `handleEditGetFixes`.
There are many TODOs, but the included test shows that this plugin
server can notify the analysis server of lint diagnostics to be
reported, and can respond to a query for quick fixes.
Change-Id: Ibc93332319220a2caf49d20ab480940041a15049
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382480
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In this CL, I do not change the signature of any EditBuilder code, as
it is public analyzer_plugin API. I only change doc comments and a few
impl nits here and there, to make more modern or idiomatic.
This CL is isolated this way so that when I do a copy to the
analysis_server_plugin package, the moves will be smaller, readable
diffs (almost zero diff, just imports and things like that).
Change-Id: Ibc8a5ddb9a679278dd7223a3e2d868fe21c4acef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363881
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
FMorschel