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>
It's awkward that PluginCommunicationChannel.listen accepts a
`Function?` for the `onError` parameter, but it _must_ be a
`void Function(Object)` or a `void Function(Object, StackTrace)`. I
wish we had static analysis for this...
Change-Id: Id91a8172c7ef20e35bb8ff21736649d1501aff42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395082
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
I found that the `propagateLinterExceptions` analysis option was
being passed to the AnalysisRuleExceptionHandler class at
approximately the same point where the exception handler is called, and
also that the AnalysisRuleExceptionHandler class's `logException`
method did not _use_ the `propagateLinterExceptions` value; it just
_unconditionally_ returned it. So it gave it back to nearly the same
code that passed it in.
So we can simplify all of this by removing the `propagateExceptions`
field in AnalysisRuleExceptionHandler. But then that class has zero
fields and one method. _And_ that one method is _the only_ ,method
that is ever passed in to AnalysisRuleVisitor as the exception
handler. So remove the class altogether, and inline the method in
AnalysisRuleVisitor.
AnalysisRuleVisitor instead takes the bool value,
`shouldPropagateExceptions`, and does the right thing with it.
Additionally:
* Privatize AnalysisRuleVisitor `registry` property.
* Make AnalysisOptionsImpl `propagateLinterExceptions` property final.
Change-Id: Ia438881a3eccb3e26ebed294a7b7b8329d7961ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393902
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
It has seemed disingenuous to me that `enableTiming` has been a
property of AnalysisOptionsImpl, when it cannot be specified in an
analysis options file. Additionally, it is used in exactly _one_
place: the linter package's `benchmark.dart` script.
Instead, it makes more sense to think of this "flag" as a process-wide
flag. It is not something that may be set one way for some files, and
another for another set of files. And it is not something that can be
set to one value early during an analysis process, and then change; it
never changes.
So instead this change makes it a _final_, _private_ field on
AnalysisDriver, and on LibraryAnalyzer. LibraryAnalyzer gets its value
from AnalysisDriver, and AnalysisDriver gets its value from the
AnalysisContextCollectionImpl constructor.
Change-Id: I347605775680a8ea1c1237f0ee20bd4bbe2c6216
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393961
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
In many cases, AnalysisOptions is sufficient.
* ResolvedCorrectionProducer will be public API for someone writing an
analyzer plugin; it should not expose an AnalysisOptionsImpl. Luckily
the only need for the Impl, today, is in the "ignore diagnostic" fixes
so we can cast in there. (We could also expose the `file` and the
`unignorableNames` fields.)
* Some other spots only cast in order to access one of the 'strict'
fields, but all of those have been made public.
* AnalysisOptionsImpl.enabledLegacyPluginNames can be made final.
* Many other users don't need AnalysisOptionsImpl, or only need it to
pass it to other code that _does_ need it. In many of those cases it
makes sense to look at an object as an AnalysisOptions, and let the
code that needs a field from Impl to do a cast.
Change-Id: I3640934fb9d93c9b95f15a22457af604e420c7a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392240
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Also move the top-level `computeFixes` convenience function.
The `computeFixes` function is the main entrypoint that various code
uses to, well, compute all fixes with a FixProcessor and a
FixInFileProcessor. In order for plugin code to call `computeFixes`,
we need that function and FixInFileProcessor in the
analysis_server_plugin package.
Work towards https://github.com/dart-lang/sdk/issues/53402
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: Id5f02864762eeefb92055a3534e91b60b76dfeb2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378220
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
FixProcessor has to be part of the analysis_server_plugin package, so
it cannot have any dependencies on the analysis_server package. This moves one.
The word 'default' is reserved, so I changed to 'standard'.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: I1ee21c800203fac758f10a6fde0ea7d07eee5e7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374742
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This brings the soft static enforcement that we had before: a producer
that extends ParsedCorrectionProducer cannot access the
ResolvedUnitResult of a ParsedUnitResult.
Also we add some runtime enforcement that the producers used for parse-
only lint rules are ParsedCorrectionProducer.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If77fa66ae6fc070de1c7e931eb992a4adc14b68a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369561
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We do this by passing a CorrectionProducerContext up each of the
constructors. We can then remove all `configure` methods. This
requires a few changes and allows a few changes:
* Remove ParsedCorrectionProducer. It does not seem to have served a
purpose.
* CorrectionProducerContext no longer needs to be generic.
* Add a public getter for `MultiCorrectionProducer._context`, so that
a multi correction producer can pass along its context to child
correction producers.
* Introduce a `CorrectionProducerContext.instance` dummy variable,
used when we need to check if a correction producer can be applied
in bulk.
* Make `CorrectionProducerContext._node` public, so that it can be
used in factory constructors.
* `BulkFixProcesor.correctionContext()` return type is non-nullable.
* Add a factory constructor for AddMissingParameter, and move the
`configure` logic there.
* Add a factory constructor for ConvertAddAllToSpread, and move the
`configure` logic there. Then make `_isInlineInvocation` and
`_invocation` final.
* Add a factory constructor for ReplaceFinalWithVar, and move the
`configure` logic there. Then make `_removeFinal` and
`_finalKeyword` final.
* Add a factory constructor for ReplaceWithIsEmpty, and move the
`configure` logic there. Then make `fixKind`, `multiFixKind`,
`_binary`, and `_replacement` final.
* Rename `_AddMissingParameter.context` to `_executableParameters`,
and make it final.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If0e9bc1cbf5c8e656938bc6cd4eb32a9d4f06b38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368760
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
pq