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>
We do this by passing a CorrectionProducerContext up each of the
constructors. We can then remove all `configure` methods. This
requires a few changes and allows a few changes:
* Remove ParsedCorrectionProducer. It does not seem to have served a
purpose.
* CorrectionProducerContext no longer needs to be generic.
* Add a public getter for `MultiCorrectionProducer._context`, so that
a multi correction producer can pass along its context to child
correction producers.
* Introduce a `CorrectionProducerContext.instance` dummy variable,
used when we need to check if a correction producer can be applied
in bulk.
* Make `CorrectionProducerContext._node` public, so that it can be
used in factory constructors.
* `BulkFixProcesor.correctionContext()` return type is non-nullable.
* Add a factory constructor for AddMissingParameter, and move the
`configure` logic there.
* Add a factory constructor for ConvertAddAllToSpread, and move the
`configure` logic there. Then make `_isInlineInvocation` and
`_invocation` final.
* Add a factory constructor for ReplaceFinalWithVar, and move the
`configure` logic there. Then make `_removeFinal` and
`_finalKeyword` final.
* Add a factory constructor for ReplaceWithIsEmpty, and move the
`configure` logic there. Then make `fixKind`, `multiFixKind`,
`_binary`, and `_replacement` final.
* Rename `_AddMissingParameter.context` to `_executableParameters`,
and make it final.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If0e9bc1cbf5c8e656938bc6cd4eb32a9d4f06b38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368760
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We decided that the existing mechanism, three bool values that can be
overridden by an AbstractProducer subclass, was confusing as it might
give the impression that they are independent, and that any of the 8
possible combinations are valid. But really each author of a
CorrectionProducer just needs to answer one question: how broadly can
this correction be applied?
So to answer that question we decided (loosely in emails) to offer an
enum of a few values that more-or-less represent the sensible
combinations of the bool getters. And more specifically I decided in
this CL what those values should be.
In this CL I also remove the notion of a default value. Each
CorrectionProducer must indicate specifically how broadly it can be
applied.
This PR should functionally be a no-op; no applicability was increased
or reduced. I left comments intact. I left `TODO(applicability)`
comments where no comment is made to justify why a correction cannot
be made any more broadly than "only at specific location."
Change-Id: I3e3a12ee811b2b08f276ff755e7ff638f4fffabf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366740
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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 is necessary to separate `ClassElement`, `EnumElement`, and `MixinElement`. And, in the future, augmentations like `ClassAugmentationElement`, etc.
Change-Id: Iecd2f8707212e53ef56f0e101880c7bab9e5d057
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254104
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For `InterfaceType` keep `element2` deprecated and define
`InterfaceElement get element2` instead. Most changes are because
of this.
Change-Id: I13b888610fc707438c3c97b676f1460e7fc2b040
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253564
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change makes sense to me for a couple of reasons. First, when
editing a correction producer the information about whether it can be
bulk applied will be easier to find. Second, the information doesn't
need to be duplicated when the producer can be applied to multiple
error codes. And third, because the information is in one place we can't
enable a producer in one place and miss enabling it in other places.
This does have the unfortunate consequence that an extra producer needs
to be created for bulk application in order to determine whether it
should be applied at all, and can't be re-used because producers
maintain state. We could consider storing a 'generator' object rather
than a generator function in the map and have the `newInstance` methods
produce those objects, but I'm not convinced that it's worthwhile given
how short lived the extra producer is.
There was also one subtle change that you probably won't see by looking
at the changes, which is that one of the producers was enabled for bulk
application for a lint but not enabled for several non-lint cases. It is
now enabled everywhere. I remember thinking at the time that it should
be fine, but I've forgotten which producer it was, so I can't easily
tell you. If you want to confirm that change I'll be happy to do the
work of figuring out which producer it is and which error codes were
impacted by the change.
Change-Id: I2010d777f727472c0d307a6948b84d37491e2b17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202600
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This should allow doing partial migration, specifically protocol files,
which are imported by other libraries, but are a small library cycle
that does not import much outside of it.
Change-Id: I904c05d6d5b444ee9a9dbd1f7ada12aabdcc5165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193583
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Sam Rawlins