Files

T

Sam Rawlins c1e535031d analyzer: Simplyify propagating lint rule exceptions

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>

2024-11-12 17:03:39 +00:00

lib

analyzer: Simplyify propagating lint rule exceptions

2024-11-12 17:03:39 +00:00

test

analyzer plugins: parse version and path keys in YAML

2024-11-06 19:41:00 +00:00

analysis_options.yaml

Track migration in 5 more packages

2024-10-18 17:03:29 +00:00

analyzer_use_new_elements.txt

Elements. Use analyzer_use_new_elements.txt for opt-out, not opt-in.

2024-11-04 22:38:38 +00:00

CONTRIBUTING.md

linter: add contributing docs about closing issues

2024-04-23 20:43:10 +00:00

LICENSE

…

OWNERS

…

pubspec.yaml

DAS plugins: Run plugin code zoned

2024-09-09 14:46:18 +00:00

README.md

…

README.md

analysis_server_plugin package

This package is being developed for the second incarnation of Dart Analyzer plugins. It is in an intermediate state, and a few things must be kept in mind during this phase of development:

This package is not to be published on pub yet. We will flesh out a stable API befoure the first publish.
In order to support the above point, no pub-publishable code can depend on this package. At no point can we introduce a dependency from a package like analyzer or analyzer_plugin to this package. If we did so, then at the next time we published that package to pub, we would need to publish this package to pub. No. In short, I think what this means is that only the analysis_server package can depend on this package.

Migration of code between packages

As part of the design of the new Dart Analyzer plugins, much code will shift around, in a few directions.

analysis_server package to analysis_server_plugin package: The API of the new Dart Analyzer plugins focuses around two primary concepts: lint rules and quick fixes. Quick assists may be chosen as a third important concept. Lint rule code has typically lived in the analyzer package, and does not need to move. (It's presence in the analyzer package could be deprecated in favor of this package, but it is not important for the implementation.)

Quick fixes, however, have only existed in concept, and interface, and API, in the analysis_server package. That code needs to move to this package in order to be used in a Dart Analyzer plugin.

A move from the analysis_server package to this package is not a breaking change.
analyzer_plugin package to analysis_server_plugin package: Care is being taken to decide where Dart Analyzer plugin code will live and how it will be published. It is not decided yet what the ultimate package API will be. Some code from analyzer_plugin may move to this package.

A move from the analyzer_plugin package is a breaking change. Extreme care must be taken.
analyzer_plugin package to analysis_server package: There will be many components of the analysis server that currently live in analyzer_plugin, because they were necessary for the first version of Dart Analyzer plugins), but are not part of the new Dart Analyzer plugins. These components can be moved safely back into the analysis_server package.

In terms of priority, it is not crucial for such code to be moved out of the analyzer_plugin package. It can live there indefinitely, and the analysis_server package can continue to depend on code from the analyzer_plugin package, as shipped in the SDK.

A move from the analyzer_plugin package is a breaking change. Extreme care must be taken.