@@ -35,7 +35,7 @@ class MyRule extends AnalysisRule {
3535 );
3636
3737 @override
38- LintCode get lintCode => code;
38+ LintCode get diagnosticCode => code;
3939
4040 @override
4141 void registerNodeProcessors(
@@ -51,16 +51,21 @@ Let's look at each declaration individually:
5151* ` class MyRule extends AnalysisRule ` - The rule class must extend
5252 ` AnalysisRule ` .
5353
54- * ` static const LintCode _code ` and ` LintCode get lintCode ` - Each rule class
55- must implement either ` LintCode get lintCode ` or `List<LintCode > get
56- lintCodes`, depending on whether there is only one diagnostic that it can
57- report, or multiple.
54+ * ` static const LintCode _code ` and ` LintCode get diagnosticCode ` - The rule class
55+ must implement ` LintCode get diagnosticCode ` , for infrastructure to be able
56+ to register the diagnostic code that the rule can report.
5857
5958 A ` LintCode ` is the template for each diagnostic that is to be reported. It
6059 contains the diagnostic name, problem message, and optionally the correction
6160 message. We instantiate a ` LintCode ` as a static field so that it can also be
62- made const. If the rule needs to report more than one ` LintCode ` , with
63- different problem messages, then multiple static fields can be declared.
61+ made const.
62+
63+ Alternatively, if a rule can report several different diagnostic codes
64+ (typically for differentiated messages), it can instead extend
65+ ` MultiAnalysisRule ` , and then implement ` List<LintCode> get diagnosticCodes `
66+ instead of ` LintCode get diagnosticCode ` . The rule can then declare the
67+ different ` LintCode ` s in multiple static fields, which are referenced in the
68+ ` diagnosticCodes ` getter.
6469
6570* ` MyRule() ` - The rule class must have a constructor that calls ` super() ` ,
6671 passing along the name of the rule, and a description. Typically this
0 commit comments