This is required so that an analyzer plugin can process producer generators that are registered in a plugin isolate.
* Change `AssistProcessor._generators` and
`AssistProcessor._multiGenerators` into private top-level variables
which are only used as "built-in" assist processor generators. They
must be explicitly registered, which we see much of in this change.
* Rename all of the lists of _generators_ and maps with lists of
_generators_, which were named "producers". The new names are
"generators." This leads to giant diffs because of alphabetizing.
Change-Id: Id4432737daaec1bb282f0b387619b23c18c0ea55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/53402
I move them all out of static fields on FixProcessor to be instance
fields on a singleton class in a new file, fix_generators.dart. For
each one that ended in the word 'Map', I removed that.
I also move `_bulkFixableErrorCodes` and `canBulkFix` to
BulkFixProcessor, as it is the only caller, and holds onto the data.
I also correct some outdated doc comments.
I also make `_isFixableError` static.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: I01beccac4969f832941c75eb6d7b49b54a0b085c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377563
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In order for CorrectionProducers to be used in analyzer plugins, we
need to access DartFixContributor which needs to compute fixes via
FixProcessor. So both DartFixContributor and FixProcessor need to be
moved into analyzer_plugin (eventually). For now, to support
prototyping, I am moving FixProcessor to its own library, and
separating all of the built in mappings (from diagnostic to producer
generators).
I think this separation actually stands on its own as being tidier,
simplifying fix_internal.dart, and separating code from data, as it
were.
Work towards https://github.com/dart-lang/sdk/issues/53402
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try
Change-Id: I3b4fadc7ed94c23597d72bef7dcd832380d34e9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345561
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This may seem to be a silly change, adding these lists only for the
error fix status file, but I claim this is a very pragmatic solution:
* It is important and beneficial to correctly track error fix
statuses; I was recently confused about these fix statuses because
the text in the fix status file was a lie.
* When fixes are added for more errors, you cannot forget to update
the codesWithFixes list because the fix won't apply (and no test
asserting the fix works would pass).
* Overhauling these FixGenerators to use maps like the others is maybe
a good change in the long run, but at this point might be
over-engineering; we only have fixes for 2-3 codes for each file
type.
Change-Id: Iaa902acf2401f97ff722e222910f5d6fcd00a5ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Sam Rawlins