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 updates `analyzer_use_new_elements` lint to stop reporting inside
deprecated declarations. So, we can deprecated and prepare for removal.
Apply deprecation dart/analysis/results.dart
Deprecate `ElementDeclarationResult`, add `FragmentDeclarationResult` instead.
Change `getFragmentDeclaration` (not yet published) return type to `FragmentDeclarationResult` to better correspond to the method name.
Rename `getElementDeclaration` from `AnalysisSessionHelper` to
`getFragmentDeclaration`, to better reflect on what it operates.
Change-Id: I2839c9a7e21ed2e5b34035fc8c3ec88fd23df1b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/412840
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
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>
Sam Rawlins