How does a Dart fix get associated with a Linter rule?

[domesticmouse]

Reading through the quick_fix documentation I'm left confused as to how a Dart fix is associated with a Linter rule. I'm guessing the Lint rule name has to be added to lib/src/services/linter/lint_names.dart, at least for testing purposes. It's probably worth explaining in the quick_fix documentation what the linkage is, and how it works.

I'm also confused as to why the linter package entry in pubspec.yaml is any. Shouldn't it be incremented to the version of the Linter package that contains all the lint rules listed in lib/src/services/linter/lint_names.dart?

[domesticmouse]

/cc @bwilkerson

[bwilkerson]

Reading through the quick_fix documentation I'm left confused as to how a Dart fix is associated with a Linter rule.

I'll update the doc later, but to unblock you...

The association is made in the lintProducerMap in FixProcessor.

I'm guessing the Lint rule name has to be added to lib/src/services/linter/lint_names.dart, at least for testing purposes.

It isn't necessary to define the lint name there, but it is the convention we follow.

I'm also confused as to why the linter package entry in pubspec.yaml is any.

I assume you mean the pubspec in the analyzer package. For the analyzer built in the sdk, the version constraint is in the DEPS file. For uses of the analyzer as a package, I suspect that it's always been acceptable to use the latest version. We don't let them get out of sync.

[FMorschel]

Reading through the quick_fix documentation

Does anyone know where that doc got moved to?

[bwilkerson]

It's probably the page at https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/doc/implementation/quick_fix.md.

[FMorschel]

Then I believe this is already completed look here:

Registering the fix

Before we can run the test, we need to register the correction producer so that
it can be run.

The list of fixes is computed by a FixProcessor. For each diagnostic passed
to it, it will look up the diagnostic in a table to get a list of the correction
producers it can use to produce fixes. There are three tables:

• The [lintProducerMap][lintmap] is used for fixes related to lint rules. The
  table is keyed by the name of the lint to which the fix applies.

• The [nonLintProducerMap][nonlintmap] is used for all other fixes. The table
  is keyed by the ErrorCode associated with the diagnostic.

• The [nonLintMultiProducerMap][multimap] is used for multi-producers, which
  are described below in "Multi-fix producers".

Actually, the tables contain lists of functions used to create the producers. We
do that so that producers can't accidentally carry state over from one use to
the next. These functions are usually a tear-off of one of the correction
producer's constructors.

The last step is to add your correction producer to the appropriate map. If
you're adding a fix for a lint, then you'd add an entry like

LintNames.could_be_final: [
  AddFinal.new,
],

At this point you should be able to run the test and see it failing.

[bwilkerson]

That's slightly out of date. The lintProducerMap is now keyed by a LintCode.