Work towards https://github.com/dart-lang/sdk/issues/55660
Spelunker will move to the analyzer_testing package, so we must first
clean it up.
Spelunker had two subclasses, but their only differentiation was the
calculation of a getter, which could be a final field. So I remove the
subclasses, move the "File"-based one to the spelunk utility script,
and change the Spelunker constructor to take in a source string.
Additionally:
* Make all of the fields private.
* Remove isDartFileName and isPubspecFileName. These calculations can
be inlined into their call sites and make use of the `file_paths`
library.
Change-Id: I4b97ed03a2845440dabd3a9ab0aa3b3ba4af5959
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428083
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Before this change, we had an enforcement that either 'get lintCode' or
'get lintCodes' is implemented, but it was a runtime enforcement. And it
was a little roundabout.
The new system is simpler and more typical:
* `AbstractLintRule` is the parent type, and it's sealed. It provides
`get lintCodes` as an interface. Code outside of the lint rules
requires this getter, in registering codes, etc.
* `LintRule` is the new subclass which is the "90% case." It declares
a `get lintRule`, and offers simpler reporting methods for reporting
a single code everywhere.
* `MultiLintRule` is the new subclass which represents that last
"10% case." It only declares the reporting methods which all require
a LintCode parameter, since there is no concept of a "default lint
code among all my lint codes."
Work towards https://github.com/dart-lang/sdk/issues/50986
Change-Id: I63cbbfc1d936bb4428aa0b8f5fb0638c9b61b3dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426284
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Currently, the `AnalysisContextCollectionImpl` constructor has a
callback parameter, `updateAnalysisOptions2`, which has 3 required
parameters. The caller can then pass in a closure which accepts those
parameters, and updates analysis options.
I find this to be a bit of an awkward API, and a little bit complex, so
it would be good if we can simplify it. It is all private impl, but it
is used in a few codebases, I believe. Dartdoc is one.
So, it looked to me like none of the callers _use_ the `ContextRoot`
parameter, so it would be good to simplify here, and remove it from
the callback signature.
This is _not_ the final API I'm looking for. Just an incremental step,
and since it is private API, it doesn't need to be in a major release
of analyzer.
Change-Id: Iad9da9f36e817add0bd8c49975ecd14311588661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392204
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The lints `omit_obvious_property_types` and
`specify_nonobvious_property_types` previously had error fix status
'needsEvaluation'. This CL changes it to 'hasFix'. This is needed in
order to get access to the fix in IntelliJ.
This CL also corrects a bug whereby a map literal was considered to have an obvious type in cases where there were no actual type arguments and no elements with an obvious type.
Change-Id: Id9305152d086604b78636b696bd97e318ed6bdb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393280
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously there was a `ReportFormatter` -> `SimpleFormatter`
-> `DetailedFormatter` hierarchy, but `DetailedFormatter` was the only class that was concretely instantiated. So we collapse these three
into one class. (`SimpleFormatter` was used in tests, but here we
convert those uses to use the remaining `ReportFormatter` class, and
use the `test_descriptor` package to allow that formatter to read
source files from disk, during the test.
Additionally, no arguments were passed for the `fileCount`, `fileRoot`,
or `machineOutput` constructor parameters, so those parameters and
corresponding fields are deleted.
Change-Id: I9d14acef7379325c42dcc729b9c77362ccd1aa86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392408
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>
Each call site for `parseLintRuleConfigs`, `processAnalysisOptionsFile`
immediately just want the `ruleConfigs` (which is the only property of a
LintConfig). So instead of passing around LintConfigs, just pass around
the list of RuleConfigs.
(LintConfig can probably be deleted now, but I'll look at that for a
separate change; might need care with google3.)
Change-Id: I30eba648e5f53bc5d5196ce95c09c8261535a737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391161
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Sam Rawlins