This change allows the LegacyAnalysisServer to understand when the
plugin isolate (if there is one) is analyzing or not. There are a few
primary concepts:
* The plugin isolate (PluginServer) notifies the analysis server, when
analyzing all files in a context collection, and analyzing changed
files, that it is analyzing, and later that it isn't.
* The NotificationManager tracks whether the plugin isolate is analyzing
or not, based on the last status.
* The PluginManager tracks whether new plugins are initialized or not.
This is determined by the work done by the PluginWatcher. If no
plugins are configured, then plugins are declared to be "initialized".
Otherwise, the AnalysisServer sets their status to be "initialized"
after receiving the first status notification from the plugin isolate.
* The LegacyAnalysisServer now uses the additional "are plugins
analyzing" signal, held in NotificationManager, and the "are plugins
initializing" signal, held in PluginManager, to determine whether to
notify the client that analysis is complete.
Change-Id: Ie2b6a6048f074d7a26d7d5d07622a17c30fcab96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405444
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This enables plugin sources to be specified in one of three ways:
* as a YamlScalar, like `plugin_name: ^1.2.3`
* with a 'version' key, like `plugin_name:\n version: ^1.2.3`, which
allows diagnostic configurations to be alongside.
* with a 'path' key, like `plugin_name:\n path: foo/bar`, which
allows diagnostic configurations to be alongside.
We introduce a PluginSource with a `toYaml` method to convert the
values back into YAML for the generates pubspec. We update
PluginPackageGenerator to use PluginSource.toYaml.
Change-Id: Ic5f372f0339edd6aa638dd9b568a83f41a023b08
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Also allow warning diagnostics to be disabled.
In many places, the RuleConfig is unchanged because currently the
`linter/rules` section parsing is shared with the `plugin/<plugin-name>/diagnostics` section parsing.
They will probably diverge at some point, but as long as they are the
same, we can use the same Registry class to identify enabled and
disabled rules/diagnostics.
Change-Id: I9c00770af14d3b753532bcf1bc6bff62624d99ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393460
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
* PluginConfiguration.ruleConfigs is now a Map instead of a List,
mapping analysis rule names to each RuleConfig. This makes it more
straightforward (and theoretically more performant) for the Registry
to determine the set of enabled analysis rules. The primary parsing
code, `parseLinterSection`, also returns a mapping now.
* This merges seamlessly into `AnalysisOptionsImpl`'s call to
`parseLinterSection`.
This is most of the refactoring work found in
https://dart-review.googlesource.com/c/sdk/+/392981, but without the
change to allow warnings to be disabled.
Change-Id: I4d1e6791da83ad370c18a15e9e3bb85b1daed58d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393120
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Since the LintRule class is the basis for writing both "lint rules"
(rules that must be explicitly enabled) and "warning rules" (rules that
are enabled by default), it is a misnomer to use 'LintRule' as a
supertype. This change adds an alias, 'AnalysisRule'. Additionally:
* Rename LinterVisitor to AnalysisRuleVisitor.
* Rename lintRuleTimers to AnalysisRuleTimers.
* Rename LinterExceptionHandler to AnalysisRuleExceptionHandler.
* Rename LintRuleExceptionHandler to _AnalysisRuleExceptionHandler.
* NodeLintRegistry is used in too many places, so I have left it for
now.
Change-Id: I43340cca0f9b64502960d8f5e05c6c9b81c3dfd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392203
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This bumps the Registry class to be able to take "rules that are enabled by default" and "rules that need to be explicitly enabled", "lint rules" and "warning rules". Next is to improve the classes.
Add parsing for the top-level `plugins` section, and
`PluginConfiguration` class to hold this data, and
`get pluginConfigurations` on AnalysisOptions.
Rename `parseLintRuleConfigs` to `parseLinterSection` to align better
with the other functions in engine.dart.
Rename `_ruleConfigs` function to `parseRulesSection`.
Change-Id: Ib93b7548bfb13cc94381971a5a2780a5dc81e9f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In this CL, I run plugin code that responds to a request in an error
zone. The bulk of this change though is the tests that verify how we
handle asynchronous and synchronous thrown errors.
I separate some shared code from plugin_server_test into a shared lint
rules file and a base class. Then a second test is introduced with a
few error cases.
Change-Id: I4e252ae0d3bec0cf6625c0044681677fba3132bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
* Move the only 3 files from server_plugin to analysis_server_plugin.
* Copy some test infra into analysis_server_plugin. This is temporary,
as we need some shared test infra location.
Change-Id: If2b41d436c9d3051e590f60ae2eb7ab31e529321
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364161
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins