[analyzer/linter] Consolidate still relevant information from `rules.json` into `messages.yaml`

[parlough]

As we introduce diagnostic style documentation for lint rules in pkg/linter/messages.yaml, we should collocate other relevant linter rule and lint code information in the same messages.yaml file. While doing so, we can move the old lint documentation information out of source code. This will help us to simplify and generalize the LintRule class, and in some cases, reduce the amount of strings that get included in the analysis server executable.

• Link to hosted version of new diagnostic docs when it's written and marked published (91254e4)
• Move since information from tools/since/sdk.yaml to messages.yaml (62a52ed)
• Generate info needed by both docs and source from messages.yaml
  • LintCode (1f4f0d3)
  • LintRule#description (TODO: @parlough)
  • LintRule#incompatibleRules (TODO: @parlough)
  • LintRule#state (9de2a62)
  • LintNames enumeration (a409a1c)
  • Maybe: Registration functionality from linter/lib/src/rules.dart (TODO: @parlough)
• Remove various info from source, move to messages.yaml if needed for docs
  • LintRule#documentation (3bf33d6)
  • LintRule#details (46cd8b6, 4819bd0)
  • LintRule#categories (94eef72, a4a7af7)
  • Rule sets/packages info won't be moved

---

Once relevant data is migrated:

• Improve and clean up validation of and generation from messages.yaml (1b6fe34)
• Move downstream users away from machine/rules.json
  • dart-lang/site-www
  • dart-lang/lints
  • Other users?
• Delete generation code and tests of machine/rules.json (e2a2761)
• Remove the generated machine/rules.json file from the SDK and dart-lang/site-www
• Fully remove the LintRule and LintCode members that were deprecated as part of this work

[parlough]

I have a proposal for generating rules from the messages.yaml file in https://dart-review.googlesource.com/c/sdk/+/397380

Follow up work can/will simplify it further, but overall this seems like a good initial setup that might reduce memory usage a bit too. Happy to receive some feedback :)

[bwilkerson]

@pq @srawlins I'd like to get your thoughts on this change. We especially need to consider how this would impact plugin authors, if nothing else in terms of the compatibility of the APIs for writing first-party lints vs. writing lints in plugins.

[pq]

I'll defer to Sam on plugins. Very interested to get his perspective.

[srawlins]

I love this.

This change seems to acknowledge that the LintRule subclasses were really just a few pieces of static data passed up to the super constructor, and one method. So then we change that to a calls to LinterLintRule (in Lint_rules.g.dart):

    LinterLintRule(
      name: LintNames.avoid_single_cascade_in_expression_statements,
      config: avoid_single_cascade_in_expression_statements.config,
      description: 'Avoid single cascade in expression statements.',
      state: State.stable(since: version(2, 0)),
      lintCodes: [LinterLintCode.avoid_single_cascade_in_expression_statements],
    ),

and the config getter looks like:

  LinterLintConfig get config =>
    LinterLintConfig(register: (lint, registry, context) {
      var visitor = _Visitor(lint);
      registry.addCascadeExpression(lint, visitor);
    });

(Most of them just pass in the callback that used to be void registerNodeProcessors().)

The simplest implementation for plugin authors, I believe, is to register a "rule" by having the author call something like:

register(
  LinterLintRule(
      name: 'avoid_single_cascade_in_expression_statements',
      config: config,
      description: 'Avoid single cascade in expression statements.',
      state: // Omitted state?
      lintCodes: [one, two, three],
    ),
);

and declaring that config:

  LinterLintConfig get config =>
    LinterLintConfig(register: (lint, registry, context) {
      var visitor = _Visitor(lint);
      registry.addCascadeExpression(lint, visitor);
    });

I don't see why we couldn't offer a similar generation script though, in the analysis_server_plugin package.