To support this feature:
* Remove `DartAssistContextImpl` as it has no differences from
`DartAssistContext`. Thus the getters `DartAssistContext` are made
into fields, and all callers now call `DartAssistContext()`.
* Add a top level `computeAssists` function, similar to the top-level
`computeFixes` function.
Change-Id: I3ef5fd9ee9430150004b29c11ab972939b85b214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The PluginServer class needs access to AssistProcessor in order to
compute assists. That class needs access to a few other classes, which
then must also be moved:
* assist_core.dart - the Assist class
* assist_dart.dart - the DartAssistContext class
* assist_generators.dart - the registeredAssistGenerators variable
* assist_performance.dart - the AssistPerformance and
GetAssistsPerformance classes
* assist_processor.dart - the AssistProcessor class with it's
singular API, `compute()`
* performance.dart - the ProducerRequestPerformance class
* the `addCaretAtOffset` helper function, refactored into a
`withCaretAt` extension method
This change is functionally a no-op.
Change-Id: Ic883d21e9cc8c3db1f6093f830f01ec6eb9a0976
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
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>
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>
Sam Rawlins