-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Could the various Lint related classes in package:analyzer be made public? #50986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think I agree. It would be perfectly reasonable to use these while writing a diagnostic in a plugin, right? |
On that note, I believe |
Some equally valuable utilities to expose would be the fixes / There's a large amount of them, and diagnostic plugins would otherwise have to reimplement them for their use-case. |
It's my opinion that we don't want to commit to supporting the lint related classes as part of the public API for the analyzer package, or to make |
We've got working designs for how to support plugins using LintRule, LintCode, CorrectionProducer, et al, so I will start working to make the necessary lint-related classes public. CC @pq |
This is hype! I'll definitely try this whenever it's available :) |
Work towards #50986 Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try Change-Id: I60d378da27570f6b76a554685802d3b888edee0d Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/372182 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Sam Rawlins <[email protected]>
Work towards #50986 This found a few lint rules that had not declared a `lintCode` or `lintCodes`! So I corrent them as well, and a few grammar nits in their descriptions. Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try Change-Id: I2bca3bbc382d1f25a3291326eb3b660c06d8917d Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/372183 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]>
Work towards #50986 Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try Change-Id: Ie5783240e3fc2c9f8076b3efb13f79a3b8fa5000 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375060 Reviewed-by: Phil Quitslund <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
@srawlins Should we close this now? |
There are a few classes that still need tidying, and in particular, renaming. |
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 #50986 Change-Id: I63cbbfc1d936bb4428aa0b8f5fb0638c9b61b3dc Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426284 Reviewed-by: Brian Wilkerson <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
Work towards #50986 Change-Id: I1bcdc6b32efef0f7e70bbb49c3cce046f95351fb Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428225 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]>
Work towards #50986 Also remove under-used libraryFragment getter. Change-Id: I6804bacc62abb483a339b28b8d5a226b689aa68d Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428224 Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
Work towards #50986 Change-Id: Ie9b2130d48929f8407a2ef20e23576699ecea2b9 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428223 Reviewed-by: Brian Wilkerson <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
Work towards #50986 At the same time, migrate `redeclare_verifier` from InheritanceManager3, so that the impl is the same as the `annotate_redeclares` lint rule. Change-Id: I9c5c77dcf50aa54820473874327bc3a7b93fd987 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428380 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Paul Berry <[email protected]>
Work towards #50986 Change-Id: I4c86dbf806964c98f4a1c5854eb53c6c8cfe002b Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428624 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Konstantin Shcheglov <[email protected]>
Work towards #50986 Change-Id: I56c14bc941e1204b9d9cc13086f5ed92a1228585 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428623 Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
Work towards #50986 Change-Id: Iedf1127b9f04aec910647c7f35597f38c6bfe1d2 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428846 Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Samuel Rawlins <[email protected]>
Hello!
I am working on enabling the implementation of custom lint rules in a syntax similar to how the Dart SDK defines them.
And while investigating how the SDK handles lints, I realized a large amount of classes related to them are private.
Here's a non-exhaustive of potential classes that I feel would be valuable if made public:
and their equally valuable dependencies, such as InterfaceManagger3, LinterVisitor, ...
All of these combined contain a large number of valuable utilities. Yet these objects aren't easily extractable out of the SDK. They are often entangled with the implementation classes of other aspects of the analyzer.
The text was updated successfully, but these errors were encountered: