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>
This change updates the flow analysis logic for `is` and `as`
expressions so that when the language feature `sound-flow-analysis` is
enabled, the static type of the operand is compared to the type to the
right of the `is` or `as` keyword. If one of the types is non-nullable
and the other type is `Null`, then the type test is known to fail. For
an `as` expression, this means that the code path following the
expression will be marked as unreachable. For an `is` expression, this
means that any code paths that assume it evaluates to `true` will be
marked as unreachable.
Note that these new behaviors break assumptions made by three
pre-existing flow analysis tests. I was able to adjust one of the
tests ("equalityOp_end does not set reachability for `this`") to
preserve its old behavior. The other two tests became redundant, so I
removed them.
There is no behavioral change if the feature `sound-flow-analysis` is
disabled.
Bug: https://github.com/dart-lang/sdk/issues/60438
Change-Id: Ib3a9e96bd39cf7df4c6c297568763c0f25bc9e39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420164
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@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>
The new lint, called `analyzer_public_api`, verifies that the analyzer
public API satisfies the following properties:
- No method, function, getter, setter, or supertype in the public API
refers to a non-public type.
- No `export` declaration in the public API shows a non-public name.
- No declaration in the public API has a name ending in `Impl`.
- No file in the public API has a `part` declaration that points to a
file that's not in the public API. (If it did, then the other checks
could be circumvented.)
A new annotation is added, `@AnalyzerPublicApi()`, allowing
declarations in `package:analyzer/src` or
`package:_fe_analyzer_shared/src` to be marked as part of the analyzer
public API. This is necessary because some parts of the analyzer
public API need to be declared elsewhere and then exported by the
analyzer.
A few lint violations have been ignored using `ignore:` comments. I
will try to clean these up in follow-up CLs.
Fixes https://github.com/dart-lang/sdk/issues/60058.
Bug: https://github.com/dart-lang/sdk/issues/60058
Change-Id: I0047a73dec8a29e2ffe03dd3a90f7e41ca2e27b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409763
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We've decided to rename enum shorthands to dot shorthands. It describes the entire feature better. It's not only for enum values. We'll update the experiment name before the implementation goes in, that way our users can use a flag that matches the actual feature name.
Additionally, roll co19 to b14b0802e696a60c79b00d0f052e26fb986f0faf so we can avoid an infra failure with co19 using what's now an unknown feature flag (enum-shorthands).
2025-02-06 sgrekhov22@gmail.comFixesdart-lang/co19#3067. Rename the static access shorthand feature experiment flag (dart-lang/co19#3068)
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try
Bug: https://github.com/dart-lang/sdk/issues/57037
Change-Id: I031e3bce8166145b24dbb77acf259d78e6e00f0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/407603
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This enables plugin sources to be specified in one of three ways:
* as a YamlScalar, like `plugin_name: ^1.2.3`
* with a 'version' key, like `plugin_name:\n version: ^1.2.3`, which
allows diagnostic configurations to be alongside.
* with a 'path' key, like `plugin_name:\n path: foo/bar`, which
allows diagnostic configurations to be alongside.
We introduce a PluginSource with a `toYaml` method to convert the
values back into YAML for the generates pubspec. We update
PluginPackageGenerator to use PluginSource.toYaml.
Change-Id: Ic5f372f0339edd6aa638dd9b568a83f41a023b08
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
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>
I think when I was adding these modes, I put them on AnalysisOptionsImpl
to keep them secret and flexible. But they're pretty stable now.
Also split out the analysis options `include` tests to test merging
of individual lists and maps.
Change-Id: Ie54a1951dc82900c1fdfc06023cfa7cfb2f410a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391020
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There will undoubtedly be other places where we need hooks, but I thought
that these would provide a good starting point for attempts to start
converting existing code to the new API.
Change-Id: If04aea4244efaca5a81553fbd88066b24c169290
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385303
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov