# Copyright (c) 2021, the Dart project authors.  Please see the AUTHORS file
# for details. All rights reserved. Use of this source code is governed by a
# BSD-style license that can be found in the LICENSE file.

# This file is organized as a two level map, where the outer key corresponds to
# the name of an analyzer error class (e.g. CompileTimeErrorCode), and the inner
# key corresponds to the name of a static variable in that class, describing a
# single diagnostic message. Ideally, each entry contains three parts:
#
# 1. A message template (problemMessage).
#
# 2. A suggestion for how to correct the problem (correctionMessage).
#
# 3. User-facing documentation for the problem (documentation).
#
# A message shouldn't indicate which kind of diagnostic it is, for example,
# warning or error. This is implied by the analyzer error class. For example,
# all entries in `StaticWarningCode` are warnings.
#
# See the file [lib/src/fasta/diagnostics.md] for more details on how to write
# good diagnostic messages.
#
# A message used for internal errors should have key that starts with
# "InternalProblem". This way, UX review can prioritize it accordingly.
#
# Eventually, we'd like to have all diagnostics in one shared location. However,
# for now, we have analyzer error codes and CFE error codes in separate files.
# See `pkg/front_end/messages.yaml` for the CFE error codes.
#
# ## Parameter Substitution in problemMessage and correctionMessage
#
# The fields `problemMessage` and `correctionMessage` are subject to parameter
# substitution. When the compiler reports a problem, it may also specify a list
# of values to be substituted into the message. Parameters are declared using
# placeholders of the form `{INTEGER}`, e.g. `{0}` is the zeroth parameter.

AnalysisOptionsErrorCode:
  INCLUDED_FILE_PARSE_ERROR:
    problemMessage: "{3} in {0}({1}..{2})"
    comment: |-
      An error code indicating that there is a syntactic error in the included
      file.

      Parameters:
      0: the path of the file containing the error
      1: the starting offset of the text in the file that contains the error
      2: the ending offset of the text in the file that contains the error
      3: the error message
  PARSE_ERROR:
    problemMessage: "{0}"
    comment: |-
      An error code indicating that there is a syntactic error in the file.

      Parameters:
      0: the error message from the parse error
AnalysisOptionsHintCode:
  PREVIEW_DART_2_SETTING_DEPRECATED:
    problemMessage: "The 'enablePreviewDart2' setting is deprecated."
    correctionMessage: It is no longer necessary to explicitly enable Dart 2.
    comment: |-
      An error code indicating that the enablePreviewDart2 setting is
      deprecated.
  STRONG_MODE_SETTING_DEPRECATED:
    problemMessage: "The 'strong-mode: true' setting is deprecated."
    correctionMessage: It is no longer necessary to explicitly enable strong mode.
    comment: "An error code indicating that strong-mode: true is deprecated."
  SUPER_MIXINS_SETTING_DEPRECATED:
    problemMessage: "The 'enableSuperMixins' setting is deprecated."
    correctionMessage: "Support has been added to the language for 'mixin' based mixins."
    comment: |-
      An error code indicating that the enablePreviewDart2 setting is
      deprecated.
AnalysisOptionsWarningCode:
  ANALYSIS_OPTION_DEPRECATED:
    problemMessage: "The option '{0}' is no longer supported."
    comment: An error code indicating that the given option is deprecated.
  INCLUDED_FILE_WARNING:
    problemMessage: "Warning in the included options file {0}({1}..{2}): {3}"
    comment: |-
      An error code indicating a specified include file has a warning.

      Parameters:
      0: the path of the file containing the warnings
      1: the starting offset of the text in the file that contains the warning
      2: the ending offset of the text in the file that contains the warning
      3: the warning message
  INCLUDE_FILE_NOT_FOUND:
    problemMessage: "The include file '{0}' in '{1}' can't be found when analyzing '{2}'."
    comment: |-
      An error code indicating a specified include file could not be found.

      Parameters:
      0: the uri of the file to be included
      1: the path of the file containing the include directive
      2: the path of the context being analyzed
  INVALID_OPTION:
    problemMessage: "Invalid option specified for '{0}': {1}"
    comment: |-
      An error code indicating that a plugin is being configured with an invalid
      value for an option and a detail message is provided.
  INVALID_SECTION_FORMAT:
    problemMessage: "Invalid format for the '{0}' section."
    comment: |-
      An error code indicating an invalid format for an options file section.

      Parameters:
      0: the section name
  SPEC_MODE_REMOVED:
    problemMessage: "The option 'strong-mode: false' is no longer supported."
    correctionMessage: "It's recommended to remove the 'strong-mode:' setting (and make your code Dart 2 compliant)."
    comment: "An error code indicating that strong-mode: false is has been removed."
  UNRECOGNIZED_ERROR_CODE:
    problemMessage: "'{0}' isn't a recognized error code."
    comment: |-
      An error code indicating that an unrecognized error code is being used to
      specify an error filter.

      Parameters:
      0: the unrecognized error code
  UNSUPPORTED_OPTION_WITHOUT_VALUES:
    problemMessage: "The option '{1}' isn't supported by '{0}'."
    comment: |-
      An error code indicating that a plugin is being configured with an
      unsupported option and legal options are provided.

      Parameters:
      0: the plugin name
      1: the unsupported option key
  UNSUPPORTED_OPTION_WITH_LEGAL_VALUE:
    problemMessage: "The option '{1}' isn't supported by '{0}'. Try using the only supported option: '{2}'."
    comment: |-
      An error code indicating that a plugin is being configured with an
      unsupported option where there is just one legal value.

      Parameters:
      0: the plugin name
      1: the unsupported option key
      2: the legal value
  UNSUPPORTED_OPTION_WITH_LEGAL_VALUES:
    problemMessage: "The option '{1}' isn't supported by '{0}'."
    correctionMessage: "Try using one of the supported options: {2}."
    comment: |-
      An error code indicating that a plugin is being configured with an
      unsupported option and legal options are provided.

      Parameters:
      0: the plugin name
      1: the unsupported option key
      2: legal values
  UNSUPPORTED_VALUE:
    problemMessage: "The value '{1}' isn't supported by '{0}'."
    correctionMessage: "Try using one of the supported options: {2}."
    comment: |-
      An error code indicating that an option entry is being configured with an
      unsupported value.

      Parameters:
      0: the option name
      1: the unsupported value
      2: legal values
CompileTimeErrorCode:
  ABSTRACT_FIELD_CONSTRUCTOR_INITIALIZER:
    sharedName: ABSTRACT_FIELD_INITIALIZER
    problemMessage: "Abstract fields can't have initializers."
    correctionMessage: "Try removing the field initializer or the 'abstract' keyword from the field declaration."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field that has the `abstract`
      modifier also has an initializer.

      #### Examples

      The following code produces this diagnostic because `f` is marked as
      `abstract` and has an initializer:

      ```dart
      abstract class C {
        abstract int [!f!] = 0;
      }
      ```

      The following code produces this diagnostic because `f` is marked as
      `abstract` and there's an initializer in the constructor:

      ```dart
      abstract class C {
        abstract int f;

        C() : [!f!] = 0;
      }
      ```

      #### Common fixes

      If the field must be abstract, then remove the initializer:

      ```dart
      abstract class C {
        abstract int f;
      }
      ```

      If the field isn't required to be abstract, then remove the keyword:

      ```dart
      abstract class C {
        int f = 0;
      }
      ```
  ABSTRACT_FIELD_INITIALIZER:
    problemMessage: "Abstract fields can't have initializers."
    correctionMessage: "Try removing the initializer or the 'abstract' keyword."
    hasPublishedDocs: true
    comment: No parameters.
  ABSTRACT_SUPER_MEMBER_REFERENCE:
    problemMessage: "The {0} '{1}' is always abstract in the supertype."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the display name for the kind of the found abstract member
      1: the name of the member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an inherited member is
      referenced using `super`, but there is no concrete implementation of the
      member in the superclass chain. Abstract members can't be invoked.

      #### Example

      The following code produces this diagnostic because `B` doesn't inherit a
      concrete implementation of `a`:

      ```dart
      abstract class A {
        int get a;
      }
      class B extends A {
        int get a => super.[!a!];
      }
      ```

      #### Common fixes

      Remove the invocation of the abstract member, possibly replacing it with an
      invocation of a concrete member.
      TODO(brianwilkerson) This either needs to be generalized (use 'member'
       rather than '{0}') or split into multiple codes.
  AMBIGUOUS_EXPORT:
    problemMessage: "The name '{0}' is defined in the libraries '{1}' and '{2}'."
    correctionMessage: Try removing the export of one of the libraries, or explicitly hiding the name in one of the export directives.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the ambiguous element
      1: the name of the first library in which the type is found
      2: the name of the second library in which the type is found
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when two or more export directives
      cause the same name to be exported from multiple libraries.

      #### Example

      Given a file named `a.dart` containing

      ```dart
      %uri="lib/a.dart"
      class C {}
      ```

      And a file named `b.dart` containing

      ```dart
      %uri="lib/b.dart"
      class C {}
      ```

      The following code produces this diagnostic because the name `C` is being
      exported from both `a.dart` and `b.dart`:

      ```dart
      export 'a.dart';
      export [!'b.dart'!];
      ```

      #### Common fixes

      If none of the names in one of the libraries needs to be exported, then
      remove the unnecessary export directives:

      ```dart
      export 'a.dart';
      ```

      If all of the export directives are needed, then hide the name in all
      except one of the directives:

      ```dart
      export 'a.dart';
      export 'b.dart' hide C;
      ```
  AMBIGUOUS_EXTENSION_MEMBER_ACCESS:
    problemMessage: "A member named '{0}' is defined in {1}, and none are more specific."
    correctionMessage: Try using an extension override to specify the extension you want to be chosen.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
      1: the names of the declaring extensions
    documentation: |-
      #### Description

      When code refers to a member of an object (for example, `o.m()` or `o.m` or
      `o[i]`) where the static type of `o` doesn't declare the member (`m` or
      `[]`, for example), then the analyzer tries to find the member in an
      extension. For example, if the member is `m`, then the analyzer looks for
      extensions that declare a member named `m` and have an extended type that
      the static type of `o` can be assigned to. When there's more than one such
      extension in scope, the extension whose extended type is most specific is
      selected.

      The analyzer produces this diagnostic when none of the extensions has an
      extended type that's more specific than the extended types of all of the
      other extensions, making the reference to the member ambiguous.

      #### Example

      The following code produces this diagnostic because there's no way to
      choose between the member in `E1` and the member in `E2`:

      ```dart
      extension E1 on String {
        int get charCount => 1;
      }

      extension E2 on String {
        int get charCount => 2;
      }

      void f(String s) {
        print(s.[!charCount!]);
      }
      ```

      #### Common fixes

      If you don't need both extensions, then you can delete or hide one of them.

      If you need both, then explicitly select the one you want to use by using
      an extension override:

      ```dart
      extension E1 on String {
        int get charCount => length;
      }

      extension E2 on String {
        int get charCount => length;
      }

      void f(String s) {
        print(E2(s).charCount);
      }
      ```
  AMBIGUOUS_IMPORT:
    problemMessage: "The name '{0}' is defined in the libraries {1}."
    correctionMessage: "Try using 'as prefix' for one of the import directives, or hiding the name from all but one of the imports."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the ambiguous type
      1: the name of the first library that the type is found
      2: the name of the second library that the type is found
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name is referenced that is
      declared in two or more imported libraries.

      #### Example

      Given a library (`a.dart`) that defines a class (`C` in this example):

      ```dart
      %uri="lib/a.dart"
      class A {}
      class C {}
      ```

      And a library (`b.dart`) that defines a different class with the same name:

      ```dart
      %uri="lib/b.dart"
      class B {}
      class C {}
      ```

      The following code produces this diagnostic:

      ```dart
      import 'a.dart';
      import 'b.dart';

      void f([!C!] c1, [!C!] c2) {}
      ```

      #### Common fixes

      If any of the libraries aren't needed, then remove the import directives
      for them:

      ```dart
      import 'a.dart';

      void f(C c1, C c2) {}
      ```

      If the name is still defined by more than one library, then add a `hide`
      clause to the import directives for all except one library:

      ```dart
      import 'a.dart' hide C;
      import 'b.dart';

      void f(C c1, C c2) {}
      ```

      If you must be able to reference more than one of these types, then add a
      prefix to each of the import directives, and qualify the references with
      the appropriate prefix:

      ```dart
      import 'a.dart' as a;
      import 'b.dart' as b;

      void f(a.C c1, b.C c2) {}
      ```
  AMBIGUOUS_SET_OR_MAP_LITERAL_BOTH:
    problemMessage: "The literal can't be either a map or a set because it contains at least one literal map entry or a spread operator spreading a 'Map', and at least one element which is neither of these."
    correctionMessage: Try removing or changing some of the elements so that all of the elements are consistent.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      Because map and set literals use the same delimiters (`{` and `}`), the
      analyzer looks at the type arguments and the elements to determine which
      kind of literal you meant. When there are no type arguments, then the
      analyzer uses the types of the elements. If all of the elements are literal
      map entries and all of the spread operators are spreading a `Map` then it's
      a `Map`. If none of the elements are literal map entries and all of the
      spread operators are spreading an `Iterable`, then it's a `Set`. If neither
      of those is true then it's ambiguous.

      The analyzer produces this diagnostic when at least one element is a
      literal map entry or a spread operator spreading a `Map`, and at least one
      element is neither of these, making it impossible for the analyzer to
      determine whether you are writing a map literal or a set literal.

      #### Example

      The following code produces this diagnostic:

      ```dart
      union(Map<String, String> a, List<String> b, Map<String, String> c) =>
          [!{...a, ...b, ...c}!];
      ```

      The list `b` can only be spread into a set, and the maps `a` and `c` can
      only be spread into a map, and the literal can't be both.

      #### Common fixes

      There are two common ways to fix this problem. The first is to remove all
      of the spread elements of one kind or another, so that the elements are
      consistent. In this case, that likely means removing the list and deciding
      what to do about the now unused parameter:

      ```dart
      union(Map<String, String> a, List<String> b, Map<String, String> c) =>
          {...a, ...c};
      ```

      The second fix is to change the elements of one kind into elements that are
      consistent with the other elements. For example, you can add the elements
      of the list as keys that map to themselves:

      ```dart
      union(Map<String, String> a, List<String> b, Map<String, String> c) =>
          {...a, for (String s in b) s: s, ...c};
      ```
  AMBIGUOUS_SET_OR_MAP_LITERAL_EITHER:
    problemMessage: "This literal must be either a map or a set, but the elements don't have enough information for type inference to work."
    correctionMessage: Try adding type arguments to the literal (one for sets, two for maps).
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      Because map and set literals use the same delimiters (`{` and `}`), the
      analyzer looks at the type arguments and the elements to determine which
      kind of literal you meant. When there are no type arguments and all of the
      elements are spread elements (which are allowed in both kinds of literals)
      then the analyzer uses the types of the expressions that are being spread.
      If all of the expressions have the type `Iterable`, then it's a set
      literal; if they all have the type `Map`, then it's a map literal.

      This diagnostic is produced when none of the expressions being spread have
      a type that allows the analyzer to decide whether you were writing a map
      literal or a set literal.

      #### Example

      The following code produces this diagnostic:

      ```dart
      union(a, b) => [!{...a, ...b}!];
      ```

      The problem occurs because there are no type arguments, and there is no
      information about the type of either `a` or `b`.

      #### Common fixes

      There are three common ways to fix this problem. The first is to add type
      arguments to the literal. For example, if the literal is intended to be a
      map literal, you might write something like this:

      ```dart
      union(a, b) => <String, String>{...a, ...b};
      ```

      The second fix is to add type information so that the expressions have
      either the type `Iterable` or the type `Map`. You can add an explicit cast
      or, in this case, add types to the declarations of the two parameters:

      ```dart
      union(List<int> a, List<int> b) => {...a, ...b};
      ```

      The third fix is to add context information. In this case, that means
      adding a return type to the function:

      ```dart
      Set<String> union(a, b) => {...a, ...b};
      ```

      In other cases, you might add a type somewhere else. For example, say the
      original code looks like this:

      ```dart
      union(a, b) {
        var x = [!{...a, ...b}!];
        return x;
      }
      ```

      You might add a type annotation on `x`, like this:

      ```dart
      union(a, b) {
        Map<String, String> x = {...a, ...b};
        return x;
      }
      ```
  ARGUMENT_TYPE_NOT_ASSIGNABLE:
    problemMessage: "The argument type '{0}' can't be assigned to the parameter type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the actual argument type
      1: the name of the expected type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the static type of an argument
      can't be assigned to the static type of the corresponding parameter.

      #### Example

      The following code produces this diagnostic because a `num` can't be
      assigned to a `String`:

      ```dart
      %language=2.9
      String f(String x) => x;
      String g(num y) => f([!y!]);
      ```

      #### Common fixes

      If possible, rewrite the code so that the static type is assignable. In the
      example above you might be able to change the type of the parameter `y`:

      ```dart
      %language=2.9
      String f(String x) => x;
      String g(String y) => f(y);
      ```

      If that fix isn't possible, then add code to handle the case where the
      argument value isn't the required type. One approach is to coerce other
      types to the required type:

      ```dart
      %language=2.9
      String f(String x) => x;
      String g(num y) => f(y.toString());
      ```

      Another approach is to add explicit type tests and fallback code:

      ```dart
      %language=2.9
      String f(String x) => x;
      String g(num y) => f(y is String ? y : '');
      ```

      If you believe that the runtime type of the argument will always be the
      same as the static type of the parameter, and you're willing to risk having
      an exception thrown at runtime if you're wrong, then add an explicit cast:

      ```dart
      String f(String x) => x;
      String g(num y) => f(y as String);
      ```
  ASSERT_IN_REDIRECTING_CONSTRUCTOR:
    problemMessage: "A redirecting constructor can't have an 'assert' initializer."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a redirecting constructor (a
      constructor that redirects to another constructor in the same class) has an
      assert in the initializer list.

      #### Example

      The following code produces this diagnostic because the unnamed constructor
      is a redirecting constructor and also has an assert in the initializer
      list:

      ```dart
      class C {
        C(int x) : [!assert(x > 0)!], this.name();
        C.name() {}
      }
      ```

      #### Common fixes

      If the assert isn't needed, then remove it:

      ```dart
      class C {
        C(int x) : this.name();
        C.name() {}
      }
      ```

      If the assert is needed, then convert the constructor into a factory
      constructor:

      ```dart
      class C {
        factory C(int x) {
          assert(x > 0);
          return C.name();
        }
        C.name() {}
      }
      ```
  ASSIGNMENT_TO_CONST:
    problemMessage: "Constant variables can't be assigned a value."
    correctionMessage: "Try removing the assignment, or remove the modifier 'const' from the variable."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an assignment to a
      top-level variable, a static field, or a local variable that has the
      `const` modifier. The value of a compile-time constant can't be changed at
      runtime.

      #### Example

      The following code produces this diagnostic because `c` is being assigned a
      value even though it has the `const` modifier:

      ```dart
      const c = 0;

      void f() {
        [!c!] = 1;
        print(c);
      }
      ```

      #### Common fixes

      If the variable must be assignable, then remove the `const` modifier:

      ```dart
      var c = 0;

      void f() {
        c = 1;
        print(c);
      }
      ```

      If the constant shouldn't be changed, then either remove the assignment or
      use a local variable in place of references to the constant:

      ```dart
      const c = 0;

      void f() {
        var v = 1;
        print(v);
      }
      ```
  ASSIGNMENT_TO_FINAL:
    problemMessage: "'{0}' can't be used as a setter because it's final."
    correctionMessage: "Try finding a different setter, or making '{0}' non-final."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the final variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an invocation of a
      setter, but there's no setter because the field with the same name was
      declared to be `final` or `const`.

      #### Example

      The following code produces this diagnostic because `v` is final:

      ```dart
      class C {
        final v = 0;
      }

      f(C c) {
        c.[!v!] = 1;
      }
      ```

      #### Common fixes

      If you need to be able to set the value of the field, then remove the
      modifier `final` from the field:

      ```dart
      class C {
        int v = 0;
      }

      f(C c) {
        c.v = 1;
      }
      ```
  ASSIGNMENT_TO_FINAL_LOCAL:
    problemMessage: "The final variable '{0}' can only be set once."
    correctionMessage: "Try making '{0}' non-final."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a local variable that was
      declared to be final is assigned after it was initialized.

      #### Example

      The following code produces this diagnostic because `x` is final, so it
      can't have a value assigned to it after it was initialized:

      ```dart
      void f() {
        final x = 0;
        [!x!] = 3;
        print(x);
      }
      ```

      #### Common fixes

      Remove the keyword `final`, and replace it with `var` if there's no type
      annotation:

      ```dart
      void f() {
        var x = 0;
        x = 3;
        print(x);
      }
      ```
  ASSIGNMENT_TO_FINAL_NO_SETTER:
    problemMessage: "There isn’t a setter named '{0}' in class '{1}'."
    correctionMessage: Try correcting the name to reference an existing setter, or declare the setter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a reference to a setter is
      found; there is no setter defined for the type; but there is a getter
      defined with the same name.

      #### Example

      The following code produces this diagnostic because there is no setter
      named `x` in `C`, but there is a getter named `x`:

      ```dart
      class C {
        int get x => 0;
        set y(int p) {}
      }

      void f(C c) {
        c.[!x!] = 1;
      }
      ```

      #### Common fixes

      If you want to invoke an existing setter, then correct the name:

      ```dart
      class C {
        int get x => 0;
        set y(int p) {}
      }

      void f(C c) {
        c.y = 1;
      }
      ```

      If you want to invoke the setter but it just doesn't exist yet, then
      declare it:

      ```dart
      class C {
        int get x => 0;
        set x(int p) {}
        set y(int p) {}
      }

      void f(C c) {
        c.x = 1;
      }
      ```
  ASSIGNMENT_TO_FUNCTION:
    problemMessage: "Functions can't be assigned a value."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name of a function appears
      on the left-hand side of an assignment expression.

      #### Example

      The following code produces this diagnostic because the assignment to the
      function `f` is invalid:

      ```dart
      void f() {}

      void g() {
        [!f!] = () {};
      }
      ```

      #### Common fixes

      If the right-hand side should be assigned to something else, such as a
      local variable, then change the left-hand side:

      ```dart
      void f() {}

      void g() {
        var x = () {};
        print(x);
      }
      ```

      If the intent is to change the implementation of the function, then define
      a function-valued variable instead of a function:

      ```dart
      void Function() f = () {};

      void g() {
        f = () {};
      }
      ```
  ASSIGNMENT_TO_METHOD:
    problemMessage: "Methods can't be assigned a value."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the target of an assignment is a
      method.

      #### Example

      The following code produces this diagnostic because `f` can't be assigned a
      value because it's a method:

      ```dart
      class C {
        void f() {}

        void g() {
          [!f!] = null;
        }
      }
      ```

      #### Common fixes

      Rewrite the code so that there isn't an assignment to a method.
  ASSIGNMENT_TO_TYPE:
    problemMessage: "Types can't be assigned a value."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name of a type name appears
      on the left-hand side of an assignment expression.

      #### Example

      The following code produces this diagnostic because the assignment to the
      class `C` is invalid:

      ```dart
      class C {}

      void f() {
        [!C!] = null;
      }
      ```

      #### Common fixes

      If the right-hand side should be assigned to something else, such as a
      local variable, then change the left-hand side:

      ```dart
      void f() {}

      void g() {
        var c = null;
        print(c);
      }
      ```
  ASYNC_FOR_IN_WRONG_CONTEXT:
    problemMessage: The async for-in loop can only be used in an async function.
    correctionMessage: "Try marking the function body with either 'async' or 'async*', or removing the 'await' before the for-in loop."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an async for-in loop is found in
      a function or method whose body isn't marked as being either `async` or
      `async*`.

      #### Example

      The following code produces this diagnostic because the body of `f` isn't
      marked as being either `async` or `async*`, but `f` contains an async
      for-in loop:

      ```dart
      void f(list) {
        await for (var e [!in!] list) {
          print(e);
        }
      }
      ```

      #### Common fixes

      If the function should return a `Future`, then mark the body with `async`:

      ```dart
      Future<void> f(list) async {
        await for (var e in list) {
          print(e);
        }
      }
      ```

      If the function should return a `Stream` of values, then mark the body with
      `async*`:

      ```dart
      Stream<void> f(list) async* {
        await for (var e in list) {
          print(e);
        }
      }
      ```

      If the function should be synchronous, then remove the `await` before the
      loop:

      ```dart
      void f(list) {
        for (var e in list) {
          print(e);
        }
      }
      ```
  AWAIT_IN_LATE_LOCAL_VARIABLE_INITIALIZER:
    problemMessage: "The 'await' expression can't be used in a 'late' local variable's initializer."
    correctionMessage: "Try removing the 'late' modifier, or rewriting the initializer without using the 'await' expression."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a local variable that has the
      `late` modifier uses an `await` expression in the initializer.

      #### Example

      The following code produces this diagnostic because an `await` expression
      is used in the initializer for `v`, a local variable that is marked `late`:

      ```dart
      Future<int> f() async {
        late var v = [!await!] 42;
        return v;
      }
      ```

      #### Common fixes

      If the initializer can be rewritten to not use `await`, then rewrite it:

      ```dart
      Future<int> f() async {
        late var v = 42;
        return v;
      }
      ```

      If the initializer can't be rewritten, then remove the `late` modifier:

      ```dart
      Future<int> f() async {
        var v = await 42;
        return v;
      }
      ```
  AWAIT_IN_WRONG_CONTEXT:
    problemMessage: The await expression can only be used in an async function.
    correctionMessage: "Try marking the function body with either 'async' or 'async*'."
    comment: |-
      16.30 Await Expressions: It is a compile-time error if the function
      immediately enclosing _a_ is not declared asynchronous. (Where _a_ is the
      await expression.)
  BODY_MIGHT_COMPLETE_NORMALLY:
    problemMessage: "The body might complete normally, causing 'null' to be returned, but the return type, '{0}', is a potentially non-nullable type."
    correctionMessage: Try adding either a return or a throw statement at the end.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function has a
      return type that's [potentially non-nullable][] but would implicitly return
      `null` if control reached the end of the function.

      #### Examples

      The following code produces this diagnostic because the method `m` has an
      implicit return of `null` inserted at the end of the method, but the method
      is declared to not return `null`:

      ```dart
      class C {
        int [!m!](int t) {
          print(t);
        }
      }
      ```

      The following code produces this diagnostic because the method `m` has an
      implicit return of `null` inserted at the end of the method, but because
      the class `C` can be instantiated with a non-nullable type argument, the
      method is effectively declared to not return `null`:

      ```dart
      class C<T> {
        T [!m!](T t) {
          print(t);
        }
      }
      ```

      #### Common fixes

      If there's a reasonable value that can be returned, then add a `return`
      statement at the end of the method:

      ```dart
      class C<T> {
        T m(T t) {
          print(t);
          return t;
        }
      }
      ```

      If the method won't reach the implicit return, then add a `throw` at the
      end of the method:

      ```dart
      class C<T> {
        T m(T t) {
          print(t);
          throw '';
        }
      }
      ```

      If the method intentionally returns `null` at the end, then add an
      explicit return of `null` at the end of the method and change the
      return type so that it's valid to return `null`:

      ```dart
      class C<T> {
        T? m(T t) {
          print(t);
          return null;
        }
      }
      ```
  BREAK_LABEL_ON_SWITCH_MEMBER:
    problemMessage: "A break label resolves to the 'case' or 'default' statement."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a break in a case clause inside
      a switch statement has a label that is associated with another case clause.

      #### Example

      The following code produces this diagnostic because the label `l` is
      associated with the case clause for `0`:

      ```dart
      void f(int i) {
        switch (i) {
          l: case 0:
            break;
          case 1:
            break [!l!];
        }
      }
      ```

      #### Common fixes

      If the intent is to transfer control to the statement after the switch,
      then remove the label from the break statement:

      ```dart
      void f(int i) {
        switch (i) {
          case 0:
            break;
          case 1:
            break;
        }
      }
      ```

      If the intent is to transfer control to a different case block, then use
      `continue` rather than `break`:

      ```dart
      void f(int i) {
        switch (i) {
          l: case 0:
            break;
          case 1:
            continue l;
        }
      }
      ```
  BUILT_IN_IDENTIFIER_AS_TYPE:
    problemMessage: "The built-in identifier '{0}' can't be used as a type."
    correctionMessage: Try correcting the name to match an existing type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a built-in identifier is used
      where a type name is expected.

      #### Example

      The following code produces this diagnostic because `import` can't be used
      as a type because it's a built-in identifier:

      ```dart
      [!import!]<int> x;
      ```

      #### Common fixes

      Replace the built-in identifier with the name of a valid type:

      ```dart
      List<int> x;
      ```
  BUILT_IN_IDENTIFIER_AS_EXTENSION_NAME:
    sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
    problemMessage: "The built-in identifier '{0}' can't be used as an extension name."
    correctionMessage: Try choosing a different name for the extension.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name used in the declaration
      of a class, extension, mixin, typedef, type parameter, or import prefix is
      a built-in identifier. Built-in identifiers can’t be used to name any of
      these kinds of declarations.

      #### Example

      The following code produces this diagnostic because `mixin` is a built-in
      identifier:

      ```dart
      extension [!mixin!] on int {}
      ```

      #### Common fixes

      Choose a different name for the declaration.
  BUILT_IN_IDENTIFIER_AS_PREFIX_NAME:
    sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
    problemMessage: "The built-in identifier '{0}' can't be used as a prefix name."
    correctionMessage: Try choosing a different name for the prefix.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
  BUILT_IN_IDENTIFIER_AS_TYPE_NAME:
    sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
    problemMessage: "The built-in identifier '{0}' can't be used as a type name."
    correctionMessage: Try choosing a different name for the type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
  BUILT_IN_IDENTIFIER_AS_TYPE_PARAMETER_NAME:
    sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
    problemMessage: "The built-in identifier '{0}' can't be used as a type parameter name."
    correctionMessage: Try choosing a different name for the type parameter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
  BUILT_IN_IDENTIFIER_AS_TYPEDEF_NAME:
    sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
    problemMessage: "The built-in identifier '{0}' can't be used as a typedef name."
    correctionMessage: Try choosing a different name for the typedef.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the built-in identifier that is being used
  CASE_BLOCK_NOT_TERMINATED:
    problemMessage: "The last statement of the 'case' should be 'break', 'continue', 'rethrow', 'return', or 'throw'."
    correctionMessage: Try adding one of the required statements.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the last statement in a `case`
      block isn't one of the required terminators: `break`, `continue`,
      `rethrow`, `return`, or `throw`.

      #### Example

      The following code produces this diagnostic because the `case` block ends
      with an assignment:

      ```dart
      %language=2.9
      void f(int x) {
        switch (x) {
          [!case!] 0:
            x += 2;
          default:
            x += 1;
        }
      }
      ```

      #### Common fixes

      Add one of the required terminators:

      ```dart
      %language=2.9
      void f(int x) {
        switch (x) {
          case 0:
            x += 2;
            break;
          default:
            x += 1;
        }
      }
      ```
  CASE_EXPRESSION_TYPE_IMPLEMENTS_EQUALS:
    problemMessage: "The switch case expression type '{0}' can't override the '==' operator."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the this of the switch case expression
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of the expression
      following the keyword `case` has an implementation of the `==` operator
      other than the one in `Object`.

      #### Example

      The following code produces this diagnostic because the expression
      following the keyword `case` (`C(0)`) has the type `C`, and the class `C`
      overrides the `==` operator:

      ```dart
      class C {
        final int value;

        const C(this.value);

        bool operator ==(Object other) {
          return false;
        }
      }

      void f(C c) {
        switch (c) {
          case [!C(0)!]:
            break;
        }
      }
      ```

      #### Common fixes

      If there isn't a strong reason not to do so, then rewrite the code to use
      an if-else structure:

      ```dart
      class C {
        final int value;

        const C(this.value);

        bool operator ==(Object other) {
          return false;
        }
      }

      void f(C c) {
        if (c == C(0)) {
          // ...
        }
      }
      ```

      If you can't rewrite the switch statement and the implementation of `==`
      isn't necessary, then remove it:

      ```dart
      class C {
        final int value;

        const C(this.value);
      }

      void f(C c) {
        switch (c) {
          case C(0):
            break;
        }
      }
      ```

      If you can't rewrite the switch statement and you can't remove the
      definition of `==`, then find some other value that can be used to control
      the switch:

      ```dart
      class C {
        final int value;

        const C(this.value);

        bool operator ==(Object other) {
          return false;
        }
      }

      void f(C c) {
        switch (c.value) {
          case 0:
            break;
        }
      }
      ```
  CASE_EXPRESSION_TYPE_IS_NOT_SWITCH_EXPRESSION_SUBTYPE:
    problemMessage: "The switch case expression type '{0}' must be a subtype of the switch expression type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the case expression
      1: the type of the switch expression
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression following `case`
      in a `switch` statement has a static type that isn't a subtype of the
      static type of the expression following `switch`.

      #### Example

      The following code produces this diagnostic because `1` is an `int`, which
      isn't a subtype of `String` (the type of `s`):

      ```dart
      void f(String s) {
        switch (s) {
          case [!1!]:
            break;
        }
      }
      ```

      #### Common fixes

      If the value of the `case` expression is wrong, then change the `case`
      expression so that it has the required type:

      ```dart
      void f(String s) {
        switch (s) {
          case '1':
            break;
        }
      }
      ```

      If the value of the `case` expression is correct, then change the `switch`
      expression to have the required type:

      ```dart
      void f(int s) {
        switch (s) {
          case 1:
            break;
        }
      }
      ```
  CAST_TO_NON_TYPE:
    problemMessage: "The name '{0}' isn't a type, so it can't be used in an 'as' expression."
    correctionMessage: "Try changing the name to the name of an existing type, or creating a type with the name '{0}'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name following the `as` in a
      cast expression is defined to be something other than a type.

      #### Example

      The following code produces this diagnostic because `x` is a variable, not
      a type:

      ```dart
      num x = 0;
      int y = x as [!x!];
      ```

      #### Common fixes

      Replace the name with the name of a type:

      ```dart
      num x = 0;
      int y = x as int;
      ```
  CLASS_INSTANTIATION_ACCESS_TO_INSTANCE_MEMBER:
    sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
    problemMessage: "The instance member '{0}' can't be accessed on a class instantiation."
    correctionMessage: Try changing the member name to the name of a constructor.
    comment: |-
      Parameters:
      0: the name of the member
  CLASS_INSTANTIATION_ACCESS_TO_UNKNOWN_MEMBER:
    sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
    problemMessage: "The class '{0} doesn't have a constructor named '{1}."
    correctionMessage: "Try invoking a different constructor, or defining a constructor named '{1}'."
    comment: |-
      Parameters:
      0: the name of the member
  CLASS_INSTANTIATION_ACCESS_TO_STATIC_MEMBER:
    sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
    problemMessage: "The static member '{0}' can't be accessed on a class instantiation."
    correctionMessage: Try removing the type arguments from the class name, or changing the member name to the name of a constructor.
    comment: |-
      Parameters:
      0: the name of the member
  NON_CONST_GENERATIVE_ENUM_CONSTRUCTOR:
    problemMessage: Generative enum constructors must be 'const'.
    correctionMessage: Try adding the keyword 'const'.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an enum declaration contains a
      generative constructor that isn't marked as `const`.
      
      #### Example
      
      The following code produces this diagnostic because the constructor in `E`
      isn't marked as being `const`:
      
      ```dart
      enum E {
        e;
      
        [!E!]();
      }
      ```
      
      #### Common fixes
      
      Add the `const` keyword before the constructor:
      
      ```dart
      enum E {
        e;
      
        const E();
      }
      ```
  NON_CONSTANT_MAP_KEY_FROM_DEFERRED_LIBRARY:
    sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
    problemMessage: "Constant values from a deferred library can't be used as keys in a 'const' map literal."
    correctionMessage: "Try removing the keyword 'const' from the map literal or removing the keyword 'deferred' from the import."
    hasPublishedDocs: true
    comment: No parameters.
  NON_CONSTANT_LIST_ELEMENT_FROM_DEFERRED_LIBRARY:
    sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
    problemMessage: "Constant values from a deferred library can't be used as values in a 'const' list literal."
    correctionMessage: "Try removing the keyword 'const' from the list literal or removing the keyword 'deferred' from the import."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a collection literal that is
      either explicitly (because it's prefixed by the `const` keyword) or
      implicitly (because it appears in a [constant context][]) a constant
      contains a value that is declared in a library that is imported using a
      deferred import. Constants are evaluated at compile time, and values from
      deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines the constant `zero`:

      ```dart
      %uri="lib/a.dart"
      const zero = 0;
      ```

      The following code produces this diagnostic because the constant list
      literal contains `a.zero`, which is imported using a `deferred` import:

      ```dart
      import 'a.dart' deferred as a;

      var l = const [[!a.zero!]];
      ```

      #### Common fixes

      If the collection literal isn't required to be constant, then remove the
      `const` keyword:

      ```dart
      import 'a.dart' deferred as a;

      var l = [a.zero];
      ```

      If the collection is required to be constant and the imported constant must
      be referenced, then remove the keyword `deferred` from the import:

      ```dart
      import 'a.dart' as a;

      var l = const [a.zero];
      ```

      If you don't need to reference the constant, then replace it with a
      suitable value:

      ```dart
      var l = const [0];
      ```
  SET_ELEMENT_FROM_DEFERRED_LIBRARY:
    sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
    problemMessage: "Constant values from a deferred library can't be used as values in a 'const' set literal."
    correctionMessage: "Try removing the keyword 'const' from the set literal or removing the keyword 'deferred' from the import."
    hasPublishedDocs: true
    comment: No parameters.
  NON_CONSTANT_MAP_VALUE_FROM_DEFERRED_LIBRARY:
    sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
    problemMessage: "Constant values from a deferred library can't be used as values in a 'const' map literal."
    correctionMessage: "Try removing the keyword 'const' from the map literal or removing the keyword 'deferred' from the import."
    hasPublishedDocs: true
    comment: No parameters.
  CONCRETE_CLASS_HAS_ENUM_SUPERINTERFACE:
    problemMessage: "Concrete classes can't have 'Enum' as a superinterface."
    correctionMessage: Try specifying a different interface, or remove it from the list.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a concrete class indirectly has
      the class `Enum` as a superinterface.
      
      #### Example
      
      The following code produces this diagnostic because the concrete class `B`
      has `Enum` as a superinterface as a result of implementing `A`:
      
      ```dart
      abstract class A implements Enum {}
      
      class [!B!] implements A {}
      ```
      
      #### Common fixes
      
      If the implemented class isn't the class you intend to implement, then
      change it:
      
      ```dart
      abstract class A implements Enum {}
      
      class B implements C {}
      
      class C {}
      ```
      
      If the implemented class can be changed to not implement `Enum`, then do
      so:
      
      ```dart
      abstract class A {}
      
      class B implements A {}
      ```
      
      If the implemented class can't be changed to not implement `Enum`, then
      remove it from the `implements` clause:
      
      ```dart
      abstract class A implements Enum {}
      
      class B {}
      ```
  CONCRETE_CLASS_WITH_ABSTRACT_MEMBER:
    problemMessage: "'{0}' must have a method body because '{1}' isn't abstract."
    correctionMessage: "Try making '{1}' abstract, or adding a body to '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the abstract method
      1: the name of the enclosing class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a member of a concrete class is
      found that doesn't have a concrete implementation. Concrete classes aren't
      allowed to contain abstract members.

      #### Example

      The following code produces this diagnostic because `m` is an abstract
      method but `C` isn't an abstract class:

      ```dart
      class C {
        [!void m();!]
      }
      ```

      #### Common fixes

      If it's valid to create instances of the class, provide an implementation
      for the member:

      ```dart
      class C {
        void m() {}
      }
      ```

      If it isn't valid to create instances of the class, mark the class as being
      abstract:

      ```dart
      abstract class C {
        void m();
      }
      ```
  CONFLICTING_CONSTRUCTOR_AND_STATIC_FIELD:
    sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
    problemMessage: "'{0}' can't be used to name both a constructor and a static field in this class."
    correctionMessage: Try renaming either the constructor or the field.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constructor and field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a named constructor and either a
      static method or static field have the same name. Both are accessed using
      the name of the class, so having the same name makes the reference
      ambiguous.

      #### Examples

      The following code produces this diagnostic because the static field `foo`
      and the named constructor `foo` have the same name:

      ```dart
      class C {
        C.[!foo!]();
        static int foo = 0;
      }
      ```

      The following code produces this diagnostic because the static method `foo`
      and the named constructor `foo` have the same name:

      ```dart
      class C {
        C.[!foo!]();
        static void foo() {}
      }
      ```

      #### Common fixes

      Rename either the member or the constructor.
  CONFLICTING_CONSTRUCTOR_AND_STATIC_GETTER:
    sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
    problemMessage: "'{0}' can't be used to name both a constructor and a static getter in this class."
    correctionMessage: Try renaming either the constructor or the getter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constructor and getter
  CONFLICTING_CONSTRUCTOR_AND_STATIC_METHOD:
    sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
    problemMessage: "'{0}' can't be used to name both a constructor and a static method in this class."
    correctionMessage: Try renaming either the constructor or the method.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constructor
  CONFLICTING_CONSTRUCTOR_AND_STATIC_SETTER:
    sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
    problemMessage: "'{0}' can't be used to name both a constructor and a static setter in this class."
    correctionMessage: Try renaming either the constructor or the setter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constructor and setter
  CONFLICTING_FIELD_AND_METHOD:
    problemMessage: "Class '{0}' can't define field '{1}' and have method '{2}.{1}' with the same name."
    correctionMessage: "Try converting the getter to a method, or renaming the field to a name that doesn't conflict."
    comment: |-
      10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
      error if `C` declares a getter or a setter with basename `n`, and has a
      method named `n`.

      Parameters:
      0: the name of the class defining the conflicting field
      1: the name of the conflicting field
      2: the name of the class defining the method with which the field conflicts
  CONFLICTING_GENERIC_INTERFACES:
    problemMessage: "The class '{0}' can't implement both '{1}' and '{2}' because the type arguments are different."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class implementing the conflicting interface
      1: the first conflicting type
      2: the second conflicting type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class attempts to implement a
      generic interface multiple times, and the values of the type arguments
      aren't the same.

      #### Example

      The following code produces this diagnostic because `C` is defined to
      implement both `I<int>` (because it extends `A`) and `I<String>` (because
      it implements`B`), but `int` and `String` aren't the same type:

      ```dart
      class I<T> {}
      class A implements I<int> {}
      class B implements I<String> {}
      class [!C!] extends A implements B {}
      ```

      #### Common fixes

      Rework the type hierarchy to avoid this situation. For example, you might
      make one or both of the inherited types generic so that `C` can specify the
      same type for both type arguments:

      ```dart
      class I<T> {}
      class A<S> implements I<S> {}
      class B implements I<String> {}
      class C extends A<String> implements B {}
      ```
  CONFLICTING_METHOD_AND_FIELD:
    problemMessage: "Class '{0}' can't define method '{1}' and have field '{2}.{1}' with the same name."
    correctionMessage: "Try converting the method to a getter, or renaming the method to a name that doesn't conflict."
    comment: |-
      10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
      error if `C` declares a method named `n`, and has a getter or a setter
      with basename `n`.

      Parameters:
      0: the name of the class defining the conflicting method
      1: the name of the conflicting method
      2: the name of the class defining the field with which the method conflicts
  CONFLICTING_STATIC_AND_INSTANCE:
    problemMessage: "Class '{0}' can't define static member '{1}' and have instance member '{2}.{1}' with the same name."
    correctionMessage: "Try renaming the member to a name that doesn't conflict."
    comment: |-
      10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
      error if `C` declares a static member with basename `n`, and has an
      instance member with basename `n`.

      Parameters:
      0: the name of the class defining the conflicting member
      1: the name of the conflicting static member
      2: the name of the class defining the field with which the method conflicts
  CONFLICTING_TYPE_VARIABLE_AND_CLASS:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
    problemMessage: "'{0}' can't be used to name both a type variable and the class in which the type variable is defined."
    correctionMessage: Try renaming either the type variable or the class.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class, mixin, or extension
      declaration declares a type parameter with the same name as the class,
      mixin, or extension that declares it.

      #### Example

      The following code produces this diagnostic because the type parameter `C`
      has the same name as the class `C` of which it's a part:

      ```dart
      class C<[!C!]> {}
      ```

      #### Common fixes

      Rename either the type parameter, or the class, mixin, or extension:

      ```dart
      class C<T> {}
      ```
  CONFLICTING_TYPE_VARIABLE_AND_ENUM:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
    problemMessage: "'{0}' can't be used to name both a type variable and the enum in which the type variable is defined."
    correctionMessage: Try renaming either the type variable or the enum.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONFLICTING_TYPE_VARIABLE_AND_EXTENSION:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
    problemMessage: "'{0}' can't be used to name both a type variable and the extension in which the type variable is defined."
    correctionMessage: Try renaming either the type variable or the extension.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONFLICTING_TYPE_VARIABLE_AND_MIXIN:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
    problemMessage: "'{0}' can't be used to name both a type variable and the mixin in which the type variable is defined."
    correctionMessage: Try renaming either the type variable or the mixin.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONFLICTING_TYPE_VARIABLE_AND_MEMBER_CLASS:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
    problemMessage: "'{0}' can't be used to name both a type variable and a member in this class."
    correctionMessage: Try renaming either the type variable or the member.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class, mixin, or extension
      declaration declares a type parameter with the same name as one of the
      members of the class, mixin, or extension that declares it.

      #### Example

      The following code produces this diagnostic because the type parameter `T`
      has the same name as the field `T`:

      ```dart
      class C<[!T!]> {
        int T = 0;
      }
      ```

      #### Common fixes

      Rename either the type parameter or the member with which it conflicts:

      ```dart
      class C<T> {
        int total = 0;
      }
      ```
  CONFLICTING_TYPE_VARIABLE_AND_MEMBER_MIXIN:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
    problemMessage: "'{0}' can't be used to name both a type variable and a member in this mixin."
    correctionMessage: Try renaming either the type variable or the member.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONFLICTING_TYPE_VARIABLE_AND_MEMBER_ENUM:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
    problemMessage: "'{0}' can't be used to name both a type variable and a member in this enum."
    correctionMessage: Try renaming either the type variable or the member.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONFLICTING_TYPE_VARIABLE_AND_MEMBER_EXTENSION:
    sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
    problemMessage: "'{0}' can't be used to name both a type variable and a member in this extension."
    correctionMessage: Try renaming either the type variable or the member.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type variable
  CONST_CONSTRUCTOR_FIELD_TYPE_MISMATCH:
    problemMessage: "In a const constructor, a value of type '{0}' can't be assigned to the field '{1}', which has type '{2}'."
    correctionMessage: "Try using a subtype, or removing the keyword 'const'."
    comment: |-
      16.12.2 Const: It is a compile-time error if evaluation of a constant
      object results in an uncaught exception being thrown.
  CONST_CONSTRUCTOR_PARAM_TYPE_MISMATCH:
    problemMessage: "A value of type '{0}' can't be assigned to a parameter of type '{1}' in a const constructor."
    correctionMessage: "Try using a subtype, or removing the keyword 'const'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the runtime value of the argument
      1: the static type of the parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the runtime type of a constant
      value can't be assigned to the static type of a constant constructor's
      parameter.

      #### Example

      The following code produces this diagnostic because the runtime type of `i`
      is `int`, which can't be assigned to the static type of `s`:

      ```dart
      class C {
        final String s;

        const C(this.s);
      }

      const dynamic i = 0;

      void f() {
        const C([!i!]);
      }
      ```

      #### Common fixes

      Pass a value of the correct type to the constructor:

      ```dart
      class C {
        final String s;

        const C(this.s);
      }

      const dynamic i = 0;

      void f() {
        const C('$i');
      }
      ```
  CONST_CONSTRUCTOR_THROWS_EXCEPTION:
    problemMessage: "Const constructors can't throw exceptions."
    correctionMessage: "Try removing the throw statement, or removing the keyword 'const'."
    comment: |-
      16.12.2 Const: It is a compile-time error if evaluation of a constant
      object results in an uncaught exception being thrown.
  CONST_CONSTRUCTOR_WITH_FIELD_INITIALIZED_BY_NON_CONST:
    problemMessage: "Can't define the 'const' constructor because the field '{0}' is initialized with a non-constant value."
    correctionMessage: "Try initializing the field to a constant value, or removing the keyword 'const' from the constructor."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor has the keyword
      `const`, but a field in the class is initialized to a non-constant value.

      #### Example

      The following code produces this diagnostic because the field `s` is
      initialized to a non-constant value:

      ```dart
      class C {
        final String s = 3.toString();
        [!const!] C();
      }
      ```

      #### Common fixes

      If the field can be initialized to a constant value, then change the
      initializer to a constant expression:

      ```dart
      class C {
        final String s = '3';
        const C();
      }
      ```

      If the field can't be initialized to a constant value, then remove the
      keyword `const` from the constructor:

      ```dart
      class C {
        final String s = 3.toString();
        C();
      }
      ```
  CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELD:
    problemMessage: "This constructor can't be declared 'const' because a mixin adds the instance field: {0}."
    correctionMessage: "Try removing the 'const' keyword or removing the 'with' clause from the class declaration, or removing the field from the mixin class."
    comment: |-
      7.6.3 Constant Constructors: The superinitializer that appears, explicitly
      or implicitly, in the initializer list of a constant constructor must
      specify a constant constructor of the superclass of the immediately
      enclosing class or a compile-time error occurs.

      12.1 Mixin Application: For each generative constructor named ... an
      implicitly declared constructor named ... is declared. If Sq is a
      generative const constructor, and M does not declare any fields, Cq is
      also a const constructor.

      Parameters:
      0: the name of the instance field.
  CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELDS:
    sharedName: CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELD
    problemMessage: "This constructor can't be declared 'const' because the mixins add the instance fields: {0}."
    correctionMessage: "Try removing the 'const' keyword or removing the 'with' clause from the class declaration, or removing the fields from the mixin classes."
    comment: |-
      7.6.3 Constant Constructors: The superinitializer that appears, explicitly
      or implicitly, in the initializer list of a constant constructor must
      specify a constant constructor of the superclass of the immediately
      enclosing class or a compile-time error occurs.

      12.1 Mixin Application: For each generative constructor named ... an
      implicitly declared constructor named ... is declared. If Sq is a
      generative const constructor, and M does not declare any fields, Cq is
      also a const constructor.

      Parameters:
      0: the names of the instance fields.
  CONST_CONSTRUCTOR_WITH_NON_CONST_SUPER:
    problemMessage: "A constant constructor can't call a non-constant super constructor of '{0}'."
    correctionMessage: "Try calling a constant constructor in the superclass, or removing the keyword 'const' from the constructor."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the superclass
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor that is marked as
      `const` invokes a constructor from its superclass that isn't marked as
      `const`.

      #### Example

      The following code produces this diagnostic because the `const` constructor
      in `B` invokes the constructor `nonConst` from the class `A`, and the
      superclass constructor isn't a `const` constructor:

      ```dart
      class A {
        const A();
        A.nonConst();
      }

      class B extends A {
        const B() : [!super.nonConst()!];
      }
      ```

      #### Common fixes

      If it isn't essential to invoke the superclass constructor that is
      currently being invoked, then invoke a constant constructor from the
      superclass:

      ```dart
      class A {
        const A();
        A.nonConst();
      }

      class B extends A {
        const B() : super();
      }
      ```

      If it's essential that the current constructor be invoked and if you can
      modify it, then add `const` to the constructor in the superclass:

      ```dart
      class A {
        const A();
        const A.nonConst();
      }

      class B extends A {
        const B() : super.nonConst();
      }
      ```

      If it's essential that the current constructor be invoked and you can't
      modify it, then remove `const` from the constructor in the subclass:

      ```dart
      class A {
        const A();
        A.nonConst();
      }

      class B extends A {
        B() : super.nonConst();
      }
      ```
  CONST_CONSTRUCTOR_WITH_NON_FINAL_FIELD:
    problemMessage: "Can't define a const constructor for a class with non-final fields."
    correctionMessage: "Try making all of the fields final, or removing the keyword 'const' from the constructor."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor is marked as a
      const constructor, but the constructor is defined in a class that has at
      least one non-final instance field (either directly or by inheritance).

      #### Example

      The following code produces this diagnostic because the field `x` isn't
      final:

      ```dart
      class C {
        int x;

        const [!C!](this.x);
      }
      ```

      #### Common fixes

      If it's possible to mark all of the fields as final, then do so:

      ```dart
      class C {
        final int x;

        const C(this.x);
      }
      ```

      If it isn't possible to mark all of the fields as final, then remove the
      keyword `const` from the constructor:

      ```dart
      class C {
        int x;

        C(this.x);
      }
      ```
  CONST_DEFERRED_CLASS:
    problemMessage: "Deferred classes can't be created with 'const'."
    correctionMessage: "Try using 'new' to create the instance, or changing the import to not be deferred."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class from a library that is
      imported using a deferred import is used to create a `const` object.
      Constants are evaluated at compile time, and classes from deferred
      libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      The following code produces this diagnostic because it attempts to create a
      `const` instance of a class from a deferred library:

      ```dart
      import 'dart:convert' deferred as convert;

      const json2 = [!convert.JsonCodec()!];
      ```

      #### Common fixes

      If the object isn't required to be a constant, then change the code so that
      a non-constant instance is created:

      ```dart
      import 'dart:convert' deferred as convert;

      final json2 = convert.JsonCodec();
      ```

      If the object must be a constant, then remove `deferred` from the import
      directive:

      ```dart
      import 'dart:convert' as convert;

      const json2 = convert.JsonCodec();
      ```
  CONST_EVAL_THROWS_EXCEPTION:
    problemMessage: Evaluation of this constant expression throws an exception.
    comment: |-
      16.12.2 Const: It is a compile-time error if evaluation of a constant
      object results in an uncaught exception being thrown.
  CONST_EVAL_THROWS_IDBZE:
    problemMessage: Evaluation of this constant expression throws an IntegerDivisionByZeroException.
    comment: |-
      16.12.2 Const: It is a compile-time error if evaluation of a constant
      object results in an uncaught exception being thrown.
  CONST_EVAL_TYPE_BOOL:
    problemMessage: "In constant expressions, operands of this operator must be of type 'bool'."
    comment: |-
      16.12.2 Const: An expression of one of the forms !e, e1 && e2 or e1 || e2,
      where e, e1 and e2 are constant expressions that evaluate to a boolean
      value.
  CONST_EVAL_TYPE_BOOL_INT:
    problemMessage: "In constant expressions, operands of this operator must be of type 'bool' or 'int'."
    comment: |-
      16.12.2 Const: An expression of one of the forms !e, e1 && e2 or e1 || e2,
      where e, e1 and e2 are constant expressions that evaluate to a boolean
      value.
  CONST_EVAL_TYPE_BOOL_NUM_STRING:
    problemMessage: "In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null'."
    comment: |-
      16.12.2 Const: An expression of one of the forms e1 == e2 or e1 != e2 where
      e1 and e2 are constant expressions that evaluate to a numeric, string or
      boolean value or to null.
  CONST_EVAL_TYPE_INT:
    problemMessage: "In constant expressions, operands of this operator must be of type 'int'."
    comment: |-
      16.12.2 Const: An expression of one of the forms ~e, e1 ^ e2, e1 & e2,
      e1 | e2, e1 >> e2 or e1 << e2, where e, e1 and e2 are constant expressions
      that evaluate to an integer value or to null.
  CONST_EVAL_TYPE_NUM:
    problemMessage: "In constant expressions, operands of this operator must be of type 'num'."
    comment: |-
      16.12.2 Const: An expression of one of the forms e, e1 + e2, e1 - e2, e1
      e2, e1 / e2, e1 ~/ e2, e1 > e2, e1 < e2, e1 >= e2, e1 <= e2 or e1 % e2,
      where e, e1 and e2 are constant expressions that evaluate to a numeric
      value or to null.
  CONST_EVAL_TYPE_TYPE:
    problemMessage: "In constant expressions, operands of this operator must be of type 'Type'."
  CONST_INITIALIZED_WITH_NON_CONSTANT_VALUE:
    problemMessage: Const variables must be initialized with a constant value.
    correctionMessage: Try changing the initializer to be a constant expression.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a value that isn't statically
      known to be a constant is assigned to a variable that's declared to be a
      `const` variable.

      #### Example

      The following code produces this diagnostic because `x` isn't declared to
      be `const`:

      ```dart
      var x = 0;
      const y = [!x!];
      ```

      #### Common fixes

      If the value being assigned can be declared to be `const`, then change the
      declaration:

      ```dart
      const x = 0;
      const y = x;
      ```

      If the value can't be declared to be `const`, then remove the `const`
      modifier from the variable, possibly using `final` in its place:

      ```dart
      var x = 0;
      final y = x;
      ```
  CONST_INITIALIZED_WITH_NON_CONSTANT_VALUE_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used to initialize a 'const' variable."
    correctionMessage: Try initializing the variable without referencing members of the deferred library, or changing the import to not be deferred.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `const` variable is
      initialized using a `const` variable from a library that is imported using
      a deferred import. Constants are evaluated at compile time, and values from
      deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      The following code produces this diagnostic because the variable `pi` is
      being initialized using the constant `math.pi` from the library
      `dart:math`, and `dart:math` is imported as a deferred library:

      ```dart
      import 'dart:math' deferred as math;

      const pi = [!math.pi!];
      ```

      #### Common fixes

      If you need to reference the value of the constant from the imported
      library, then remove the keyword `deferred`:

      ```dart
      import 'dart:math' as math;

      const pi = math.pi;
      ```

      If you don't need to reference the imported constant, then remove the
      reference:

      ```dart
      const pi = 3.14;
      ```
  CONST_INSTANCE_FIELD:
    problemMessage: Only static fields can be declared as const.
    correctionMessage: "Try declaring the field as final, or adding the keyword 'static'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an instance field is marked as
      being const.

      #### Example

      The following code produces this diagnostic because `f` is an instance
      field:

      ```dart
      class C {
        [!const!] int f = 3;
      }
      ```

      #### Common fixes

      If the field needs to be an instance field, then remove the keyword
      `const`, or replace it with `final`:

      ```dart
      class C {
        final int f = 3;
      }
      ```

      If the field really should be a const field, then make it a static field:

      ```dart
      class C {
        static const int f = 3;
      }
      ```
  CONST_MAP_KEY_EXPRESSION_TYPE_IMPLEMENTS_EQUALS:
    problemMessage: "The type of a key in a constant map can't override the '==' operator, but the class '{0}' does."
    correctionMessage: "Try using a different value for the key, or removing the keyword 'const' from the map."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the entry's key
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the class of object used as a
      key in a constant map literal implements the `==` operator. The
      implementation of constant maps uses the `==` operator, so any
      implementation other than the one inherited from `Object` requires
      executing arbitrary code at compile time, which isn't supported.

      #### Example

      The following code produces this diagnostic because the constant map
      contains a key whose type is `C`, and the class `C` overrides the
      implementation of `==`:

      ```dart
      class C {
        const C();

        bool operator ==(Object other) => true;
      }

      const map = {[!C()!] : 0};
      ```

      #### Common fixes

      If you can remove the implementation of `==` from the class, then do so:

      ```dart
      class C {
        const C();
      }

      const map = {C() : 0};
      ```

      If you can't remove the implementation of `==` from the class, then make
      the map be non-constant:

      ```dart
      class C {
        const C();

        bool operator ==(Object other) => true;
      }

      final map = {C() : 0};
      ```
  CONST_NOT_INITIALIZED:
    problemMessage: "The constant '{0}' must be initialized."
    correctionMessage: Try adding an initialization to the declaration.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the uninitialized final variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a variable that is declared to
      be a constant doesn't have an initializer.

      #### Example

      The following code produces this diagnostic because `c` isn't initialized:

      ```dart
      const [!c!];
      ```

      #### Common fixes

      Add an initializer:

      ```dart
      const c = 'c';
      ```
  CONST_SET_ELEMENT_TYPE_IMPLEMENTS_EQUALS:
    problemMessage: "The type of an element in a constant set can't override the '==' operator, but the type '{0}' does."
    correctionMessage: "Try using a different value for the element, or removing the keyword 'const' from the set."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the element
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the class of object used as an
      element in a constant set literal implements the `==` operator. The
      implementation of constant sets uses the `==` operator, so any
      implementation other than the one inherited from `Object` requires
      executing arbitrary code at compile time, which isn't supported.

      #### Example

      The following code produces this diagnostic because the constant set
      contains an element whose type is `C`, and the class `C` overrides the
      implementation of `==`:

      ```dart
      class C {
        const C();

        bool operator ==(Object other) => true;
      }

      const set = {[!C()!]};
      ```

      #### Common fixes

      If you can remove the implementation of `==` from the class, then do so:

      ```dart
      class C {
        const C();
      }

      const set = {C()};
      ```

      If you can't remove the implementation of `==` from the class, then make
      the set be non-constant:

      ```dart
      class C {
        const C();

        bool operator ==(Object other) => true;
      }

      final set = {C()};
      ```
  CONST_SPREAD_EXPECTED_LIST_OR_SET:
    problemMessage: A list or a set is expected in this spread.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression of a spread
      operator in a constant list or set evaluates to something other than a list
      or a set.

      #### Example

      The following code produces this diagnostic because the value of `list1` is
      `null`, which is neither a list nor a set:

      ```dart
      %language=2.9
      const List<int> list1 = null;
      const List<int> list2 = [...[!list1!]];
      ```

      #### Common fixes

      Change the expression to something that evaluates to either a constant list
      or a constant set:

      ```dart
      %language=2.9
      const List<int> list1 = [];
      const List<int> list2 = [...list1];
      ```
  CONST_SPREAD_EXPECTED_MAP:
    problemMessage: A map is expected in this spread.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression of a spread
      operator in a constant map evaluates to something other than a map.

      #### Example

      The following code produces this diagnostic because the value of `map1` is
      `null`, which isn't a map:

      ```dart
      %language=2.9
      const Map<String, int> map1 = null;
      const Map<String, int> map2 = {...[!map1!]};
      ```

      #### Common fixes

      Change the expression to something that evaluates to a constant map:

      ```dart
      %language=2.9
      const Map<String, int> map1 = {};
      const Map<String, int> map2 = {...map1};
      ```
  CONST_WITH_NON_CONST:
    problemMessage: "The constructor being called isn't a const constructor."
    correctionMessage: "Try removing 'const' from the constructor invocation."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the keyword `const` is used to
      invoke a constructor that isn't marked with `const`.

      #### Example

      The following code produces this diagnostic because the constructor in `A`
      isn't a const constructor:

      ```dart
      class A {
        A();
      }

      A f() => [!const!] A();
      ```

      #### Common fixes

      If it's desirable and possible to make the class a constant class (by
      making all of the fields of the class, including inherited fields, final),
      then add the keyword `const` to the constructor:

      ```dart
      class A {
        const A();
      }

      A f() => const A();
      ```

      Otherwise, remove the keyword `const`:

      ```dart
      class A {
        A();
      }

      A f() => A();
      ```
  CONST_WITH_NON_CONSTANT_ARGUMENT:
    problemMessage: Arguments of a constant creation must be constant expressions.
    correctionMessage: "Try making the argument a valid constant, or use 'new' to call the constructor."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a const constructor is invoked
      with an argument that isn't a constant expression.

      #### Example

      The following code produces this diagnostic because `i` isn't a constant:

      ```dart
      class C {
        final int i;
        const C(this.i);
      }
      C f(int i) => const C([!i!]);
      ```

      #### Common fixes

      Either make all of the arguments constant expressions, or remove the
      `const` keyword to use the non-constant form of the constructor:

      ```dart
      class C {
        final int i;
        const C(this.i);
      }
      C f(int i) => C(i);
      ```
  CONST_WITH_TYPE_PARAMETERS:
    problemMessage: "A constant creation can't use a type parameter as a type argument."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type parameter is used as a
      type argument in a `const` invocation of a constructor. This isn't allowed
      because the value of the type parameter (the actual type that will be used
      at runtime) can't be known at compile time.

      #### Example

      The following code produces this diagnostic because the type parameter `T`
      is being used as a type argument when creating a constant:

      ```dart
      class C<T> {
        const C();
      }

      C<T> newC<T>() => const C<[!T!]>();
      ```

      #### Common fixes

      If the type that will be used for the type parameter can be known at
      compile time, then remove the use of the type parameter:

      ```dart
      class C<T> {
        const C();
      }

      C<int> newC() => const C<int>();
      ```

      If the type that will be used for the type parameter can't be known until
      runtime, then remove the keyword `const`:

      ```dart
      class C<T> {
        const C();
      }

      C<T> newC<T>() => C<T>();
      ```
  CONST_WITH_TYPE_PARAMETERS_CONSTRUCTOR_TEAROFF:
    sharedName: CONST_WITH_TYPE_PARAMETERS
    problemMessage: "A constant constructor tearoff can't use a type parameter as a type argument."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: No parameters.
  CONST_WITH_TYPE_PARAMETERS_FUNCTION_TEAROFF:
    sharedName: CONST_WITH_TYPE_PARAMETERS
    problemMessage: "A constant function tearoff can't use a type parameter as a type argument."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: No parameters.
  CONST_WITH_UNDEFINED_CONSTRUCTOR:
    problemMessage: "The class '{0}' doesn't have a constant constructor '{1}'."
    correctionMessage: Try calling a different constructor.
    comment: |-
      16.12.2 Const: It is a compile-time error if <i>T.id</i> is not the name of
      a constant constructor declared by the type <i>T</i>.

      Parameters:
      0: the name of the type
      1: the name of the requested constant constructor
  CONST_WITH_UNDEFINED_CONSTRUCTOR_DEFAULT:
    problemMessage: "The class '{0}' doesn't have an unnamed constant constructor."
    correctionMessage: Try calling a different constructor.
    comment: |-
      16.12.2 Const: It is a compile-time error if <i>T.id</i> is not the name of
      a constant constructor declared by the type <i>T</i>.

      Parameters:
      0: the name of the type
  CONTINUE_LABEL_ON_SWITCH:
    problemMessage: A `continue` label resolves to a `switch` statement, but the label must be on a loop or a switch member.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the label in a `continue`
      statement resolves to a label on a `switch` statement.

      #### Example

      The following code produces this diagnostic because the label `l`, used to
      label a `switch` statement, is used in the `continue` statement:

      ```dart
      void f(int i) {
        l: switch (i) {
          case 0:
            continue [!l!];
        }
      }
      ```

      #### Common fixes

      Find a different way to achieve the control flow you need; for example, by
      introducing a loop that re-executes the `switch` statement.
  COULD_NOT_INFER:
    problemMessage: "Couldn't infer type parameter '{0}'.{1}"
    comment: |-
      Parameters:
      0: the name of the type parameter
      1: detail text explaining why the type could not be inferred
  NEW_WITH_NON_TYPE:
    sharedName: CREATION_WITH_NON_TYPE
    problemMessage: "The name '{0}' isn't a class."
    correctionMessage: Try correcting the name to match an existing class.
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the non-type element
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an instance creation using
      either `new` or `const` specifies a name that isn't defined as a class.

      #### Example

      The following code produces this diagnostic because `f` is a function
      rather than a class:

      ```dart
      int f() => 0;

      void g() {
        new [!f!]();
      }
      ```

      #### Common fixes

      If a class should be created, then replace the invalid name with the name
      of a valid class:

      ```dart
      int f() => 0;

      void g() {
        new Object();
      }
      ```

      If the name is the name of a function and you want that function to be
      invoked, then remove the `new` or `const` keyword:

      ```dart
      int f() => 0;

      void g() {
        f();
      }
      ```
  CONST_WITH_NON_TYPE:
    sharedName: CREATION_WITH_NON_TYPE
    problemMessage: "The name '{0}' isn't a class."
    correctionMessage: Try correcting the name to match an existing class.
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the non-type element
  DEFAULT_LIST_CONSTRUCTOR:
    problemMessage: "The default 'List' constructor isn't available when null safety is enabled."
    correctionMessage: "Try using a list literal, 'List.filled' or 'List.generate'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a use of the default
      constructor for the class `List` in code that has opted in to null safety.

      #### Example

      Assuming the following code is opted in to null safety, it produces this
      diagnostic because it uses the default `List` constructor:

      ```dart
      var l = [!List<int>!]();
      ```

      #### Common fixes

      If no initial size is provided, then convert the code to use a list
      literal:

      ```dart
      var l = <int>[];
      ```

      If an initial size needs to be provided and there is a single reasonable
      initial value for the elements, then use `List.filled`:

      ```dart
      var l = List.filled(3, 0);
      ```

      If an initial size needs to be provided but each element needs to be
      computed, then use `List.generate`:

      ```dart
      var l = List.generate(3, (i) => i);
      ```
  DEFAULT_VALUE_IN_REDIRECTING_FACTORY_CONSTRUCTOR:
    problemMessage: "Default values aren't allowed in factory constructors that redirect to another constructor."
    correctionMessage: Try removing the default value.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a factory constructor that
      redirects to another constructor specifies a default value for an optional
      parameter.

      #### Example

      The following code produces this diagnostic because the factory constructor
      in `A` has a default value for the optional parameter `x`:

      ```dart
      class A {
        factory A([int [!x!] = 0]) = B;
      }

      class B implements A {
        B([int x = 1]) {}
      }
      ```

      #### Common fixes

      Remove the default value from the factory constructor:

      ```dart
      class A {
        factory A([int x]) = B;
      }

      class B implements A {
        B([int x = 1]) {}
      }
      ```

      Note that this fix might change the value used when the optional parameter
      is omitted. If that happens, and if that change is a problem, then consider
      making the optional parameter a required parameter in the factory method:

      ```dart
      class A {
       factory A(int x) = B;
      }

      class B implements A {
        B([int x = 1]) {}
      }
      ```
  DEFAULT_VALUE_ON_REQUIRED_PARAMETER:
    problemMessage: "Required named parameters can't have a default value."
    correctionMessage: "Try removing either the default value or the 'required' modifier."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a named parameter has both the
      `required` modifier and a default value. If the parameter is required, then
      a value for the parameter is always provided at the call sites, so the
      default value can never be used.

      #### Example

      The following code generates this diagnostic:

      ```dart
      void log({required String [!message!] = 'no message'}) {}
      ```

      #### Common fixes

      If the parameter is really required, then remove the default value:

      ```dart
      void log({required String message}) {}
      ```

      If the parameter isn't always required, then remove the `required`
      modifier:

      ```dart
      void log({String message = 'no message'}) {}
      ```
  DEFERRED_IMPORT_OF_EXTENSION:
    problemMessage: Imports of deferred libraries must hide all extensions.
    correctionMessage: Try adding either a show combinator listing the names you need to reference or a hide combinator listing all of the extensions.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library that is imported using
      a deferred import declares an extension that is visible in the importing
      library. Extension methods are resolved at compile time, and extensions
      from deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines a named extension:

      ```dart
      %uri="lib/a.dart"
      class C {}

      extension E on String {
        int get size => length;
      }
      ```

      The following code produces this diagnostic because the named extension is
      visible to the library:

      ```dart
      import [!'a.dart'!] deferred as a;

      void f() {
        a.C();
      }
      ```

      #### Common fixes

      If the library must be imported as `deferred`, then either add a `show`
      clause listing the names being referenced or add a `hide` clause listing
      all of the named extensions. Adding a `show` clause would look like this:

      ```dart
      import 'a.dart' deferred as a show C;

      void f() {
        a.C();
      }
      ```

      Adding a `hide` clause would look like this:

      ```dart
      import 'a.dart' deferred as a hide E;

      void f() {
        a.C();
      }
      ```

      With the first fix, the benefit is that if new extensions are added to the
      imported library, then the extensions won't cause a diagnostic to be
      generated.

      If the library doesn't need to be imported as `deferred`, or if you need to
      make use of the extension method declared in it, then remove the keyword
      `deferred`:

      ```dart
      import 'a.dart' as a;

      void f() {
        a.C();
      }
      ```
  DEFINITELY_UNASSIGNED_LATE_LOCAL_VARIABLE:
    problemMessage: "The late local variable '{0}' is definitely unassigned at this point."
    correctionMessage: Ensure that it is assigned on necessary execution paths.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the variable that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when [definite assignment][] analysis
      shows that a local variable that's marked as `late` is read before being
      assigned.

      #### Example

      The following code produces this diagnostic because `x` wasn't assigned a
      value before being read:

      ```dart
      void f(bool b) {
        late int x;
        print([!x!]);
      }
      ```

      #### Common fixes

      Assign a value to the variable before reading from it:

      ```dart
      void f(bool b) {
        late int x;
        x = b ? 1 : 0;
        print(x);
      }
      ```
  DISALLOWED_TYPE_INSTANTIATION_EXPRESSION:
    problemMessage: Only a generic type, generic function, generic instance method, or generic constructor can have type arguments.
    correctionMessage: Try removing the type arguments, or instantiating the type(s) of a generic type, generic function, generic instance method, or generic constructor.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an expression with a value that
      is anything other than one of the allowed kinds of values is followed by
      type arguments. The allowed kinds of values are:
      - generic types,
      - generic constructors, and
      - generic functions, including top-level functions, static and instance
        members, and local functions.

      #### Example

      The following code produces this diagnostic because `i` is a top-level
      variable, which isn't one of the allowed cases:

      ```dart
      int i = 1;

      void f() {
        print([!i!]<int>);
      }
      ```

      #### Common fixes

      If the referenced value is correct, then remove the type arguments:

      ```dart
      int i = 1;

      void f() {
        print(i);
      }
      ```
  DUPLICATE_CONSTRUCTOR_NAME:
    sharedName: DUPLICATE_CONSTRUCTOR
    problemMessage: "The constructor with name '{0}' is already defined."
    correctionMessage: Try renaming one of the constructors.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the duplicate entity
  DUPLICATE_CONSTRUCTOR_DEFAULT:
    sharedName: DUPLICATE_CONSTRUCTOR
    problemMessage: The unnamed constructor is already defined.
    correctionMessage: Try giving one of the constructors a name.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class declares more than one
      unnamed constructor or when it declares more than one constructor with the
      same name.

      #### Examples

      The following code produces this diagnostic because there are two
      declarations for the unnamed constructor:

      ```dart
      class C {
        C();

        [!C!]();
      }
      ```

      The following code produces this diagnostic because there are two
      declarations for the constructor named `m`:

      ```dart
      class C {
        C.m();

        [!C.m!]();
      }
      ```

      #### Common fixes

      If there are multiple unnamed constructors and all of the constructors are
      needed, then give all of them, or all except one of them, a name:

      ```dart
      class C {
        C();

        C.n();
      }
      ```

      If there are multiple unnamed constructors and all except one of them are
      unneeded, then remove the constructors that aren't needed:

      ```dart
      class C {
        C();
      }
      ```

      If there are multiple named constructors and all of the constructors are
      needed, then rename all except one of them:

      ```dart
      class C {
        C.m();

        C.n();
      }
      ```

      If there are multiple named constructors and all except one of them are
      unneeded, then remove the constructorsthat aren't needed:

      ```dart
      class C {
        C.m();
      }
      ```
  DUPLICATE_DEFINITION:
    problemMessage: "The name '{0}' is already defined."
    correctionMessage: Try renaming one of the declarations.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the duplicate entity
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name is declared, and there is
      a previous declaration with the same name in the same scope.

      #### Example

      The following code produces this diagnostic because the name `x` is
      declared twice:

      ```dart
      int x = 0;
      int [!x!] = 1;
      ```

      #### Common fixes

      Choose a different name for one of the declarations.

      ```dart
      int x = 0;
      int y = 1;
      ```
  DUPLICATE_FIELD_FORMAL_PARAMETER:
    problemMessage: "The field '{0}' can't be initialized by multiple parameters in the same constructor."
    correctionMessage: Try removing one of the parameters, or using different fields.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's more than one
      initializing formal parameter for the same field in a constructor's
      parameter list. It isn't useful to assign a value that will immediately be
      overwritten.

      #### Example

      The following code produces this diagnostic because `this.f` appears twice
      in the parameter list:

      ```dart
      class C {
        int f;

        C(this.f, this.[!f!]) {}
      }
      ```

      #### Common fixes

      Remove one of the initializing formal parameters:

      ```dart
      class C {
        int f;

        C(this.f) {}
      }
      ```
  DUPLICATE_NAMED_ARGUMENT:
    problemMessage: "The argument for the named parameter '{0}' was already specified."
    correctionMessage: Try removing one of the named arguments, or correcting one of the names to reference a different named parameter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the parameter that was duplicated
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation has two or more
      named arguments that have the same name.

      #### Example

      The following code produces this diagnostic because there are two arguments
      with the name `a`:

      ```dart
      %language=2.9
      void f(C c) {
        c.m(a: 0, [!a!]: 1);
      }

      class C {
        void m({int a, int b}) {}
      }
      ```

      #### Common fixes

      If one of the arguments should have a different name, then change the name:

      ```dart
      %language=2.9
      void f(C c) {
        c.m(a: 0, b: 1);
      }

      class C {
        void m({int a, int b}) {}
      }
      ```

      If one of the arguments is wrong, then remove it:

      ```dart
      %language=2.9
      void f(C c) {
        c.m(a: 1);
      }

      class C {
        void m({int a, int b}) {}
      }
      ```
  DUPLICATE_PART:
    problemMessage: "The library already contains a part with the URI '{0}'."
    correctionMessage: Try removing all except one of the duplicated part directives.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the URI of the duplicate part
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a single file is referenced in
      multiple part directives.

      #### Example

      Given a file named `part.dart` containing

      ```dart
      %uri="lib/part.dart"
      part of lib;
      ```

      The following code produces this diagnostic because the file `part.dart` is
      included multiple times:

      ```dart
      library lib;

      part 'part.dart';
      part [!'part.dart'!];
      ```

      #### Common fixes

      Remove all except the first of the duplicated part directives:

      ```dart
      library lib;

      part 'part.dart';
      ```
  ENUM_CONSTANT_SAME_NAME_AS_ENCLOSING:
    problemMessage: "The name of the enum constant can't be the same as the enum's name."
    correctionMessage: Try renaming the constant.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an enum constant has the same
      name as the enum in which it's declared.

      #### Example

      The following code produces this diagnostic because the enum constant `E`
      has the same name as the enclosing enum `E`:

      ```dart
      enum E {
        [!E!]
      }
      ```

      #### Common fixes

      If the name of the enum is correct, then rename the constant:

      ```dart
      enum E {
        e
      }
      ```

      If the name of the constant is correct, then rename the enum:

      ```dart
      enum F {
        E
      }
      ```
  ENUM_CONSTANT_WITH_NON_CONST_CONSTRUCTOR:
    problemMessage: The invoked constructor isn't a 'const' constructor.
    correctionMessage: Try invoking a 'const' generative constructor.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an enum constant is being
      created using either a factory constructor or a generative constructor
      that isn't marked as being `const`.
      
      #### Example
      
      The following code produces this diagnostic because the enum constant `e`
      is being initialized by a factory constructor:
      
      ```dart
      enum E {
        [!e!]();
      
        factory E() => e;
      }
      ```
      
      #### Common fixes
      
      Use a generative constructor marked as `const`:
      
      ```dart
      enum E {
        e._();
      
        factory E() => e;
      
        const E._();
      }
      ```
  ENUM_INSTANTIATED_TO_BOUNDS_IS_NOT_WELL_BOUNDED:
    problemMessage: The result of instantiating the enum to bounds is not well-bounded.
    correctionMessage: Try using different bounds for type parameters.
  ENUM_MIXIN_WITH_INSTANCE_VARIABLE:
    problemMessage: Mixins applied to enums can't have instance variables.
    correctionMessage: Try replacing the instance variables with getters.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a mixin that's applied to an
      enum declares one or more instance variables. This isn't allowed because
      the enum constants are constant, and there isn't any way for the
      constructor in the enum to initialize any of the mixin's fields.
      
      #### Example
      
      The following code produces this diagnostic because the mixin `M` defines
      the instance field `x`:
      
      ```dart
      mixin M {
        int x = 0;
      }
      
      enum E with [!M!] {
        a
      }
      ```
      
      #### Common fixes
      
      If you need to apply the mixin, then change all instance fields into
      getter and setter pairs and implement them in the enum if necessary:
      
      ```dart
      mixin M {
        int get x => 0;
      }
      
      enum E with M {
        a
      }
      ```
      
      If you don't need to apply the mixin, then remove it:
      
      ```dart
      enum E {
        a
      }
      ```
  ENUM_WITH_ABSTRACT_MEMBER:
    problemMessage: "'{0}' must have a method body because '{1}' is an enum."
    correctionMessage: "Try adding a body to '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the abstract method
      1: the name of the enclosing enum
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a member of an enum is found
      that doesn't have a concrete implementation. Enums aren't allowed to
      contain abstract members.
      
      #### Example
      
      The following code produces this diagnostic because `m` is an abstract
      method and `E` is an enum:
      
      ```dart
      enum E {
        e;
      
        [!void m();!]
      }
      ```
      
      #### Common fixes
      
      Provide an implementation for the member:
      
      ```dart
      enum E {
        e;
      
        void m() {}
      }
      ```
  ENUM_WITH_NAME_VALUES:
    problemMessage: The name 'values' is not a valid name for an enum.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an enum is declared to have the
      name `values`. This isn't allowed because the enum has an implicit static
      field named `values`, and the two would collide.
      
      #### Example
      
      The following code produces this diagnostic because there's an enum
      declaration that has the name `values`:
      
      ```dart
      enum [!values!] {
        c
      }
      ```
      
      #### Common fixes
      
      Rename the enum to something other than `values`.
  EQUAL_ELEMENTS_IN_CONST_SET:
    problemMessage: "Two elements in a constant set literal can't be equal."
    correctionMessage: Change or remove the duplicate element.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when two elements in a constant set
      literal have the same value. The set can only contain each value once,
      which means that one of the values is unnecessary.

      #### Example

      The following code produces this diagnostic because the string `'a'` is
      specified twice:

      ```dart
      const Set<String> set = {'a', [!'a'!]};
      ```

      #### Common fixes

      Remove one of the duplicate values:

      ```dart
      const Set<String> set = {'a'};
      ```

      Note that literal sets preserve the order of their elements, so the choice
      of which element to remove might affect the order in which elements are
      returned by an iterator.
  EQUAL_KEYS_IN_CONST_MAP:
    problemMessage: "Two keys in a constant map literal can't be equal."
    correctionMessage: Change or remove the duplicate key.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a key in a constant map is the
      same as a previous key in the same map. If two keys are the same, then the
      second value would overwrite the first value, which makes having both pairs
      pointless.

      #### Example

      The following code produces this diagnostic because the key `1` is used
      twice:

      ```dart
      const map = <int, String>{1: 'a', 2: 'b', [!1!]: 'c', 4: 'd'};
      ```

      #### Common fixes

      If both entries should be included in the map, then change one of the keys
      to be different:

      ```dart
      const map = <int, String>{1: 'a', 2: 'b', 3: 'c', 4: 'd'};
      ```

      If only one of the entries is needed, then remove the one that isn't
      needed:

      ```dart
      const map = <int, String>{1: 'a', 2: 'b', 4: 'd'};
      ```

      Note that literal maps preserve the order of their entries, so the choice
      of which entry to remove might affect the order in which keys and values
      are returned by an iterator.
  EXPECTED_ONE_LIST_TYPE_ARGUMENTS:
    problemMessage: "List literals require one type argument or none, but {0} found."
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the number of provided type arguments
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a list literal has more than one
      type argument.

      #### Example

      The following code produces this diagnostic because the list literal has
      two type arguments when it can have at most one:

      ```dart
      var l = [!<int, int>!][];
      ```

      #### Common fixes

      Remove all except one of the type arguments:

      ```dart
      var l = <int>[];
      ```
  EXPECTED_ONE_SET_TYPE_ARGUMENTS:
    problemMessage: "Set literals require one type argument or none, but {0} were found."
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the number of provided type arguments
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a set literal has more than one
      type argument.

      #### Example

      The following code produces this diagnostic because the set literal has
      three type arguments when it can have at most one:

      ```dart
      var s = [!<int, String, int>!]{0, 'a', 1};
      ```

      #### Common fixes

      Remove all except one of the type arguments:

      ```dart
      var s = <int>{0, 1};
      ```
  EXPECTED_TWO_MAP_TYPE_ARGUMENTS:
    problemMessage: "Map literals require two type arguments or none, but {0} found."
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the number of provided type arguments
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a map literal has either one or
      more than two type arguments.

      #### Example

      The following code produces this diagnostic because the map literal has
      three type arguments when it can have either two or zero:

      ```dart
      var m = [!<int, String, int>!]{};
      ```

      #### Common fixes

      Remove all except two of the type arguments:

      ```dart
      var m = <int, String>{};
      ```
  EXPORT_INTERNAL_LIBRARY:
    problemMessage: "The library '{0}' is internal and can't be exported."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the uri pointing to a library
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an export whose `dart:`
      URI references an internal library.

      #### Example

      The following code produces this diagnostic because `_interceptors` is an
      internal library:

      ```dart
      export [!'dart:_interceptors'!];
      ```

      #### Common fixes

      Remove the export directive.
  EXPORT_LEGACY_SYMBOL:
    problemMessage: "The symbol '{0}' is defined in a legacy library, and can't be re-exported from a library with null safety enabled."
    correctionMessage: Try removing the export or migrating the legacy library.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of a symbol defined in a legacy library
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library that was opted in to
      null safety exports another library, and the exported library is opted out
      of null safety.

      #### Example

      Given a library that is opted out of null safety:

      ```dart
      %uri="lib/optedOut.dart"
      // @dart = 2.8
      String s;
      ```

      The following code produces this diagnostic because it's exporting symbols
      from an opted-out library:

      ```dart
      export [!'optedOut.dart'!];

      class C {}
      ```

      #### Common fixes

      If you're able to do so, migrate the exported library so that it doesn't
      need to opt out:

      ```dart
      String? s;
      ```

      If you can't migrate the library, then remove the export:

      ```dart
      class C {}
      ```

      If the exported library (the one that is opted out) itself exports an
      opted-in library, then it's valid for your library to indirectly export the
      symbols from the opted-in library. You can do so by adding a hide
      combinator to the export directive in your library that hides all of the
      names declared in the opted-out library.
  EXPORT_OF_NON_LIBRARY:
    problemMessage: "The exported library '{0}' can't have a part-of directive."
    correctionMessage: Try exporting the library that the part is a part of.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the uri pointing to a non-library declaration
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an export directive references a
      part rather than a library.

      #### Example

      Given a file named `part.dart` containing

      ```dart
      %uri="lib/part.dart"
      part of lib;
      ```

      The following code produces this diagnostic because the file `part.dart` is
      a part, and only libraries can be exported:

      ```dart
      library lib;

      export [!'part.dart'!];
      ```

      #### Common fixes

      Either remove the export directive, or change the URI to be the URI of the
      library containing the part.
  EXPRESSION_IN_MAP:
    problemMessage: "Expressions can't be used in a map literal."
    correctionMessage: Try removing the expression or converting it to be a map entry.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the analyzer finds an
      expression, rather than a map entry, in what appears to be a map literal.

      #### Example

      The following code produces this diagnostic:

      ```dart
      var map = <String, int>{'a': 0, 'b': 1, [!'c'!]};
      ```

      #### Common fixes

      If the expression is intended to compute either a key or a value in an
      entry, fix the issue by replacing the expression with the key or the value.
      For example:

      ```dart
      var map = <String, int>{'a': 0, 'b': 1, 'c': 2};
      ```
  EXTENDS_NON_CLASS:
    problemMessage: Classes can only extend other classes.
    correctionMessage: Try specifying a different superclass, or removing the extends clause.
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name in the extends clause
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an `extends` clause contains a
      name that is declared to be something other than a class.

      #### Example

      The following code produces this diagnostic because `f` is declared to be a
      function:

      ```dart
      void f() {}

      class C extends [!f!] {}
      ```

      #### Common fixes

      If you want the class to extend a class other than `Object`, then replace
      the name in the `extends` clause with the name of that class:

      ```dart
      void f() {}

      class C extends B {}

      class B {}
      ```

      If you want the class to extend `Object`, then remove the `extends` clause:

      ```dart
      void f() {}

      class C {}
      ```
  EXTENSION_AS_EXPRESSION:
    problemMessage: "Extension '{0}' can't be used as an expression."
    correctionMessage: Try replacing it with a valid expression.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the extension
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name of an extension is used
      in an expression other than in an extension override or to qualify an
      access to a static member of the extension. Because classes define a type,
      the name of a class can be used to refer to the instance of `Type`
      representing the type of the class. Extensions, on the other hand, don't
      define a type and can't be used as a type literal.

      #### Example

      The following code produces this diagnostic because `E` is an extension:

      ```dart
      extension E on int {
        static String m() => '';
      }

      var x = [!E!];
      ```

      #### Common fixes

      Replace the name of the extension with a name that can be referenced, such
      as a static member defined on the extension:

      ```dart
      extension E on int {
        static String m() => '';
      }

      var x = E.m();
      ```
  EXTENSION_CONFLICTING_STATIC_AND_INSTANCE:
    problemMessage: "An extension can't define static member '{0}' and an instance member with the same name."
    correctionMessage: "Try renaming the member to a name that doesn't conflict."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the conflicting static member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension declaration
      contains both an instance member and a static member that have the same
      name. The instance member and the static member can't have the same name
      because it's unclear which member is being referenced by an unqualified use
      of the name within the body of the extension.

      #### Example

      The following code produces this diagnostic because the name `a` is being
      used for two different members:

      ```dart
      extension E on Object {
        int get a => 0;
        static int [!a!]() => 0;
      }
      ```

      #### Common fixes

      Rename or remove one of the members:

      ```dart
      extension E on Object {
        int get a => 0;
        static int b() => 0;
      }
      ```
  EXTENSION_DECLARES_MEMBER_OF_OBJECT:
    problemMessage: "Extensions can't declare members with the same name as a member declared by 'Object'."
    correctionMessage: Try specifying a different name for the member.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension declaration
      declares a member with the same name as a member declared in the class
      `Object`. Such a member can never be used because the member in `Object` is
      always found first.

      #### Example

      The following code produces this diagnostic because `toString` is defined
      by `Object`:

      ```dart
      extension E on String {
        String [!toString!]() => this;
      }
      ```

      #### Common fixes

      Remove the member or rename it so that the name doesn't conflict with the
      member in `Object`:

      ```dart
      extension E on String {
        String displayString() => this;
      }
      ```
  EXTENSION_OVERRIDE_ACCESS_TO_STATIC_MEMBER:
    problemMessage: "An extension override can't be used to access a static member from an extension."
    correctionMessage: Try using just the name of the extension.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is the
      receiver of the invocation of a static member. Similar to static members in
      classes, the static members of an extension should be accessed using the
      name of the extension, not an extension override.

      #### Example

      The following code produces this diagnostic because `m` is static:

      ```dart
      extension E on String {
        static void m() {}
      }

      void f() {
        E('').[!m!]();
      }
      ```

      #### Common fixes

      Replace the extension override with the name of the extension:

      ```dart
      extension E on String {
        static void m() {}
      }

      void f() {
        E.m();
      }
      ```
  EXTENSION_OVERRIDE_ARGUMENT_NOT_ASSIGNABLE:
    problemMessage: "The type of the argument to the extension override '{0}' isn't assignable to the extended type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the argument
      1: the extended type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the argument to an extension
      override isn't assignable to the type being extended by the extension.

      #### Example

      The following code produces this diagnostic because `3` isn't a `String`:

      ```dart
      extension E on String {
        void method() {}
      }

      void f() {
        E([!3!]).method();
      }
      ```

      #### Common fixes

      If you're using the correct extension, then update the argument to have the
      correct type:

      ```dart
      extension E on String {
        void method() {}
      }

      void f() {
        E(3.toString()).method();
      }
      ```

      If there's a different extension that's valid for the type of the argument,
      then either replace the name of the extension or unwrap the argument so
      that the correct extension is found.
  EXTENSION_OVERRIDE_WITHOUT_ACCESS:
    problemMessage: An extension override can only be used to access instance members.
    correctionMessage: Consider adding an access to an instance member.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is found
      that isn't being used to access one of the members of the extension. The
      extension override syntax doesn't have any runtime semantics; it only
      controls which member is selected at compile time.

      #### Example

      The following code produces this diagnostic because `E(i)` isn't an
      expression:

      ```dart
      extension E on int {
        int get a => 0;
      }

      void f(int i) {
        print([!E(i)!]);
      }
      ```

      #### Common fixes

      If you want to invoke one of the members of the extension, then add the
      invocation:

      ```dart
      extension E on int {
        int get a => 0;
      }

      void f(int i) {
        print(E(i).a);
      }
      ```

      If you don't want to invoke a member, then unwrap the argument:

      ```dart
      extension E on int {
        int get a => 0;
      }

      void f(int i) {
        print(i);
      }
      ```
  EXTENSION_OVERRIDE_WITH_CASCADE:
    problemMessage: "Extension overrides have no value so they can't be used as the receiver of a cascade expression."
    correctionMessage: "Try using '.' instead of '..'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is used as
      the receiver of a cascade expression. The value of a cascade expression
      `e..m` is the value of the receiver `e`, but extension overrides aren't
      expressions and don't have a value.

      #### Example

      The following code produces this diagnostic because `E(3)` isn't an
      expression:

      ```dart
      extension E on int {
        void m() {}
      }
      f() {
        [!E!](3)..m();
      }
      ```

      #### Common fixes

      Use `.` rather than `..`:

      ```dart
      extension E on int {
        void m() {}
      }
      f() {
        E(3).m();
      }
      ```

      If there are multiple cascaded accesses, you'll need to duplicate the
      extension override for each one.
  EXTERNAL_FIELD_CONSTRUCTOR_INITIALIZER:
    sharedName: EXTERNAL_WITH_INITIALIZER
    problemMessage: External fields can't have initializers.
    correctionMessage: "Try removing the field initializer or the 'external' keyword from the field declaration."
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field or variable marked with
      the keyword `external` has an initializer, or when an external field is
      initialized in a constructor.

      #### Examples

      The following code produces this diagnostic because the external field `x`
      is assigned a value in an initializer:

      ```dart
      class C {
        external int x;
        C() : [!x!] = 0;
      }
      ```

      The following code produces this diagnostic because the external field `x`
      has an initializer:

      ```dart
      class C {
        external final int [!x!] = 0;
      }
      ```

      The following code produces this diagnostic because the external top level
      variable `x` has an initializer:

      ```dart
      external final int [!x!] = 0;
      ```

      #### Common fixes

      Remove the initializer:

      ```dart
      class C {
        external final int x;
      }
      ```
  EXTERNAL_FIELD_INITIALIZER:
    sharedName: EXTERNAL_WITH_INITIALIZER
    problemMessage: External fields can't have initializers.
    correctionMessage: "Try removing the initializer or the 'external' keyword."
    hasPublishedDocs: true
  EXTERNAL_VARIABLE_INITIALIZER:
    sharedName: EXTERNAL_WITH_INITIALIZER
    problemMessage: External variables can't have initializers.
    correctionMessage: "Try removing the initializer or the 'external' keyword."
    hasPublishedDocs: true
  EXTRA_POSITIONAL_ARGUMENTS:
    problemMessage: "Too many positional arguments: {0} expected, but {1} found."
    correctionMessage: Try removing the extra arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the maximum number of positional arguments
      1: the actual number of positional arguments given
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function invocation
      has more positional arguments than the method or function allows.

      #### Example

      The following code produces this diagnostic because `f` defines 2
      parameters but is invoked with 3 arguments:

      ```dart
      void f(int a, int b) {}
      void g() {
        f(1, 2, [!3!]);
      }
      ```

      #### Common fixes

      Remove the arguments that don't correspond to parameters:

      ```dart
      void f(int a, int b) {}
      void g() {
        f(1, 2);
      }
      ```
  EXTRA_POSITIONAL_ARGUMENTS_COULD_BE_NAMED:
    problemMessage: "Too many positional arguments: {0} expected, but {1} found."
    correctionMessage: Try removing the extra positional arguments, or specifying the name for named arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the maximum number of positional arguments
      1: the actual number of positional arguments given
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function invocation
      has more positional arguments than the method or function allows, but the
      method or function defines named parameters.

      #### Example

      The following code produces this diagnostic because `f` defines 2
      positional parameters but has a named parameter that could be used for the
      third argument:

      ```dart
      %language=2.9
      void f(int a, int b, {int c}) {}
      void g() {
        f(1, 2, [!3!]);
      }
      ```

      #### Common fixes

      If some of the arguments should be values for named parameters, then add
      the names before the arguments:

      ```dart
      %language=2.9
      void f(int a, int b, {int c}) {}
      void g() {
        f(1, 2, c: 3);
      }
      ```

      Otherwise, remove the arguments that don't correspond to positional
      parameters:

      ```dart
      %language=2.9
      void f(int a, int b, {int c}) {}
      void g() {
        f(1, 2);
      }
      ```
  FIELD_INITIALIZED_BY_MULTIPLE_INITIALIZERS:
    problemMessage: "The field '{0}' can't be initialized twice in the same constructor."
    correctionMessage: Try removing one of the initializations.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field being initialized multiple times
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the initializer list of a
      constructor initializes a field more than once. There is no value to allow
      both initializers because only the last value is preserved.

      #### Example

      The following code produces this diagnostic because the field `f` is being
      initialized twice:

      ```dart
      class C {
        int f;

        C() : f = 0, [!f!] = 1;
      }
      ```

      #### Common fixes

      Remove one of the initializers:

      ```dart
      class C {
        int f;

        C() : f = 0;
      }
      ```
  FIELD_INITIALIZED_IN_INITIALIZER_AND_DECLARATION:
    problemMessage: "Fields can't be initialized in the constructor if they are final and were already initialized at their declaration."
    correctionMessage: Try removing one of the initializations.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a final field is initialized in
      both the declaration of the field and in an initializer in a constructor.
      Final fields can only be assigned once, so it can't be initialized in both
      places.

      #### Example

      The following code produces this diagnostic because `f` is :

      ```dart
      class C {
        final int f = 0;
        C() : [!f!] = 1;
      }
      ```

      #### Common fixes

      If the initialization doesn't depend on any values passed to the
      constructor, and if all of the constructors need to initialize the field to
      the same value, then remove the initializer from the constructor:

      ```dart
      class C {
        final int f = 0;
        C();
      }
      ```

      If the initialization depends on a value passed to the constructor, or if
      different constructors need to initialize the field differently, then
      remove the initializer in the field's declaration:

      ```dart
      class C {
        final int f;
        C() : f = 1;
      }
      ```
  FIELD_INITIALIZED_IN_PARAMETER_AND_INITIALIZER:
    problemMessage: "Fields can't be initialized in both the parameter list and the initializers."
    correctionMessage: Try removing one of the initializations.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field is initialized in both
      the parameter list and in the initializer list of a constructor.

      #### Example

      The following code produces this diagnostic because the field `f` is
      initialized both by an initializing formal parameter and in the
      initializer list:

      ```dart
      class C {
        int f;

        C(this.f) : [!f!] = 0;
      }
      ```

      #### Common fixes

      If the field should be initialized by the parameter, then remove the
      initialization in the initializer list:

      ```dart
      class C {
        int f;

        C(this.f);
      }
      ```

      If the field should be initialized in the initializer list and the
      parameter isn't needed, then remove the parameter:

      ```dart
      class C {
        int f;

        C() : f = 0;
      }
      ```

      If the field should be initialized in the initializer list and the
      parameter is needed, then make it a normal parameter:

      ```dart
      class C {
        int f;

        C(int g) : f = g * 2;
      }
      ```
  FIELD_INITIALIZER_FACTORY_CONSTRUCTOR:
    problemMessage: "Initializing formal parameters can't be used in factory constructors."
    correctionMessage: Try using a normal parameter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a factory constructor has an
      initializing formal parameter. Factory constructors can't assign values to
      fields because no instance is created; hence, there is no field to assign.

      #### Example

      The following code produces this diagnostic because the factory constructor
      uses an initializing formal parameter:

      ```dart
      class C {
        int? f;

        factory C([!this.f!]) => throw 0;
      }
      ```

      #### Common fixes

      Replace the initializing formal parameter with a normal parameter:

      ```dart
      class C {
        int? f;

        factory C(int f) => throw 0;
      }
      ```
  FIELD_INITIALIZER_NOT_ASSIGNABLE:
    problemMessage: "The initializer type '{0}' can't be assigned to the field type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type of the initializer expression
      1: the name of the type of the field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the initializer list of a
      constructor initializes a field to a value that isn't assignable to the
      field.

      #### Example

      The following code produces this diagnostic because `0` has the type `int`,
      and an `int` can't be assigned to a field of type `String`:

      ```dart
      class C {
        String s;

        C() : s = [!0!];
      }
      ```

      #### Common fixes

      If the type of the field is correct, then change the value assigned to it
      so that the value has a valid type:

      ```dart
      class C {
        String s;

        C() : s = '0';
      }
      ```

      If the type of the value is correct, then change the type of the field to
      allow the assignment:

      ```dart
      class C {
        int s;

        C() : s = 0;
      }
      ```
  CONST_FIELD_INITIALIZER_NOT_ASSIGNABLE:
    sharedName: FIELD_INITIALIZER_NOT_ASSIGNABLE
    problemMessage: "The initializer type '{0}' can't be assigned to the field type '{1}' in a const constructor."
    correctionMessage: "Try using a subtype, or removing the 'const' keyword"
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type of the initializer expression
      1: the name of the type of the field
  FIELD_INITIALIZER_OUTSIDE_CONSTRUCTOR:
    problemMessage: Initializing formal parameters can only be used in constructors.
    correctionMessage: Try using a normal parameter.
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an initializing formal
      parameter is used in the parameter list for anything other than a
      constructor.

      #### Example

      The following code produces this diagnostic because the initializing
      formal parameter `this.x` is being used in the method `m`:

      ```dart
      class A {
        int x = 0;

        m([[!this.x!] = 0]) {}
      }
      ```

      #### Common fixes

      Replace the initializing formal parameter with a normal parameter and
      assign the field within the body of the method:

      ```dart
      class A {
        int x = 0;

        m([int x = 0]) {
          this.x = x;
        }
      }
      ```
  FIELD_INITIALIZER_REDIRECTING_CONSTRUCTOR:
    problemMessage: "The redirecting constructor can't have a field initializer."
    correctionMessage: Try initializing the field in the constructor being redirected to.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a redirecting constructor
      initializes a field in the object. This isn't allowed because the instance
      that has the field hasn't been created at the point at which it should be
      initialized.

      #### Examples

      The following code produces this diagnostic because the constructor
      `C.zero`, which redirects to the constructor `C`, has an initializing
      formal parameter that initializes the field `f`:

      ```dart
      class C {
        int f;

        C(this.f);

        C.zero([!this.f!]) : this(f);
      }
      ```

      The following code produces this diagnostic because the constructor
      `C.zero`, which redirects to the constructor `C`, has an initializer that
      initializes the field `f`:

      ```dart
      class C {
        int f;

        C(this.f);

        C.zero() : [!f = 0!], this(1);
      }
      ```

      #### Common fixes

      If the initialization is done by an initializing formal parameter, then
      use a normal parameter:

      ```dart
      class C {
        int f;

        C(this.f);

        C.zero(int f) : this(f);
      }
      ```

      If the initialization is done in an initializer, then remove the
      initializer:

      ```dart
      class C {
        int f;

        C(this.f);

        C.zero() : this(0);
      }
      ```
  FIELD_INITIALIZING_FORMAL_NOT_ASSIGNABLE:
    problemMessage: "The parameter type '{0}' is incompatible with the field type '{1}'."
    correctionMessage: "Try changing or removing the parameter's type, or changing the field's type."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type of the field formal parameter
      1: the name of the type of the field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of an initializing
      formal parameter isn't assignable to the type of the field being
      initialized.

      #### Example

      The following code produces this diagnostic because the initializing
      formal parameter has the type `String`, but the type of the field is
      `int`. The parameter must have a type that is a subtype of the field's
      type.

      ```dart
      class C {
        int f;

        C([!String this.f!]);
      }
      ```

      #### Common fixes

      If the type of the field is incorrect, then change the type of the field to
      match the type of the parameter, and consider removing the type from the
      parameter:

      ```dart
      class C {
        String f;

        C(this.f);
      }
      ```

      If the type of the parameter is incorrect, then remove the type of the
      parameter:

      ```dart
      class C {
        int f;

        C(this.f);
      }
      ```

      If the types of both the field and the parameter are correct, then use an
      initializer rather than an initializing formal parameter to convert the
      parameter value into a value of the correct type:

      ```dart
      class C {
        int f;

        C(String s) : f = int.parse(s);
      }
      ```
  FINAL_INITIALIZED_IN_DECLARATION_AND_CONSTRUCTOR:
    problemMessage: "'{0}' is final and was given a value when it was declared, so it can't be set to a new value."
    correctionMessage: Try removing one of the initializations.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field in question
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a final field is initialized
      twice: once where it's declared and once by a constructor's parameter.

      #### Example

      The following code produces this diagnostic because the field `f` is
      initialized twice:

      ```dart
      class C {
        final int f = 0;

        C(this.[!f!]);
      }
      ```

      #### Common fixes

      If the field should have the same value for all instances, then remove the
      initialization in the parameter list:

      ```dart
      class C {
        final int f = 0;

        C();
      }
      ```

      If the field can have different values in different instances, then remove
      the initialization in the declaration:

      ```dart
      class C {
        final int f;

        C(this.f);
      }
      ```
  FINAL_NOT_INITIALIZED:
    problemMessage: "The final variable '{0}' must be initialized."
    correctionMessage: Try initializing the variable.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the uninitialized final variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a final field or variable isn't
      initialized.

      #### Example

      The following code produces this diagnostic because `x` doesn't have an
      initializer:

      ```dart
      final [!x!];
      ```

      #### Common fixes

      For variables and static fields, you can add an initializer:

      ```dart
      final x = 0;
      ```

      For instance fields, you can add an initializer as shown in the previous
      example, or you can initialize the field in every constructor. You can
      initialize the field by using an initializing formal parameter:

      ```dart
      class C {
        final int x;
        C(this.x);
      }
      ```

      You can also initialize the field by using an initializer in the
      constructor:

      ```dart
      class C {
        final int x;
        C(int y) : x = y * 2;
      }
      ```
  FINAL_NOT_INITIALIZED_CONSTRUCTOR_1:
    sharedName: FINAL_NOT_INITIALIZED_CONSTRUCTOR
    problemMessage: "All final variables must be initialized, but '{0}' isn't."
    correctionMessage: Try adding an initializer for the field.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the uninitialized final variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class defines one or more
      final instance fields without initializers and has at least one constructor
      that doesn't initialize those fields. All final instance fields must be
      initialized when the instance is created, either by the field's initializer
      or by the constructor.

      #### Example

      The following code produces this diagnostic:

      ```dart
      class C {
        final String value;

        [!C!]();
      }
      ```

      #### Common fixes

      If the value should be passed in to the constructor directly, then use an
      initializing formal parameter to initialize the field `value`:

      ```dart
      class C {
        final String value;

        C(this.value);
      }
      ```

      If the value should be computed indirectly from a value provided by the
      caller, then add a parameter and include an initializer:

      ```dart
      class C {
        final String value;

        C(Object o) : value = o.toString();
      }
      ```

      If the value of the field doesn't depend on values that can be passed to
      the constructor, then add an initializer for the field as part of the field
      declaration:

      ```dart
      class C {
        final String value = '';

        C();
      }
      ```

      If the value of the field doesn't depend on values that can be passed to
      the constructor but different constructors need to initialize it to
      different values, then add an initializer for the field in the initializer
      list:

      ```dart
      class C {
        final String value;

        C() : value = '';

        C.named() : value = 'c';
      }
      ```

      However, if the value is the same for all instances, then consider using a
      static field instead of an instance field:

      ```dart
      class C {
        static const String value = '';

        C();
      }
      ```
  FINAL_NOT_INITIALIZED_CONSTRUCTOR_2:
    sharedName: FINAL_NOT_INITIALIZED_CONSTRUCTOR
    problemMessage: "All final variables must be initialized, but '{0}' and '{1}' aren't."
    correctionMessage: Try adding initializers for the fields.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the uninitialized final variable
      1: the name of the uninitialized final variable
  FINAL_NOT_INITIALIZED_CONSTRUCTOR_3_PLUS:
    sharedName: FINAL_NOT_INITIALIZED_CONSTRUCTOR
    problemMessage: "All final variables must be initialized, but '{0}', '{1}', and {2} others aren't."
    correctionMessage: Try adding initializers for the fields.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the uninitialized final variable
      1: the name of the uninitialized final variable
      2: the number of additional not initialized variables that aren't listed
  FOR_IN_OF_INVALID_ELEMENT_TYPE:
    problemMessage: "The type '{0}' used in the 'for' loop must implement '{1}' with a type argument that can be assigned to '{2}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the iterable expression.
      1: the sequence type -- Iterable for `for` or Stream for `await for`.
      2: the loop variable type.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the `Iterable` or `Stream` in a
      for-in loop has an element type that can't be assigned to the loop
      variable.

      #### Example

      The following code produces this diagnostic because `<String>[]` has an
      element type of `String`, and `String` can't be assigned to the type of `e`
      (`int`):

      ```dart
      void f() {
        for (int e in [!<String>[]!]) {
          print(e);
        }
      }
      ```

      #### Common fixes

      If the type of the loop variable is correct, then update the type of the
      iterable:

      ```dart
      void f() {
        for (int e in <int>[]) {
          print(e);
        }
      }
      ```

      If the type of the iterable is correct, then update the type of the loop
      variable:

      ```dart
      void f() {
        for (String e in <String>[]) {
          print(e);
        }
      }
      ```
  FOR_IN_OF_INVALID_TYPE:
    problemMessage: "The type '{0}' used in the 'for' loop must implement {1}."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the iterable expression.
      1: the sequence type -- Iterable for `for` or Stream for `await for`.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression following `in` in
      a for-in loop has a type that isn't a subclass of `Iterable`.

      #### Example

      The following code produces this diagnostic because `m` is a `Map`, and
      `Map` isn't a subclass of `Iterable`:

      ```dart
      void f(Map<String, String> m) {
        for (String s in [!m!]) {
          print(s);
        }
      }
      ```

      #### Common fixes

      Replace the expression with one that produces an iterable value:

      ```dart
      void f(Map<String, String> m) {
        for (String s in m.values) {
          print(s);
        }
      }
      ```
  FOR_IN_WITH_CONST_VARIABLE:
    problemMessage: "A for-in loop variable can't be a 'const'."
    correctionMessage: "Try removing the 'const' modifier from the variable, or use a different variable."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the loop variable declared in a
      for-in loop is declared to be a `const`. The variable can't be a `const`
      because the value can't be computed at compile time.

      #### Example

      The following code produces this diagnostic because the loop variable `x`
      is declared to be a `const`:

      ```dart
      void f() {
        for ([!const!] x in [0, 1, 2]) {
          print(x);
        }
      }
      ```

      #### Common fixes

      If there's a type annotation, then remove the `const` modifier from the
      declaration.

      If there's no type, then replace the `const` modifier with `final`, `var`,
      or a type annotation:

      ```dart
      void f() {
        for (final x in [0, 1, 2]) {
          print(x);
        }
      }
      ```
  GENERIC_FUNCTION_TYPE_CANNOT_BE_BOUND:
    problemMessage: "Generic function types can't be used as type parameter bounds"
    correctionMessage: Try making the free variable in the function type part of the larger declaration signature
    comment: |-
      It is a compile-time error if a generic function type is used as a bound
      for a formal type parameter of a class or a function.
  GENERIC_FUNCTION_TYPE_CANNOT_BE_TYPE_ARGUMENT:
    problemMessage: "A generic function type can't be a type argument."
    correctionMessage: "Try removing type parameters from the generic function type, or using 'dynamic' as the type argument here."
    comment: |-
      It is a compile-time error if a generic function type is used as an actual
      type argument.
  GENERIC_METHOD_TYPE_INSTANTIATION_ON_DYNAMIC:
    problemMessage: "A method tear-off on a receiver whose type is 'dynamic' can't have type arguments."
    correctionMessage: Specify the type of the receiver, or remove the type arguments from the method tear-off.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an instance method is being torn
      off from a receiver whose type is `dynamic`, and the tear-off includes type
      arguments. Because the analyzer can't know how many type parameters the
      method has, or whether it has any type parameters, there's no way it can
      validate that the type arguments are correct. As a result, the type
      arguments aren't allowed.

      #### Example

      The following code produces this diagnostic because the type of `p` is
      `dynamic` and the tear-off of `m` has type arguments:

      ```dart
      void f(dynamic list) {
        [!list.fold!]<int>;
      }
      ```

      #### Common fixes

      If you can use a more specific type than `dynamic`, then change the type of
      the receiver:

      ```dart
      void f(List<Object> list) {
        list.fold<int>;
      }
      ```

      If you can't use a more specific type, then remove the type arguments:

      ```dart
      void f(dynamic list) {
        list.cast;
      }
      ```
  GETTER_NOT_ASSIGNABLE_SETTER_TYPES:
    problemMessage: "The return type of getter '{0}' is '{1}' which isn't assignable to the type '{2}' of its setter '{3}'."
    correctionMessage: Try changing the types so that they are compatible.
    comment: |-
      Parameters:
      0: the name of the getter
      1: the type of the getter
      2: the type of the setter
      3: the name of the setter
  GETTER_NOT_SUBTYPE_SETTER_TYPES:
    problemMessage: "The return type of getter '{0}' is '{1}' which isn't a subtype of the type '{2}' of its setter '{3}'."
    correctionMessage: Try changing the types so that they are compatible.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the getter
      1: the type of the getter
      2: the type of the setter
      3: the name of the setter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the return type of a getter
      isn't a subtype of the type of the parameter of a setter with the same
      name.

      The subtype relationship is a requirement whether the getter and setter are
      in the same class or whether one of them is in a superclass of the other.

      #### Example

      The following code produces this diagnostic because the return type of the
      getter `x` is `num`, the parameter type of the setter `x` is `int`, and
      `num` isn't a subtype of `int`:

      ```dart
      class C {
        num get [!x!] => 0;

        set x(int y) {}
      }
      ```

      #### Common fixes

      If the type of the getter is correct, then change the type of the setter:

      ```dart
      class C {
        num get x => 0;

        set x(num y) {}
      }
      ```

      If the type of the setter is correct, then change the type of the getter:

      ```dart
      class C {
        int get x => 0;

        set x(int y) {}
      }
      ```
  IF_ELEMENT_CONDITION_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used as values in an if condition inside a const collection literal."
    correctionMessage: Try making the deferred import non-deferred.
  ILLEGAL_ASYNC_GENERATOR_RETURN_TYPE:
    problemMessage: "Functions marked 'async*' must have a return type that is a supertype of 'Stream<T>' for some type 'T'."
    correctionMessage: "Try fixing the return type of the function, or removing the modifier 'async*' from the function body."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a function has the
      `async*` modifier even though the return type of the function isn't either
      `Stream` or a supertype of `Stream`.

      #### Example

      The following code produces this diagnostic because the body of the
      function `f` has the 'async*' modifier even though the return type `int`
      isn't a supertype of `Stream`:

      ```dart
      [!int!] f() async* {}
      ```

      #### Common fixes

      If the function should be asynchronous, then change the return type to be
      either `Stream` or a supertype of `Stream`:

      ```dart
      Stream<int> f() async* {}
      ```

      If the function should be synchronous, then remove the `async*` modifier:

      ```dart
      int f() => 0;
      ```
  ILLEGAL_ASYNC_RETURN_TYPE:
    problemMessage: "Functions marked 'async' must have a return type assignable to 'Future'."
    correctionMessage: "Try fixing the return type of the function, or removing the modifier 'async' from the function body."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a function has the
      `async` modifier even though the return type of the function isn't
      assignable to `Future`.

      #### Example

      The following code produces this diagnostic because the body of the
      function `f` has the `async` modifier even though the return type isn't
      assignable to `Future`:

      ```dart
      [!int!] f() async {
        return 0;
      }
      ```

      #### Common fixes

      If the function should be asynchronous, then change the return type to be
      assignable to `Future`:

      ```dart
      Future<int> f() async {
        return 0;
      }
      ```

      If the function should be synchronous, then remove the `async` modifier:

      ```dart
      int f() => 0;
      ```
  ILLEGAL_ENUM_VALUES_DECLARATION:
    sharedName: ILLEGAL_ENUM_VALUES
    problemMessage: An instance member named 'values' can't be declared in a class that implements 'Enum'.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when either a class that implements
      `Enum` or a mixin with a superclass constraint of `Enum` has an instance
      member named `values`.
      
      #### Examples
      
      The following code produces this diagnostic because the class `C`, which
      implements `Enum`, declares an instance field named `values`:
      
      ```dart
      abstract class C implements Enum {
        int get [!values!] => 0;
      }
      ```
      
      The following code produces this diagnostic because the class `B`, which
      implements `Enum`, inherits an instance method named `values` from `A`:
      
      ```dart
      abstract class A {
        int values() => 0;
      }
      
      abstract class [!B!] extends A implements Enum {}
      ```
      
      #### Common fixes
      
      Change the name of the conflicting member:
      
      ```dart
      abstract class C implements Enum {
        int get value => 0;
      }
      ```
  ILLEGAL_ENUM_VALUES_INHERITANCE:
    sharedName: ILLEGAL_ENUM_VALUES
    problemMessage: An instance member named 'values' can't be inherited from '{0}' in a class that implements 'Enum'.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class that declares 'values'
  ILLEGAL_LANGUAGE_VERSION_OVERRIDE:
    problemMessage: The language version must be {0}.
    correctionMessage: Try removing the language version override and migrating the code.
  ILLEGAL_CONCRETE_ENUM_MEMBER_DECLARATION:
    sharedName: ILLEGAL_CONCRETE_ENUM_MEMBER
    problemMessage: A concrete instance member named '{0}' can't be declared in a class that implements 'Enum'.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of member that cannot be declared
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when either an enum declaration, a
      class that implements `Enum`, or a mixin with a superclass constraint of
      `Enum`, declares or inherits a concrete instance member named either
      `index`, `hashCode`, or `==`.
      
      #### Examples
      
      The following code produces this diagnostic because the enum `E` declares
      an instance getter named `index`:
      
      ```dart
      enum E {
        v;
      
        int get [!index!] => 0;
      }
      ```
      
      The following code produces this diagnostic because the class `C`, which
      implements `Enum`, declares an instance field named `hashCode`:
      
      ```dart
      abstract class C implements Enum {
        int [!hashCode!] = 0;
      }
      ```
      
      The following code produces this diagnostic because the class `C`, which
      indirectly implements `Enum` through the class `A`, declares an instance
      getter named `hashCode`:
      
      ```dart
      abstract class A implements Enum {}
      
      abstract class C implements A {
        int get [!hashCode!] => 0;
      }
      ```
      
      The following code produces this diagnostic because the mixin `M`, which
      has `Enum` in the `on` clause, declares an explicit operator named `==`:
      
      ```dart
      mixin M on Enum {
        bool operator [!==!](Object? other) => false;
      }
      ```
      
      #### Common fixes
      
      Rename the conflicting member:
      
      ```dart
      enum E {
        v;
      
        int get getIndex => 0;
      }
      ```
  ILLEGAL_CONCRETE_ENUM_MEMBER_INHERITANCE:
    sharedName: ILLEGAL_CONCRETE_ENUM_MEMBER
    problemMessage: A concrete instance member named '{0}' can't be inherited from '{1}' in a class that implements 'Enum'.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of member that cannot be inherited
      1: the name of the class that declares the member
  ILLEGAL_SYNC_GENERATOR_RETURN_TYPE:
    problemMessage: "Functions marked 'sync*' must have a return type that is a supertype of 'Iterable<T>' for some type 'T'."
    correctionMessage: "Try fixing the return type of the function, or removing the modifier 'sync*' from the function body."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a function has the
      `sync*` modifier even though the return type of the function isn't either
      `Iterable` or a supertype of `Iterable`.

      #### Example

      The following code produces this diagnostic because the body of the
      function `f` has the 'sync*' modifier even though the return type `int`
      isn't a supertype of `Iterable`:

      ```dart
      [!int!] f() sync* {}
      ```

      #### Common fixes

      If the function should return an iterable, then change the return type to
      be either `Iterable` or a supertype of `Iterable`:

      ```dart
      Iterable<int> f() sync* {}
      ```

      If the function should return a single value, then remove the `sync*`
      modifier:

      ```dart
      int f() => 0;
      ```
  IMPLEMENTS_NON_CLASS:
    problemMessage: Classes and mixins can only implement other classes and mixins.
    correctionMessage: Try specifying a class or mixin, or remove the name from the list.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the interface that was not found
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name used in the `implements`
      clause of a class or mixin declaration is defined to be something other
      than a class or mixin.

      #### Example

      The following code produces this diagnostic because `x` is a variable
      rather than a class or mixin:

      ```dart
      var x;
      class C implements [!x!] {}
      ```

      #### Common fixes

      If the name is the name of an existing class or mixin that's already being
      imported, then add a prefix to the import so that the local definition of
      the name doesn't shadow the imported name.

      If the name is the name of an existing class or mixin that isn't being
      imported, then add an import, with a prefix, for the library in which it’s
      declared.

      Otherwise, either replace the name in the `implements` clause with the name
      of an existing class or mixin, or remove the name from the `implements`
      clause.
  IMPLEMENTS_REPEATED:
    problemMessage: "'{0}' can only be implemented once."
    correctionMessage: Try removing all but one occurrence of the class name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the interface that is implemented more than once
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a single class is specified more
      than once in an `implements` clause.

      #### Example

      The following code produces this diagnostic because `A` is in the list
      twice:

      ```dart
      class A {}
      class B implements A, [!A!] {}
      ```

      #### Common fixes

      Remove all except one occurrence of the class name:

      ```dart
      class A {}
      class B implements A {}
      ```
  IMPLEMENTS_SUPER_CLASS:
    problemMessage: "'{0}' can't be used in both the 'extends' and 'implements' clauses."
    correctionMessage: Try removing one of the occurrences.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class that appears in both "extends" and "implements"
         clauses
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when one class is listed in both the
      `extends` and `implements` clauses of another class.

      #### Example

      The following code produces this diagnostic because the class `A` is used
      in both the `extends` and `implements` clauses for the class `B`:

      ```dart
      class A {}

      class B extends A implements [!A!] {}
      ```

      #### Common fixes

      If you want to inherit the implementation from the class, then remove the
      class from the `implements` clause:

      ```dart
      class A {}

      class B extends A {}
      ```

      If you don't want to inherit the implementation from the class, then remove
      the `extends` clause:

      ```dart
      class A {}

      class B implements A {}
      ```
  IMPLICIT_THIS_REFERENCE_IN_INITIALIZER:
    problemMessage: "The instance member '{0}' can't be accessed in an initializer."
    correctionMessage: Try replacing the reference to the instance member with a different expression
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the instance member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a reference to an
      instance member in a constructor's initializer list.

      #### Example

      The following code produces this diagnostic because `defaultX` is an
      instance member:

      ```dart
      class C {
        int x;

        C() : x = [!defaultX!];

        int get defaultX => 0;
      }
      ```

      #### Common fixes

      If the member can be made static, then do so:

      ```dart
      class C {
        int x;

        C() : x = defaultX;

        static int get defaultX => 0;
      }
      ```

      If not, then replace the reference in the initializer with a different
      expression that doesn't use an instance member:

      ```dart
      class C {
        int x;

        C() : x = 0;

        int get defaultX => 0;
      }
      ```
  IMPLICIT_SUPER_INITIALIZER_MISSING_ARGUMENTS:
    problemMessage: The implicitly invoked unnamed constructor from '{0}' has required parameters.
    correctionMessage: Try adding an explicit super parameter with the required arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the superclass
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a constructor implicitly
      invokes the unnamed constructor from the superclass, the unnamed
      constructor of the superclass has a required parameter, and there's no
      super parameter corresponding to the required parameter.
      
      #### Examples
      
      The following code produces this diagnostic because the unnamed
      constructor in the class `B` implicitly invokes the unnamed constructor in
      the class `A`, but the constructor in `A` has a required positional
      parameter named `x`:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        [!B!]();
      }
      ```
      
      The following code produces this diagnostic because the unnamed
      constructor in the class `B` implicitly invokes the unnamed constructor in
      the class `A`, but the constructor in `A` has a required named parameter
      named `x`:
      
      ```dart
      class A {
        A({required int x});
      }
      
      class B extends A {
        [!B!]();
      }
      ```
      
      #### Common fixes
      
      If you can add a parameter to the constructor in the subclass, then add a
      super parameter corresponding to the required parameter in the superclass'
      constructor. The new parameter can either be required:
      
      ```dart
      class A {
        A({required int x});
      }
      
      class B extends A {
        B({required super.x});
      }
      ```
      
      or it can be optional:
      
      ```dart
      class A {
        A({required int x});
      }
      
      class B extends A {
        B({super.x = 0});
      }
      ```
      
      If you can't add a parameter to the constructor in the subclass, then add
      an explicit super constructor invocation with the required argument:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        B() : super(0);
      }
      ```
  IMPORT_INTERNAL_LIBRARY:
    problemMessage: "The library '{0}' is internal and can't be imported."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the uri pointing to a library
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an import whose `dart:`
      URI references an internal library.

      #### Example

      The following code produces this diagnostic because `_interceptors` is an
      internal library:

      ```dart
      import [!'dart:_interceptors'!];
      ```

      #### Common fixes

      Remove the import directive.
  IMPORT_OF_NON_LIBRARY:
    problemMessage: "The imported library '{0}' can't have a part-of directive."
    correctionMessage: Try importing the library that the part is a part of.
    comment: |-
      Parameters:
      0: the uri pointing to a non-library declaration
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a [part file][] is imported
      into a library.

      #### Example

      Given a [part file][] named `part.dart` containing the following:

      ```dart
      %uri="lib/part.dart"
      part of lib;

      class C{}
      ```

      The following code produces this diagnostic because imported files can't
      have a part-of directive:

      ```dart
      library lib;

      import [!'part.dart'!];

      C c = C();
      ```

      #### Common fixes

      Import the library that contains the [part file][] rather than the
      [part file][] itself.
  INCONSISTENT_CASE_EXPRESSION_TYPES:
    problemMessage: "Case expressions must have the same types, '{0}' isn't a '{1}'."
    comment: |-
      13.9 Switch: It is a compile-time error if values of the expressions
      <i>e<sub>k</sub></i> are not instances of the same class <i>C</i>, for all
      <i>1 &lt;= k &lt;= n</i>.

      Parameters:
      0: the expression source code that is the unexpected type
      1: the name of the expected type
  INCONSISTENT_INHERITANCE:
    problemMessage: "Superinterfaces don't have a valid override for '{0}': {1}."
    correctionMessage: Try adding an explicit override that is consistent with all of the inherited members.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the instance member with inconsistent inheritance.
      1: the list of all inherited signatures for this member.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class inherits two or more
      conflicting signatures for a member and doesn't provide an implementation
      that satisfies all the inherited signatures.

      #### Example

      The following code produces this diagnostic because `C` is inheriting the
      declaration of `m` from `A`, and that implementation isn't consistent with
      the signature of `m` that's inherited from `B`:

      ```dart
      %language=2.9
      class A {
        void m({int a}) {}
      }

      class B {
        void m({int b}) {}
      }

      class [!C!] extends A implements B {
      }
      ```

      #### Common fixes

      Add an implementation of the method that satisfies all the inherited
      signatures:

      ```dart
      %language=2.9
      class A {
        void m({int a}) {}
      }

      class B {
        void m({int b}) {}
      }

      class C extends A implements B {
        void m({int a, int b}) {}
      }
      ```
  INCONSISTENT_INHERITANCE_GETTER_AND_METHOD:
    problemMessage: "'{0}' is inherited as a getter (from '{1}') and also a method (from '{2}')."
    correctionMessage: Try adjusting the supertypes of this class to remove the inconsistency.
    comment: |-
      11.1.1 Inheritance and Overriding. Let `I` be the implicit interface of a
      class `C` declared in library `L`. `I` inherits all members of
      `inherited(I, L)` and `I` overrides `m'` if `m' ∈ overrides(I, L)`. It is
      a compile-time error if `m` is a method and `m'` is a getter, or if `m`
      is a getter and `m'` is a method.

      Parameters:
      0: the name of the instance member with inconsistent inheritance.
      1: the name of the superinterface that declares the name as a getter.
      2: the name of the superinterface that declares the name as a method.
  INCONSISTENT_LANGUAGE_VERSION_OVERRIDE:
    problemMessage: Parts must have exactly the same language version override as the library.
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a [part file][] has a language
      version override comment that specifies a different language version than
      the one being used for the library to which the part belongs.

      #### Example

      Given a [part file][] named `part.dart` that contains the following:

      ```dart
      %uri="lib/part.dart"
      // @dart = 2.6
      part of 'test.dart';
      ```

      The following code produces this diagnostic because the parts of a library
      must have the same language version as the defining compilation unit:

      ```dart
      // @dart = 2.5
      part [!'part.dart'!];
      ```

      #### Common fixes

      Remove the language version override from the [part file][], so that it
      implicitly uses the same version as the defining compilation unit:

      ```dart
      part of 'test.dart';
      ```

      If necessary, either adjust the language version override in the defining
      compilation unit to be appropriate for the code in the part, or migrate
      the code in the [part file][] to be consistent with the new language
      version.
  INITIALIZER_FOR_NON_EXISTENT_FIELD:
    problemMessage: "'{0}' isn't a field in the enclosing class."
    correctionMessage: "Try correcting the name to match an existing field, or defining a field named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the initializing formal that is not an instance variable in
         the immediately enclosing class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor initializes a
      field that isn't declared in the class containing the constructor.
      Constructors can't initialize fields that aren't declared and fields that
      are inherited from superclasses.

      #### Example

      The following code produces this diagnostic because the initializer is
      initializing `x`, but `x` isn't a field in the class:

      ```dart
      %language=2.9
      class C {
        int y;

        C() : [!x = 0!];
      }
      ```

      #### Common fixes

      If a different field should be initialized, then change the name to the
      name of the field:

      ```dart
      %language=2.9
      class C {
        int y;

        C() : y = 0;
      }
      ```

      If the field must be declared, then add a declaration:

      ```dart
      %language=2.9
      class C {
        int x;
        int y;

        C() : x = 0;
      }
      ```
  INITIALIZER_FOR_STATIC_FIELD:
    problemMessage: "'{0}' is a static field in the enclosing class. Fields initialized in a constructor can't be static."
    correctionMessage: Try removing the initialization.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the initializing formal that is a static variable in the
         immediately enclosing class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a static field is initialized
      in a constructor using either an initializing formal parameter or an
      assignment in the initializer list.

      #### Example

      The following code produces this diagnostic because the static field `a`
      is being initialized by the initializing formal parameter `this.a`:

      ```dart
      class C {
        static int? a;
        C([!this.a!]);
      }
      ```

      #### Common fixes

      If the field should be an instance field, then remove the keyword `static`:

      ```dart
      class C {
        int? a;
        C(this.a);
      }
      ```

      If you intended to initialize an instance field and typed the wrong name,
      then correct the name of the field being initialized:

      ```dart
      class C {
        static int? a;
        int? b;
        C(this.b);
      }
      ```

      If you really want to initialize the static field, then move the
      initialization into the constructor body:

      ```dart
      class C {
        static int? a;
        C(int? c) {
          a = c;
        }
      }
      ```
  INITIALIZING_FORMAL_FOR_NON_EXISTENT_FIELD:
    problemMessage: "'{0}' isn't a field in the enclosing class."
    correctionMessage: "Try correcting the name to match an existing field, or defining a field named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the initializing formal that is not an instance variable in
         the immediately enclosing class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an initializing formal
      parameter is found in a constructor in a class that doesn't declare the
      field being initialized. Constructors can't initialize fields that aren't
      declared and fields that are inherited from superclasses.

      #### Example

      The following code produces this diagnostic because the field `x` isn't
      defined:

      ```dart
      %language=2.9
      class C {
        int y;

        C([!this.x!]);
      }
      ```

      #### Common fixes

      If the field name was wrong, then change it to the name of an existing
      field:

      ```dart
      %language=2.9
      class C {
        int y;

        C(this.y);
      }
      ```

      If the field name is correct but hasn't yet been defined, then declare the
      field:

      ```dart
      %language=2.9
      class C {
        int x;
        int y;

        C(this.x);
      }
      ```

      If the parameter is needed but shouldn't initialize a field, then convert
      it to a normal parameter and use it:

      ```dart
      %language=2.9
      class C {
        int y;

        C(int x) : y = x * 2;
      }
      ```

      If the parameter isn't needed, then remove it:

      ```dart
      %language=2.9
      class C {
        int y;

        C();
      }
      ```
  INSTANCE_ACCESS_TO_STATIC_MEMBER:
    problemMessage: "The static {1} '{0}' can't be accessed through an instance."
    correctionMessage: "Try using the {3} '{2}' to access the {1}."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the static member
      1: the kind of the static member (field, getter, setter, or method)
      2: the name of the static member's enclosing element
      3: the kind of the static member's enclosing element (class, mixin, or extension)
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an access operator is used to
      access a static member through an instance of the class.

      #### Example

      The following code produces this diagnostic because `zero` is a static
      field, but it’s being accessed as if it were an instance field:

      ```dart
      void f(C c) {
        c.[!zero!];
      }

      class C {
        static int zero = 0;
      }
      ```

      #### Common fixes

      Use the class to access the static member:

      ```dart
      void f(C c) {
        C.zero;
      }

      class C {
        static int zero = 0;
      }
      ```
  INSTANCE_ACCESS_TO_STATIC_MEMBER_OF_UNNAMED_EXTENSION:
    sharedName: INSTANCE_ACCESS_TO_STATIC_MEMBER
    problemMessage: "The static {1} '{0}' can't be accessed through an instance."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the static member
      1: the kind of the static member (field, getter, setter, or method)
  INSTANCE_MEMBER_ACCESS_FROM_FACTORY:
    problemMessage: "Instance members can't be accessed from a factory constructor."
    correctionMessage: Try removing the reference to the instance member.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a factory constructor contains
      an unqualified reference to an instance member. In a generative
      constructor, the instance of the class is created and initialized before
      the body of the constructor is executed, so the instance can be bound to
      `this` and accessed just like it would be in an instance method. But, in a
      factory constructor, the instance isn't created before executing the body,
      so `this` can't be used to reference it.

      #### Example

      The following code produces this diagnostic because `x` isn't in scope in
      the factory constructor:

      ```dart
      class C {
        int x;
        factory C() {
          return C._([!x!]);
        }
        C._(this.x);
      }
      ```

      #### Common fixes

      Rewrite the code so that it doesn't reference the instance member:

      ```dart
      class C {
        int x;
        factory C() {
          return C._(0);
        }
        C._(this.x);
      }
      ```
  INSTANCE_MEMBER_ACCESS_FROM_STATIC:
    problemMessage: "Instance members can't be accessed from a static method."
    correctionMessage: "Try removing the reference to the instance member, or removing the keyword 'static' from the method."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a static method contains an
      unqualified reference to an instance member.

      #### Example

      The following code produces this diagnostic because the instance field `x`
      is being referenced in a static method:

      ```dart
      %language=2.9
      class C {
        int x;

        static int m() {
          return [!x!];
        }
      }
      ```

      #### Common fixes

      If the method must reference the instance member, then it can't be static,
      so remove the keyword:

      ```dart
      %language=2.9
      class C {
        int x;

        int m() {
          return x;
        }
      }
      ```

      If the method can't be made an instance method, then add a parameter so
      that an instance of the class can be passed in:

      ```dart
      %language=2.9
      class C {
        int x;

        static int m(C c) {
          return c.x;
        }
      }
      ```
  INSTANTIATE_ABSTRACT_CLASS:
    problemMessage: "Abstract classes can't be instantiated."
    correctionMessage: Try creating an instance of a concrete subtype.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a constructor
      invocation and the constructor is declared in an abstract class. Even
      though you can't create an instance of an abstract class, abstract classes
      can declare constructors that can be invoked by subclasses.

      #### Example

      The following code produces this diagnostic because `C` is an abstract
      class:

      ```dart
      abstract class C {}

      var c = new [!C!]();
      ```

      #### Common fixes

      If there's a concrete subclass of the abstract class that can be used, then
      create an instance of the concrete subclass.
  INSTANTIATE_ENUM:
    problemMessage: "Enums can't be instantiated."
    correctionMessage: Try using one of the defined constants.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an enum is instantiated. It's
      invalid to create an instance of an enum by invoking a constructor; only
      the instances named in the declaration of the enum can exist.

      #### Example

      The following code produces this diagnostic because the enum `E` is being
      instantiated:

      ```dart
      // @dart = 2.16
      enum E {a}

      var e = [!E!]();
      ```

      #### Common fixes

      If you intend to use an instance of the enum, then reference one of the
      constants defined in the enum:

      ```dart
      // @dart = 2.16
      enum E {a}

      var e = E.a;
      ```

      If you intend to use an instance of a class, then use the name of that class in place of the name of the enum.
  INSTANTIATE_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    problemMessage: "Type aliases that expand to a type parameter can't be instantiated."
    correctionMessage: Try replacing it with a class.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor invocation is
      found where the type being instantiated is a type alias for one of the type
      parameters of the type alias. This isn’t allowed because the value of the
      type parameter is a type rather than a class.

      #### Example

      The following code produces this diagnostic because it creates an instance
      of `A`, even though `A` is a type alias that is defined to be equivalent to
      a type parameter:

      ```dart
      typedef A<T> = T;

      void f() {
        const [!A!]<int>();
      }
      ```

      #### Common fixes

      Use either a class name or a type alias defined to be a class, rather than
      a type alias defined to be a type parameter:

      ```dart
      typedef A<T> = C<T>;

      void f() {
        const A<int>();
      }

      class C<T> {
        const C();
      }
      ```
  INTEGER_LITERAL_IMPRECISE_AS_DOUBLE:
    problemMessage: "The integer literal is being used as a double, but can't be represented as a 64-bit double without overflow or loss of precision: '{0}'."
    correctionMessage: "Try using the class 'BigInt', or switch to the closest valid double: '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the lexeme of the integer
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an integer literal is being
      implicitly converted to a double, but can't be represented as a 64-bit
      double without overflow or loss of precision. Integer literals are
      implicitly converted to a double if the context requires the type `double`.

      #### Example

      The following code produces this diagnostic because the integer value
      `9223372036854775807` can't be represented exactly as a double:

      ```dart
      double x = [!9223372036854775807!];
      ```

      #### Common fixes

      If you need to use the exact value, then use the class `BigInt` to
      represent the value:

      ```dart
      var x = BigInt.parse('9223372036854775807');
      ```

      If you need to use a double, then change the value to one that can be
      represented exactly:

      ```dart
      double x = 9223372036854775808;
      ```
  INTEGER_LITERAL_OUT_OF_RANGE:
    problemMessage: "The integer literal {0} can't be represented in 64 bits."
    correctionMessage: "Try using the 'BigInt' class if you need an integer larger than 9,223,372,036,854,775,807 or less than -9,223,372,036,854,775,808."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an integer literal has a value
      that is too large (positive) or too small (negative) to be represented in a
      64-bit word.

      #### Example

      The following code produces this diagnostic because the value can't be
      represented in 64 bits:

      ```dart
      var x = [!9223372036854775810!];
      ```

      #### Common fixes

      If you need to represent the current value, then wrap it in an instance of
      the class `BigInt`:

      ```dart
      var x = BigInt.parse('9223372036854775810');
      ```
  INVALID_ANNOTATION:
    problemMessage: Annotation must be either a const variable reference or const constructor invocation.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an annotation is found that is
      using something that is neither a variable marked as `const` or the
      invocation of a `const` constructor.

      Getters can't be used as annotations.

      #### Examples

      The following code produces this diagnostic because the variable `v` isn't
      a `const` variable:

      ```dart
      var v = 0;

      [!@v!]
      void f() {
      }
      ```

      The following code produces this diagnostic because `f` isn't a variable:

      ```dart
      [!@f!]
      void f() {
      }
      ```

      The following code produces this diagnostic because `f` isn't a
      constructor:

      ```dart
      [!@f()!]
      void f() {
      }
      ```

      The following code produces this diagnostic because `g` is a getter:

      ```dart
      [!@g!]
      int get g => 0;
      ```

      #### Common fixes

      If the annotation is referencing a variable that isn't a `const`
      constructor, add the keyword `const` to the variable's declaration:

      ```dart
      const v = 0;

      @v
      void f() {
      }
      ```

      If the annotation isn't referencing a variable, then remove it:

      ```dart
      int v = 0;

      void f() {
      }
      ```
  INVALID_ANNOTATION_CONSTANT_VALUE_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used in annotations."
    correctionMessage: "Try moving the constant from the deferred library, or removing 'deferred' from the import."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constant defined in a library
      that is imported as a deferred library is referenced in the argument list
      of an annotation. Annotations are evaluated at compile time, and values
      from deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      The following code produces this diagnostic because the constant `pi` is
      being referenced in the argument list of an annotation, even though the
      library that defines it is being imported as a deferred library:

      ```dart
      import 'dart:math' deferred as math;

      class C {
        const C(double d);
      }

      @C([!math.pi!])
      void f () {}
      ```

      #### Common fixes

      If you need to reference the imported constant, then remove the `deferred`
      keyword:

      ```dart
      import 'dart:math' as math;

      class C {
        const C(double d);
      }

      @C(math.pi)
      void f () {}
      ```

      If the import is required to be deferred and there's another constant that
      is appropriate, then use that constant in place of the constant from the
      deferred library.
  INVALID_ANNOTATION_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used as annotations."
    correctionMessage: Try removing the annotation, or changing the import to not be deferred.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constant from a library that
      is imported using a deferred import is used as an annotation. Annotations
      are evaluated at compile time, and constants from deferred libraries aren't
      available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      The following code produces this diagnostic because the constant `pi` is
      being used as an annotation when the library `dart:math` is imported as
      `deferred`:

      ```dart
      import 'dart:math' deferred as math;

      @[!math.pi!]
      void f() {}
      ```

      #### Common fixes

      If you need to reference the constant as an annotation, then remove the
      keyword `deferred` from the import:

      ```dart
      import 'dart:math' as math;

      @math.pi
      void f() {}
      ```

      If you can use a different constant as an annotation, then replace the
      annotation with a different constant:

      ```dart
      @deprecated
      void f() {}
      ```
  INVALID_ASSIGNMENT:
    problemMessage: "A value of type '{0}' can't be assigned to a variable of type '{1}'."
    correctionMessage: "Try changing the type of the variable, or casting the right-hand type to '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the right hand side type
      1: the name of the left hand side type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the static type of an expression
      that is assigned to a variable isn't assignable to the type of the
      variable.

      #### Example

      The following code produces this diagnostic because the type of the
      initializer (`int`) isn't assignable to the type of the variable
      (`String`):

      ```dart
      int i = 0;
      String s = [!i!];
      ```

      #### Common fixes

      If the value being assigned is always assignable at runtime, even though
      the static types don't reflect that, then add an explicit cast.

      Otherwise, change the value being assigned so that it has the expected
      type. In the previous example, this might look like:

      ```dart
      int i = 0;
      String s = i.toString();
      ```

      If you can’t change the value, then change the type of the variable to be
      compatible with the type of the value being assigned:

      ```dart
      int i = 0;
      int s = i;
      ```
  INVALID_CAST_FUNCTION:
    problemMessage: "The function '{0}' has type '{1}' that isn't of expected type '{2}'. This means its parameter or return type doesn't match what is expected."
    comment: |-
      Parameters:
      0: the type of the function
      1: the expected function type
  INVALID_CAST_FUNCTION_EXPR:
    problemMessage: "The function expression type '{0}' isn't of type '{1}'. This means its parameter or return type doesn't match what is expected. Consider changing parameter type(s) or the returned type(s)."
    comment: |-
      Parameters:
      0: the type of the torn-off function expression
      1: the expected function type
  INVALID_CAST_LITERAL:
    problemMessage: "The literal '{0}' with type '{1}' isn't of expected type '{2}'."
    comment: |-
      Parameters:
      0: the type of the literal
      1: the expected type
  INVALID_CAST_LITERAL_LIST:
    problemMessage: "The list literal type '{0}' isn't of expected type '{1}'. The list's type can be changed with an explicit generic type argument or by changing the element types."
    comment: |-
      Parameters:
      0: the type of the list literal
      1: the expected type
  INVALID_CAST_LITERAL_MAP:
    problemMessage: "The map literal type '{0}' isn't of expected type '{1}'. The map's type can be changed with an explicit generic type arguments or by changing the key and value types."
    comment: |-
      Parameters:
      0: the type of the map literal
      1: the expected type
  INVALID_CAST_LITERAL_SET:
    problemMessage: "The set literal type '{0}' isn't of expected type '{1}'. The set's type can be changed with an explicit generic type argument or by changing the element types."
    comment: |-
      Parameters:
      0: the type of the set literal
      1: the expected type
  INVALID_CAST_METHOD:
    problemMessage: "The method tear-off '{0}' has type '{1}' that isn't of expected type '{2}'. This means its parameter or return type doesn't match what is expected."
    comment: |-
      Parameters:
      0: the type of the torn-off method
      1: the expected function type
  INVALID_CAST_NEW_EXPR:
    problemMessage: "The constructor returns type '{0}' that isn't of expected type '{1}'."
    comment: |-
      Parameters:
      0: the type of the instantiated object
      1: the expected type
  INVALID_CONSTANT:
    problemMessage: Invalid constant value.
    comment: |-
      TODO(brianwilkerson) Remove this when we have decided on how to report
      errors in compile-time constants. Until then, this acts as a placeholder
      for more informative errors.

      See TODOs in ConstantVisitor
  INVALID_EXTENSION_ARGUMENT_COUNT:
    problemMessage: "Extension overrides must have exactly one argument: the value of 'this' in the extension method."
    correctionMessage: Try specifying exactly one argument.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override doesn't
      have exactly one argument. The argument is the expression used to compute
      the value of `this` within the extension method, so there must be one
      argument.

      #### Examples

      The following code produces this diagnostic because there are no arguments:

      ```dart
      extension E on String {
        String join(String other) => '$this $other';
      }

      void f() {
        E[!()!].join('b');
      }
      ```

      And, the following code produces this diagnostic because there's more than
      one argument:

      ```dart
      extension E on String {
        String join(String other) => '$this $other';
      }

      void f() {
        E[!('a', 'b')!].join('c');
      }
      ```

      #### Common fixes

      Provide one argument for the extension override:

      ```dart
      extension E on String {
        String join(String other) => '$this $other';
      }

      void f() {
        E('a').join('b');
      }
      ```
  INVALID_FACTORY_NAME_NOT_A_CLASS:
    problemMessage: The name of a factory constructor must be the same as the name of the immediately enclosing class.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name of a factory
      constructor isn't the same as the name of the surrounding class.

      #### Example

      The following code produces this diagnostic because the name of the factory
      constructor (`A`) isn't the same as the surrounding class (`C`):

      ```dart
      class A {}

      class C {
        factory [!A!]() => throw 0;
      }
      ```

      #### Common fixes

      If the factory returns an instance of the surrounding class, then rename
      the factory:

      ```dart
      class A {}

      class C {
        factory C() => throw 0;
      }
      ```

      If the factory returns an instance of a different class, then move the
      factory to that class:

      ```dart
      class A {
        factory A() => throw 0;
      }

      class C {}
      ```

      If the factory returns an instance of a different class, but you can't
      modify that class or don't want to move the factory, then convert it to be
      a static method:

      ```dart
      class A {}

      class C {
        static A a() => throw 0;
      }
      ```
  INVALID_IMPLEMENTATION_OVERRIDE:
    problemMessage: "'{1}.{0}' ('{2}') isn't a valid concrete implementation of '{3}.{0}' ('{4}')."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the declared member that is not a valid override.
      1: the name of the interface that declares the member.
      2: the type of the declared member in the interface.
      3. the name of the interface with the overridden member.
      4. the type of the overridden member.

      These parameters must be kept in sync with those of
      [CompileTimeErrorCode.INVALID_OVERRIDE].
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when all of the following are true:

      - A class defines an abstract member.
      - There is a concrete implementation of that member in a superclass.
      - The concrete implementation isn't a valid implementation of the abstract
        method.

      The concrete implementation can be invalid because of incompatibilities in
      either the return type, the types of parameters, or the type variables.

      #### Example

      The following code produces this diagnostic because the method `A.add` has
      a parameter of type `int`, and the overriding method `B.add` has a
      corresponding parameter of type `num`:

      ```dart
      class A {
        int add(int a) => a;
      }
      class [!B!] extends A {
        int add(num a);
      }
      ```

      This is a problem because in an invocation of `B.add` like the following:

      ```dart
      void f(B b) {
        b.add(3.4);
      }
      ```

      `B.add` is expecting to be able to take, for example, a `double`, but when
      the method `A.add` is executed (because it's the only concrete
      implementation of `add`), a runtime exception will be thrown because a
      `double` can't be assigned to a parameter of type `int`.

      #### Common fixes

      If the method in the subclass can conform to the implementation in the
      superclass, then change the declaration in the subclass (or remove it if
      it's the same):

      ```dart
      class A {
        int add(int a) => a;
      }
      class B	extends A {
        int add(int a);
      }
      ```

      If the method in the superclass can be generalized to be a valid
      implementation of the method in the subclass, then change the superclass
      method:

      ```dart
      class A {
        int add(num a) => a.floor();
      }
      class B	extends A {
        int add(num a);
      }
      ```

      If neither the method in the superclass nor the method in the subclass can
      be changed, then provide a concrete implementation of the method in the
      subclass:

      ```dart
      class A {
        int add(int a) => a;
      }
      class B	extends A {
        int add(num a) => a.floor();
      }
      ```
  INVALID_INLINE_FUNCTION_TYPE:
    problemMessage: "Inline function types can't be used for parameters in a generic function type."
    correctionMessage: "Try using a generic function type (returnType 'Function(' parameters ')')."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generic function type has a
      function-valued parameter that is written using the older inline function
      type syntax.

      #### Example

      The following code produces this diagnostic because the parameter `f`, in
      the generic function type used to define `F`, uses the inline function
      type syntax:

      ```dart
      typedef F = int Function(int f[!(!]String s));
      ```

      #### Common fixes

      Use the generic function syntax for the parameter's type:

      ```dart
      typedef F = int Function(int Function(String));
      ```
  INVALID_MODIFIER_ON_CONSTRUCTOR:
    problemMessage: "The modifier '{0}' can't be applied to the body of a constructor."
    correctionMessage: Try removing the modifier.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the invalid modifier
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a constructor is
      prefixed by one of the following modifiers: `async`, `async*`, or `sync*`.
      Constructor bodies must be synchronous.

      #### Example

      The following code produces this diagnostic because the body of the
      constructor for `C` is marked as being `async`:

      ```dart
      class C {
        C() [!async!] {}
      }
      ```

      #### Common fixes

      If the constructor can be synchronous, then remove the modifier:

      ```dart
      class C {
        C();
      }
      ```

      If the constructor can't be synchronous, then use a static method to create
      the instance instead:

      ```dart
      class C {
        C();
        static Future<C> c() async {
          return C();
        }
      }
      ```
  INVALID_MODIFIER_ON_SETTER:
    problemMessage: "Setters can't use 'async', 'async*', or 'sync*'."
    correctionMessage: Try removing the modifier.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the invalid modifier
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a setter is prefixed
      by one of the following modifiers: `async`, `async*`, or `sync*`. Setter
      bodies must be synchronous.

      #### Example

      The following code produces this diagnostic because the body of the setter
      `x` is marked as being `async`:

      ```dart
      class C {
        set x(int i) [!async!] {}
      }
      ```

      #### Common fixes

      If the setter can be synchronous, then remove the modifier:

      ```dart
      class C {
        set x(int i) {}
      }
      ```

      If the setter can't be synchronous, then use a method to set the value
      instead:

      ```dart
      class C {
        void x(int i) async {}
      }
      ```
  INVALID_OVERRIDE:
    problemMessage: "'{1}.{0}' ('{2}') isn't a valid override of '{3}.{0}' ('{4}')."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the declared member that is not a valid override.
      1: the name of the interface that declares the member.
      2: the type of the declared member in the interface.
      3. the name of the interface with the overridden member.
      4. the type of the overridden member.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a member of a class is found
      that overrides a member from a supertype and the override isn't valid. An
      override is valid if all of these are true:
      * It allows all of the arguments allowed by the overridden member.
      * It doesn't require any arguments that aren't required by the overridden
        member.
      * The type of every parameter of the overridden member is assignable to the
        corresponding parameter of the override.
      * The return type of the override is assignable to the return type of the
        overridden member.

      #### Example

      The following code produces this diagnostic because the type of the
      parameter `s` (`String`) isn't assignable to the type of the parameter `i`
      (`int`):

      ```dart
      class A {
        void m(int i) {}
      }

      class B extends A {
        void [!m!](String s) {}
      }
      ```

      #### Common fixes

      If the invalid method is intended to override the method from the
      superclass, then change it to conform:

      ```dart
      class A {
        void m(int i) {}
      }

      class B extends A {
        void m(int i) {}
      }
      ```

      If it isn't intended to override the method from the superclass, then
      rename it:

      ```dart
      class A {
        void m(int i) {}
      }

      class B extends A {
        void m2(String s) {}
      }
      ```
  INVALID_REFERENCE_TO_GENERATIVE_ENUM_CONSTRUCTOR:
    problemMessage: Generative enum constructors can only be used as targets of redirection.
    correctionMessage: Try using an enum constant, or a factory constructor.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a generative constructor
      defined on an enum is used anywhere other than to create one of the enum
      constants or as the target of a redirection from another constructor in
      the same enum.
      
      #### Example
      
      The following code produces this diagnostic because the constructor for
      `E` is being used to create an instance in the function `f`:
      
      ```dart
      enum E {
        a(0);
      
        const E(int x);
      }
      
      E f() => const [!E!](2); 
      ```
      
      #### Common fixes
      
      If there's an enum constant with the same value, or if you add such a
      constant, then reference the constant directly:
      
      ```dart
      enum E {
        a(0), b(2);
      
        const E(int x);
      }
      
      E f() => E.b; 
      ```
      
      If you need to use a constructor invocation, then use a factory
      constructor:
      
      ```dart
      enum E {
        a(0);
      
        const E(int x);
      
        factory E.c(int x) => a;
      }
      
      E f() => E.c(2);
      ```
  INVALID_REFERENCE_TO_THIS:
    problemMessage: "Invalid reference to 'this' expression."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when `this` is used outside of an
      instance method or a generative constructor. The reserved word `this` is
      only defined in the context of an instance method or a generative
      constructor.

      #### Example

      The following code produces this diagnostic because `v` is a top-level
      variable:

      ```dart
      C f() => [!this!];

      class C {}
      ```

      #### Common fixes

      Use a variable of the appropriate type in place of `this`, declaring it if
      necessary:

      ```dart
      C f(C c) => c;

      class C {}
      ```
  INVALID_SUPER_FORMAL_PARAMETER_LOCATION:
    problemMessage: Super parameters can only be used in non-redirecting generative constructors.
    correctionMessage: Try removing the 'super' modifier, or changing the constructor to be non-redirecting and generative.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the super modifier
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when a super parameter is used
      anywhere other than a non-redirecting generative constructor.
      
      #### Examples
      
      The following code produces this diagnostic because the super parameter
      `x` is in a redirecting generative constructor:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        B.b([!super!].x) : this._();
        B._() : super(0);
      }
      ```
      
      The following code produces this diagnostic because the super parameter
      `x` isn't in a generative constructor:
      
      ```dart
      class A {
        A(int x);
      }
      
      class C extends A {
        factory C.c([!super!].x) => C._();
        C._() : super(0);
      }
      ```
      
      The following code produces this diagnostic because the super parameter
      `x` is in a method:
      
      ```dart
      class A {
        A(int x);
      }
      
      class D extends A {
        D() : super(0);
      
        void m([!super!].x) {}
      }
      ```
      
      #### Common fixes
      
      If the function containing the super parameter can be changed to be a
      non-redirecting generative constructor, then do so:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        B.b(super.x);
      }
      ```
      
      If the function containing the super parameter can't be changed to be a
      non-redirecting generative constructor, then remove the `super`:
      
      ```dart
      class A {
        A(int x);
      }
      
      class D extends A {
        D() : super(0);
      
        void m(int x) {}
      }
      ```
  INVALID_TYPE_ARGUMENT_IN_CONST_LIST:
    sharedName: INVALID_TYPE_ARGUMENT_IN_CONST_LITERAL
    problemMessage: "Constant list literals can't include a type parameter as a type argument, such as '{0}'."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type parameter is used as a
      type argument in a list, map, or set literal that is prefixed by `const`.
      This isn't allowed because the value of the type parameter (the actual type
      that will be used at runtime) can't be known at compile time.

      #### Examples

      The following code produces this diagnostic because the type parameter `T`
      is being used as a type argument when creating a constant list:

      ```dart
      List<T> newList<T>() => const <[!T!]>[];
      ```

      The following code produces this diagnostic because the type parameter `T`
      is being used as a type argument when creating a constant map:

      ```dart
      Map<String, T> newSet<T>() => const <String, [!T!]>{};
      ```

      The following code produces this diagnostic because the type parameter `T`
      is being used as a type argument when creating a constant set:

      ```dart
      Set<T> newSet<T>() => const <[!T!]>{};
      ```

      #### Common fixes

      If the type that will be used for the type parameter can be known at
      compile time, then remove the type parameter:

      ```dart
      List<int> newList() => const <int>[];
      ```

      If the type that will be used for the type parameter can't be known until
      runtime, then remove the keyword `const`:

      ```dart
      List<T> newList<T>() => <T>[];
      ```
  INVALID_TYPE_ARGUMENT_IN_CONST_MAP:
    sharedName: INVALID_TYPE_ARGUMENT_IN_CONST_LITERAL
    problemMessage: "Constant map literals can't include a type parameter as a type argument, such as '{0}'."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type parameter
  INVALID_TYPE_ARGUMENT_IN_CONST_SET:
    sharedName: INVALID_TYPE_ARGUMENT_IN_CONST_LITERAL
    problemMessage: "Constant set literals can't include a type parameter as a type argument, such as '{0}'."
    correctionMessage: Try replacing the type parameter with a different type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type parameter
  INVALID_URI:
    problemMessage: "Invalid URI syntax: '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the URI that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a URI in a directive doesn't
      conform to the syntax of a valid URI.

      #### Example

      The following code produces this diagnostic because `'#'` isn't a valid
      URI:

      ```dart
      import [!'#'!];
      ```

      #### Common fixes

      Replace the invalid URI with a valid URI.
  INVALID_USE_OF_COVARIANT:
    problemMessage: "The 'covariant' keyword can only be used for parameters in instance methods or before non-final instance fields."
    correctionMessage: "Try removing the 'covariant' keyword."
    comment: "The 'covariant' keyword was found in an inappropriate location."
  INVALID_USE_OF_NULL_VALUE:
    problemMessage: "An expression whose value is always 'null' can't be dereferenced."
    correctionMessage: Try changing the type of the expression.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an expression whose value will
      always be `null` is dereferenced.

      #### Example

      The following code produces this diagnostic because `x` will always be
      `null`:

      ```dart
      int f(Null x) {
        return [!x!].length;
      }
      ```

      #### Common fixes

      If the value is allowed to be something other than `null`, then change the
      type of the expression:

      ```dart
      int f(String? x) {
        return x!.length;
      }
      ```
  INVOCATION_OF_EXTENSION_WITHOUT_CALL:
    problemMessage: "The extension '{0}' doesn't define a 'call' method so the override can't be used in an invocation."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the extension
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is used to
      invoke a function but the extension doesn't declare a `call` method.

      #### Example

      The following code produces this diagnostic because the extension `E`
      doesn't define a `call` method:

      ```dart
      extension E on String {}

      void f() {
        [!E('')!]();
      }
      ```

      #### Common fixes

      If the extension is intended to define a `call` method, then declare it:

      ```dart
      extension E on String {
        int call() => 0;
      }

      void f() {
        E('')();
      }
      ```

      If the extended type defines a `call` method, then remove the extension
      override.

      If the `call` method isn't defined, then rewrite the code so that it
      doesn't invoke the `call` method.
  INVOCATION_OF_NON_FUNCTION:
    problemMessage: "'{0}' isn't a function."
    correctionMessage: "Try correcting the name to match an existing function, or define a method or function named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the identifier that is not a function type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a function invocation,
      but the name of the function being invoked is defined to be something other
      than a function.

      #### Example

      The following code produces this diagnostic because `Binary` is the name of
      a function type, not a function:

      ```dart
      typedef Binary = int Function(int, int);

      int f() {
        return [!Binary!](1, 2);
      }
      ```

      #### Common fixes

      Replace the name with the name of a function.
  INVOCATION_OF_NON_FUNCTION_EXPRESSION:
    problemMessage: "The expression doesn't evaluate to a function, so it can't be invoked."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a function invocation is found,
      but the name being referenced isn't the name of a function, or when the
      expression computing the function doesn't compute a function.

      #### Examples

      The following code produces this diagnostic because `x` isn't a function:

      ```dart
      int x = 0;

      int f() => x;

      var y = [!x!]();
      ```

      The following code produces this diagnostic because `f()` doesn't return a
      function:

      ```dart
      int x = 0;

      int f() => x;

      var y = [!f()!]();
      ```

      #### Common fixes

      If you need to invoke a function, then replace the code before the argument
      list with the name of a function or with an expression that computes a
      function:

      ```dart
      int x = 0;

      int f() => x;

      var y = f();
      ```
  LABEL_IN_OUTER_SCOPE:
    problemMessage: "Can't reference label '{0}' declared in an outer method."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the unresolvable label
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `break` or `continue`
      statement references a label that is declared in a method or function
      containing the function in which the `break` or `continue` statement
      appears. The `break` and `continue` statements can't be used to transfer
      control outside the function that contains them.

      #### Example

      The following code produces this diagnostic because the label `loop` is
      declared outside the local function `g`:

      ```dart
      void f() {
        loop:
        while (true) {
          void g() {
            break [!loop!];
          }

          g();
        }
      }
      ```

      #### Common fixes

      Try rewriting the code so that it isn't necessary to transfer control
      outside the local function, possibly by inlining the local function:

      ```dart
      void f() {
        loop:
        while (true) {
          break loop;
        }
      }
      ```

      If that isn't possible, then try rewriting the local function so that a
      value returned by the function can be used to determine whether control is
      transferred:

      ```dart
      void f() {
        loop:
        while (true) {
          bool g() {
            return true;
          }

          if (g()) {
            break loop;
          }
        }
      }
      ```
  LABEL_UNDEFINED:
    problemMessage: "Can't reference an undefined label '{0}'."
    correctionMessage: Try defining the label, or correcting the name to match an existing label.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the unresolvable label
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a reference to a label
      that isn't defined in the scope of the `break` or `continue` statement that
      is referencing it.

      #### Example

      The following code produces this diagnostic because the label `loop` isn't
      defined anywhere:

      ```dart
      void f() {
        for (int i = 0; i < 10; i++) {
          for (int j = 0; j < 10; j++) {
            break [!loop!];
          }
        }
      }
      ```

      #### Common fixes

      If the label should be on the innermost enclosing `do`, `for`, `switch`, or
      `while` statement, then remove the label:

      ```dart
      void f() {
        for (int i = 0; i < 10; i++) {
          for (int j = 0; j < 10; j++) {
            break;
          }
        }
      }
      ```

      If the label should be on some other statement, then add the label:

      ```dart
      void f() {
        loop: for (int i = 0; i < 10; i++) {
          for (int j = 0; j < 10; j++) {
            break loop;
          }
        }
      }
      ```
  LATE_FINAL_FIELD_WITH_CONST_CONSTRUCTOR:
    problemMessage: "Can't have a late final field in a class with a generative const constructor."
    correctionMessage: "Try removing the 'late' modifier, or don't declare 'const' constructors."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class that has at least one
      `const` constructor also has a field marked both `late` and `final`.

      #### Example

      The following code produces this diagnostic because the class `A` has a
      `const` constructor and the `final` field `f` is marked as `late`:

      ```dart
      class A {
        [!late!] final int f;

        const A();
      }
      ```

      #### Common fixes

      If the field doesn't need to be marked `late`, then remove the `late`
      modifier from the field:

      ```dart
      class A {
        final int f = 0;

        const A();
      }
      ```

      If the field must be marked `late`, then remove the `const` modifier from
      the constructors:

      ```dart
      class A {
        late final int f;

        A();
      }
      ```
  LATE_FINAL_LOCAL_ALREADY_ASSIGNED:
    problemMessage: The late final local variable is already assigned.
    correctionMessage: "Try removing the 'final' modifier, or don't reassign the value."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the analyzer can prove that a
      local variable marked as both `late` and `final` was already assigned a
      value at the point where another assignment occurs.

      Because `final` variables can only be assigned once, subsequent assignments
      are guaranteed to fail, so they're flagged.

      #### Example

      The following code produces this diagnostic because the `final` variable
      `v` is assigned a value in two places:

      ```dart
      int f() {
        late final int v;
        v = 0;
        [!v!] += 1;
        return v;
      }
      ```

      #### Common fixes

      If you need to be able to reassign the variable, then remove the `final`
      keyword:

      ```dart
      int f() {
        late int v;
        v = 0;
        v += 1;
        return v;
      }
      ```

      If you don't need to reassign the variable, then remove all except the
      first of the assignments:

      ```dart
      int f() {
        late final int v;
        v = 0;
        return v;
      }
      ```
  LIST_ELEMENT_TYPE_NOT_ASSIGNABLE:
    problemMessage: "The element type '{0}' can't be assigned to the list type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the actual type of the list element
      1: the expected type of the list element
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of an element in a list
      literal isn't assignable to the element type of the list.

      #### Example

      The following code produces this diagnostic because `2.5` is a double, and
      the list can hold only integers:

      ```dart
      List<int> x = [1, [!2.5!], 3];
      ```

      #### Common fixes

      If you intended to add a different object to the list, then replace the
      element with an expression that computes the intended object:

      ```dart
      List<int> x = [1, 2, 3];
      ```

      If the object shouldn't be in the list, then remove the element:

      ```dart
      List<int> x = [1, 3];
      ```

      If the object being computed is correct, then widen the element type of the
      list to allow all of the different types of objects it needs to contain:

      ```dart
      List<num> x = [1, 2.5, 3];
      ```
  MAIN_FIRST_POSITIONAL_PARAMETER_TYPE:
    problemMessage: "The type of the first positional parameter of the 'main' function must be a supertype of 'List<String>'."
    correctionMessage: Try changing the type of the parameter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the first positional parameter
      of a function named `main` isn't a supertype of `List<String>`.

      #### Example

      The following code produces this diagnostic because `List<int>` isn't a
      supertype of `List<String>`:

      ```dart
      void main([!List<int>!] args) {}
      ```

      #### Common fixes

      If the function is an entry point, then change the type of the first
      positional parameter to be a supertype of `List<String>`:

      ```dart
      void main(List<String> args) {}
      ```

      If the function isn't an entry point, then change the name of the function:

      ```dart
      void f(List<int> args) {}
      ```
  MAIN_HAS_REQUIRED_NAMED_PARAMETERS:
    problemMessage: "The function 'main' can't have any required named parameters."
    correctionMessage: "Try using a different name for the function, or removing the 'required' modifier."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a function named `main` has one
      or more required named parameters.

      #### Example

      The following code produces this diagnostic because the function named
      `main` has a required named parameter (`x`):

      ```dart
      void [!main!]({required int x}) {}
      ```

      #### Common fixes

      If the function is an entry point, then remove the `required` keyword:

      ```dart
      void main({int? x}) {}
      ```

      If the function isn't an entry point, then change the name of the function:

      ```dart
      void f({required int x}) {}
      ```
  MAIN_HAS_TOO_MANY_REQUIRED_POSITIONAL_PARAMETERS:
    problemMessage: "The function 'main' can't have more than two required positional parameters."
    correctionMessage: Try using a different name for the function, or removing extra parameters.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a function named `main` has more
      than two required positional parameters.

      #### Example

      The following code produces this diagnostic because the function `main` has
      three required positional parameters:

      ```dart
      void [!main!](List<String> args, int x, int y) {}
      ```

      #### Common fixes

      If the function is an entry point and the extra parameters aren't used,
      then remove them:

      ```dart
      void main(List<String> args, int x) {}
      ```

      If the function is an entry point, but the extra parameters used are for
      when the function isn't being used as an entry point, then make the extra
      parameters optional:

      ```dart
      void main(List<String> args, int x, [int y = 0]) {}
      ```

      If the function isn't an entry point, then change the name of the function:

      ```dart
      void f(List<String> args, int x, int y) {}
      ```
  MAIN_IS_NOT_FUNCTION:
    problemMessage: "The declaration named 'main' must be a function."
    correctionMessage: Try using a different name for this declaration.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library contains a declaration
      of the name `main` that isn't the declaration of a top-level function.

      #### Example

      The following code produces this diagnostic because the name `main` is
      being used to declare a top-level variable:

      ```dart
      var [!main!] = 3;
      ```

      #### Common fixes

      Use a different name for the declaration:

      ```dart
      var mainIndex = 3;
      ```
  MAP_ENTRY_NOT_IN_MAP:
    problemMessage: Map entries can only be used in a map literal.
    correctionMessage: Try converting the collection to a map or removing the map entry.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a map entry (a key/value pair)
      is found in a set literal.

      #### Example

      The following code produces this diagnostic because the literal has a map
      entry even though it's a set literal:

      ```dart
      const collection = <String>{[!'a' : 'b'!]};
      ```

      #### Common fixes

      If you intended for the collection to be a map, then change the code so
      that it is a map. In the previous example, you could do this by adding
      another type argument:

      ```dart
      const collection = <String, String>{'a' : 'b'};
      ```

      In other cases, you might need to change the explicit type from `Set` to
      `Map`.

      If you intended for the collection to be a set, then remove the map entry,
      possibly by replacing the colon with a comma if both values should be
      included in the set:

      ```dart
      const collection = <String>{'a', 'b'};
      ```
  MAP_KEY_TYPE_NOT_ASSIGNABLE:
    problemMessage: "The element type '{0}' can't be assigned to the map key type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the expression being used as a key
      1: the type of keys declared for the map
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a key of a key-value pair in a
      map literal has a type that isn't assignable to the key type of the map.

      #### Example

      The following code produces this diagnostic because `2` is an `int`, but
      the keys of the map are required to be `String`s:

      ```dart
      var m = <String, String>{[!2!] : 'a'};
      ```

      #### Common fixes

      If the type of the map is correct, then change the key to have the correct
      type:

      ```dart
      var m = <String, String>{'2' : 'a'};
      ```

      If the type of the key is correct, then change the key type of the map:

      ```dart
      var m = <int, String>{2 : 'a'};
      ```
  MAP_VALUE_TYPE_NOT_ASSIGNABLE:
    problemMessage: "The element type '{0}' can't be assigned to the map value type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the expression being used as a value
      1: the type of values declared for the map
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a value of a key-value pair in a
      map literal has a type that isn't assignable to the value type of the
      map.

      #### Example

      The following code produces this diagnostic because `2` is an `int`, but/
      the values of the map are required to be `String`s:

      ```dart
      var m = <String, String>{'a' : [!2!]};
      ```

      #### Common fixes

      If the type of the map is correct, then change the value to have the
      correct type:

      ```dart
      var m = <String, String>{'a' : '2'};
      ```

      If the type of the value is correct, then change the value type of the map:

      ```dart
      var m = <String, int>{'a' : 2};
      ```
  MISSING_CONST_IN_LIST_LITERAL:
    problemMessage: Seeing this message constitutes a bug. Please report it.
    comment: |-
      12.1 Constants: A constant expression is ... a constant list literal.
      
      Note: This diagnostic is never displayed to the user, so it doesn't need
      to be documented.
  MISSING_CONST_IN_MAP_LITERAL:
    problemMessage: Seeing this message constitutes a bug. Please report it.
    comment: |-
      12.1 Constants: A constant expression is ... a constant map literal.

      Note: This diagnostic is never displayed to the user, so it doesn't need
      to be documented.
  MISSING_CONST_IN_SET_LITERAL:
    problemMessage: Seeing this message constitutes a bug. Please report it.
    comment: |-
      12.1 Constants: A constant expression is ... a constant set literal.

      Note: This diagnostic is never displayed to the user, so it doesn't need
      to be documented.
  MISSING_DART_LIBRARY:
    problemMessage: "Required library '{0}' is missing."
    correctionMessage: Re-install the Dart or Flutter SDK.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when either the Dart or Flutter SDK
      isn’t installed correctly, and, as a result, one of the `dart:` libraries
      can't be found.

      #### Common fixes

      Reinstall the Dart or Flutter SDK.
  MISSING_DEFAULT_VALUE_FOR_PARAMETER:
    problemMessage: "The parameter '{0}' can't have a value of 'null' because of its type, but the implicit default value is 'null'."
    correctionMessage: "Try adding either an explicit non-'null' default value or the 'required' modifier."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an optional parameter, whether
      positional or named, has a [potentially non-nullable][] type and doesn't
      specify a default value. Optional parameters that have no explicit default
      value have an implicit default value of `null`. If the type of the
      parameter doesn't allow the parameter to have a value of `null`, then the
      implicit default value isn't valid.

      #### Examples

      The following code produces this diagnostic because `x` can't be `null`,
      and no non-`null` default value is specified:

      ```dart
      void f([int [!x!]]) {}
      ```

      As does this:

      ```dart
      void g({int [!x!]}) {}
      ```

      #### Common fixes

      If you want to use `null` to indicate that no value was provided, then you
      need to make the type nullable:

      ```dart
      void f([int? x]) {}
      void g({int? x}) {}
      ```

      If the parameter can't be null, then either provide a default value:

      ```dart
      void f([int x = 1]) {}
      void g({int x = 2}) {}
      ```

      or make the parameter a required parameter:

      ```dart
      void f(int x) {}
      void g({required int x}) {}
      ```
  MISSING_DEFAULT_VALUE_FOR_PARAMETER_WITH_ANNOTATION:
    sharedName: MISSING_DEFAULT_VALUE_FOR_PARAMETER
    problemMessage: "With null safety, use the 'required' keyword, not the '@required' annotation."
    correctionMessage: "Try removing the '@'."
    hasPublishedDocs: true
    comment: No parameters.
  MISSING_REQUIRED_ARGUMENT:
    problemMessage: "The named parameter '{0}' is required, but there's no corresponding argument."
    correctionMessage: Try adding the required argument.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of a function is
      missing a required named parameter.

      #### Example

      The following code produces this diagnostic because the invocation of `f`
      doesn't include a value for the required named parameter `end`:

      ```dart
      void f(int start, {required int end}) {}
      void g() {
        [!f!](3);
      }
      ```

      #### Common fixes

      Add a named argument corresponding to the missing required parameter:

      ```dart
      void f(int start, {required int end}) {}
      void g() {
        f(3, end: 5);
      }
      ```
  MIXINS_SUPER_CLASS:
    problemMessage: "'{0}' can't be used in both 'extends' and 'with' clauses."
    correctionMessage: Try removing one of the occurrences.
    comment: |-
      Technically this is [IMPLEMENTS_SUPER_CLASS].
      See https://github.com/dart-lang/sdk/issues/25765#issuecomment-307422593

      Parameters:
      0: the name of the class that appears in both "extends" and "with" clauses
  MIXIN_APPLICATION_CONCRETE_SUPER_INVOKED_MEMBER_TYPE:
    problemMessage: "The super-invoked member '{0}' has the type '{1}', and the concrete member in the class has the type '{2}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the super-invoked member
      1: the display name of the type of the super-invoked member in the mixin
      2: the display name of the type of the concrete member in the class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a mixin that invokes a method
      using `super` is used in a class where the concrete implementation of that
      method has a different signature than the signature defined for that method
      by the mixin's `on` type. The reason this is an error is because the
      invocation in the mixin might invoke the method in a way that's
      incompatible with the method that will actually be executed.

      #### Example

      The following code produces this diagnostic because the class `C` uses the
      mixin `M`, the mixin `M` invokes `foo` using `super`, and the abstract
      version of `foo` declared in `I` (the mixin's `on` type) doesn't have the
      same signature as the concrete version of `foo` declared in `A`:

      ```dart
      class I {
        void foo([int? p]) {}
      }

      class A {
        void foo(int p) {}
      }

      abstract class B extends A implements I {
        @override
        void foo([int? p]);
      }

      mixin M on I {
        void bar() {
          super.foo(42);
        }
      }

      abstract class C extends B with [!M!] {}
      ```

      #### Common fixes

      If the class doesn't need to use the mixin, then remove it from the `with`
      clause:

      ```dart
      class I {
        void foo([int? p]) {}
      }

      class A {
        void foo(int? p) {}
      }

      abstract class B extends A implements I {
        @override
        void foo([int? p]);
      }

      mixin M on I {
        void bar() {
          super.foo(42);
        }
      }

      abstract class C extends B {}
      ```

      If the class needs to use the mixin, then ensure that there's a concrete
      implementation of the method that conforms to the signature expected by the
      mixin:

      ```dart
      class I {
        void foo([int? p]) {}
      }

      class A {
        void foo(int? p) {}
      }

      abstract class B extends A implements I {
        @override
        void foo([int? p]) {
          super.foo(p);
        }
      }

      mixin M on I {
        void bar() {
          super.foo(42);
        }
      }

      abstract class C extends B with M {}
      ```
  MIXIN_APPLICATION_NOT_IMPLEMENTED_INTERFACE:
    problemMessage: "'{0}' can't be mixed onto '{1}' because '{1}' doesn't implement '{2}'."
    correctionMessage: "Try extending the class '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the display name of the mixin
      1: the display name of the superclass
      2: the display name of the type that is not implemented
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a mixin that has a superclass
      constraint is used in a [mixin application][] with a superclass that
      doesn't implement the required constraint.

      #### Example

      The following code produces this diagnostic because the mixin `M` requires
      that the class to which it's applied be a subclass of `A`, but `Object`
      isn't a subclass of `A`:

      ```dart
      class A {}

      mixin M on A {}

      class X = Object with [!M!];
      ```

      #### Common fixes

      If you need to use the mixin, then change the superclass to be either the
      same as or a subclass of the superclass constraint:

      ```dart
      class A {}

      mixin M on A {}

      class X = A with M;
      ```
  MIXIN_APPLICATION_NO_CONCRETE_SUPER_INVOKED_MEMBER:
    problemMessage: "The class doesn't have a concrete implementation of the super-invoked member '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the display name of the member without a concrete implementation
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a [mixin application][] contains
      an invocation of a member from its superclass, and there's no concrete
      member of that name in the mixin application's superclass.

      #### Example

      The following code produces this diagnostic because the mixin `M` contains
      the invocation `super.m()`, and the class `A`, which is the superclass of
      the [mixin application][] `A+M`, doesn't define a concrete implementation
      of `m`:

      ```dart
      abstract class A {
        void m();
      }

      mixin M on A {
        void bar() {
          super.m();
        }
      }

      abstract class B extends A with [!M!] {}
      ```

      #### Common fixes

      If you intended to apply the mixin `M` to a different class, one that has a
      concrete implementation of `m`, then change the superclass of `B` to that
      class:

      ```dart
      abstract class A {
        void m();
      }

      mixin M on A {
        void bar() {
          super.m();
        }
      }

      class C implements A {
        void m() {}
      }

      abstract class B extends C with M {}
      ```

      If you need to make `B` a subclass of `A`, then add a concrete
      implementation of `m` in `A`:

      ```dart
      abstract class A {
        void m() {}
      }

      mixin M on A {
        void bar() {
          super.m();
        }
      }

      abstract class B extends A with M {}
      ```
  MIXIN_CLASS_DECLARES_CONSTRUCTOR:
    problemMessage: "The class '{0}' can't be used as a mixin because it declares a constructor."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the mixin that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class is used as a mixin and
      the mixed-in class defines a constructor.

      #### Example

      The following code produces this diagnostic because the class `A`, which
      defines a constructor, is being used as a mixin:

      ```dart
      class A {
        A();
      }

      class B with [!A!] {}
      ```

      #### Common fixes

      If it's possible to convert the class to a mixin, then do so:

      ```dart
      mixin A {
      }

      class B with A {}
      ```

      If the class can't be a mixin and it's possible to remove the constructor,
      then do so:

      ```dart
      class A {
      }

      class B with A {}
      ```

      If the class can't be a mixin and you can't remove the constructor, then
      try extending or implementing the class rather than mixing it in:

      ```dart
      class A {
        A();
      }

      class B extends A {}
      ```
  MIXIN_INHERITS_FROM_NOT_OBJECT:
    problemMessage: "The class '{0}' can't be used as a mixin because it extends a class other than 'Object'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the mixin that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class that extends a class
      other than `Object` is used as a mixin.

      #### Example

      The following code produces this diagnostic because the class `B`, which
      extends `A`, is being used as a mixin by `C`:

      ```dart
      class A {}

      class B extends A {}

      class C with [!B!] {}
      ```

      #### Common fixes

      If the class being used as a mixin can be changed to extend `Object`, then
      change it:

      ```dart
      class A {}

      class B {}

      class C with B {}
      ```

      If the class being used as a mixin can't be changed and the class that's
      using it extends `Object`, then extend the class being used as a mixin:

      ```dart
      class A {}

      class B extends A {}

      class C extends B {}
      ```

      If the class doesn't extend `Object` or if you want to be able to mix in
      the behavior from `B` in other places, then create a real mixin:

      ```dart
      class A {}

      mixin M on A {}

      class B extends A with M {}

      class C extends A with M {}
      ```
  MIXIN_INSTANTIATE:
    problemMessage: "Mixins can't be instantiated."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a mixin is instantiated.

      #### Example

      The following code produces this diagnostic because the mixin `M` is being
      instantiated:

      ```dart
      mixin M {}

      var m = [!M!]();
      ```

      #### Common fixes

      If you intend to use an instance of a class, then use the name of that
      class in place of the name of the mixin.
  MIXIN_OF_NON_CLASS:
    problemMessage: Classes can only mix in mixins and classes.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name in a `with` clause is
      defined to be something other than a mixin or a class.

      #### Example

      The following code produces this diagnostic because `F` is defined to be a
      function type:

      ```dart
      typedef F = int Function(String);

      class C with [!F!] {}
      ```

      #### Common fixes

      Remove the invalid name from the list, possibly replacing it with the name
      of the intended mixin or class:

      ```dart
      typedef F = int Function(String);

      class C {}
      ```
  MIXIN_SUPER_CLASS_CONSTRAINT_DEFERRED_CLASS:
    problemMessage: "Deferred classes can't be used as super-class constraints."
    correctionMessage: Try changing the import to not be deferred.
    comment: No parameters.
  MIXIN_SUPER_CLASS_CONSTRAINT_NON_INTERFACE:
    problemMessage: Only classes and mixins can be used as superclass constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type following the `on`
      keyword in a mixin declaration is neither a class nor a mixin.

      #### Example

      The following code produces this diagnostic because `F` is neither a class
      nor a mixin:

      ```dart
      typedef F = void Function();

      mixin M on [!F!] {}
      ```

      #### Common fixes

      If the type was intended to be a class but was mistyped, then replace the
      name.

      Otherwise, remove the type from the `on` clause.
  MIXIN_WITH_NON_CLASS_SUPERCLASS:
    problemMessage: Mixin can only be applied to class.
    comment: |-
      9.1 Mixin Application: It is a compile-time error if <i>S</i> does not
      denote a class available in the immediately enclosing scope.
  MULTIPLE_REDIRECTING_CONSTRUCTOR_INVOCATIONS:
    problemMessage: Constructors can have only one 'this' redirection, at most.
    correctionMessage: Try removing all but one of the redirections.
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor redirects to more
      than one other constructor in the same class (using `this`).

      #### Example

      The following code produces this diagnostic because the unnamed
      constructor in `C` is redirecting to both `this.a` and `this.b`:

      ```dart
      class C {
        C() : this.a(), [!this.b()!];
        C.a();
        C.b();
      }
      ```

      #### Common fixes

      Remove all but one of the redirections:

      ```dart
      class C {
        C() : this.a();
        C.a();
        C.b();
      }
      ```
  MULTIPLE_SUPER_INITIALIZERS:
    problemMessage: "A constructor can have at most one 'super' initializer."
    correctionMessage: "Try removing all but one of the 'super' initializers."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the initializer list of a
      constructor contains more than one invocation of a constructor from the
      superclass. The initializer list is required to have exactly one such call,
      which can either be explicit or implicit.

      #### Example

      The following code produces this diagnostic because the initializer list
      for `B`’s constructor invokes both the constructor `one` and the
      constructor `two` from the superclass `A`:

      ```dart
      class A {
        int? x;
        String? s;
        A.one(this.x);
        A.two(this.s);
      }

      class B extends A {
        B() : super.one(0), [!super.two('')!];
      }
      ```

      #### Common fixes

      If one of the super constructors will initialize the instance fully, then
      remove the other:

      ```dart
      class A {
        int? x;
        String? s;
        A.one(this.x);
        A.two(this.s);
      }

      class B extends A {
        B() : super.one(0);
      }
      ```

      If the initialization achieved by one of the super constructors can be
      performed in the body of the constructor, then remove its super invocation
      and perform the initialization in the body:

      ```dart
      class A {
        int? x;
        String? s;
        A.one(this.x);
        A.two(this.s);
      }

      class B extends A {
        B() : super.one(0) {
          s = '';
        }
      }
      ```

      If the initialization can only be performed in a constructor in the
      superclass, then either add a new constructor or modify one of the existing
      constructors so there's a constructor that allows all the required
      initialization to occur in a single call:

      ```dart
      class A {
        int? x;
        String? s;
        A.one(this.x);
        A.two(this.s);
        A.three(this.x, this.s);
      }

      class B extends A {
        B() : super.three(0, '');
      }
      ```
  NEW_WITH_UNDEFINED_CONSTRUCTOR:
    problemMessage: "The class '{0}' doesn't have a constructor named '{1}'."
    correctionMessage: "Try invoking a different constructor, or define a constructor named '{1}'."
    comment: |-
      12.11.1 New: If <i>T</i> is a class or parameterized type accessible in the
      current scope then:
      1. If <i>e</i> is of the form <i>new T.id(a<sub>1</sub>, &hellip;,
         a<sub>n</sub>, x<sub>n+1</sub>: a<sub>n+1</sub>, &hellip;,
         x<sub>n+k</sub>: a<sub>n+k</sub>)</i> it is a static warning if
         <i>T.id</i> is not the name of a constructor declared by the type
         <i>T</i>.
      If <i>e</i> of the form <i>new T(a<sub>1</sub>, &hellip;, a<sub>n</sub>,
      x<sub>n+1</sub>: a<sub>n+1</sub>, &hellip;, x<sub>n+k</sub>:
      a<sub>n+kM/sub>)</i> it is a static warning if the type <i>T</i> does not
      declare a constructor with the same name as the declaration of <i>T</i>.
  NEW_WITH_UNDEFINED_CONSTRUCTOR_DEFAULT:
    problemMessage: "The class '{0}' doesn't have an unnamed constructor."
    correctionMessage: "Try using one of the named constructors defined in '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class being instantiated
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an unnamed constructor is
      invoked on a class that defines named constructors but the class doesn’t
      have an unnamed constructor.

      #### Example

      The following code produces this diagnostic because `A` doesn't define an
      unnamed constructor:

      ```dart
      class A {
        A.a();
      }

      A f() => [!A!]();
      ```

      #### Common fixes

      If one of the named constructors does what you need, then use it:

      ```dart
      class A {
        A.a();
      }

      A f() => A.a();
      ```

      If none of the named constructors does what you need, and you're able to
      add an unnamed constructor, then add the constructor:

      ```dart
      class A {
        A();
        A.a();
      }

      A f() => A();
      ```
  NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_FIVE_PLUS:
    sharedName: NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER
    problemMessage: "Missing concrete implementations of '{0}', '{1}', '{2}', '{3}', and {4} more."
    correctionMessage: Try implementing the missing methods, or make the class abstract.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the first member
      1: the name of the second member
      2: the name of the third member
      3: the name of the fourth member
      4: the number of additional missing members that aren't listed
  NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_FOUR:
    sharedName: NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER
    problemMessage: "Missing concrete implementations of '{0}', '{1}', '{2}', and '{3}'."
    correctionMessage: Try implementing the missing methods, or make the class abstract.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the first member
      1: the name of the second member
      2: the name of the third member
      3: the name of the fourth member
  NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_ONE:
    sharedName: NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER
    problemMessage: "Missing concrete implementation of '{0}'."
    correctionMessage: Try implementing the missing method, or make the class abstract.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a concrete class inherits one or
      more abstract members, and doesn't provide or inherit an implementation for
      at least one of those abstract members.

      #### Example

      The following code produces this diagnostic because the class `B` doesn't
      have a concrete implementation of `m`:

      ```dart
      abstract class A {
        void m();
      }

      class [!B!] extends A {}
      ```

      #### Common fixes

      If the subclass can provide a concrete implementation for some or all of
      the abstract inherited members, then add the concrete implementations:

      ```dart
      abstract class A {
        void m();
      }

      class B extends A {
        void m() {}
      }
      ```

      If there is a mixin that provides an implementation of the inherited
      methods, then apply the mixin to the subclass:

      ```dart
      abstract class A {
        void m();
      }

      class B extends A with M {}

      mixin M {
        void m() {}
      }
      ```

      If the subclass can't provide a concrete implementation for all of the
      abstract inherited members, then mark the subclass as being abstract:

      ```dart
      abstract class A {
        void m();
      }

      abstract class B extends A {}
      ```
  NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_THREE:
    sharedName: NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER
    problemMessage: "Missing concrete implementations of '{0}', '{1}', and '{2}'."
    correctionMessage: Try implementing the missing methods, or make the class abstract.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the first member
      1: the name of the second member
      2: the name of the third member
  NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER_TWO:
    sharedName: NON_ABSTRACT_CLASS_INHERITS_ABSTRACT_MEMBER
    problemMessage: "Missing concrete implementations of '{0}' and '{1}'."
    correctionMessage: Try implementing the missing methods, or make the class abstract.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the first member
      1: the name of the second member
  NON_BOOL_CONDITION:
    problemMessage: "Conditions must have a static type of 'bool'."
    correctionMessage: Try changing the condition.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a condition, such as an `if` or
      `while` loop, doesn't have the static type `bool`.

      #### Example

      The following code produces this diagnostic because `x` has the static type
      `int`:

      ```dart
      void f(int x) {
        if ([!x!]) {
          // ...
        }
      }
      ```

      #### Common fixes

      Change the condition so that it produces a Boolean value:

      ```dart
      void f(int x) {
        if (x == 0) {
          // ...
        }
      }
      ```
  NON_BOOL_EXPRESSION:
    problemMessage: "The expression in an assert must be of type 'bool'."
    correctionMessage: Try changing the expression.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the first expression in an
      assert has a type other than `bool`.

      #### Example

      The following code produces this diagnostic because the type of `p` is
      `int`, but a `bool` is required:

      ```dart
      void f(int p) {
        assert([!p!]);
      }
      ```

      #### Common fixes

      Change the expression so that it has the type `bool`:

      ```dart
      void f(int p) {
        assert(p > 0);
      }
      ```
  NON_BOOL_NEGATION_EXPRESSION:
    problemMessage: "A negation operand must have a static type of 'bool'."
    correctionMessage: "Try changing the operand to the '!' operator."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the operand of the unary
      negation operator (`!`) doesn't have the type `bool`.

      #### Example

      The following code produces this diagnostic because `x` is an `int` when it
      must be a `bool`:

      ```dart
      int x = 0;
      bool y = ![!x!];
      ```

      #### Common fixes

      Replace the operand with an expression that has the type `bool`:

      ```dart
      int x = 0;
      bool y = !(x > 0);
      ```
  NON_BOOL_OPERAND:
    problemMessage: "The operands of the operator '{0}' must be assignable to 'bool'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the lexeme of the logical operator
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when one of the operands of either
      the `&&` or `||` operator doesn't have the type `bool`.

      #### Example

      The following code produces this diagnostic because `a` isn't a Boolean
      value:

      ```dart
      int a = 3;
      bool b = [!a!] || a > 1;
      ```

      #### Common fixes

      Change the operand to a Boolean value:

      ```dart
      int a = 3;
      bool b = a == 0 || a > 1;
      ```
  NON_CONSTANT_ANNOTATION_CONSTRUCTOR:
    problemMessage: Annotation creation can only call a const constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an annotation is the invocation
      of an existing constructor even though the invoked constructor isn't a
      const constructor.

      #### Example

      The following code produces this diagnostic because the constructor for `C`
      isn't a const constructor:

      ```dart
      [!@C()!]
      void f() {
      }

      class C {
        C();
      }
      ```

      #### Common fixes

      If it's valid for the class to have a const constructor, then create a
      const constructor that can be used for the annotation:

      ```dart
      @C()
      void f() {
      }

      class C {
        const C();
      }
      ```

      If it isn't valid for the class to have a const constructor, then either
      remove the annotation or use a different class for the annotation.
  NON_CONSTANT_CASE_EXPRESSION:
    problemMessage: Case expressions must be constant.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression in a `case`
      clause isn't a constant expression.

      #### Example

      The following code produces this diagnostic because `j` isn't a constant:

      ```dart
      void f(int i, int j) {
        switch (i) {
          case [!j!]:
            // ...
            break;
        }
      }
      ```

      #### Common fixes

      Either make the expression a constant expression, or rewrite the `switch`
      statement as a sequence of `if` statements:

      ```dart
      void f(int i, int j) {
        if (i == j) {
          // ...
        }
      }
      ```
  NON_CONSTANT_CASE_EXPRESSION_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used as a case expression."
    correctionMessage: Try re-writing the switch as a series of if statements, or changing the import to not be deferred.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the expression in a case clause
      references a constant from a library that is imported using a deferred
      import. In order for switch statements to be compiled efficiently, the
      constants referenced in case clauses need to be available at compile time,
      and constants from deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines the constant `zero`:

      ```dart
      %uri="lib/a.dart"
      const zero = 0;
      ```

      The following code produces this diagnostic because the library `a.dart` is
      imported using a `deferred` import, and the constant `a.zero`, declared in
      the imported library, is used in a case clause:

      ```dart
      import 'a.dart' deferred as a;

      void f(int x) {
        switch (x) {
          case [!a.zero!]:
            // ...
            break;
        }
      }
      ```

      #### Common fixes

      If you need to reference the constant from the imported library, then
      remove the `deferred` keyword:

      ```dart
      import 'a.dart' as a;

      void f(int x) {
        switch (x) {
          case a.zero:
            // ...
            break;
        }
      }
      ```

      If you need to reference the constant from the imported library and also
      need the imported library to be deferred, then rewrite the switch statement
      as a sequence of `if` statements:

      ```dart
      import 'a.dart' deferred as a;

      void f(int x) {
        if (x == a.zero) {
          // ...
        }
      }
      ```

      If you don't need to reference the constant, then replace the case
      expression:

      ```dart
      void f(int x) {
        switch (x) {
          case 0:
            // ...
            break;
        }
      }
      ```
  NON_CONSTANT_DEFAULT_VALUE:
    problemMessage: The default value of an optional parameter must be constant.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an optional parameter, either
      named or positional, has a default value that isn't a compile-time
      constant.

      #### Example

      The following code produces this diagnostic:

      ```dart
      %language=2.9
      var defaultValue = 3;

      void f([int value = [!defaultValue!]]) {}
      ```

      #### Common fixes

      If the default value can be converted to be a constant, then convert it:

      ```dart
      %language=2.9
      const defaultValue = 3;

      void f([int value = defaultValue]) {}
      ```

      If the default value needs to change over time, then apply the default
      value inside the function:

      ```dart
      %language=2.9
      var defaultValue = 3;

      void f([int value]) {
        value ??= defaultValue;
      }
      ```
  NON_CONSTANT_DEFAULT_VALUE_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be used as a default parameter value."
    correctionMessage: Try leaving the default as null and initializing the parameter inside the function body.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the default value of an optional
      parameter uses a constant from a library imported using a deferred import.
      Default values need to be available at compile time, and constants from
      deferred libraries aren't available at compile time.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines the constant `zero`:

      ```dart
      %uri="lib/a.dart"
      const zero = 0;
      ```

      The following code produces this diagnostic because `zero` is declared in a
      library imported using a deferred import:

      ```dart
      import 'a.dart' deferred as a;

      void f({int x = [!a.zero!]}) {}
      ```

      #### Common fixes

      If you need to reference the constant from the imported library, then
      remove the `deferred` keyword:

      ```dart
      import 'a.dart' as a;

      void f({int x = a.zero}) {}
      ```

      If you don't need to reference the constant, then replace the default
      value:

      ```dart
      void f({int x = 0}) {}
      ```
  NON_CONSTANT_LIST_ELEMENT:
    problemMessage: The values in a const list literal must be constants.
    correctionMessage: "Try removing the keyword 'const' from the list literal."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an element in a constant list
      literal isn't a constant value. The list literal can be constant either
      explicitly (because it's prefixed by the `const` keyword) or implicitly
      (because it appears in a [constant context][]).

      #### Example

      The following code produces this diagnostic because `x` isn't a constant,
      even though it appears in an implicitly constant list literal:

      ```dart
      var x = 2;
      var y = const <int>[0, 1, [!x!]];
      ```

      #### Common fixes

      If the list needs to be a constant list, then convert the element to be a
      constant. In the example above, you might add the `const` keyword to the
      declaration of `x`:

      ```dart
      const x = 2;
      var y = const <int>[0, 1, x];
      ```

      If the expression can't be made a constant, then the list can't be a
      constant either, so you must change the code so that the list isn't a
      constant. In the example above this means removing the `const` keyword
      before the list literal:

      ```dart
      var x = 2;
      var y = <int>[0, 1, x];
      ```
  NON_CONSTANT_MAP_ELEMENT:
    problemMessage: The elements in a const map literal must be constant.
    correctionMessage: "Try removing the keyword 'const' from the map literal."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an `if` element or a spread
      element in a constant map isn't a constant element.

      #### Examples

      The following code produces this diagnostic because it's attempting to
      spread a non-constant map:

      ```dart
      var notConst = <int, int>{};
      var map = const <int, int>{...[!notConst!]};
      ```

      Similarly, the following code produces this diagnostic because the
      condition in the `if` element isn't a constant expression:

      ```dart
      bool notConst = true;
      var map = const <int, int>{if ([!notConst!]) 1 : 2};
      ```

      #### Common fixes

      If the map needs to be a constant map, then make the elements constants.
      In the spread example, you might do that by making the collection being
      spread a constant:

      ```dart
      const notConst = <int, int>{};
      var map = const <int, int>{...notConst};
      ```

      If the map doesn't need to be a constant map, then remove the `const`
      keyword:

      ```dart
      bool notConst = true;
      var map = <int, int>{if (notConst) 1 : 2};
      ```
  NON_CONSTANT_MAP_KEY:
    problemMessage: The keys in a const map literal must be constant.
    correctionMessage: "Try removing the keyword 'const' from the map literal."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a key in a constant map literal
      isn't a constant value.

      #### Example

      The following code produces this diagnostic because `a` isn't a constant:

      ```dart
      var a = 'a';
      var m = const {[!a!]: 0};
      ```

      #### Common fixes

      If the map needs to be a constant map, then make the key a constant:

      ```dart
      const a = 'a';
      var m = const {a: 0};
      ```

      If the map doesn't need to be a constant map, then remove the `const`
      keyword:

      ```dart
      var a = 'a';
      var m = {a: 0};
      ```
  NON_CONSTANT_MAP_VALUE:
    problemMessage: The values in a const map literal must be constant.
    correctionMessage: "Try removing the keyword 'const' from the map literal."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a value in a constant map
      literal isn't a constant value.

      #### Example

      The following code produces this diagnostic because `a` isn't a constant:

      ```dart
      var a = 'a';
      var m = const {0: [!a!]};
      ```

      #### Common fixes

      If the map needs to be a constant map, then make the key a constant:

      ```dart
      const a = 'a';
      var m = const {0: a};
      ```

      If the map doesn't need to be a constant map, then remove the `const`
      keyword:

      ```dart
      var a = 'a';
      var m = {0: a};
      ```
  NON_CONSTANT_SET_ELEMENT:
    problemMessage: The values in a const set literal must be constants.
    correctionMessage: "Try removing the keyword 'const' from the set literal."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constant set literal contains
      an element that isn't a compile-time constant.

      #### Example

      The following code produces this diagnostic because `i` isn't a constant:

      ```dart
      var i = 0;

      var s = const {[!i!]};
      ```

      #### Common fixes

      If the element can be changed to be a constant, then change it:

      ```dart
      const i = 0;

      var s = const {i};
      ```

      If the element can't be a constant, then remove the keyword `const`:

      ```dart
      var i = 0;

      var s = {i};
      ```
  NON_CONST_MAP_AS_EXPRESSION_STATEMENT:
    problemMessage: "A non-constant map or set literal without type arguments can't be used as an expression statement."
    comment: |-
      13.2 Expression Statements: It is a compile-time error if a non-constant
      map literal that has no explicit type arguments appears in a place where a
      statement is expected.
  NON_FINAL_FIELD_IN_ENUM:
    problemMessage: Enums can only declare final fields.
    correctionMessage: Try making the field final.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an instance field in an enum
      isn't marked as `final`.
      
      #### Example
      
      The following code produces this diagnostic because the field `f` isn't a
      final field:
      
      ```dart
      enum E {
        c;
      
        int [!f!] = 0;
      }
      ```
      
      #### Common fixes
      
      If the field must be defined for the enum, then mark the field as being
      `final`:
      
      ```dart
      enum E {
        c;
      
        final int f = 0;
      }
      ```
      
      If the field can be removed, then remove it:
      
      ```dart
      enum E {
        c
      }
      ```
  NON_GENERATIVE_CONSTRUCTOR:
    problemMessage: "The generative constructor '{0}' is expected, but a factory was found."
    correctionMessage: Try calling a different constructor of the superclass, or making the called constructor not be a factory constructor.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the non-generative constructor
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the initializer list of a
      constructor invokes a constructor from the superclass, and the invoked
      constructor is a factory constructor. Only a generative constructor can be
      invoked in the initializer list.

      #### Example

      The following code produces this diagnostic because the invocation of the
      constructor `super.one()` is invoking a factory constructor:

      ```dart
      class A {
        factory A.one() = B;
        A.two();
      }

      class B extends A {
        B() : [!super.one()!];
      }
      ```

      #### Common fixes

      Change the super invocation to invoke a generative constructor:

      ```dart
      class A {
        factory A.one() = B;
        A.two();
      }

      class B extends A {
        B() : super.two();
      }
      ```

      If the generative constructor is the unnamed constructor, and if there are
      no arguments being passed to it, then you can remove the super invocation.
  NON_GENERATIVE_IMPLICIT_CONSTRUCTOR:
    problemMessage: "The unnamed constructor of superclass '{0}' (called by the default constructor of '{1}') must be a generative constructor, but factory found."
    correctionMessage: "Try adding an explicit constructor that has a different superinitializer or changing the superclass constructor '{2}' to not be a factory constructor."
    comment: |-
      Parameters:
      0: the name of the superclass
      1: the name of the current class
      2: the implicitly called factory constructor of the superclass
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class has an implicit
      generative constructor and the superclass has an explicit unnamed factory
      constructor. The implicit constructor in the subclass implicitly invokes
      the unnamed constructor in the superclass, but generative constructors can
      only invoke another generative constructor, not a factory constructor.

      #### Example

      The following code produces this diagnostic because the implicit
      constructor in `B` invokes the unnamed constructor in `A`, but the
      constructor in `A` is a factory constructor, when a generative constructor
      is required:

      ```dart
      class A {
        factory A() => throw 0;
        A.named();
      }

      class [!B!] extends A {}
      ```

      #### Common fixes

      If the unnamed constructor in the superclass can be a generative
      constructor, then change it to be a generative constructor:

      ```dart
      class A {
        A();
        A.named();
      }

      class B extends A { }
      ```

      If the unnamed constructor can't be a generative constructor and there are
      other generative constructors in the superclass, then explicitly invoke
      one of them:

      ```dart
      class A {
        factory A() => throw 0;
        A.named();
      }

      class B extends A {
        B() : super.named();
      }
      ```

      If there are no generative constructors that can be used and none can be
      added, then implement the superclass rather than extending it:

      ```dart
      class A {
        factory A() => throw 0;
        A.named();
      }

      class B implements A {}
      ```
  NON_SYNC_FACTORY:
    problemMessage: "Factory bodies can't use 'async', 'async*', or 'sync*'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the body of a factory
      constructor is marked with `async`, `async*`, or `sync*`. All constructors,
      including factory constructors, are required to return an instance of the
      class in which they're declared, not a `Future`, `Stream`, or `Iterator`.

      #### Example

      The following code produces this diagnostic because the body of the factory
      constructor is marked with `async`:

      ```dart
      class C {
        factory C() [!async!] {
          return C._();
        }
        C._();
      }
      ```

      #### Common fixes

      If the member must be declared as a factory constructor, then remove the
      keyword appearing before the body:

      ```dart
      class C {
        factory C() {
          return C._();
        }
        C._();
      }
      ```

      If the member must return something other than an instance of the enclosing
      class, then make the member a static method:

      ```dart
      class C {
        static Future<C> m() async {
          return C._();
        }
        C._();
      }
      ```
  NON_TYPE_AS_TYPE_ARGUMENT:
    problemMessage: "The name '{0}' isn't a type so it can't be used as a type argument."
    correctionMessage: "Try correcting the name to an existing type, or defining a type named '{0}'."
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name appearing where a type is expected
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an identifier that isn't a type
      is used as a type argument.

      #### Example

      The following code produces this diagnostic because `x` is a variable, not
      a type:

      ```dart
      var x = 0;
      List<[!x!]> xList = [];
      ```

      #### Common fixes

      Change the type argument to be a type:

      ```dart
      var x = 0;
      List<int> xList = [];
      ```
  NON_TYPE_IN_CATCH_CLAUSE:
    problemMessage: "The name '{0}' isn't a type and can't be used in an on-catch clause."
    correctionMessage: Try correcting the name to match an existing class.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the non-type element
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the identifier following the
      `on` in a `catch` clause is defined to be something other than a type.

      #### Example

      The following code produces this diagnostic because `f` is a function, not
      a type:

      ```dart
      %language=2.9
      void f() {
        try {
          // ...
        } on [!f!] {
          // ...
        }
      }
      ```

      #### Common fixes

      Change the name to the type of object that should be caught:

      ```dart
      %language=2.9
      void f() {
        try {
          // ...
        } on FormatException {
          // ...
        }
      }
      ```
  NON_VOID_RETURN_FOR_OPERATOR:
    problemMessage: "The return type of the operator []= must be 'void'."
    correctionMessage: "Try changing the return type to 'void'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a declaration of the operator
      `[]=` has a return type other than `void`.

      #### Example

      The following code produces this diagnostic because the declaration of the
      operator `[]=` has a return type of `int`:

      ```dart
      class C {
        [!int!] operator []=(int index, int value) => 0;
      }
      ```

      #### Common fixes

      Change the return type to `void`:

      ```dart
      class C {
        void operator []=(int index, int value) => 0;
      }
      ```
  NON_VOID_RETURN_FOR_SETTER:
    problemMessage: "The return type of the setter must be 'void' or absent."
    correctionMessage: Try removing the return type, or define a method rather than a setter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a setter is defined with a
      return type other than `void`.

      #### Example

      The following code produces this diagnostic because the setter `p` has a
      return type of `int`:

      ```dart
      class C {
        [!int!] set p(int i) => 0;
      }
      ```

      #### Common fixes

      Change the return type to `void` or omit the return type:

      ```dart
      class C {
        set p(int i) => 0;
      }
      ```
  NOT_ASSIGNED_POTENTIALLY_NON_NULLABLE_LOCAL_VARIABLE:
    problemMessage: "The non-nullable local variable '{0}' must be assigned before it can be used."
    correctionMessage: "Try giving it an initializer expression, or ensure that it's assigned on every execution path."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the variable that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a local variable is referenced
      and has all these characteristics:
      - Has a type that's [potentially non-nullable][].
      - Doesn't have an initializer.
      - Isn't marked as `late`.
      - The analyzer can't prove that the local variable will be assigned before
        the reference based on the specification of [definite assignment][].

      #### Examples

      The following code produces this diagnostic because `x` can't have a value
      of `null`, but is referenced before a value was assigned to it:

      ```dart
      String f() {
        int x;
        return [!x!].toString();
      }
      ```

      The following code produces this diagnostic because the assignment to `x`
      might not be executed, so it might have a value of `null`:

      ```dart
      int g(bool b) {
        int x;
        if (b) {
          x = 1;
        }
        return [!x!] * 2;
      }
      ```

      The following code produces this diagnostic because the analyzer can't
      prove, based on definite assignment analysis, that `x` won't be referenced
      without having a value assigned to it:

      ```dart
      int h(bool b) {
        int x;
        if (b) {
          x = 1;
        }
        if (b) {
          return [!x!] * 2;
        }
        return 0;
      }
      ```

      #### Common fixes

      If `null` is a valid value, then make the variable nullable:

      ```dart
      String f() {
        int? x;
        return x!.toString();
      }
      ```

      If `null` isn’t a valid value, and there's a reasonable default value, then
      add an initializer:

      ```dart
      int g(bool b) {
        int x = 2;
        if (b) {
          x = 1;
        }
        return x * 2;
      }
      ```

      Otherwise, ensure that a value was assigned on every possible code path
      before the value is accessed:

      ```dart
      int g(bool b) {
        int x;
        if (b) {
          x = 1;
        } else {
          x = 2;
        }
        return x * 2;
      }
      ```

      You can also mark the variable as `late`, which removes the diagnostic, but
      if the variable isn't assigned a value before it's accessed, then it
      results in an exception being thrown at runtime. This approach should only
      be used if you're sure that the variable will always be assigned, even
      though the analyzer can't prove it based on definite assignment analysis.

      ```dart
      int h(bool b) {
        late int x;
        if (b) {
          x = 1;
        }
        if (b) {
          return x * 2;
        }
        return 0;
      }
      ```
  NOT_A_TYPE:
    problemMessage: "{0} isn't a type."
    correctionMessage: Try correcting the name to match an existing type.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name that is not a type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name is used as a type but
      declared to be something other than a type.

      #### Example

      The following code produces this diagnostic because `f` is a function:

      ```dart
      f() {}
      g([!f!] v) {}
      ```

      #### Common fixes

      Replace the name with the name of a type.
  NOT_BINARY_OPERATOR:
    problemMessage: "'{0}' isn't a binary operator."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the operator that is not a binary operator.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an operator that can only be
      used as a unary operator is used as a binary operator.

      #### Example

      The following code produces this diagnostic because the operator `~` can
      only be used as a unary operator:

      ```dart
      var a = 5 [!~!] 3;
      ```

      #### Common fixes

      Replace the operator with the correct binary operator:

      ```dart
      var a = 5 - 3;
      ```
  NOT_ENOUGH_POSITIONAL_ARGUMENTS:
    problemMessage: "{0} positional argument(s) expected, but {1} found."
    correctionMessage: Try adding the missing arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the expected number of required arguments
      1: the actual number of positional arguments given
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function invocation
      has fewer positional arguments than the number of required positional
      parameters.

      #### Example

      The following code produces this diagnostic because `f` declares two
      required parameters, but only one argument is provided:

      ```dart
      void f(int a, int b) {}
      void g() {
        f[!(0)!];
      }
      ```

      #### Common fixes

      Add arguments corresponding to the remaining parameters:

      ```dart
      void f(int a, int b) {}
      void g() {
        f(0, 1);
      }
      ```
  NOT_INITIALIZED_NON_NULLABLE_INSTANCE_FIELD:
    problemMessage: "Non-nullable instance field '{0}' must be initialized."
    correctionMessage: "Try adding an initializer expression, or a generative constructor that initializes it, or mark it 'late'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field that is not initialized
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field is declared and has all
      these characteristics:
      - Has a type that's [potentially non-nullable][]
      - Doesn't have an initializer
      - Isn't marked as `late`

      #### Examples

      The following code produces this diagnostic because `x` is implicitly
      initialized to `null` when it isn't allowed to be `null`:

      ```dart
      class C {
        int [!x!];
      }
      ```

      Similarly, the following code produces this diagnostic because `x` is
      implicitly initialized to `null`, when it isn't allowed to be `null`, by
      one of the constructors, even though it's initialized by other
      constructors:

      ```dart
      class C {
        int x;

        C(this.x);

        [!C!].n();
      }
      ```

      #### Common fixes

      If there's a reasonable default value for the field that’s the same for all
      instances, then add an initializer expression:

      ```dart
      class C {
        int x = 0;
      }
      ```

      If the value of the field should be provided when an instance is created,
      then add a constructor that sets the value of the field or update an
      existing constructor:

      ```dart
      class C {
        int x;

        C(this.x);
      }
      ```

      You can also mark the field as `late`, which removes the diagnostic, but if
      the field isn't assigned a value before it's accessed, then it results in
      an exception being thrown at runtime. This approach should only be used if
      you're sure that the field will always be assigned before it's referenced.

      ```dart
      class C {
        late int x;
      }
      ```
  NOT_INITIALIZED_NON_NULLABLE_INSTANCE_FIELD_CONSTRUCTOR:
    sharedName: NOT_INITIALIZED_NON_NULLABLE_INSTANCE_FIELD
    problemMessage: "Non-nullable instance field '{0}' must be initialized."
    correctionMessage: "Try adding an initializer expression, or add a field initializer in this constructor, or mark it 'late'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the field that is not initialized
  NOT_INITIALIZED_NON_NULLABLE_VARIABLE:
    problemMessage: "The non-nullable variable '{0}' must be initialized."
    correctionMessage: Try adding an initializer expression.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the variable that is invalid
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a static field or top-level
      variable has a type that's non-nullable and doesn't have an initializer.
      Fields and variables that don't have an initializer are normally
      initialized to `null`, but the type of the field or variable doesn't allow
      it to be set to `null`, so an explicit initializer must be provided.

      #### Examples

      The following code produces this diagnostic because the field `f` can't be
      initialized to `null`:

      ```dart
      class C {
        static int [!f!];
      }
      ```

      Similarly, the following code produces this diagnostic because the
      top-level variable `v` can't be initialized to `null`:

      ```dart
      int [!v!];
      ```

      #### Common fixes

      If the field or variable can't be initialized to `null`, then add an
      initializer that sets it to a non-null value:

      ```dart
      class C {
        static int f = 0;
      }
      ```

      If the field or variable should be initialized to `null`, then change the
      type to be nullable:

      ```dart
      int? v;
      ```

      If the field or variable can't be initialized in the declaration but will
      always be initialized before it's referenced, then mark it as being `late`:

      ```dart
      class C {
        static late int f;
      }
      ```
  NOT_INSTANTIATED_BOUND:
    problemMessage: Type parameter bound types must be instantiated.
    correctionMessage: Try adding type arguments to the type parameter bound.
    comment: No parameters.
  NOT_ITERABLE_SPREAD:
    problemMessage: "Spread elements in list or set literals must implement 'Iterable'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the static type of the
      expression of a spread element that appears in either a list literal or a
      set literal doesn't implement the type `Iterable`.

      #### Example

      The following code produces this diagnostic:

      ```dart
      var m = <String, int>{'a': 0, 'b': 1};
      var s = <String>{...[!m!]};
      ```

      #### Common fixes

      The most common fix is to replace the expression with one that produces an
      iterable object:

      ```dart
      var m = <String, int>{'a': 0, 'b': 1};
      var s = <String>{...m.keys};
      ```
  NOT_MAP_SPREAD:
    problemMessage: "Spread elements in map literals must implement 'Map'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the static type of the
      expression of a spread element that appears in a map literal doesn't
      implement the type `Map`.

      #### Example

      The following code produces this diagnostic because `l` isn't a `Map`:

      ```dart
      var l =  <String>['a', 'b'];
      var m = <int, String>{...[!l!]};
      ```

      #### Common fixes

      The most common fix is to replace the expression with one that produces a
      map:

      ```dart
      var l =  <String>['a', 'b'];
      var m = <int, String>{...l.asMap()};
      ```
  NOT_NULL_AWARE_NULL_SPREAD:
    problemMessage: "The Null typed expression can't be used with a non-null-aware spread."
    comment: No parameters.
  NO_ANNOTATION_CONSTRUCTOR_ARGUMENTS:
    problemMessage: Annotation creation must have arguments.
    correctionMessage: Try adding an empty argument list.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an annotation consists of a
      single identifier, but that identifier is the name of a class rather than a
      variable. To create an instance of the class, the identifier must be
      followed by an argument list.

      #### Example

      The following code produces this diagnostic because `C` is a class, and a
      class can't be used as an annotation without invoking a `const` constructor
      from the class:

      ```dart
      class C {
        const C();
      }

      [!@C!]
      var x;
      ```

      #### Common fixes

      Add the missing argument list:

      ```dart
      class C {
        const C();
      }

      @C()
      var x;
      ```
  NO_COMBINED_SUPER_SIGNATURE:
    problemMessage: "Can't infer missing types in '{0}' from overridden methods: {1}."
    correctionMessage: "Try providing explicit types for this method's parameters and return type."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class where override error was detected
      1: the list of candidate signatures which cannot be combined
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there is a method declaration
      for which one or more types needs to be inferred, and those types can't be
      inferred because none of the overridden methods has a function type that is
      a supertype of all the other overridden methods, as specified by
      [override inference][].

      #### Example

      The following code produces this diagnostic because the method `m` declared
      in the class `C` is missing both the return type and the type of the
      parameter `a`, and neither of the missing types can be inferred for it:

      ```dart
      abstract class A {
        A m(String a);
      }

      abstract class B {
        B m(int a);
      }

      abstract class C implements A, B {
        [!m!](a);
      }
      ```

      In this example, override inference can't be performed because the
      overridden methods are incompatible in these ways:
      - Neither parameter type (`String` and `int`) is a supertype of the other.
      - Neither return type is a subtype of the other.

      #### Common fixes

      If possible, add types to the method in the subclass that are consistent
      with the types from all the overridden methods:

      ```dart
      abstract class A {
        A m(String a);
      }

      abstract class B {
        B m(int a);
      }

      abstract class C implements A, B {
        C m(Object a);
      }
      ```
  NO_DEFAULT_SUPER_CONSTRUCTOR_EXPLICIT:
    sharedName: NO_DEFAULT_SUPER_CONSTRUCTOR
    problemMessage: "The superclass '{0}' doesn't have a zero argument constructor."
    correctionMessage: "Try declaring a zero argument constructor in '{0}', or explicitly invoking a different constructor in '{0}'."
    comment: |-
      Parameters:
      0: the name of the superclass that does not define an implicitly invoked
         constructor
  NO_DEFAULT_SUPER_CONSTRUCTOR_IMPLICIT:
    sharedName: NO_DEFAULT_SUPER_CONSTRUCTOR
    problemMessage: "The superclass '{0}' doesn't have a zero argument constructor."
    correctionMessage: "Try declaring a zero argument constructor in '{0}', or declaring a constructor in {1} that explicitly invokes a constructor in '{0}'."
    comment: |-
      Parameters:
      0: the name of the superclass that does not define an implicitly invoked
         constructor
      1: the name of the subclass that does not contain any explicit constructors
  NO_GENERATIVE_CONSTRUCTORS_IN_SUPERCLASS:
    problemMessage: "The class '{0}' can't extend '{1}' because '{1}' only has factory constructors (no generative constructors), and '{0}' has at least one generative constructor."
    correctionMessage: "Try implementing the class instead, adding a generative (not factory) constructor to the superclass '{1}', or a factory constructor to the subclass."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the superclass
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class that has at least one
      generative constructor (whether explicit or implicit) has a superclass
      that doesn't have any generative constructors. Every generative
      constructor, except the one defined in `Object`, invokes, either
      explicitly or implicitly, one of the generative constructors from its
      superclass.

      #### Example

      The following code produces this diagnostic because the class `B` has an
      implicit generative constructor that can't invoke a generative constructor
      from `A` because `A` doesn't have any generative constructors:

      ```dart
      class A {
        factory A.none() => throw '';
      }

      class B extends [!A!] {}
      ```

      #### Common fixes

      If the superclass should have a generative constructor, then add one:

      ```dart
      class A {
        A();
        factory A.none() => throw '';
      }

      class B extends A {}
      ```

      If the subclass shouldn't have a generative constructor, then remove it by
      adding a factory constructor:

      ```dart
      class A {
        factory A.none() => throw '';
      }

      class B extends A {
        factory B.none() => throw '';
      }
      ```

      If the subclass must have a generative constructor but the superclass
      can't have one, then implement the superclass instead:

      ```dart
      class A {
        factory A.none() => throw '';
      }

      class B implements A {}
      ```
  NULLABLE_TYPE_IN_EXTENDS_CLAUSE:
    problemMessage: "A class can't extend a nullable type."
    correctionMessage: Try removing the question mark.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class declaration uses an
      `extends` clause to specify a superclass, and the superclass is followed by
      a `?`.

      It isn't valid to specify a nullable superclass because doing so would have
      no meaning; it wouldn't change either the interface or implementation being
      inherited by the class containing the `extends` clause.

      Note, however, that it _is_ valid to use a nullable type as a type argument
      to the superclass, such as `class A extends B<C?> {}`.

      #### Example

      The following code produces this diagnostic because `A?` is a nullable
      type, and nullable types can't be used in an `extends` clause:

      ```dart
      class A {}
      class B extends [!A?!] {}
      ```

      #### Common fixes

      Remove the question mark from the type:

      ```dart
      class A {}
      class B extends A {}
      ```
  NULLABLE_TYPE_IN_IMPLEMENTS_CLAUSE:
    problemMessage: "A class or mixin can't implement a nullable type."
    correctionMessage: Try removing the question mark.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class or mixin declaration has
      an `implements` clause, and an interface is followed by a `?`.

      It isn't valid to specify a nullable interface because doing so would have
      no meaning; it wouldn't change the interface being inherited by the class
      containing the `implements` clause.

      Note, however, that it _is_ valid to use a nullable type as a type argument
      to the interface, such as `class A implements B<C?> {}`.


      #### Example

      The following code produces this diagnostic because `A?` is a nullable
      type, and nullable types can't be used in an `implements` clause:

      ```dart
      class A {}
      class B implements [!A?!] {}
      ```

      #### Common fixes

      Remove the question mark from the type:

      ```dart
      class A {}
      class B implements A {}
      ```
  NULLABLE_TYPE_IN_ON_CLAUSE:
    problemMessage: "A mixin can't have a nullable type as a superclass constraint."
    correctionMessage: Try removing the question mark.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a mixin declaration uses an `on`
      clause to specify a superclass constraint, and the class that's specified
      is followed by a `?`.

      It isn't valid to specify a nullable superclass constraint because doing so
      would have no meaning; it wouldn't change the interface being depended on
      by the mixin containing the `on` clause.

      Note, however, that it _is_ valid to use a nullable type as a type argument
      to the superclass constraint, such as `mixin A on B<C?> {}`.


      #### Example

      The following code produces this diagnostic because `A?` is a nullable type
      and nullable types can't be used in an `on` clause:

      ```dart
      class C {}
      mixin M on [!C?!] {}
      ```

      #### Common fixes

      Remove the question mark from the type:

      ```dart
      class C {}
      mixin M on C {}
      ```
  NULLABLE_TYPE_IN_WITH_CLAUSE:
    problemMessage: "A class or mixin can't mix in a nullable type."
    correctionMessage: Try removing the question mark.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class or mixin declaration has
      a `with` clause, and a mixin is followed by a `?`.

      It isn't valid to specify a nullable mixin because doing so would have no
      meaning; it wouldn't change either the interface or implementation being
      inherited by the class containing the `with` clause.

      Note, however, that it _is_ valid to use a nullable type as a type argument
      to the mixin, such as `class A with B<C?> {}`.

      #### Example

      The following code produces this diagnostic because `A?` is a nullable
      type, and nullable types can't be used in a `with` clause:

      ```dart
      mixin M {}
      class C with [!M?!] {}
      ```

      #### Common fixes

      Remove the question mark from the type:

      ```dart
      mixin M {}
      class C with M {}
      ```
  OBJECT_CANNOT_EXTEND_ANOTHER_CLASS:
    problemMessage: "The class 'Object' can't extend any other class."
    comment: |-
      7.9 Superclasses: It is a compile-time error to specify an extends clause
      for class Object.
  ON_REPEATED:
    problemMessage: "The type '{0}' can be included in the superclass constraints only once."
    correctionMessage: Try removing all except one occurrence of the type name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the interface that is implemented more than once
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the same type is listed in the
      superclass constraints of a mixin multiple times.

      #### Example

      The following code produces this diagnostic because `A` is included twice
      in the superclass constraints for `M`:

      ```dart
      mixin M on A, [!A!] {
      }

      class A {}
      class B {}
      ```

      #### Common fixes

      If a different type should be included in the superclass constraints, then
      replace one of the occurrences with the other type:

      ```dart
      mixin M on A, B {
      }

      class A {}
      class B {}
      ```

      If no other type was intended, then remove the repeated type name:

      ```dart
      mixin M on A {
      }

      class A {}
      class B {}
      ```
  OPTIONAL_PARAMETER_IN_OPERATOR:
    problemMessage: "Optional parameters aren't allowed when defining an operator."
    correctionMessage: Try removing the optional parameters.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when one or more of the parameters in
      an operator declaration are optional.

      #### Example

      The following code produces this diagnostic because the parameter `other`
      is an optional parameter:

      ```dart
      class C {
        C operator +([[!C? other!]]) => this;
      }
      ```

      #### Common fixes

      Make all of the parameters be required parameters:

      ```dart
      class C {
        C operator +(C other) => this;
      }
      ```
  PART_OF_DIFFERENT_LIBRARY:
    problemMessage: "Expected this library to be part of '{0}', not '{1}'."
    correctionMessage: "Try including a different part, or changing the name of the library in the part's part-of directive."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of expected library name
      1: the non-matching actual library name from the "part of" declaration
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library attempts to include a
      file as a part of itself when the other file is a part of a different
      library.

      #### Example

      Given a file named `part.dart` containing

      ```dart
      %uri="package:a/part.dart"
      part of 'library.dart';
      ```

      The following code, in any file other than `library.dart`, produces this
      diagnostic because it attempts to include `part.dart` as a part of itself
      when `part.dart` is a part of a different library:

      ```dart
      part [!'package:a/part.dart'!];
      ```

      #### Common fixes

      If the library should be using a different file as a part, then change the
      URI in the part directive to be the URI of the other file.

      If the [part file][] should be a part of this library, then update the URI
      (or library name) in the part-of directive to be the URI (or name) of the
      correct library.
  PART_OF_NON_PART:
    problemMessage: "The included part '{0}' must have a part-of directive."
    correctionMessage: "Try adding a part-of directive to '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the uri pointing to a non-library declaration
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a part directive is found and
      the referenced file doesn't have a part-of directive.

      #### Example

      Given a file (`a.dart`) containing:

      ```dart
      %uri="lib/a.dart"
      class A {}
      ```

      The following code produces this diagnostic because `a.dart` doesn't
      contain a part-of directive:

      ```dart
      part [!'a.dart'!];
      ```

      #### Common fixes

      If the referenced file is intended to be a part of another library, then
      add a part-of directive to the file:

      ```dart
      part of 'test.dart';

      class A {}
      ```

      If the referenced file is intended to be a library, then replace the part
      directive with an import directive:

      ```dart
      import 'a.dart';
      ```
  PART_OF_UNNAMED_LIBRARY:
    problemMessage: "The library is unnamed. A URI is expected, not a library name '{0}', in the part-of directive."
    correctionMessage: Try changing the part-of directive to a URI, or try including a different part.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the URI of the expected library
      1: the non-matching actual library name from the "part of" declaration
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library that doesn't have a
      `library` directive (and hence has no name) contains a `part` directive
      and the `part of` directive in the [part file][] uses a name to specify
      the library that it's a part of.

      #### Example

      Given a [part file][] named `part_file.dart` containing the following
      code:

      ```dart
      %uri="lib/part_file.dart"
      part of lib;
      ```

      The following code produces this diagnostic because the library including
      the [part file][] doesn't have a name even though the [part file][] uses a
      name to specify which library it's a part of:

      ```dart
      part [!'part_file.dart'!];
      ```

      #### Common fixes

      Change the `part of` directive in the [part file][] to specify its library
      by URI:

      ```dart
      part of 'test.dart';
      ```
  POSITIONAL_SUPER_FORMAL_PARAMETER_WITH_POSITIONAL_ARGUMENT:
    problemMessage: Positional super parameters can't be used when the super constructor invocation has a positional argument.
    correctionMessage: Try making all the positional parameters passed to the super constructor be either all super parameters or all normal parameters.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when some, but not all, of the
      positional parameters provided to the constructor of the superclass are
      using a super parameter.
      
      Positional super parameters are associated with positional parameters in
      the super constructor by their index. That is, the first super parameter
      is associated with the first positional parameter in the super
      constructor, the second with the second, and so on. The same is true for
      positional arguments. Having both positional super parameters and
      positional arguments means that there are two values associated with the
      same parameter in the superclass's constructor, and hence isn't allowed.
      
      #### Example
      
      The following code produces this diagnostic because the constructor
      `B.new` is using a super parameter to pass one of the required positional
      parameters to the super constructor in `A`, but is explicitly passing the
      other in the super constructor invocation:
      
      ```dart
      class A {
        A(int x, int y);
      }
      
      class B extends A {
        B(int x, super.[!y!]) : super(x);
      }
      ```
      
      #### Common fixes
      
      If all the positional parameters can be super parameters, then convert the
      normal positional parameters to be super parameters:
      
      ```dart
      class A {
        A(int x, int y);
      }
      
      class B extends A {
        B(super.x, super.y);
      }
      ```
      
      If some positional parameters can't be super parameters, then convert the
      super parameters to be normal parameters:
      
      ```dart
      class A {
        A(int x, int y);
      }
      
      class B extends A {
        B(int x, int y) : super(x, y);
      }
      ```
  PREFIX_COLLIDES_WITH_TOP_LEVEL_MEMBER:
    problemMessage: "The name '{0}' is already used as an import prefix and can't be used to name a top-level element."
    correctionMessage: Try renaming either the top-level element or the prefix.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the prefix
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name is used as both an import
      prefix and the name of a top-level declaration in the same library.

      #### Example

      The following code produces this diagnostic because `f` is used as both an
      import prefix and the name of a function:

      ```dart
      import 'dart:math' as f;

      int [!f!]() => f.min(0, 1);
      ```

      #### Common fixes

      If you want to use the name for the import prefix, then rename the
      top-level declaration:

      ```dart
      import 'dart:math' as f;

      int g() => f.min(0, 1);
      ```

      If you want to use the name for the top-level declaration, then rename the
      import prefix:

      ```dart
      import 'dart:math' as math;

      int f() => math.min(0, 1);
      ```
  PREFIX_IDENTIFIER_NOT_FOLLOWED_BY_DOT:
    problemMessage: "The name '{0}' refers to an import prefix, so it must be followed by '.'."
    correctionMessage: Try correcting the name to refer to something other than a prefix, or renaming the prefix.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the prefix
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import prefix is used by
      itself, without accessing any of the names declared in the libraries
      associated with the prefix. Prefixes aren't variables, and therefore can't
      be used as a value.

      #### Example

      The following code produces this diagnostic because the prefix `math` is
      being used as if it were a variable:

      ```dart
      import 'dart:math' as math;

      void f() {
        print([!math!]);
      }
      ```

      #### Common fixes

      If the code is incomplete, then reference something in one of the libraries
      associated with the prefix:

      ```dart
      import 'dart:math' as math;

      void f() {
        print(math.pi);
      }
      ```

      If the name is wrong, then correct the name.
  PREFIX_SHADOWED_BY_LOCAL_DECLARATION:
    problemMessage: "The prefix '{0}' can't be used here because it's shadowed by a local declaration."
    correctionMessage: Try renaming either the prefix or the local declaration.
    comment: |-
      Parameters:
      0: the prefix being shadowed
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import prefix is used in a
      context where it isn't visible because it was shadowed by a local
      declaration.

      #### Example

      The following code produces this diagnostic because the prefix `a` is
      being used to access the class `Future`, but isn't visible because it's
      shadowed by the parameter `a`:

      ```dart
      import 'dart:async' as a;

      a.Future? f(int a) {
        [!a!].Future? x;
        return x;
      }
      ```

      #### Common fixes

      Rename either the prefix:

      ```dart
      import 'dart:async' as p;

      p.Future? f(int a) {
        p.Future? x;
        return x;
      }
      ```

      Or rename the local variable:

      ```dart
      import 'dart:async' as a;

      a.Future? f(int p) {
        a.Future? x;
        return x;
      }
      ```
  PRIVATE_COLLISION_IN_MIXIN_APPLICATION:
    problemMessage: "The private name '{0}', defined by '{1}', conflicts with the same name defined by '{2}'."
    correctionMessage: "Try removing '{1}' from the 'with' clause."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the private name that collides
      1: the name of the first mixin
      2: the name of the second mixin
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when two mixins that define the same
      private member are used together in a single class in a library other than
      the one that defines the mixins.

      #### Example

      Given a file named `a.dart` containing the following code:

      ```dart
      %uri="lib/a.dart"
      class A {
        void _foo() {}
      }

      class B {
        void _foo() {}
      }
      ```

      The following code produces this diagnostic because the classes `A` and `B`
      both define the method `_foo`:

      ```dart
      import 'a.dart';

      class C extends Object with A, [!B!] {}
      ```

      #### Common fixes

      If you don't need both of the mixins, then remove one of them from the
      `with` clause:

      ```dart
      import 'a.dart';

      class C extends Object with A, [!B!] {}
      ```

      If you need both of the mixins, then rename the conflicting member in one
      of the two mixins.
  PRIVATE_OPTIONAL_PARAMETER:
    problemMessage: "Named parameters can't start with an underscore."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name of a named parameter
      starts with an underscore.

      #### Example

      The following code produces this diagnostic because the named parameter
      `_x` starts with an underscore:

      ```dart
      class C {
        void m({int [!_x!] = 0}) {}
      }
      ```

      #### Common fixes

      Rename the parameter so that it doesn't start with an underscore:

      ```dart
      class C {
        void m({int x = 0}) {}
      }
      ```
  PRIVATE_SETTER:
    problemMessage: "The setter '{0}' is private and can't be accessed outside the library that declares it."
    correctionMessage: Try making it public.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a private setter is used in a
      library where it isn't visible.

      #### Example

      Given a file named `a.dart` that contains the following:

      ```dart
      %uri="lib/a.dart"
      class A {
        static int _f = 0;
      }
      ```

      The following code produces this diagnostic because it references the
      private setter `_f` even though the setter isn't visible:

      ```dart
      import 'a.dart';

      void f() {
        A.[!_f!] = 0;
      }
      ```

      #### Common fixes

      If you're able to make the setter public, then do so:

      ```dart
      %uri="lib/a.dart"
      class A {
        static int f = 0;
      }
      ```

      If you aren't able to make the setter public, then find a different way to
      implement the code.
  READ_POTENTIALLY_UNASSIGNED_FINAL:
    problemMessage: "The final variable '{0}' can't be read because it's potentially unassigned at this point."
    correctionMessage: Ensure that it is assigned on necessary execution paths.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a final local variable that
      isn't initialized at the declaration site is read at a point where the
      compiler can't prove that the variable is always initialized before it's
      referenced.

      #### Example

      The following code produces this diagnostic because the final local
      variable `x` is read (on line 3) when it's possible that it hasn't yet
      been initialized:

      ```dart
      int f() {
        final int x;
        return [!x!];
      }
      ```

      #### Common fixes

      Ensure that the variable has been initialized before it's read:

      ```dart
      int f(bool b) {
        final int x;
        if (b) {
          x = 0;
        } else {
          x = 1;
        }
        return x;
      }
      ```
  RECURSIVE_COMPILE_TIME_CONSTANT:
    problemMessage: The compile-time constant expression depends on itself.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of a compile-time
      constant is defined in terms of itself, either directly or indirectly,
      creating an infinite loop.

      #### Example

      The following code produces this diagnostic twice because both of the
      constants are defined in terms of the other:

      ```dart
      const [!secondsPerHour!] = minutesPerHour * 60;
      const [!minutesPerHour!] = secondsPerHour / 60;
      ```

      #### Common fixes

      Break the cycle by finding an alternative way of defining at least one of
      the constants:

      ```dart
      const secondsPerHour = minutesPerHour * 60;
      const minutesPerHour = 60;
      ```
  RECURSIVE_CONSTRUCTOR_REDIRECT:
    problemMessage: "Constructors can't redirect to themselves either directly or indirectly."
    correctionMessage: Try changing one of the constructors in the loop to not redirect.
    hasPublishedDocs: true
    comment: |-
      No parameters.

      TODO(scheglov) review this later, there are no explicit "it is a
      compile-time error" in specification. But it was added to the co19 and
      there is same error for factories.

      https://code.google.com/p/dart/issues/detail?id=954
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor redirects to
      itself, either directly or indirectly, creating an infinite loop.

      #### Examples

      The following code produces this diagnostic because the generative
      constructors `C.a` and `C.b` each redirect to the other:

      ```dart
      class C {
        C.a() : [!this.b()!];
        C.b() : [!this.a()!];
      }
      ```

      The following code produces this diagnostic because the factory
      constructors `A` and `B` each redirect to the other:

      ```dart
      abstract class A {
        factory A() = [!B!];
      }
      class B implements A {
        factory B() = [!A!];
        B.named();
      }
      ```

      #### Common fixes

      In the case of generative constructors, break the cycle by finding defining
      at least one of the constructors to not redirect to another constructor:

      ```dart
      class C {
        C.a() : this.b();
        C.b();
      }
      ```

      In the case of factory constructors, break the cycle by defining at least
      one of the factory constructors to do one of the following:

      - Redirect to a generative constructor:

      ```dart
      abstract class A {
        factory A() = B;
      }
      class B implements A {
        factory B() = B.named;
        B.named();
      }
      ```

      - Not redirect to another constructor:

      ```dart
      abstract class A {
        factory A() = B;
      }
      class B implements A {
        factory B() {
          return B.named();
        }

        B.named();
      }
      ```

      - Not be a factory constructor:

      ```dart
      abstract class A {
        factory A() = B;
      }
      class B implements A {
        B();
        B.named();
      }
      ```
  RECURSIVE_FACTORY_REDIRECT:
    sharedName: RECURSIVE_CONSTRUCTOR_REDIRECT
    problemMessage: "Constructors can't redirect to themselves either directly or indirectly."
    correctionMessage: Try changing one of the constructors in the loop to not redirect.
    hasPublishedDocs: true
    comment: No parameters.
  RECURSIVE_INTERFACE_INHERITANCE:
    problemMessage: "'{0}' can't be a superinterface of itself: {1}."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class that implements itself recursively
      1: a string representation of the implements loop
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's a circularity in the
      type hierarchy. This happens when a type, either directly or indirectly,
      is declared to be a subtype of itself.

      #### Example

      The following code produces this diagnostic because the class `A` is
      declared to be a subtype of `B`, and `B` is a subtype of `A`:

      ```dart
      class [!A!] extends B {}
      class B implements A {}
      ```

      #### Common fixes

      Change the type hierarchy so that there's no circularity.
  RECURSIVE_INTERFACE_INHERITANCE_EXTENDS:
    sharedName: RECURSIVE_INTERFACE_INHERITANCE
    problemMessage: "'{0}' can't extend itself."
    hasPublishedDocs: true
    comment: |-
      7.10 Superinterfaces: It is a compile-time error if the interface of a
      class <i>C</i> is a superinterface of itself.

      8.1 Superinterfaces: It is a compile-time error if an interface is a
      superinterface of itself.

      7.9 Superclasses: It is a compile-time error if a class <i>C</i> is a
      superclass of itself.

      Parameters:
      0: the name of the class that implements itself recursively
  RECURSIVE_INTERFACE_INHERITANCE_IMPLEMENTS:
    sharedName: RECURSIVE_INTERFACE_INHERITANCE
    problemMessage: "'{0}' can't implement itself."
    hasPublishedDocs: true
    comment: |-
      7.10 Superinterfaces: It is a compile-time error if the interface of a
      class <i>C</i> is a superinterface of itself.

      8.1 Superinterfaces: It is a compile-time error if an interface is a
      superinterface of itself.

      7.9 Superclasses: It is a compile-time error if a class <i>C</i> is a
      superclass of itself.

      Parameters:
      0: the name of the class that implements itself recursively
  RECURSIVE_INTERFACE_INHERITANCE_ON:
    sharedName: RECURSIVE_INTERFACE_INHERITANCE
    problemMessage: "'{0}' can't use itself as a superclass constraint."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the mixin that constraints itself recursively
  RECURSIVE_INTERFACE_INHERITANCE_WITH:
    sharedName: RECURSIVE_INTERFACE_INHERITANCE
    problemMessage: "'{0}' can't use itself as a mixin."
    hasPublishedDocs: true
    comment: |-
      7.10 Superinterfaces: It is a compile-time error if the interface of a
      class <i>C</i> is a superinterface of itself.

      8.1 Superinterfaces: It is a compile-time error if an interface is a
      superinterface of itself.

      7.9 Superclasses: It is a compile-time error if a class <i>C</i> is a
      superclass of itself.

      Parameters:
      0: the name of the class that implements itself recursively
  REDIRECT_GENERATIVE_TO_MISSING_CONSTRUCTOR:
    problemMessage: "The constructor '{0}' couldn't be found in '{1}'."
    correctionMessage: "Try redirecting to a different constructor, or defining the constructor named '{0}'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generative constructor
      redirects to a constructor that isn't defined.

      #### Example

      The following code produces this diagnostic because the constructor `C.a`
      redirects to the constructor `C.b`, but `C.b` isn't defined:

      ```dart
      class C {
        C.a() : [!this.b()!];
      }
      ```

      #### Common fixes

      If the missing constructor must be called, then define it:

      ```dart
      class C {
        C.a() : this.b();
        C.b();
      }
      ```

      If the missing constructor doesn't need to be called, then remove the
      redirect:

      ```dart
      class C {
        C.a();
      }
      ```
  REDIRECT_GENERATIVE_TO_NON_GENERATIVE_CONSTRUCTOR:
    problemMessage: "Generative constructors can't redirect to a factory constructor."
    correctionMessage: Try redirecting to a different constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generative constructor
      redirects to a factory constructor.

      #### Example

      The following code produces this diagnostic because the generative
      constructor `C.a` redirects to the factory constructor `C.b`:

      ```dart
      class C {
        C.a() : [!this.b()!];
        factory C.b() => C.a();
      }
      ```

      #### Common fixes

      If the generative constructor doesn't need to redirect to another
      constructor, then remove the redirect.

      ```dart
      class C {
        C.a();
        factory C.b() => C.a();
      }
      ```

      If the generative constructor must redirect to another constructor, then
      make the other constructor be a generative (non-factory) constructor:

      ```dart
      class C {
        C.a() : this.b();
        C.b();
      }
      ```
  REDIRECT_TO_ABSTRACT_CLASS_CONSTRUCTOR:
    problemMessage: "The redirecting constructor '{0}' can't redirect to a constructor of the abstract class '{1}'."
    correctionMessage: Try redirecting to a constructor of a different class.
    comment: |-
      Parameters:
      0: the name of the redirecting constructor
      1: the name of the abstract class defining the constructor being redirected to
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor redirects to a
      constructor in an abstract class.

      #### Example

      The following code produces this diagnostic because the factory
      constructor in `A` redirects to a constructor in `B`, but `B` is an
      abstract class:

      ```dart
      class A {
        factory A() = [!B!];
      }

      abstract class B implements A {}
      ```

      #### Common fixes

      If the code redirects to the correct constructor, then change the class so
      that it isn't abstract:

      ```dart
      class A {
        factory A() = B;
      }

      class B implements A {}
      ```

      Otherwise, change the factory constructor so that it either redirects to a
      constructor in a concrete class, or has a concrete implementation.
  REDIRECT_TO_INVALID_FUNCTION_TYPE:
    problemMessage: "The redirected constructor '{0}' has incompatible parameters with '{1}'."
    correctionMessage: Try redirecting to a different constructor.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the redirected constructor
      1: the name of the redirecting constructor
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a factory constructor attempts
      to redirect to another constructor, but the two have incompatible
      parameters. The parameters are compatible if all of the parameters of the
      redirecting constructor can be passed to the other constructor and if the
      other constructor doesn't require any parameters that aren't declared by
      the redirecting constructor.

      #### Examples

      The following code produces this diagnostic because the constructor for `A`
      doesn't declare a parameter that the constructor for `B` requires:

      ```dart
      abstract class A {
        factory A() = [!B!];
      }

      class B implements A {
        B(int x);
        B.zero();
      }
      ```

      The following code produces this diagnostic because the constructor for `A`
      declares a named parameter (`y`) that the constructor for `B` doesn't
      allow:

      ```dart
      abstract class A {
        factory A(int x, {int y}) = [!B!];
      }

      class B implements A {
        B(int x);
      }
      ```

      #### Common fixes

      If there's a different constructor that is compatible with the redirecting
      constructor, then redirect to that constructor:

      ```dart
      abstract class A {
        factory A() = B.zero;
      }

      class B implements A {
        B(int x);
        B.zero();
      }
      ```

      Otherwise, update the redirecting constructor to be compatible:

      ```dart
      abstract class A {
        factory A(int x) = B;
      }

      class B implements A {
        B(int x);
      }
      ```
  REDIRECT_TO_INVALID_RETURN_TYPE:
    problemMessage: "The return type '{0}' of the redirected constructor isn't a subtype of '{1}'."
    correctionMessage: Try redirecting to a different constructor.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the redirected constructor's return type
      1: the name of the redirecting constructor's return type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a factory constructor redirects
      to a constructor whose return type isn't a subtype of the type that the
      factory constructor is declared to produce.

      #### Example

      The following code produces this diagnostic because `A` isn't a subclass
      of `C`, which means that the value returned by the constructor `A()`
      couldn't be returned from the constructor `C()`:

      ```dart
      class A {}

      class B implements C {}

      class C {
        factory C() = [!A!];
      }
      ```

      #### Common fixes

      If the factory constructor is redirecting to a constructor in the wrong
      class, then update the factory constructor to redirect to the correct
      constructor:

      ```dart
      class A {}

      class B implements C {}

      class C {
        factory C() = B;
      }
      ```

      If the class defining the constructor being redirected to is the class that
      should be returned, then make it a subtype of the factory's return type:

      ```dart
      class A implements C {}

      class B implements C {}

      class C {
        factory C() = A;
      }
      ```
  REDIRECT_TO_MISSING_CONSTRUCTOR:
    problemMessage: "The constructor '{0}' couldn't be found in '{1}'."
    correctionMessage: "Try redirecting to a different constructor, or define the constructor named '{0}'."
    comment: |-
      Parameters:
      0: the name of the constructor
      1: the name of the class containing the constructor
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor redirects to a
      constructor that doesn't exist.

      #### Example

      The following code produces this diagnostic because the factory
      constructor in `A` redirects to a constructor in `B` that doesn't exist:

      ```dart
      class A {
        factory A() = [!B.name!];
      }

      class B implements A {
        B();
      }
      ```

      #### Common fixes

      If the constructor being redirected to is correct, then define the
      constructor:

      ```dart
      class A {
        factory A() = B.name;
      }

      class B implements A {
        B();
        B.name();
      }
      ```

      If a different constructor should be invoked, then update the redirect:

      ```dart
      class A {
        factory A() = B;
      }

      class B implements A {
        B();
      }
      ```
  REDIRECT_TO_NON_CLASS:
    problemMessage: "The name '{0}' isn't a type and can't be used in a redirected constructor."
    correctionMessage: Try redirecting to a different constructor.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the non-type referenced in the redirect
    documentation: |-
      #### Description

      One way to implement a factory constructor is to redirect to another
      constructor by referencing the name of the constructor. The analyzer
      produces this diagnostic when the redirect is to something other than a
      constructor.

      #### Example

      The following code produces this diagnostic because `f` is a function:

      ```dart
      C f() => throw 0;

      class C {
        factory C() = [!f!];
      }
      ```

      #### Common fixes

      If the constructor isn't defined, then either define it or replace it with
      a constructor that is defined.

      If the constructor is defined but the class that defines it isn't visible,
      then you probably need to add an import.

      If you're trying to return the value returned by a function, then rewrite
      the constructor to return the value from the constructor's body:

      ```dart
      C f() => throw 0;

      class C {
        factory C() => f();
      }
      ```
  REDIRECT_TO_NON_CONST_CONSTRUCTOR:
    problemMessage: "A constant redirecting constructor can't redirect to a non-constant constructor."
    correctionMessage: Try redirecting to a different constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor marked as `const`
      redirects to a constructor that isn't marked as `const`.

      #### Example

      The following code produces this diagnostic because the constructor `C.a`
      is marked as `const` but redirects to the constructor `C.b`, which isn't:

      ```dart
      class C {
        const C.a() : this.[!b!]();
        C.b();
      }
      ```

      #### Common fixes

      If the non-constant constructor can be marked as `const`, then mark it as
      `const`:

      ```dart
      class C {
        const C.a() : this.b();
        const C.b();
      }
      ```

      If the non-constant constructor can't be marked as `const`, then either
      remove the redirect or remove `const` from the redirecting constructor:

      ```dart
      class C {
        C.a() : this.b();
        C.b();
      }
      ```
  REDIRECT_TO_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    problemMessage: "A redirecting constructor can't redirect to a type alias that expands to a type parameter."
    correctionMessage: Try replacing it with a class.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a redirecting factory
      constructor redirects to a type alias, and the type alias expands to one of
      the type parameters of the type alias. This isn’t allowed because the value
      of the type parameter is a type rather than a class.

      #### Example

      The following code produces this diagnostic because the redirect to `B<A>`
      is to a type alias whose value is `T`, even though it looks like the value
      should be `A`:

      ```dart
      class A implements C {}

      typedef B<T> = T;

      abstract class C {
        factory C() = [!B!]<A>;
      }
      ```

      #### Common fixes

      Use either a class name or a type alias that is defined to be a class
      rather than a type alias defined to be a type parameter:

      ```dart
      class A implements C {}

      abstract class C {
        factory C() = A;
      }
      ```
  REFERENCED_BEFORE_DECLARATION:
    problemMessage: "Local variable '{0}' can't be referenced before it is declared."
    correctionMessage: "Try moving the declaration to before the first use, or renaming the local variable so that it doesn't hide a name from an enclosing scope."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a variable is referenced before
      it’s declared. In Dart, variables are visible everywhere in the block in
      which they are declared, but can only be referenced after they are
      declared.

      The analyzer also produces a context message that indicates where the
      declaration is located.

      #### Example

      The following code produces this diagnostic because `i` is used before it
      is declared:

      ```dart
      %language=2.9
      void f() {
        print([!i!]);
        int i = 5;
      }
      ```

      #### Common fixes

      If you intended to reference the local variable, move the declaration
      before the first reference:

      ```dart
      %language=2.9
      void f() {
        int i = 5;
        print(i);
      }
      ```

      If you intended to reference a name from an outer scope, such as a
      parameter, instance field or top-level variable, then rename the local
      declaration so that it doesn't hide the outer variable.

      ```dart
      %language=2.9
      void f(int i) {
        print(i);
        int x = 5;
        print(x);
      }
      ```
  RETHROW_OUTSIDE_CATCH:
    problemMessage: A rethrow must be inside of a catch clause.
    correctionMessage: "Try moving the expression into a catch clause, or using a 'throw' expression."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `rethrow` statement is outside
      a `catch` clause. The `rethrow` statement is used to throw a caught
      exception again, but there's no caught exception outside of a `catch`
      clause.

      #### Example

      The following code produces this diagnostic because the`rethrow` statement
      is outside of a `catch` clause:

      ```dart
      void f() {
        [!rethrow!];
      }
      ```

      #### Common fixes

      If you're trying to rethrow an exception, then wrap the `rethrow` statement
      in a `catch` clause:

      ```dart
      void f() {
        try {
          // ...
        } catch (exception) {
          rethrow;
        }
      }
      ```

      If you're trying to throw a new exception, then replace the `rethrow`
      statement with a `throw` expression:

      ```dart
      void f() {
        throw UnsupportedError('Not yet implemented');
      }
      ```
  RETURN_IN_GENERATIVE_CONSTRUCTOR:
    problemMessage: "Constructors can't return values."
    correctionMessage: Try removing the return statement or using a factory constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generative constructor
      contains a `return` statement that specifies a value to be returned.
      Generative constructors always return the object that was created, and
      therefore can't return a different object.

      #### Example

      The following code produces this diagnostic because the `return` statement
      has an expression:

      ```dart
      class C {
        C() {
          return [!this!];
        }
      }
      ```

      #### Common fixes

      If the constructor should create a new instance, then remove either the
      `return` statement or the expression:

      ```dart
      class C {
        C();
      }
      ```

      If the constructor shouldn't create a new instance, then convert it to be a
      factory constructor:

      ```dart
      class C {
        factory C() {
          return _instance;
        }

        static C _instance = C._();

        C._();
      }
      ```
  RETURN_IN_GENERATOR:
    problemMessage: "Can't return a value from a generator function that uses the 'async*' or 'sync*' modifier."
    correctionMessage: "Try replacing 'return' with 'yield', using a block function body, or changing the method body modifier."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generator function (one whose
      body is marked with either `async*` or `sync*`) uses either a `return`
      statement to return a value or implicitly returns a value because of using
      `=>`. In any of these cases, they should use `yield` instead of `return`.

      #### Examples

      The following code produces this diagnostic because the method `f` is a
      generator and is using `return` to return a value:

      ```dart
      Iterable<int> f() sync* {
        [!return 3!];
      }
      ```

      The following code produces this diagnostic because the function `f` is a
      generator and is implicitly returning a value:

      ```dart
      Stream<int> f() async* [!=>!] 3;
      ```

      #### Common fixes

      If the function is using `=>` for the body of the function, then convert it
      to a block function body, and use `yield` to return a value:

      ```dart
      Stream<int> f() async* {
        yield 3;
      }
      ```

      If the method is intended to be a generator, then use `yield` to return a
      value:

      ```dart
      Iterable<int> f() sync* {
        yield 3;
      }
      ```

      If the method isn't intended to be a generator, then remove the modifier
      from the body (or use `async` if you're returning a future):

      ```dart
      int f() {
        return 3;
      }
      ```
  RETURN_OF_INVALID_TYPE_FROM_CONSTRUCTOR:
    sharedName: RETURN_OF_INVALID_TYPE
    problemMessage: "A value of type '{0}' can't be returned from the constructor '{2}' because it has a return type of '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type as declared in the return statement
      1: the expected return type as defined by the enclosing class
      2: the name of the constructor
  RETURN_OF_INVALID_TYPE_FROM_FUNCTION:
    sharedName: RETURN_OF_INVALID_TYPE
    problemMessage: "A value of type '{0}' can't be returned from the function '{2}' because it has a return type of '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type as declared in the return statement
      1: the expected return type as defined by the method
      2: the name of the method
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function returns a
      value whose type isn't assignable to the declared return type.

      #### Example

      The following code produces this diagnostic because `f` has a return type
      of `String` but is returning an `int`:

      ```dart
      String f() => [!3!];
      ```

      #### Common fixes

      If the return type is correct, then replace the value being returned with a
      value of the correct type, possibly by converting the existing value:

      ```dart
      String f() => 3.toString();
      ```

      If the value is correct, then change the return type to match:

      ```dart
      int f() => 3;
      ```
  RETURN_OF_INVALID_TYPE_FROM_METHOD:
    sharedName: RETURN_OF_INVALID_TYPE
    problemMessage: "A value of type '{0}' can't be returned from the method '{2}' because it has a return type of '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type as declared in the return statement
      1: the expected return type as defined by the method
      2: the name of the method
  RETURN_OF_INVALID_TYPE_FROM_CLOSURE:
    problemMessage: "The return type '{0}' isn't a '{1}', as required by the closure's context."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type as declared in the return statement
      1: the expected return type as defined by the method
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the static type of a returned
      expression isn't assignable to the return type that the closure is required
      to have.

      #### Example

      The following code produces this diagnostic because `f` is defined to be a
      function that returns a `String`, but the closure assigned to it returns an
      `int`:

      ```dart
      String Function(String) f = (s) => [!3!];
      ```

      #### Common fixes

      If the return type is correct, then replace the returned value with a value
      of the correct type, possibly by converting the existing value:

      ```dart
      String Function(String) f = (s) => 3.toString();
      ```
  RETURN_WITHOUT_VALUE:
    problemMessage: "The return value is missing after 'return'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds a `return` statement
      without an expression in a function that declares a return type.

      #### Example

      The following code produces this diagnostic because the function `f` is
      expected to return an `int`, but no value is being returned:

      ```dart
      int f() {
        [!return!];
      }
      ```

      #### Common fixes

      Add an expression that computes the value to be returned:

      ```dart
      int f() {
        return 0;
      }
      ```
  SET_ELEMENT_TYPE_NOT_ASSIGNABLE:
    problemMessage: "The element type '{0}' can't be assigned to the set type '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the actual type of the set element
      1: the expected type of the set element
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an element in a set literal has
      a type that isn't assignable to the element type of the set.

      #### Example

      The following code produces this diagnostic because the type of the string
      literal `'0'` is `String`, which isn't assignable to `int`, the element
      type of the set:

      ```dart
      var s = <int>{[!'0'!]};
      ```

      #### Common fixes

      If the element type of the set literal is wrong, then change the element
      type of the set:

      ```dart
      var s = <String>{'0'};
      ```

      If the type of the element is wrong, then change the element:

      ```dart
      var s = <int>{'0'.length};
      ```
  SHARED_DEFERRED_PREFIX:
    problemMessage: "The prefix of a deferred import can't be used in other import directives."
    correctionMessage: Try renaming one of the prefixes.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a prefix in a deferred import is
      also used as a prefix in other imports (whether deferred or not). The
      prefix in a deferred import can't be shared with other imports because the
      prefix is used to load the imported library.

      #### Example

      The following code produces this diagnostic because the prefix `x` is used
      as the prefix for a deferred import and is also used for one other import:

      ```dart
      import 'dart:math' [!deferred!] as x;
      import 'dart:convert' as x;

      var y = x.json.encode(x.min(0, 1));
      ```

      #### Common fixes

      If you can use a different name for the deferred import, then do so:

      ```dart
      import 'dart:math' deferred as math;
      import 'dart:convert' as x;

      var y = x.json.encode(math.min(0, 1));
      ```

      If you can use a different name for the other imports, then do so:

      ```dart
      import 'dart:math' deferred as x;
      import 'dart:convert' as convert;

      var y = convert.json.encode(x.min(0, 1));
      ```
  SPREAD_EXPRESSION_FROM_DEFERRED_LIBRARY:
    problemMessage: "Constant values from a deferred library can't be spread into a const literal."
    correctionMessage: Try making the deferred import non-deferred.
  STATIC_ACCESS_TO_INSTANCE_MEMBER:
    problemMessage: "Instance member '{0}' can't be accessed using static access."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the instance member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class name is used to access
      an instance field. Instance fields don't exist on a class; they exist only
      on an instance of the class.

      #### Example

      The following code produces this diagnostic because `x` is an instance
      field:

      ```dart
      %language=2.9
      class C {
        static int a;

        int b;
      }

      int f() => C.[!b!];
      ```

      #### Common fixes

      If you intend to access a static field, then change the name of the field
      to an existing static field:

      ```dart
      %language=2.9
      class C {
        static int a;

        int b;
      }

      int f() => C.a;
      ```

      If you intend to access the instance field, then use an instance of the
      class to access the field:

      ```dart
      %language=2.9
      class C {
        static int a;

        int b;
      }

      int f(C c) => c.b;
      ```
  SUPER_FORMAL_PARAMETER_TYPE_IS_NOT_SUBTYPE_OF_ASSOCIATED:
    problemMessage: The type '{0}' of this parameter isn't a subtype of the type '{1}' of the associated super constructor parameter.
    correctionMessage: Try removing the explicit type annotation from the parameter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of super-parameter
      1: the type of associated super-constructor parameter
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when the type of a super parameter
      isn't a subtype of the corresponding parameter from the super constructor.
      
      #### Example
      
      The following code produces this diagnostic because the type of the super
      parameter `x` in the constructor for `B` isn't a subtype of the parameter
      `x` in the constructor for `A`:
      
      ```dart
      class A {
        A(num x);
      }
      
      class B extends A {
        B(String super.[!x!]);
      }
      ```
      
      #### Common fixes
      
      If the type of the super parameter can be the same as the parameter from
      the super constructor, then remove the type annotation from the super
      parameter (if the type is implicit, it is inferred from the type in the
      super constructor):
      
      ```dart
      class A {
        A(num x);
      }
      
      class B extends A {
        B(super.x);
      }
      ```
      
      If the type of the super parameter can be a subtype of the corresponding
      parameter's type, then change the type of the super parameter:
      
      ```dart
      class A {
        A(num x);
      }
      
      class B extends A {
        B(int super.x);
      }
      ```
      
      If the type of the super parameter can't be changed, then use a normal
      parameter instead of a super parameter:
      
      ```dart
      class A {
        A(num x);
      }
      
      class B extends A {
        B(String x) : super(x.length);
      }
      ```
  SUPER_FORMAL_PARAMETER_WITHOUT_ASSOCIATED_NAMED:
    problemMessage: No associated named super constructor parameter.
    correctionMessage: Try changing the name to the name of an existing named super constructor parameter, or creating such named parameter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when there's a named super parameter
      in a constructor and the implicitly or explicitly invoked super
      constructor doesn't have a named parameter with the same name.
      
      Named super parameters are associated by name with named parameters in the
      super constructor.
      
      #### Example
      
      The following code produces this diagnostic because the constructor in `A`
      doesn't have a parameter named `y`:
      
      ```dart
      class A {
        A({int? x});
      }
      
      class B extends A {
        B({super.[!y!]});
      }
      ```
      
      #### Common fixes
      
      If the super parameter should be associated with an existing parameter
      from the super constructor, then change the name to match the name of the
      corresponding parameter:
      
      ```dart
      class A {
        A({int? x});
      }
      
      class B extends A {
        B({super.x});
      }
      ```
      
      If the super parameter should be associated with a parameter that hasn't
      yet been added to the super constructor, then add it:
      
      ```dart
      class A {
        A({int? x, int? y});
      }
      
      class B extends A {
        B({super.y});
      }
      ```
      
      If the super parameter doesn't correspond to a named parameter from the
      super constructor, then change it to be a normal parameter:
      
      ```dart
      class A {
        A({int? x});
      }
      
      class B extends A {
        B({int? y});
      }
      ```
  SUPER_FORMAL_PARAMETER_WITHOUT_ASSOCIATED_POSITIONAL:
    problemMessage: No associated positional super constructor parameter.
    correctionMessage: Try using a normal parameter, or adding more positional parameters to the super constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when there's a positional super
      parameter in a constructor and the implicitly or explicitly invoked super
      constructor doesn't have a positional parameter at the corresponding
      index.
      
      Positional super parameters are associated with positional parameters in
      the super constructor by their index. That is, the first super parameter
      is associated with the first positional parameter in the super
      constructor, the second with the second, and so on.
      
      #### Examples
      
      The following code produces this diagnostic because the constructor in `B`
      has a positional super parameter, but there's no positional parameter in
      the super constructor in `A`:
      
      ```dart
      class A {
        A({int? x});
      }
      
      class B extends A {
        B(super.[!x!]);
      }
      ```
      
      The following code produces this diagnostic because the constructor in `B`
      has two positional super parameters, but there's only one positional
      parameter in the super constructor in `A`, which means that there's no
      corresponding parameter for `y`:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        B(super.x, super.[!y!]);
      }
      ```
      
      #### Common fixes
      
      If the super constructor should have a positional parameter corresponding
      to the super parameter, then update the super constructor appropriately:
      
      ```dart
      class A {
        A(int x, int y);
      }
      
      class B extends A {
        B(super.x, super.y);
      }
      ```
      
      If the super constructor is correct, or can't be changed, then convert the
      super parameter into a normal parameter:
      
      ```dart
      class A {
        A(int x);
      }
      
      class B extends A {
        B(super.x, int y);
      }
      ```
  IMPLEMENTS_DEFERRED_CLASS:
    sharedName: SUBTYPE_OF_DEFERRED_CLASS
    problemMessage: "Classes and mixins can't implement deferred classes."
    correctionMessage: Try specifying a different interface, removing the class from the list, or changing the import to not be deferred.
    hasPublishedDocs: true
    comment: No parameters.
  MIXIN_DEFERRED_CLASS:
    sharedName: SUBTYPE_OF_DEFERRED_CLASS
    problemMessage: "Classes can't mixin deferred classes."
    correctionMessage: Try changing the import to not be deferred.
    hasPublishedDocs: true
    comment: No parameters.
  EXTENDS_DEFERRED_CLASS:
    sharedName: SUBTYPE_OF_DEFERRED_CLASS
    problemMessage: "Classes can't extend deferred classes."
    correctionMessage: Try specifying a different superclass, or removing the extends clause.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type (class or mixin) is a
      subtype of a class from a library being imported using a deferred import.
      The supertypes of a type must be compiled at the same time as the type, and
      classes from deferred libraries aren't compiled until the library is
      loaded.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines the class `A`:

      ```dart
      %uri="lib/a.dart"
      class A {}
      ```

      The following code produces this diagnostic because the superclass of `B`
      is declared in a deferred library:

      ```dart
      import 'a.dart' deferred as a;

      class B extends [!a.A!] {}
      ```

      #### Common fixes

      If you need to create a subtype of a type from the deferred library, then
      remove the `deferred` keyword:

      ```dart
      import 'a.dart' as a;

      class B extends a.A {}
      ```
  EXTENDS_DISALLOWED_CLASS:
    sharedName: SUBTYPE_OF_DISALLOWED_TYPE
    problemMessage: "Classes can't extend '{0}'."
    correctionMessage: Try specifying a different superclass, or removing the extends clause.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the disallowed type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when one of the restricted classes is
      used in either an `extends`, `implements`, `with`, or `on` clause. The
      classes `bool`, `double`, `FutureOr`, `int`, `Null`, `num`, and `String`
      are all restricted in this way, to allow for more efficient
      implementations.

      #### Examples

      The following code produces this diagnostic because `String` is used in an
      `extends` clause:

      ```dart
      class A extends [!String!] {}
      ```

      The following code produces this diagnostic because `String` is used in an
      `implements` clause:

      ```dart
      class B implements [!String!] {}
      ```

      The following code produces this diagnostic because `String` is used in a
      `with` clause:

      ```dart
      class C with [!String!] {}
      ```

      The following code produces this diagnostic because `String` is used in an
      `on` clause:

      ```dart
      mixin M on [!String!] {}
      ```

      #### Common fixes

      If a different type should be specified, then replace the type:

      ```dart
      class A extends Object {}
      ```

      If there isn't a different type that would be appropriate, then remove the
      type, and possibly the whole clause:

      ```dart
      class B {}
      ```
  MIXIN_OF_DISALLOWED_CLASS:
    sharedName: SUBTYPE_OF_DISALLOWED_TYPE
    problemMessage: "Classes can't mixin '{0}'."
    correctionMessage: Try specifying a different class or mixin, or remove the class or mixin from the list.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the disallowed type
  MIXIN_SUPER_CLASS_CONSTRAINT_DISALLOWED_CLASS:
    sharedName: SUBTYPE_OF_DISALLOWED_TYPE
    problemMessage: "''{0}' can't be used as a superclass constraint."
    correctionMessage: "Try specifying a different super-class constraint, or remove the 'on' clause."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the disallowed type
  IMPLEMENTS_DISALLOWED_CLASS:
    sharedName: SUBTYPE_OF_DISALLOWED_TYPE
    problemMessage: "Classes and mixins can't implement '{0}'."
    correctionMessage: Try specifying a different interface, or remove the class from the list.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the disallowed type
  EXTENDS_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    sharedName: SUPERTYPE_EXPANDS_TO_TYPE_PARAMETER
    problemMessage: "A type alias that expands to a type parameter can't be used as a superclass."
    correctionMessage: Try specifying a different superclass, or removing the extends clause.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type alias that expands to a
      type parameter is used in an `extends`, `implements`, `with`, or `on`
      clause.

      #### Example

      The following code produces this diagnostic because the type alias `T`,
      which expands to the type parameter `S`, is used in the `extends` clause of
      the class `C`:

      ```dart
      typedef T<S> = S;

      class C extends [!T!]<Object> {}
      ```

      #### Common fixes

      Use the value of the type argument directly:

      ```dart
      typedef T<S> = S;

      class C extends Object {}
      ```
  MIXIN_ON_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    sharedName: SUPERTYPE_EXPANDS_TO_TYPE_PARAMETER
    problemMessage: "A type alias that expands to a type parameter can't be used as a superclass constraint."
    hasPublishedDocs: true
    comment: No parameters.
  MIXIN_OF_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    sharedName: SUPERTYPE_EXPANDS_TO_TYPE_PARAMETER
    problemMessage: "A type alias that expands to a type parameter can't be mixed in."
    hasPublishedDocs: true
    comment: No parameters.
  IMPLEMENTS_TYPE_ALIAS_EXPANDS_TO_TYPE_PARAMETER:
    sharedName: SUPERTYPE_EXPANDS_TO_TYPE_PARAMETER
    problemMessage: "A type alias that expands to a type parameter can't be implemented."
    correctionMessage: Try specifying a class or mixin, or removing the list.
    hasPublishedDocs: true
    comment: No parameters.
  SUPER_INITIALIZER_IN_OBJECT:
    problemMessage: "The class 'Object' can't invoke a constructor from a superclass."
    comment: |-
      7.6.1 Generative Constructors: Let <i>k</i> be a generative constructor. It
      is a compile-time error if a generative constructor of class Object
      includes a superinitializer.
  SUPER_INVOCATION_NOT_LAST:
    previousName: INVALID_SUPER_INVOCATION
    problemMessage: "The superconstructor call must be last in an initializer list: '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the superinitializer
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the initializer list of a
      constructor contains an invocation of a constructor in the superclass, but
      the invocation isn't the last item in the initializer list.

      #### Example

      The following code produces this diagnostic because the invocation of the
      superclass' constructor isn't the last item in the initializer list:

      ```dart
      class A {
        A(int x);
      }

      class B extends A {
        B(int x) : [!super!](x), assert(x >= 0);
      }
      ```

      #### Common fixes

      Move the invocation of the superclass' constructor to the end of the
      initializer list:

      ```dart
      class A {
        A(int x);
      }

      class B extends A {
        B(int x) : assert(x >= 0), super(x);
      }
      ```
  SUPER_IN_ENUM_CONSTRUCTOR:
    problemMessage: The enum constructor can't have a 'super' initializer.
    correctionMessage: Try removing the 'super' invocation.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when the initializer list in a
      constructor in an enum contains an invocation of a super constructor.
      
      #### Example
      
      The following code produces this diagnostic because the constructor in
      the enum `E` has a super constructor invocation in the initializer list:
      
      ```dart
      enum E {
        e;
      
        const E() : [!super!]();
      }
      ```
      
      #### Common fixes
      
      Remove the super constructor invocation:
      
      ```dart
      enum E {
        e;
      
        const E();
      }
      ```
  SUPER_IN_EXTENSION:
    problemMessage: "The 'super' keyword can't be used in an extension because an extension doesn't have a superclass."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a member declared inside an
      extension uses the `super` keyword . Extensions aren't classes and don't
      have superclasses, so the `super` keyword serves no purpose.

      #### Example

      The following code produces this diagnostic because `super` can't be used
      in an extension:

      ```dart
      extension E on Object {
        String get displayString => [!super!].toString();
      }
      ```

      #### Common fixes

      Remove the `super` keyword :

      ```dart
      extension E on Object {
        String get displayString => toString();
      }
      ```
  SUPER_IN_INVALID_CONTEXT:
    problemMessage: "Invalid context for 'super' invocation."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the keyword `super` is used
      outside of a instance method.

      #### Example

      The following code produces this diagnostic because `super` is used in a
      top-level function:

      ```dart
      void f() {
        [!super!].f();
      }
      ```

      #### Common fixes

      Rewrite the code to not use `super`.
  SUPER_IN_REDIRECTING_CONSTRUCTOR:
    problemMessage: "The redirecting constructor can't have a 'super' initializer."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor that redirects to
      another constructor also attempts to invoke a constructor from the
      superclass. The superclass constructor will be invoked when the constructor
      that the redirecting constructor is redirected to is invoked.

      #### Example

      The following code produces this diagnostic because the constructor `C.a`
      both redirects to `C.b` and invokes a constructor from the superclass:

      ```dart
      class C {
        C.a() : this.b(), [!super()!];
        C.b();
      }
      ```

      #### Common fixes

      Remove the invocation of the `super` constructor:

      ```dart
      class C {
        C.a() : this.b();
        C.b();
      }
      ```
  SWITCH_CASE_COMPLETES_NORMALLY:
    problemMessage: "The 'case' shouldn't complete normally."
    correctionMessage: "Try adding 'break', 'return', or 'throw'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the statements following a
      `case` label in a `switch` statement could fall through to the next `case`
      or `default` label.

      #### Example

      The following code produces this diagnostic because the `case` label with
       a value of zero (`0`) falls through to the `default` statements:

      ```dart
      void f(int a) {
        switch (a) {
          [!case!] 0:
            print(0);
          default:
            return;
        }
      }
      ```

      #### Common fixes

      Change the flow of control so that the `case` won't fall through. There
      are several ways that this can be done, including adding one of the
      following at the end of the current list of statements:
      - a `return` statement,
      - a `throw` expression,
      - a `break` statement,
      - a `continue`, or
      - an invocation of a function or method whose return type is `Never`.
  SWITCH_EXPRESSION_NOT_ASSIGNABLE:
    problemMessage: "Type '{0}' of the switch expression isn't assignable to the type '{1}' of case expressions."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the static type of the switch expression
      1: the static type of the case expressions
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of the expression in a
      `switch` statement isn't assignable to the type of the expressions in the
      `case` clauses.

      #### Example

      The following code produces this diagnostic because the type of `s`
      (`String`) isn't assignable to the type of `0` (`int`):

      ```dart
      %language=2.9
      void f(String s) {
        switch ([!s!]) {
          case 0:
            break;
        }
      }
      ```

      #### Common fixes

      If the type of the `case` expressions is correct, then change the
      expression in the `switch` statement to have the correct type:

      ```dart
      %language=2.9
      void f(String s) {
        switch (int.parse(s)) {
          case 0:
            break;
        }
      }
      ```

      If the type of the `switch` expression is correct, then change the `case`
      expressions to have the correct type:

      ```dart
      %language=2.9
      void f(String s) {
        switch (s) {
          case '0':
            break;
        }
      }
      ```
  TEAROFF_OF_GENERATIVE_CONSTRUCTOR_OF_ABSTRACT_CLASS:
    problemMessage: "A generative constructor of an abstract class can't be torn off."
    correctionMessage: Try tearing off a constructor of a concrete class, or a non-generative constructor.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a generative constructor from an
      abstract class is being torn off. This isn't allowed because it isn't valid
      to create an instance of an abstract class, which means that there isn't
      any valid use for the torn off constructor.

      #### Example

      The following code produces this diagnostic because the constructor `C.new`
      is being torn off and the class `C` is an abstract class:

      ```dart
      abstract class C {
        C();
      }

      void f() {
        [!C.new!];
      }
      ```

      #### Common fixes

      Tear off the constructor of a concrete class.
  THROW_OF_INVALID_TYPE:
    problemMessage: "The type '{0}' of the thrown expression must be assignable to 'Object'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type that can't be thrown
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of the expression in a
      throw expression isn't assignable to `Object`. It isn't valid to throw
      `null`, so it isn't valid to use an expression that might evaluate to
      `null`.

      #### Example

      The following code produces this diagnostic because `s` might be `null`:

      ```dart
      void f(String? s) {
        throw [!s!];
      }
      ```

      #### Common fixes

      Add an explicit null check to the expression:

      ```dart
      void f(String? s) {
        throw s!;
      }
      ```
  TOP_LEVEL_CYCLE:
    problemMessage: "The type of '{0}' can't be inferred because it depends on itself through the cycle: {1}."
    correctionMessage: Try adding an explicit type to one or more of the variables in the cycle in order to break the cycle.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the element whose type could not be inferred.
      1: The [TopLevelInferenceError]'s arguments that led to the cycle.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a top-level variable has no type
      annotation and the variable's initializer refers to the variable, either
      directly or indirectly.

      #### Example

      The following code produces this diagnostic because the variables `x` and
      `y` are defined in terms of each other, and neither has an explicit type,
      so the type of the other can't be inferred:

      ```dart
      var x = y;
      var y = [!x!];
      ```

      #### Common fixes

      If the two variables don't need to refer to each other, then break the
      cycle:

      ```dart
      var x = 0;
      var y = x;
      ```

      If the two variables need to refer to each other, then give at least one of
      them an explicit type:

      ```dart
      int x = y;
      var y = x;
      ```

      Note, however, that while this code doesn't produce any diagnostics, it
      will produce a stack overflow at runtime unless at least one of the
      variables is assigned a value that doesn't depend on the other variables
      before any of the variables in the cycle are referenced.
  TYPE_ALIAS_CANNOT_REFERENCE_ITSELF:
    problemMessage: "Typedefs can't reference themselves directly or recursively via another typedef."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a typedef refers to itself,
      either directly or indirectly.

      #### Example

      The following code produces this diagnostic because `F` depends on itself
      indirectly through `G`:

      ```dart
      typedef [!F!] = void Function(G);
      typedef G = void Function(F);
      ```

      #### Common fixes

      Change one or more of the typedefs in the cycle so that none of them refer
      to themselves:

      ```dart
      typedef F = void Function(G);
      typedef G = void Function(int);
      ```
  TYPE_ANNOTATION_DEFERRED_CLASS:
    problemMessage: "The deferred type '{0}' can't be used in a declaration, cast, or type test."
    correctionMessage: Try using a different type, or changing the import to not be deferred.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type that is deferred and being used in a type
         annotation
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type annotation is in a
      variable declaration, or the type used in a cast (`as`) or type test (`is`)
      is a type declared in a library that is imported using a deferred import.
      These types are required to be available at compile time, but aren't.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      The following code produces this diagnostic because the type of the
      parameter `f` is imported from a deferred library:

      ```dart
      import 'dart:io' deferred as io;

      void f([!io.File!] f) {}
      ```

      #### Common fixes

      If you need to reference the imported type, then remove the `deferred`
      keyword:

      ```dart
      import 'dart:io' as io;

      void f(io.File f) {}
      ```

      If the import is required to be deferred and there's another type that is
      appropriate, then use that type in place of the type from the deferred
      library.
  TYPE_ARGUMENT_NOT_MATCHING_BOUNDS:
    problemMessage: "'{0}' doesn't conform to the bound '{2}' of the type parameter '{1}'."
    correctionMessage: "Try using a type that is or is a subclass of '{2}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type used in the instance creation that should be
         limited by the bound as specified in the class declaration
      1: the name of the type parameter
      2: the substituted bound of the type parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type argument isn't the same
      as or a subclass of the bounds of the corresponding type parameter.

      #### Example

      The following code produces this diagnostic because `String` isn't a
      subclass of `num`:

      ```dart
      class A<E extends num> {}

      var a = A<[!String!]>();
      ```

      #### Common fixes

      Change the type argument to be a subclass of the bounds:

      ```dart
      class A<E extends num> {}

      var a = A<int>();
      ```
  TYPE_PARAMETER_REFERENCED_BY_STATIC:
    problemMessage: "Static members can't reference type parameters of the class."
    correctionMessage: Try removing the reference to the type parameter, or making the member an instance member.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a static member references a
      type parameter that is declared for the class. Type parameters only have
      meaning for instances of the class.

      #### Example

      The following code produces this diagnostic because the static method
      `hasType` has a reference to the type parameter `T`:

      ```dart
      class C<T> {
        static bool hasType(Object o) => o is [!T!];
      }
      ```

      #### Common fixes

      If the member can be an instance member, then remove the keyword `static`:

      ```dart
      class C<T> {
        bool hasType(Object o) => o is T;
      }
      ```

      If the member must be a static member, then make the member be generic:

      ```dart
      class C<T> {
        static bool hasType<S>(Object o) => o is S;
      }
      ```

      Note, however, that there isn’t a relationship between `T` and `S`, so this
      second option changes the semantics from what was likely to be intended.
  TYPE_PARAMETER_SUPERTYPE_OF_ITS_BOUND:
    problemMessage: "'{0}' can't be a supertype of its upper bound."
    correctionMessage: "Try using a type that is the same as or a subclass of '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type parameter
      1: the name of the bounding type

      See [CompileTimeErrorCode.TYPE_ARGUMENT_NOT_MATCHING_BOUNDS].
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the bound of a type parameter
      (the type following the `extends` keyword) is either directly or indirectly
      the type parameter itself. Stating that the type parameter must be the same
      as itself or a subtype of itself or a subtype of itself isn't helpful
      because it will always be the same as itself.

      #### Examples

      The following code produces this diagnostic because the bound of `T` is
      `T`:

      ```dart
      class C<[!T!] extends T> {}
      ```

      The following code produces this diagnostic because the bound of `T1` is
      `T2`, and the bound of `T2` is `T1`, effectively making the bound of `T1`
      be `T1`:

      ```dart
      class C<[!T1!] extends T2, T2 extends T1> {}
      ```

      #### Common fixes

      If the type parameter needs to be a subclass of some type, then replace the
      bound with the required type:

      ```dart
      class C<T extends num> {}
      ```

      If the type parameter can be any type, then remove the `extends` clause:

      ```dart
      class C<T> {}
      ```
  TYPE_TEST_WITH_NON_TYPE:
    problemMessage: "The name '{0}' isn't a type and can't be used in an 'is' expression."
    correctionMessage: Try correcting the name to match an existing type.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the right-hand side of an `is`
      or `is!` test isn't a type.

      #### Example

      The following code produces this diagnostic because the right-hand side is
      a parameter, not a type:

      ```dart
      typedef B = int Function(int);

      void f(Object a, B b) {
        if (a is [!b!]) {
          return;
        }
      }
      ```

      #### Common fixes

      If you intended to use a type test, then replace the right-hand side with a
      type:

      ```dart
      typedef B = int Function(int);

      void f(Object a, B b) {
        if (a is B) {
          return;
        }
      }
      ```

      If you intended to use a different kind of test, then change the test:

      ```dart
      typedef B = int Function(int);

      void f(Object a, B b) {
        if (a == b) {
          return;
        }
      }
      ```
  TYPE_TEST_WITH_UNDEFINED_NAME:
    problemMessage: "The name '{0}' isn't defined, so it can't be used in an 'is' expression."
    correctionMessage: "Try changing the name to the name of an existing type, or creating a type with the name '{0}'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name following the `is` in a
      type test expression isn't defined.

      #### Example

      The following code produces this diagnostic because the name `Srting` isn't
      defined:

      ```dart
      void f(Object o) {
        if (o is [!Srting!]) {
          // ...
        }
      }
      ```

      #### Common fixes

      Replace the name with the name of a type:

      ```dart
      void f(Object o) {
        if (o is String) {
          // ...
        }
      }
      ```
  UNCHECKED_USE_OF_NULLABLE_VALUE_IN_SPREAD:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "A nullable expression can't be used in a spread."
    correctionMessage: "Try checking that the value isn't 'null' before using it in a spread, or use a null-aware spread."
    hasPublishedDocs: true
  UNCHECKED_INVOCATION_OF_NULLABLE_VALUE:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "The function can't be unconditionally invoked because it can be 'null'."
    correctionMessage: "Try adding a null check ('!')."
    hasPublishedDocs: true
  UNCHECKED_METHOD_INVOCATION_OF_NULLABLE_VALUE:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "The method '{0}' can't be unconditionally invoked because the receiver can be 'null'."
    correctionMessage: "Try making the call conditional (using '?.') or adding a null check to the target ('!')."
    hasPublishedDocs: true
  UNCHECKED_OPERATOR_INVOCATION_OF_NULLABLE_VALUE:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "The operator '{0}' can't be unconditionally invoked because the receiver can be 'null'."
    correctionMessage: "Try adding a null check to the target ('!')."
    hasPublishedDocs: true
  UNCHECKED_USE_OF_NULLABLE_VALUE_IN_YIELD_EACH:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "A nullable expression can't be used in a yield-each statement."
    correctionMessage: "Try checking that the value isn't 'null' before using it in a yield-each statement."
    hasPublishedDocs: true
  UNCHECKED_USE_OF_NULLABLE_VALUE_AS_CONDITION:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "A nullable expression can't be used as a condition."
    correctionMessage: "Try checking that the value isn't 'null' before using it as a condition."
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an expression whose type is
      [potentially non-nullable][] is dereferenced without first verifying that
      the value isn't `null`.

      #### Example

      The following code produces this diagnostic because `s` can be `null` at
      the point where it's referenced:

      ```dart
      void f(String? s) {
        if (s.[!length!] > 3) {
          // ...
        }
      }
      ```

      #### Common fixes

      If the value really can be `null`, then add a test to ensure that members
      are only accessed when the value isn't `null`:

      ```dart
      void f(String? s) {
        if (s != null && s.length > 3) {
          // ...
        }
      }
      ```

      If the expression is a variable and the value should never be `null`, then
      change the type of the variable to be non-nullable:

      ```dart
      void f(String s) {
        if (s.length > 3) {
          // ...
        }
      }
      ```

      If you believe that the value of the expression should never be `null`, but
      you can't change the type of the variable, and you're willing to risk
      having an exception thrown at runtime if you're wrong, then you can assert
      that the value isn't null:

      ```dart
      void f(String? s) {
        if (s!.length > 3) {
          // ...
        }
      }
      ```
  UNCHECKED_USE_OF_NULLABLE_VALUE_AS_ITERATOR:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "A nullable expression can't be used as an iterator in a for-in loop."
    correctionMessage: "Try checking that the value isn't 'null' before using it as an iterator."
    hasPublishedDocs: true
  UNCHECKED_PROPERTY_ACCESS_OF_NULLABLE_VALUE:
    sharedName: UNCHECKED_USE_OF_NULLABLE_VALUE
    problemMessage: "The property '{0}' can't be unconditionally accessed because the receiver can be 'null'."
    correctionMessage: "Try making the access conditional (using '?.') or adding a null check to the target ('!')."
    hasPublishedDocs: true
  UNDEFINED_ANNOTATION:
    problemMessage: "Undefined name '{0}' used as an annotation."
    correctionMessage: Try defining the name or importing it from another library.
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name that isn't defined is
      used as an annotation.

      #### Example

      The following code produces this diagnostic because the name `undefined`
      isn't defined:

      ```dart
      [!@undefined!]
      void f() {}
      ```

      #### Common fixes

      If the name is correct, but it isn’t declared yet, then declare the name as
      a constant value:

      ```dart
      const undefined = 'undefined';

      @undefined
      void f() {}
      ```

      If the name is wrong, replace the name with the name of a valid constant:

      ```dart
      @deprecated
      void f() {}
      ```

      Otherwise, remove the annotation.
  UNDEFINED_CLASS:
    problemMessage: "Undefined class '{0}'."
    correctionMessage: "Try changing the name to the name of an existing class, or creating a class with the name '{0}'."
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the undefined class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of a class but either isn't defined or isn't visible
      in the scope in which it's being referenced.

      #### Example

      The following code produces this diagnostic because `Piont` isn't defined:

      ```dart
      class Point {}

      void f([!Piont!] p) {}
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      the name of a class that is defined. The example above can be corrected by
      fixing the spelling of the class:

      ```dart
      class Point {}

      void f(Point p) {}
      ```

      If the class is defined but isn't visible, then you probably need to add an
      import.
  UNDEFINED_CLASS_BOOLEAN:
    sharedName: UNDEFINED_CLASS
    problemMessage: "Undefined class '{0}'."
    correctionMessage: "Try using the type 'bool'."
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Same as [CompileTimeErrorCode.UNDEFINED_CLASS], but to catch using
      "boolean" instead of "bool" in order to improve the correction message.

      Parameters:
      0: the name of the undefined class
  UNDEFINED_CONSTRUCTOR_IN_INITIALIZER:
    problemMessage: "The class '{0}' doesn't have a constructor named '{1}'."
    correctionMessage: "Try defining a constructor named '{1}' in '{0}', or invoking a different constructor."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the superclass that does not define the invoked constructor
      1: the name of the constructor being invoked
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a superclass constructor is
      invoked in the initializer list of a constructor, but the superclass
      doesn't define the constructor being invoked.

      #### Examples

      The following code produces this diagnostic because `A` doesn't have an
      unnamed constructor:

      ```dart
      class A {
        A.n();
      }
      class B extends A {
        B() : [!super()!];
      }
      ```

      The following code produces this diagnostic because `A` doesn't have a
      constructor named `m`:

      ```dart
      class A {
        A.n();
      }
      class B extends A {
        B() : [!super.m()!];
      }
      ```

      #### Common fixes

      If the superclass defines a constructor that should be invoked, then change
      the constructor being invoked:

      ```dart
      class A {
        A.n();
      }
      class B extends A {
        B() : super.n();
      }
      ```

      If the superclass doesn't define an appropriate constructor, then define
      the constructor being invoked:

      ```dart
      class A {
        A.m();
        A.n();
      }
      class B extends A {
        B() : super.m();
      }
      ```
  UNDEFINED_CONSTRUCTOR_IN_INITIALIZER_DEFAULT:
    sharedName: UNDEFINED_CONSTRUCTOR_IN_INITIALIZER
    problemMessage: "The class '{0}' doesn't have an unnamed constructor."
    correctionMessage: "Try defining an unnamed constructor in '{0}', or invoking a different constructor."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the superclass that does not define the invoked constructor
  UNDEFINED_ENUM_CONSTANT:
    problemMessage: "There's no constant named '{0}' in '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing constant, or defining a constant named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the enum constant that is not defined
      1: the name of the enum used to access the constant
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of an enum constant, and the name either isn't
      defined or isn't visible in the scope in which it's being referenced.

      #### Example

      The following code produces this diagnostic because `E` doesn't define a
      constant named `c`:

      ```dart
      enum E {a, b}

      var e = E.[!c!];
      ```

      #### Common fixes

      If the constant should be defined, then add it to the declaration of the
      enum:

      ```dart
      enum E {a, b, c}

      var e = E.c;
      ```

      If the constant shouldn't be defined, then change the name to the name of
      an existing constant:

      ```dart
      enum E {a, b}

      var e = E.b;
      ```
  UNDEFINED_ENUM_CONSTRUCTOR_NAMED:
    sharedName: UNDEFINED_ENUM_CONSTRUCTOR
    problemMessage: The enum doesn't have a constructor named '{0}'.
    correctionMessage: Try correcting the name to the name of an existing constructor, or defining constructor with the name '{0}'.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constructor that is undefined
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when the constructor invoked to
      initialize an enum constant doesn't exist.
      
      #### Examples
      
      The following code produces this diagnostic because the enum constant `c`
      is being initialized by the unnamed constructor, but there's no unnamed
      constructor defined in `E`:
      
      ```dart
      enum E {
        [!c!]();
      
        const E.x();
      }
      ```
      
      The following code produces this diagnostic because the enum constant `c`
      is being initialized by the constructor named `x`, but there's no
      constructor named `x` defined in `E`:
      
      ```dart
      enum E {
        c.[!x!]();
      
        const E.y();
      }
      ```
      
      #### Common fixes
      
      If the enum constant is being initialized by the unnamed constructor and
      one of the named constructors should have been used, then add the name of
      the constructor:
      
      ```dart
      enum E {
        c.x();
      
        const E.x();
      }
      ```
      
      If the enum constant is being initialized by the unnamed constructor and
      none of the named constructors are appropriate, then define the unnamed
      constructor:
      
      ```dart
      enum E {
        c();
      
        const E();
      }
      ```
      
      If the enum constant is being initialized by a named constructor and one
      of the existing constructors should have been used, then change the name
      of the constructor being invoked (or remove it if the unnamed constructor
      should be used):
      
      ```dart
      enum E {
        c.y();
      
        const E();
        const E.y();
      }
      ```
      
      If the enum constant is being initialized by a named constructor and none
      of the existing constructors should have been used, then define a
      constructor with the name that was used:
      
      ```dart
      enum E {
        c.x();
      
        const E.x();
      }
      ```
  UNDEFINED_ENUM_CONSTRUCTOR_UNNAMED:
    sharedName: UNDEFINED_ENUM_CONSTRUCTOR
    problemMessage: The enum doesn't have an unnamed constructor.
    correctionMessage: Try adding the name of an existing constructor, or defining an unnamed constructor.
    hasPublishedDocs: true
  UNDEFINED_EXTENSION_GETTER:
    problemMessage: "The getter '{0}' isn't defined for the extension '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing getter, or defining a getter named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the getter that is undefined
      1: the name of the extension that was explicitly specified
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is used to
      invoke a getter, but the getter isn't defined by the specified extension.
      The analyzer also produces this diagnostic when a static getter is
      referenced but isn't defined by the specified extension.

      #### Examples

      The following code produces this diagnostic because the extension `E`
      doesn't declare an instance getter named `b`:

      ```dart
      extension E on String {
        String get a => 'a';
      }

      extension F on String {
        String get b => 'b';
      }

      void f() {
        E('c').[!b!];
      }
      ```

      The following code produces this diagnostic because the extension `E`
      doesn't declare a static getter named `a`:

      ```dart
      extension E on String {}

      var x = E.[!a!];
      ```

      #### Common fixes

      If the name of the getter is incorrect, then change it to the name of an
      existing getter:

      ```dart
      extension E on String {
        String get a => 'a';
      }

      extension F on String {
        String get b => 'b';
      }

      void f() {
        E('c').a;
      }
      ```

      If the name of the getter is correct but the name of the extension is
      wrong, then change the name of the extension to the correct name:

      ```dart
      extension E on String {
        String get a => 'a';
      }

      extension F on String {
        String get b => 'b';
      }

      void f() {
        F('c').b;
      }
      ```

      If the name of the getter and extension are both correct, but the getter
      isn't defined, then define the getter:

      ```dart
      extension E on String {
        String get a => 'a';
        String get b => 'z';
      }

      extension F on String {
        String get b => 'b';
      }

      void f() {
        E('c').b;
      }
      ```
  UNDEFINED_EXTENSION_METHOD:
    problemMessage: "The method '{0}' isn't defined for the extension '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing method, or defining a method named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method that is undefined
      1: the name of the extension that was explicitly specified
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is used to
      invoke a method, but the method isn't defined by the specified extension.
      The analyzer also produces this diagnostic when a static method is
      referenced but isn't defined by the specified extension.

      #### Examples

      The following code produces this diagnostic because the extension `E`
      doesn't declare an instance method named `b`:

      ```dart
      extension E on String {
        String a() => 'a';
      }

      extension F on String {
        String b() => 'b';
      }

      void f() {
        E('c').[!b!]();
      }
      ```

      The following code produces this diagnostic because the extension `E`
      doesn't declare a static method named `a`:

      ```dart
      extension E on String {}

      var x = E.[!a!]();
      ```

      #### Common fixes

      If the name of the method is incorrect, then change it to the name of an
      existing method:

      ```dart
      extension E on String {
        String a() => 'a';
      }

      extension F on String {
        String b() => 'b';
      }

      void f() {
        E('c').a();
      }
      ```

      If the name of the method is correct, but the name of the extension is
      wrong, then change the name of the extension to the correct name:

      ```dart
      extension E on String {
        String a() => 'a';
      }

      extension F on String {
        String b() => 'b';
      }

      void f() {
        F('c').b();
      }
      ```

      If the name of the method and extension are both correct, but the method
      isn't defined, then define the method:

      ```dart
      extension E on String {
        String a() => 'a';
        String b() => 'z';
      }

      extension F on String {
        String b() => 'b';
      }

      void f() {
        E('c').b();
      }
      ```
  UNDEFINED_EXTENSION_OPERATOR:
    problemMessage: "The operator '{0}' isn't defined for the extension '{1}'."
    correctionMessage: "Try defining the operator '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the operator that is undefined
      1: the name of the extension that was explicitly specified
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an operator is invoked on a
      specific extension when that extension doesn't implement the operator.

      #### Example

      The following code produces this diagnostic because the extension `E`
      doesn't define the operator `*`:

      ```dart
      var x = E('') [!*!] 4;

      extension E on String {}
      ```

      #### Common fixes

      If the extension is expected to implement the operator, then add an
      implementation of the operator to the extension:

      ```dart
      var x = E('') * 4;

      extension E on String {
        int operator *(int multiplier) => length * multiplier;
      }
      ```

      If the operator is defined by a different extension, then change the name
      of the extension to the name of the one that defines the operator.

      If the operator is defined on the argument of the extension override, then
      remove the extension override:

      ```dart
      var x = '' * 4;

      extension E on String {}
      ```
  UNDEFINED_EXTENSION_SETTER:
    problemMessage: "The setter '{0}' isn't defined for the extension '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing setter, or defining a setter named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the setter that is undefined
      1: the name of the extension that was explicitly specified
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension override is used to
      invoke a setter, but the setter isn't defined by the specified extension.
      The analyzer also produces this diagnostic when a static setter is
      referenced but isn't defined by the specified extension.

      #### Examples

      The following code produces this diagnostic because the extension `E`
      doesn't declare an instance setter named `b`:

      ```dart
      extension E on String {
        set a(String v) {}
      }

      extension F on String {
        set b(String v) {}
      }

      void f() {
        E('c').[!b!] = 'd';
      }
      ```

      The following code produces this diagnostic because the extension `E`
      doesn't declare a static setter named `a`:

      ```dart
      extension E on String {}

      void f() {
        E.[!a!] = 3;
      }
      ```

      #### Common fixes

      If the name of the setter is incorrect, then change it to the name of an
      existing setter:

      ```dart
      extension E on String {
        set a(String v) {}
      }

      extension F on String {
        set b(String v) {}
      }

      void f() {
        E('c').a = 'd';
      }
      ```

      If the name of the setter is correct, but the name of the extension is
      wrong, then change the name of the extension to the correct name:

      ```dart
      extension E on String {
        set a(String v) {}
      }

      extension F on String {
        set b(String v) {}
      }

      void f() {
        F('c').b = 'd';
      }
      ```

      If the name of the setter and extension are both correct, but the setter
      isn't defined, then define the setter:

      ```dart
      extension E on String {
        set a(String v) {}
        set b(String v) {}
      }

      extension F on String {
        set b(String v) {}
      }

      void f() {
        E('c').b = 'd';
      }
      ```
  UNDEFINED_FUNCTION:
    problemMessage: "The function '{0}' isn't defined."
    correctionMessage: "Try importing the library that defines '{0}', correcting the name to the name of an existing function, or defining a function named '{0}'."
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method that is undefined
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of a function but either isn't defined or isn't
      visible in the scope in which it's being referenced.

      #### Example

      The following code produces this diagnostic because the name `emty` isn't
      defined:

      ```dart
      List<int> empty() => [];

      void main() {
        print([!emty!]());
      }
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      the name of a function that is defined. The example above can be corrected
      by fixing the spelling of the function:

      ```dart
      List<int> empty() => [];

      void main() {
        print(empty());
      }
      ```

      If the function is defined but isn't visible, then you probably need to add
      an import or re-arrange your code to make the function visible.
  UNDEFINED_GETTER:
    problemMessage: "The getter '{0}' isn't defined for the type '{1}'."
    correctionMessage: "Try importing the library that defines '{0}', correcting the name to the name of an existing getter, or defining a getter or field named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the getter
      1: the name of the enclosing type where the getter is being looked for
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of a getter but either isn't defined or isn't
      visible in the scope in which it's being referenced.

      #### Example

      The following code produces this diagnostic because `String` has no member
      named `len`:

      ```dart
      int f(String s) => s.[!len!];
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      the name of a getter that is defined. The example above can be corrected by
      fixing the spelling of the getter:

      ```dart
      int f(String s) => s.length;
      ```
  UNDEFINED_GETTER_ON_FUNCTION_TYPE:
    sharedName: UNDEFINED_GETTER
    problemMessage: "The getter '{0}' isn't defined for the '{1}' function type."
    correctionMessage: "Try wrapping the function type alias in parentheses in order to access '{0}' as an extension getter on 'Type'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the getter
      1: the name of the function type alias
  UNDEFINED_IDENTIFIER:
    problemMessage: "Undefined name '{0}'."
    correctionMessage: Try correcting the name to one that is defined, or defining the name.
    isUnresolvedIdentifier: true
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the identifier
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      either isn't defined or isn't visible in the scope in which it's being
      referenced.

      #### Example

      The following code produces this diagnostic because the name `rihgt` isn't
      defined:

      ```dart
      int min(int left, int right) => left <= [!rihgt!] ? left : right;
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      an identifier that is defined. The example above can be corrected by
      fixing the spelling of the variable:

      ```dart
      int min(int left, int right) => left <= right ? left : right;
      ```

      If the identifier is defined but isn't visible, then you probably need to
      add an import or re-arrange your code to make the identifier visible.
  UNDEFINED_IDENTIFIER_AWAIT:
    problemMessage: "Undefined name 'await' in function body not marked with 'async'."
    correctionMessage: "Try correcting the name to one that is defined, defining the name, or adding 'async' to the enclosing function body."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the name `await` is used in a
      method or function body without being declared, and the body isn't marked
      with the `async` keyword. The name `await` only introduces an await
      expression in an asynchronous function.

      #### Example

      The following code produces this diagnostic because the name `await` is
      used in the body of `f` even though the body of `f` isn't marked with the
      `async` keyword:

      ```dart
      void f(p) { [!await!] p; }
      ```

      #### Common fixes

      Add the keyword `async` to the function body:

      ```dart
      void f(p) async { await p; }
      ```
  UNDEFINED_METHOD:
    problemMessage: "The method '{0}' isn't defined for the type '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing method, or defining a method named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method that is undefined
      1: the resolved type name that the method lookup is happening on
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of a method but either isn't defined or isn't
      visible in the scope in which it's being referenced.

      #### Example

      The following code produces this diagnostic because the identifier
      `removeMiddle` isn't defined:

      ```dart
      int f(List<int> l) => l.[!removeMiddle!]();
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      the name of a method that is defined. The example above can be corrected by
      fixing the spelling of the method:

      ```dart
      int f(List<int> l) => l.removeLast();
      ```
  UNDEFINED_METHOD_ON_FUNCTION_TYPE:
    sharedName: UNDEFINED_METHOD
    problemMessage: "The method '{0}' isn't defined for the '{1}' function type."
    correctionMessage: "Try wrapping the function type alias in parentheses in order to access '{0}' as an extension method on 'Type'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method
      1: the name of the function type alias
  UNDEFINED_NAMED_PARAMETER:
    problemMessage: "The named parameter '{0}' isn't defined."
    correctionMessage: "Try correcting the name to an existing named parameter's name, or defining a named parameter with the name '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the requested named parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function invocation
      has a named argument, but the method or function being invoked doesn't
      define a parameter with the same name.

      #### Example

      The following code produces this diagnostic because `m` doesn't declare a
      named parameter named `a`:

      ```dart
      %language=2.9
      class C {
        m({int b}) {}
      }

      void f(C c) {
        c.m([!a!]: 1);
      }
      ```

      #### Common fixes

      If the argument name is mistyped, then replace it with the correct name.
      The example above can be fixed by changing `a` to `b`:

      ```dart
      %language=2.9
      class C {
        m({int b}) {}
      }

      void f(C c) {
        c.m(b: 1);
      }
      ```

      If a subclass adds a parameter with the name in question, then cast the
      receiver to the subclass:

      ```dart
      %language=2.9
      class C {
        m({int b}) {}
      }

      class D extends C {
        m({int a, int b}) {}
      }

      void f(C c) {
        (c as D).m(a: 1);
      }
      ```

      If the parameter should be added to the function, then add it:

      ```dart
      %language=2.9
      class C {
        m({int a, int b}) {}
      }

      void f(C c) {
        c.m(a: 1);
      }
      ```
  UNDEFINED_OPERATOR:
    problemMessage: "The operator '{0}' isn't defined for the type '{1}'."
    correctionMessage: "Try defining the operator '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the operator
      1: the name of the enclosing type where the operator is being looked for
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a user-definable operator is
      invoked on an object for which the operator isn't defined.

      #### Example

      The following code produces this diagnostic because the class `C` doesn't
      define the operator `+`:

      ```dart
      class C {}

      C f(C c) => c [!+!] 2;
      ```

      #### Common fixes

      If the operator should be defined for the class, then define it:

      ```dart
      class C {
        C operator +(int i) => this;
      }

      C f(C c) => c + 2;
      ```
  UNDEFINED_PREFIXED_NAME:
    problemMessage: "The name '{0}' is being referenced through the prefix '{1}', but it isn't defined in any of the libraries imported using that prefix."
    correctionMessage: "Try correcting the prefix or importing the library that defines '{0}'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a prefixed identifier is found
      where the prefix is valid, but the identifier isn't declared in any of the
      libraries imported using that prefix.

      #### Example

      The following code produces this diagnostic because `dart:core` doesn't
      define anything named `a`:

      ```dart
      import 'dart:core' as p;

      void f() {
        p.[!a!];
      }
      ```

      #### Common fixes

      If the library in which the name is declared isn't imported yet, add an
      import for the library.

      If the name is wrong, then change it to one of the names that's declared in
      the imported libraries.
  UNDEFINED_SETTER:
    problemMessage: "The setter '{0}' isn't defined for the type '{1}'."
    correctionMessage: "Try importing the library that defines '{0}', correcting the name to the name of an existing setter, or defining a setter or field named '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the setter
      1: the name of the enclosing type where the setter is being looked for
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters an identifier that
      appears to be the name of a setter but either isn't defined or isn't
      visible in the scope in which the identifier is being referenced.

      #### Example

      The following code produces this diagnostic because there isn't a setter
      named `z`:

      ```dart
      class C {
        int x = 0;
        void m(int y) {
          this.[!z!] = y;
        }
      }
      ```

      #### Common fixes

      If the identifier isn't defined, then either define it or replace it with
      the name of a setter that is defined. The example above can be corrected by
      fixing the spelling of the setter:

      ```dart
      class C {
        int x = 0;
        void m(int y) {
          this.x = y;
        }
      }
      ```
  UNDEFINED_SETTER_ON_FUNCTION_TYPE:
    sharedName: UNDEFINED_SETTER
    problemMessage: "The setter '{0}' isn't defined for the '{1}' function type."
    correctionMessage: "Try wrapping the function type alias in parentheses in order to access '{0}' as an extension getter on 'Type'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the setter
      1: the name of the function type alias
  UNDEFINED_SUPER_GETTER:
    sharedName: UNDEFINED_SUPER_MEMBER
    problemMessage: "The getter '{0}' isn't defined in a superclass of '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing getter, or defining a getter or field named '{0}' in a superclass."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the getter
      1: the name of the enclosing type where the getter is being looked for
  UNDEFINED_SUPER_METHOD:
    sharedName: UNDEFINED_SUPER_MEMBER
    previousName: UNDEFINED_SUPER_METHOD
    problemMessage: "The method '{0}' isn't defined in a superclass of '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing method, or defining a method named '{0}' in a superclass."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method that is undefined
      1: the resolved type name that the method lookup is happening on
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an inherited member (method,
      getter, setter, or operator) is referenced using `super`, but there’s no
      member with that name in the superclass chain.

      #### Examples

      The following code produces this diagnostic because `Object` doesn't define
      a method named `n`:

      ```dart
      class C {
        void m() {
          super.[!n!]();
        }
      }
      ```

      The following code produces this diagnostic because `Object` doesn't define
      a getter named `g`:

      ```dart
      class C {
        void m() {
          super.[!g!];
        }
      }
      ```

      #### Common fixes

      If the inherited member you intend to invoke has a different name, then
      make the name of the invoked member match the inherited member.

      If the member you intend to invoke is defined in the same class, then
      remove the `super.`.

      If the member isn’t defined, then either add the member to one of the
      superclasses or remove the invocation.
  UNDEFINED_SUPER_OPERATOR:
    sharedName: UNDEFINED_SUPER_MEMBER
    problemMessage: "The operator '{0}' isn't defined in a superclass of '{1}'."
    correctionMessage: "Try defining the operator '{0}' in a superclass."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the operator
      1: the name of the enclosing type where the operator is being looked for
  UNDEFINED_SUPER_SETTER:
    sharedName: UNDEFINED_SUPER_MEMBER
    problemMessage: "The setter '{0}' isn't defined in a superclass of '{1}'."
    correctionMessage: "Try correcting the name to the name of an existing setter, or defining a setter or field named '{0}' in a superclass."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the setter
      1: the name of the enclosing type where the setter is being looked for
  UNQUALIFIED_REFERENCE_TO_NON_LOCAL_STATIC_MEMBER:
    problemMessage: Static members from supertypes must be qualified by the name of the defining type.
    correctionMessage: "Try adding '{0}.' before the name."
    hasPublishedDocs: true
    comment: |-
      This is a specialization of [INSTANCE_ACCESS_TO_STATIC_MEMBER] that is used
      when we are able to find the name defined in a supertype. It exists to
      provide a more informative error message.

      Parameters:
      0: the name of the defining type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when code in one class references a
      static member in a superclass without prefixing the member's name with the
      name of the superclass. Static members can only be referenced without a
      prefix in the class in which they're declared.

      #### Example

      The following code produces this diagnostic because the static field `x` is
      referenced in the getter `g` without prefixing it with the name of the
      defining class:

      ```dart
      class A {
        static int x = 3;
      }

      class B extends A {
        int get g => [!x!];
      }
      ```

      #### Common fixes

      Prefix the name of the static member with the name of the declaring class:

      ```dart
      class A {
        static int x = 3;
      }

      class B extends A {
        int get g => A.x;
      }
      ```
  UNQUALIFIED_REFERENCE_TO_STATIC_MEMBER_OF_EXTENDED_TYPE:
    problemMessage: Static members from the extended type or one of its superclasses must be qualified by the name of the defining type.
    correctionMessage: "Try adding '{0}.' before the name."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the defining type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an undefined name is found, and
      the name is the same as a static member of the extended type or one of its
      superclasses.

      #### Example

      The following code produces this diagnostic because `m` is a static member
      of the extended type `C`:

      ```dart
      class C {
        static void m() {}
      }

      extension E on C {
        void f() {
          [!m!]();
        }
      }
      ```

      #### Common fixes

      If you're trying to reference a static member that's declared outside the
      extension, then add the name of the class or extension before the reference
      to the member:

      ```dart
      class C {
        static void m() {}
      }

      extension E on C {
        void f() {
          C.m();
        }
      }
      ```

      If you're referencing a member that isn't declared yet, add a declaration:

      ```dart
      class C {
        static void m() {}
      }

      extension E on C {
        void f() {
          m();
        }

        void m() {}
      }
      ```
  URI_DOES_NOT_EXIST:
    problemMessage: "Target of URI doesn't exist: '{0}'."
    correctionMessage: Try creating the file referenced by the URI, or Try using a URI for a file that does exist.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the URI pointing to a non-existent file
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import, export, or part
      directive is found where the URI refers to a file that doesn't exist.

      #### Example

      If the file `lib.dart` doesn't exist, the following code produces this
      diagnostic:

      ```dart
      import [!'lib.dart'!];
      ```

      #### Common fixes

      If the URI was mistyped or invalid, then correct the URI.

      If the URI is correct, then create the file.
  URI_HAS_NOT_BEEN_GENERATED:
    problemMessage: "Target of URI hasn't been generated: '{0}'."
    correctionMessage: Try running the generator that will generate the file referenced by the URI.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the URI pointing to a non-existent file
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import, export, or part
      directive is found where the URI refers to a file that doesn't exist and
      the name of the file ends with a pattern that's commonly produced by code
      generators, such as one of the following:
      - `.g.dart`
      - `.pb.dart`
      - `.pbenum.dart`
      - `.pbserver.dart`
      - `.pbjson.dart`
      - `.template.dart`

      #### Example

      If the file `lib.g.dart` doesn't exist, the following code produces this
      diagnostic:

      ```dart
      import [!'lib.g.dart'!];
      ```

      #### Common fixes

      If the file is a generated file, then run the generator that generates the
      file.

      If the file isn't a generated file, then check the spelling of the URI or
      create the file.
  URI_WITH_INTERPOLATION:
    problemMessage: "URIs can't use string interpolation."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the string literal in an
      `import`, `export`, or `part` directive contains an interpolation. The
      resolution of the URIs in directives must happen before the declarations
      are compiled, so expressions can’t be  evaluated  while determining the
      values of the URIs.

      #### Example

      The following code produces this diagnostic because the string in the
      `import` directive contains an interpolation:

      ```dart
      import [!'dart:$m'!];

      const m = 'math';
      ```

      #### Common fixes

      Remove the interpolation from the URI:

      ```dart
      import 'dart:math';

      var zero = min(0, 0);
      ```
  USE_OF_NATIVE_EXTENSION:
    problemMessage: Dart native extensions are deprecated and aren’t available in Dart 2.15.
    correctionMessage: "Try using dart:ffi for C interop."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library is imported using the
      `dart-ext` scheme.

      #### Example

      The following code produces this diagnostic because the native library `x`
      is being imported using a scheme of `dart-ext`:

      ```dart
      import [!'dart-ext:x'!];
      ```

      #### Common fixes

      Rewrite the code to use `dart:ffi` as a way of invoking the contents of the
      native library.
  USE_OF_VOID_RESULT:
    problemMessage: "This expression has a type of 'void' so its value can't be used."
    correctionMessage: "Try checking to see if you're using the correct API; there might be a function or call that returns void you didn't expect. Also check type parameters and variables which might also be void."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an expression whose
      type is `void`, and the expression is used in a place where a value is
      expected, such as before a member access or on the right-hand side of an
      assignment.

      #### Example

      The following code produces this diagnostic because `f` doesn't produce an
      object on which `toString` can be invoked:

      ```dart
      void f() {}

      void g() {
        [!f()!].toString();
      }
      ```

      #### Common fixes

      Either rewrite the code so that the expression has a value or rewrite the
      code so that it doesn't depend on the value.
  VALUES_DECLARATION_IN_ENUM:
    problemMessage: A member named 'values' can't be declared in an enum.
    correctionMessage: Try using a different name.
    hasPublishedDocs: true
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an enum declaration defines a
      member named `values`, whether the member is an enum constant, an instance
      member, or a static member.
      
      Any such member conflicts with the implicit declaration of the static
      getter named `values` that returns a list containing all the enum
      constants.
      
      #### Example
      
      The following code produces this diagnostic because the enum `E` defines
      an instance member named `values`:
      
      ```dart
      enum E {
        v;
        void [!values!]() {}
      }
      ```
      
      #### Common fixes
      
      Change the name of the conflicting member:
      
      ```dart
      enum E {
        v;
        void getValues() {}
      }
      ```
  VARIABLE_TYPE_MISMATCH:
    problemMessage: "A value of type '{0}' can't be assigned to a const variable of type '{1}'."
    correctionMessage: "Try using a subtype, or removing the 'const' keyword"
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the object being assigned.
      1: the type of the variable being assigned to
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the evaluation of a constant
      expression would result in a `CastException`.

      #### Example

      The following code produces this diagnostic because the value of `x` is an
      `int`, which can't be assigned to `y` because an `int` isn't a `String`:

      ```dart
      %language=2.9
      const Object x = 0;
      const String y = [!x!];
      ```

      #### Common fixes

      If the declaration of the constant is correct, then change the value being
      assigned to be of the correct type:

      ```dart
      %language=2.9
      const Object x = 0;
      const String y = '$x';
      ```

      If the assigned value is correct, then change the declaration to have the
      correct type:

      ```dart
      %language=2.9
      const Object x = 0;
      const int y = x;
      ```
  WRONG_EXPLICIT_TYPE_PARAMETER_VARIANCE_IN_SUPERINTERFACE:
    problemMessage: "'{0}' is an '{1}' type parameter and can't be used in an '{2}' position in '{3}'."
    correctionMessage: "Try using 'in' type parameters in 'in' positions and 'out' type parameters in 'out' positions in the superinterface."
    comment: |-
      Let `C` be a generic class that declares a formal type parameter `X`, and
      assume that `T` is a direct superinterface of `C`.

      It is a compile-time error if `X` is explicitly defined as a covariant or
      'in' type parameter and `X` occurs in a non-covariant position in `T`.
      It is a compile-time error if `X` is explicitly defined as a contravariant
      or 'out' type parameter and `X` occurs in a non-contravariant position in
      `T`.

      Parameters:
      0: the name of the type parameter
      1: the variance modifier defined for {0}
      2: the variance position of the type parameter {0} in the
         superinterface {3}
      3: the name of the superinterface
  WRONG_NUMBER_OF_PARAMETERS_FOR_OPERATOR:
    problemMessage: "Operator '{0}' should declare exactly {1} parameters, but {2} found."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the declared operator
      1: the number of parameters expected
      2: the number of parameters found in the operator declaration
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a declaration of an operator has
      the wrong number of parameters.

      #### Example

      The following code produces this diagnostic because the operator `+` must
      have a single parameter corresponding to the right operand:

      ```dart
      class C {
        int operator [!+!](a, b) => 0;
      }
      ```

      #### Common fixes

      Add or remove parameters to match the required number:

      ```dart
      class C {
        int operator +(a) => 0;
      }
      ```
      TODO(brianwilkerson) It would be good to add a link to the spec or some
       other documentation that lists the number of parameters for each operator,
       but I don't know what to link to.
  WRONG_NUMBER_OF_PARAMETERS_FOR_OPERATOR_MINUS:
    sharedName: WRONG_NUMBER_OF_PARAMETERS_FOR_OPERATOR
    problemMessage: "Operator '-' should declare 0 or 1 parameter, but {0} found."
    hasPublishedDocs: true
    comment: |-
      7.1.1 Operators: It is a compile time error if the arity of the
      user-declared operator - is not 0 or 1.

      Parameters:
      0: the number of parameters found in the operator declaration
  WRONG_NUMBER_OF_PARAMETERS_FOR_SETTER:
    problemMessage: Setters must declare exactly one required positional parameter.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a setter is found that doesn't
      declare exactly one required positional parameter.

      #### Examples

      The following code produces this diagnostic because the setter `s` declares
      two required parameters:

      ```dart
      %language=2.9
      class C {
        set [!s!](int x, int y) {}
      }
      ```

      The following code produces this diagnostic because the setter `s` declares
      one optional parameter:

      ```dart
      %language=2.9
      class C {
        set [!s!]([int x]) {}
      }
      ```

      #### Common fixes

      Change the declaration so that there's exactly one required positional
      parameter:

      ```dart
      %language=2.9
      class C {
        set s(int x) {}
      }
      ```
  WRONG_NUMBER_OF_TYPE_ARGUMENTS:
    problemMessage: "The type '{0}' is declared with {1} type parameters, but {2} type arguments were given."
    correctionMessage: Try adjusting the number of type arguments to match the number of type parameters.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type being referenced (<i>G</i>)
      1: the number of type parameters that were declared
      2: the number of type arguments provided
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a type that has type parameters
      is used and type arguments are provided, but the number of type arguments
      isn't the same as the number of type parameters.

      The analyzer also produces this diagnostic when a constructor is invoked
      and the number of type arguments doesn't match the number of type
      parameters declared for the class.

      #### Examples

      The following code produces this diagnostic because `C` has one type
      parameter but two type arguments are provided when it is used as a type
      annotation:

      ```dart
      class C<E> {}

      void f([!C<int, int>!] x) {}
      ```

      The following code produces this diagnostic because `C` declares one type
      parameter, but two type arguments are provided when creating an instance:

      ```dart
      class C<E> {}

      var c = [!C<int, int>!]();
      ```

      #### Common fixes

      Add or remove type arguments, as necessary, to match the number of type
      parameters defined for the type:

      ```dart
      class C<E> {}

      void f(C<int> x) {}
      ```
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR:
    problemMessage: "The constructor '{0}.{1}' doesn't have type parameters."
    correctionMessage: Try moving type arguments to after the type name.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class being instantiated
      1: the name of the constructor being invoked
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when type arguments are provided
      after the name of a named constructor. Constructors can't declare type
      parameters, so invocations can only provide the type arguments associated
      with the class, and those type arguments are required to follow the name of
      the class rather than the name of the constructor.

      #### Example

      The following code produces this diagnostic because the type parameters
      (`<String>`) follow the name of the constructor rather than the name of the
      class:

      ```dart
      class C<T> {
        C.named();
      }
      C f() => C.named[!<String>!]();
      ```

      #### Common fixes

      If the type arguments are for the class' type parameters, then move the
      type arguments to follow the class name:

      ```dart
      class C<T> {
        C.named();
      }
      C f() => C<String>.named();
      ```

      If the type arguments aren't for the class' type parameters, then remove
      them:

      ```dart
      class C<T> {
        C.named();
      }
      C f() => C.named();
      ```
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_ENUM:
    problemMessage: The enum is declared with {0} type parameters, but {1} type arguments were given.
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the number of type parameters that were declared
      1: the number of type arguments provided
    documentation: |-
      #### Description
      
      The analyzer produces this diagnostic when an enum constant in an enum
      that has type parameters is instantiated and type arguments are provided,
      but the number of type arguments isn't the same as the number of type
      parameters.
      
      #### Example
      
      The following code produces this diagnostic because the enum constant `c`
      provides one type argument even though the enum `E` is declared to have
      two type parameters:
      
      ```dart
      enum E<T, U> {
        c[!<int>!]()
      }
      ```
      
      #### Common fixes
      
      If the number of type parameters is correct, then change the number of
      type arguments to match the number of type parameters:
      
      ```dart
      enum E<T, U> {
        c<int, String>()
      }
      ```
      
      If the number of type arguments is correct, then change the number of type
      parameters to match the number of type arguments:
      
      ```dart
      enum E<T> {
        c<int>()
      }
      ```
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_EXTENSION:
    problemMessage: "The extension '{0}' is declared with {1} type parameters, but {2} type arguments were given."
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the extension being referenced
      1: the number of type parameters that were declared
      2: the number of type arguments provided
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension that has type
      parameters is used and type arguments are provided, but the number of type
      arguments isn't the same as the number of type parameters.

      #### Example

      The following code produces this diagnostic because the extension `E` is
      declared to have a single type parameter (`T`), but the extension override
      has two type arguments:

      ```dart
      extension E<T> on List<T> {
        int get len => length;
      }

      void f(List<int> p) {
        E[!<int, String>!](p).len;
      }
      ```

      #### Common fixes

      Change the type arguments so that there are the same number of type
      arguments as there are type parameters:

      ```dart
      extension E<T> on List<T> {
        int get len => length;
      }

      void f(List<int> p) {
        E<int>(p).len;
      }
      ```
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_ANONYMOUS_FUNCTION:
    sharedName: WRONG_NUMBER_OF_TYPE_ARGUMENTS_FUNCTION
    problemMessage: "This function is declared with {0} type parameters, but {1} type arguments were given."
    correctionMessage: Try adjusting the number of type arguments to match the number of type parameters.
    comment: |-
      Parameters:
      0: the number of type parameters that were declared
      1: the number of type arguments provided
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_FUNCTION:
    problemMessage: "The function '{0}' is declared with {1} type parameters, but {2} type arguments were given."
    correctionMessage: Try adjusting the number of type arguments to match the number of type parameters.
    comment: |-
      Parameters:
      0: the name of the function being referenced
      1: the number of type parameters that were declared
      2: the number of type arguments provided
  WRONG_NUMBER_OF_TYPE_ARGUMENTS_METHOD:
    problemMessage: "The method '{0}' is declared with {1} type parameters, but {2} type arguments are given."
    correctionMessage: Try adjusting the number of type arguments.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method being referenced (<i>G</i>)
      1: the number of type parameters that were declared
      2: the number of type arguments provided
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function is invoked
      with a different number of type arguments than the number of type
      parameters specified in its declaration. There must either be no type
      arguments or the number of arguments must match the number of parameters.

      #### Example

      The following code produces this diagnostic because the invocation of the
      method `m` has two type arguments, but the declaration of `m` only has one
      type parameter:

      ```dart
      class C {
        int m<A>(A a) => 0;
      }

      int f(C c) => c.m[!<int, int>!](2);
      ```

      #### Common fixes

      If the type arguments are necessary, then make them match the number of
      type parameters by either adding or removing type arguments:

      ```dart
      class C {
        int m<A>(A a) => 0;
      }

      int f(C c) => c.m<int>(2);
      ```

      If the type arguments aren't necessary, then remove them:

      ```dart
      class C {
        int m<A>(A a) => 0;
      }

      int f(C c) => c.m(2);
      ```
  WRONG_TYPE_PARAMETER_VARIANCE_IN_SUPERINTERFACE:
    problemMessage: "'{0}' can't be used contravariantly or invariantly in '{1}'."
    correctionMessage: Try not using class type parameters in types of formal parameters of function types, nor in explicitly contravariant or invariant superinterfaces.
    comment: |-
      Let `C` be a generic class that declares a formal type parameter `X`, and
      assume that `T` is a direct superinterface of `C`. It is a compile-time
      error if `X` occurs contravariantly or invariantly in `T`.
  WRONG_TYPE_PARAMETER_VARIANCE_POSITION:
    problemMessage: "The '{0}' type parameter '{1}' can't be used in an '{2}' position."
    correctionMessage: "Try removing the type parameter or change the explicit variance modifier declaration for the type parameter to another one of 'in', 'out', or 'inout'."
    comment: |-
      Let `C` be a generic class that declares a formal type parameter `X`.

      If `X` is explicitly contravariant then it is a compile-time error for
      `X` to occur in a non-contravariant position in a member signature in the
      body of `C`, except when `X` is in a contravariant position in the type
      annotation of a covariant formal parameter.

      If `X` is explicitly covariant then it is a compile-time error for
      `X` to occur in a non-covariant position in a member signature in the
      body of `C`, except when `X` is in a covariant position in the type
      annotation of a covariant formal parameter.

      Parameters:
      0: the variance modifier defined for {0}
      1: the name of the type parameter
      2: the variance position that the type parameter {1} is in
  YIELD_EACH_IN_NON_GENERATOR:
    sharedName: YIELD_IN_NON_GENERATOR
    problemMessage: "Yield-each statements must be in a generator function (one marked with either 'async*' or 'sync*')."
    correctionMessage: "Try adding 'async*' or 'sync*' to the enclosing function."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `yield` or `yield*` statement
      appears in a function whose body isn't marked with one of the `async*` or
      `sync*` modifiers.

      #### Examples

      The following code produces this diagnostic because `yield` is being used
      in a function whose body doesn't have a modifier:

      ```dart
      Iterable<int> get digits {
        yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
      }
      ```

      The following code produces this diagnostic because `yield*` is being used
      in a function whose body has the `async` modifier rather than the `async*`
      modifier:

      ```dart
      Stream<int> get digits async {
        yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
      }
      ```

      #### Common fixes

      Add a modifier, or change the existing modifier to be either `async*` or
      `sync*`:

      ```dart
      Iterable<int> get digits sync* {
        yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
      }
      ```
  YIELD_IN_NON_GENERATOR:
    problemMessage: "Yield statements must be in a generator function (one marked with either 'async*' or 'sync*')."
    correctionMessage: "Try adding 'async*' or 'sync*' to the enclosing function."
    hasPublishedDocs: true
    comment: |-
      ?? Yield: It is a compile-time error if a yield statement appears in a
      function that is not a generator function.

      No parameters.
  YIELD_EACH_OF_INVALID_TYPE:
    sharedName: YIELD_OF_INVALID_TYPE
    problemMessage: "The type '{0}' implied by the 'yield*' expression must be assignable to '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the expression after `yield*`
      1: the return type of the function containing the `yield*`
  YIELD_OF_INVALID_TYPE:
    problemMessage: "A yielded value of type '{0}' must be assignable to '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the type of the expression after `yield`
      1: the return type of the function containing the `yield`
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type of object produced by
      a `yield` or `yield*` expression doesn't match the type of objects that
      are to be returned from the `Iterable` or `Stream` types that are returned
      from a generator (a function or method marked with either `sync*` or
      `async*`).

      #### Example

      The following code produces this diagnostic because the getter `zero` is
      declared to return an `Iterable` that returns integers, but the `yield` is
      returning a string from the iterable:

      ```dart
      Iterable<int> get zero sync* {
        yield [!'0'!];
      }
      ```

      #### Common fixes

      If the return type of the function is correct, then fix the expression
      following the keyword `yield` to return the correct type:

      ```dart
      Iterable<int> get zero sync* {
        yield 0;
      }
      ```

      If the expression following the `yield` is correct, then change the return
      type of the function to allow it:

      ```dart
      Iterable<String> get zero sync* {
        yield '0';
      }
      ```
FfiCode:
  ABI_SPECIFIC_INTEGER_INVALID:
    problemMessage: "Classes extending 'AbiSpecificInteger' must have exactly one const constructor, no other members, and no type arguments."
    correctionMessage: Try removing all type arguments, removing all members, and adding one const constructor.
    comment: No parameters.
  ABI_SPECIFIC_INTEGER_MAPPING_EXTRA:
    problemMessage: "Classes extending 'AbiSpecificInteger' must have exactly one 'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size."
    correctionMessage: Try removing the extra annotation.
    comment: No parameters.
  ABI_SPECIFIC_INTEGER_MAPPING_MISSING:
    problemMessage: "Classes extending 'AbiSpecificInteger' must have exactly one 'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size."
    correctionMessage: Try adding an annotation.
    comment: No parameters.
  ABI_SPECIFIC_INTEGER_MAPPING_UNSUPPORTED:
    problemMessage: "Only mappings to 'Int8', 'Int16', 'Int32', 'Int64', 'Uint8', 'Uint16', 'UInt32', and 'Uint64' are supported."
    correctionMessage: Try changing the value to 'Int8', 'Int16', 'Int32', 'Int64', 'Uint8', 'Uint16', 'UInt32', or 'Uint64'.
    comment: No parameters.
  ANNOTATION_ON_POINTER_FIELD:
    problemMessage: "Fields in a struct class whose type is 'Pointer' shouldn't have any annotations."
    correctionMessage: Try removing the annotation.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field that's declared in a
      subclass of `Struct` and has the type `Pointer` also has an annotation
      associated with it.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `p`, which
      has the type `Pointer` and is declared in a subclass of `Struct`, has the
      annotation `@Double()`:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        [!@Double()!]
        external Pointer<Int8> p;
      }
      ```

      #### Common fixes

      Remove the annotations from the field:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        external Pointer<Int8> p;
      }
      ```
  ARGUMENT_MUST_BE_A_CONSTANT:
    problemMessage: "Argument '{0}' must be a constant."
    correctionMessage: Try replacing the value with a literal or const.
    comment: |-
      Parameters:
      0: the name of the argument
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of either
      `Pointer.asFunction` or `DynamicLibrary.lookupFunction` has an `isLeaf`
      argument whose value isn't a constant expression.

      The analyzer also produces this diagnostic when the value of the
      `exceptionalReturn` argument of `Pointer.fromFunction`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the value of the
      `isLeaf` argument is a parameter, and hence isn't a constant:

      ```dart
      import 'dart:ffi';

      int Function(int) fromPointer(
          Pointer<NativeFunction<Int8 Function(Int8)>> p, bool isLeaf) {
        return p.asFunction(isLeaf: [!isLeaf!]);
      }
      ```

      #### Common fixes

      If there's a suitable constant that can be used, then replace the argument
      with a constant:

      ```dart
      import 'dart:ffi';

      const isLeaf = false;

      int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
        return p.asFunction(isLeaf: isLeaf);
      }
      ```

      If there isn't a suitable constant, then replace the argument with a
      boolean literal:

      ```dart
      import 'dart:ffi';

      int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
        return p.asFunction(isLeaf: true);
      }
      ```
  COMPOUND_IMPLEMENTS_FINALIZABLE:
    problemMessage: "The class '{0}' can't implement Finalizable."
    correctionMessage: "Try removing the implements clause from '{0}'."
    comment: |-
      Parameters:
      0: the name of the struct or union class
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of either `Struct`
      or `Union` implements `Finalizable`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `S`
      implements `Finalizable`:

      ```dart
      import 'dart:ffi';

      class [!S!] extends Struct implements Finalizable {
        external Pointer notEmpty;
      }
      ```

      #### Common fixes

      Try removing the implements clause from the class:

      ```dart
      import 'dart:ffi';

      class S extends Struct {
        external Pointer notEmpty;
      }
      ```
  CREATION_OF_STRUCT_OR_UNION:
    problemMessage: "Subclasses of 'Struct' and 'Union' are backed by native memory, and can't be instantiated by a generative constructor."
    correctionMessage: "Try allocating it via allocation, or load from a 'Pointer'."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of either `Struct`
      or `Union` is instantiated using a generative constructor.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C` is being
      instantiated using a generative constructor:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        external int a;
      }

      void f() {
        [!C!]();
      }
      ```

      #### Common fixes

      If you need to allocate the structure described by the class, then use the
      `ffi` package to do so:

      ```dart
      import 'dart:ffi';
      import 'package:ffi/ffi.dart';

      class C extends Struct {
        @Int32()
        external int a;
      }

      void f() {
        final pointer = calloc.allocate<C>(4);
        final c = pointer.ref;
        print(c);
        calloc.free(pointer);
      }
      ```
  EMPTY_STRUCT:
    problemMessage: "The class '{0}' can't be empty because it's a subclass of '{1}'."
    correctionMessage: "Try adding a field to '{0}' or use a different superclass."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the superclass
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of `Struct` or
      `Union` doesn't have any fields. Having an empty `Struct` or `Union`
      isn't supported.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C`, which
      extends `Struct`, doesn't declare any fields:

      ```dart
      import 'dart:ffi';

      class [!C!] extends Struct {}
      ```

      #### Common fixes

      If the class is intended to be a struct, then declare one or more fields:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        external int x;
      }
      ```

      If the class is intended to be used as a type argument to `Pointer`, then
      make it a subclass of `Opaque`:

      ```dart
      import 'dart:ffi';

      class C extends Opaque {}
      ```

      If the class isn't intended to be a struct, then remove or change the
      extends clause:

      ```dart
      class C {}
      ```
  EXTRA_ANNOTATION_ON_STRUCT_FIELD:
    problemMessage: Fields in a struct class must have exactly one annotation indicating the native type.
    correctionMessage: Try removing the extra annotation.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` has more than one annotation describing the native type of the
      field.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `x` has two
      annotations describing the native type of the field:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        [!@Int16()!]
        external int x;
      }
      ```

      #### Common fixes

      Remove all but one of the annotations:

      ```dart
      import 'dart:ffi';
      class C extends Struct {
        @Int32()
        external int x;
      }
      ```
  EXTRA_SIZE_ANNOTATION_CARRAY:
    problemMessage: "'Array's must have exactly one 'Array' annotation."
    correctionMessage: Try removing the extra annotation.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` has more than one annotation describing the size of the native
      array.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `a0` has two
      annotations that specify the size of the native array:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(4)
        [!@Array(8)!]
        external Array<Uint8> a0;
      }
      ```

      #### Common fixes

      Remove all but one of the annotations:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8)
        external Array<Uint8> a0;
      }
      ```
  FFI_NATIVE_MUST_BE_EXTERNAL:
    problemMessage: FfiNative functions must be declared external.
    correctionMessage: Add the `external` keyword to the function.
    comment: No parameters.
  FFI_NATIVE_ONLY_CLASSES_EXTENDING_NATIVEFIELDWRAPPERCLASS1_CAN_BE_POINTER:
    problemMessage: Only classes extending NativeFieldWrapperClass1 can be passed as Pointer.
    correctionMessage: Pass as Handle instead.
    comment: No parameters.
  FFI_NATIVE_UNEXPECTED_NUMBER_OF_PARAMETERS:
    problemMessage: Unexpected number of FfiNative annotation parameters. Expected {0} but has {1}.
    correctionMessage: Make sure parameters match the function annotated.
    comment: |-
      Parameters:
      0: the expected number of parameters
      1: the actual number of parameters
  FFI_NATIVE_UNEXPECTED_NUMBER_OF_PARAMETERS_WITH_RECEIVER:
    problemMessage: Unexpected number of FfiNative annotation parameters. Expected {0} but has {1}. FfiNative instance method annotation must have receiver as first argument.
    correctionMessage: Make sure parameters match the function annotated, including an extra first parameter for the receiver.
    comment: |-
      Parameters:
      0: the expected number of parameters
      1: the actual number of parameters
  FIELD_INITIALIZER_IN_STRUCT:
    problemMessage: "Constructors in subclasses of 'Struct' and 'Union' can't have field initializers."
    correctionMessage: Try removing the field initializer and marking the field as external.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor in a subclass of
      either `Struct` or `Union` has one or more field initializers.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C` has a
      constructor with an initializer for the field `f`:

      ```dart
      // @dart = 2.9
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        int f;

        C() : [!f = 0!];
      }
      ```

      #### Common fixes

      Remove the field initializer:

      ```dart
      // @dart = 2.9
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        int f;

        C();
      }
      ```
  FIELD_IN_STRUCT_WITH_INITIALIZER:
    problemMessage: "Fields in subclasses of 'Struct' and 'Union' can't have initializers."
    correctionMessage: Try removing the initializer and marking the field as external.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` has an initializer.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `p` has an
      initializer:

      ```dart
      // @dart = 2.9
      import 'dart:ffi';

      class C extends Struct {
        Pointer [!p!] = nullptr;
      }
      ```

      #### Common fixes

      Remove the initializer:

      ```dart
      // @dart = 2.9
      import 'dart:ffi';

      class C extends Struct {
        Pointer p;
      }
      ```
  FIELD_MUST_BE_EXTERNAL_IN_STRUCT:
    problemMessage: "Fields of 'Struct' and 'Union' subclasses must be marked external."
    correctionMessage: "Try adding the 'external' modifier."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of either
      `Struct` or `Union` isn't marked as being `external`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `a` isn't
      marked as being `external`:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int16()
        int [!a!];
      }
      ```

      #### Common fixes

      Add the required `external` modifier:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int16()
        external int a;
      }
      ```
  GENERIC_STRUCT_SUBCLASS:
    problemMessage: "The class '{0}' can't extend 'Struct' or 'Union' because '{0}' is generic."
    correctionMessage: "Try removing the type parameters from '{0}'."
    comment: |-
      Parameters:
      0: the name of the struct class
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of either `Struct`
      or `Union` has a type parameter.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `S` defines
      the type parameter `T`:

      ```dart
      import 'dart:ffi';

      class [!S!]<T> extends Struct {
        external Pointer notEmpty;
      }
      ```

      #### Common fixes

      Remove the type parameters from the class:

      ```dart
      import 'dart:ffi';

      class S extends Struct {
        external Pointer notEmpty;
      }
      ```
  INVALID_EXCEPTION_VALUE:
    problemMessage: "The method 'Pointer.fromFunction' can't have an exceptional return value (the second argument) when the return type of the function is either 'void', 'Handle' or 'Pointer'."
    correctionMessage: Try removing the exceptional return value.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of the method
      `Pointer.fromFunction` has a second argument (the exceptional return
      value) and the type to be returned from the invocation is either `void`,
      `Handle` or `Pointer`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because a second argument is
      provided when the return type of `f` is `void`:

      ```dart
      import 'dart:ffi';

      typedef T = Void Function(Int8);

      void f(int i) {}

      void g() {
        Pointer.fromFunction<T>(f, [!42!]);
      }
      ```

      #### Common fixes

      Remove the exception value:

      ```dart
      import 'dart:ffi';

      typedef T = Void Function(Int8);

      void f(int i) {}

      void g() {
        Pointer.fromFunction<T>(f);
      }
      ```
  INVALID_FIELD_TYPE_IN_STRUCT:
    problemMessage: "Fields in struct classes can't have the type '{0}'. They can only be declared as 'int', 'double', 'Array', 'Pointer', or subtype of 'Struct' or 'Union'."
    correctionMessage: "Try using 'int', 'double', 'Array', 'Pointer', or subtype of 'Struct' or 'Union'."
    comment: |-
      Parameters:
      0: the type of the field
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` has a type other than `int`, `double`, `Array`, `Pointer`, or
      subtype of `Struct` or `Union`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `str` has
      the type `String`, which isn't one of the allowed types for fields in a
      subclass of `Struct`:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        external [!String!] s;

        @Int32()
        external int i;
      }
      ```

      #### Common fixes

      Use one of the allowed types for the field:

      ```dart
      import 'dart:ffi';
      import 'package:ffi/ffi.dart';

      class C extends Struct {
        external Pointer<Utf8> s;

        @Int32()
        external int i;
      }
      ```
  LEAF_CALL_MUST_NOT_RETURN_HANDLE:
    problemMessage: "FFI leaf call can't return a 'Handle'."
    correctionMessage: Try changing the return type to primitive or struct.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of the `isLeaf`
      argument in an invocation of either `Pointer.asFunction` or
      `DynamicLibrary.lookupFunction` is `true` and the function that would be
      returned would have a return type of `Handle`.

      The analyzer also produces this diagnostic when the value of the `isLeaf`
      argument in an `FfiNative` annotation is `true` and the type argument on
      the annotation is a function type whose return type is `Handle`.

      In all of these cases, leaf calls are only supported for the types `bool`,
      `int`, `float`, `double`, and, as a return type `void`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the function `p`
      returns a `Handle`, but the `isLeaf` argument is `true`:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Handle Function()>> p) {
        [!p.asFunction<Object Function()>(isLeaf: true)!];
      }
      ```

      #### Common fixes

      If the function returns a handle, then remove the `isLeaf` argument:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Handle Function()>> p) {
        p.asFunction<Object Function()>();
      }
      ```

      If the function returns one of the supported types, then correct the type
      information:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Int32 Function()>> p) {
        p.asFunction<int Function()>(isLeaf: true);
      }
      ```
  LEAF_CALL_MUST_NOT_TAKE_HANDLE:
    problemMessage: "FFI leaf call can't take arguments of type 'Handle'."
    correctionMessage: Try changing the argument type to primitive or struct.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of the `isLeaf`
      argument in an invocation of either `Pointer.asFunction` or
      `DynamicLibrary.lookupFunction` is `true` and the function that would be
      returned would have a parameter of type `Handle`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the function `p` has a
      parameter of type `Handle`, but the `isLeaf` argument is `true`:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Void Function(Handle)>> p) {
        [!p.asFunction<void Function(Object)>(isLeaf: true)!];
      }
      ```

      #### Common fixes

      If the function has at least one parameter of type `Handle`, then remove
      the `isLeaf` argument:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Void Function(Handle)>> p) {
        p.asFunction<void Function(Object)>();
      }
      ```

      If none of the function's parameters are `Handle`s, then correct the type
      information:

      ```dart
      import 'dart:ffi';

      void f(Pointer<NativeFunction<Void Function(Int8)>> p) {
        p.asFunction<void Function(int)>(isLeaf: true);
      }
      ```
  MISMATCHED_ANNOTATION_ON_STRUCT_FIELD:
    problemMessage: "The annotation doesn't match the declared type of the field."
    correctionMessage: Try using a different annotation or changing the declared type to match.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the annotation on a field in a
      subclass of `Struct` or `Union` doesn't match the Dart type of the field.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the annotation
      `Double` doesn't match the Dart type `int`:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        [!@Double()!]
        external int x;
      }
      ```

      #### Common fixes

      If the type of the field is correct, then change the annotation to match:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        external int x;
      }
      ```

      If the annotation is correct, then change the type of the field to match:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Double()
        external double x;
      }
      ```
  MISSING_ANNOTATION_ON_STRUCT_FIELD:
    problemMessage: "Fields in a struct class must either have the type 'Pointer' or an annotation indicating the native type."
    correctionMessage: Try adding an annotation.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` or `Union` whose type requires an annotation doesn't have one.
      The Dart types `int`, `double`, and `Array` are used to represent multiple
      C types, and the annotation specifies which of the compatible C types the
      field represents.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `x` doesn't
      have an annotation indicating the underlying width of the integer value:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        external [!int!] x;
      }
      ```

      #### Common fixes

      Add an appropriate annotation to the field:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int64()
        external int x;
      }
      ```
  MISSING_EXCEPTION_VALUE:
    problemMessage: "The method 'Pointer.fromFunction' must have an exceptional return value (the second argument) when the return type of the function is neither 'void', 'Handle', nor 'Pointer'."
    correctionMessage: Try adding an exceptional return value.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of the method
      `Pointer.fromFunction` doesn't have a second argument (the exceptional
      return value) when the type to be returned from the invocation is neither
      `void`, `Handle`, nor `Pointer`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the type returned by
      `f` is expected to be an 8-bit integer but the call to `fromFunction`
      doesn't include an exceptional return argument:

      ```dart
      import 'dart:ffi';

      int f(int i) => i * 2;

      void g() {
        Pointer.[!fromFunction!]<Int8 Function(Int8)>(f);
      }
      ```

      #### Common fixes

      Add an exceptional return type:

      ```dart
      import 'dart:ffi';

      int f(int i) => i * 2;

      void g() {
        Pointer.fromFunction<Int8 Function(Int8)>(f, 0);
      }
      ```
  MISSING_FIELD_TYPE_IN_STRUCT:
    problemMessage: "Fields in struct classes must have an explicitly declared type of 'int', 'double' or 'Pointer'."
    correctionMessage: "Try using 'int', 'double' or 'Pointer'."
    comment: |-
      Parameters:
      0: the type of the field
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of
      `Struct` or `Union` doesn't have a type annotation. Every field must have
      an explicit type, and the type must either be `int`, `double`, `Pointer`,
      or a subclass of either `Struct` or `Union`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `str`
      doesn't have a type annotation:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        external var [!str!];

        @Int32()
        external int i;
      }
      ```

      #### Common fixes

      Explicitly specify the type of the field:

      ```dart
      import 'dart:ffi';
      import 'package:ffi/ffi.dart';

      class C extends Struct {
        external Pointer<Utf8> str;

        @Int32()
        external int i;
      }
      ```
  MISSING_SIZE_ANNOTATION_CARRAY:
    problemMessage: "Fields of type 'Array' must have exactly one 'Array' annotation."
    correctionMessage: "Try adding an 'Array' annotation, or removing all but one of the annotations."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a field in a subclass of either
      `Struct` or `Union` has a type of `Array` but doesn't have a single
      `Array` annotation indicating the dimensions of the array.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `a0` doesn't
      have an `Array` annotation:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        external [!Array<Uint8>!] a0;
      }
      ```

      #### Common fixes

      Ensure that there's exactly one `Array` annotation on the field:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8)
        external Array<Uint8> a0;
      }
      ```
  MUST_BE_A_NATIVE_FUNCTION_TYPE:
    problemMessage: "The type '{0}' given to '{1}' must be a valid 'dart:ffi' native function type."
    correctionMessage: "Try changing the type to only use members for 'dart:ffi'."
    comment: |-
      Parameters:
      0: the type that should be a valid dart:ffi native type.
      1: the name of the function whose invocation depends on this relationship
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of either
      `Pointer.fromFunction` or `DynamicLibrary.lookupFunction` has a type
      argument(whether explicit or inferred) that isn't a native function type.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the type `T` can be
      any subclass of `Function` but the type argument for `fromFunction` is
      required to be a native function type:

      ```dart
      import 'dart:ffi';

      int f(int i) => i * 2;

      class C<T extends Function> {
        void g() {
          Pointer.fromFunction<[!T!]>(f, 0);
        }
      }
      ```

      #### Common fixes

      Use a native function type as the type argument to the invocation:

      ```dart
      import 'dart:ffi';

      int f(int i) => i * 2;

      class C<T extends Function> {
        void g() {
          Pointer.fromFunction<Int32 Function(Int32)>(f, 0);
        }
      }
      ```
  MUST_BE_A_SUBTYPE:
    problemMessage: "The type '{0}' must be a subtype of '{1}' for '{2}'."
    correctionMessage: Try changing one or both of the type arguments.
    comment: |-
      Parameters:
      0: the type that should be a subtype
      1: the supertype that the subtype is compared to
      2: the name of the function whose invocation depends on this relationship
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic in two cases:
      - In an invocation of `Pointer.fromFunction` where the type argument
        (whether explicit or inferred) isn't a supertype of the type of the
        function passed as the first argument to the method.
      - In an invocation of `DynamicLibrary.lookupFunction` where the first type
        argument isn't a supertype of the second type argument.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the type of the
      function `f` (`String Function(int)`) isn't a subtype of the type
      argument `T` (`Int8 Function(Int8)`):

      ```dart
      import 'dart:ffi';

      typedef T = Int8 Function(Int8);

      double f(double i) => i;

      void g() {
        Pointer.fromFunction<T>([!f!], 5.0);
      }
      ```

      #### Common fixes

      If the function is correct, then change the type argument to match:

      ```dart
      import 'dart:ffi';

      typedef T = Float Function(Float);

      double f(double i) => i;

      void g() {
        Pointer.fromFunction<T>(f, 5.0);
      }
      ```

      If the type argument is correct, then change the function to match:

      ```dart
      import 'dart:ffi';

      typedef T = Int8 Function(Int8);

      int f(int i) => i;

      void g() {
        Pointer.fromFunction<T>(f, 5);
      }
      ```
  NON_CONSTANT_TYPE_ARGUMENT:
    problemMessage: "The type arguments to '{0}' must be known at compile time, so they can't be type parameters."
    correctionMessage: Try changing the type argument to be a constant type.
    comment: |-
      Parameters:
      0: the name of the function, method, or constructor having type arguments
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type arguments to a method
      are required to be known at compile time, but a type parameter, whose
      value can't be known at compile time, is used as a type argument.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the type argument to
      `Pointer.asFunction` must be known at compile time, but the type parameter
      `R`, which isn't known at compile time, is being used as the type
      argument:

      ```dart
      import 'dart:ffi';

      typedef T = int Function(int);

      class C<R extends T> {
        void m(Pointer<NativeFunction<T>> p) {
          p.asFunction<[!R!]>();
        }
      }
      ```

      #### Common fixes

      Remove any uses of type parameters:

      ```dart
      import 'dart:ffi';

      class C {
        void m(Pointer<NativeFunction<Int64 Function(Int64)>> p) {
          p.asFunction<int Function(int)>();
        }
      }
      ```
  NON_NATIVE_FUNCTION_TYPE_ARGUMENT_TO_POINTER:
    problemMessage: "Can't invoke 'asFunction' because the function signature '{0}' for the pointer isn't a valid C function signature."
    correctionMessage: "Try changing the function argument in 'NativeFunction' to only use NativeTypes."
    comment: |-
      Parameters:
      0: the type that should be a valid dart:ffi native type.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the method `asFunction` is
      invoked on a pointer to a native function, but the signature of the native
      function isn't a valid C function signature.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because function signature
      associated with the pointer `p` (`FNative`) isn't a valid C function
      signature:

      ```dart
      import 'dart:ffi';

      typedef FNative = int Function(int);
      typedef F = int Function(int);

      class C {
        void f(Pointer<NativeFunction<FNative>> p) {
          p.asFunction<[!F!]>();
        }
      }
      ```

      #### Common fixes

      Make the `NativeFunction` signature a valid C signature:

      ```dart
      import 'dart:ffi';

      typedef FNative = Int8 Function(Int8);
      typedef F = int Function(int);

      class C {
        void f(Pointer<NativeFunction<FNative>> p) {
          p.asFunction<F>();
        }
      }
      ```
  NON_POSITIVE_ARRAY_DIMENSION:
    problemMessage: Array dimensions must be positive numbers.
    correctionMessage: Try changing the input to a positive number.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a dimension given in an `Array`
      annotation is less than or equal to zero (`0`).

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because an array dimension of
      `-1` was provided:

      ```dart
      import 'dart:ffi';

      class MyStruct extends Struct {
        @Array([!-8!])
        external Array<Uint8> a0;
      }
      ```

      #### Common fixes

      Change the dimension to be a positive integer:

      ```dart
      import 'dart:ffi';

      class MyStruct extends Struct {
        @Array(8)
        external Array<Uint8> a0;
      }
      ```
  NON_SIZED_TYPE_ARGUMENT:
    problemMessage: "The type '{1}' isn't a valid type argument for '{0}'. The type argument must be a native integer, 'Float', 'Double', 'Pointer', or subtype of 'Struct', 'Union', or 'AbiSpecificInteger'."
    correctionMessage: "Try using a native integer, 'Float', 'Double', 'Pointer', or subtype of 'Struct', 'Union', or 'AbiSpecificInteger'."
    comment: |-
      Parameters:
      0: the type of the field
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type argument for the class
      `Array` isn't one of the valid types: either a native integer, `Float`,
      `Double`, `Pointer`, or subtype of `Struct`, `Union`, or
      `AbiSpecificInteger`.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the type argument to
      `Array` is `Void`, and `Void` isn't one of the valid types:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8)
        external Array<[!Void!]> a0;
      }
      ```

      #### Common fixes

      Change the type argument to one of the valid types:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8)
        external Array<Uint8> a0;
      }
      ```
  PACKED_ANNOTATION:
    problemMessage: "Structs must have at most one 'Packed' annotation."
    correctionMessage: "Try removing extra 'Packed' annotations."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of `Struct` has more
      than one `Packed` annotation.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C`, which
      is a subclass of `Struct`, has two `Packed` annotations:

      ```dart
      import 'dart:ffi';

      @Packed(1)
      [!@Packed(1)!]
      class C extends Struct {
        external Pointer<Uint8> notEmpty;
      }
      ```

      #### Common fixes

      Remove all but one of the annotations:

      ```dart
      import 'dart:ffi';

      @Packed(1)
      class C extends Struct {
        external Pointer<Uint8> notEmpty;
      }
      ```
  PACKED_ANNOTATION_ALIGNMENT:
    problemMessage: Only packing to 1, 2, 4, 8, and 16 bytes is supported.
    correctionMessage: "Try changing the 'Packed' annotation alignment to 1, 2, 4, 8, or 16."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the argument to the `Packed`
      annotation isn't one of the allowed values: 1, 2, 4, 8, or 16.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the argument to the
      `Packed` annotation (`3`) isn't one of the allowed values:

      ```dart
      import 'dart:ffi';

      @Packed([!3!])
      class C extends Struct {
        external Pointer<Uint8> notEmpty;
      }
      ```

      #### Common fixes

      Change the alignment to be one of the allowed values:

      ```dart
      import 'dart:ffi';

      @Packed(4)
      class C extends Struct {
        external Pointer<Uint8> notEmpty;
      }
      ```
  PACKED_NESTING_NON_PACKED:
    problemMessage: "Nesting the non-packed or less tightly packed struct '{0}' in a packed struct '{1}' isn't supported."
    correctionMessage: Try packing the nested struct or packing the nested struct more tightly.
    comment: |-
      Parameters:
      0: the name of the outer struct
      1: the name of the struct being nested
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a subclass of `Struct` that is
      annotated as being `Packed` declares a field whose type is also a subclass
      of `Struct` and the field's type is either not packed or is packed less
      tightly.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `Outer`,
      which is a subclass of `Struct` and is packed on 1-byte boundaries,
      declared a field whose type (`Inner`) is packed on 8-byte boundaries:

      ```dart
      import 'dart:ffi';

      @Packed(8)
      class Inner extends Struct {
        external Pointer<Uint8> notEmpty;
      }

      @Packed(1)
      class Outer extends Struct {
        external Pointer<Uint8> notEmpty;

        external [!Inner!] nestedLooselyPacked;
      }
      ```

      #### Common fixes

      If the inner struct should be packed more tightly, then change the
      argument to the inner struct's `Packed` annotation:

      ```dart
      import 'dart:ffi';

      @Packed(1)
      class Inner extends Struct {
        external Pointer<Uint8> notEmpty;
      }

      @Packed(1)
      class Outer extends Struct {
        external Pointer<Uint8> notEmpty;

        external Inner nestedLooselyPacked;
      }
      ```

      If the outer struct should be packed less tightly, then change the
      argument to the outer struct's `Packed` annotation:

      ```dart
      import 'dart:ffi';

      @Packed(8)
      class Inner extends Struct {
        external Pointer<Uint8> notEmpty;
      }

      @Packed(8)
      class Outer extends Struct {
        external Pointer<Uint8> notEmpty;

        external Inner nestedLooselyPacked;
      }
      ```

      If the inner struct doesn't have an annotation and should be packed, then
      add an annotation.

      If the inner struct doesn't have an annotation and the outer struct
      shouldn't be packed, then remove its annotation.
  SIZE_ANNOTATION_DIMENSIONS:
    problemMessage: "'Array's must have an 'Array' annotation that matches the dimensions."
    correctionMessage: "Try adjusting the arguments in the 'Array' annotation."
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the number of dimensions
      specified in an `Array` annotation doesn't match the number of nested
      arrays specified by the type of a field.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the field `a0` has a
      type with three nested arrays, but only two dimensions are given in the
      `Array` annotation:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        [!@Array(8, 8)!]
        external Array<Array<Array<Uint8>>> a0;
      }
      ```

      #### Common fixes

      If the type of the field is correct, then fix the annotation to have the
      required number of dimensions:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8, 8, 4)
        external Array<Array<Array<Uint8>>> a0;
      }
      ```

      If the type of the field is wrong, then fix the type of the field:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Array(8, 8)
        external Array<Array<Uint8>> a0;
      }
      ```
  SUBTYPE_OF_FFI_CLASS_IN_EXTENDS:
    sharedName: SUBTYPE_OF_FFI_CLASS
    problemMessage: "The class '{0}' can't extend '{1}'."
    correctionMessage: "Try extending 'Struct' or 'Union'."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class extends any FFI class
      other than `Struct` or `Union`, or implements or mixes in any FFI class.
      `Struct` and `Union` are the only FFI classes that can be subtyped, and
      then only by extending them.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C` extends
      `Double`:

      ```dart
      import 'dart:ffi';

      class C extends [!Double!] {}
      ```

      #### Common fixes

      If the class should extend either `Struct` or `Union`, then change the
      declaration of the class:

      ```dart
      import 'dart:ffi';

      class C extends Struct {
        @Int32()
        external int i;
      }
      ```

      If the class shouldn't extend either `Struct` or `Union`, then remove any
      references to FFI classes:

      ```dart
      class C {}
      ```
  SUBTYPE_OF_FFI_CLASS_IN_IMPLEMENTS:
    sharedName: SUBTYPE_OF_FFI_CLASS
    problemMessage: "The class '{0}' can't implement '{1}'."
    correctionMessage: "Try implementing 'Allocator' or 'Finalizable'."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
  SUBTYPE_OF_FFI_CLASS_IN_WITH:
    sharedName: SUBTYPE_OF_FFI_CLASS
    problemMessage: "The class '{0}' can't mix in '{1}'."
    correctionMessage: "Try extending 'Struct' or 'Union'."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
  SUBTYPE_OF_STRUCT_CLASS_IN_EXTENDS:
    sharedName: SUBTYPE_OF_STRUCT_CLASS
    problemMessage: "The class '{0}' can't extend '{1}' because '{1}' is a subtype of 'Struct', 'Union', or 'AbiSpecificInteger'."
    correctionMessage: "Try extending 'Struct', 'Union', or 'AbiSpecificInteger' directly."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class extends, implements, or
      mixes in a class that extends either `Struct` or `Union`. Classes can only
      extend either `Struct` or `Union` directly.

      For more information about FFI, see [C interop using dart:ffi][].

      #### Example

      The following code produces this diagnostic because the class `C` extends
      `S`, and `S` extends `Struct`:

      ```dart
      import 'dart:ffi';

      class S extends Struct {
        external Pointer f;
      }

      class C extends [!S!] {
        external Pointer g;
      }
      ```

      #### Common fixes

      If you're trying to define a struct or union that shares some fields
      declared by a different struct or union, then extend `Struct` or `Union`
      directly and copy the shared fields:

      ```dart
      import 'dart:ffi';

      class S extends Struct {
        external Pointer f;
      }

      class C extends Struct {
        external Pointer f;

        external Pointer g;
      }
      ```
  SUBTYPE_OF_STRUCT_CLASS_IN_IMPLEMENTS:
    sharedName: SUBTYPE_OF_STRUCT_CLASS
    problemMessage: "The class '{0}' can't implement '{1}' because '{1}' is a subtype of 'Struct', 'Union', or 'AbiSpecificInteger'."
    correctionMessage: "Try extending 'Struct', 'Union', or 'AbiSpecificInteger' directly."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
  SUBTYPE_OF_STRUCT_CLASS_IN_WITH:
    sharedName: SUBTYPE_OF_STRUCT_CLASS
    problemMessage: "The class '{0}' can't mix in '{1}' because '{1}' is a subtype of 'Struct', 'Union', or 'AbiSpecificInteger'."
    correctionMessage: "Try extending 'Struct', 'Union', or 'AbiSpecificInteger' directly."
    comment: |-
      Parameters:
      0: the name of the subclass
      1: the name of the class being extended, implemented, or mixed in
    hasPublishedDocs: true
HintCode:
  ARGUMENT_TYPE_NOT_ASSIGNABLE_TO_ERROR_HANDLER:
    problemMessage: "The argument type '{0}' can't be assigned to the parameter type '{1} Function(Object)' or '{1} Function(Object, StackTrace)'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the actual argument type
      1: the name of the expected function return type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of
      `Future.catchError` has an argument that is a function whose parameters
      aren't compatible with the arguments that will be passed to the function
      when it's invoked. The static type of the first argument to `catchError`
      is just `Function`, even though the function that is passed in is expected
      to have either a single parameter of type `Object` or two parameters of
      type `Object` and `StackTrace`.

      #### Examples

      The following code produces this diagnostic because the closure being
      passed to `catchError` doesn't take any parameters, but the function is
      required to take at least one parameter:

      ```dart
      void f(Future<int> f) {
        f.catchError([!() => 0!]);
      }
      ```

      The following code produces this diagnostic because the closure being
      passed to `catchError` takes three parameters, but it can't have more than
      two required parameters:

      ```dart
      void f(Future<int> f) {
        f.catchError([!(one, two, three) => 0!]);
      }
      ```

      The following code produces this diagnostic because even though the closure
      being passed to `catchError` takes one parameter, the closure doesn't have
      a type that is compatible with `Object`:

      ```dart
      void f(Future<int> f) {
        f.catchError([!(String error) => 0!]);
      }
      ```

      #### Common fixes

      Change the function being passed to `catchError` so that it has either one
      or two required parameters, and the parameters have the required types:

      ```dart
      void f(Future<int> f) {
        f.catchError((Object error) => 0);
      }
      ```
  ASSIGNMENT_OF_DO_NOT_STORE:
    problemMessage: "'{0}' is marked 'doNotStore' and shouldn't be assigned to a field or top-level variable."
    correctionMessage: Try removing the assignment.
    comment: Users should not assign values marked `@doNotStore`.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of a function
      (including methods and getters) that is explicitly or implicitly marked by
      the `[doNotStore][meta-doNotStore]` annotation is stored in either a field
      or top-level variable.

      #### Example

      The following code produces this diagnostic because the value of the
      function `f` is being stored in the top-level variable `x`:

      ```dart
      import 'package:meta/meta.dart';

      @doNotStore
      int f() => 1;

      var x = [!f()!];
      ```

      #### Common fixes

      Replace references to the field or variable with invocations of the
      function producing the value.
  BODY_MIGHT_COMPLETE_NORMALLY_NULLABLE:
    problemMessage: "This function has a nullable return type of '{0}', but ends without returning a value."
    correctionMessage: "Try adding a return statement, or if no value is ever returned, try changing the return type to 'void'."
    hasPublishedDocs: false
    comment: |-
      Parameters:
      0: the name of the declared return type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function can
      implicitly return `null` by falling off the end. While this is valid Dart
      code, it's better for the return of `null` to be explicit.

      #### Example

      The following code produces this diagnostic because the function `f`
      implicitly returns `null`:

      ```dart
      String? [!f!]() {}
      ```

      #### Common fixes

      If the return of `null` is intentional, then make it explicit:

      ```dart
      String? f() {
        return null;
      }
      ```

      If the function should return a non-null value along that path, then add
      the missing return statement:

      ```dart
      String? f() {
        return '';
      }
      ```
  CAN_BE_NULL_AFTER_NULL_AWARE:
    problemMessage: "The receiver uses '?.', so its value can be null."
    correctionMessage: "Replace the '.' with a '?.' in the invocation."
    comment: |-
      When the target expression uses '?.' operator, it can be `null`, so all the
      subsequent invocations should also use '?.' operator.
  DEAD_CODE:
    problemMessage: Dead code.
    correctionMessage: Try removing the code, or fixing the code before it so that it can be reached.
    hasPublishedDocs: true
    comment: |-
      Dead code is code that is never reached, this can happen for instance if a
      statement follows a return statement.

      No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when code is found that won't be
      executed because execution will never reach the code.

      #### Example

      The following code produces this diagnostic because the invocation of
      `print` occurs after the function has returned:

      ```dart
      void f() {
        return;
        [!print('here');!]
      }
      ```

      #### Common fixes

      If the code isn't needed, then remove it:

      ```dart
      void f() {
        return;
      }
      ```

      If the code needs to be executed, then either move the code to a place
      where it will be executed:

      ```dart
      void f() {
        print('here');
        return;
      }
      ```

      Or, rewrite the code before it, so that it can be reached:

      ```dart
      void f({bool skipPrinting = true}) {
        if (skipPrinting) {
          return;
        }
        print('here');
      }
      ```
  DEAD_CODE_CATCH_FOLLOWING_CATCH:
    problemMessage: "Dead code: Catch clauses after a 'catch (e)' or an 'on Object catch (e)' are never reached."
    correctionMessage: Try reordering the catch clauses so that they can be reached, or removing the unreachable catch clauses.
    hasPublishedDocs: true
    comment: |-
      Dead code is code that is never reached. This case covers cases where the
      user has catch clauses after `catch (e)` or `on Object catch (e)`.

      No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `catch` clause is found that
      can't be executed because it’s after a `catch` clause of the form
      `catch (e)` or `on Object catch (e)`. The first `catch` clause that matches
      the thrown object is selected, and both of those forms will match any
      object, so no `catch` clauses that follow them will be selected.

      #### Example

      The following code produces this diagnostic:

      ```dart
      void f() {
        try {
        } catch (e) {
        } [!on String {
        }!]
      }
      ```

      #### Common fixes

      If the clause should be selectable, then move the clause before the general
      clause:

      ```dart
      void f() {
        try {
        } on String {
        } catch (e) {
        }
      }
      ```

      If the clause doesn't need to be selectable, then remove it:

      ```dart
      void f() {
        try {
        } catch (e) {
        }
      }
      ```
  DEAD_CODE_ON_CATCH_SUBTYPE:
    problemMessage: "Dead code: This on-catch block won’t be executed because '{0}' is a subtype of '{1}' and hence will have been caught already."
    correctionMessage: Try reordering the catch clauses so that this block can be reached, or removing the unreachable catch clause.
    hasPublishedDocs: true
    comment: |-
      Dead code is code that is never reached. This case covers cases where the
      user has an on-catch clause such as `on A catch (e)`, where a supertype of
      `A` was already caught.

      Parameters:
      0: name of the subtype
      1: name of the supertype
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `catch` clause is found that
      can't be executed because it is after a `catch` clause that catches either
      the same type or a supertype of the clause's type. The first `catch` clause
      that matches the thrown object is selected, and the earlier clause always
      matches anything matchable by the highlighted clause, so the highlighted
      clause will never be selected.

      #### Example

      The following code produces this diagnostic:

      ```dart
      void f() {
        try {
        } on num {
        } [!on int {
        }!]
      }
      ```

      #### Common fixes

      If the clause should be selectable, then move the clause before the general
      clause:

      ```dart
      void f() {
        try {
        } on int {
        } on num {
        }
      }
      ```

      If the clause doesn't need to be selectable, then remove it:

      ```dart
      void f() {
        try {
        } on num {
        }
      }
      ```
  DEPRECATED_FUNCTION_CLASS_DECLARATION:
    problemMessage: "Declaring a class named 'Function' is deprecated."
    correctionMessage: Try renaming the class.
    comment: Users should not create a class named `Function` anymore.
  DEPRECATED_MEMBER_USE:
    problemMessage: "'{0}' is deprecated and shouldn't be used."
    correctionMessage: Try replacing the use of the deprecated member with the replacement.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a deprecated library or class
      member is used in a different package.

      #### Example

      If the method `m` in the class `C` is annotated with `@deprecated`, then
      the following code produces this diagnostic:

      ```dart
      void f(C c) {
        c.[!m!]();
      }
      ```

      #### Common fixes

      The documentation for declarations that are annotated with `@deprecated`
      should indicate what code to use in place of the deprecated code.
  DEPRECATED_MEMBER_USE_WITH_MESSAGE:
    sharedName: DEPRECATED_MEMBER_USE
    problemMessage: "'{0}' is deprecated and shouldn't be used. {1}."
    correctionMessage: Try replacing the use of the deprecated member with the replacement.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
      1: message details
  DEPRECATED_MEMBER_USE_FROM_SAME_PACKAGE:
    problemMessage: "'{0}' is deprecated and shouldn't be used."
    correctionMessage: Try replacing the use of the deprecated member with the replacement.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a deprecated library member or
      class member is used in the same package in which it's declared.

      #### Example

      The following code produces this diagnostic because `x` is deprecated:

      ```dart
      @deprecated
      var x = 0;
      var y = [!x!];
      ```

      #### Common fixes

      The fix depends on what's been deprecated and what the replacement is. The
      documentation for deprecated declarations should indicate what code to use
      in place of the deprecated code.
  DEPRECATED_MEMBER_USE_FROM_SAME_PACKAGE_WITH_MESSAGE:
    sharedName: DEPRECATED_MEMBER_USE_FROM_SAME_PACKAGE
    problemMessage: "'{0}' is deprecated and shouldn't be used. {1}."
    correctionMessage: Try replacing the use of the deprecated member with the replacement.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
      1: message details
  DEPRECATED_NEW_IN_COMMENT_REFERENCE:
    problemMessage: "Using the 'new' keyword in a comment reference is deprecated."
    correctionMessage: Try referring to a constructor by its name.
    comment: No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a comment reference (the name
      of a declaration enclosed in square brackets in a documentation comment)
      uses the keyword `new` to refer to a constructor. This form is deprecated.

      #### Examples

      The following code produces this diagnostic because the unnamed
      constructor is being referenced using `new C`:

      ```dart
      /// See [[!new!] C].
      class C {
        C();
      }
      ```

      The following code produces this diagnostic because the constructor named
      `c` is being referenced using `new C.c`:

      ```dart
      /// See [[!new!] C.c].
      class C {
        C.c();
      }
      ```

      #### Common fixes

      If you're referencing a named constructor, then remove the keyword `new`:

      ```dart
      /// See [C.c].
      class C {
        C.c();
      }
      ```

      If you're referencing the unnamed constructor, then remove the keyword
      `new` and append `.new` after the class name:

      ```dart
      /// See [C.new].
      class C {
        C.c();
      }
      ```
  DEPRECATED_MIXIN_FUNCTION:
    sharedName: DEPRECATED_SUBTYPE_OF_FUNCTION
    problemMessage: "Mixing in 'Function' is deprecated."
    correctionMessage: "Try removing 'Function' from the 'with' clause."
    hasPublishedDocs: true
    comment: No parameters.
  DEPRECATED_IMPLEMENTS_FUNCTION:
    sharedName: DEPRECATED_SUBTYPE_OF_FUNCTION
    problemMessage: "Implementing 'Function' has no effect."
    correctionMessage: "Try removing 'Function' from the 'implements' clause."
    hasPublishedDocs: true
    comment: No parameters.
  DEPRECATED_EXTENDS_FUNCTION:
    sharedName: DEPRECATED_SUBTYPE_OF_FUNCTION
    problemMessage: "Extending 'Function' is deprecated."
    correctionMessage: "Try removing 'Function' from the 'extends' clause."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the class `Function` is used in
      either the `extends`, `implements`, or `with` clause of a class or mixin.
      Using the class `Function` in this way has no semantic value, so it's
      effectively dead code.

      #### Example

      The following code produces this diagnostic because `Function` is used as
      the superclass of `F`:

      ```dart
      class F extends [!Function!] {}
      ```

      #### Common fixes

      Remove the class `Function` from whichever clause it's in, and remove the
      whole clause if `Function` is the only type in the clause:

      ```dart
      class F {}
      ```
  DIVISION_OPTIMIZATION:
    problemMessage: The operator x ~/ y is more efficient than (x / y).toInt().
    correctionMessage: "Try re-writing the expression to use the '~/' operator."
    comment: Hint to use the ~/ operator.
  DUPLICATE_HIDDEN_NAME:
    problemMessage: Duplicate hidden name.
    correctionMessage: Try removing the repeated name from the list of hidden members.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name occurs multiple times in
      a `hide` clause. Repeating the name is unnecessary.

      #### Example

      The following code produces this diagnostic because the name `min` is
      hidden more than once:

      ```dart
      import 'dart:math' hide min, [!min!];

      var x = pi;
      ```

      #### Common fixes

      If the name was mistyped in one or more places, then correct the mistyped
      names:

      ```dart
      import 'dart:math' hide max, min;

      var x = pi;
      ```

      If the name wasn't mistyped, then remove the unnecessary name from the
      list:

      ```dart
      import 'dart:math' hide min;

      var x = pi;
      ```
  DUPLICATE_IGNORE:
    problemMessage: "The diagnostic '{0}' doesn't need to be ignored here because it's already being ignored."
    correctionMessage: Try removing the name from the list, or removing the whole comment if this is the only name in the list.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the diagnostic being ignored
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a diagnostic name appears in an
      `ignore` comment, but the diagnostic is already being ignored, either
      because it's already included in the same `ignore` comment or because it
      appears in an `ignore-in-file` comment.

      #### Examples

      The following code produces this diagnostic because the diagnostic named
      `unused_local_variable` is already being ignored for the whole file so it
      doesn't need to be ignored on a specific line:

      ```dart
      // ignore_for_file: unused_local_variable
      void f() {
        // ignore: [!unused_local_variable!]
        var x = 0;
      }
      ```

      The following code produces this diagnostic because the diagnostic named
      `unused_local_variable` is being ignored twice on the same line:

      ```dart
      void f() {
        // ignore: unused_local_variable, [!unused_local_variable!]
        var x = 0;
      }
      ```

      #### Common fixes

      Remove the ignore comment, or remove the unnecessary diagnostic name if the
      ignore comment is ignoring more than one diagnostic:

      ```dart
      // ignore_for_file: unused_local_variable
      void f() {
        var x = 0;
      }
      ```
  DUPLICATE_IMPORT:
    problemMessage: Duplicate import.
    correctionMessage: Try removing all but one import of the library.
    hasPublishedDocs: true
    comment: |-
      Duplicate imports.

      No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import directive is found
      that is the same as an import before it in the file. The second import
      doesn’t add value and should be removed.

      #### Example

      The following code produces this diagnostic:

      ```dart
      import 'package:meta/meta.dart';
      import [!'package:meta/meta.dart'!];

      @sealed class C {}
      ```

      #### Common fixes

      Remove the unnecessary import:

      ```dart
      import 'package:meta/meta.dart';

      @sealed class C {}
      ```
  DUPLICATE_SHOWN_NAME:
    problemMessage: Duplicate shown name.
    correctionMessage: Try removing the repeated name from the list of shown members.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a name occurs multiple times in
      a `show` clause. Repeating the name is unnecessary.

      #### Example

      The following code produces this diagnostic because the name `min` is shown
      more than once:

      ```dart
      import 'dart:math' show min, [!min!];

      var x = min(2, min(0, 1));
      ```

      #### Common fixes

      If the name was mistyped in one or more places, then correct the mistyped
      names:

      ```dart
      import 'dart:math' show max, min;

      var x = max(2, min(0, 1));
      ```

      If the name wasn't mistyped, then remove the unnecessary name from the
      list:

      ```dart
      import 'dart:math' show min;

      var x = min(2, min(0, 1));
      ```
  EQUAL_ELEMENTS_IN_SET:
    problemMessage: "Two elements in a set literal shouldn't be equal."
    correctionMessage: Change or remove the duplicate element.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an element in a non-constant set
      is the same as a previous element in the same set. If two elements are the
      same, then the second value is ignored, which makes having both elements
      pointless and likely signals a bug.

      #### Example

      The following code produces this diagnostic because the element `1` appears
      twice:

      ```dart
      const a = 1;
      const b = 1;
      var s = <int>{a, [!b!]};
      ```

      #### Common fixes

      If both elements should be included in the set, then change one of the
      elements:

      ```dart
      const a = 1;
      const b = 2;
      var s = <int>{a, b};
      ```

      If only one of the elements is needed, then remove the one that isn't
      needed:

      ```dart
      const a = 1;
      var s = <int>{a};
      ```

      Note that literal sets preserve the order of their elements, so the choice
      of which element to remove might affect the order in which elements are
      returned by an iterator.
  EQUAL_KEYS_IN_MAP:
    problemMessage: "Two keys in a map literal shouldn't be equal."
    correctionMessage: Change or remove the duplicate key.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a key in a non-constant map is
      the same as a previous key in the same map. If two keys are the same, then
      the second value overwrites the first value, which makes having both pairs
      pointless and likely signals a bug.

      #### Example

      The following code produces this diagnostic because the keys `a` and `b`
      have the same value:

      ```dart
      const a = 1;
      const b = 1;
      var m = <int, String>{a: 'a', [!b!]: 'b'};
      ```

      #### Common fixes

      If both entries should be included in the map, then change one of the keys:

      ```dart
      const a = 1;
      const b = 2;
      var m = <int, String>{a: 'a', b: 'b'};
      ```

      If only one of the entries is needed, then remove the one that isn't
      needed:

      ```dart
      const a = 1;
      var m = <int, String>{a: 'a'};
      ```

      Note that literal maps preserve the order of their entries, so the choice
      of which entry to remove might affect the order in which the keys and
      values are returned by an iterator.
  FILE_IMPORT_INSIDE_LIB_REFERENCES_FILE_OUTSIDE:
    problemMessage: "A file in the 'lib' directory shouldn't import a file outside the 'lib' directory."
    correctionMessage: "Try removing the import, or moving the imported file inside the 'lib' directory."
    comment: |-
      It is a bad practice for a source file in a package "lib" directory
      hierarchy to traverse outside that directory hierarchy. For example, a
      source file in the "lib" directory should not contain a directive such as
      `import '../web/some.dart'` which references a file outside the lib
      directory.
  FILE_IMPORT_OUTSIDE_LIB_REFERENCES_FILE_INSIDE:
    problemMessage: "A file outside the 'lib' directory shouldn't reference a file inside the 'lib' directory using a relative path."
    correctionMessage: "Try using a package: URI instead."
    comment: |-
      It is a bad practice for a source file ouside a package "lib" directory
      hierarchy to traverse into that directory hierarchy. For example, a source
      file in the "web" directory should not contain a directive such as
      `import '../lib/some.dart'` which references a file inside the lib
      directory.
  IMPORT_DEFERRED_LIBRARY_WITH_LOAD_FUNCTION:
    problemMessage: "The imported library defines a top-level function named 'loadLibrary' that is hidden by deferring this library."
    correctionMessage: Try changing the import to not be deferred, or rename the function in the imported library.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library that declares a
      function named `loadLibrary` is imported using a deferred import. A
      deferred import introduces an implicit function named `loadLibrary`. This
      function is used to load the contents of the deferred library, and the
      implicit function hides the explicit declaration in the deferred library.

      For more information, see the language tour's coverage of
      [deferred loading](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).

      #### Example

      Given a file (`a.dart`) that defines a function named `loadLibrary`:

      ```dart
      %uri="lib/a.dart"
      void loadLibrary(Library library) {}

      class Library {}
      ```

      The following code produces this diagnostic because the implicit
      declaration of `a.loadLibrary` is hiding the explicit declaration of
      `loadLibrary` in `a.dart`:

      ```dart
      [!import 'a.dart' deferred as a;!]

      void f() {
        a.Library();
      }
      ```

      #### Common fixes

      If the imported library isn't required to be deferred, then remove the
      keyword `deferred`:

      ```dart
      import 'a.dart' as a;

      void f() {
        a.Library();
      }
      ```

      If the imported library is required to be deferred and you need to
      reference the imported function, then rename the function in the imported
      library:

      ```dart
      void populateLibrary(Library library) {}

      class Library {}
      ```

      If the imported library is required to be deferred and you don't need to
      reference the imported function, then add a `hide` clause:

      ```dart
      import 'a.dart' deferred as a hide loadLibrary;

      void f() {
        a.Library();
      }
      ```

      If type arguments shouldn't be required for the class, then mark the class
      with the `[optionalTypeArgs][meta-optionalTypeArgs]` annotation (from
      `package:meta`):
  IMPORT_OF_LEGACY_LIBRARY_INTO_NULL_SAFE:
    problemMessage: "The library '{0}' is legacy, and shouldn't be imported into a null safe library."
    correctionMessage: Try migrating the imported library.
    comment: |-
      No parameters.

      https://github.com/dart-lang/sdk/issues/44063
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a library that is null safe
      imports a library that isn't null safe.

      #### Example

      Given a file named `a.dart` that contains the following:

      ```dart
      %uri="lib/a.dart"
      // @dart = 2.9

      class A {}
      ```

      The following code produces this diagnostic because a library that null
      safe is importing a library that isn't null safe:

      ```dart
      import [!'a.dart'!];

      A? f() => null;
      ```

      #### Common fixes

      If you can migrate the imported library to be null safe, then migrate it
      and update or remove the migrated library's language version.

      If you can't migrate the imported library, then the importing library
      needs to have a language version that is before 2.12, when null safety was
      enabled by default.
  INFERENCE_FAILURE_ON_COLLECTION_LITERAL:
    problemMessage: "The type argument(s) of '{0}' can't be inferred."
    correctionMessage: "Use explicit type argument(s) for '{0}'."
    comment: |-
      When "strict-inference" is enabled, collection literal types must be
      inferred via the context type, or have type arguments.
  INFERENCE_FAILURE_ON_FUNCTION_INVOCATION:
    problemMessage: "The type argument(s) of the function '{0}' can't be inferred."
    correctionMessage: "Use explicit type argument(s) for '{0}'."
    comment: |-
      When "strict-inference" is enabled, types in function invocations must be
      inferred via the context type, or have type arguments.
  INFERENCE_FAILURE_ON_FUNCTION_RETURN_TYPE:
    problemMessage: "The return type of '{0}' cannot be inferred."
    correctionMessage: "Declare the return type of '{0}'."
    comment: |-
      When "strict-inference" is enabled, recursive local functions, top-level
      functions, methods, and function-typed function parameters must all
      specify a return type. See the strict-inference resource:

      https://github.com/dart-lang/language/blob/master/resources/type-system/strict-inference.md
  INFERENCE_FAILURE_ON_GENERIC_INVOCATION:
    problemMessage: "The type argument(s) of the generic function type '{0}' can't be inferred."
    correctionMessage: "Use explicit type argument(s) for '{0}'."
    comment: |-
      When "strict-inference" is enabled, types in function invocations must be
      inferred via the context type, or have type arguments.
  INFERENCE_FAILURE_ON_INSTANCE_CREATION:
    problemMessage: "The type argument(s) of the constructor '{0}' can't be inferred."
    correctionMessage: "Use explicit type argument(s) for '{0}'."
    comment: |-
      When "strict-inference" is enabled, types in instance creation
      (constructor calls) must be inferred via the context type, or have type
      arguments.
  INFERENCE_FAILURE_ON_UNINITIALIZED_VARIABLE:
    problemMessage: "The type of {0} can't be inferred without either a type or initializer."
    correctionMessage: Try specifying the type of the variable.
    comment: |-
      When "strict-inference" in enabled, uninitialized variables must be
      declared with a specific type.
  INFERENCE_FAILURE_ON_UNTYPED_PARAMETER:
    problemMessage: "The type of {0} can't be inferred; a type must be explicitly provided."
    correctionMessage: Try specifying the type of the parameter.
    comment: |-
      When "strict-inference" in enabled, function parameters must be
      declared with a specific type, or inherit a type.
  INVALID_ANNOTATION_TARGET:
    problemMessage: "The annotation '{0}' can only be used on {1}."
    comment: |-
      Parameters:
      0: the name of the annotation
      1: the list of valid targets
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an annotation is applied to a
      kind of declaration that it doesn't support.

      #### Example

      The following code produces this diagnostic because the `optionalTypeArgs`
      annotation isn't defined to be valid for top-level variables:

      ```dart
      import 'package:meta/meta.dart';

      @[!optionalTypeArgs!]
      int x = 0;
      ```

      #### Common fixes

      Remove the annotation from the declaration.
  INVALID_EXPORT_OF_INTERNAL_ELEMENT:
    problemMessage: "The member '{0}' can't be exported as a part of a package's public API."
    correctionMessage: "Try using a hide clause to hide '{0}'."
    comment: |-
      Parameters:
      0: the name of the element
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a [public library][] exports a
      declaration that is marked with the `[internal][meta-internal]`
      annotation.

      #### Example

      Given a file named `a.dart` in the `src` directory that contains:

      ```dart
      %uri="lib/src/a.dart"
      import 'package:meta/meta.dart';

      @internal class One {}
      ```

      The following code, when found in a [public library][] produces this
      diagnostic because the `export` directive is exporting a name that is only
      intended to be used internally:

      ```dart
      [!export 'src/a.dart';!]
      ```

      #### Common fixes

      If the export is needed, then add a `hide` clause to hide the internal
      names:

      ```dart
      export 'src/a.dart' hide One;
      ```

      If the export isn't needed, then remove it.
  INVALID_EXPORT_OF_INTERNAL_ELEMENT_INDIRECTLY:
    problemMessage: "The member '{0}' can't be exported as a part of a package's public API, but is indirectly exported as part of the signature of '{1}'."
    correctionMessage: "Try using a hide clause to hide '{0}'."
    comment: |-
      Parameters:
      0: the name of the element
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a [public library][] exports a
      top-level function  with a return type or at least one parameter type that
      is marked with the `[internal][meta-internal]` annotation.

      #### Example

      Given a file named `a.dart` in the `src` directory that contains the
      following:

      ```dart
      %uri="lib/src/a.dart"
      import 'package:meta/meta.dart';

      @internal
      typedef IntFunction = int Function();

      int f(IntFunction g) => g();
      ```

      The following code produces this diagnostic because the function `f` has a
      parameter of type `IntFunction`, and `IntFunction` is only intended to be
      used internally:

      ```dart
      [!export 'src/a.dart' show f;!]
      ```

      #### Common fixes

      If the function must be public, then make all the types in the function's
      signature public types.

      If the function doesn't need to be exported, then stop exporting it,
      either by removing it from the `show` clause, adding it to the `hide`
      clause, or by removing the export.
  INVALID_FACTORY_ANNOTATION:
    problemMessage: Only methods can be annotated as factories.
    comment: |-
      This hint is generated anywhere a @factory annotation is associated with
      anything other than a method.
  INVALID_FACTORY_METHOD_DECL:
    problemMessage: "Factory method '{0}' must have a return type."
    comment: |-
      Parameters:
      0: The name of the method
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method that is annotated with
      the `[factory][meta-factory]` annotation has a return type of `void`.

      #### Example

      The following code produces this diagnostic because the method `createC`
      is annotated with the `[factory][meta-factory]` annotation but doesn't
      return any value:

      ```dart
      import 'package:meta/meta.dart';

      class Factory {
        @factory
        void [!createC!]() {}
      }

      class C {}
      ```

      #### Common fixes

      Change the return type to something other than `void`:

      ```dart
      import 'package:meta/meta.dart';

      class Factory {
        @factory
        C createC() => C();
      }

      class C {}
      ```
  INVALID_FACTORY_METHOD_IMPL:
    problemMessage: "Factory method '{0}' doesn't return a newly allocated object."
    comment: |-
      Parameters:
      0: the name of the method
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method that is annotated with
      the `[factory][meta-factory]` annotation doesn't return a newly allocated
      object.

      #### Example

      The following code produces this diagnostic because the method `createC`
      returns the value of a field rather than a newly created instance of `C`:

      ```dart
      import 'package:meta/meta.dart';

      class Factory {
        C c = C();

        @factory
        C [!createC!]() => c;
      }

      class C {}
      ```

      #### Common fixes

      Change the method to return a newly created instance of the return type:

      ```dart
      import 'package:meta/meta.dart';

      class Factory {
        @factory
        C createC() => C();
      }

      class C {}
      ```
  INVALID_IMMUTABLE_ANNOTATION:
    problemMessage: Only classes can be annotated as being immutable.
    comment: |-
      This hint is generated anywhere an @immutable annotation is associated with
      anything other than a class.
  INVALID_INTERNAL_ANNOTATION:
    problemMessage: "Only public elements in a package's private API can be annotated as being internal."
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a declaration is annotated with
      the `[internal][meta-internal]` annotation and that declaration is either
      in a [public library][] or has a private name.

      #### Example

      The following code, when in a [public library][], produces this diagnostic
      because the `[internal][meta-internal]` annotation can't be applied to
      declarations in a [public library][]:

      ```dart
      import 'package:meta/meta.dart';

      [!@internal!]
      class C {}
      ```

      The following code, whether in a public or internal library, produces this
      diagnostic because the `[internal][meta-internal]` annotation can't be
      applied to declarations with private names:

      ```dart
      import 'package:meta/meta.dart';

      [!@internal!]
      class _C {}
      
      void f(_C c) {}
      ```

      #### Common fixes

      If the declaration has a private name, then remove the annotation:

      ```dart
      class _C {}

      void f(_C c) {}
      ```

      If the declaration has a public name and is intended to be internal to the
      package, then move the annotated declaration into an internal library (in
      other words, a library inside the `src` directory).

      Otherwise, remove the use of the annotation:

      ```dart
      class C {}
      ```
  INVALID_LANGUAGE_VERSION_OVERRIDE_GREATER:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The language version override can't specify a version greater than the latest known language version: {0}.{1}."
    correctionMessage: Try removing the language version override.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_AT_SIGN:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override number must begin with '@dart'."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a comment that appears to be an
      attempt to specify a language version override doesn't conform to the
      requirements for such a comment. For more information, see
      [Per-library language version selection](https://dart.dev/guides/language/evolution#per-library-language-version-selection).

      #### Example

      The following code produces this diagnostic because the word `dart` must
      be lowercase in such a comment and because there's no equal sign between
      the word `dart` and the version number:

      ```dart
      [!// @Dart 2.9!]
      ```

      #### Common fixes

      If the comment is intended to be a language version override, then change
      the comment to follow the correct format:

      ```dart
      // @dart = 2.9
      ```
  INVALID_LANGUAGE_VERSION_OVERRIDE_LOCATION:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: The language version override must be specified before any declaration or directive.
    correctionMessage: Try moving the language version override to the top of the file.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_LOWER_CASE:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override comment must be specified with the word 'dart' in all lower case."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_NUMBER:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override comment must be specified with a version number, like '2.0', after the '=' character."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_PREFIX:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override number can't be prefixed with a letter."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_TRAILING_CHARACTERS:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override comment can't be followed by any non-whitespace characters."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_TWO_SLASHES:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: The Dart language version override comment must be specified with exactly two slashes.
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LANGUAGE_VERSION_OVERRIDE_EQUALS:
    sharedName: INVALID_LANGUAGE_VERSION_OVERRIDE
    problemMessage: "The Dart language version override comment must be specified with an '=' character."
    correctionMessage: "Specify a Dart language version override with a comment like '// @dart = 2.0'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
  INVALID_LITERAL_ANNOTATION:
    problemMessage: Only const constructors can have the `@literal` annotation.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the `[literal][[meta-literal]]`
      annotation is applied to anything other than a const constructor.

      #### Examples

      The following code produces this diagnostic because the constructor isn't
      a `const` constructor:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        [!@literal!]
        C();
      }
      ```

      The following code produces this diagnostic because `x` isn't a
      constructor:

      ```dart
      import 'package:meta/meta.dart';

      [!@literal!]
      var x;
      ```

      #### Common fixes

      If the annotation is on a constructor and the constructor should always be
      invoked with `const`, when possible, then mark the constructor with the
      `const` keyword:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @literal
        const C();
      }
      ```

      If the constructor can't be marked as `const`, then remove the annotation.

      If the annotation is on anything other than a constructor, then remove the
      annotation:

      ```dart
      var x;
      ```
  INVALID_NON_VIRTUAL_ANNOTATION:
    problemMessage: "The annotation '@nonVirtual' can only be applied to a concrete instance member."
    correctionMessage: Try removing @nonVirtual.
    comment: |-
      This hint is generated anywhere where `@nonVirtual` annotates something
      other than a non-abstract instance member in a class or mixin.

      No Parameters.
  INVALID_OVERRIDE_OF_NON_VIRTUAL_MEMBER:
    problemMessage: "The member '{0}' is declared non-virtual in '{1}' and can't be overridden in subclasses."
    comment: |-
      This hint is generated anywhere where an instance member annotated with
      `@nonVirtual` is overridden in a subclass.

      Parameters:
      0: the name of the member
      1: the name of the defining class
  INVALID_REQUIRED_NAMED_PARAM:
    problemMessage: "The type parameter '{0}' is annotated with @required but only named parameters without a default value can be annotated with it."
    correctionMessage: Remove @required.
    comment: |-
      This hint is generated anywhere where `@required` annotates a named
      parameter with a default value.

      Parameters:
      0: the name of the member
  INVALID_REQUIRED_OPTIONAL_POSITIONAL_PARAM:
    problemMessage: "Incorrect use of the annotation @required on the optional positional parameter '{0}'. Optional positional parameters cannot be required."
    correctionMessage: Remove @required.
    comment: |-
      This hint is generated anywhere where `@required` annotates an optional
      positional parameter.

      Parameters:
      0: the name of the member
  INVALID_REQUIRED_POSITIONAL_PARAM:
    problemMessage: "Redundant use of the annotation @required on the required positional parameter '{0}'."
    correctionMessage: Remove @required.
    comment: |-
      This hint is generated anywhere where `@required` annotates a non optional
      positional parameter.

      Parameters:
      0: the name of the member
  RETURN_TYPE_INVALID_FOR_CATCH_ERROR:
    sharedName: INVALID_RETURN_TYPE_FOR_CATCH_ERROR
    problemMessage: "The return type '{0}' isn't assignable to '{1}', as required by 'Future.catchError'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type of the function
      1: the expected return type as defined by the type of the Future
  RETURN_OF_INVALID_TYPE_FROM_CATCH_ERROR:
    sharedName: INVALID_RETURN_TYPE_FOR_CATCH_ERROR
    problemMessage: "A value of type '{0}' can't be returned by the 'onError' handler because it must be assignable to '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the return type as declared in the return statement
      1: the expected return type as defined by the type of the Future
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an invocation of
      `Future.catchError` has an argument whose return type isn't compatible with
      the type returned by the instance of `Future`. At runtime, the method
      `catchError` attempts to return the value from the callback as the result
      of the future, which results in another exception being thrown.

      #### Examples

      The following code produces this diagnostic because `future` is declared to
      return an `int` while `callback` is declared to return a `String`, and
      `String` isn't a subtype of `int`:

      ```dart
      void f(Future<int> future, String Function(dynamic, StackTrace) callback) {
        future.catchError([!callback!]);
      }
      ```

      The following code produces this diagnostic because the closure being
      passed to `catchError` returns an `int` while `future` is declared to
      return a `String`:

      ```dart
      void f(Future<String> future) {
        future.catchError((error, stackTrace) => [!3!]);
      }
      ```

      #### Common fixes

      If the instance of `Future` is declared correctly, then change the callback
      to match:

      ```dart
      void f(Future<int> future, int Function(dynamic, StackTrace) callback) {
        future.catchError(callback);
      }
      ```

      If the declaration of the instance of `Future` is wrong, then change it to
      match the callback:

      ```dart
      void f(Future<String> future, String Function(dynamic, StackTrace) callback) {
        future.catchError(callback);
      }
      ```
  INVALID_SEALED_ANNOTATION:
    problemMessage: "The annotation '@sealed' can only be applied to classes."
    correctionMessage: Remove @sealed.
    comment: |-
      This hint is generated anywhere where `@sealed` annotates something other
      than a class.

      No parameters.
  INVALID_USE_OF_INTERNAL_MEMBER:
    problemMessage: "The member '{0}' can only be used within its package."
    comment: |-
      Parameters:
      0: the name of the member
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a reference to a declaration
      that is annotated with the `[internal][meta-internal]` annotation is found
      outside the package containing the declaration.

      #### Example

      Given a package `p` that defines a library containing a declaration marked
      with the `[internal][meta-internal]` annotation:

      ```dart
      %uri="package:p/src/p.dart"
      import 'package:meta/meta.dart';

      @internal
      class C {}
      ```

      The following code produces this diagnostic because it's referencing the
      class `C`, which isn't intended to be used outside the package `p`:

      ```dart
      import 'package:p/src/p.dart';

      void f([!C!] c) {}
      ```

      #### Common fixes

      Remove the reference to the internal declaration.
  INVALID_USE_OF_PROTECTED_MEMBER:
    problemMessage: "The member '{0}' can only be used within instance members of subclasses of '{1}'."
    comment: |-
      This hint is generated anywhere where a member annotated with `@protected`
      is used outside of an instance member of a subclass.

      Parameters:
      0: the name of the member
      1: the name of the defining class
  INVALID_USE_OF_VISIBLE_FOR_OVERRIDING_MEMBER:
    problemMessage: "The member '{0}' can only be used for overriding."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an instance member that is
      annotated with `[visibleForOverriding][meta-visibleForOverriding]` is
      referenced outside the library in which it's declared for any reason other
      than to override it.

      #### Example

      Given a file named `a.dart` containing the following declaration:

      ```dart
      %uri="lib/a.dart"
      import 'package:meta/meta.dart';

      class A {
        @visibleForOverriding
        void a() {}
      }
      ```

      The following code produces this diagnostic because the method `m` is being
      invoked even though the only reason it's public is to allow it to be
      overridden:

      ```dart
      import 'a.dart';

      class B extends A {
        void b() {
          [!a!]();
        }
      }
      ```

      #### Common fixes

      Remove the invalid use of the member.
  INVALID_USE_OF_VISIBLE_FOR_TEMPLATE_MEMBER:
    problemMessage: "The member '{0}' can only be used within '{1}' or a template library."
    comment: |-
      This hint is generated anywhere where a member annotated with
      `@visibleForTemplate` is used outside of a "template" Dart file.

      Parameters:
      0: the name of the member
      1: the name of the defining class
  INVALID_USE_OF_VISIBLE_FOR_TESTING_MEMBER:
    problemMessage: "The member '{0}' can only be used within '{1}' or a test."
    comment: |-
      This hint is generated anywhere where a member annotated with
      `@visibleForTesting` is used outside the defining library, or a test.

      Parameters:
      0: the name of the member
      1: the name of the defining class
  INVALID_VISIBILITY_ANNOTATION:
    problemMessage: "The member '{0}' is annotated with '{1}', but this annotation is only meaningful on declarations of public members."
    hasPublishedDocs: true
    comment: |-
      This hint is generated anywhere where a private declaration is annotated
      with `@visibleForTemplate` or `@visibleForTesting`.

      Parameters:
      0: the name of the member
      1: the name of the annotation
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when either the `visibleForTemplate`
      or `[visibleForTesting][meta-visibleForTesting]` annotation is applied to
      a non-public declaration.

      #### Example

      The following code produces this diagnostic:

      ```dart
      import 'package:meta/meta.dart';

      [!@visibleForTesting!]
      void _someFunction() {}

      void f() => _someFunction();
      ```

      #### Common fixes

      If the declaration doesn't need to be used by test code, then remove the
      annotation:

      ```dart
      void _someFunction() {}

      void f() => _someFunction();
      ```

      If it does, then make it public:

      ```dart
      import 'package:meta/meta.dart';

      @visibleForTesting
      void someFunction() {}

      void f() => someFunction();
      ```
  INVALID_VISIBLE_FOR_OVERRIDING_ANNOTATION:
    problemMessage: "The annotation 'visibleForOverriding' can only be applied to a public instance member that can be overridden."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when anything other than a public
      instance member of a class is annotated with
      `[visibleForOverriding][meta-visibleForOverriding]`. Because only public
      instance members can be overridden outside the defining library, there's
      no value to annotating any other declarations.

      #### Example

      The following code produces this diagnostic because the annotation is on a
      class, and classes can't be overridden:

      ```dart
      import 'package:meta/meta.dart';

      [!@visibleForOverriding!]
      class C {}
      ```

      #### Common fixes

      Remove the annotation:

      ```dart
      class C {}
      ```
  MISSING_REQUIRED_PARAM:
    problemMessage: "The parameter '{0}' is required."
    hasPublishedDocs: true
    comment: |-
      Generate a hint for a constructor, function or method invocation where a
      required parameter is missing.

      Parameters:
      0: the name of the parameter
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method or function with a
      named parameter that is annotated as being required is invoked without
      providing a value for the parameter.

      #### Example

      The following code produces this diagnostic because the named parameter `x`
      is required:

      ```dart
      %language=2.9
      import 'package:meta/meta.dart';

      void f({@required int x}) {}

      void g() {
        [!f!]();
      }
      ```

      #### Common fixes

      Provide the required value:

      ```dart
      %language=2.9
      import 'package:meta/meta.dart';

      void f({@required int x}) {}

      void g() {
        f(x: 2);
      }
      ```
  MISSING_REQUIRED_PARAM_WITH_DETAILS:
    sharedName: MISSING_REQUIRED_PARAM
    problemMessage: "The parameter '{0}' is required. {1}."
    hasPublishedDocs: true
    comment: |-
      Generate a hint for a constructor, function or method invocation where a
      required parameter is missing.

      Parameters:
      0: the name of the parameter
      1: message details
  MISSING_RETURN:
    problemMessage: "This function has a return type of '{0}', but doesn't end with a return statement."
    correctionMessage: "Try adding a return statement, or changing the return type to 'void'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the declared return type
    documentation: |-
      #### Description

      Any function or method that doesn't end with either an explicit return or a
      throw implicitly returns `null`. This is rarely the desired behavior. The
      analyzer produces this diagnostic when it finds an implicit return.

      #### Example

      The following code produces this diagnostic because `f` doesn't end with a
      return:

      ```dart
      %language=2.9
      int [!f!](int x) {
        if (x < 0) {
          return 0;
        }
      }
      ```

      #### Common fixes

      Add a `return` statement that makes the return value explicit, even if
      `null` is the appropriate value.
  MIXIN_ON_SEALED_CLASS:
    problemMessage: "The class '{0}' shouldn't be used as a mixin constraint because it is sealed, and any class mixing in this mixin must have '{0}' as a superclass."
    correctionMessage: Try composing with this class, or refer to its documentation for more information.
    hasPublishedDocs: true
    comment: |-
      This hint is generated anywhere where a `@sealed` class is used as a
      a superclass constraint of a mixin.

      Parameters:
      0: the name of the sealed class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the superclass constraint of a
      mixin is a class from a different package that was marked as
      `[sealed][meta-sealed]`. Classes that are sealed can't be extended,
      implemented, mixed in, or used as a superclass constraint.

      #### Example

      If the package `p` defines a sealed class:

      ```dart
      %uri="package:p/p.dart"
      import 'package:meta/meta.dart';

      @sealed
      class C {}
      ```

      Then, the following code, when in a package other than `p`, produces this
      diagnostic:

      ```dart
      import 'package:p/p.dart';

      [!mixin M on C {}!]
      ```

      #### Common fixes

      If the classes that use the mixin don't need to be subclasses of the sealed
      class, then consider adding a field and delegating to the wrapped instance
      of the sealed class.
  MUST_BE_IMMUTABLE:
    problemMessage: "This class (or a class that this class inherits from) is marked as '@immutable', but one or more of its instance fields aren't final: {0}"
    hasPublishedDocs: true
    comment: |-
      Generate a hint for classes that inherit from classes annotated with
      `@immutable` but that are not immutable.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an immutable class defines one
      or more instance fields that aren't final. A class is immutable if it's
      marked as being immutable using the annotation
      `[immutable][meta-immutable]` or if it's a subclass of an immutable class.

      #### Example

      The following code produces this diagnostic because the field `x` isn't
      final:

      ```dart
      import 'package:meta/meta.dart';

      @immutable
      class [!C!] {
        int x;

        C(this.x);
      }
      ```

      #### Common fixes

      If instances of the class should be immutable, then add the keyword `final`
      to all non-final field declarations:

      ```dart
      import 'package:meta/meta.dart';

      @immutable
      class C {
        final int x;

        C(this.x);
      }
      ```

      If the instances of the class should be mutable, then remove the
      annotation, or choose a different superclass if the annotation is
      inherited:

      ```dart
      class C {
        int x;

        C(this.x);
      }
      ```
  MUST_CALL_SUPER:
    problemMessage: "This method overrides a method annotated as '@mustCallSuper' in '{0}', but doesn't invoke the overridden method."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the class declaring the overridden method
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a method that overrides a method
      that is annotated as `[mustCallSuper][meta-mustCallSuper]` doesn't invoke
      the overridden method as required.

      #### Example

      The following code produces this diagnostic because the method `m` in `B`
      doesn't invoke the overridden method `m` in `A`:

      ```dart
      import 'package:meta/meta.dart';

      class A {
        @mustCallSuper
        m() {}
      }

      class B extends A {
        @override
        [!m!]() {}
      }
      ```

      #### Common fixes

      Add an invocation of the overridden method in the overriding method:

      ```dart
      import 'package:meta/meta.dart';

      class A {
        @mustCallSuper
        m() {}
      }

      class B extends A {
        @override
        m() {
          super.m();
        }
      }
      ```
  NON_CONST_CALL_TO_LITERAL_CONSTRUCTOR_USING_NEW:
    sharedName: NON_CONST_CALL_TO_LITERAL_CONSTRUCTOR
    problemMessage: "This instance creation must be 'const', because the {0} constructor is marked as '@literal'."
    correctionMessage: "Try replacing the 'new' keyword with 'const'."
    hasPublishedDocs: true
    comment: |-
      Generate a hint for non-const instance creation (with the `new` keyword)
      using a constructor annotated with `@literal`.

      Parameters:
      0: the name of the class defining the annotated constructor
  NON_CONST_CALL_TO_LITERAL_CONSTRUCTOR:
    problemMessage: "This instance creation must be 'const', because the {0} constructor is marked as '@literal'."
    correctionMessage: "Try adding a 'const' keyword."
    hasPublishedDocs: true
    comment: |-
      Generate a hint for non-const instance creation using a constructor
      annotated with `@literal`.

      Parameters:
      0: the name of the class defining the annotated constructor
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor that has the
      `[literal][meta-literal]` annotation is invoked without using the `const`
      keyword, but all of the arguments to the constructor are constants. The
      annotation indicates that the constructor should be used to create a
      constant value whenever possible.

      #### Example

      The following code produces this diagnostic:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @literal
        const C();
      }

      C f() => [!C()!];
      ```

      #### Common fixes

      Add the keyword `const` before the constructor invocation:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @literal
        const C();
      }

      void f() => const C();
      ```
  NULLABLE_TYPE_IN_CATCH_CLAUSE:
    problemMessage: "A potentially nullable type can't be used in an 'on' clause because it isn't valid to throw a nullable expression."
    correctionMessage: Try using a non-nullable type.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the type following `on` in a
      `catch` clause is a nullable type. It isn't valid to specify a nullable
      type because it isn't possible to catch `null` (because it's a runtime
      error to throw `null`).

      #### Example

      The following code produces this diagnostic because the exception type is
      specified to allow `null` when `null` can't be thrown:

      ```dart
      void f() {
        try {
          // ...
        } on [!FormatException?!] {
        }
      }
      ```

      #### Common fixes

      Remove the question mark from the type:

      ```dart
      void f() {
        try {
          // ...
        } on FormatException {
        }
      }
      ```
  NULL_ARGUMENT_TO_NON_NULL_TYPE:
    problemMessage: "'{0}' shouldn't be called with a null argument for the non-nullable type argument '{1}'."
    correctionMessage: Try adding a non-null argument.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the method being invoked
      1: the type argument associated with the method
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when `null` is passed to either the
      constructor `Future.value` or the method `Completer.complete` when the type
      argument used to create the instance was non-nullable. Even though the type
      system can't express this restriction, passing in a `null` results in a
      runtime exception.

      #### Example

      The following code produces this diagnostic because `null` is being passed
      to the constructor `Future.value` even though the type argument is the
      non-nullable type `String`:

      ```dart
      Future<String> f() {
        return Future.value([!null!]);
      }
      ```

      #### Common fixes

      Pass in a non-null value:

      ```dart
      Future<String> f() {
        return Future.value('');
      }
      ```
  NULL_AWARE_BEFORE_OPERATOR:
    problemMessage: "The left operand uses '?.', so its value can be null."
    comment: |-
      When the left operand of a binary expression uses '?.' operator, it can be
      `null`.
  NULL_AWARE_IN_CONDITION:
    problemMessage: "The value of the '?.' operator can be 'null', which isn't appropriate in a condition."
    correctionMessage: "Try replacing the '?.' with a '.', testing the left-hand side for null if necessary."
    comment: |-
      A condition in a control flow statement could evaluate to `null` because it
      uses the null-aware '?.' operator.
  NULL_AWARE_IN_LOGICAL_OPERATOR:
    problemMessage: "The value of the '?.' operator can be 'null', which isn't appropriate as an operand of a logical operator."
    comment: |-
      A condition in operands of a logical operator could evaluate to `null`
      because it uses the null-aware '?.' operator.
  NULL_CHECK_ALWAYS_FAILS:
    problemMessage: "This null-check will always throw an exception because the expression will always evaluate to 'null'."
    comment: |-
      No parameters.
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the null check operator (`!`)
      is used on an expression whose value can only be `null`. In such a case
      the operator always throws an exception, which likely isn't the intended
      behavior.

      #### Example

      The following code produces this diagnostic because the function `g` will
      always return `null`, which means that the null check in `f` will always
      throw:

      ```dart
      void f() {
        [!g()!!];
      }

      Null g() => null;
      ```

      #### Common fixes

      If you intend to always throw an exception, then replace the null check
      with an explicit `throw` expression to make the intent more clear:

      ```dart
      void f() {
        g();
        throw TypeError();
      }

      Null g() => null;
      ```
  OVERRIDE_ON_NON_OVERRIDING_FIELD:
    sharedName: OVERRIDE_ON_NON_OVERRIDING_MEMBER
    problemMessage: "The field doesn't override an inherited getter or setter."
    correctionMessage: Try updating this class to match the superclass, or removing the override annotation.
    hasPublishedDocs: true
    comment: |-
      A field with the override annotation does not override a getter or setter.

      No parameters.
  OVERRIDE_ON_NON_OVERRIDING_GETTER:
    sharedName: OVERRIDE_ON_NON_OVERRIDING_MEMBER
    problemMessage: "The getter doesn't override an inherited getter."
    correctionMessage: Try updating this class to match the superclass, or removing the override annotation.
    hasPublishedDocs: true
    comment: |-
      A getter with the override annotation does not override an existing getter.

      No parameters.
  OVERRIDE_ON_NON_OVERRIDING_METHOD:
    sharedName: OVERRIDE_ON_NON_OVERRIDING_MEMBER
    problemMessage: "The method doesn't override an inherited method."
    correctionMessage: Try updating this class to match the superclass, or removing the override annotation.
    hasPublishedDocs: true
    comment: |-
      A method with the override annotation does not override an existing method.

      No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a class member is annotated with
      the `@override` annotation, but the member isn’t declared in any of the
      supertypes of the class.

      #### Example

      The following code produces this diagnostic because `m` isn't declared in
      any of the supertypes of `C`:

      ```dart
      class C {
        @override
        String [!m!]() => '';
      }
      ```

      #### Common fixes

      If the member is intended to override a member with a different name, then
      update the member to have the same name:

      ```dart
      class C {
        @override
        String toString() => '';
      }
      ```

      If the member is intended to override a member that was removed from the
      superclass, then consider removing the member from the subclass.

      If the member can't be removed, then remove the annotation.
  OVERRIDE_ON_NON_OVERRIDING_SETTER:
    sharedName: OVERRIDE_ON_NON_OVERRIDING_MEMBER
    problemMessage: "The setter doesn't override an inherited setter."
    correctionMessage: Try updating this class to match the superclass, or removing the override annotation.
    hasPublishedDocs: true
    comment: |-
      A setter with the override annotation does not override an existing setter.

      No parameters.
  PACKAGE_IMPORT_CONTAINS_DOT_DOT:
    problemMessage: "A package import shouldn't contain '..'."
    comment: |-
      It is a bad practice for a package import to reference anything outside the
      given package, or more generally, it is bad practice for a package import
      to contain a "..". For example, a source file should not contain a
      directive such as `import 'package:foo/../some.dart'`.
  RECEIVER_OF_TYPE_NEVER:
    problemMessage: "The receiver is of type 'Never', and will never complete with a value."
    correctionMessage: Try checking for throw expressions or type errors in the receiver
    comment: |-
      It is not an error to call or tear-off a method, setter, or getter, or to
      read or write a field, on a receiver of static type `Never`.
      Implementations that provide feedback about dead or unreachable code are
      encouraged to indicate that any arguments to the invocation are
      unreachable.

      It is not an error to apply an expression of type `Never` in the function
      position of a function call. Implementations that provide feedback about
      dead or unreachable code are encouraged to indicate that any arguments to
      the call are unreachable.

      Parameters: none
  RETURN_OF_DO_NOT_STORE:
    problemMessage: "'{0}' is annotated with 'doNotStore' and shouldn't be returned unless '{1}' is also annotated."
    correctionMessage: "Annotate '{1}' with 'doNotStore'."
    comment: |-
      Parameters:
      0: the name of the annotated function being invoked
      1: the name of the function containing the return
    hasPublishedDocs: true
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a value that is annotated with
      the `[doNotStore][meta-doNotStore]` annotation is returned from a method,
      getter, or function that doesn't have the same annotation.

      #### Example

      The following code produces this diagnostic because the result of invoking
      `f` shouldn't be stored, but the function `g` isn't annotated to preserve
      that semantic:

      ```dart
      import 'package:meta/meta.dart';

      @doNotStore
      int f() => 0;

      int g() => [!f()!];
      ```

      #### Common fixes

      If the value that shouldn't be stored is the correct value to return, then
      mark the function with the `[doNotStore][meta-doNotStore]` annotation:

      ```dart
      import 'package:meta/meta.dart';

      @doNotStore
      int f() => 0;

      @doNotStore
      int g() => f();
      ```

      Otherwise, return a different value from the function:

      ```dart
      import 'package:meta/meta.dart';

      @doNotStore
      int f() => 0;

      int g() => 0;
      ```
  SDK_VERSION_ASYNC_EXPORTED_FROM_CORE:
    problemMessage: "The class '{0}' wasn't exported from 'dart:core' until version 2.1, but this code is required to be able to run on earlier versions."
    correctionMessage: "Try either importing 'dart:async' or updating the SDK constraints."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when either the class `Future` or
      `Stream` is referenced in a library that doesn't import `dart:async` in
      code that has an SDK constraint whose lower bound is less than 2.1.0. In
      earlier versions, these classes weren't defined in `dart:core`, so the
      import was necessary.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.1.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.0.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      void f([!Future!] f) {}
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the classes to be referenced:

      ```yaml
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      If you need to support older versions of the SDK, then import the
      `dart:async` library.

      ```dart
      import 'dart:async';

      void f(Future f) {}
      ```
  SDK_VERSION_AS_EXPRESSION_IN_CONST_CONTEXT:
    problemMessage: "The use of an as expression in a constant expression wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an `as` expression inside a
      [constant context][] is found in code that has an SDK constraint whose
      lower bound is less than 2.3.2. Using an `as` expression in a
      [constant context][] wasn't supported in earlier versions, so this code
      won't be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.3.2:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces
      this diagnostic:

      ```dart
      const num n = 3;
      const int i = [!n as int!];
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the expression to be used:

      ```yaml
      environment:
        sdk: '>=2.3.2 <2.4.0'
      ```

      If you need to support older versions of the SDK, then either rewrite the
      code to not use an `as` expression, or change the code so that the `as`
      expression isn't in a [constant context][]:

      ```dart
      num x = 3;
      int y = x as int;
      ```
  SDK_VERSION_BOOL_OPERATOR_IN_CONST_CONTEXT:
    problemMessage: "The use of the operator '{0}' for 'bool' operands in a constant context wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when any use of the `&`, `|`, or `^`
      operators on the class `bool` inside a [constant context][] is found in
      code that has an SDK constraint whose lower bound is less than 2.3.2. Using
      these operators in a [constant context][] wasn't supported in earlier
      versions, so this code won't be able to run against earlier versions of the
      SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.3.2:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      const bool a = true;
      const bool b = false;
      const bool c = a [!&!] b;
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the operators to be used:

      ```yaml
      environment:
       sdk: '>=2.3.2 <2.4.0'
      ```

      If you need to support older versions of the SDK, then either rewrite the
      code to not use these operators, or change the code so that the expression
      isn't in a [constant context][]:

      ```dart
      const bool a = true;
      const bool b = false;
      bool c = a & b;
      ```
  SDK_VERSION_CONSTRUCTOR_TEAROFFS:
    problemMessage: "Tearing off a constructor requires the 'constructor-tearoffs' language feature."
    correctionMessage: "Try updating your pubspec.yaml to set the minimum SDK constraint to 2.15 or higher, and running 'pub get'."
    hasPublishedDocs: true
    comment: |-
      No parameters.

      There is also a [ParserError.EXPERIMENT_NOT_ENABLED] code which catches
      some cases of constructor tearoff features (like `List<int>.filled;`).
      Other constructor tearoff cases are not realized until resolution
      (like `List.filled;`).
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a constructor tear-off is found
      in code that has an SDK constraint whose lower bound is less than 2.15.
      Constructor tear-offs weren't supported in earlier versions, so this code
      won't be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.15:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.9.0 <2.15.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      %language=2.14
      var setConstructor = [!Set.identity!];
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the operator to be used:

      ```yaml
      environment:
        sdk: '>=2.15.0 <2.16.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not use constructor tear-offs:

      ```dart
      %language=2.14
      var setConstructor = () => Set.identity();
      ```
  SDK_VERSION_EQ_EQ_OPERATOR_IN_CONST_CONTEXT:
    problemMessage: "Using the operator '==' for non-primitive types wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the operator `==` is used on a
      non-primitive type inside a [constant context][] is found in code that has
      an SDK constraint whose lower bound is less than 2.3.2. Using this operator
      in a [constant context][] wasn't supported in earlier versions, so this
      code won't be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.3.2:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      %language=2.9
      class C {}
      const C a = null;
      const C b = null;
      const bool same = a [!==!] b;
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the operator to be used:

      ```yaml
      environment:
        sdk: '>=2.3.2 <2.4.0'
      ```

      If you need to support older versions of the SDK, then either rewrite the
      code to not use the `==` operator, or change the code so that the
      expression isn't in a [constant context][]:

      ```dart
      %language=2.9
      class C {}
      const C a = null;
      const C b = null;
      bool same = a == b;
      ```
  SDK_VERSION_EXTENSION_METHODS:
    problemMessage: "Extension methods weren't supported until version 2.6.0, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an extension declaration or an
      extension override is found in code that has an SDK constraint whose lower
      bound is less than 2.6.0. Using extensions wasn't supported in earlier
      versions, so this code won't be able to run against earlier versions of the
      SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.6.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
       sdk: '>=2.4.0 <2.7.0'
      ```

      In the package that has that pubspec, code like the following produces
      this diagnostic:

      ```dart
      [!extension!] E on String {
        void sayHello() {
          print('Hello $this');
        }
      }
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the syntax to be used:

      ```yaml
      environment:
        sdk: '>=2.6.0 <2.7.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not make use of extensions. The most common way to do this is to rewrite
      the members of the extension as top-level functions (or methods) that take
      the value that would have been bound to `this` as a parameter:

      ```dart
      void sayHello(String s) {
        print('Hello $s');
      }
      ```
  SDK_VERSION_GT_GT_GT_OPERATOR:
    problemMessage: "The operator '>>>' wasn't supported until version 2.14.0, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the operator `>>>` is used in
      code that has an SDK constraint whose lower bound is less than 2.14.0. This
      operator wasn't supported in earlier versions, so this code won't be able
      to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.14.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
       sdk: '>=2.0.0 <2.15.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      int x = 3 [!>>>!] 4;
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the operator to be used:

      ```yaml
      environment:
        sdk: '>=2.14.0 <2.15.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not use the `>>>` operator:

      ```dart
      int x = logicalShiftRight(3, 4);

      int logicalShiftRight(int leftOperand, int rightOperand) {
        int divisor = 1 << rightOperand;
        if (divisor == 0) {
          return 0;
        }
        return leftOperand ~/ divisor;
      }
      ```
  SDK_VERSION_IS_EXPRESSION_IN_CONST_CONTEXT:
    problemMessage: "The use of an is expression in a constant context wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an `is` expression inside a
      [constant context][] is found in code that has an SDK constraint whose
      lower bound is less than 2.3.2. Using an `is` expression in a
      [constant context][] wasn't supported in earlier versions, so this code
      won't be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.3.2:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces
      this diagnostic:

      ```dart
      const Object x = 4;
      const y = [!x is int!] ? 0 : 1;
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the expression to be used:

      ```yaml
      environment:
        sdk: '>=2.3.2 <2.4.0'
      ```

      If you need to support older versions of the SDK, then either rewrite the
      code to not use the `is` operator, or, if that isn't possible, change the
      code so that the `is` expression isn't in a
      [constant context][]:

      ```dart
      const Object x = 4;
      var y = x is int ? 0 : 1;
      ```
  SDK_VERSION_NEVER:
    problemMessage: "The type 'Never' wasn't supported until version 2.12.0, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a reference to the class `Never`
      is found in code that has an SDK constraint whose lower bound is less than
      2.12.0. This class wasn't defined in earlier versions, so this code won't
      be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.12.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.5.0 <2.6.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      %language=2.9
      [!Never!] n;
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the type to be used:

      ```yaml
      environment:
        sdk: '>=2.12.0 <2.13.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not reference this class:

      ```dart
      dynamic x;
      ```
  SDK_VERSION_SET_LITERAL:
    problemMessage: "Set literals weren't supported until version 2.2, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a set literal is found in code
      that has an SDK constraint whose lower bound is less than 2.2.0. Set
      literals weren't supported in earlier versions, so this code won't be able
      to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.2.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.1.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces this
      diagnostic:

      ```dart
      var s = [!<int>{}!];
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the syntax to be used:

      ```yaml
      environment:
        sdk: '>=2.2.0 <2.4.0'
      ```

      If you do need to support older versions of the SDK, then replace the set
      literal with code that creates the set without the use of a literal:

      ```dart
      var s = new Set<int>();
      ```
  SDK_VERSION_UI_AS_CODE:
    problemMessage: "The for, if, and spread elements weren't supported until version 2.3.0, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a for, if, or spread element is
      found in code that has an SDK constraint whose lower bound is less than
      2.3.0. Using a for, if, or spread element wasn't supported in earlier
      versions, so this code won't be able to run against earlier versions of the
      SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.3.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.2.0 <2.4.0'
      ```

      In the package that has that pubspec, code like the following produces
      this diagnostic:

      ```dart
      var digits = [[!for (int i = 0; i < 10; i++) i!]];
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the syntax to be used:

      ```yaml
      environment:
        sdk: '>=2.3.0 <2.4.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not make use of those elements:

      ```dart
      var digits = _initializeDigits();

      List<int> _initializeDigits() {
        var digits = <int>[];
        for (int i = 0; i < 10; i++) {
          digits.add(i);
        }
        return digits;
      }
      ```
  SDK_VERSION_UI_AS_CODE_IN_CONST_CONTEXT:
    problemMessage: "The if and spread elements weren't supported in constant expressions until version 2.5.0, but this code is required to be able to run on earlier versions."
    correctionMessage: Try updating the SDK constraints.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an if or spread element inside
      a [constant context][] is found in code that has an SDK constraint whose
      lower bound is less than 2.5.0. Using an if or spread element inside a
      [constant context][] wasn't supported in earlier versions, so this code
      won't be able to run against earlier versions of the SDK.

      #### Example

      Here's an example of a pubspec that defines an SDK constraint with a lower
      bound of less than 2.5.0:

      ```yaml
      %uri="pubspec.yaml"
      environment:
        sdk: '>=2.4.0 <2.6.0'
      ```

      In the package that has that pubspec, code like the following produces
      this diagnostic:

      ```dart
      const a = [1, 2];
      const b = [[!...a!]];
      ```

      #### Common fixes

      If you don't need to support older versions of the SDK, then you can
      increase the SDK constraint to allow the syntax to be used:

      ```yaml
      environment:
        sdk: '>=2.5.0 <2.6.0'
      ```

      If you need to support older versions of the SDK, then rewrite the code to
      not make use of those elements:

      ```dart
      const a = [1, 2];
      const b = [1, 2];
      ```

      If that isn't possible, change the code so that the element isn't in a
      [constant context][]:

      ```dart
      const a = [1, 2];
      var b = [...a];
      ```
  STRICT_RAW_TYPE:
    problemMessage: "The generic type '{0}' should have explicit type arguments but doesn't."
    correctionMessage: "Use explicit type arguments for '{0}'."
    comment: |-
      When "strict-raw-types" is enabled, "raw types" must have type arguments.

      A "raw type" is a type name that does not use inference to fill in missing
      type arguments; instead, each type argument is instantiated to its bound.
  SUBTYPE_OF_SEALED_CLASS:
    problemMessage: "The class '{0}' shouldn't be extended, mixed in, or implemented because it's sealed."
    correctionMessage: "Try composing instead of inheriting, or refer to the documentation of '{0}' for more information."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the sealed class
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a sealed class (one that either
      has the `[sealed][meta-sealed]` annotation or inherits or mixes in a
      sealed class) is referenced in either the `extends`, `implements`, or
      `with` clause of a class or mixin declaration if the declaration isn't in
      the same package as the sealed class.

      #### Example

      Given a library in a package other than the package being analyzed that
      contains the following:

      ```dart
      %uri="package:a/a.dart"
      import 'package:meta/meta.dart';

      class A {}

      @sealed
      class B {}
      ```

      The following code produces this diagnostic because `C`, which isn't in the
      same package as `B`, is extending the sealed class `B`:

      ```dart
      import 'package:a/a.dart';

      [!class C extends B {}!]
      ```

      #### Common fixes

      If the class doesn't need to be a subtype of the sealed class, then change
      the declaration so that it isn't:

      ```dart
      import 'package:a/a.dart';

      class B extends A {}
      ```

      If the class needs to be a subtype of the sealed class, then either change
      the sealed class so that it's no longer sealed or move the subclass into
      the same package as the sealed class.
  TEXT_DIRECTION_CODE_POINT_IN_COMMENT:
    problemMessage: The Unicode code point 'U+{0}' changes the appearance of text from how it's interpreted by the compiler.
    correctionMessage: Try removing the code point or using the Unicode escape sequence '\u{0}'.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the unicode sequence of the code point.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters source that
      contains text direction Unicode code points. These code points cause
      source code in either a string literal or a comment to be interpreted
      and compiled differently than how it appears in editors, leading to
      possible security vulnerabilities.

      #### Example

      The following code produces this diagnostic twice because there are
      hidden characters at the start and end of the label string:

      ```dart
      var label = '[!I!]nteractive text[!'!];
      ```

      #### Common fixes

      If the code points are intended to be included in the string literal,
      then escape them:

      ```dart
      var label = '\u202AInteractive text\u202C';
      ```

      If the code points aren't intended to be included in the string literal,
      then remove them:

      ```dart
      var label = 'Interactive text';
      ```
  TEXT_DIRECTION_CODE_POINT_IN_LITERAL:
    problemMessage: The Unicode code point 'U+{0}' changes the appearance of text from how it's interpreted by the compiler.
    correctionMessage: Try removing the code point or using the Unicode escape sequence '\u{0}'.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the unicode sequence of the code point.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it encounters source that
      contains text direction Unicode code points. These code points cause
      source code in either a string literal or a comment to be interpreted
      and compiled differently than how it appears in editors, leading to
      possible security vulnerabilities.

      #### Example

      The following code produces this diagnostic twice because there are
      hidden characters at the start and end of the label string:

      ```dart
      var label = '[!I!]nteractive text[!'!];
      ```

      #### Common fixes

      If the code points are intended to be included in the string literal,
      then escape them:

      ```dart
      var label = '\u202AInteractive text\u202C';
      ```

      If the code points aren't intended to be included in the string literal,
      then remove them:

      ```dart
      var label = 'Interactive text';
      ```
  TYPE_CHECK_IS_NOT_NULL:
    sharedName: TYPE_CHECK_WITH_NULL
    problemMessage: "Tests for non-null should be done with '!= null'."
    correctionMessage: "Try replacing the 'is! Null' check with '!= null'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's a type check (using the
      `as` operator) where the type is `Null`. There's only one value whose type
      is `Null`, so the code is both more readable and more performant when it
      tests for `null` explicitly.

      #### Examples

      The following code produces this diagnostic because the code is testing to
      see whether the value of `s` is `null` by using a type check:

      ```dart
      void f(String? s) {
        if ([!s is Null!]) {
          return;
        }
        print(s);
      }
      ```

      The following code produces this diagnostic because the code is testing to
      see whether the value of `s` is something other than `null` by using a type
      check:

      ```dart
      void f(String? s) {
        if ([!s is! Null!]) {
          print(s);
        }
      }
      ```

      #### Common fixes

      Replace the type check with the equivalent comparison with `null`:

      ```dart
      void f(String? s) {
        if (s == null) {
          return;
        }
        print(s);
      }
      ```
  TYPE_CHECK_IS_NULL:
    sharedName: TYPE_CHECK_WITH_NULL
    problemMessage: "Tests for null should be done with '== null'."
    correctionMessage: "Try replacing the 'is Null' check with '== null'."
    hasPublishedDocs: true
    comment: No parameters.
  UNDEFINED_HIDDEN_NAME:
    problemMessage: "The library '{0}' doesn't export a member with the hidden name '{1}'."
    correctionMessage: Try removing the name from the list of hidden members.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the library being imported
      1: the name in the hide clause that isn't defined in the library
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a hide combinator includes a
      name that isn't defined by the library being imported.

      #### Example

      The following code produces this diagnostic because `dart:math` doesn't
      define the name `String`:

      ```dart
      import 'dart:math' hide [!String!], max;

      var x = min(0, 1);
      ```

      #### Common fixes

      If a different name should be hidden, then correct the name. Otherwise,
      remove the name from the list:

      ```dart
      import 'dart:math' hide max;

      var x = min(0, 1);
      ```
  UNDEFINED_REFERENCED_PARAMETER:
    problemMessage: "The parameter '{0}' isn't defined by '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the undefined parameter
      1: the name of the targeted member
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an annotation of the form
      `[UseResult][meta-UseResult].unless(parameterDefined: parameterName)`
      specifies a parameter name that isn't defined by the annotated function.

      #### Example

      The following code produces this diagnostic because the function `f`
      doesn't have a parameter named `b`:

      ```dart
      import 'package:meta/meta.dart';

      @UseResult.unless(parameterDefined: [!'b'!])
      int f([int? a]) => a ?? 0;
      ```

      #### Common fixes

      Change the argument named `parameterDefined` to match the name of one of
      the parameters to the function:

      ```dart
      import 'package:meta/meta.dart';

      @UseResult.unless(parameterDefined: 'a')
      int f([int? a]) => a ?? 0;
      ```
  UNDEFINED_SHOWN_NAME:
    problemMessage: "The library '{0}' doesn't export a member with the shown name '{1}'."
    correctionMessage: Try removing the name from the list of shown members.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the library being imported
      1: the name in the show clause that isn't defined in the library
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a show combinator includes a
      name that isn't defined by the library being imported.

      #### Example

      The following code produces this diagnostic because `dart:math` doesn't
      define the name `String`:

      ```dart
      import 'dart:math' show min, [!String!];

      var x = min(0, 1);
      ```

      #### Common fixes

      If a different name should be shown, then correct the name. Otherwise,
      remove the name from the list:

      ```dart
      import 'dart:math' show min;

      var x = min(0, 1);
      ```
  UNIGNORABLE_IGNORE:
    problemMessage: "The diagnostic '{0}' can't be ignored."
    correctionMessage: Try removing the name from the list, or removing the whole comment if this is the only name in the list.
    comment: |-
      Parameters:
      0: the name of the non-diagnostic being ignored
  UNNECESSARY_CAST:
    problemMessage: Unnecessary cast.
    correctionMessage: Try removing the cast.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value being cast is already
      known to be of the type that it's being cast to.

      #### Example

      The following code produces this diagnostic because `n` is already known to
      be an `int` as a result of the `is` test:

      ```dart
      void f(num n) {
        if (n is int) {
          ([!n as int!]).isEven;
        }
      }
      ```

      #### Common fixes

      Remove the unnecessary cast:

      ```dart
      void f(num n) {
        if (n is int) {
          n.isEven;
        }
      }
      ```
  UNNECESSARY_IGNORE:
    problemMessage: "The diagnostic '{0}' isn't produced at this location so it doesn't need to be ignored."
    correctionMessage: Try removing the name from the list, or removing the whole comment if this is the only name in the list.
    comment: |-
      Parameters:
      0: the name of the diagnostic being ignored
  UNNECESSARY_IMPORT:
    problemMessage: "The import of '{0}' is unnecessary because all of the used elements are also provided by the import of '{1}'."
    correctionMessage: Try removing the import directive.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the uri that is not necessary
      1: the uri that makes it unnecessary
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import isn't needed because
      all of the names that are imported and referenced within the importing
      library are also visible through another import.

      #### Example

      Given a file named `a.dart` that contains the following:

      ```dart
      %uri="lib/a.dart"
      class A {}
      ```

      And, given a file named `b.dart` that contains the following:

      ```dart
      %uri="lib/b.dart"
      export 'a.dart';

      class B {}
      ```

      The following code produces this diagnostic because the class `A`, which is
      imported from `a.dart`, is also imported from `b.dart`. Removing the import
      of `a.dart` leaves the semantics unchanged:

      ```dart
      import [!'a.dart'!];
      import 'b.dart';

      void f(A a, B b) {}
      ```

      #### Common fixes

      If the import isn't needed, then remove it.

      If some of the names imported by this import are intended to be used but
      aren't yet, and if those names aren't imported by other imports, then add
      the missing references to those names.
  UNNECESSARY_NO_SUCH_METHOD:
    problemMessage: "Unnecessary 'noSuchMethod' declaration."
    correctionMessage: "Try removing the declaration of 'noSuchMethod'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's a declaration of
      `noSuchMethod`, the only thing the declaration does is invoke the
      overridden declaration, and the overridden declaration isn't the
      declaration in `Object`.

      Overriding the implementation of `Object`'s `noSuchMethod` (no matter what
      the implementation does) signals to the analyzer that it shouldn't flag any
      inherited abstract methods that aren't implemented in that class. This
      works even if the overriding implementation is inherited from a superclass,
      so there's no value to declare it again in a subclass.

      #### Example

      The following code produces this diagnostic because the declaration of
      `noSuchMethod` in `A` makes the declaration of `noSuchMethod` in `B`
      unnecessary:

      ```dart
      class A {
        @override
        dynamic noSuchMethod(x) => super.noSuchMethod(x);
      }
      class B extends A {
        @override
        dynamic [!noSuchMethod!](y) {
          return super.noSuchMethod(y);
        }
      }
      ```

      #### Common fixes

      Remove the unnecessary declaration:

      ```dart
      class A {
        @override
        dynamic noSuchMethod(x) => super.noSuchMethod(x);
      }
      class B extends A {}
      ```
  UNNECESSARY_NULL_COMPARISON_FALSE:
    sharedName: UNNECESSARY_NULL_COMPARISON
    problemMessage: "The operand can't be null, so the condition is always false."
    correctionMessage: Try removing the condition, an enclosing condition, or the whole conditional statement.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when it finds an equality comparison
      (either `==` or `!=`) with one operand of `null` and the other operand
      can't be `null`. Such comparisons are always either `true` or `false`, so
      they serve no purpose.

      #### Examples

      The following code produces this diagnostic because `x` can never be
      `null`, so the comparison always evaluates to `true`:

      ```dart
      void f(int x) {
        if (x [!!= null!]) {
          print(x);
        }
      }
      ```

      The following code produces this diagnostic because `x` can never be
      `null`, so the comparison always evaluates to `false`:

      ```dart
      void f(int x) {
        if (x [!== null!]) {
          throw ArgumentError("x can't be null");
        }
      }
      ```

      #### Common fixes

      If the other operand should be able to be `null`, then change the type of
      the operand:

      ```dart
      void f(int? x) {
        if (x != null) {
          print(x);
        }
      }
      ```

      If the other operand really can't be `null`, then remove the condition:

      ```dart
      void f(int x) {
        print(x);
      }
      ```
  UNNECESSARY_NULL_COMPARISON_TRUE:
    sharedName: UNNECESSARY_NULL_COMPARISON
    problemMessage: "The operand can't be null, so the condition is always true."
    correctionMessage: Remove the condition.
    hasPublishedDocs: true
    comment: No parameters.
  UNNECESSARY_QUESTION_MARK:
    problemMessage: "The '?' is unnecessary because '{0}' is nullable without it."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the type
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when either the type `dynamic` or the
      type `Null` is followed by a question mark. Both of these types are
      inherently nullable so the question mark doesn't change the semantics.

      #### Example

      The following code produces this diagnostic because the question mark
      following `dynamic` isn't necessary:

      ```dart
      dynamic[!?!] x;
      ```

      #### Common fixes

      Remove the unneeded question mark:

      ```dart
      dynamic x;
      ```
  UNNECESSARY_TYPE_CHECK_FALSE:
    sharedName: UNNECESSARY_TYPE_CHECK
    problemMessage: "Unnecessary type check; the result is always 'false'."
    correctionMessage: Try correcting the type check, or removing the type check.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of a type check (using
      either `is` or `is!`) is known at compile time.

      #### Example

      The following code produces this diagnostic because the test `a is Object?`
      is always `true`:

      ```dart
      bool f<T>(T a) => [!a is Object?!];
      ```

      #### Common fixes

      If the type check doesn't check what you intended to check, then change the
      test:

      ```dart
      bool f<T>(T a) => a is Object;
      ```

      If the type check does check what you intended to check, then replace the
      type check with its known value or completely remove it:

      ```dart
      bool f<T>(T a) => true;
      ```
  UNNECESSARY_TYPE_CHECK_TRUE:
    sharedName: UNNECESSARY_TYPE_CHECK
    problemMessage: "Unnecessary type check; the result is always 'true'."
    correctionMessage: Try correcting the type check, or removing the type check.
    hasPublishedDocs: true
    comment: No parameters.
  UNUSED_CATCH_CLAUSE:
    problemMessage: "The exception variable '{0}' isn't used, so the 'catch' clause can be removed."
    correctionMessage: Try removing the catch clause.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the exception variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `catch` clause is found, and
      neither the exception parameter nor the optional stack trace parameter are
      used in the `catch` block.

      #### Example

      The following code produces this diagnostic because `e` isn't referenced:

      ```dart
      void f() {
        try {
          int.parse(';');
        } on FormatException catch ([!e!]) {
          // ignored
        }
      }
      ```

      #### Common fixes

      Remove the unused `catch` clause:

      ```dart
      void f() {
        try {
          int.parse(';');
        } on FormatException {
          // ignored
        }
      }
      ```
  UNUSED_CATCH_STACK:
    problemMessage: "The stack trace variable '{0}' isn't used and can be removed."
    correctionMessage: Try removing the stack trace variable, or using it.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the stack trace variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the stack trace parameter in a
      `catch` clause isn't referenced within the body of the `catch` block.

      #### Example

      The following code produces this diagnostic because `stackTrace` isn't
      referenced:

      ```dart
      void f() {
        try {
          // ...
        } catch (exception, [!stackTrace!]) {
          // ...
        }
      }
      ```

      #### Common fixes

      If you need to reference the stack trace parameter, then add a reference to
      it. Otherwise, remove it:

      ```dart
      void f() {
        try {
          // ...
        } catch (exception) {
          // ...
        }
      }
      ```
  UNUSED_ELEMENT:
    problemMessage: "The declaration '{0}' isn't referenced."
    correctionMessage: "Try removing the declaration of '{0}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name that is declared but not referenced
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a private declaration isn't
      referenced in the library that contains the declaration. The following
      kinds of declarations are analyzed:
      - Private top-level declarations, such as classes, enums, mixins, typedefs,
        top-level variables, and top-level functions
      - Private static and instance methods
      - Optional parameters of private functions for which a value is never
        passed, even when the parameter doesn't have a private name

      #### Example

      Assuming that no code in the library references `_C`, the following code
      produces this diagnostic:

      ```dart
      class [!_C!] {}
      ```

      Assuming that no code in the library passes a value for `y` in any
      invocation of `_m`, the following code produces this diagnostic:

      ```dart
      %language=2.9
      class C {
        void _m(int x, [int [!y!]]) {}

        void n() => _m(0);
      }
      ```

      #### Common fixes

      If the declaration isn't needed, then remove it:

      ```dart
      class C {
        void _m(int x) {}

        void n() => _m(0);
      }
      ```

      If the declaration is intended to be used, then add the code to use it.
  UNUSED_ELEMENT_PARAMETER:
    sharedName: UNUSED_ELEMENT
    problemMessage: "A value for optional parameter '{0}' isn't ever given."
    correctionMessage: Try removing the unused parameter.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the parameter that is declared but not used
  UNUSED_FIELD:
    problemMessage: "The value of the field '{0}' isn't used."
    correctionMessage: Try removing the field, or using it.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the unused field
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a private field is declared but
      never read, even if it's written in one or more places.

      #### Example

      The following code produces this diagnostic because the field
      `_originalValue` isn't read anywhere in the library:

      ```dart
      class C {
        final String [!_originalValue!];
        final String _currentValue;

        C(this._originalValue) : _currentValue = _originalValue;

        String get value => _currentValue;
      }
      ```

      It might appear that the field `_originalValue` is being read in the
      initializer (`_currentValue = _originalValue`), but that is actually a
      reference to the parameter of the same name, not a reference to the field.

      #### Common fixes

      If the field isn't needed, then remove it.

      If the field was intended to be used, then add the missing code.
  UNUSED_IMPORT:
    problemMessage: "Unused import: '{0}'."
    correctionMessage: Try removing the import directive.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the content of the unused import's uri
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an import isn't needed because
      none of the names that are imported are referenced within the importing
      library.

      #### Example

      The following code produces this diagnostic because nothing defined in
      `dart:async` is referenced in the library:

      ```dart
      import [!'dart:async'!];

      void main() {}
      ```

      #### Common fixes

      If the import isn't needed, then remove it.

      If some of the imported names are intended to be used, then add the missing
      code.
  UNUSED_LABEL:
    problemMessage: "The label '{0}' isn't used."
    correctionMessage: "Try removing the label, or using it in either a 'break' or 'continue' statement."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the label that isn't used
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a label that isn't used is
      found.

      #### Example

      The following code produces this diagnostic because the label `loop` isn't
      referenced anywhere in the method:

      ```dart
      void f(int limit) {
        [!loop:!] for (int i = 0; i < limit; i++) {
          print(i);
        }
      }
      ```

      #### Common fixes

      If the label isn't needed, then remove it:

      ```dart
      void f(int limit) {
        for (int i = 0; i < limit; i++) {
          print(i);
        }
      }
      ```

      If the label is needed, then use it:

      ```dart
      void f(int limit) {
        loop: for (int i = 0; i < limit; i++) {
          print(i);
          break loop;
        }
      }
      ```
      TODO(brianwilkerson) Highlight the identifier without the colon.
  UNUSED_LOCAL_VARIABLE:
    problemMessage: "The value of the local variable '{0}' isn't used."
    correctionMessage: Try removing the variable or using it.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the unused variable
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a local variable is declared but
      never read, even if it's written in one or more places.

      #### Example

      The following code produces this diagnostic because the value of `count` is
      never read:

      ```dart
      void main() {
        int [!count!] = 0;
      }
      ```

      #### Common fixes

      If the variable isn't needed, then remove it.

      If the variable was intended to be used, then add the missing code.
  UNUSED_RESULT:
    problemMessage: "The value of '{0}' should be used."
    correctionMessage: Try using the result by invoking a member, passing it to a function, or returning it from this function.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the annotated method, property or function
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a function annotated with
      `[useResult][meta-useResult]` is invoked, and the value returned by that
      function isn't used. The value is considered to be used if a member of the
      value is invoked, if the value is passed to another function, or if the
      value is assigned to a variable or field.

      #### Example

      The following code produces this diagnostic because the invocation of
      `c.a()` isn't used, even though the method `a` is annotated with
      `[useResult][meta-useResult]`:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @useResult
        int a() => 0;

        int b() => 0;
      }

      void f(C c) {
        c.[!a!]();
      }
      ```

      #### Common fixes

      If you intended to invoke the annotated function, then use the value that
      was returned:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @useResult
        int a() => 0;

        int b() => 0;
      }

      void f(C c) {
        print(c.a());
      }
      ```

      If you intended to invoke a different function, then correct the name of
      the function being invoked:

      ```dart
      import 'package:meta/meta.dart';

      class C {
        @useResult
        int a() => 0;

        int b() => 0;
      }

      void f(C c) {
        c.b();
      }
      ```
  UNUSED_RESULT_WITH_MESSAGE:
    sharedName: UNUSED_RESULT
    problemMessage: "'{0}' should be used. {1}."
    correctionMessage: Try using the result by invoking a member, passing it to a function, or returning it from this function.
    hasPublishedDocs: true
    comment: |-
      The result of invoking a method, property, or function annotated with
      `@useResult` must be used (assigned, passed to a function as an argument,
      or returned by a function).

      Parameters:
      0: the name of the annotated method, property or function
      1: message details
  UNUSED_SHOWN_NAME:
    problemMessage: "The name {0} is shown, but isn’t used."
    correctionMessage: Try removing the name from the list of shown members.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name that is shown but not used
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a show combinator includes a
      name that isn't used within the library. Because it isn't referenced, the
      name can be removed.

      #### Example

      The following code produces this diagnostic because the function `max`
      isn't used:

      ```dart
      import 'dart:math' show min, [!max!];

      var x = min(0, 1);
      ```

      #### Common fixes

      Either use the name or remove it:

      ```dart
      import 'dart:math' show min;

      var x = min(0, 1);
      ```
LanguageCode:
  IMPLICIT_DYNAMIC_FIELD:
    problemMessage: "Missing field type for '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_FUNCTION:
    problemMessage: "Missing type arguments for generic function '{0}<{1}>'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_INVOKE:
    problemMessage: "Missing type arguments for calling generic function type '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_LIST_LITERAL:
    problemMessage: Missing type argument for list literal.
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_MAP_LITERAL:
    problemMessage: Missing type arguments for map literal.
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_METHOD:
    problemMessage: "Missing type arguments for generic method '{0}<{1}>'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_PARAMETER:
    problemMessage: "Missing parameter type for '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_RETURN:
    problemMessage: "Missing return type for '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_TYPE:
    problemMessage: "Missing type arguments for generic type '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
  IMPLICIT_DYNAMIC_VARIABLE:
    problemMessage: "Missing variable type for '{0}'."
    correctionMessage: Try adding an explicit type, or remove implicit-dynamic from your analysis options file.
ManifestWarningCode:
  CAMERA_PERMISSIONS_INCOMPATIBLE:
    problemMessage: Camera permissions make app incompatible for Chrome OS, consider adding optional features "android.hardware.camera" and "android.hardware.camera.autofocus".
    correctionMessage: "Try adding `<uses-feature android:name=\"android.hardware.camera\"  android:required=\"false\">` `<uses-feature android:name=\"android.hardware.camera.autofocus\"  android:required=\"false\">`."
    comment: |-
      A code indicating that the camera permissions is not supported on Chrome
      OS.
  NON_RESIZABLE_ACTIVITY:
    problemMessage: The `<activity>` element should be allowed to be resized to allow users to take advantage of the multi-window environment on Chrome OS
    correctionMessage: Consider declaring the corresponding activity element with `resizableActivity="true"` attribute.
    comment: A code indicating that the activity is set to be non resizable.
  NO_TOUCHSCREEN_FEATURE:
    problemMessage: "The default \"android.hardware.touchscreen\" needs to be optional for Chrome OS. "
    correctionMessage: "Consider adding <uses-feature android:name=\"android.hardware.touchscreen\" android:required=\"false\" /> to the manifest."
    comment: |-
      A code indicating that the touchscreen feature is not specified in the
      manifest.
  PERMISSION_IMPLIES_UNSUPPORTED_HARDWARE:
    problemMessage: "Permission makes app incompatible for Chrome OS, consider adding optional {0} feature tag, "
    correctionMessage: " Try adding `<uses-feature android:name=\"{0}\"  android:required=\"false\">`."
    comment: |-
      A code indicating that a specified permission is not supported on Chrome
      OS.
  SETTING_ORIENTATION_ON_ACTIVITY:
    problemMessage: The `<activity>` element should not be locked to any orientation so that users can take advantage of the multi-window environments and larger screens on Chrome OS
    correctionMessage: Consider declaring the corresponding activity element with `screenOrientation="unspecified"` or `"fullSensor"` attribute.
    comment: A code indicating that the activity is locked to an orientation.
  UNSUPPORTED_CHROME_OS_FEATURE:
    problemMessage: "The feature {0} isn't supported on Chrome OS, consider making it optional."
    correctionMessage: "Try changing to `android:required=\"false\"` for this feature."
    comment: A code indicating that a specified feature is not supported on Chrome OS.
  UNSUPPORTED_CHROME_OS_HARDWARE:
    problemMessage: "The feature {0} isn't supported on Chrome OS, consider making it optional."
    correctionMessage: "Try adding `android:required=\"false\"` for this feature."
    comment: |-
      A code indicating that a specified hardware feature is not supported on
      Chrome OS.
ParserErrorCode:
  ABSTRACT_ENUM:
    problemMessage: "Enums can't be declared to be 'abstract'."
    correctionMessage: "Try removing the keyword 'abstract'."
  ABSTRACT_STATIC_METHOD:
    problemMessage: "Static methods can't be declared to be 'abstract'."
    correctionMessage: "Try removing the keyword 'abstract'."
  ABSTRACT_TOP_LEVEL_FUNCTION:
    problemMessage: "Top-level functions can't be declared to be 'abstract'."
    correctionMessage: "Try removing the keyword 'abstract'."
  ABSTRACT_TOP_LEVEL_VARIABLE:
    problemMessage: "Top-level variables can't be declared to be 'abstract'."
    correctionMessage: "Try removing the keyword 'abstract'."
  ABSTRACT_TYPEDEF:
    problemMessage: "Typedefs can't be declared to be 'abstract'."
    correctionMessage: "Try removing the keyword 'abstract'."
  ASYNC_KEYWORD_USED_AS_IDENTIFIER:
    problemMessage: "The keywords 'await' and 'yield' can't be used as identifiers in an asynchronous or generator function."
    comment: |-
      16.32 Identifier Reference: It is a compile-time error if any of the
      identifiers async, await, or yield is used as an identifier in a function
      body marked with either async, async, or sync.
  CONST_CONSTRUCTOR_WITH_BODY:
    problemMessage: "Const constructors can't have a body."
    correctionMessage: "Try removing either the 'const' keyword or the body."
  CONST_ENUM:
    problemMessage: "Enums can't be declared to be 'const'."
    correctionMessage: "Try removing the 'const' keyword."
  CONST_TYPEDEF:
    problemMessage: "Type aliases can't be declared to be 'const'."
    correctionMessage: "Try removing the 'const' keyword."
  COVARIANT_CONSTRUCTOR:
    problemMessage: "A constructor can't be declared to be 'covariant'."
    correctionMessage: "Try removing the keyword 'covariant'."
  COVARIANT_TOP_LEVEL_DECLARATION:
    problemMessage: "Top-level declarations can't be declared to be covariant."
    correctionMessage: "Try removing the keyword 'covariant'."
  DEFAULT_VALUE_IN_FUNCTION_TYPE:
    problemMessage: "Parameters in a function type can't have default values."
    correctionMessage: Try removing the default value.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a function type associated with
      a parameter includes optional parameters that have a default value. This
      isn't allowed because the default values of parameters aren't part of the
      function's type, and therefore including them doesn't provide any value.

      #### Example

      The following code produces this diagnostic because the parameter `p` has a
      default value even though it's part of the type of the parameter `g`:

      ```dart
      void f(void Function([int p [!=!] 0]) g) {
      }
      ```

      #### Common fixes

      Remove the default value from the function-type's parameter:

      ```dart
      void f(void Function([int p]) g) {
      }
      ```
  EMPTY_ENUM_BODY:
    problemMessage: An enum must declare at least one constant name.
    correctionMessage: Try declaring a constant.
  EXPECTED_CASE_OR_DEFAULT:
    problemMessage: "Expected 'case' or 'default'."
    correctionMessage: Try placing this code inside a case clause.
  EXPECTED_CLASS_MEMBER:
    problemMessage: Expected a class member.
    correctionMessage: Try placing this code inside a class member.
  EXPECTED_EXECUTABLE:
    problemMessage: Expected a method, getter, setter or operator declaration.
    correctionMessage: This appears to be incomplete code. Try removing it or completing it.
  EXPECTED_LIST_OR_MAP_LITERAL:
    problemMessage: Expected a list or map literal.
    correctionMessage: Try inserting a list or map literal, or remove the type arguments.
  EXPECTED_STRING_LITERAL:
    problemMessage: Expected a string literal.
  EXPECTED_TOKEN:
    problemMessage: "Expected to find '{0}'."
    comment: |-
      Parameters:
      0: the token that was expected but not found
  EXPECTED_TYPE_NAME:
    problemMessage: Expected a type name.
  EXTERNAL_GETTER_WITH_BODY:
    problemMessage: "External getters can't have a body."
    correctionMessage: "Try removing the body of the getter, or removing the keyword 'external'."
  EXTERNAL_OPERATOR_WITH_BODY:
    problemMessage: "External operators can't have a body."
    correctionMessage: "Try removing the body of the operator, or removing the keyword 'external'."
  EXTERNAL_SETTER_WITH_BODY:
    problemMessage: "External setters can't have a body."
    correctionMessage: "Try removing the body of the setter, or removing the keyword 'external'."
  FACTORY_WITHOUT_BODY:
    problemMessage: "A non-redirecting 'factory' constructor must have a body."
    correctionMessage: Try adding a body to the constructor.
  FACTORY_WITH_INITIALIZERS:
    problemMessage: "A 'factory' constructor can't have initializers."
    correctionMessage: "Try removing the 'factory' keyword to make this a generative constructor, or removing the initializers."
  FINAL_CLASS:
    problemMessage: "Classes can't be declared to be 'final'."
    correctionMessage: "Try removing the keyword 'final'."
  FINAL_CONSTRUCTOR:
    problemMessage: "A constructor can't be declared to be 'final'."
    correctionMessage: "Try removing the keyword 'final'."
  FINAL_ENUM:
    problemMessage: "Enums can't be declared to be 'final'."
    correctionMessage: "Try removing the keyword 'final'."
  FINAL_METHOD:
    problemMessage: "Getters, setters and methods can't be declared to be 'final'."
    correctionMessage: "Try removing the keyword 'final'."
  FINAL_TYPEDEF:
    problemMessage: "Typedefs can't be declared to be 'final'."
    correctionMessage: "Try removing the keyword 'final'."
  GETTER_IN_FUNCTION:
    problemMessage: "Getters can't be defined within methods or functions."
    correctionMessage: Try moving the getter outside the method or function, or converting the getter to a function.
  GETTER_WITH_PARAMETERS:
    problemMessage: Getters must be declared without a parameter list.
    correctionMessage: "Try removing the parameter list, or removing the keyword 'get' to define a method rather than a getter."
  INVALID_CODE_POINT:
    problemMessage: "The escape sequence '{0}' isn't a valid code point."
    comment: |-
      Parameters:
      0: the invalid escape sequence
  INVALID_COMMENT_REFERENCE:
    problemMessage: "Comment references should contain a possibly prefixed identifier and can start with 'new', but shouldn't contain anything else."
  INVALID_GENERIC_FUNCTION_TYPE:
    problemMessage: Invalid generic function type.
    correctionMessage: "Try using a generic function type (returnType 'Function(' parameters ')')."
  INVALID_LITERAL_IN_CONFIGURATION:
    problemMessage: "The literal in a configuration can't contain interpolation."
    correctionMessage: Try removing the interpolation expressions.
  INVALID_OPERATOR_FOR_SUPER:
    problemMessage: "The operator '{0}' can't be used with 'super'."
    comment: |-
      Parameters:
      0: the operator being applied to 'super'

      Only generated by the old parser.
      Replaced by INVALID_OPERATOR_QUESTIONMARK_PERIOD_FOR_SUPER.
  INVALID_STAR_AFTER_ASYNC:
    problemMessage: "The modifier 'async*' isn't allowed for an expression function body."
    correctionMessage: Try converting the body to a block.
  INVALID_SYNC:
    problemMessage: "The modifier 'sync' isn't allowed for an expression function body."
    correctionMessage: Try converting the body to a block.
  LOCAL_FUNCTION_DECLARATION_MODIFIER:
    problemMessage: "Local function declarations can't specify any modifiers."
    correctionMessage: Try removing the modifier.
  MISSING_CLOSING_PARENTHESIS:
    problemMessage: The closing parenthesis is missing.
    correctionMessage: Try adding the closing parenthesis.
  MISSING_ENUM_BODY:
    problemMessage: An enum definition must have a body with at least one constant name.
    correctionMessage: Try adding a body and defining at least one constant.
  MISSING_EXPRESSION_IN_INITIALIZER:
    problemMessage: Expected an expression after the assignment operator.
    correctionMessage: Try adding the value to be assigned, or remove the assignment operator.
  MISSING_FUNCTION_BODY:
    problemMessage: A function body must be provided.
    correctionMessage: Try adding a function body.
  MISSING_FUNCTION_KEYWORD:
    problemMessage: "Function types must have the keyword 'Function' before the parameter list."
    correctionMessage: "Try adding the keyword 'Function'."
  MISSING_FUNCTION_PARAMETERS:
    problemMessage: Functions must have an explicit list of parameters.
    correctionMessage: Try adding a parameter list.
  MISSING_GET:
    problemMessage: "Getters must have the keyword 'get' before the getter name."
    correctionMessage: "Try adding the keyword 'get'."
  MISSING_IDENTIFIER:
    problemMessage: Expected an identifier.
  MISSING_METHOD_PARAMETERS:
    problemMessage: Methods must have an explicit list of parameters.
    correctionMessage: Try adding a parameter list.
  MISSING_NAME_FOR_NAMED_PARAMETER:
    problemMessage: Named parameters in a function type must have a name
    correctionMessage: Try providing a name for the parameter or removing the curly braces.
  MISSING_NAME_IN_LIBRARY_DIRECTIVE:
    problemMessage: Library directives must include a library name.
    correctionMessage: "Try adding a library name after the keyword 'library', or remove the library directive if the library doesn't have any parts."
  MISSING_NAME_IN_PART_OF_DIRECTIVE:
    problemMessage: Part-of directives must include a library name.
    correctionMessage: "Try adding a library name after the 'of'."
  MISSING_STAR_AFTER_SYNC:
    problemMessage: "The modifier 'sync' must be followed by a star ('*')."
    correctionMessage: Try removing the modifier, or add a star.
  MISSING_TERMINATOR_FOR_PARAMETER_GROUP:
    problemMessage: "There is no '{0}' to close the parameter group."
    correctionMessage: "Try inserting a '{0}' at the end of the group."
    comment: |-
      Parameters:
      0: the terminator that is missing
  MISSING_TYPEDEF_PARAMETERS:
    problemMessage: Typedefs must have an explicit list of parameters.
    correctionMessage: Try adding a parameter list.
  MISSING_VARIABLE_IN_FOR_EACH:
    problemMessage: "A loop variable must be declared in a for-each loop before the 'in', but none was found."
    correctionMessage: Try declaring a loop variable.
  MIXED_PARAMETER_GROUPS:
    problemMessage: "Can't have both positional and named parameters in a single parameter list."
    correctionMessage: Try choosing a single style of optional parameters.
  MULTIPLE_IMPLEMENTS_CLAUSES:
    problemMessage: Each class or mixin definition can have at most one implements clause.
    correctionMessage: Try combining all of the implements clauses into a single clause.
  MULTIPLE_NAMED_PARAMETER_GROUPS:
    problemMessage: "Can't have multiple groups of named parameters in a single parameter list."
    correctionMessage: Try combining all of the groups into a single group.
  MULTIPLE_POSITIONAL_PARAMETER_GROUPS:
    problemMessage: "Can't have multiple groups of positional parameters in a single parameter list."
    correctionMessage: Try combining all of the groups into a single group.
  MULTIPLE_VARIABLES_IN_FOR_EACH:
    problemMessage: "A single loop variable must be declared in a for-each loop before the 'in', but {0} were found."
    correctionMessage: Try moving all but one of the declarations inside the loop body.
    comment: |-
      Parameters:
      0: the number of variables being declared
  NAMED_FUNCTION_EXPRESSION:
    problemMessage: "Function expressions can't be named."
    correctionMessage: Try removing the name, or moving the function expression to a function declaration statement.
  NAMED_FUNCTION_TYPE:
    problemMessage: "Function types can't be named."
    correctionMessage: "Try replacing the name with the keyword 'Function'."
  NAMED_PARAMETER_OUTSIDE_GROUP:
    problemMessage: "Named parameters must be enclosed in curly braces ('{' and '}')."
    correctionMessage: Try surrounding the named parameters in curly braces.
  NATIVE_CLAUSE_IN_NON_SDK_CODE:
    problemMessage: Native clause can only be used in the SDK and code that is loaded through native extensions.
    correctionMessage: Try removing the native clause.
  NATIVE_FUNCTION_BODY_IN_NON_SDK_CODE:
    problemMessage: Native functions can only be declared in the SDK and code that is loaded through native extensions.
    correctionMessage: "Try removing the word 'native'."
  NON_CONSTRUCTOR_FACTORY:
    problemMessage: Only a constructor can be declared to be a factory.
    correctionMessage: "Try removing the keyword 'factory'."
  NON_IDENTIFIER_LIBRARY_NAME:
    problemMessage: The name of a library must be an identifier.
    correctionMessage: Try using an identifier as the name of the library.
  NON_PART_OF_DIRECTIVE_IN_PART:
    problemMessage: The part-of directive must be the only directive in a part.
    correctionMessage: Try removing the other directives, or moving them to the library for which this is a part.
  NON_STRING_LITERAL_AS_URI:
    problemMessage: The URI must be a string literal.
    correctionMessage: Try enclosing the URI in either single or double quotes.
  NON_USER_DEFINABLE_OPERATOR:
    problemMessage: "The operator '{0}' isn't user definable."
    comment: |-
      Parameters:
      0: the operator that the user is trying to define
  NORMAL_BEFORE_OPTIONAL_PARAMETERS:
    problemMessage: Normal parameters must occur before optional parameters.
    correctionMessage: Try moving all of the normal parameters before the optional parameters.
  POSITIONAL_AFTER_NAMED_ARGUMENT:
    problemMessage: Positional arguments must occur before named arguments.
    correctionMessage: Try moving all of the positional arguments before the named arguments.
  POSITIONAL_PARAMETER_OUTSIDE_GROUP:
    problemMessage: "Positional parameters must be enclosed in square brackets ('[' and ']')."
    correctionMessage: Try surrounding the positional parameters in square brackets.
  SETTER_IN_FUNCTION:
    problemMessage: "Setters can't be defined within methods or functions."
    correctionMessage: Try moving the setter outside the method or function.
  STATIC_GETTER_WITHOUT_BODY:
    problemMessage: "A 'static' getter must have a body."
    correctionMessage: "Try adding a body to the getter, or removing the keyword 'static'."
  STATIC_SETTER_WITHOUT_BODY:
    problemMessage: "A 'static' setter must have a body."
    correctionMessage: "Try adding a body to the setter, or removing the keyword 'static'."
  STATIC_TOP_LEVEL_DECLARATION:
    problemMessage: "Top-level declarations can't be declared to be static."
    correctionMessage: "Try removing the keyword 'static'."
  UNEXPECTED_TERMINATOR_FOR_PARAMETER_GROUP:
    problemMessage: "There is no '{0}' to open a parameter group."
    correctionMessage: "Try inserting the '{0}' at the appropriate location."
    comment: |-
      Parameters:
      0: the starting character that was missing
  UNEXPECTED_TOKEN:
    problemMessage: "Unexpected text '{0}'."
    correctionMessage: Try removing the text.
    comment: |-
      Parameters:
      0: the unexpected text that was found
  VAR_CLASS:
    problemMessage: "Classes can't be declared to be 'var'."
    correctionMessage: "Try removing the keyword 'var'."
  VAR_ENUM:
    problemMessage: "Enums can't be declared to be 'var'."
    correctionMessage: "Try removing the keyword 'var'."
  VAR_TYPEDEF:
    problemMessage: "Typedefs can't be declared to be 'var'."
    correctionMessage: "Try removing the keyword 'var', or replacing it with the name of the return type."
  WRONG_SEPARATOR_FOR_POSITIONAL_PARAMETER:
    problemMessage: "The default value of a positional parameter should be preceded by '='."
    correctionMessage: "Try replacing the ':' with '='."
  WRONG_TERMINATOR_FOR_PARAMETER_GROUP:
    problemMessage: "Expected '{0}' to close parameter group."
    correctionMessage: "Try replacing '{0}' with '{1}'."
    comment: |-
      Parameters:
      0: the terminator that was expected
      1: the terminator that was found
PubspecWarningCode:
  ASSET_DIRECTORY_DOES_NOT_EXIST:
    problemMessage: "The asset directory '{0}' doesn't exist."
    correctionMessage: Try creating the directory or fixing the path to the directory.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the path to the asset directory as given in the file.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an asset list contains a value
      referencing a directory that doesn't exist.

      #### Example

      Assuming that the directory `assets` doesn't exist, the following code
      produces this diagnostic because it's listed as a directory containing
      assets:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets:
          - assets/
      ```

      #### Common fixes

      If the path is correct, then create a directory at that path.

      If the path isn't correct, then change the path to match the path of the
      directory containing the assets.
  ASSET_DOES_NOT_EXIST:
    problemMessage: "The asset file '{0}' doesn't exist."
    correctionMessage: Try creating the file or fixing the path to the file.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the path to the asset as given in the file.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an asset list contains a value
      referencing a file that doesn't exist.

      #### Example

      Assuming that the file `doesNotExist.gif` doesn't exist, the following code
      produces this diagnostic because it's listed as an asset:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets:
          - doesNotExist.gif
      ```

      #### Common fixes

      If the path is correct, then create a file at that path.

      If the path isn't correct, then change the path to match the path of the
      file containing the asset.
  ASSET_FIELD_NOT_LIST:
    problemMessage: "The value of the 'asset' field is expected to be a list of relative file paths."
    correctionMessage: Try converting the value to be a list of relative file paths.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of the `asset` key
      isn't a list.

      #### Example

      The following code produces this diagnostic because the value of the assets
      key is a string when a list is expected:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets: assets/
      ```

      #### Common fixes

      Change the value of the asset list so that it's a list:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets:
          - assets/
      ```
  ASSET_NOT_STRING:
    problemMessage: Assets are required to be file paths (strings).
    correctionMessage: Try converting the value to be a string.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when an asset list contains a value
      that isn't a string.

      #### Example

      The following code produces this diagnostic because the asset list contains
      a map:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets:
          - image.gif: true
      ```

      #### Common fixes

      Change the asset list so that it only contains valid POSIX-style file
      paths:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        assets:
          - image.gif
      ```
  DEPENDENCIES_FIELD_NOT_MAP:
    problemMessage: "The value of the '{0}' field is expected to be a map."
    correctionMessage: Try converting the value to be a map.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of either the
      `dependencies` or `dev_dependencies` key isn't a map.

      #### Example

      The following code produces this diagnostic because the value of the
      top-level `dependencies` key is a list:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        - meta
      ```

      #### Common fixes

      Use a map as the value of the `dependencies` key:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        meta: ^1.0.2
      ```
  DEPRECATED_FIELD:
    problemMessage: "The '{0}' field is no longer used and can be removed."
    correctionMessage: Try removing the field.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a key is used in a
      `pubspec.yaml` file that was deprecated. Unused keys take up space and
      might imply semantics that are no longer valid.

      #### Example

      The following code produces this diagnostic because the `author` key is no
      longer being used:

      ```dart
      %uri="pubspec.yaml"
      name: example
      author: 'Dash'
      ```

      #### Common fixes

      Remove the deprecated key:

      ```dart
      %uri="pubspec.yaml"
      name: example
      ```
  FLUTTER_FIELD_NOT_MAP:
    problemMessage: "The value of the 'flutter' field is expected to be a map."
    correctionMessage: Try converting the value to be a map.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the value of the `flutter` key
      isn't a map.

      #### Example

      The following code produces this diagnostic because the value of the
      top-level `flutter` key is a string:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter: true
      ```

      #### Common fixes

      If you need to specify Flutter-specific options, then change the value to
      be a map:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      flutter:
        uses-material-design: true
      ```

      If you don't need to specify Flutter-specific options, then remove the
      `flutter` key:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      ```
  INVALID_DEPENDENCY:
    problemMessage: "Publishable packages can't have '{0}' dependencies."
    correctionMessage: "Try adding a 'publish_to: none' entry to mark the package as not for publishing or remove the {0} dependency."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the kind of dependency.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a package under either
      `dependencies` or `dev_dependencies` isn't a pub, `git`, or `path` based
      dependency.

      See [Package dependencies](https://dart.dev/tools/pub/dependencies) for
      more information about the kind of dependencies that are supported.

      #### Example

      The following code produces this diagnostic because the dependency on the
      package `transmogrify` isn't a pub, `git`, or `path` based dependency:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        transmogrify:
          hosted:
            name: transmogrify
            url: http://your-package-server.com
          version: ^1.4.0
      ```

      #### Common fixes

      If you want to publish your package to `pub.dev`, then change the
      dependencies to ones that are supported by `pub`.

      If you don't want to publish your package to `pub.dev`, then add a
      `publish_to: none` entry to mark the package as one that isn't intended to
      be published:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      publish_to: none
      dependencies:
        transmogrify:
          hosted:
            name: transmogrify
            url: http://your-package-server.com
          version: ^1.4.0
      ```
  MISSING_NAME:
    problemMessage: "The 'name' field is required but missing."
    correctionMessage: "Try adding a field named 'name'."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's no top-level `name` key.
      The `name` key provides the name of the package, which is required.

      #### Example

      The following code produces this diagnostic because the package doesn't
      have a name:

      ```yaml
      %uri="pubspec.yaml"
      dependencies:
        meta: ^1.0.2
      ```

      #### Common fixes

      Add the top-level key `name` with a value that's the name of the package:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        meta: ^1.0.2
      ```
  NAME_NOT_STRING:
    problemMessage: "The value of the 'name' field is required to be a string."
    correctionMessage: Try converting the value to be a string.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the top-level `name` key has a
      value that isn't a string.

      #### Example

      The following code produces this diagnostic because the value following the
      `name` key is a list:

      ```yaml
      %uri="pubspec.yaml"
      name:
        - example
      ```

      #### Common fixes

      Replace the value with a string:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      ```
  PATH_DOES_NOT_EXIST:
    problemMessage: "The path '{0}' doesn't exist."
    correctionMessage: Try creating the referenced path or using a path that exists.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the path to the dependency as given in the file.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a dependency has a `path` key
      referencing a directory that doesn't exist.

      #### Example

      Assuming that the directory `doesNotExist` doesn't exist, the following
      code produces this diagnostic because it's listed as the path of a package:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        local_package:
          path: doesNotExist
      ```

      #### Common fixes

      If the path is correct, then create a directory at that path.

      If the path isn't correct, then change the path to match the path to the
      root of the package.
  PATH_NOT_POSIX:
    problemMessage: "The path '{0}' isn't a POSIX-style path."
    correctionMessage: Try converting the value to a POSIX-style path.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the path as given in the file.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a dependency has a `path` key
      whose value is a string, but isn't a POSIX-style path.

      #### Example

      The following code produces this diagnostic because the path following the
      `path` key is a Windows path:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        local_package:
          path: E:\local_package
      ```

      #### Common fixes

      Convert the path to a POSIX path.
  PATH_PUBSPEC_DOES_NOT_EXIST:
    problemMessage: "The directory '{0}' doesn't contain a pubspec."
    correctionMessage: Try creating a pubspec in the referenced directory or using a path that has a pubspec.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the path to the dependency as given in the file.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a dependency has a `path` key
      that references a directory that doesn't contain a `pubspec.yaml` file.

      #### Example

      Assuming that the directory `local_package` doesn't contain a file named
      `pubspec.yaml`, the following code produces this diagnostic because it's
      listed as the path of a package:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        local_package:
          path: local_package
      ```

      #### Common fixes

      If the path is intended to be the root of a package, then add a
      `pubspec.yaml` file in the directory:

      ```yaml
      %uri="pubspec.yaml"
      name: local_package
      ```

      If the path is wrong, then replace it with the correct path.
  UNNECESSARY_DEV_DEPENDENCY:
    problemMessage: "The dev dependency on {0} is unnecessary because there is also a normal dependency on that package."
    correctionMessage: Try removing the dev dependency.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the package in the dev_dependency list.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when there's an entry under
      `dev_dependencies` for a package that is also listed under `dependencies`.
      The packages under `dependencies` are available to all of the code in the
      package, so there's no need to also list them under `dev_dependencies`.

      #### Example

      The following code produces this diagnostic because the package `meta` is
      listed under both `dependencies` and `dev_dependencies`:

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        meta: ^1.0.2
      dev_dependencies:
        meta: ^1.0.2
      ```

      #### Common fixes

      Remove the entry under `dev_dependencies` (and the `dev_dependencies` key
      if that's the only package listed there):

      ```yaml
      %uri="pubspec.yaml"
      name: example
      dependencies:
        meta: ^1.0.2
      ```
StaticWarningCode:
  DEAD_NULL_AWARE_EXPRESSION:
    problemMessage: "The left operand can't be null, so the right operand is never executed."
    correctionMessage: Try removing the operator and the right operand.
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic in two cases.

      The first is when the left operand of an `??` operator can't be `null`.
      The right operand is only evaluated if the left operand has the value
      `null`, and because the left operand can't be `null`, the right operand is
      never evaluated.

      The second is when the left-hand side of an assignment using the `??=`
      operator can't be `null`. The right-hand side is only evaluated if the
      left-hand side has the value `null`, and because the left-hand side can't
      be `null`, the right-hand side is never evaluated.

      #### Examples

      The following code produces this diagnostic because `x` can't be `null`:

      ```dart
      int f(int x) {
        return x ?? [!0!];
      }
      ```

      The following code produces this diagnostic because `f` can't be `null`:

      ```dart
      class C {
        int f = -1;

        void m(int x) {
          f ??= [!x!];
        }
      }
      ```

      #### Common fixes

      If the diagnostic is reported for an `??` operator, then remove the `??`
      operator and the right operand:

      ```dart
      int f(int x) {
        return x;
      }
      ```

      If the diagnostic is reported for an assignment, and the assignment isn't
      needed, then remove the assignment:

      ```dart
      class C {
        int f = -1;

        void m(int x) {
        }
      }
      ```

      If the assignment is needed, but should be based on a different condition,
      then rewrite the code to use `=` and the different condition:

      ```dart
      class C {
        int f = -1;

        void m(int x) {
          if (f < 0) {
            f = x;
          }
        }
      }
      ```
  INVALID_NULL_AWARE_OPERATOR:
    problemMessage: "The receiver can't be null, so the null-aware operator '{0}' is unnecessary."
    correctionMessage: "Try replacing the operator '{0}' with '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the null-aware operator that is invalid
      1: the non-null-aware operator that can replace the invalid operator
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a null-aware operator (`?.`,
      `?..`, `?[`, `?..[`, or `...?`) is used on a receiver that's known to be
      non-nullable.

      #### Examples

      The following code produces this diagnostic because `s` can't be `null`:

      ```dart
      int? getLength(String s) {
        return s[!?.!]length;
      }
      ```

      The following code produces this diagnostic because `a` can't be `null`:

      ```dart
      var a = [];
      var b = [[!...?!]a];
      ```

      The following code produces this diagnostic because `s?.length` can't
      return `null`:

      ```dart
      void f(String? s) {
        s?.length[!?.!]isEven;
      }
      ```

      The reason `s?.length` can't return `null` is because the null-aware
      operator following `s` short-circuits the evaluation of both `length` and
      `isEven` if `s` is `null`. In other words, if `s` is `null`, then neither
      `length` nor `isEven` will be invoked, and if `s` is non-`null`, then
      `length` can't return a `null` value. Either way, `isEven` can't be invoked
      on a `null` value, so the null-aware operator isn't necessary. See
      [Understanding null safety](/null-safety/understanding-null-safety#smarter-null-aware-methods)
      for more details.

      The following code produces this diagnostic because `s` can't be `null`.

      ```dart
      void f(Object? o) {
        var s = o as String;
        s[!?.!]length;
      }
      ```

      The reason `s` can't be null, despite the fact that `o` can be `null`, is
      because of the cast to `String`, which is a non-nullable type. If `o` ever
      has the value `null`, the cast will fail and the invocation of `length`
      will not happen.

      #### Common fixes

      Replace the null-aware operator with a non-null-aware equivalent; for
      example, change `?.` to  `.`:

      ```dart
      int getLength(String s) {
        return s.length;
      }
      ```

      (Note that the return type was also changed to be non-nullable, which might
      not be appropriate in some cases.)
  INVALID_NULL_AWARE_OPERATOR_AFTER_SHORT_CIRCUIT:
    sharedName: INVALID_NULL_AWARE_OPERATOR
    problemMessage: "The receiver can't be null because of short-circuiting, so the null-aware operator '{0}' can't be used."
    correctionMessage: "Try replacing the operator '{0}' with '{1}'."
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the null-aware operator that is invalid
      1: the non-null-aware operator that can replace the invalid operator
  INVALID_OVERRIDE_DIFFERENT_DEFAULT_VALUES_NAMED:
    problemMessage: "Parameters can't override default values, this method overrides '{0}.{1}' where '{2}' has a different value."
    correctionMessage: Try using the same default value in both methods.
    comment: |-
      7.1 Instance Methods: It is a static warning if an instance method
      <i>m1</i> overrides an instance member <i>m2</i>, the signature of
      <i>m2</i> explicitly specifies a default value for a formal parameter
      <i>p</i> and the signature of <i>m1</i> specifies a different default value
      for <i>p</i>.
  INVALID_OVERRIDE_DIFFERENT_DEFAULT_VALUES_POSITIONAL:
    problemMessage: "Parameters can't override default values, this method overrides '{0}.{1}' where this positional parameter has a different value."
    correctionMessage: Try using the same default value in both methods.
    comment: |-
      7.1 Instance Methods: It is a static warning if an instance method
      <i>m1</i> overrides an instance member <i>m2</i>, the signature of
      <i>m2</i> explicitly specifies a default value for a formal parameter
      <i>p</i> and the signature of <i>m1</i> specifies a different default value
      for <i>p</i>.
  MISSING_ENUM_CONSTANT_IN_SWITCH:
    problemMessage: "Missing case clause for '{0}'."
    correctionMessage: Try adding a case clause for the missing constant, or adding a default clause.
    hasPublishedDocs: true
    comment: |-
      Parameters:
      0: the name of the constant that is missing
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when a `switch` statement for an enum
      doesn't include an option for one of the values in the enum.

      Note that `null` is always a possible value for an enum and therefore also
      must be handled.

      #### Example

      The following code produces this diagnostic because the enum constant `e2`
      isn't handled:

      ```dart
      enum E { e1, e2 }

      void f(E e) {
        [!switch (e)!] {
          case E.e1:
            break;
        }
      }
      ```

      #### Common fixes

      If there's special handling for the missing values, then add a `case`
      clause for each of the missing values:

      ```dart
      enum E { e1, e2 }

      void f(E e) {
        switch (e) {
          case E.e1:
            break;
          case E.e2:
            break;
        }
      }
      ```

      If the missing values should be handled the same way, then add a `default`
      clause:

      ```dart
      enum E { e1, e2 }

      void f(E e) {
        switch (e) {
          case E.e1:
            break;
          default:
            break;
        }
      }
      ```
      TODO(brianwilkerson) This documentation will need to be updated when NNBD
       ships.
  UNNECESSARY_NON_NULL_ASSERTION:
    problemMessage: "The '!' will have no effect because the receiver can't be null."
    correctionMessage: "Try removing the '!' operator."
    hasPublishedDocs: true
    comment: No parameters.
    documentation: |-
      #### Description

      The analyzer produces this diagnostic when the operand of the `!` operator
      can't be `null`.

      #### Example

      The following code produces this diagnostic because `x` can't be `null`:

      ```dart
      int f(int x) {
        return x[!!!];
      }
      ```

      #### Common fixes

      Remove the null check operator (`!`):

      ```dart
      int f(int x) {
        return x;
      }
      ```