---
title: Diagnostic messages
description: Details for diagnostics produced by the Dart analyzer.
body_class: highlight-diagnostics
---
{%- comment %}
WARNING: Do NOT EDIT this file directly. It is autogenerated by the script in
`pkg/analyzer/tool/diagnostics/generate.dart` in the sdk repository.
Update instructions: https://github.com/dart-lang/site-www/issues/1949
{% endcomment -%}

This page lists diagnostic messages produced by the Dart analyzer,
with details about what those messages mean and how you can fix your code.
For more information about the analyzer, see
[Customizing static analysis](/tools/analysis).

[constant context]: /resources/glossary#constant-context
[definite assignment]: /resources/glossary#definite-assignment
[mixin application]: /resources/glossary#mixin-application
[override inference]: /resources/glossary#override-inference
[part file]: /resources/glossary#part-file
[potentially non-nullable]: /resources/glossary#potentially-non-nullable
[public library]: /resources/glossary#public-library

## Diagnostics

The analyzer produces the following diagnostics for code that
doesn't conform to the language specification or
that might work in unexpected ways.

[ffi]: https://dart.dev/guides/libraries/c-interop
[IEEE 754]: https://en.wikipedia.org/wiki/IEEE_754
[irrefutable pattern]: https://dart.dev/resources/glossary#irrefutable-pattern
[meta-doNotStore]: https://pub.dev/documentation/meta/latest/meta/doNotStore-constant.html
[meta-factory]: https://pub.dev/documentation/meta/latest/meta/factory-constant.html
[meta-immutable]: https://pub.dev/documentation/meta/latest/meta/immutable-constant.html
[meta-internal]: https://pub.dev/documentation/meta/latest/meta/internal-constant.html
[meta-literal]: https://pub.dev/documentation/meta/latest/meta/literal-constant.html
[meta-mustCallSuper]: https://pub.dev/documentation/meta/latest/meta/mustCallSuper-constant.html
[meta-optionalTypeArgs]: https://pub.dev/documentation/meta/latest/meta/optionalTypeArgs-constant.html
[meta-sealed]: https://pub.dev/documentation/meta/latest/meta/sealed-constant.html
[meta-useResult]: https://pub.dev/documentation/meta/latest/meta/useResult-constant.html
[meta-UseResult]: https://pub.dev/documentation/meta/latest/meta/UseResult-class.html
[meta-visibleForOverriding]: https://pub.dev/documentation/meta/latest/meta/visibleForOverriding-constant.html
[meta-visibleForTesting]: https://pub.dev/documentation/meta/latest/meta/visibleForTesting-constant.html
[refutable pattern]: https://dart.dev/resources/glossary#refutable-pattern

### abi_specific_integer_invalid

_Classes extending 'AbiSpecificInteger' must have exactly one const constructor,
no other members, and no type parameters._

#### Description

The analyzer produces this diagnostic when a class that extends
`AbiSpecificInteger` doesn't meet all of the following requirements:
- there must be exactly one constructor
- the constructor must be marked `const`
- there must not be any members of other than the one constructor
- there must not be any type parameters

#### Examples

The following code produces this diagnostic because the class `C` doesn't
define a const constructor:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class [!C!] extends AbiSpecificInteger {
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class [!C!] extends AbiSpecificInteger {
  C();
}
{% endprettify %}

The following code produces this diagnostic because the class `C` defines
multiple constructors:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class [!C!] extends AbiSpecificInteger {
  const C.zero();
  const C.one();
}
{% endprettify %}

The following code produces this diagnostic because the class `C` defines
a field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class [!C!] extends AbiSpecificInteger {
  final int i;

  const C(this.i);
}
{% endprettify %}

The following code produces this diagnostic because the class `C` has a
type parameter:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class [!C!]<T> extends AbiSpecificInteger { // type parameters
  const C();
}
{% endprettify %}

#### Common fixes

Change the class so that it meets the requirements of having no type
parameters and a single member that is a `const` constructor:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

### abi_specific_integer_mapping_extra

_Classes extending 'AbiSpecificInteger' must have exactly one
'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size._

#### Description

The analyzer produces this diagnostic when a class that extends
`AbiSpecificInteger` has more than one `AbiSpecificIntegerMapping`
annotation.

#### Example

The following code produces this diagnostic because there are two
`AbiSpecificIntegerMapping` annotations on the class `C`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
@[!AbiSpecificIntegerMapping!]({Abi.linuxX64 : Uint16()})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

#### Common fixes

Remove all but one of the annotations, merging the arguments as
appropriate:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8(), Abi.linuxX64 : Uint16()})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

### abi_specific_integer_mapping_missing

_Classes extending 'AbiSpecificInteger' must have exactly one
'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size._

#### Description

The analyzer produces this diagnostic when a class that extends
`AbiSpecificInteger` doesn't have an `AbiSpecificIntegerMapping`
annotation.

#### Example

The following code produces this diagnostic because there's no
`AbiSpecificIntegerMapping` annotation on the class `C`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class [!C!] extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

#### Common fixes

Add an `AbiSpecificIntegerMapping` annotation to the class:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

### abi_specific_integer_mapping_unsupported

_Invalid mapping to '{0}'; only mappings to 'Int8', 'Int16', 'Int32', 'Int64',
'Uint8', 'Uint16', 'UInt32', and 'Uint64' are supported._

#### Description

The analyzer produces this diagnostic when a value in the map argument of
an `AbiSpecificIntegerMapping` annotation is anything other than one of
the following integer types:
- `Int8`
- `Int16`
- `Int32`
- `Int64`
- `Uint8`
- `Uint16`
- `UInt32`
- `Uint64`

#### Example

The following code produces this diagnostic because the value of the map
entry is `Array<Uint8>`, which isn't a valid integer type:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : [!Array<Uint8>(4)!]})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

#### Common fixes

Use one of the valid types as a value in the map:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
  const C();
}
{% endprettify %}

### abstract_field_initializer

_Abstract fields can't have initializers._

#### 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:

{% prettify dart tag=pre+code %}
abstract class C {
  abstract int [!f!] = 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
abstract class C {
  abstract int f;

  C() : [!f!] = 0;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
abstract class C {
  abstract int f;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
abstract class C {
  int f = 0;
}
{% endprettify %}

### abstract_sealed_class

_A 'sealed' class can't be marked 'abstract' because it's already implicitly
abstract._

#### Description

The analyzer produces this diagnostic when a class is declared using both
the modifier `abstract` and the modifier `sealed`. Sealed classes are
implicitly abstract, so explicitly using both modifiers is not allowed.

#### Example

The following code produces this diagnostic because the class `C` is
declared using both `abstract` and `sealed`:

{% prettify dart tag=pre+code %}
abstract [!sealed!] class C {}
{% endprettify %}

#### Common fixes

If the class should be abstract but not sealed, then remove the `sealed`
modifier:

{% prettify dart tag=pre+code %}
abstract class C {}
{% endprettify %}

If the class should be both abstract and sealed, then remove the
`abstract` modifier:

{% prettify dart tag=pre+code %}
sealed class C {}
{% endprettify %}

### abstract_super_member_reference

_The {0} '{1}' is always abstract in the supertype._

#### 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`:

{% prettify dart tag=pre+code %}
abstract class A {
  int get a;
}
class B extends A {
  int get a => super.[!a!];
}
{% endprettify %}

#### Common fixes

Remove the invocation of the abstract member, possibly replacing it with an
invocation of a concrete member.

### ambiguous_export

_The name '{0}' is defined in the libraries '{1}' and '{2}'._

#### 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 `a.dart` containing

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

And a file `b.dart` containing

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
export 'a.dart';
export [!'b.dart'!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
export 'a.dart';
{% endprettify %}

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

{% prettify dart tag=pre+code %}
export 'a.dart';
export 'b.dart' hide C;
{% endprettify %}

### ambiguous_extension_member_access

_A member named '{0}' is defined in {1}, and none are more specific._

#### 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`:

{% prettify dart tag=pre+code %}
extension E1 on String {
  int get charCount => 1;
}

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

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

#### 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:

{% prettify dart tag=pre+code %}
extension E1 on String {
  int get charCount => length;
}

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

void f(String s) {
  print(E2(s).charCount);
}
{% endprettify %}

### ambiguous_import

_The name '{0}' is defined in the libraries {1}._

#### 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):

{% prettify dart tag=pre+code %}
class A {}
class C {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class B {}
class C {}
{% endprettify %}

The following code produces this diagnostic:

{% prettify dart tag=pre+code %}
import 'a.dart';
import 'b.dart';

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'a.dart';

void f(C c1, C c2) {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart' hide C;
import 'b.dart';

void f(C c1, C c2) {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart' as a;
import 'b.dart' as b;

void f(a.C c1, b.C c2) {}
{% endprettify %}

### ambiguous_set_or_map_literal_both

_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._

#### 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:

{% prettify dart tag=pre+code %}
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
    [!{...a, ...b, ...c}!];
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
    {...a, ...c};
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
    {...a, for (String s in b) s: s, ...c};
{% endprettify %}

### ambiguous_set_or_map_literal_either

_This literal must be either a map or a set, but the elements don't have enough
information for type inference to work._

#### 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:

{% prettify dart tag=pre+code %}
union(a, b) => [!{...a, ...b}!];
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
union(a, b) => <String, String>{...a, ...b};
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
union(List<int> a, List<int> b) => {...a, ...b};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
Set<String> union(a, b) => {...a, ...b};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
union(a, b) {
  var x = [!{...a, ...b}!];
  return x;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
union(a, b) {
  Map<String, String> x = {...a, ...b};
  return x;
}
{% endprettify %}

### annotation_on_pointer_field

_Fields in a struct class whose type is 'Pointer' shouldn't have any
annotations._

#### 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][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()`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  [!@Double()!]
  external Pointer<Int8> p;
}
{% endprettify %}

#### Common fixes

Remove the annotations from the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  external Pointer<Int8> p;
}
{% endprettify %}

### argument_must_be_a_constant

_Argument '{0}' must be a constant._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the value of the
`isLeaf` argument is a parameter, and hence isn't a constant:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int Function(int) fromPointer(
    Pointer<NativeFunction<Int8 Function(Int8)>> p, bool isLeaf) {
  return p.asFunction(isLeaf: [!isLeaf!]);
}
{% endprettify %}

#### Common fixes

If there's a suitable constant that can be used, then replace the argument
with a constant:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

const isLeaf = false;

int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
  return p.asFunction(isLeaf: isLeaf);
}
{% endprettify %}

If there isn't a suitable constant, then replace the argument with a
boolean literal:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
  return p.asFunction(isLeaf: true);
}
{% endprettify %}

### argument_type_not_assignable

_The argument type '{0}' can't be assigned to the parameter type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
String f(String x) => x;
String g(num y) => f([!y!]);
{% endprettify %}

#### 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`:

{% prettify dart tag=pre+code %}
String f(String x) => x;
String g(String y) => f(y);
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
String f(String x) => x;
String g(num y) => f(y.toString());
{% endprettify %}

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

{% prettify dart tag=pre+code %}
String f(String x) => x;
String g(num y) => f(y is String ? y : '');
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
String f(String x) => x;
String g(num y) => f(y as String);
{% endprettify %}

### argument_type_not_assignable_to_error_handler

_The argument type '{0}' can't be assigned to the parameter type '{1}
Function(Object)' or '{1} Function(Object, StackTrace)'._

#### 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:

{% prettify dart tag=pre+code %}
void f(Future<int> f) {
  f.catchError([!() => 0!]);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void f(Future<int> f) {
  f.catchError([!(one, two, three) => 0!]);
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
void f(Future<int> f) {
  f.catchError([!(String error) => 0!]);
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void f(Future<int> f) {
  f.catchError((Object error) => 0);
}
{% endprettify %}

### assert_in_redirecting_constructor

_A redirecting constructor can't have an 'assert' initializer._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C(int x) : [!assert(x > 0)!], this.name();
  C.name() {}
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  C(int x) : this.name();
  C.name() {}
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  factory C(int x) {
    assert(x > 0);
    return C.name();
  }
  C.name() {}
}
{% endprettify %}

### asset_directory_does_not_exist

_The asset directory '{0}' doesn't exist._

#### 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
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

_The asset file '{0}' doesn't exist._

#### 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
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

_The value of the 'asset' field is expected to be a list of relative file
paths._

#### 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
name: example
flutter:
  assets: assets/
```

#### Common fixes

Change the value of the asset list so that it's a list:

```yaml
name: example
flutter:
  assets:
    - assets/
```

### asset_not_string

_Assets are required to be file paths (strings)._

#### 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
name: example
flutter:
  assets:
    - image.gif: true
```

#### Common fixes

Change the asset list so that it only contains valid POSIX-style file
paths:

```yaml
name: example
flutter:
  assets:
    - image.gif
```

### assignment_of_do_not_store

_'{0}' is marked 'doNotStore' and shouldn't be assigned to a field or top-level
variable._

#### 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`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@doNotStore
int f() => 1;

var x = [!f()!];
{% endprettify %}

#### Common fixes

Replace references to the field or variable with invocations of the
function producing the value.

### assignment_to_const

_Constant variables can't be assigned a value._

#### 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:

{% prettify dart tag=pre+code %}
const c = 0;

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
var c = 0;

void f() {
  c = 1;
  print(c);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
const c = 0;

void f() {
  var v = 1;
  print(v);
}
{% endprettify %}

### assignment_to_final

_'{0}' can't be used as a setter because it's final._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final v = 0;
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  int v = 0;
}

f(C c) {
  c.v = 1;
}
{% endprettify %}

### assignment_to_final_local

_The final variable '{0}' can only be set once._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  final x = 0;
  [!x!] = 3;
  print(x);
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f() {
  var x = 0;
  x = 3;
  print(x);
}
{% endprettify %}

### assignment_to_final_no_setter

_There isn't a setter named '{0}' in class '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  int get x => 0;
  set y(int p) {}
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  int get x => 0;
  set y(int p) {}
}

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

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

{% prettify dart tag=pre+code %}
class C {
  int get x => 0;
  set x(int p) {}
  set y(int p) {}
}

void f(C c) {
  c.x = 1;
}
{% endprettify %}

### assignment_to_function

_Functions can't be assigned a value._

#### 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:

{% prettify dart tag=pre+code %}
void f() {}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f() {}

void g() {
  var x = () {};
  print(x);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void Function() f = () {};

void g() {
  f = () {};
}
{% endprettify %}

### assignment_to_method

_Methods can't be assigned a value._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  void f() {}

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

#### Common fixes

Rewrite the code so that there isn't an assignment to a method.

### assignment_to_type

_Types can't be assigned a value._

#### 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:

{% prettify dart tag=pre+code %}
class C {}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f() {}

void g() {
  var c = null;
  print(c);
}
{% endprettify %}

### async_for_in_wrong_context

_The async for-in loop can only be used in an async function._

#### 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:

{% prettify dart tag=pre+code %}
void f(list) {
  [!await!] for (var e in list) {
    print(e);
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
Future<void> f(list) async {
  await for (var e in list) {
    print(e);
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
Stream<void> f(list) async* {
  await for (var e in list) {
    print(e);
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(list) {
  for (var e in list) {
    print(e);
  }
}
{% endprettify %}

### await_in_late_local_variable_initializer

_The 'await' expression can't be used in a 'late' local variable's initializer._

#### 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`:

{% prettify dart tag=pre+code %}
Future<int> f() async {
  late var v = [!await!] 42;
  return v;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
Future<int> f() async {
  late var v = 42;
  return v;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
Future<int> f() async {
  var v = await 42;
  return v;
}
{% endprettify %}

### body_might_complete_normally

_The body might complete normally, causing 'null' to be returned, but the return
type, '{0}', is a potentially non-nullable type._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  int [!m!](int t) {
    print(t);
  }
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class C<T> {
  T [!m!](T t) {
    print(t);
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C<T> {
  T m(T t) {
    print(t);
    return t;
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C<T> {
  T m(T t) {
    print(t);
    throw '';
  }
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class C<T> {
  T? m(T t) {
    print(t);
    return null;
  }
}
{% endprettify %}

### body_might_complete_normally_catch_error

_This 'onError' handler must return a value assignable to '{0}', but ends
without returning a value._

#### Description

The analyzer produces this diagnostic when the closure passed to the
`onError` parameter of the `Future.catchError` method is required to
return a non-`null` value (because of the `Future`s type argument) but can
implicitly return `null`.

#### Example

The following code produces this diagnostic because the closure passed to
the `catchError` method is required to return an `int` but doesn't end
with an explicit `return`, causing it to implicitly return `null`:

{% prettify dart tag=pre+code %}
void g(Future<int> f) {
  f.catchError((e, st) [!{!]});
}
{% endprettify %}

#### Common fixes

If the closure should sometimes return a non-`null` value, then add an
explicit return to the closure:

{% prettify dart tag=pre+code %}
void g(Future<int> f) {
  f.catchError((e, st) {
    return -1;
  });
}
{% endprettify %}

If the closure should always return `null`, then change the type argument
of the `Future` to be either `void` or `Null`:

{% prettify dart tag=pre+code %}
void g(Future<void> f) {
  f.catchError((e, st) {});
}
{% endprettify %}

### body_might_complete_normally_nullable

_This function has a nullable return type of '{0}', but ends without returning a
value._

#### 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`:

{% prettify dart tag=pre+code %}
String? [!f!]() {}
{% endprettify %}

#### Common fixes

If the return of `null` is intentional, then make it explicit:

{% prettify dart tag=pre+code %}
String? f() {
  return null;
}
{% endprettify %}

If the function should return a non-null value along that path, then add
the missing return statement:

{% prettify dart tag=pre+code %}
String? f() {
  return '';
}
{% endprettify %}

### break_label_on_switch_member

_A break label resolves to the 'case' or 'default' statement._

#### 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`:

{% prettify dart tag=pre+code %}
void f(int i) {
  switch (i) {
    l: case 0:
      break;
    case 1:
      break [!l!];
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(int i) {
  switch (i) {
    case 0:
      break;
    case 1:
      break;
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(int i) {
  switch (i) {
    l: case 0:
      break;
    case 1:
      continue l;
  }
}
{% endprettify %}

### built_in_identifier_as_type

_The built-in identifier '{0}' can't be used as a type._

#### 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:

{% prettify dart tag=pre+code %}
[!import!]<int> x;
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
List<int> x;
{% endprettify %}

### built_in_identifier_in_declaration

_The built-in identifier '{0}' can't be used as a prefix name._

_The built-in identifier '{0}' can't be used as a type name._

_The built-in identifier '{0}' can't be used as a type parameter name._

_The built-in identifier '{0}' can't be used as a typedef name._

_The built-in identifier '{0}' can't be used as an extension name._

#### 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:

{% prettify dart tag=pre+code %}
extension [!mixin!] on int {}
{% endprettify %}

#### Common fixes

Choose a different name for the declaration.

### case_block_not_terminated

_The last statement of the 'case' should be 'break', 'continue', 'rethrow',
'return', or 'throw'._

#### 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:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    [!case!] 0:
      x += 2;
    default:
      x += 1;
  }
}
{% endprettify %}

#### Common fixes

Add one of the required terminators:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case 0:
      x += 2;
      break;
    default:
      x += 1;
  }
}
{% endprettify %}

### case_expression_type_implements_equals

_The switch case expression type '{0}' can't override the '==' operator._

#### 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:

{% prettify dart tag=pre+code %}
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;
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final int value;

  const C(this.value);

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

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

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

{% prettify dart tag=pre+code %}
class C {
  final int value;

  const C(this.value);
}

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

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:

{% prettify dart tag=pre+code %}
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;
  }
}
{% endprettify %}

### case_expression_type_is_not_switch_expression_subtype

_The switch case expression type '{0}' must be a subtype of the switch
expression type '{1}'._

#### 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`):

{% prettify dart tag=pre+code %}
void f(String s) {
  switch (s) {
    case [!1!]:
      break;
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(String s) {
  switch (s) {
    case '1':
      break;
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(int s) {
  switch (s) {
    case 1:
      break;
  }
}
{% endprettify %}

### cast_from_nullable_always_fails

_This cast will always throw an exception because the nullable local variable
'{0}' is not assigned._

#### Description

The analyzer produces this diagnostic when a local variable that has a
nullable type hasn't been assigned and is cast to a non-nullable type.
Because the variable hasn't been assigned it has the default value of
`null`, causing the cast to throw an exception.

#### Example

The following code produces this diagnostic because the variable `x` is
cast to a non-nullable type (`int`) when it's known to have the value
`null`:

{% prettify dart tag=pre+code %}
void f() {
  num? x;
  [!x!] as int;
  print(x);
}
{% endprettify %}

#### Common fixes

If the variable is expected to have a value before the cast, then add an
initializer or an assignment:

{% prettify dart tag=pre+code %}
void f() {
  num? x = 3;
  x as int;
  print(x);
}
{% endprettify %}

If the variable isn't expected to be assigned, then remove the cast:

{% prettify dart tag=pre+code %}
void f() {
  num? x;
  print(x);
}
{% endprettify %}

### cast_from_null_always_fails

_This cast always throws an exception because the expression always evaluates to
'null'._

#### Description

The analyzer produces this diagnostic when an expression whose type is
`Null` is being cast to a non-nullable type.

#### Example

The following code produces this diagnostic because `n` is known to always
be `null`, but it's being cast to a non-nullable type:

{% prettify dart tag=pre+code %}
void f(Null n) {
  [!n as int!];
}
{% endprettify %}

#### Common fixes

Remove the unnecessary cast:

{% prettify dart tag=pre+code %}
void f(Null n) {
  n;
}
{% endprettify %}

### cast_to_non_type

_The name '{0}' isn't a type, so it can't be used in an 'as' expression._

#### 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:

{% prettify dart tag=pre+code %}
num x = 0;
int y = x as [!x!];
{% endprettify %}

#### Common fixes

Replace the name with the name of a type:

{% prettify dart tag=pre+code %}
num x = 0;
int y = x as int;
{% endprettify %}

### class_used_as_mixin

_The class '{0}' can't be used as a mixin because it's neither a mixin class nor
a mixin._

#### Description

The analyzer produces this diagnostic when a class that is neither a
`mixin class` nor a `mixin` is used in a `with` clause.

#### Example

The following code produces this diagnostic because the class `M` is being
used as a mixin, but it isn't defined as a `mixin class`:

{% prettify dart tag=pre+code %}
class M {}
class C with [!M!] {}
{% endprettify %}

#### Common fixes

If the class can be a pure mixin, then change `class` to `mixin`:

{% prettify dart tag=pre+code %}
mixin M {}
class C with M {}
{% endprettify %}

If the class needs to be both a class and a mixin, then add `mixin`:

{% prettify dart tag=pre+code %}
mixin class M {}
class C with M {}
{% endprettify %}

### collection_element_from_deferred_library

_Constant values from a deferred library can't be used as keys in a 'const' map
literal._

_Constant values from a deferred library can't be used as values in a 'const'
constructor._

_Constant values from a deferred library can't be used as values in a 'const'
list literal._

_Constant values from a deferred library can't be used as values in a 'const'
map literal._

_Constant values from a deferred library can't be used as values in a 'const'
set literal._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

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

{% prettify dart tag=pre+code %}
const zero = 0;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

var l = const [a.[!zero!]];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

var l = [a.zero];
{% endprettify %}

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

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

var l = const [a.zero];
{% endprettify %}

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

{% prettify dart tag=pre+code %}
var l = const [0];
{% endprettify %}

### compound_implements_finalizable

_The class '{0}' can't implement Finalizable._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `S`
implements `Finalizable`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class [!S!] extends Struct implements Finalizable {
  external Pointer notEmpty;
}
{% endprettify %}

#### Common fixes

Try removing the implements clause from the class:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class S extends Struct {
  external Pointer notEmpty;
}
{% endprettify %}

### concrete_class_has_enum_superinterface

_Concrete classes can't have 'Enum' as a superinterface._

#### 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`:

{% prettify dart tag=pre+code %}
abstract class A implements Enum {}

class [!B!] implements A {}
{% endprettify %}

#### Common fixes

If the implemented class isn't the class you intend to implement, then
change it:

{% prettify dart tag=pre+code %}
abstract class A implements Enum {}

class B implements C {}

class C {}
{% endprettify %}

If the implemented class can be changed to not implement `Enum`, then do
so:

{% prettify dart tag=pre+code %}
abstract class A {}

class B implements A {}
{% endprettify %}

If the implemented class can't be changed to not implement `Enum`, then
remove it from the `implements` clause:

{% prettify dart tag=pre+code %}
abstract class A implements Enum {}

class B {}
{% endprettify %}

### concrete_class_with_abstract_member

_'{0}' must have a method body because '{1}' isn't abstract._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  [!void m();!]
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  void m() {}
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
abstract class C {
  void m();
}
{% endprettify %}

### conflicting_constructor_and_static_member

_'{0}' can't be used to name both a constructor and a static field in this
class._

_'{0}' can't be used to name both a constructor and a static getter in this
class._

_'{0}' can't be used to name both a constructor and a static method in this
class._

_'{0}' can't be used to name both a constructor and a static setter in this
class._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C.[!foo!]();
  static int foo = 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  C.[!foo!]();
  static void foo() {}
}
{% endprettify %}

#### Common fixes

Rename either the member or the constructor.

### conflicting_generic_interfaces

_The {0} '{1}' can't implement both '{2}' and '{3}' because the type arguments
are different._

#### 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:

{% prettify dart tag=pre+code %}
class I<T> {}
class A implements I<int> {}
class B implements I<String> {}
class [!C!] extends A implements B {}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class I<T> {}
class A<S> implements I<S> {}
class B implements I<String> {}
class C extends A<String> implements B {}
{% endprettify %}

### conflicting_type_variable_and_container

_'{0}' can't be used to name both a type variable and the class in which the
type variable is defined._

_'{0}' can't be used to name both a type variable and the enum in which the type
variable is defined._

_'{0}' can't be used to name both a type variable and the extension in which the
type variable is defined._

_'{0}' can't be used to name both a type variable and the mixin in which the
type variable is defined._

#### 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:

{% prettify dart tag=pre+code %}
class C<[!C!]> {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C<T> {}
{% endprettify %}

### conflicting_type_variable_and_member

_'{0}' can't be used to name both a type variable and a member in this class._

_'{0}' can't be used to name both a type variable and a member in this enum._

_'{0}' can't be used to name both a type variable and a member in this
extension._

_'{0}' can't be used to name both a type variable and a member in this mixin._

#### 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`:

{% prettify dart tag=pre+code %}
class C<[!T!]> {
  int T = 0;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C<T> {
  int total = 0;
}
{% endprettify %}

### constant_pattern_never_matches_value_type

_The matched value type '{0}' can never be equal to this constant of type
'{1}'._

#### Description

The analyzer produces this diagnostic when a constant pattern can never
match the value it's being tested against because the type of the constant
is known to never match the type of the value.

#### Example

The following code produces this diagnostic because the type of the
constant pattern `(true)` is `bool`, and the type of the value being
matched (`x`) is `int`, and a Boolean can never match an integer:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case [!true!]) {}
}
{% endprettify %}

#### Common fixes

If the type of the value is correct, then rewrite the pattern to be
compatible:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case 3) {}
}
{% endprettify %}

If the type of the constant is correct, then rewrite the value to be
compatible:

{% prettify dart tag=pre+code %}
void f(bool x) {
  if (x case true) {}
}
{% endprettify %}

### constant_pattern_with_non_constant_expression

_The expression of a constant pattern must be a valid constant._

#### Description

The analyzer produces this diagnostic when a constant pattern has an
expression that isn't a valid constant.

#### Example

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

{% prettify dart tag=pre+code %}
void f(int e, int i) {
  switch (e) {
    case [!i!]:
      break;
  }
}
{% endprettify %}

#### Common fixes

If the value that should be matched is known, then replace the expression
with a constant:

{% prettify dart tag=pre+code %}
void f(int e, int i) {
  switch (e) {
    case 0:
      break;
  }
}
{% endprettify %}

If the value that should be matched isn't known, then rewrite the code to
not use a pattern:

{% prettify dart tag=pre+code %}
void f(int e, int i) {
  if (e == i) {}
}
{% endprettify %}

### const_constructor_param_type_mismatch

_A value of type '{0}' can't be assigned to a parameter of type '{1}' in a const
constructor._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  final String s;

  const C(this.s);
}

const dynamic i = 0;

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

#### Common fixes

Pass a value of the correct type to the constructor:

{% prettify dart tag=pre+code %}
class C {
  final String s;

  const C(this.s);
}

const dynamic i = 0;

void f() {
  const C('$i');
}
{% endprettify %}

### const_constructor_with_field_initialized_by_non_const

_Can't define the 'const' constructor because the field '{0}' is initialized
with a non-constant value._

#### 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:

{% prettify dart tag=pre+code %}
String x = '3';
class C {
  final String s = x;
  [!const!] C();
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final String s = '3';
  const C();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
String x = '3';
class C {
  final String s = x;
  C();
}
{% endprettify %}

### const_constructor_with_non_const_super

_A constant constructor can't call a non-constant super constructor of '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  const A();
  A.nonConst();
}

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

#### 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:

{% prettify dart tag=pre+code %}
class A {
  const A();
  A.nonConst();
}

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

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:

{% prettify dart tag=pre+code %}
class A {
  const A();
  const A.nonConst();
}

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

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:

{% prettify dart tag=pre+code %}
class A {
  const A();
  A.nonConst();
}

class B extends A {
  B() : super.nonConst();
}
{% endprettify %}

### const_constructor_with_non_final_field

_Can't define a const constructor for a class with non-final fields._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int x;

  const [!C!](this.x);
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final int x;

  const C(this.x);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int x;

  C(this.x);
}
{% endprettify %}

### const_deferred_class

_Deferred classes can't be created with 'const'._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#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:

{% prettify dart tag=pre+code %}
import 'dart:convert' deferred as convert;

const json2 = [!convert.JsonCodec()!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'dart:convert' deferred as convert;

final json2 = convert.JsonCodec();
{% endprettify %}

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

{% prettify dart tag=pre+code %}
import 'dart:convert' as convert;

const json2 = convert.JsonCodec();
{% endprettify %}

### const_initialized_with_non_constant_value

_Const variables must be initialized with a constant value._

#### 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`:

{% prettify dart tag=pre+code %}
var x = 0;
const y = [!x!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
const x = 0;
const y = x;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
var x = 0;
final y = x;
{% endprettify %}

### const_initialized_with_non_constant_value_from_deferred_library

_Constant values from a deferred library can't be used to initialize a 'const'
variable._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#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:

{% prettify dart tag=pre+code %}
import 'dart:math' deferred as math;

const pi = math.[!pi!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

const pi = math.pi;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
const pi = 3.14;
{% endprettify %}

### const_instance_field

_Only static fields can be declared as const._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  [!const!] int f = 3;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final int f = 3;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  static const int f = 3;
}
{% endprettify %}

### const_map_key_not_primitive_equality

_The type of a key in a constant map can't override the '==' operator, or
'hashCode', but the class '{0}' does._

#### Description

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

#### Examples

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 `==`:

{% prettify dart tag=pre+code %}
class C {
  const C();

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

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

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 `hashCode`:

{% prettify dart tag=pre+code %}
class C {
  const C();

  int get hashCode => 3;
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  const C();
}

const map = {C() : 0};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  const C();

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

final map = {C() : 0};
{% endprettify %}

### const_not_initialized

_The constant '{0}' must be initialized._

#### 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:

{% prettify dart tag=pre+code %}
const [!c!];
{% endprettify %}

#### Common fixes

Add an initializer:

{% prettify dart tag=pre+code %}
const c = 'c';
{% endprettify %}

### const_set_element_not_primitive_equality

<a id="const_set_element_type_implements_equals" aria-hidden="true"></a>_(Previously known as `const_set_element_type_implements_equals`)_

_An element in a constant set can't override the '==' operator, or 'hashCode',
but the type '{0}' does._

#### Description

The analyzer produces this diagnostic when the class of object used as an
element in a constant set literal implements either the `==` operator, the
getter `hashCode`, or both. The implementation of constant sets uses both
the `==` operator and the `hashCode` getter, so any implementation other
than the ones 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 `==`:

{% prettify dart tag=pre+code %}
class C {
  const C();

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

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

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 `hashCode`:

{% prettify dart tag=pre+code %}
class C {
  const C();

  int get hashCode => 3;
}

const map = {[!C()!]};
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  const C();
}

const set = {C()};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  const C();

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

final set = {C()};
{% endprettify %}

### const_spread_expected_list_or_set

_A list or a set is expected in this spread._

#### 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:

{% prettify dart tag=pre+code %}
const List<int> list1 = null;
const List<int> list2 = [...[!list1!]];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
const List<int> list1 = [];
const List<int> list2 = [...list1];
{% endprettify %}

### const_spread_expected_map

_A map is expected in this spread._

#### 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:

{% prettify dart tag=pre+code %}
const Map<String, int> map1 = null;
const Map<String, int> map2 = {...[!map1!]};
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
const Map<String, int> map1 = {};
const Map<String, int> map2 = {...map1};
{% endprettify %}

### const_with_non_const

_The constructor being called isn't a const constructor._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A();
}

A f() => [!const!] A();
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A {
  const A();
}

A f() => const A();
{% endprettify %}

Otherwise, remove the keyword `const`:

{% prettify dart tag=pre+code %}
class A {
  A();
}

A f() => A();
{% endprettify %}

### const_with_non_constant_argument

_Arguments of a constant creation must be constant expressions._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final int i;
  const C(this.i);
}
C f(int i) => const C([!i!]);
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final int i;
  const C(this.i);
}
C f(int i) => C(i);
{% endprettify %}

### const_with_type_parameters

_A constant constructor tearoff can't use a type parameter as a type argument._

_A constant creation can't use a type parameter as a type argument._

_A constant function tearoff can't use a type parameter as a type argument._

#### 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:

{% prettify dart tag=pre+code %}
class C<T> {
  const C();
}

C<T> newC<T>() => const C<[!T!]>();
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C<T> {
  const C();
}

C<int> newC() => const C<int>();
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C<T> {
  const C();
}

C<T> newC<T>() => C<T>();
{% endprettify %}

### continue_label_invalid

<a id="continue_label_on_switch" aria-hidden="true"></a>_(Previously known as `continue_label_on_switch`)_

_The label used in a 'continue' statement must be defined on either a loop or a
switch member._

#### 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:

{% prettify dart tag=pre+code %}
void f(int i) {
  l: switch (i) {
    case 0:
      [!continue l;!]
  }
}
{% endprettify %}

#### 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.

### creation_of_struct_or_union

_Subclasses of 'Struct' and 'Union' are backed by native memory, and can't be
instantiated by a generative constructor._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C` is being
instantiated using a generative constructor:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  external int a;
}

void f() {
  [!C!]();
}
{% endprettify %}

#### Common fixes

If you need to allocate the structure described by the class, then use the
`ffi` package to do so:

{% prettify dart tag=pre+code %}
import 'dart:ffi';
import 'package:ffi/ffi.dart';

final 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);
}
{% endprettify %}

### creation_with_non_type

_The name '{0}' isn't a class._

#### 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:

{% prettify dart tag=pre+code %}
int f() => 0;

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
int f() => 0;

void g() {
  new Object();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
int f() => 0;

void g() {
  f();
}
{% endprettify %}

### dead_code

_Dead code._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  return;
  [!print('here');!]
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f() {
  return;
}
{% endprettify %}

If the code needs to be executed, then either move the code to a place
where it will be executed:

{% prettify dart tag=pre+code %}
void f() {
  print('here');
  return;
}
{% endprettify %}

Or, rewrite the code before it, so that it can be reached:

{% prettify dart tag=pre+code %}
void f({bool skipPrinting = true}) {
  if (skipPrinting) {
    return;
  }
  print('here');
}
{% endprettify %}

### dead_code_catch_following_catch

_Dead code: Catch clauses after a 'catch (e)' or an 'on Object catch (e)' are
never reached._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } catch (e) {
  } [!on String {
  }!]
}
{% endprettify %}

#### Common fixes

If the clause should be selectable, then move the clause before the general
clause:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } on String {
  } catch (e) {
  }
}
{% endprettify %}

If the clause doesn't need to be selectable, then remove it:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } catch (e) {
  }
}
{% endprettify %}

### dead_code_on_catch_subtype

_Dead code: This on-catch block won't be executed because '{0}' is a subtype of
'{1}' and hence will have been caught already._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } on num {
  } [!on int {
  }!]
}
{% endprettify %}

#### Common fixes

If the clause should be selectable, then move the clause before the general
clause:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } on int {
  } on num {
  }
}
{% endprettify %}

If the clause doesn't need to be selectable, then remove it:

{% prettify dart tag=pre+code %}
void f() {
  try {
  } on num {
  }
}
{% endprettify %}

### dead_null_aware_expression

_The left operand can't be null, so the right operand is never executed._

#### 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`:

{% prettify dart tag=pre+code %}
int f(int x) {
  return x ?? [!0!];
}
{% endprettify %}

The following code produces this diagnostic because `f` can't be `null`:

{% prettify dart tag=pre+code %}
class C {
  int f = -1;

  void m(int x) {
    f ??= [!x!];
  }
}
{% endprettify %}

#### Common fixes

If the diagnostic is reported for an `??` operator, then remove the `??`
operator and the right operand:

{% prettify dart tag=pre+code %}
int f(int x) {
  return x;
}
{% endprettify %}

If the diagnostic is reported for an assignment, and the assignment isn't
needed, then remove the assignment:

{% prettify dart tag=pre+code %}
class C {
  int f = -1;

  void m(int x) {
  }
}
{% endprettify %}

If the assignment is needed, but should be based on a different condition,
then rewrite the code to use `=` and the different condition:

{% prettify dart tag=pre+code %}
class C {
  int f = -1;

  void m(int x) {
    if (f < 0) {
      f = x;
    }
  }
}
{% endprettify %}

### default_list_constructor

_The default 'List' constructor isn't available when null safety is enabled._

#### 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:

{% prettify dart tag=pre+code %}
var l = [!List<int>!]();
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
var l = <int>[];
{% endprettify %}

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

{% prettify dart tag=pre+code %}
var l = List.filled(3, 0);
{% endprettify %}

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

{% prettify dart tag=pre+code %}
var l = List.generate(3, (i) => i);
{% endprettify %}

### default_value_in_function_type

_Parameters in a function type can't have default values._

#### 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`:

{% prettify dart tag=pre+code %}
void f(void Function([int p [!=!] 0]) g) {
}
{% endprettify %}

#### Common fixes

Remove the default value from the function-type's parameter:

{% prettify dart tag=pre+code %}
void f(void Function([int p]) g) {
}
{% endprettify %}

### default_value_in_redirecting_factory_constructor

_Default values aren't allowed in factory constructors that redirect to another
constructor._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  factory A([int [!x!] = 0]) = B;
}

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

#### Common fixes

Remove the default value from the factory constructor:

{% prettify dart tag=pre+code %}
class A {
  factory A([int x]) = B;
}

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

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:

{% prettify dart tag=pre+code %}
class A {
 factory A(int x) = B;
}

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

### default_value_on_required_parameter

_Required named parameters can't have a default value._

#### 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:

{% prettify dart tag=pre+code %}
void log({required String [!message!] = 'no message'}) {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void log({required String message}) {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void log({String message = 'no message'}) {}
{% endprettify %}

### deferred_import_of_extension

_Imports of deferred libraries must hide all extensions._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

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

{% prettify dart tag=pre+code %}
class C {}

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

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

{% prettify dart tag=pre+code %}
import [!'a.dart'!] deferred as a;

void f() {
  a.C();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a show C;

void f() {
  a.C();
}
{% endprettify %}

Adding a `hide` clause would look like this:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a hide E;

void f() {
  a.C();
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

void f() {
  a.C();
}
{% endprettify %}

### definitely_unassigned_late_local_variable

_The late local variable '{0}' is definitely unassigned at this point._

#### 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:

{% prettify dart tag=pre+code %}
void f(bool b) {
  late int x;
  print([!x!]);
}
{% endprettify %}

#### Common fixes

Assign a value to the variable before reading from it:

{% prettify dart tag=pre+code %}
void f(bool b) {
  late int x;
  x = b ? 1 : 0;
  print(x);
}
{% endprettify %}

### dependencies_field_not_map

_The value of the '{0}' field is expected to be a map._

#### 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
name: example
dependencies:
  - meta
```

#### Common fixes

Use a map as the value of the `dependencies` key:

```yaml
name: example
dependencies:
  meta: ^1.0.2
```

### deprecated_colon_for_default_value

_Using a colon as a separator before a default value is deprecated and will not
be supported in language version 3.0 and later._

#### Description

The analyzer produces this diagnostic when a colon is used as the
separator before the default value of an optional parameter. While this
syntax is allowed, it's being deprecated in favor of using an equal sign.

#### Example

The following code produces this diagnostic because a colon is being used
before the default value of the optional parameter `i`:

{% prettify dart tag=pre+code %}
void f({int i [!:!] 0}) {}
{% endprettify %}

#### Common fixes

Replace the colon with an equal sign.

{% prettify dart tag=pre+code %}
void f({int i = 0}) {}
{% endprettify %}

### deprecated_export_use

_The ability to import '{0}' indirectly is deprecated._

#### Description

The analyzer produces this diagnostic when one library imports a name from
a second library, and the second library exports the name from a third
library but has indicated that it won't export the third library in the
future.

#### Example

Given a library `a.dart` defining the class `A`:

{% prettify dart tag=pre+code %}
class A {}
{% endprettify %}

And a second library `b.dart` that exports `a.dart` but has marked the
export as being deprecated:

{% prettify dart tag=pre+code %}
import 'a.dart';

@deprecated
export 'a.dart';
{% endprettify %}

The following code produces this diagnostic because the class `A` won't be
exported from `b.dart` in some future version:

{% prettify dart tag=pre+code %}
import 'b.dart';

[!A!]? a;
{% endprettify %}

#### Common fixes

If the name is available from a different library that you can import,
then replace the existing import with an import for that library (or add
an import for the defining library if you still need the old import):

{% prettify dart tag=pre+code %}
import 'a.dart';

A? a;
{% endprettify %}

If the name isn't available, then look for instructions from the library
author or contact them directly to find out how to update your code.

### deprecated_field

_The '{0}' field is no longer used and can be removed._

#### 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:

{% prettify dart tag=pre+code %}
name: example
author: 'Dash'
{% endprettify %}

#### Common fixes

Remove the deprecated key:

{% prettify dart tag=pre+code %}
name: example
{% endprettify %}

### deprecated_member_use

_'{0}' is deprecated and shouldn't be used._

_'{0}' is deprecated and shouldn't be used. {1}_

#### 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:

{% prettify dart tag=pre+code %}
void f(C c) {
  c.[!m!]();
}
{% endprettify %}

#### 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_from_same_package

_'{0}' is deprecated and shouldn't be used._

_'{0}' is deprecated and shouldn't be used. {1}_

#### 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:

{% prettify dart tag=pre+code %}
@deprecated
var x = 0;
var y = [!x!];
{% endprettify %}

#### 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_new_in_comment_reference

_Using the 'new' keyword in a comment reference is deprecated._

#### 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`:

{% prettify dart tag=pre+code %}
/// See [[!new!] C].
class C {
  C();
}
{% endprettify %}

The following code produces this diagnostic because the constructor named
`c` is being referenced using `new C.c`:

{% prettify dart tag=pre+code %}
/// See [[!new!] C.c].
class C {
  C.c();
}
{% endprettify %}

#### Common fixes

If you're referencing a named constructor, then remove the keyword `new`:

{% prettify dart tag=pre+code %}
/// See [C.c].
class C {
  C.c();
}
{% endprettify %}

If you're referencing the unnamed constructor, then remove the keyword
`new` and append `.new` after the class name:

{% prettify dart tag=pre+code %}
/// See [C.new].
class C {
  C.c();
}
{% endprettify %}

### deprecated_subtype_of_function

_Extending 'Function' is deprecated._

_Implementing 'Function' has no effect._

_Mixing in 'Function' is deprecated._

#### 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`:

{% prettify dart tag=pre+code %}
class F extends [!Function!] {}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class F {}
{% endprettify %}

### disallowed_type_instantiation_expression

_Only a generic type, generic function, generic instance method, or generic
constructor can have type arguments._

#### 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:

{% prettify dart tag=pre+code %}
int i = 1;

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
int i = 1;

void f() {
  print(i);
}
{% endprettify %}

### division_optimization

_The operator x ~/ y is more efficient than (x / y).toInt()._

#### Description

The analyzer produces this diagnostic when the result of dividing two
numbers is converted to an integer using `toInt`. Dart has a built-in
integer division operator that is both more efficient and more concise.

#### Example

The following code produces this diagnostic because the result of dividing
`x` and `y` is converted to an integer using `toInt`:

{% prettify dart tag=pre+code %}
int divide(num x, num y) => [!(x / y).toInt()!];
{% endprettify %}

#### Common fixes

Use the integer division operator (`~/`):

{% prettify dart tag=pre+code %}
int divide(num x, num y) => x ~/ y;
{% endprettify %}

### duplicate_constructor

_The constructor with name '{0}' is already defined._

_The unnamed constructor is already defined._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C();

  [!C!]();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  C.m();

  [!C.m!]();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C();

  C.n();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  C();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  C.m();

  C.n();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  C.m();
}
{% endprettify %}

### duplicate_definition

_The name '{0}' is already defined._

#### 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:

{% prettify dart tag=pre+code %}
int x = 0;
int [!x!] = 1;
{% endprettify %}

#### Common fixes

Choose a different name for one of the declarations.

{% prettify dart tag=pre+code %}
int x = 0;
int y = 1;
{% endprettify %}

### duplicate_export

_Duplicate export._

#### Description

The analyzer produces this diagnostic when an export directive is found
that is the same as an export before it in the file. The second export
doesn't add value and should be removed.

#### Example

The following code produces this diagnostic because the same library is
being exported twice:

{% prettify dart tag=pre+code %}
export 'package:meta/meta.dart';
export [!'package:meta/meta.dart'!];
{% endprettify %}

#### Common fixes

Remove the unnecessary export:

{% prettify dart tag=pre+code %}
export 'package:meta/meta.dart';
{% endprettify %}

### duplicate_field_formal_parameter

_The field '{0}' can't be initialized by multiple parameters in the same
constructor._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int f;

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

#### Common fixes

Remove one of the initializing formal parameters:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f) {}
}
{% endprettify %}

### duplicate_field_name

_The field name '{0}' is already used in this record._

#### Description

The analyzer produces this diagnostic when either a record literal or a
record type annotation contains a field whose name is the same as a
previously declared field in the same literal or type.

#### Examples

The following code produces this diagnostic because the record literal has
two fields named `a`:

{% prettify dart tag=pre+code %}
var r = (a: 1, [!a!]: 2);
{% endprettify %}

The following code produces this diagnostic because the record type
annotation has two fields named `a`, one a positional field and the other
a named field:

{% prettify dart tag=pre+code %}
void f((int a, {int [!a!]}) r) {}
{% endprettify %}

#### Common fixes

Rename one or both of the fields:

{% prettify dart tag=pre+code %}
var r = (a: 1, b: 2);
{% endprettify %}

### duplicate_hidden_name

_Duplicate hidden name._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' hide min, [!min!];

var x = pi;
{% endprettify %}

#### Common fixes

If the name was mistyped in one or more places, then correct the mistyped
names:

{% prettify dart tag=pre+code %}
import 'dart:math' hide max, min;

var x = pi;
{% endprettify %}

If the name wasn't mistyped, then remove the unnecessary name from the
list:

{% prettify dart tag=pre+code %}
import 'dart:math' hide min;

var x = pi;
{% endprettify %}

### duplicate_ignore

_The diagnostic '{0}' doesn't need to be ignored here because it's already being
ignored._

#### 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:

{% prettify dart tag=pre+code %}
// ignore_for_file: unused_local_variable
void f() {
  // ignore: [!unused_local_variable!]
  var x = 0;
}
{% endprettify %}

The following code produces this diagnostic because the diagnostic named
`unused_local_variable` is being ignored twice on the same line:

{% prettify dart tag=pre+code %}
void f() {
  // ignore: unused_local_variable, [!unused_local_variable!]
  var x = 0;
}
{% endprettify %}

#### Common fixes

Remove the ignore comment, or remove the unnecessary diagnostic name if the
ignore comment is ignoring more than one diagnostic:

{% prettify dart tag=pre+code %}
// ignore_for_file: unused_local_variable
void f() {
  var x = 0;
}
{% endprettify %}

### duplicate_import

_Duplicate import._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';
import [!'package:meta/meta.dart'!];

@sealed class C {}
{% endprettify %}

#### Common fixes

Remove the unnecessary import:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@sealed class C {}
{% endprettify %}

### duplicate_named_argument

_The argument for the named parameter '{0}' was already specified._

#### 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`:

{% prettify dart tag=pre+code %}
void f(C c) {
  c.m(a: 0, [!a!]: 1);
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(C c) {
  c.m(a: 0, b: 1);
}

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

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

{% prettify dart tag=pre+code %}
void f(C c) {
  c.m(a: 1);
}

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

### duplicate_part

_The library already contains a part with the URI '{0}'._

#### Description

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

#### Example

Given a file `part.dart` containing

{% prettify dart tag=pre+code %}
part of lib;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
library lib;

part 'part.dart';
part [!'part.dart'!];
{% endprettify %}

#### Common fixes

Remove all except the first of the duplicated part directives:

{% prettify dart tag=pre+code %}
library lib;

part 'part.dart';
{% endprettify %}

### duplicate_pattern_assignment_variable

_The variable '{0}' is already assigned in this pattern._

#### Description

The analyzer produces this diagnostic when a single pattern variable is
assigned a value more than once in the same pattern assignment.

#### Example

The following code produces this diagnostic because the variable `a` is
assigned twice in the pattern `(a, a)`:

{% prettify dart tag=pre+code %}
int f((int, int) r) {
  int a;
  (a, [!a!]) = r;
  return a;
}
{% endprettify %}

#### Common fixes

If you need to capture all of the values, then use a unique variable for
each of the subpatterns being matched:

{% prettify dart tag=pre+code %}
int f((int, int) r) {
  int a, b;
  (a, b) = r;
  return a + b;
}
{% endprettify %}

If some of the values don't need to be captured, then use a wildcard
pattern `_` to avoid having to bind the value to a variable:

{% prettify dart tag=pre+code %}
int f((int, int) r) {
  int a;
  (_, a) = r;
  return a;
}
{% endprettify %}

### duplicate_pattern_field

_The field '{0}' is already matched in this pattern._

#### Description

The analyzer produces this diagnostic when a record pattern matches the
same field more than once, or when an object pattern matches the same
getter more than once.

#### Examples

The following code produces this diagnostic because the record field `a`
is matched twice in the same record pattern:

{% prettify dart tag=pre+code %}
void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, [!a!]: 2):
      return;
  }
}
{% endprettify %}

The following code produces this diagnostic because the getter `f` is
matched twice in the same object pattern:

{% prettify dart tag=pre+code %}
void f(Object o) {
  switch (o) {
    case C(f: 1, [!f!]: 2):
      return;
  }
}
class C {
  int? f;
}
{% endprettify %}

#### Common fixes

If the pattern should match for more than one value of the duplicated
field, then use a logical-or pattern:

{% prettify dart tag=pre+code %}
void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, b: _) || (a: 2, b: _):
      break;
  }
}
{% endprettify %}

If the pattern should match against multiple fields, then change the name
of one of the fields:

{% prettify dart tag=pre+code %}
void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, b: 2):
      return;
  }
}
{% endprettify %}

### duplicate_rest_element_in_pattern

_At most one rest element is allowed in a list or map pattern._

#### Description

The analyzer produces this diagnostic when there's more than one rest
pattern in either a list or map pattern. A rest pattern will capture any
values unmatched by other subpatterns, making subsequent rest patterns
unnecessary because there's nothing left to capture.

#### Example

The following code produces this diagnostic because there are two rest
patterns in the list pattern:

{% prettify dart tag=pre+code %}
void f(List<int> x) {
  if (x case [0, ..., [!...!]]) {}
}
{% endprettify %}

#### Common fixes

Remove all but one of the rest patterns:

{% prettify dart tag=pre+code %}
void f(List<int> x) {
  if (x case [0, ...]) {}
}
{% endprettify %}

### duplicate_shown_name

_Duplicate shown name._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' show min, [!min!];

var x = min(2, min(0, 1));
{% endprettify %}

#### Common fixes

If the name was mistyped in one or more places, then correct the mistyped
names:

{% prettify dart tag=pre+code %}
import 'dart:math' show max, min;

var x = max(2, min(0, 1));
{% endprettify %}

If the name wasn't mistyped, then remove the unnecessary name from the
list:

{% prettify dart tag=pre+code %}
import 'dart:math' show min;

var x = min(2, min(0, 1));
{% endprettify %}

### duplicate_variable_pattern

_The variable '{0}' is already defined in this pattern._

#### Description

The analyzer produces this diagnostic when a branch of a logical-and
pattern declares a variable that is already declared in an earlier branch
of the same pattern.

#### Example

The following code produces this diagnostic because the variable `a` is
declared in both branches of the logical-and pattern:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (var a, 0) && (0, var [!a!])) {
    print(a);
  }
}
{% endprettify %}

#### Common fixes

If you need to capture the matched value in multiple branches, then change
the names of the variables so that they are unique:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (var a, 0) && (0, var b)) {
    print(a + b);
  }
}
{% endprettify %}

If you only need to capture the matched value on one branch, then remove
the variable pattern from all but one branch:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (var a, 0) && (0, _)) {
    print(a);
  }
}
{% endprettify %}

### empty_map_pattern

_A map pattern must have at least one entry._

#### Description

The analyzer produces this diagnostic when a map pattern is empty.

#### Example

The following code produces this diagnostic because the map pattern
is empty:

{% prettify dart tag=pre+code %}
void f(Map<int, String> x) {
  if (x case [!{}!]) {}
}
{% endprettify %}

#### Common fixes

If the pattern should match any map, then replace it with an object
pattern:

{% prettify dart tag=pre+code %}
void f(Map<int, String> x) {
  if (x case Map()) {}
}
{% endprettify %}

If the pattern should only match an empty map, then check the length
in the pattern:

{% prettify dart tag=pre+code %}
void f(Map<int, String> x) {
  if (x case Map(isEmpty: true)) {}
}
{% endprettify %}

### empty_record_literal_with_comma

_A record literal without fields can't have a trailing comma._

#### Description

The analyzer produces this diagnostic when a record literal that has no
fields has a trailing comma. Empty record literals can't contain a comma.

#### Example

The following code produces this diagnostic because the empty record
literal has a trailing comma:

{% prettify dart tag=pre+code %}
var r = ([!,!]);
{% endprettify %}

#### Common fixes

If the record is intended to be empty, then remove the comma:

{% prettify dart tag=pre+code %}
var r = ();
{% endprettify %}

If the record is intended to have one or more fields, then add the
expressions used to compute the values of those fields:

{% prettify dart tag=pre+code %}
var r = (3, 4);
{% endprettify %}

### empty_record_type_named_fields_list

_The list of named fields in a record type can't be empty._

#### Description

The analyzer produces this diagnostic when a record type has an empty list
of named fields.

#### Example

The following code produces this diagnostic because the record type has an
empty list of named fields:

{% prettify dart tag=pre+code %}
void f((int, int, {[!}!]) r) {}
{% endprettify %}

#### Common fixes

If the record is intended to have named fields, then add the types and
names of the fields:

{% prettify dart tag=pre+code %}
void f((int, int, {int z}) r) {}
{% endprettify %}

If the record isn't intended to have named fields, then remove the curly
braces:

{% prettify dart tag=pre+code %}
void f((int, int) r) {}
{% endprettify %}

### empty_record_type_with_comma

_A record type without fields can't have a trailing comma._

#### Description

The analyzer produces this diagnostic when a record type that has no
fields has a trailing comma. Empty record types can't contain a comma.

#### Example

The following code produces this diagnostic because the empty record type
has a trailing comma:

{% prettify dart tag=pre+code %}
void f(([!,!]) r) {}
{% endprettify %}

#### Common fixes

If the record type is intended to be empty, then remove the comma:

{% prettify dart tag=pre+code %}
void f(() r) {}
{% endprettify %}

If the record type is intended to have one or more fields, then add the
types of those fields:

{% prettify dart tag=pre+code %}
void f((int, int) r) {}
{% endprettify %}

### empty_struct

_The class '{0}' can't be empty because it's a subclass of '{1}'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C`, which
extends `Struct`, doesn't declare any fields:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class [!C!] extends Struct {}
{% endprettify %}

#### Common fixes

If the class is intended to be a struct, then declare one or more fields:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  external int x;
}
{% endprettify %}

If the class is intended to be used as a type argument to `Pointer`, then
make it a subclass of `Opaque`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Opaque {}
{% endprettify %}

If the class isn't intended to be a struct, then remove or change the
extends clause:

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

### enum_constant_same_name_as_enclosing

_The name of the enum constant can't be the same as the enum's name._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  [!E!]
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
enum E {
  e
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
enum F {
  E
}
{% endprettify %}

### enum_constant_with_non_const_constructor

_The invoked constructor isn't a 'const' constructor._

#### 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:

{% prettify dart tag=pre+code %}
enum E {
  [!e!]();

  factory E() => e;
}
{% endprettify %}

#### Common fixes

Use a generative constructor marked as `const`:

{% prettify dart tag=pre+code %}
enum E {
  e._();

  factory E() => e;

  const E._();
}
{% endprettify %}

### enum_mixin_with_instance_variable

_Mixins applied to enums can't have instance variables._

#### 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`:

{% prettify dart tag=pre+code %}
mixin M {
  int x = 0;
}

enum E with [!M!] {
  a
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
mixin M {
  int get x => 0;
}

enum E with M {
  a
}
{% endprettify %}

If you don't need to apply the mixin, then remove it:

{% prettify dart tag=pre+code %}
enum E {
  a
}
{% endprettify %}

### enum_with_abstract_member

_'{0}' must have a method body because '{1}' is an enum._

#### 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:

{% prettify dart tag=pre+code %}
enum E {
  e;

  [!void m();!]
}
{% endprettify %}

#### Common fixes

Provide an implementation for the member:

{% prettify dart tag=pre+code %}
enum E {
  e;

  void m() {}
}
{% endprettify %}

### enum_with_name_values

_The name 'values' is not a valid name for an enum._

#### 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`:

{% prettify dart tag=pre+code %}
enum [!values!] {
  c
}
{% endprettify %}

#### Common fixes

Rename the enum to something other than `values`.

### equal_elements_in_const_set

_Two elements in a constant set literal can't be equal._

#### 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:

{% prettify dart tag=pre+code %}
const Set<String> set = {'a', [!'a'!]};
{% endprettify %}

#### Common fixes

Remove one of the duplicate values:

{% prettify dart tag=pre+code %}
const Set<String> set = {'a'};
{% endprettify %}

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_elements_in_set

_Two elements in a set literal shouldn't be equal._

#### 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:

{% prettify dart tag=pre+code %}
const a = 1;
const b = 1;
var s = <int>{a, [!b!]};
{% endprettify %}

#### Common fixes

If both elements should be included in the set, then change one of the
elements:

{% prettify dart tag=pre+code %}
const a = 1;
const b = 2;
var s = <int>{a, b};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
const a = 1;
var s = <int>{a};
{% endprettify %}

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

_Two keys in a constant map literal can't be equal._

#### 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:

{% prettify dart tag=pre+code %}
const map = <int, String>{1: 'a', 2: 'b', [!1!]: 'c', 4: 'd'};
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
const map = <int, String>{1: 'a', 2: 'b', 3: 'c', 4: 'd'};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
const map = <int, String>{1: 'a', 2: 'b', 4: 'd'};
{% endprettify %}

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.

### equal_keys_in_map

_Two keys in a map literal shouldn't be equal._

#### 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:

{% prettify dart tag=pre+code %}
const a = 1;
const b = 1;
var m = <int, String>{a: 'a', [!b!]: 'b'};
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
const a = 1;
const b = 2;
var m = <int, String>{a: 'a', b: 'b'};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
const a = 1;
var m = <int, String>{a: 'a'};
{% endprettify %}

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.

### equal_keys_in_map_pattern

_Two keys in a map pattern can't be equal._

#### Description

The analyzer produces this diagnostic when a map pattern contains more
than one key with the same name. The same key can't be matched twice.

#### Example

The following code produces this diagnostic because the key `'a'` appears
twice:

{% prettify dart tag=pre+code %}
void f(Map<String, int> x) {
  if (x case {'a': 1, [!'a'!]: 2}) {}
}
{% endprettify %}

#### Common fixes

If you are trying to match two different keys, then change one of the keys
in the pattern:

{% prettify dart tag=pre+code %}
void f(Map<String, int> x) {
  if (x case {'a': 1, 'b': 2}) {}
}
{% endprettify %}

If you are trying to match the same key, but allow any one of multiple
patterns to match, the use a logical-or pattern:

{% prettify dart tag=pre+code %}
void f(Map<String, int> x) {
  if (x case {'a': 1 || 2}) {}
}
{% endprettify %}

### expected_one_list_pattern_type_arguments

_List patterns require one type argument or none, but {0} found._

#### Description

The analyzer produces this diagnostic when a list pattern has more than
one type argument. List patterns can have either zero type arguments or
one type argument, but can't have more than one.

#### Example

The following code produces this diagnostic because the list pattern
(`[0]`) has two type arguments:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case [!<int, int>!][0]) {}
}
{% endprettify %}

#### Common fixes

Remove all but one of the type arguments:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case <int>[0]) {}
}
{% endprettify %}

### expected_one_list_type_arguments

_List literals require one type argument or none, but {0} found._

#### 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:

{% prettify dart tag=pre+code %}
var l = [!<int, int>!][];
{% endprettify %}

#### Common fixes

Remove all except one of the type arguments:

{% prettify dart tag=pre+code %}
var l = <int>[];
{% endprettify %}

### expected_one_set_type_arguments

_Set literals require one type argument or none, but {0} were found._

#### 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:

{% prettify dart tag=pre+code %}
var s = [!<int, String, int>!]{0, 'a', 1};
{% endprettify %}

#### Common fixes

Remove all except one of the type arguments:

{% prettify dart tag=pre+code %}
var s = <int>{0, 1};
{% endprettify %}

### expected_two_map_pattern_type_arguments

_Map patterns require two type arguments or none, but {0} found._

#### Description

The analyzer produces this diagnostic when a map pattern has either one
type argument or more than two type arguments. Map patterns can have
either two type arguments or zero type arguments, but can't have any other
number.

#### Example

The following code produces this diagnostic because the map pattern
(`<int>{}`) has one type argument:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case [!<int>!]{0: _}) {}
}
{% endprettify %}

#### Common fixes

Add or remove type arguments until there are two, or none:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case <int, int>{0: _}) {}
}
{% endprettify %}

### expected_two_map_type_arguments

_Map literals require two type arguments or none, but {0} found._

#### 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:

{% prettify dart tag=pre+code %}
var m = [!<int, String, int>!]{};
{% endprettify %}

#### Common fixes

Remove all except two of the type arguments:

{% prettify dart tag=pre+code %}
var m = <int, String>{};
{% endprettify %}

### export_internal_library

_The library '{0}' is internal and can't be exported._

#### 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:

{% prettify dart tag=pre+code %}
export [!'dart:_interceptors'!];
{% endprettify %}

#### Common fixes

Remove the export directive.

### export_legacy_symbol

_The symbol '{0}' is defined in a legacy library, and can't be re-exported from
a library with null safety enabled._

#### 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:

{% prettify dart tag=pre+code %}
// @dart = 2.8
String s;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
export [!'optedOut.dart'!];

class C {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
String? s;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

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

_The exported library '{0}' can't have a part-of directive._

#### Description

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

#### Example

Given a file `part.dart` containing

{% prettify dart tag=pre+code %}
part of lib;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
library lib;

export [!'part.dart'!];
{% endprettify %}

#### Common fixes

Either remove the export directive, or change the URI to be the URI of the
library containing the part.

### expression_in_map

_Expressions can't be used in a map literal._

#### 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:

{% prettify dart tag=pre+code %}
var map = <String, int>{'a': 0, 'b': 1, [!'c'!]};
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
var map = <String, int>{'a': 0, 'b': 1, 'c': 2};
{% endprettify %}

### extends_non_class

_Classes can only extend other classes._

#### 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:

{% prettify dart tag=pre+code %}
void f() {}

class C extends [!f!] {}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void f() {}

class C extends B {}

class B {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f() {}

class C {}
{% endprettify %}

### extension_as_expression

_Extension '{0}' can't be used as an expression._

#### 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:

{% prettify dart tag=pre+code %}
extension E on int {
  static String m() => '';
}

var x = [!E!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
extension E on int {
  static String m() => '';
}

var x = E.m();
{% endprettify %}

### extension_conflicting_static_and_instance

_An extension can't define static member '{0}' and an instance member with the
same name._

#### 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:

{% prettify dart tag=pre+code %}
extension E on Object {
  int get a => 0;
  static int [!a!]() => 0;
}
{% endprettify %}

#### Common fixes

Rename or remove one of the members:

{% prettify dart tag=pre+code %}
extension E on Object {
  int get a => 0;
  static int b() => 0;
}
{% endprettify %}

### extension_declares_abstract_member

_Extensions can't declare abstract members._

#### Description

The analyzer produces this diagnostic when an abstract declaration is
declared in an extension. Extensions can declare only concrete members.

#### Example

The following code produces this diagnostic because the method `a` doesn't
have a body:

{% prettify dart tag=pre+code %}
extension E on String {
  int [!a!]();
}
{% endprettify %}

#### Common fixes

Either provide an implementation for the member or remove it.

### extension_declares_constructor

_Extensions can't declare constructors._

#### Description

The analyzer produces this diagnostic when a constructor declaration is
found in an extension. It isn't valid to define a constructor because
extensions aren't classes, and it isn't possible to create an instance of
an extension.

#### Example

The following code produces this diagnostic because there is a constructor
declaration in `E`:

{% prettify dart tag=pre+code %}
extension E on String {
  [!E!]() : super();
}
{% endprettify %}

#### Common fixes

Remove the constructor or replace it with a static method.

### extension_declares_instance_field

_Extensions can't declare instance fields_

#### Description

The analyzer produces this diagnostic when an instance field declaration is
found in an extension. It isn't valid to define an instance field because
extensions can only add behavior, not state.

#### Example

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

{% prettify dart tag=pre+code %}
extension E on String {
  String [!s!];
}
{% endprettify %}

#### Common fixes

Remove the field, make it a static field, or convert it to be a getter,
setter, or method.

### extension_declares_member_of_object

_Extensions can't declare members with the same name as a member declared by
'Object'._

#### 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`:

{% prettify dart tag=pre+code %}
extension E on String {
  String [!toString!]() => this;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
extension E on String {
  String displayString() => this;
}
{% endprettify %}

### extension_override_access_to_static_member

_An extension override can't be used to access a static member from an
extension._

#### 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:

{% prettify dart tag=pre+code %}
extension E on String {
  static void m() {}
}

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

#### Common fixes

Replace the extension override with the name of the extension:

{% prettify dart tag=pre+code %}
extension E on String {
  static void m() {}
}

void f() {
  E.m();
}
{% endprettify %}

### extension_override_argument_not_assignable

_The type of the argument to the extension override '{0}' isn't assignable to
the extended type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
extension E on String {
  void method() {}
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
extension E on String {
  void method() {}
}

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

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

_An extension override can only be used to access instance members._

#### 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:

{% prettify dart tag=pre+code %}
extension E on int {
  int get a => 0;
}

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
extension E on int {
  int get a => 0;
}

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

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

{% prettify dart tag=pre+code %}
extension E on int {
  int get a => 0;
}

void f(int i) {
  print(i);
}
{% endprettify %}

### extension_override_with_cascade

_Extension overrides have no value so they can't be used as the receiver of a
cascade expression._

#### 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:

{% prettify dart tag=pre+code %}
extension E on int {
  void m() {}
}
f() {
  [!E!](3)..m();
}
{% endprettify %}

#### Common fixes

Use `.` rather than `..`:

{% prettify dart tag=pre+code %}
extension E on int {
  void m() {}
}
f() {
  E(3).m();
}
{% endprettify %}

If there are multiple cascaded accesses, you'll need to duplicate the
extension override for each one.

### external_with_initializer

_External fields can't have initializers._

_External variables can't have initializers._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  external int x;
  C() : [!x!] = 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  external final int [!x!] = 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
external final int [!x!] = 0;
{% endprettify %}

#### Common fixes

Remove the initializer:

{% prettify dart tag=pre+code %}
class C {
  external final int x;
}
{% endprettify %}

### extra_annotation_on_struct_field

_Fields in a struct class must have exactly one annotation indicating the native
type._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the field `x` has two
annotations describing the native type of the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  [!@Int16()!]
  external int x;
}
{% endprettify %}

#### Common fixes

Remove all but one of the annotations:

{% prettify dart tag=pre+code %}
import 'dart:ffi';
final class C extends Struct {
  @Int32()
  external int x;
}
{% endprettify %}

### extra_positional_arguments

_Too many positional arguments: {0} expected, but {1} found._

#### 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:

{% prettify dart tag=pre+code %}
void f(int a, int b) {}
void g() {
  f(1, 2, [!3!]);
}
{% endprettify %}

#### Common fixes

Remove the arguments that don't correspond to parameters:

{% prettify dart tag=pre+code %}
void f(int a, int b) {}
void g() {
  f(1, 2);
}
{% endprettify %}

### extra_positional_arguments_could_be_named

_Too many positional arguments: {0} expected, but {1} found._

#### 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:

{% prettify dart tag=pre+code %}
void f(int a, int b, {int c}) {}
void g() {
  f(1, 2, [!3!]);
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(int a, int b, {int c}) {}
void g() {
  f(1, 2, c: 3);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(int a, int b, {int c}) {}
void g() {
  f(1, 2);
}
{% endprettify %}

### extra_size_annotation_carray

_'Array's must have exactly one 'Array' annotation._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the field `a0` has two
annotations that specify the size of the native array:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(4)
  [!@Array(8)!]
  external Array<Uint8> a0;
}
{% endprettify %}

#### Common fixes

Remove all but one of the annotations:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8)
  external Array<Uint8> a0;
}
{% endprettify %}

### field_initialized_by_multiple_initializers

_The field '{0}' can't be initialized twice in the same constructor._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C() : f = 0, [!f!] = 1;
}
{% endprettify %}

#### Common fixes

Remove one of the initializers:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C() : f = 0;
}
{% endprettify %}

### field_initialized_in_initializer_and_declaration

_Fields can't be initialized in the constructor if they are final and were
already initialized at their declaration._

#### 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 :

{% prettify dart tag=pre+code %}
class C {
  final int f = 0;
  C() : [!f!] = 1;
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final int f = 0;
  C();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  final int f;
  C() : f = 1;
}
{% endprettify %}

### field_initialized_in_parameter_and_initializer

_Fields can't be initialized in both the parameter list and the initializers._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f) : [!f!] = 0;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C() : f = 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(int g) : f = g * 2;
}
{% endprettify %}

### field_initializer_factory_constructor

_Initializing formal parameters can't be used in factory constructors._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int? f;

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

#### Common fixes

Replace the initializing formal parameter with a normal parameter:

{% prettify dart tag=pre+code %}
class C {
  int? f;

  factory C(int f) => throw 0;
}
{% endprettify %}

### field_initializer_in_struct

_Constructors in subclasses of 'Struct' and 'Union' can't have field
initializers._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C` has a
constructor with an initializer for the field `f`:

{% prettify dart tag=pre+code %}
// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  int f;

  C() : [!f = 0!];
}
{% endprettify %}

#### Common fixes

Remove the field initializer:

{% prettify dart tag=pre+code %}
// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  int f;

  C();
}
{% endprettify %}

### field_initializer_not_assignable

_The initializer type '{0}' can't be assigned to the field type '{1}' in a const
constructor._

_The initializer type '{0}' can't be assigned to the field type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  String s;

  C() : s = [!0!];
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  String s;

  C() : s = '0';
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int s;

  C() : s = 0;
}
{% endprettify %}

### field_initializer_outside_constructor

_Field formal parameters can only be used in a constructor._

_Initializing formal parameters can only be used in constructors._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  int x = 0;

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
class A {
  int x = 0;

  m([int x = 0]) {
    this.x = x;
  }
}
{% endprettify %}

### field_initializer_redirecting_constructor

_The redirecting constructor can't have a field initializer._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);

  C.zero([!this.f!]) : this(f);
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);

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

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);

  C.zero(int f) : this(f);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);

  C.zero() : this(0);
}
{% endprettify %}

### field_initializing_formal_not_assignable

_The parameter type '{0}' is incompatible with the field type '{1}'._

#### 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.

{% prettify dart tag=pre+code %}
class C {
  int f;

  C([!String this.f!]);
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  String f;

  C(this.f);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(this.f);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  int f;

  C(String s) : f = int.parse(s);
}
{% endprettify %}

### field_in_struct_with_initializer

_Fields in subclasses of 'Struct' and 'Union' can't have initializers._

#### 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][ffi].

#### Example

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

{% prettify dart tag=pre+code %}
// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  Pointer [!p!] = nullptr;
}
{% endprettify %}

#### Common fixes

Remove the initializer:

{% prettify dart tag=pre+code %}
// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  Pointer p;
}
{% endprettify %}

### field_must_be_external_in_struct

_Fields of 'Struct' and 'Union' subclasses must be marked external._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the field `a` isn't
marked as being `external`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int16()
  int [!a!];
}
{% endprettify %}

#### Common fixes

Add the required `external` modifier:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int16()
  external int a;
}
{% endprettify %}

### final_initialized_in_declaration_and_constructor

_'{0}' is final and was given a value when it was declared, so it can't be set
to a new value._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final int f = 0;

  C(this.[!f!]);
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final int f = 0;

  C();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  final int f;

  C(this.f);
}
{% endprettify %}

### final_not_initialized

_The final variable '{0}' must be initialized._

#### 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:

{% prettify dart tag=pre+code %}
final [!x!];
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
final x = 0;
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  final int x;
  C(this.x);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  final int x;
  C(int y) : x = y * 2;
}
{% endprettify %}

### final_not_initialized_constructor

_All final variables must be initialized, but '{0}' and '{1}' aren't._

_All final variables must be initialized, but '{0}' isn't._

_All final variables must be initialized, but '{0}', '{1}', and {2} others
aren't._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final String value;

  [!C!]();
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  final String value;

  C(this.value);
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  final String value;

  C(Object o) : value = o.toString();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  final String value = '';

  C();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  final String value;

  C() : value = '';

  C.named() : value = 'c';
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  static const String value = '';

  C();
}
{% endprettify %}

### flutter_field_not_map

_The value of the 'flutter' field is expected to be a map._

#### 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
name: example
flutter: true
```

#### Common fixes

If you need to specify Flutter-specific options, then change the value to
be a map:

```yaml
name: example
flutter:
  uses-material-design: true
```

If you don't need to specify Flutter-specific options, then remove the
`flutter` key:

```yaml
name: example
```

### for_in_of_invalid_element_type

_The type '{0}' used in the 'for' loop must implement '{1}' with a type argument
that can be assigned to '{2}'._

#### 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`):

{% prettify dart tag=pre+code %}
void f() {
  for (int e in [!<String>[]!]) {
    print(e);
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f() {
  for (int e in <int>[]) {
    print(e);
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f() {
  for (String e in <String>[]) {
    print(e);
  }
}
{% endprettify %}

### for_in_of_invalid_type

_The type '{0}' used in the 'for' loop must implement '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
void f(Map<String, String> m) {
  for (String s in [!m!]) {
    print(s);
  }
}
{% endprettify %}

#### Common fixes

Replace the expression with one that produces an iterable value:

{% prettify dart tag=pre+code %}
void f(Map<String, String> m) {
  for (String s in m.values) {
    print(s);
  }
}
{% endprettify %}

### for_in_with_const_variable

_A for-in loop variable can't be a 'const'._

#### 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`:

{% prettify dart tag=pre+code %}
void f() {
  for ([!const!] x in [0, 1, 2]) {
    print(x);
  }
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  for (final x in [0, 1, 2]) {
    print(x);
  }
}
{% endprettify %}

### generic_method_type_instantiation_on_dynamic

_A method tear-off on a receiver whose type is 'dynamic' can't have type
arguments._

#### 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:

{% prettify dart tag=pre+code %}
void f(dynamic list) {
  [!list.fold!]<int>;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(List<Object> list) {
  list.fold<int>;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(dynamic list) {
  list.cast;
}
{% endprettify %}

### generic_struct_subclass

_The class '{0}' can't extend 'Struct' or 'Union' because '{0}' is generic._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `S` defines
the type parameter `T`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class [!S!]<T> extends Struct {
  external Pointer notEmpty;
}
{% endprettify %}

#### Common fixes

Remove the type parameters from the class:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class S extends Struct {
  external Pointer notEmpty;
}
{% endprettify %}

### getter_not_subtype_setter_types

_The return type of getter '{0}' is '{1}' which isn't a subtype of the type
'{2}' of its setter '{3}'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  num get [!x!] => 0;

  set x(int y) {}
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  num get x => 0;

  set x(num y) {}
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int get x => 0;

  set x(int y) {}
}
{% endprettify %}

### illegal_async_generator_return_type

_Functions marked 'async*' must have a return type that is a supertype of
'Stream<T>' for some type 'T'._

#### 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`:

{% prettify dart tag=pre+code %}
[!int!] f() async* {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
Stream<int> f() async* {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
int f() => 0;
{% endprettify %}

### illegal_async_return_type

_Functions marked 'async' must have a return type which is a supertype of
'Future'._

#### 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`:

{% prettify dart tag=pre+code %}
[!int!] f() async {
  return 0;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
Future<int> f() async {
  return 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
int f() => 0;
{% endprettify %}

### illegal_concrete_enum_member

_A concrete instance member named '{0}' can't be declared in a class that
implements 'Enum'._

_A concrete instance member named '{0}' can't be inherited from '{1}' in a class
that implements 'Enum'._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  v;

  int get [!index!] => 0;
}
{% endprettify %}

The following code produces this diagnostic because the class `C`, which
implements `Enum`, declares an instance field named `hashCode`:

{% prettify dart tag=pre+code %}
abstract class C implements Enum {
  int [!hashCode!] = 0;
}
{% endprettify %}

The following code produces this diagnostic because the class `C`, which
indirectly implements `Enum` through the class `A`, declares an instance
getter named `hashCode`:

{% prettify dart tag=pre+code %}
abstract class A implements Enum {}

abstract class C implements A {
  int get [!hashCode!] => 0;
}
{% endprettify %}

The following code produces this diagnostic because the mixin `M`, which
has `Enum` in the `on` clause, declares an explicit operator named `==`:

{% prettify dart tag=pre+code %}
mixin M on Enum {
  bool operator [!==!](Object? other) => false;
}
{% endprettify %}

#### Common fixes

Rename the conflicting member:

{% prettify dart tag=pre+code %}
enum E {
  v;

  int get getIndex => 0;
}
{% endprettify %}

### illegal_enum_values

_An instance member named 'values' can't be declared in a class that implements
'Enum'._

_An instance member named 'values' can't be inherited from '{0}' in a class that
implements 'Enum'._

#### 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`:

{% prettify dart tag=pre+code %}
abstract class C implements Enum {
  int get [!values!] => 0;
}
{% endprettify %}

The following code produces this diagnostic because the class `B`, which
implements `Enum`, inherits an instance method named `values` from `A`:

{% prettify dart tag=pre+code %}
abstract class A {
  int values() => 0;
}

abstract class [!B!] extends A implements Enum {}
{% endprettify %}

#### Common fixes

Change the name of the conflicting member:

{% prettify dart tag=pre+code %}
abstract class C implements Enum {
  int get value => 0;
}
{% endprettify %}

### illegal_sync_generator_return_type

_Functions marked 'sync*' must have a return type that is a supertype of
'Iterable<T>' for some type 'T'._

#### 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`:

{% prettify dart tag=pre+code %}
[!int!] f() sync* {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
Iterable<int> f() sync* {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
int f() => 0;
{% endprettify %}

### implements_non_class

_Classes and mixins can only implement other classes and mixins._

#### 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:

{% prettify dart tag=pre+code %}
var x;
class C implements [!x!] {}
{% endprettify %}

#### 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

_'{0}' can only be implemented once._

#### 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:

{% prettify dart tag=pre+code %}
class A {}
class B implements A, [!A!] {}
{% endprettify %}

#### Common fixes

Remove all except one occurrence of the class name:

{% prettify dart tag=pre+code %}
class A {}
class B implements A {}
{% endprettify %}

### implements_super_class

_'{0}' can't be used in both the 'extends' and 'implements' clauses._

_'{0}' can't be used in both the 'extends' and 'with' clauses._

#### Description

The analyzer produces this diagnostic when a class is listed in the
`extends` clause of a class declaration and also in either the
`implements` or `with` clause of the same declaration.

#### Example

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

{% prettify dart tag=pre+code %}
class A {}

class B extends A implements [!A!] {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
mixin class A {}

class B extends A with [!A!] {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class A {}

class B extends A {}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class A {}

class B implements A {}
{% endprettify %}

### implicit_super_initializer_missing_arguments

_The implicitly invoked unnamed constructor from '{0}' has required parameters._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  [!B!]();
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class A {
  A({required int x});
}

class B extends A {
  [!B!]();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A({required int x});
}

class B extends A {
  B({required super.x});
}
{% endprettify %}

or it can be optional:

{% prettify dart tag=pre+code %}
class A {
  A({required int x});
}

class B extends A {
  B({super.x = 0});
}
{% endprettify %}

If you can't add a parameter to the constructor in the subclass, then add
an explicit super constructor invocation with the required argument:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B() : super(0);
}
{% endprettify %}

### implicit_this_reference_in_initializer

_The instance member '{0}' can't be accessed in an initializer._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int x;

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

  int get defaultX => 0;
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  int x;

  C() : x = defaultX;

  static int get defaultX => 0;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int x;

  C() : x = 0;

  int get defaultX => 0;
}
{% endprettify %}

### import_deferred_library_with_load_function

_The imported library defines a top-level function named 'loadLibrary' that is
hidden by deferring this library._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

Given a file `a.dart` that defines a function named `loadLibrary`:

{% prettify dart tag=pre+code %}
void loadLibrary(Library library) {}

class Library {}
{% endprettify %}

The following code produces this diagnostic because the implicit
declaration of `a.loadLibrary` is hiding the explicit declaration of
`loadLibrary` in `a.dart`:

{% prettify dart tag=pre+code %}
[!import 'a.dart' deferred as a;!]

void f() {
  a.Library();
}
{% endprettify %}

#### Common fixes

If the imported library isn't required to be deferred, then remove the
keyword `deferred`:

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

void f() {
  a.Library();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void populateLibrary(Library library) {}

class Library {}
{% endprettify %}

If the imported library is required to be deferred and you don't need to
reference the imported function, then add a `hide` clause:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a hide loadLibrary;

void f() {
  a.Library();
}
{% endprettify %}

### import_internal_library

_The library '{0}' is internal and can't be imported._

#### 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:

{% prettify dart tag=pre+code %}
import [!'dart:_interceptors'!];
{% endprettify %}

#### Common fixes

Remove the import directive.

### import_of_legacy_library_into_null_safe

_The library '{0}' is legacy, and shouldn't be imported into a null safe
library._

#### 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 `a.dart` that contains the following:

{% prettify dart tag=pre+code %}
// @dart = 2.9

class A {}
{% endprettify %}

The following code produces this diagnostic because a library that null
safe is importing a library that isn't null safe:

{% prettify dart tag=pre+code %}
import [!'a.dart'!];

A? f() => null;
{% endprettify %}

#### 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.

### import_of_non_library

_The imported library '{0}' can't have a part-of directive._

#### 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:

{% prettify dart tag=pre+code %}
part of lib;
{% endprettify %}

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

{% prettify dart tag=pre+code %}
library lib;

import [!'part.dart'!];
{% endprettify %}

#### Common fixes

Import the library that contains the [part file][] rather than the
[part file][] itself.

### inconsistent_inheritance

_Superinterfaces don't have a valid override for '{0}': {1}._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  void m({int a}) {}
}

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

class [!C!] extends A implements B {
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class A {
  void m({int a}) {}
}

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

class C extends A implements B {
  void m({int a, int b}) {}
}
{% endprettify %}

### inconsistent_language_version_override

_Parts must have exactly the same language version override as the library._

#### 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:

{% prettify dart tag=pre+code %}
// @dart = 2.14
part of 'test.dart';
{% endprettify %}

The following code produces this diagnostic because the parts of a library
must have the same language version as the defining compilation unit:

{% prettify dart tag=pre+code %}
// @dart = 2.15
part [!'part.dart'!];
{% endprettify %}

#### Common fixes

Remove the language version override from the [part file][], so that it
implicitly uses the same version as the defining compilation unit:

{% prettify dart tag=pre+code %}
part of 'test.dart';
{% endprettify %}

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.

### inconsistent_pattern_variable_logical_or

_The variable '{0}' has a different type and/or finality in this branch of the
logical-or pattern._

#### Description

The analyzer produces this diagnostic when a pattern variable that is
declared on all branches of a logical-or pattern doesn't have the same
type on every branch. It is also produced when the variable has a
different finality on different branches. A pattern variable declared on
multiple branches of a logical-or pattern is required to have the same
type and finality in each branch, so that the type and finality of the
variable can be known in code that's guarded by the logical-or pattern.

#### Examples

The following code produces this diagnostic because the variable `a` is
defined to be an `int` on one branch and a `double` on the other:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  if (x case (int a) || (double [!a!])) {
    print(a);
  }
}
{% endprettify %}

The following code produces this diagnostic because the variable `a` is
`final` in the first branch and isn't `final` in the second branch:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  if (x case (final int a) || (int [!a!])) {
    print(a);
  }
}
{% endprettify %}

#### Common fixes

If the finality of the variable is different, decide whether it should be
`final` or not `final` and make the cases consistent:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  if (x case (int a) || (int a)) {
    print(a);
  }
}
{% endprettify %}

If the type of the variable is different and the type isn't critical to
the condition being matched, then ensure that the variable has the same
type on both branches:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  if (x case (num a) || (num a)) {
    print(a);
  }
}
{% endprettify %}

If the type of the variable is different and the type is critical to the
condition being matched, then consider breaking the condition into
multiple `if` statements or `case` clauses:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  if (x case int a) {
    print(a);
  } else if (x case double a) {
    print(a);
  }
}
{% endprettify %}

### initializer_for_non_existent_field

_'{0}' isn't a field in the enclosing class._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int y;

  C() : [!x = 0!];
}
{% endprettify %}

#### Common fixes

If a different field should be initialized, then change the name to the
name of the field:

{% prettify dart tag=pre+code %}
class C {
  int y;

  C() : y = 0;
}
{% endprettify %}

If the field must be declared, then add a declaration:

{% prettify dart tag=pre+code %}
class C {
  int x;
  int y;

  C() : x = 0;
}
{% endprettify %}

### initializer_for_static_field

_'{0}' is a static field in the enclosing class. Fields initialized in a
constructor can't be static._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  static int? a;
  C([!this.a!]);
}
{% endprettify %}

#### Common fixes

If the field should be an instance field, then remove the keyword `static`:

{% prettify dart tag=pre+code %}
class C {
  int? a;
  C(this.a);
}
{% endprettify %}

If you intended to initialize an instance field and typed the wrong name,
then correct the name of the field being initialized:

{% prettify dart tag=pre+code %}
class C {
  static int? a;
  int? b;
  C(this.b);
}
{% endprettify %}

If you really want to initialize the static field, then move the
initialization into the constructor body:

{% prettify dart tag=pre+code %}
class C {
  static int? a;
  C(int? c) {
    a = c;
  }
}
{% endprettify %}

### initializing_formal_for_non_existent_field

_'{0}' isn't a field in the enclosing class._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int y;

  C([!this.x!]);
}
{% endprettify %}

#### Common fixes

If the field name was wrong, then change it to the name of an existing
field:

{% prettify dart tag=pre+code %}
class C {
  int y;

  C(this.y);
}
{% endprettify %}

If the field name is correct but hasn't yet been defined, then declare the
field:

{% prettify dart tag=pre+code %}
class C {
  int x;
  int y;

  C(this.x);
}
{% endprettify %}

If the parameter is needed but shouldn't initialize a field, then convert
it to a normal parameter and use it:

{% prettify dart tag=pre+code %}
class C {
  int y;

  C(int x) : y = x * 2;
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
class C {
  int y;

  C();
}
{% endprettify %}

### instance_access_to_static_member

_The static {1} '{0}' can't be accessed through an instance._

#### 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:

{% prettify dart tag=pre+code %}
void f(C c) {
  c.[!zero!];
}

class C {
  static int zero = 0;
}
{% endprettify %}

#### Common fixes

Use the class to access the static member:

{% prettify dart tag=pre+code %}
void f(C c) {
  C.zero;
}

class C {
  static int zero = 0;
}
{% endprettify %}

### instance_member_access_from_factory

_Instance members can't be accessed from a factory constructor._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int x;
  factory C() {
    return C._([!x!]);
  }
  C._(this.x);
}
{% endprettify %}

#### Common fixes

Rewrite the code so that it doesn't reference the instance member:

{% prettify dart tag=pre+code %}
class C {
  int x;
  factory C() {
    return C._(0);
  }
  C._(this.x);
}
{% endprettify %}

### instance_member_access_from_static

_Instance members can't be accessed from a static method._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int x;

  static int m() {
    return [!x!];
  }
}
{% endprettify %}

#### Common fixes

If the method must reference the instance member, then it can't be static,
so remove the keyword:

{% prettify dart tag=pre+code %}
class C {
  int x;

  int m() {
    return x;
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  int x;

  static int m(C c) {
    return c.x;
  }
}
{% endprettify %}

### instantiate_abstract_class

_Abstract classes can't be instantiated._

#### 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:

{% prettify dart tag=pre+code %}
abstract class C {}

var c = new [!C!]();
{% endprettify %}

#### 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

_Enums can't be instantiated._

#### 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:

{% prettify dart tag=pre+code %}
// @dart = 2.16
enum E {a}

var e = [!E!]();
{% endprettify %}

#### Common fixes

If you intend to use an instance of the enum, then reference one of the
constants defined in the enum:

{% prettify dart tag=pre+code %}
// @dart = 2.16
enum E {a}

var e = E.a;
{% endprettify %}

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

_Type aliases that expand to a type parameter can't be instantiated._

#### 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:

{% prettify dart tag=pre+code %}
typedef A<T> = T;

void f() {
  const [!A!]<int>();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
typedef A<T> = C<T>;

void f() {
  const A<int>();
}

class C<T> {
  const C();
}
{% endprettify %}

### integer_literal_imprecise_as_double

_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}'._

#### 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:

{% prettify dart tag=pre+code %}
double x = [!9223372036854775807!];
{% endprettify %}

#### Common fixes

If you need to use the exact value, then use the class `BigInt` to
represent the value:

{% prettify dart tag=pre+code %}
var x = BigInt.parse('9223372036854775807');
{% endprettify %}

If you need to use a double, then change the value to one that can be
represented exactly:

{% prettify dart tag=pre+code %}
double x = 9223372036854775808;
{% endprettify %}

### integer_literal_out_of_range

_The integer literal {0} can't be represented in 64 bits._

#### 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:

{% prettify dart tag=pre+code %}
var x = [!9223372036854775810!];
{% endprettify %}

#### Common fixes

If you need to represent the current value, then wrap it in an instance of
the class `BigInt`:

{% prettify dart tag=pre+code %}
var x = BigInt.parse('9223372036854775810');
{% endprettify %}

### invalid_annotation

_Annotation must be either a const variable reference or const constructor
invocation._

#### 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:

{% prettify dart tag=pre+code %}
var v = 0;

[!@v!]
void f() {
}
{% endprettify %}

The following code produces this diagnostic because `f` isn't a variable:

{% prettify dart tag=pre+code %}
[!@f!]
void f() {
}
{% endprettify %}

The following code produces this diagnostic because `f` isn't a
constructor:

{% prettify dart tag=pre+code %}
[!@f()!]
void f() {
}
{% endprettify %}

The following code produces this diagnostic because `g` is a getter:

{% prettify dart tag=pre+code %}
[!@g!]
int get g => 0;
{% endprettify %}

#### Common fixes

If the annotation is referencing a variable that isn't a `const`
constructor, add the keyword `const` to the variable's declaration:

{% prettify dart tag=pre+code %}
const v = 0;

@v
void f() {
}
{% endprettify %}

If the annotation isn't referencing a variable, then remove it:

{% prettify dart tag=pre+code %}
int v = 0;

void f() {
}
{% endprettify %}

### invalid_annotation_constant_value_from_deferred_library

_Constant values from a deferred library can't be used in annotations._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#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:

{% prettify dart tag=pre+code %}
import 'dart:math' deferred as math;

class C {
  const C(double d);
}

@C(math.[!pi!])
void f () {}
{% endprettify %}

#### Common fixes

If you need to reference the imported constant, then remove the `deferred`
keyword:

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

class C {
  const C(double d);
}

@C(math.pi)
void f () {}
{% endprettify %}

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

_Constant values from a deferred library can't be used as annotations._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#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`:

{% prettify dart tag=pre+code %}
import 'dart:math' deferred as math;

@[!math.pi!]
void f() {}
{% endprettify %}

#### Common fixes

If you need to reference the constant as an annotation, then remove the
keyword `deferred` from the import:

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

@math.pi
void f() {}
{% endprettify %}

If you can use a different constant as an annotation, then replace the
annotation with a different constant:

{% prettify dart tag=pre+code %}
@deprecated
void f() {}
{% endprettify %}

### invalid_annotation_target

_The annotation '{0}' can only be used on {1}._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@[!optionalTypeArgs!]
int x = 0;
{% endprettify %}

#### Common fixes

Remove the annotation from the declaration.

### invalid_assignment

_A value of type '{0}' can't be assigned to a variable of type '{1}'._

#### 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`):

{% prettify dart tag=pre+code %}
int i = 0;
String s = [!i!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int i = 0;
String s = i.toString();
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
int i = 0;
int s = i;
{% endprettify %}

### invalid_dependency

_Publishable packages can't have '{0}' dependencies._

#### 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
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
name: example
publish_to: none
dependencies:
  transmogrify:
    hosted:
      name: transmogrify
      url: http://your-package-server.com
    version: ^1.4.0
```

### invalid_exception_value

_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'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because a second argument is
provided when the return type of `f` is `void`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = Void Function(Int8);

void f(int i) {}

void g() {
  Pointer.fromFunction<T>(f, [!42!]);
}
{% endprettify %}

#### Common fixes

Remove the exception value:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = Void Function(Int8);

void f(int i) {}

void g() {
  Pointer.fromFunction<T>(f);
}
{% endprettify %}

### invalid_export_of_internal_element

_The member '{0}' can't be exported as a part of a package's public API._

#### 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 `a.dart` in the `src` directory that contains:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@internal class One {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
[!export 'src/a.dart';!]
{% endprettify %}

#### Common fixes

If the export is needed, then add a `hide` clause to hide the internal
names:

{% prettify dart tag=pre+code %}
export 'src/a.dart' hide One;
{% endprettify %}

If the export isn't needed, then remove it.

### invalid_export_of_internal_element_indirectly

_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}'._

#### 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 `a.dart` in the `src` directory that contains the
following:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@internal
typedef IntFunction = int Function();

int f(IntFunction g) => g();
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
[!export 'src/a.dart' show f;!]
{% endprettify %}

#### 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_extension_argument_count

_Extension overrides must have exactly one argument: the value of 'this' in the
extension method._

#### 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:

{% prettify dart tag=pre+code %}
extension E on String {
  String join(String other) => '$this $other';
}

void f() {
  E[!()!].join('b');
}
{% endprettify %}

And, the following code produces this diagnostic because there's more than
one argument:

{% prettify dart tag=pre+code %}
extension E on String {
  String join(String other) => '$this $other';
}

void f() {
  E[!('a', 'b')!].join('c');
}
{% endprettify %}

#### Common fixes

Provide one argument for the extension override:

{% prettify dart tag=pre+code %}
extension E on String {
  String join(String other) => '$this $other';
}

void f() {
  E('a').join('b');
}
{% endprettify %}

### invalid_factory_method_decl

_Factory method '{0}' must have a return type._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class Factory {
  @factory
  void [!createC!]() {}
}

class C {}
{% endprettify %}

#### Common fixes

Change the return type to something other than `void`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class Factory {
  @factory
  C createC() => C();
}

class C {}
{% endprettify %}

### invalid_factory_method_impl

_Factory method '{0}' doesn't return a newly allocated object._

#### 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`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class Factory {
  C c = C();

  @factory
  C [!createC!]() => c;
}

class C {}
{% endprettify %}

#### Common fixes

Change the method to return a newly created instance of the return type:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class Factory {
  @factory
  C createC() => C();
}

class C {}
{% endprettify %}

### invalid_factory_name_not_a_class

_The name of a factory constructor must be the same as the name of the
immediately enclosing class._

#### 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`):

{% prettify dart tag=pre+code %}
class A {}

class C {
  factory [!A!]() => throw 0;
}
{% endprettify %}

#### Common fixes

If the factory returns an instance of the surrounding class, and you
intend it to be an unnamed factory constructor, then rename the factory:

{% prettify dart tag=pre+code %}
class A {}

class C {
  factory C() => throw 0;
}
{% endprettify %}

If the factory returns an instance of the surrounding class, and you
intend it to be a named factory constructor, then prefix the name of the
factory constructor with the name of the surrounding class:

{% prettify dart tag=pre+code %}
class A {}

class C {
  factory C.a() => throw 0;
}
{% endprettify %}

If the factory returns an instance of a different class, then move the
factory to that class:

{% prettify dart tag=pre+code %}
class A {
  factory A() => throw 0;
}

class C {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {}

class C {
  static A a() => throw 0;
}
{% endprettify %}

### invalid_field_name

_Record field names can't be a dollar sign followed by an integer when the
integer is the index of a positional field._

_Record field names can't be private._

_Record field names can't be the same as a member from 'Object'._

#### Description

The analyzer produces this diagnostic when either a record literal or a
record type annotation has a field whose name is invalid. The name is
invalid if it is:
- private (starts with `_`)
- the same as one of the members defined on `Object`
- the same as the name of a positional field (an exception is made if the
  field is a positional field with the specified name)

#### Examples

The following code produces this diagnostic because the record literal has
a field named `toString`, which is a method defined on `Object`:

{% prettify dart tag=pre+code %}
var r = (a: 1, [!toString!]: 4);
{% endprettify %}

The following code produces this diagnostic because the record type
annotation has a field named `hashCode`, which is a getter defined on
`Object`:

{% prettify dart tag=pre+code %}
void f(({int a, int [!hashCode!]}) r) {}
{% endprettify %}

The following code produces this diagnostic because the record literal has
a private field named `_a`:

{% prettify dart tag=pre+code %}
var r = ([!_a!]: 1, b: 2);
{% endprettify %}

The following code produces this diagnostic because the record type
annotation has a private field named `_a`:

{% prettify dart tag=pre+code %}
void f(({int [!_a!], int b}) r) {}
{% endprettify %}

The following code produces this diagnostic because the record literal has
a field named `$1`, which is also the name of a different positional
parameter:

{% prettify dart tag=pre+code %}
var r = (2, [!$1!]: 1);
{% endprettify %}

The following code produces this diagnostic because the record type
annotation has a field named `$1`, which is also the name of a different
positional parameter:

{% prettify dart tag=pre+code %}
void f((int, String, {int [!$1!]}) r) {}
{% endprettify %}

#### Common fixes

Rename the field:

{% prettify dart tag=pre+code %}
var r = (a: 1, d: 4);
{% endprettify %}

### invalid_field_type_in_struct

_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'._

#### 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][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`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  external [!String!] s;

  @Int32()
  external int i;
}
{% endprettify %}

#### Common fixes

Use one of the allowed types for the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';
import 'package:ffi/ffi.dart';

final class C extends Struct {
  external Pointer<Utf8> s;

  @Int32()
  external int i;
}
{% endprettify %}

### invalid_implementation_override

_'{1}.{0}' ('{2}') isn't a valid concrete implementation of '{3}.{0}' ('{4}')._

_The setter '{1}.{0}' ('{2}') isn't a valid concrete implementation of '{3}.{0}'
('{4}')._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  int add(int a) => a;
}
class [!B!] extends A {
  int add(num a);
}
{% endprettify %}

This is a problem because in an invocation of `B.add` like the following:

{% prettify dart tag=pre+code %}
void f(B b) {
  b.add(3.4);
}
{% endprettify %}

`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):

{% prettify dart tag=pre+code %}
class A {
  int add(int a) => a;
}
class B	extends A {
  int add(int a);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  int add(num a) => a.floor();
}
class B	extends A {
  int add(num a);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  int add(int a) => a;
}
class B	extends A {
  int add(num a) => a.floor();
}
{% endprettify %}

### invalid_inline_function_type

_Inline function types can't be used for parameters in a generic function type._

#### 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:

{% prettify dart tag=pre+code %}
typedef F = int Function(int f[!(!]String s));
{% endprettify %}

#### Common fixes

Use the generic function syntax for the parameter's type:

{% prettify dart tag=pre+code %}
typedef F = int Function(int Function(String));
{% endprettify %}

### invalid_internal_annotation

_Only public elements in a package's private API can be annotated as being
internal._

#### 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][]:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@internal!]
class C {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@internal!]
class _C {}

void f(_C c) {}
{% endprettify %}

#### Common fixes

If the declaration has a private name, then remove the annotation:

{% prettify dart tag=pre+code %}
class _C {}

void f(_C c) {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

### invalid_language_version_override

_The Dart language version override comment can't be followed by any
non-whitespace characters._

_The Dart language version override comment must be specified with a version
number, like '2.0', after the '=' character._

_The Dart language version override comment must be specified with an '='
character._

_The Dart language version override comment must be specified with exactly two
slashes._

_The Dart language version override comment must be specified with the word
'dart' in all lower case._

_The Dart language version override number can't be prefixed with a letter._

_The Dart language version override number must begin with '@dart'._

_The language version override can't specify a version greater than the latest
known language version: {0}.{1}._

_The language version override must be specified before any declaration or
directive._

#### 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:

{% prettify dart tag=pre+code %}
[!// @Dart 2.13!]
{% endprettify %}

#### Common fixes

If the comment is intended to be a language version override, then change
the comment to follow the correct format:

{% prettify dart tag=pre+code %}
// @dart = 2.13
{% endprettify %}

### invalid_literal_annotation

_Only const constructors can have the `@literal` annotation._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  [!@literal!]
  C();
}
{% endprettify %}

The following code produces this diagnostic because `x` isn't a
constructor:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@literal!]
var x;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @literal
  const C();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
var x;
{% endprettify %}

### invalid_modifier_on_constructor

_The modifier '{0}' can't be applied to the body of a constructor._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  C() [!async!] {}
}
{% endprettify %}

#### Common fixes

If the constructor can be synchronous, then remove the modifier:

{% prettify dart tag=pre+code %}
class C {
  C();
}
{% endprettify %}

If the constructor can't be synchronous, then use a static method to create
the instance instead:

{% prettify dart tag=pre+code %}
class C {
  C();
  static Future<C> c() async {
    return C();
  }
}
{% endprettify %}

### invalid_modifier_on_setter

_Setters can't use 'async', 'async*', or 'sync*'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  set x(int i) [!async!] {}
}
{% endprettify %}

#### Common fixes

If the setter can be synchronous, then remove the modifier:

{% prettify dart tag=pre+code %}
class C {
  set x(int i) {}
}
{% endprettify %}

If the setter can't be synchronous, then use a method to set the value
instead:

{% prettify dart tag=pre+code %}
class C {
  void x(int i) async {}
}
{% endprettify %}

### invalid_non_virtual_annotation

_The annotation '@nonVirtual' can only be applied to a concrete instance
member._

#### Description

The analyzer produces this diagnostic when the `nonVirtual` annotation is
found on a declaration other than a member of a class, mixin, or enum, or
if the member isn't a concrete instance member.

#### Examples

The following code produces this diagnostic because the annotation is on a
class declaration rather than a member inside the class:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@nonVirtual!]
class C {}
{% endprettify %}

The following code produces this diagnostic because the method `m` is an
abstract method:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

abstract class C {
  [!@nonVirtual!]
  void m();
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

abstract class C {
  [!@nonVirtual!]
  static void m() {}
}
{% endprettify %}

#### Common fixes

If the declaration isn't a member of a class, mixin, or enum, then remove
the annotation:

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

If the member is intended to be a concrete instance member, then make it
so:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

abstract class C {
  @nonVirtual
  void m() {}
}
{% endprettify %}

If the member is not intended to be a concrete instance member, then
remove the annotation:

{% prettify dart tag=pre+code %}
abstract class C {
  static void m() {}
}
{% endprettify %}

### invalid_null_aware_operator

_The receiver can't be null because of short-circuiting, so the null-aware
operator '{0}' can't be used._

_The receiver can't be null, so the null-aware operator '{0}' is unnecessary._

#### 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`:

{% prettify dart tag=pre+code %}
int? getLength(String s) {
  return s[!?.!]length;
}
{% endprettify %}

The following code produces this diagnostic because `a` can't be `null`:

{% prettify dart tag=pre+code %}
var a = [];
var b = [[!...?!]a];
{% endprettify %}

The following code produces this diagnostic because `s?.length` can't
return `null`:

{% prettify dart tag=pre+code %}
void f(String? s) {
  s?.length[!?.!]isEven;
}
{% endprettify %}

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`.

{% prettify dart tag=pre+code %}
void f(Object? o) {
  var s = o as String;
  s[!?.!]length;
}
{% endprettify %}

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  `.`:

{% prettify dart tag=pre+code %}
int getLength(String s) {
  return s.length;
}
{% endprettify %}

(Note that the return type was also changed to be non-nullable, which might
not be appropriate in some cases.)

### invalid_override

_'{1}.{0}' ('{2}') isn't a valid override of '{3}.{0}' ('{4}')._

_The setter '{1}.{0}' ('{2}') isn't a valid override of '{3}.{0}' ('{4}')._

#### 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`):

{% prettify dart tag=pre+code %}
class A {
  void m(int i) {}
}

class B extends A {
  void [!m!](String s) {}
}
{% endprettify %}

#### Common fixes

If the invalid method is intended to override the method from the
superclass, then change it to conform:

{% prettify dart tag=pre+code %}
class A {
  void m(int i) {}
}

class B extends A {
  void m(int i) {}
}
{% endprettify %}

If it isn't intended to override the method from the superclass, then
rename it:

{% prettify dart tag=pre+code %}
class A {
  void m(int i) {}
}

class B extends A {
  void m2(String s) {}
}
{% endprettify %}

### invalid_override_of_non_virtual_member

_The member '{0}' is declared non-virtual in '{1}' and can't be overridden in
subclasses._

#### Description

The analyzer produces this diagnostic when a member of a class, mixin, or
enum overrides a member that has the `@nonVirtual` annotation on it.

#### Example

The following code produces this diagnostic because the method `m` in `B`
overrides the method `m` in `A`, and the method `m` in `A` is annotated
with the `@nonVirtual` annotation:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @nonVirtual
  void m() {}
}

class B extends A {
  @override
  void [!m!]() {}
}
{% endprettify %}

#### Common fixes

If the annotation on the method in the superclass is correct (the method
in the superclass is not intended to be overridden), then remove or rename
the overriding method:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @nonVirtual
  void m() {}
}

class B extends A {}
{% endprettify %}

If the method in the superclass is intended to be overridden, then remove
the `@nonVirtual` annotation:

{% prettify dart tag=pre+code %}
class A {
  void m() {}
}

class B extends A {
  @override
  void m() {}
}
{% endprettify %}

### invalid_pattern_variable_in_shared_case_scope

_The variable '{0}' doesn't have the same type and/or finality in all cases that
share this body._

_The variable '{0}' is available in some, but not all cases that share this
body._

_The variable '{0}' is not available because there is a label or 'default'
case._

#### Description

The analyzer produces this diagnostic when multiple case clauses in a
switch statement share a body, and at least one of them declares a
variable that is referenced in the shared statements, but the variable is
either not declared in all of the case clauses or it is declared in
inconsistent ways.

If the variable isn't declared in all of the case clauses, then it won't
have a value if one of the clauses that doesn't declare the variable is
the one that matches and executes the body. This includes the situation
where one of the case clauses is the `default` clause.

If the variable is declared in inconsistent ways, either being `final` in
some cases and not `final` in others or having a different type in
different cases, then the semantics of what the type or finality of the
variable should be are not defined.

#### Examples

The following code produces this diagnostic because the variable `a` is
only declared in one of the case clauses, and won't have a value if the
second clause is the one that matched `x`:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case int a when a > 0:
    case 0:
      [!a!];
  }
}
{% endprettify %}

The following code produces this diagnostic because the variable `a` isn't
declared in the `default` clause, and won't have a value if the body is
executed because none of the other clauses matched `x`:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case int a when a > 0:
    default:
      [!a!];
  }
}
{% endprettify %}

The following code produces this diagnostic because the variable `a` won't
have a value if the body is executed because a different group of cases
caused control to continue at the label:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    someLabel:
    case int a when a > 0:
      [!a!];
    case int b when b < 0:
      continue someLabel;
  }
}
{% endprettify %}

The following code produces this diagnostic because the variable `a`,
while being assigned in all of the case clauses, doesn't have then same
type associated with it in every clause:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case int a when a < 0:
    case num a when a > 0:
      [!a!];
  }
}
{% endprettify %}

The following code produces this diagnostic because the variable `a` is
`final` in the first case clause and isn't `final` in the second case
clause:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case final int a when a < 0:
    case int a when a > 0:
      [!a!];
  }
}
{% endprettify %}

#### Common fixes

If the variable isn't declared in all of the cases, and you need to
reference it in the statements, then declare it in the other cases:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case int a when a > 0:
    case int a when a == 0:
      a;
  }
}
{% endprettify %}

If the variable isn't declared in all of the cases, and you don't need to
reference it in the statements, then remove the references to it and
remove the declarations from the other cases:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case > 0:
    case 0:
  }
}
{% endprettify %}

If the type of the variable is different, decide the type the variable
should have and make the cases consistent:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case num a when a < 0:
    case num a when a > 0:
      a;
  }
}
{% endprettify %}

If the finality of the variable is different, decide whether it should be
`final` or not `final` and make the cases consistent:

{% prettify dart tag=pre+code %}
void f(Object? x) {
  switch (x) {
    case final int a when a < 0:
    case final int a when a > 0:
      a;
  }
}
{% endprettify %}

### invalid_platforms_field

_The 'platforms' field must be a map with platforms as keys._

#### Description

The analyzer produces this diagnostic when a top-level `platforms`
field is specified, but its value is not a map with keys.
See the [documentation on platform declaration](https://dart.dev/tools/pub/pubspec#platforms)
for details.

#### Example

The following `pubspec.yaml` produces this diagnostic because `platforms`
should be a map.

```yaml
name: example
platforms:
  [!- android
  - web
  - ios!]
```

#### Common fixes

If you can rely on automatic platform detection, then omit the
top-level `platforms` field. 

```yaml
name: example
```

If you need to manually specify the list of supported platforms, then
write the `platforms` field as a map with platform names as keys.

```yaml
name: example
platforms:
  android:
  web:
  ios:
```

### invalid_reference_to_generative_enum_constructor

_Generative enum constructors can only be used as targets of redirection._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  a(0);

  const E(int x);
}

E f() => const [!E!](2);
{% endprettify %}

#### Common fixes

If there's an enum constant with the same value, or if you add such a
constant, then reference the constant directly:

{% prettify dart tag=pre+code %}
enum E {
  a(0), b(2);

  const E(int x);
}

E f() => E.b;
{% endprettify %}

If you need to use a constructor invocation, then use a factory
constructor:

{% prettify dart tag=pre+code %}
enum E {
  a(0);

  const E(int x);

  factory E.c(int x) => a;
}

E f() => E.c(2);
{% endprettify %}

### invalid_reference_to_this

_Invalid reference to 'this' expression._

#### 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:

{% prettify dart tag=pre+code %}
C f() => [!this!];

class C {}
{% endprettify %}

#### Common fixes

Use a variable of the appropriate type in place of `this`, declaring it if
necessary:

{% prettify dart tag=pre+code %}
C f(C c) => c;

class C {}
{% endprettify %}

### invalid_return_type_for_catch_error

_A value of type '{0}' can't be returned by the 'onError' handler because it
must be assignable to '{1}'._

_The return type '{0}' isn't assignable to '{1}', as required by
'Future.catchError'._

#### 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`:

{% prettify dart tag=pre+code %}
void f(Future<int> future, String Function(dynamic, StackTrace) callback) {
  future.catchError([!callback!]);
}
{% endprettify %}

The following code produces this diagnostic because the closure being
passed to `catchError` returns an `int` while `future` is declared to
return a `String`:

{% prettify dart tag=pre+code %}
void f(Future<String> future) {
  future.catchError((error, stackTrace) => [!3!]);
}
{% endprettify %}

#### Common fixes

If the instance of `Future` is declared correctly, then change the callback
to match:

{% prettify dart tag=pre+code %}
void f(Future<int> future, int Function(dynamic, StackTrace) callback) {
  future.catchError(callback);
}
{% endprettify %}

If the declaration of the instance of `Future` is wrong, then change it to
match the callback:

{% prettify dart tag=pre+code %}
void f(Future<String> future, String Function(dynamic, StackTrace) callback) {
  future.catchError(callback);
}
{% endprettify %}

### invalid_sealed_annotation

_The annotation '@sealed' can only be applied to classes._

#### Description

The analyzer produces this diagnostic when a declaration other than a
class declaration has the `@sealed` annotation on it.

#### Example

The following code produces this diagnostic because the `@sealed`
annotation is on a method declaration:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  [!@sealed!]
  void m() {}
}
{% endprettify %}

#### Common fixes

Remove the annotation:

{% prettify dart tag=pre+code %}
class A {
  void m() {}
}
{% endprettify %}

### invalid_super_formal_parameter_location

_Super parameters can only be used in non-redirecting generative constructors._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B.b([!super!].x) : this._();
  B._() : super(0);
}
{% endprettify %}

The following code produces this diagnostic because the super parameter
`x` isn't in a generative constructor:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class C extends A {
  factory C.c([!super!].x) => C._();
  C._() : super(0);
}
{% endprettify %}

The following code produces this diagnostic because the super parameter
`x` is in a method:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class D extends A {
  D() : super(0);

  void m([!super!].x) {}
}
{% endprettify %}

#### Common fixes

If the function containing the super parameter can be changed to be a
non-redirecting generative constructor, then do so:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B.b(super.x);
}
{% endprettify %}

If the function containing the super parameter can't be changed to be a
non-redirecting generative constructor, then remove the `super`:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class D extends A {
  D() : super(0);

  void m(int x) {}
}
{% endprettify %}

### invalid_type_argument_in_const_literal

_Constant list literals can't include a type parameter as a type argument, such
as '{0}'._

_Constant map literals can't include a type parameter as a type argument, such
as '{0}'._

_Constant set literals can't include a type parameter as a type argument, such
as '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
List<T> newList<T>() => const <[!T!]>[];
{% endprettify %}

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

{% prettify dart tag=pre+code %}
Map<String, T> newSet<T>() => const <String, [!T!]>{};
{% endprettify %}

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

{% prettify dart tag=pre+code %}
Set<T> newSet<T>() => const <[!T!]>{};
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
List<int> newList() => const <int>[];
{% endprettify %}

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

{% prettify dart tag=pre+code %}
List<T> newList<T>() => <T>[];
{% endprettify %}

### invalid_uri

_Invalid URI syntax: '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
import [!'#'!];
{% endprettify %}

#### Common fixes

Replace the invalid URI with a valid URI.

### invalid_use_of_covariant_in_extension

_Can't have modifier '{0}' in an extension._

#### Description

The analyzer produces this diagnostic when a member declared inside an
extension uses the keyword `covariant` in the declaration of a parameter.
Extensions aren't classes and don't have subclasses, so the keyword serves
no purpose.

#### Example

The following code produces this diagnostic because `i` is marked as being
covariant:

{% prettify dart tag=pre+code %}
extension E on String {
  void a([!covariant!] int i) {}
}
{% endprettify %}

#### Common fixes

Remove the `covariant` keyword:

{% prettify dart tag=pre+code %}
extension E on String {
  void a(int i) {}
}
{% endprettify %}

### invalid_use_of_internal_member

_The member '{0}' can only be used within its package._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@internal
class C {}
{% endprettify %}

The following code produces this diagnostic because it's referencing the
class `C`, which isn't intended to be used outside the package `p`:

{% prettify dart tag=pre+code %}
import 'package:p/src/p.dart';

void f([!C!] c) {}
{% endprettify %}

#### Common fixes

Remove the reference to the internal declaration.

### invalid_use_of_null_value

_An expression whose value is always 'null' can't be dereferenced._

#### 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`:

{% prettify dart tag=pre+code %}
int f(Null x) {
  return x.[!length!];
}
{% endprettify %}

#### Common fixes

If the value is allowed to be something other than `null`, then change the
type of the expression:

{% prettify dart tag=pre+code %}
int f(String? x) {
  return x!.length;
}
{% endprettify %}

### invalid_use_of_type_outside_library

_The class '{0}' can't be extended outside of its library because it's a final
class._

_The class '{0}' can't be extended outside of its library because it's an
interface class._

_The class '{0}' can't be extended, implemented, or mixed in outside of its
library because it's a sealed class._

_The class '{0}' can't be implemented outside of its library because it's a base
class._

_The class '{0}' can't be implemented outside of its library because it's a
final class._

_The class '{0}' can't be used as a mixin superclass constraint outside of its
library because it's a final class._

_The mixin '{0}' can't be implemented outside of its library because it's a base
mixin._

#### Description

The analyzer produces this diagnostic when an `extends`, `implements`,
`with`, or `on` clause uses a class or mixin in a way that isn't allowed
given the modifiers on that class or mixin's declaration.

The message specifies how the declaration is being used and why it isn't
allowed.

#### Example

Given a file `a.dart` that defines a base class `A`:

{% prettify dart tag=pre+code %}
base class A {}
{% endprettify %}

The following code produces this diagnostic because the class `B`
implements the class `A`, but the `base` modifier prevents `A` from being
implemented outside of the library where it's defined:

{% prettify dart tag=pre+code %}
import 'a.dart';

final class B implements [!A!] {}
{% endprettify %}

#### Common fixes

Use of this type is restricted outside of its declaring library. If a
different, unrestricted type is available that can provide similar
functionality, then replace the type:

{% prettify dart tag=pre+code %}
class B implements C {}
class C {}
{% endprettify %}

If there isn't a different type that would be appropriate, then remove the
type, and possibly the whole clause:

{% prettify dart tag=pre+code %}
class B {}
{% endprettify %}

### invalid_use_of_visible_for_overriding_member

_The member '{0}' can only be used for overriding._

#### 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 `a.dart` containing the following declaration:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @visibleForOverriding
  void a() {}
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart';

class B extends A {
  void b() {
    [!a!]();
  }
}
{% endprettify %}

#### Common fixes

Remove the invalid use of the member.

### invalid_use_of_visible_for_testing_member

_The member '{0}' can only be used within '{1}' or a test._

#### Description

The analyzer produces this diagnostic when a member annotated with
`@visibleForTesting` is referenced anywhere other than the library in
which it is declared or in a library in the `test` directory.

#### Example

Given a file `c.dart` that contains the following:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @visibleForTesting
  void m() {}
}
{% endprettify %}

The following code, when not inside the `test` directory, produces this
diagnostic because the method `m` is marked as being visible only for
tests:

{% prettify dart tag=pre+code %}
import 'c.dart';

void f(C c) {
  c.[!m!]();
}
{% endprettify %}

#### Common fixes

If the annotated member should not be referenced outside of tests, then
remove the reference:

{% prettify dart tag=pre+code %}
import 'c.dart';

void f(C c) {}
{% endprettify %}

If it's OK to reference the annotated member outside of tests, then remove
the annotation:

{% prettify dart tag=pre+code %}
class C {
  void m() {}
}
{% endprettify %}

### invalid_visibility_annotation

_The member '{0}' is annotated with '{1}', but this annotation is only
meaningful on declarations of public members._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@visibleForTesting!]
void _someFunction() {}

void f() => _someFunction();
{% endprettify %}

#### Common fixes

If the declaration doesn't need to be used by test code, then remove the
annotation:

{% prettify dart tag=pre+code %}
void _someFunction() {}

void f() => _someFunction();
{% endprettify %}

If it does, then make it public:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@visibleForTesting
void someFunction() {}

void f() => someFunction();
{% endprettify %}

### invalid_visible_for_overriding_annotation

_The annotation 'visibleForOverriding' can only be applied to a public instance
member that can be overridden._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

[!@visibleForOverriding!]
class C {}
{% endprettify %}

#### Common fixes

Remove the annotation:

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

### invalid_visible_outside_template_annotation

_The annotation 'visibleOutsideTemplate' can only be applied to a member of a
class, enum, or mixin that is annotated with 'visibleForTemplate'._

#### Description

The analyzer produces this diagnostic when the `@visibleOutsideTemplate`
annotation is used incorrectly. This annotation is only meant to annotate
members of a class, enum, or mixin that has the `@visibleForTemplate`
annotation, to opt those members out of the visibility restrictions that
`@visibleForTemplate` imposes.

#### Examples

The following code produces this diagnostic because there is no
`@visibleForTemplate` annotation at the class level:

{% prettify dart tag=pre+code %}
import 'package:angular_meta/angular_meta.dart';

class C {
  [!@visibleOutsideTemplate!]
  int m() {
    return 1;
  }
}
{% endprettify %}

The following code produces this diagnostic because the annotation is on
a class declaration, not a member of a class, enum, or mixin:

{% prettify dart tag=pre+code %}
import 'package:angular_meta/angular_meta.dart';

[!@visibleOutsideTemplate!]
class C {}
{% endprettify %}

#### Common fixes

If the class is only visible so that templates can reference it, then add
the `@visibleForTemplate` annotation to the class:

{% prettify dart tag=pre+code %}
import 'package:angular_meta/angular_meta.dart';

@visibleForTemplate
class C {
  @visibleOutsideTemplate
  int m() {
    return 1;
  }
}
{% endprettify %}

If the `@visibleOutsideTemplate` annotation is on anything other than a
member of a class, enum, or mixin with the `@visibleForTemplate`
annotation, remove the annotation:

{% prettify dart tag=pre+code %}
class C {}
{% endprettify %}

### invocation_of_extension_without_call

_The extension '{0}' doesn't define a 'call' method so the override can't be
used in an invocation._

#### 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:

{% prettify dart tag=pre+code %}
extension E on String {}

void f() {
  [!E('')!]();
}
{% endprettify %}

#### Common fixes

If the extension is intended to define a `call` method, then declare it:

{% prettify dart tag=pre+code %}
extension E on String {
  int call() => 0;
}

void f() {
  E('')();
}
{% endprettify %}

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

_'{0}' isn't a function._

#### 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:

{% prettify dart tag=pre+code %}
typedef Binary = int Function(int, int);

int f() {
  return [!Binary!](1, 2);
}
{% endprettify %}

#### Common fixes

Replace the name with the name of a function.

### invocation_of_non_function_expression

_The expression doesn't evaluate to a function, so it can't be invoked._

#### 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:

{% prettify dart tag=pre+code %}
int x = 0;

int f() => x;

var y = [!x!]();
{% endprettify %}

The following code produces this diagnostic because `f()` doesn't return a
function:

{% prettify dart tag=pre+code %}
int x = 0;

int f() => x;

var y = [!f()!]();
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int x = 0;

int f() => x;

var y = f();
{% endprettify %}

### label_in_outer_scope

_Can't reference label '{0}' declared in an outer method._

#### 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`:

{% prettify dart tag=pre+code %}
void f() {
  loop:
  while (true) {
    void g() {
      break [!loop!];
    }

    g();
  }
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  loop:
  while (true) {
    break loop;
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void f() {
  loop:
  while (true) {
    bool g() {
      return true;
    }

    if (g()) {
      break loop;
    }
  }
}
{% endprettify %}

### label_undefined

_Can't reference an undefined label '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  for (int i = 0; i < 10; i++) {
    for (int j = 0; j < 10; j++) {
      if (j != 0) {
        break [!loop!];
      }
    }
  }
}
{% endprettify %}

#### Common fixes

If the label should be on the innermost enclosing `do`, `for`, `switch`, or
`while` statement, then remove the label:

{% prettify dart tag=pre+code %}
void f() {
  for (int i = 0; i < 10; i++) {
    for (int j = 0; j < 10; j++) {
      if (j != 0) {
        break;
      }
    }
  }
}
{% endprettify %}

If the label should be on some other statement, then add the label:

{% prettify dart tag=pre+code %}
void f() {
  loop: for (int i = 0; i < 10; i++) {
    for (int j = 0; j < 10; j++) {
      if (j != 0) {
        break loop;
      }
    }
  }
}
{% endprettify %}

### late_final_field_with_const_constructor

_Can't have a late final field in a class with a generative const constructor._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  [!late!] final int f;

  const A();
}
{% endprettify %}

#### Common fixes

If the field doesn't need to be marked `late`, then remove the `late`
modifier from the field:

{% prettify dart tag=pre+code %}
class A {
  final int f = 0;

  const A();
}
{% endprettify %}

If the field must be marked `late`, then remove the `const` modifier from
the constructors:

{% prettify dart tag=pre+code %}
class A {
  late final int f;

  A();
}
{% endprettify %}

### late_final_local_already_assigned

_The late final local variable is already assigned._

#### 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:

{% prettify dart tag=pre+code %}
int f() {
  late final int v;
  v = 0;
  [!v!] += 1;
  return v;
}
{% endprettify %}

#### Common fixes

If you need to be able to reassign the variable, then remove the `final`
keyword:

{% prettify dart tag=pre+code %}
int f() {
  late int v;
  v = 0;
  v += 1;
  return v;
}
{% endprettify %}

If you don't need to reassign the variable, then remove all except the
first of the assignments:

{% prettify dart tag=pre+code %}
int f() {
  late final int v;
  v = 0;
  return v;
}
{% endprettify %}

### leaf_call_must_not_return_handle

_FFI leaf call can't return a 'Handle'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the function `p`
returns a `Handle`, but the `isLeaf` argument is `true`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Handle Function()>> p) {
  [!p.asFunction<Object Function()>(isLeaf: true)!];
}
{% endprettify %}

#### Common fixes

If the function returns a handle, then remove the `isLeaf` argument:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Handle Function()>> p) {
  p.asFunction<Object Function()>();
}
{% endprettify %}

If the function returns one of the supported types, then correct the type
information:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Int32 Function()>> p) {
  p.asFunction<int Function()>(isLeaf: true);
}
{% endprettify %}

### leaf_call_must_not_take_handle

_FFI leaf call can't take arguments of type 'Handle'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the function `p` has a
parameter of type `Handle`, but the `isLeaf` argument is `true`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Void Function(Handle)>> p) {
  [!p.asFunction<void Function(Object)>(isLeaf: true)!];
}
{% endprettify %}

#### Common fixes

If the function has at least one parameter of type `Handle`, then remove
the `isLeaf` argument:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Void Function(Handle)>> p) {
  p.asFunction<void Function(Object)>();
}
{% endprettify %}

If none of the function's parameters are `Handle`s, then correct the type
information:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(Pointer<NativeFunction<Void Function(Int8)>> p) {
  p.asFunction<void Function(int)>(isLeaf: true);
}
{% endprettify %}

### list_element_type_not_assignable

_The element type '{0}' can't be assigned to the list type '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
List<int> x = [1, [!2.5!], 3];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
List<int> x = [1, 2, 3];
{% endprettify %}

If the object shouldn't be in the list, then remove the element:

{% prettify dart tag=pre+code %}
List<int> x = [1, 3];
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
List<num> x = [1, 2.5, 3];
{% endprettify %}

### main_first_positional_parameter_type

_The type of the first positional parameter of the 'main' function must be a
supertype of 'List<String>'._

#### 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>`:

{% prettify dart tag=pre+code %}
void main([!List<int>!] args) {}
{% endprettify %}

#### 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>`:

{% prettify dart tag=pre+code %}
void main(List<String> args) {}
{% endprettify %}

If the function isn't an entry point, then change the name of the function:

{% prettify dart tag=pre+code %}
void f(List<int> args) {}
{% endprettify %}

### main_has_required_named_parameters

_The function 'main' can't have any required named parameters._

#### 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`):

{% prettify dart tag=pre+code %}
void [!main!]({required int x}) {}
{% endprettify %}

#### Common fixes

If the function is an entry point, then remove the `required` keyword:

{% prettify dart tag=pre+code %}
void main({int? x}) {}
{% endprettify %}

If the function isn't an entry point, then change the name of the function:

{% prettify dart tag=pre+code %}
void f({required int x}) {}
{% endprettify %}

### main_has_too_many_required_positional_parameters

_The function 'main' can't have more than two required positional parameters._

#### 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:

{% prettify dart tag=pre+code %}
void [!main!](List<String> args, int x, int y) {}
{% endprettify %}

#### Common fixes

If the function is an entry point and the extra parameters aren't used,
then remove them:

{% prettify dart tag=pre+code %}
void main(List<String> args, int x) {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void main(List<String> args, int x, [int y = 0]) {}
{% endprettify %}

If the function isn't an entry point, then change the name of the function:

{% prettify dart tag=pre+code %}
void f(List<String> args, int x, int y) {}
{% endprettify %}

### main_is_not_function

_The declaration named 'main' must be a function._

#### 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:

{% prettify dart tag=pre+code %}
var [!main!] = 3;
{% endprettify %}

#### Common fixes

Use a different name for the declaration:

{% prettify dart tag=pre+code %}
var mainIndex = 3;
{% endprettify %}

### map_entry_not_in_map

_Map entries can only be used in a map literal._

#### 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:

{% prettify dart tag=pre+code %}
const collection = <String>{[!'a' : 'b'!]};
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
const collection = <String, String>{'a' : 'b'};
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
const collection = <String>{'a', 'b'};
{% endprettify %}

### map_key_type_not_assignable

_The element type '{0}' can't be assigned to the map key type '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
var m = <String, String>{[!2!] : 'a'};
{% endprettify %}

#### Common fixes

If the type of the map is correct, then change the key to have the correct
type:

{% prettify dart tag=pre+code %}
var m = <String, String>{'2' : 'a'};
{% endprettify %}

If the type of the key is correct, then change the key type of the map:

{% prettify dart tag=pre+code %}
var m = <int, String>{2 : 'a'};
{% endprettify %}

### map_value_type_not_assignable

_The element type '{0}' can't be assigned to the map value type '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
var m = <String, String>{'a' : [!2!]};
{% endprettify %}

#### Common fixes

If the type of the map is correct, then change the value to have the
correct type:

{% prettify dart tag=pre+code %}
var m = <String, String>{'a' : '2'};
{% endprettify %}

If the type of the value is correct, then change the value type of the map:

{% prettify dart tag=pre+code %}
var m = <String, int>{'a' : 2};
{% endprettify %}

### mismatched_annotation_on_struct_field

_The annotation doesn't match the declared type of the field._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the annotation
`Double` doesn't match the Dart type `int`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  [!@Double()!]
  external int x;
}
{% endprettify %}

#### Common fixes

If the type of the field is correct, then change the annotation to match:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  external int x;
}
{% endprettify %}

If the annotation is correct, then change the type of the field to match:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Double()
  external double x;
}
{% endprettify %}

### missing_annotation_on_struct_field

_Fields of type '{0}' in a subclass of '{1}' must have an annotation indicating
the native type._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  external [!int!] x;
}
{% endprettify %}

#### Common fixes

Add an appropriate annotation to the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int64()
  external int x;
}
{% endprettify %}

### missing_dart_library

_Required library '{0}' is missing._

#### 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

_The parameter '{0}' can't have a value of 'null' because of its type, but the
implicit default value is 'null'._

_With null safety, use the 'required' keyword, not the '@required' annotation._

#### 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:

{% prettify dart tag=pre+code %}
void f([int [!x!]]) {}
{% endprettify %}

As does this:

{% prettify dart tag=pre+code %}
void g({int [!x!]}) {}
{% endprettify %}

#### Common fixes

If you want to use `null` to indicate that no value was provided, then you
need to make the type nullable:

{% prettify dart tag=pre+code %}
void f([int? x]) {}
void g({int? x}) {}
{% endprettify %}

If the parameter can't be null, then either provide a default value:

{% prettify dart tag=pre+code %}
void f([int x = 1]) {}
void g({int x = 2}) {}
{% endprettify %}

or make the parameter a required parameter:

{% prettify dart tag=pre+code %}
void f(int x) {}
void g({required int x}) {}
{% endprettify %}

### missing_enum_constant_in_switch

_Missing case clause for '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
enum E { e1, e2 }

void f(E e) {
  [!switch (e)!] {
    case E.e1:
      break;
  }
}
{% endprettify %}

#### Common fixes

If there's special handling for the missing values, then add a `case`
clause for each of the missing values:

{% prettify dart tag=pre+code %}
enum E { e1, e2 }

void f(E e) {
  switch (e) {
    case E.e1:
      break;
    case E.e2:
      break;
  }
}
{% endprettify %}

If the missing values should be handled the same way, then add a `default`
clause:

{% prettify dart tag=pre+code %}
enum E { e1, e2 }

void f(E e) {
  switch (e) {
    case E.e1:
      break;
    default:
      break;
  }
}
{% endprettify %}

### missing_exception_value

_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'._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int f(int i) => i * 2;

void g() {
  Pointer.[!fromFunction!]<Int8 Function(Int8)>(f);
}
{% endprettify %}

#### Common fixes

Add an exceptional return type:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int f(int i) => i * 2;

void g() {
  Pointer.fromFunction<Int8 Function(Int8)>(f, 0);
}
{% endprettify %}

### missing_field_type_in_struct

_Fields in struct classes must have an explicitly declared type of 'int',
'double' or 'Pointer'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the field `str`
doesn't have a type annotation:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  external var [!str!];

  @Int32()
  external int i;
}
{% endprettify %}

#### Common fixes

Explicitly specify the type of the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';
import 'package:ffi/ffi.dart';

final class C extends Struct {
  external Pointer<Utf8> str;

  @Int32()
  external int i;
}
{% endprettify %}

### missing_name

_The 'name' field is required but missing._

#### 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
dependencies:
  meta: ^1.0.2
```

#### Common fixes

Add the top-level key `name` with a value that's the name of the package:

```yaml
name: example
dependencies:
  meta: ^1.0.2
```

### missing_named_pattern_field_name

_The getter name is not specified explicitly, and the pattern is not a
variable._

#### Description

The analyzer produces this diagnostic when, within an object pattern, the
specification of a property and the pattern used to match the property's
value doesn't have either:

- a getter name before the colon
- a variable pattern from which the getter name can be inferred

#### Example

The following code produces this diagnostic because there is no getter
name before the colon and no variable pattern after the colon in the
object pattern (`C(:0)`):

{% prettify dart tag=pre+code %}
abstract class C {
  int get f;
}

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

#### Common fixes

If you need to use the actual value of the property within the pattern's
scope, then add a variable pattern where the name of the variable is the
same as the name of the property being matched:

{% prettify dart tag=pre+code %}
abstract class C {
  int get f;
}

void f(C c) {
  switch (c) {
    case C(:var f) when f == 0:
      print(f);
  }
}
{% endprettify %}

If you don't need to use the actual value of the property within the
pattern's scope, then add the name of the property being matched before
the colon:

{% prettify dart tag=pre+code %}
abstract class C {
  int get f;
}

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

### missing_override_of_must_be_overridden

_Missing concrete implementation of '{0}'._

_Missing concrete implementations of '{0}' and '{1}'._

_Missing concrete implementations of '{0}', '{1}', and {2} more._

#### Description

The analyzer produces this diagnostic when an instance member that has the
`@mustBeOverridden` annotation isn't overridden in a subclass.

#### Example

The following code produces this diagnostic because the class `B` doesn't
have an override of the inherited method `A.m` when `A.m` is annotated
with `@mustBeOverridden`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @mustBeOverridden
  void m() {}
}

class [!B!] extends A {}
{% endprettify %}

#### Common fixes

If the annotation is appropriate for the member, then override the member
in the subclass:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @mustBeOverridden
  void m() {}
}

class B extends A {
  @override
  void m() {}
}
{% endprettify %}

If the annotation isn't appropriate for the member, then remove the
annotation:

{% prettify dart tag=pre+code %}
class A {
  void m() {}
}

class B extends A {}
{% endprettify %}

### missing_required_argument

_The named parameter '{0}' is required, but there's no corresponding argument._

#### 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`:

{% prettify dart tag=pre+code %}
void f(int start, {required int end}) {}
void g() {
  [!f!](3);
}
{% endprettify %}

#### Common fixes

Add a named argument corresponding to the missing required parameter:

{% prettify dart tag=pre+code %}
void f(int start, {required int end}) {}
void g() {
  f(3, end: 5);
}
{% endprettify %}

### missing_required_param

_The parameter '{0}' is required._

_The parameter '{0}' is required. {1}._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

void f({@required int x}) {}

void g() {
  [!f!]();
}
{% endprettify %}

#### Common fixes

Provide the required value:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

void f({@required int x}) {}

void g() {
  f(x: 2);
}
{% endprettify %}

### missing_return

_This function has a return type of '{0}', but doesn't end with a return
statement._

#### 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:

{% prettify dart tag=pre+code %}
int [!f!](int x) {
  if (x < 0) {
    return 0;
  }
}
{% endprettify %}

#### Common fixes

Add a `return` statement that makes the return value explicit, even if
`null` is the appropriate value.

### missing_size_annotation_carray

_Fields of type 'Array' must have exactly one 'Array' annotation._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the field `a0` doesn't
have an `Array` annotation:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  external [!Array<Uint8>!] a0;
}
{% endprettify %}

#### Common fixes

Ensure that there's exactly one `Array` annotation on the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8)
  external Array<Uint8> a0;
}
{% endprettify %}

### missing_variable_pattern

_Variable pattern '{0}' is missing in this branch of the logical-or pattern._

#### Description

The analyzer produces this diagnostic when one branch of a logical-or
pattern doesn't declare a variable that is declared on the other branch of
the same pattern.

#### Example

The following code produces this diagnostic because the right-hand side of
the logical-or pattern doesn't declare the variable `a`:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (var a, 0) || [!(0, _)!]) {
    print(a);
  }
}
{% endprettify %}

#### Common fixes

If the variable needs to be referenced in the controlled statements, then
add a declaration of the variable to every branch of the logical-or
pattern:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (var a, 0) || (0, var a)) {
    print(a);
  }
}
{% endprettify %}

If the variable doesn't need to be referenced in the controlled
statements, then remove the declaration of the variable from every branch
of the logical-or pattern:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  if (r case (_, 0) || (0, _)) {
    print('found a zero');
  }
}
{% endprettify %}

If the variable needs to be referenced if one branch of the pattern
matches but not when the other matches, then break the pattern into two
pieces:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  switch (r) {
    case (var a, 0):
      print(a);
    case (0, _):
      print('found a zero');
  }
}
{% endprettify %}

### mixin_application_concrete_super_invoked_member_type

_The super-invoked member '{0}' has the type '{1}', and the concrete member in
the class has the type '{2}'._

#### 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`:

{% prettify dart tag=pre+code %}
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!] {}
{% endprettify %}

#### Common fixes

If the class doesn't need to use the mixin, then remove it from the `with`
clause:

{% prettify dart tag=pre+code %}
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 {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
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 {}
{% endprettify %}

### mixin_application_not_implemented_interface

_'{0}' can't be mixed onto '{1}' because '{1}' doesn't implement '{2}'._

#### 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`:

{% prettify dart tag=pre+code %}
class A {}

mixin M on A {}

class X = Object with [!M!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A {}

mixin M on A {}

class X = A with M;
{% endprettify %}

### mixin_application_no_concrete_super_invoked_member

_The class doesn't have a concrete implementation of the super-invoked member
'{0}'._

_The class doesn't have a concrete implementation of the super-invoked setter
'{0}'._

#### 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`:

{% prettify dart tag=pre+code %}
abstract class A {
  void m();
}

mixin M on A {
  void bar() {
    super.m();
  }
}

abstract class B extends A with [!M!] {}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
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 {}
{% endprettify %}

If you need to make `B` a subclass of `A`, then add a concrete
implementation of `m` in `A`:

{% prettify dart tag=pre+code %}
abstract class A {
  void m() {}
}

mixin M on A {
  void bar() {
    super.m();
  }
}

abstract class B extends A with M {}
{% endprettify %}

### mixin_class_declaration_extends_not_object

_The class '{0}' can't be declared a mixin because it extends a class other than
'Object'._

#### Description

The analyzer produces this diagnostic when a class that is marked with
the `mixin` modifier extends a class other than `Object`. A mixin class
can't have a superclass other than `Object`.

#### Example

The following code produces this diagnostic because the class `B`, which
has the modifier `mixin`, extends `A`:

{% prettify dart tag=pre+code %}
class A {}

mixin class B extends [!A!] {}
{% endprettify %}

#### Common fixes

If you want the class to be used as a mixin, then change the superclass to
`Object`, either explicitly or by removing the extends clause:

{% prettify dart tag=pre+code %}
class A {}

mixin class B {}
{% endprettify %}

If the class needs to have a superclass other than `Object`, then remove
the `mixin` modifier:

{% prettify dart tag=pre+code %}
class A {}

class B extends A {}
{% endprettify %}

If you need both a mixin and a subclass of a class other than `Object`,
then move the members of the subclass to a new mixin, remove the `mixin`
modifier from the subclass, and apply the new mixin to the subclass:

{% prettify dart tag=pre+code %}
class A {}

class B extends A with M {}

mixin M {}
{% endprettify %}

Depending on the members of the subclass this might require adding an `on`
clause to the mixin.

### mixin_class_declares_constructor

_The class '{0}' can't be used as a mixin because it declares a constructor._

#### 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:

{% prettify dart tag=pre+code %}
//@dart=2.19
class A {
  A();
}

class B with [!A!] {}
{% endprettify %}

#### Common fixes

If it's possible to convert the class to a mixin, then do so:

{% prettify dart tag=pre+code %}
mixin A {
}

class B with A {}
{% endprettify %}

If the class can't be a mixin and it's possible to remove the constructor,
then do so:

{% prettify dart tag=pre+code %}
//@dart=2.19
class A {
}

class B with A {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  A();
}

class B extends A {}
{% endprettify %}

### mixin_inherits_from_not_object

_The class '{0}' can't be used as a mixin because it extends a class other than
'Object'._

#### 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`:

{% prettify dart tag=pre+code %}
//@dart=2.19
class A {}

class B extends A {}

class C with [!B!] {}
{% endprettify %}

#### Common fixes

If the class being used as a mixin can be changed to extend `Object`, then
change it:

{% prettify dart tag=pre+code %}
//@dart=2.19
class A {}

class B {}

class C with B {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {}

class B extends A {}

class C extends B {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {}

mixin M on A {}

class B extends A with M {}

class C extends A with M {}
{% endprettify %}

### mixin_instantiate

_Mixins can't be instantiated._

#### 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:

{% prettify dart tag=pre+code %}
mixin M {}

var m = [!M!]();
{% endprettify %}

#### 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

_Classes can only mix in mixins and classes._

#### 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:

{% prettify dart tag=pre+code %}
typedef F = int Function(String);

class C with [!F!] {}
{% endprettify %}

#### Common fixes

Remove the invalid name from the list, possibly replacing it with the name
of the intended mixin or class:

{% prettify dart tag=pre+code %}
typedef F = int Function(String);

class C {}
{% endprettify %}

### mixin_on_sealed_class

_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._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@sealed
class C {}
{% endprettify %}

Then, the following code, when in a package other than `p`, produces this
diagnostic:

{% prettify dart tag=pre+code %}
import 'package:p/p.dart';

[!mixin M on C {}!]
{% endprettify %}

#### 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.

### mixin_super_class_constraint_deferred_class

_Deferred classes can't be used as superclass constraints._

#### Description

The analyzer produces this diagnostic when a superclass constraint of a
mixin is imported from a deferred library.

#### Example

The following code produces this diagnostic because the superclass
constraint of `math.Random` is imported from a deferred library:

{% prettify dart tag=pre+code %}
import 'dart:async' deferred as async;

mixin M<T> on [!async.Stream<T>!] {}
{% endprettify %}

#### Common fixes

If the import doesn't need to be deferred, then remove the `deferred`
keyword:

{% prettify dart tag=pre+code %}
import 'dart:async' as async;

mixin M<T> on async.Stream<T> {}
{% endprettify %}

If the import does need to be deferred, then remove the superclass
constraint:

{% prettify dart tag=pre+code %}
mixin M<T> {}
{% endprettify %}

### mixin_super_class_constraint_non_interface

_Only classes and mixins can be used as superclass constraints._

#### 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:

{% prettify dart tag=pre+code %}
typedef F = void Function();

mixin M on [!F!] {}
{% endprettify %}

#### 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.

### multiple_redirecting_constructor_invocations

_Constructors can have only one 'this' redirection, at most._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  C() : this.a(), [!this.b()!];
  C.a();
  C.b();
}
{% endprettify %}

#### Common fixes

Remove all but one of the redirections:

{% prettify dart tag=pre+code %}
class C {
  C() : this.a();
  C.a();
  C.b();
}
{% endprettify %}

### multiple_super_initializers

_A constructor can have at most one 'super' initializer._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  int? x;
  String? s;
  A.one(this.x);
  A.two(this.s);
}

class B extends A {
  B() : super.one(0), [!super.two('')!];
}
{% endprettify %}

#### Common fixes

If one of the super constructors will initialize the instance fully, then
remove the other:

{% prettify dart tag=pre+code %}
class A {
  int? x;
  String? s;
  A.one(this.x);
  A.two(this.s);
}

class B extends A {
  B() : super.one(0);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  int? x;
  String? s;
  A.one(this.x);
  A.two(this.s);
}

class B extends A {
  B() : super.one(0) {
    s = '';
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
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, '');
}
{% endprettify %}

### must_be_a_native_function_type

_The type '{0}' given to '{1}' must be a valid 'dart:ffi' native function type._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int f(int i) => i * 2;

class C<T extends Function> {
  void g() {
    Pointer.fromFunction<[!T!]>(f, 0);
  }
}
{% endprettify %}

#### Common fixes

Use a native function type as the type argument to the invocation:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int f(int i) => i * 2;

class C<T extends Function> {
  void g() {
    Pointer.fromFunction<Int32 Function(Int32)>(f, 0);
  }
}
{% endprettify %}

### must_be_a_subtype

_The type '{0}' must be a subtype of '{1}' for '{2}'._

#### 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][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)`):

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = Int8 Function(Int8);

double f(double i) => i;

void g() {
  Pointer.fromFunction<T>([!f!], 5.0);
}
{% endprettify %}

#### Common fixes

If the function is correct, then change the type argument to match:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = Float Function(Float);

double f(double i) => i;

void g() {
  Pointer.fromFunction<T>(f, 5.0);
}
{% endprettify %}

If the type argument is correct, then change the function to match:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = Int8 Function(Int8);

int f(int i) => i;

void g() {
  Pointer.fromFunction<T>(f, 5);
}
{% endprettify %}

### must_be_immutable

_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}_

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@immutable
class [!C!] {
  int x;

  C(this.x);
}
{% endprettify %}

#### Common fixes

If instances of the class should be immutable, then add the keyword `final`
to all non-final field declarations:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@immutable
class C {
  final int x;

  C(this.x);
}
{% endprettify %}

If the instances of the class should be mutable, then remove the
annotation, or choose a different superclass if the annotation is
inherited:

{% prettify dart tag=pre+code %}
class C {
  int x;

  C(this.x);
}
{% endprettify %}

### must_call_super

_This method overrides a method annotated as '@mustCallSuper' in '{0}', but
doesn't invoke the overridden method._

#### 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`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @mustCallSuper
  m() {}
}

class B extends A {
  @override
  [!m!]() {}
}
{% endprettify %}

#### Common fixes

Add an invocation of the overridden method in the overriding method:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {
  @mustCallSuper
  m() {}
}

class B extends A {
  @override
  m() {
    super.m();
  }
}
{% endprettify %}

### must_return_void

_The return type of the function passed to 'NativeCallable.listener' must be
'void' rather than '{0}'._

#### Description

The analyzer produces this diagnostic when you pass a function
that doesn't return `void` to the `NativeCallable.listener` constructor.

`NativeCallable.listener` creates a native callable that can be invoked
from any thread. The native code that invokes the callable sends a message
back to the isolate that created the callable, and doesn't wait for a
response. So it isn't possible to return a result from the callable.

For more information about FFI, see [C interop using dart:ffi][ffi].

#### Example

The following code produces this diagnostic because the function
`f` returns `int` rather than `void`.

{% prettify dart tag=pre+code %}
import 'dart:ffi';

int f(int i) => i * 2;

void g() {
  NativeCallable<Int32 Function(Int32)>.listener([!f!]);
}
{% endprettify %}

#### Common fixes

Change the return type of the function to `void`.

{% prettify dart tag=pre+code %}
import 'dart:ffi';

void f(int i) => print(i * 2);

void g() {
  NativeCallable<Void Function(Int32)>.listener(f);
}
{% endprettify %}

### name_not_string

_The value of the 'name' field is required to be a string._

#### 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
name:
  - example
```

#### Common fixes

Replace the value with a string:

```yaml
name: example
```

### new_with_undefined_constructor_default

_The class '{0}' doesn't have an unnamed constructor._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A.a();
}

A f() => [!A!]();
{% endprettify %}

#### Common fixes

If one of the named constructors does what you need, then use it:

{% prettify dart tag=pre+code %}
class A {
  A.a();
}

A f() => A.a();
{% endprettify %}

If none of the named constructors does what you need, and you're able to
add an unnamed constructor, then add the constructor:

{% prettify dart tag=pre+code %}
class A {
  A();
  A.a();
}

A f() => A();
{% endprettify %}

### non_abstract_class_inherits_abstract_member

_Missing concrete implementation of '{0}'._

_Missing concrete implementations of '{0}' and '{1}'._

_Missing concrete implementations of '{0}', '{1}', '{2}', '{3}', and {4} more._

_Missing concrete implementations of '{0}', '{1}', '{2}', and '{3}'._

_Missing concrete implementations of '{0}', '{1}', and '{2}'._

#### 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`:

{% prettify dart tag=pre+code %}
abstract class A {
  void m();
}

class [!B!] extends A {}
{% endprettify %}

#### Common fixes

If the subclass can provide a concrete implementation for some or all of
the abstract inherited members, then add the concrete implementations:

{% prettify dart tag=pre+code %}
abstract class A {
  void m();
}

class B extends A {
  void m() {}
}
{% endprettify %}

If there is a mixin that provides an implementation of the inherited
methods, then apply the mixin to the subclass:

{% prettify dart tag=pre+code %}
abstract class A {
  void m();
}

class B extends A with M {}

mixin M {
  void m() {}
}
{% endprettify %}

If the subclass can't provide a concrete implementation for all of the
abstract inherited members, then mark the subclass as being abstract:

{% prettify dart tag=pre+code %}
abstract class A {
  void m();
}

abstract class B extends A {}
{% endprettify %}

### non_bool_condition

_Conditions must have a static type of 'bool'._

#### 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`:

{% prettify dart tag=pre+code %}
void f(int x) {
  if ([!x!]) {
    // ...
  }
}
{% endprettify %}

#### Common fixes

Change the condition so that it produces a Boolean value:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x == 0) {
    // ...
  }
}
{% endprettify %}

### non_bool_expression

_The expression in an assert must be of type 'bool'._

#### 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:

{% prettify dart tag=pre+code %}
void f(int p) {
  assert([!p!]);
}
{% endprettify %}

#### Common fixes

Change the expression so that it has the type `bool`:

{% prettify dart tag=pre+code %}
void f(int p) {
  assert(p > 0);
}
{% endprettify %}

### non_bool_negation_expression

_A negation operand must have a static type of 'bool'._

#### 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`:

{% prettify dart tag=pre+code %}
int x = 0;
bool y = ![!x!];
{% endprettify %}

#### Common fixes

Replace the operand with an expression that has the type `bool`:

{% prettify dart tag=pre+code %}
int x = 0;
bool y = !(x > 0);
{% endprettify %}

### non_bool_operand

_The operands of the operator '{0}' must be assignable to 'bool'._

#### 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:

{% prettify dart tag=pre+code %}
int a = 3;
bool b = [!a!] || a > 1;
{% endprettify %}

#### Common fixes

Change the operand to a Boolean value:

{% prettify dart tag=pre+code %}
int a = 3;
bool b = a == 0 || a > 1;
{% endprettify %}

### non_constant_annotation_constructor

_Annotation creation can only call a const constructor._

#### 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:

{% prettify dart tag=pre+code %}
[!@C()!]
void f() {
}

class C {
  C();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
@C()
void f() {
}

class C {
  const C();
}
{% endprettify %}

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

_Case expressions must be constant._

#### 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:

{% prettify dart tag=pre+code %}
void f(int i, int j) {
  switch (i) {
    case [!j!]:
      // ...
      break;
  }
}
{% endprettify %}

#### Common fixes

Either make the expression a constant expression, or rewrite the `switch`
statement as a sequence of `if` statements:

{% prettify dart tag=pre+code %}
void f(int i, int j) {
  if (i == j) {
    // ...
  }
}
{% endprettify %}

### non_constant_case_expression_from_deferred_library

_Constant values from a deferred library can't be used as a case expression._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

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

{% prettify dart tag=pre+code %}
const zero = 0;
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

void f(int x) {
  switch (x) {
    case a.[!zero!]:
      // ...
      break;
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

void f(int x) {
  switch (x) {
    case a.zero:
      // ...
      break;
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

void f(int x) {
  if (x == a.zero) {
    // ...
  }
}
{% endprettify %}

If you don't need to reference the constant, then replace the case
expression:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case 0:
      // ...
      break;
  }
}
{% endprettify %}

### non_constant_default_value

_The default value of an optional parameter must be constant._

#### 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:

{% prettify dart tag=pre+code %}
var defaultValue = 3;

void f([int value = [!defaultValue!]]) {}
{% endprettify %}

#### Common fixes

If the default value can be converted to be a constant, then convert it:

{% prettify dart tag=pre+code %}
const defaultValue = 3;

void f([int value = defaultValue]) {}
{% endprettify %}

If the default value needs to change over time, then apply the default
value inside the function:

{% prettify dart tag=pre+code %}
var defaultValue = 3;

void f([int value]) {
  value ??= defaultValue;
}
{% endprettify %}

### non_constant_default_value_from_deferred_library

_Constant values from a deferred library can't be used as a default parameter
value._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

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

{% prettify dart tag=pre+code %}
const zero = 0;
{% endprettify %}

The following code produces this diagnostic because `zero` is declared in a
library imported using a deferred import:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

void f({int x = a.[!zero!]}) {}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

void f({int x = a.zero}) {}
{% endprettify %}

If you don't need to reference the constant, then replace the default
value:

{% prettify dart tag=pre+code %}
void f({int x = 0}) {}
{% endprettify %}

### non_constant_list_element

_The values in a const list literal must be constants._

#### 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:

{% prettify dart tag=pre+code %}
var x = 2;
var y = const <int>[0, 1, [!x!]];
{% endprettify %}

#### 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`:

{% prettify dart tag=pre+code %}
const x = 2;
var y = const <int>[0, 1, x];
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
var x = 2;
var y = <int>[0, 1, x];
{% endprettify %}

### non_constant_map_element

_The elements in a const map literal must be constant._

#### 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:

{% prettify dart tag=pre+code %}
var notConst = <int, int>{};
var map = const <int, int>{...[!notConst!]};
{% endprettify %}

Similarly, the following code produces this diagnostic because the
condition in the `if` element isn't a constant expression:

{% prettify dart tag=pre+code %}
bool notConst = true;
var map = const <int, int>{if ([!notConst!]) 1 : 2};
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
const notConst = <int, int>{};
var map = const <int, int>{...notConst};
{% endprettify %}

If the map doesn't need to be a constant map, then remove the `const`
keyword:

{% prettify dart tag=pre+code %}
bool notConst = true;
var map = <int, int>{if (notConst) 1 : 2};
{% endprettify %}

### non_constant_map_key

_The keys in a const map literal must be constant._

#### 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:

{% prettify dart tag=pre+code %}
var a = 'a';
var m = const {[!a!]: 0};
{% endprettify %}

#### Common fixes

If the map needs to be a constant map, then make the key a constant:

{% prettify dart tag=pre+code %}
const a = 'a';
var m = const {a: 0};
{% endprettify %}

If the map doesn't need to be a constant map, then remove the `const`
keyword:

{% prettify dart tag=pre+code %}
var a = 'a';
var m = {a: 0};
{% endprettify %}

### non_constant_map_pattern_key

_Key expressions in map patterns must be constants._

#### Description

The analyzer produces this diagnostic when a key in a map pattern isn't a
constant expression.

#### Example

The following code produces this diagnostic because the key `A()` isn't a
constant:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case {[!A()!]: 0}) {}
}

class A {
  const A();
}
{% endprettify %}

#### Common fixes

Use a constant for the key:

{% prettify dart tag=pre+code %}
void f(Object x) {
  if (x case {const A(): 0}) {}
}

class A {
  const A();
}
{% endprettify %}

### non_constant_map_value

_The values in a const map literal must be constant._

#### 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:

{% prettify dart tag=pre+code %}
var a = 'a';
var m = const {0: [!a!]};
{% endprettify %}

#### Common fixes

If the map needs to be a constant map, then make the key a constant:

{% prettify dart tag=pre+code %}
const a = 'a';
var m = const {0: a};
{% endprettify %}

If the map doesn't need to be a constant map, then remove the `const`
keyword:

{% prettify dart tag=pre+code %}
var a = 'a';
var m = {0: a};
{% endprettify %}

### non_constant_relational_pattern_expression

_The relational pattern expression must be a constant._

#### Description

The analyzer produces this diagnostic when the value in a relational
pattern expression isn't a constant expression.

#### Example

The following code produces this diagnostic because the operand of the `>`
operator, `a`, isn't a constant:

{% prettify dart tag=pre+code %}
final a = 0;

void f(int x) {
  if (x case > [!a!]) {}
}
{% endprettify %}

#### Common fixes

Replace the value with a constant expression:

{% prettify dart tag=pre+code %}
const a = 0;

void f(int x) {
  if (x case > a) {}
}
{% endprettify %}

### non_constant_set_element

_The values in a const set literal must be constants._

#### 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:

{% prettify dart tag=pre+code %}
var i = 0;

var s = const {[!i!]};
{% endprettify %}

#### Common fixes

If the element can be changed to be a constant, then change it:

{% prettify dart tag=pre+code %}
const i = 0;

var s = const {i};
{% endprettify %}

If the element can't be a constant, then remove the keyword `const`:

{% prettify dart tag=pre+code %}
var i = 0;

var s = {i};
{% endprettify %}

### non_constant_type_argument

_The type arguments to '{0}' must be known at compile time, so they can't be
type parameters._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef T = int Function(int);

class C<R extends T> {
  void m(Pointer<NativeFunction<T>> p) {
    p.asFunction<[!R!]>();
  }
}
{% endprettify %}

#### Common fixes

Remove any uses of type parameters:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

class C {
  void m(Pointer<NativeFunction<Int64 Function(Int64)>> p) {
    p.asFunction<int Function(int)>();
  }
}
{% endprettify %}

### non_const_call_to_literal_constructor

_This instance creation must be 'const', because the {0} constructor is marked
as '@literal'._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @literal
  const C();
}

C f() => [!C()!];
{% endprettify %}

#### Common fixes

Add the keyword `const` before the constructor invocation:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @literal
  const C();
}

void f() => const C();
{% endprettify %}

### non_const_generative_enum_constructor

_Generative enum constructors must be 'const'._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  e;

  [!E!]();
}
{% endprettify %}

#### Common fixes

Add the `const` keyword before the constructor:

{% prettify dart tag=pre+code %}
enum E {
  e;

  const E();
}
{% endprettify %}

### non_exhaustive_switch_expression

_The type '{0}' is not exhaustively matched by the switch cases since it doesn't
match '{1}'._

#### Description

The analyzer produces this diagnostic when a `switch` expression is
missing a case for one or more of the possible values that could flow
through it.

#### Example

The following code produces this diagnostic because the switch expression
doesn't have a case for the value `E.three`:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

String f(E e) => [!switch!] (e) {
    E.one => 'one',
    E.two => 'two',
  };
{% endprettify %}

#### Common fixes

If the missing values are distinctly meaningful to the switch expression,
then add a case for each of the values missing a match:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

String f(E e) => switch (e) {
    E.one => 'one',
    E.two => 'two',
    E.three => 'three',
  };
{% endprettify %}

If the missing values don't need to be matched, then add a wildcard
pattern that returns a simple default:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

String f(E e) => switch (e) {
    E.one => 'one',
    E.two => 'two',
    _ => 'unknown',
  };
{% endprettify %}

Be aware that a wildcard pattern will handle any values added to the type
in the future. You will lose the ability to have the compiler warn you if
the `switch` needs to be updated to account for newly added types.

### non_exhaustive_switch_statement

_The type '{0}' is not exhaustively matched by the switch cases since it doesn't
match '{1}'._

#### Description

The analyzer produces this diagnostic when a `switch` statement switching
over an exhaustive type is missing a case for one or more of the possible
values that could flow through it.

#### Example

The following code produces this diagnostic because the switch statement
doesn't have a case for the value `E.three`, and `E` is an exhaustive
type:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

void f(E e) {
  [!switch!] (e) {
    case E.one:
    case E.two:
  }
}
{% endprettify %}

#### Common fixes

Add a case for each of the constants that aren't currently being matched:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

void f(E e) {
  switch (e) {
    case E.one:
    case E.two:
      break;
    case E.three:
  }
}
{% endprettify %}

If the missing values don't need to be matched, then add a `default`
clause or a wildcard pattern:

{% prettify dart tag=pre+code %}
enum E { one, two, three }

void f(E e) {
  switch (e) {
    case E.one:
    case E.two:
      break;
    default:
  }
}
{% endprettify %}

But be aware that adding a `default` clause or wildcard pattern will cause
any future values of the exhaustive type to also be handled, so you will
have lost the ability for the compiler to warn you if the `switch` needs
to be updated.

### non_final_field_in_enum

_Enums can only declare final fields._

#### 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:

{% prettify dart tag=pre+code %}
enum E {
  c;

  int [!f!] = 0;
}
{% endprettify %}

#### Common fixes

If the field must be defined for the enum, then mark the field as being
`final`:

{% prettify dart tag=pre+code %}
enum E {
  c;

  final int f = 0;
}
{% endprettify %}

If the field can be removed, then remove it:

{% prettify dart tag=pre+code %}
enum E {
  c
}
{% endprettify %}

### non_generative_constructor

_The generative constructor '{0}' is expected, but a factory was found._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  factory A.one() = B;
  A.two();
}

class B extends A {
  B() : [!super.one()!];
}
{% endprettify %}

#### Common fixes

Change the super invocation to invoke a generative constructor:

{% prettify dart tag=pre+code %}
class A {
  factory A.one() = B;
  A.two();
}

class B extends A {
  B() : super.two();
}
{% endprettify %}

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

_The unnamed constructor of superclass '{0}' (called by the default constructor
of '{1}') must be a generative constructor, but factory found._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  factory A() => throw 0;
  A.named();
}

class [!B!] extends A {}
{% endprettify %}

#### Common fixes

If the unnamed constructor in the superclass can be a generative
constructor, then change it to be a generative constructor:

{% prettify dart tag=pre+code %}
class A {
  A();
  A.named();
}

class B extends A { }
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  factory A() => throw 0;
  A.named();
}

class B extends A {
  B() : super.named();
}
{% endprettify %}

If there are no generative constructors that can be used and none can be
added, then implement the superclass rather than extending it:

{% prettify dart tag=pre+code %}
class A {
  factory A() => throw 0;
  A.named();
}

class B implements A {}
{% endprettify %}

### non_native_function_type_argument_to_pointer

_Can't invoke 'asFunction' because the function signature '{0}' for the pointer
isn't a valid C function signature._

#### 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][ffi].

#### Example

The following code produces this diagnostic because function signature
associated with the pointer `p` (`FNative`) isn't a valid C function
signature:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef FNative = int Function(int);
typedef F = int Function(int);

class C {
  void f(Pointer<NativeFunction<FNative>> p) {
    p.asFunction<[!F!]>();
  }
}
{% endprettify %}

#### Common fixes

Make the `NativeFunction` signature a valid C signature:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

typedef FNative = Int8 Function(Int8);
typedef F = int Function(int);

class C {
  void f(Pointer<NativeFunction<FNative>> p) {
    p.asFunction<F>();
  }
}
{% endprettify %}

### non_positive_array_dimension

_Array dimensions must be positive numbers._

#### 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][ffi].

#### Example

The following code produces this diagnostic because an array dimension of
`-1` was provided:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class MyStruct extends Struct {
  @Array([!-8!])
  external Array<Uint8> a0;
}
{% endprettify %}

#### Common fixes

Change the dimension to be a positive integer:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class MyStruct extends Struct {
  @Array(8)
  external Array<Uint8> a0;
}
{% endprettify %}

### non_sized_type_argument

_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'._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8)
  external Array<[!Void!]> a0;
}
{% endprettify %}

#### Common fixes

Change the type argument to one of the valid types:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8)
  external Array<Uint8> a0;
}
{% endprettify %}

### non_sync_factory

_Factory bodies can't use 'async', 'async*', or 'sync*'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  factory C() [!async!] {
    return C._();
  }
  C._();
}
{% endprettify %}

#### Common fixes

If the member must be declared as a factory constructor, then remove the
keyword appearing before the body:

{% prettify dart tag=pre+code %}
class C {
  factory C() {
    return C._();
  }
  C._();
}
{% endprettify %}

If the member must return something other than an instance of the enclosing
class, then make the member a static method:

{% prettify dart tag=pre+code %}
class C {
  static Future<C> m() async {
    return C._();
  }
  C._();
}
{% endprettify %}

### non_type_as_type_argument

_The name '{0}' isn't a type, so it can't be used as a type argument._

#### 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:

{% prettify dart tag=pre+code %}
var x = 0;
List<[!x!]> xList = [];
{% endprettify %}

#### Common fixes

Change the type argument to be a type:

{% prettify dart tag=pre+code %}
var x = 0;
List<int> xList = [];
{% endprettify %}

### non_type_in_catch_clause

_The name '{0}' isn't a type and can't be used in an on-catch clause._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } on [!f!] {
    // ...
  }
}
{% endprettify %}

#### Common fixes

Change the name to the type of object that should be caught:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } on FormatException {
    // ...
  }
}
{% endprettify %}

### non_void_return_for_operator

_The return type of the operator []= must be 'void'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  [!int!] operator []=(int index, int value) => 0;
}
{% endprettify %}

#### Common fixes

Change the return type to `void`:

{% prettify dart tag=pre+code %}
class C {
  void operator []=(int index, int value) => 0;
}
{% endprettify %}

### non_void_return_for_setter

_The return type of the setter must be 'void' or absent._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  [!int!] set p(int i) => 0;
}
{% endprettify %}

#### Common fixes

Change the return type to `void` or omit the return type:

{% prettify dart tag=pre+code %}
class C {
  set p(int i) => 0;
}
{% endprettify %}

### not_assigned_potentially_non_nullable_local_variable

_The non-nullable local variable '{0}' must be assigned before it can be used._

#### 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:

{% prettify dart tag=pre+code %}
String f() {
  int x;
  return [!x!].toString();
}
{% endprettify %}

The following code produces this diagnostic because the assignment to `x`
might not be executed, so it might have a value of `null`:

{% prettify dart tag=pre+code %}
int g(bool b) {
  int x;
  if (b) {
    x = 1;
  }
  return [!x!] * 2;
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
int h(bool b) {
  int x;
  if (b) {
    x = 1;
  }
  if (b) {
    return [!x!] * 2;
  }
  return 0;
}
{% endprettify %}

#### Common fixes

If `null` is a valid value, then make the variable nullable:

{% prettify dart tag=pre+code %}
String f() {
  int? x;
  return x!.toString();
}
{% endprettify %}

If `null` isn't a valid value, and there's a reasonable default value, then
add an initializer:

{% prettify dart tag=pre+code %}
int g(bool b) {
  int x = 2;
  if (b) {
    x = 1;
  }
  return x * 2;
}
{% endprettify %}

Otherwise, ensure that a value was assigned on every possible code path
before the value is accessed:

{% prettify dart tag=pre+code %}
int g(bool b) {
  int x;
  if (b) {
    x = 1;
  } else {
    x = 2;
  }
  return x * 2;
}
{% endprettify %}

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.

{% prettify dart tag=pre+code %}
int h(bool b) {
  late int x;
  if (b) {
    x = 1;
  }
  if (b) {
    return x * 2;
  }
  return 0;
}
{% endprettify %}

### not_a_type

_{0} isn't a type._

#### 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:

{% prettify dart tag=pre+code %}
f() {}
g([!f!] v) {}
{% endprettify %}

#### Common fixes

Replace the name with the name of a type.

### not_binary_operator

_'{0}' isn't a binary operator._

#### 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:

{% prettify dart tag=pre+code %}
var a = 5 [!~!] 3;
{% endprettify %}

#### Common fixes

Replace the operator with the correct binary operator:

{% prettify dart tag=pre+code %}
var a = 5 - 3;
{% endprettify %}

### not_enough_positional_arguments

_1 positional argument expected by '{0}', but 0 found._

_1 positional argument expected, but 0 found._

_{0} positional arguments expected by '{2}', but {1} found._

_{0} positional arguments expected, but {1} found._

#### 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:

{% prettify dart tag=pre+code %}
void f(int a, int b) {}
void g() {
  f(0[!)!];
}
{% endprettify %}

#### Common fixes

Add arguments corresponding to the remaining parameters:

{% prettify dart tag=pre+code %}
void f(int a, int b) {}
void g() {
  f(0, 1);
}
{% endprettify %}

### not_initialized_non_nullable_instance_field

_Non-nullable instance field '{0}' must be initialized._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  int [!x!];
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  int x;

  C(this.x);

  [!C!].n();
}
{% endprettify %}

#### Common fixes

If there's a reasonable default value for the field that's the same for all
instances, then add an initializer expression:

{% prettify dart tag=pre+code %}
class C {
  int x = 0;
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class C {
  int x;

  C(this.x);
}
{% endprettify %}

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.

{% prettify dart tag=pre+code %}
class C {
  late int x;
}
{% endprettify %}

### not_initialized_non_nullable_variable

_The non-nullable variable '{0}' must be initialized._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  static int [!f!];
}
{% endprettify %}

Similarly, the following code produces this diagnostic because the
top-level variable `v` can't be initialized to `null`:

{% prettify dart tag=pre+code %}
int [!v!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  static int f = 0;
}
{% endprettify %}

If the field or variable should be initialized to `null`, then change the
type to be nullable:

{% prettify dart tag=pre+code %}
int? v;
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class C {
  static late int f;
}
{% endprettify %}

### not_iterable_spread

_Spread elements in list or set literals must implement 'Iterable'._

#### 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:

{% prettify dart tag=pre+code %}
var m = <String, int>{'a': 0, 'b': 1};
var s = <String>{...[!m!]};
{% endprettify %}

#### Common fixes

The most common fix is to replace the expression with one that produces an
iterable object:

{% prettify dart tag=pre+code %}
var m = <String, int>{'a': 0, 'b': 1};
var s = <String>{...m.keys};
{% endprettify %}

### not_map_spread

_Spread elements in map literals must implement 'Map'._

#### 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`:

{% prettify dart tag=pre+code %}
var l =  <String>['a', 'b'];
var m = <int, String>{...[!l!]};
{% endprettify %}

#### Common fixes

The most common fix is to replace the expression with one that produces a
map:

{% prettify dart tag=pre+code %}
var l =  <String>['a', 'b'];
var m = <int, String>{...l.asMap()};
{% endprettify %}

### no_annotation_constructor_arguments

_Annotation creation must have arguments._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  const C();
}

[!@C!]
var x;
{% endprettify %}

#### Common fixes

Add the missing argument list:

{% prettify dart tag=pre+code %}
class C {
  const C();
}

@C()
var x;
{% endprettify %}

### no_combined_super_signature

_Can't infer missing types in '{0}' from overridden methods: {1}._

#### 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:

{% prettify dart tag=pre+code %}
abstract class A {
  A m(String a);
}

abstract class B {
  B m(int a);
}

abstract class C implements A, B {
  [!m!](a);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
abstract class A {
  A m(String a);
}

abstract class B {
  B m(int a);
}

abstract class C implements A, B {
  C m(Object a);
}
{% endprettify %}

### no_generative_constructors_in_superclass

_The class '{0}' can't extend '{1}' because '{1}' only has factory constructors
(no generative constructors), and '{0}' has at least one generative constructor._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  factory A.none() => throw '';
}

class B extends [!A!] {}
{% endprettify %}

#### Common fixes

If the superclass should have a generative constructor, then add one:

{% prettify dart tag=pre+code %}
class A {
  A();
  factory A.none() => throw '';
}

class B extends A {}
{% endprettify %}

If the subclass shouldn't have a generative constructor, then remove it by
adding a factory constructor:

{% prettify dart tag=pre+code %}
class A {
  factory A.none() => throw '';
}

class B extends A {
  factory B.none() => throw '';
}
{% endprettify %}

If the subclass must have a generative constructor but the superclass
can't have one, then implement the superclass instead:

{% prettify dart tag=pre+code %}
class A {
  factory A.none() => throw '';
}

class B implements A {}
{% endprettify %}

### nullable_type_in_catch_clause

_A potentially nullable type can't be used in an 'on' clause because it isn't
valid to throw a nullable expression._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } on [!FormatException?!] {
  }
}
{% endprettify %}

#### Common fixes

Remove the question mark from the type:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } on FormatException {
  }
}
{% endprettify %}

### nullable_type_in_extends_clause

_A class can't extend a nullable type._

#### 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:

{% prettify dart tag=pre+code %}
class A {}
class B extends [!A?!] {}
{% endprettify %}

#### Common fixes

Remove the question mark from the type:

{% prettify dart tag=pre+code %}
class A {}
class B extends A {}
{% endprettify %}

### nullable_type_in_implements_clause

_A class or mixin can't implement a nullable type._

#### 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:

{% prettify dart tag=pre+code %}
class A {}
class B implements [!A?!] {}
{% endprettify %}

#### Common fixes

Remove the question mark from the type:

{% prettify dart tag=pre+code %}
class A {}
class B implements A {}
{% endprettify %}

### nullable_type_in_on_clause

_A mixin can't have a nullable type as a superclass constraint._

#### 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:

{% prettify dart tag=pre+code %}
class C {}
mixin M on [!C?!] {}
{% endprettify %}

#### Common fixes

Remove the question mark from the type:

{% prettify dart tag=pre+code %}
class C {}
mixin M on C {}
{% endprettify %}

### nullable_type_in_with_clause

_A class or mixin can't mix in a nullable type._

#### 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:

{% prettify dart tag=pre+code %}
mixin M {}
class C with [!M?!] {}
{% endprettify %}

#### Common fixes

Remove the question mark from the type:

{% prettify dart tag=pre+code %}
mixin M {}
class C with M {}
{% endprettify %}

### null_argument_to_non_null_type

_'{0}' shouldn't be called with a null argument for the non-nullable type
argument '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
Future<String> f() {
  return Future.value([!null!]);
}
{% endprettify %}

#### Common fixes

Pass in a non-null value:

{% prettify dart tag=pre+code %}
Future<String> f() {
  return Future.value('');
}
{% endprettify %}

### null_check_always_fails

_This null-check will always throw an exception because the expression will
always evaluate to 'null'._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  [!g()!!];
}

Null g() => null;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  g();
  throw TypeError();
}

Null g() => null;
{% endprettify %}

### obsolete_colon_for_default_value

_Using a colon as a separator before a default value is no longer supported._

#### Description

The analyzer produces this diagnostic when a colon is used as the
separator before the default value of an optional parameter. While this
syntax used to be allowed, it's deprecated in favor of using an equal
sign.

#### Example

The following code produces this diagnostic because a colon is being used
before the default value of the optional parameter `i`:

{% prettify dart tag=pre+code %}
void f({int i [!:!] 0}) {}
{% endprettify %}

#### Common fixes

Replace the colon with an equal sign:

{% prettify dart tag=pre+code %}
void f({int i = 0}) {}
{% endprettify %}

### on_repeated

_The type '{0}' can be included in the superclass constraints only once._

#### 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`:

{% prettify dart tag=pre+code %}
mixin M on A, [!A!] {
}

class A {}
class B {}
{% endprettify %}

#### Common fixes

If a different type should be included in the superclass constraints, then
replace one of the occurrences with the other type:

{% prettify dart tag=pre+code %}
mixin M on A, B {
}

class A {}
class B {}
{% endprettify %}

If no other type was intended, then remove the repeated type name:

{% prettify dart tag=pre+code %}
mixin M on A {
}

class A {}
class B {}
{% endprettify %}

### optional_parameter_in_operator

_Optional parameters aren't allowed when defining an operator._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C operator +([[!C? other!]]) => this;
}
{% endprettify %}

#### Common fixes

Make all of the parameters be required parameters:

{% prettify dart tag=pre+code %}
class C {
  C operator +(C other) => this;
}
{% endprettify %}

### override_on_non_overriding_member

_The field doesn't override an inherited getter or setter._

_The getter doesn't override an inherited getter._

_The method doesn't override an inherited method._

_The setter doesn't override an inherited setter._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  @override
  String [!m!]() => '';
}
{% endprettify %}

#### Common fixes

If the member is intended to override a member with a different name, then
update the member to have the same name:

{% prettify dart tag=pre+code %}
class C {
  @override
  String toString() => '';
}
{% endprettify %}

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.

### packed_annotation

_Structs must have at most one 'Packed' annotation._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C`, which
is a subclass of `Struct`, has two `Packed` annotations:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@Packed(1)
[!@Packed(1)!]
final class C extends Struct {
  external Pointer<Uint8> notEmpty;
}
{% endprettify %}

#### Common fixes

Remove all but one of the annotations:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@Packed(1)
final class C extends Struct {
  external Pointer<Uint8> notEmpty;
}
{% endprettify %}

### packed_annotation_alignment

_Only packing to 1, 2, 4, 8, and 16 bytes is supported._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the argument to the
`Packed` annotation (`3`) isn't one of the allowed values:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@Packed([!3!])
final class C extends Struct {
  external Pointer<Uint8> notEmpty;
}
{% endprettify %}

#### Common fixes

Change the alignment to be one of the allowed values:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

@Packed(4)
final class C extends Struct {
  external Pointer<Uint8> notEmpty;
}
{% endprettify %}

### part_of_different_library

_Expected this library to be part of '{0}', not '{1}'._

#### 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 `part.dart` containing

{% prettify dart tag=pre+code %}
part of 'library.dart';
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
part [!'package:a/part.dart'!];
{% endprettify %}

#### 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

_The included part '{0}' must have a part-of directive._

#### 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:

{% prettify dart tag=pre+code %}
class A {}
{% endprettify %}

The following code produces this diagnostic because `a.dart` doesn't
contain a part-of directive:

{% prettify dart tag=pre+code %}
part [!'a.dart'!];
{% endprettify %}

#### Common fixes

If the referenced file is intended to be a part of another library, then
add a part-of directive to the file:

{% prettify dart tag=pre+code %}
part of 'test.dart';

class A {}
{% endprettify %}

If the referenced file is intended to be a library, then replace the part
directive with an import directive:

{% prettify dart tag=pre+code %}
import 'a.dart';
{% endprettify %}

### part_of_unnamed_library

_The library is unnamed. A URI is expected, not a library name '{0}', in the
part-of directive._

#### 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:

{% prettify dart tag=pre+code %}
part of lib;
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
part [!'part_file.dart'!];
{% endprettify %}

#### Common fixes

Change the `part of` directive in the [part file][] to specify its library
by URI:

{% prettify dart tag=pre+code %}
part of 'test.dart';
{% endprettify %}

### path_does_not_exist

_The path '{0}' doesn't exist._

#### 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
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

_The path '{0}' isn't a POSIX-style path._

#### 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
name: example
dependencies:
  local_package:
    path: E:\local_package
```

#### Common fixes

Convert the path to a POSIX path.

### path_pubspec_does_not_exist

_The directory '{0}' doesn't contain a pubspec._

#### 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
`pubspec.yaml`, the following code produces this diagnostic because it's
listed as the path of a package:

```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
name: local_package
```

If the path is wrong, then replace it with the correct path.

### pattern_assignment_not_local_variable

_Only local variables can be assigned in pattern assignments._

#### Description

The analyzer produces this diagnostic when a pattern assignment assigns a
value to anything other than a local variable. Patterns can't assign to
fields or top-level variables.

#### Example

If the code is cleaner when destructuring with a pattern, then rewrite the
code to assign the value to a local variable in a pattern declaration,
assigning the non-local variable separately:

{% prettify dart tag=pre+code %}
class C {
  var x = 0;

  void f((int, int) r) {
    ([!x!], _) = r;
  }
}
{% endprettify %}

#### Common fixes

If the code is cleaner when using a pattern assignment, then rewrite the
code to assign the value to a local variable, assigning the non-local
variable separately:

{% prettify dart tag=pre+code %}
class C {
  var x = 0;

  void f((int, int) r) {
    var (a, _) = r;
    x = a;
  }
}
{% endprettify %}

If the code is cleaner without using a pattern assignment, then rewrite
the code to not use a pattern assignment:

{% prettify dart tag=pre+code %}
class C {
  var x = 0;

  void f((int, int) r) {
    x = r.$1;
  }
}
{% endprettify %}

### pattern_constant_from_deferred_library

_Constant values from a deferred library can't be used in patterns._

#### Description

The analyzer produces this diagnostic when a pattern contains a value
declared in a different library, and that library is imported using a
deferred import. Constants are evaluated at compile time, but values from
deferred libraries aren't available at compile time.

For more information, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

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

{% prettify dart tag=pre+code %}
const zero = 0;
{% endprettify %}

The following code produces this diagnostic because the constant pattern
`a.zero` is imported using a deferred import:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

void f(int x) {
  switch (x) {
    case a.[!zero!]:
      // ...
      break;
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

void f(int x) {
  switch (x) {
    case a.zero:
      // ...
      break;
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

void f(int x) {
  if (x == a.zero) {
    // ...
  }
}
{% endprettify %}

If you don't need to reference the constant, then replace the case
expression:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case 0:
      // ...
      break;
  }
}
{% endprettify %}

### pattern_type_mismatch_in_irrefutable_context

_The matched value of type '{0}' isn't assignable to the required type '{1}'._

#### Description

The analyzer produces this diagnostic when the type of the value on the
right-hand side of a pattern assignment or pattern declaration doesn't
match the type required by the pattern being used to match it.

#### Example

The following code produces this diagnostic because `x` might not be a
`String` and hence might not match the object pattern:

{% prettify dart tag=pre+code %}
void f(Object x) {
  var [!String(length: a)!] = x;
  print(a);
}
{% endprettify %}

#### Common fixes

Change the code so that the type of the expression on the right-hand side
matches the type required by the pattern:

{% prettify dart tag=pre+code %}
void f(String x) {
  var String(length: a) = x;
  print(a);
}
{% endprettify %}

### pattern_variable_assignment_inside_guard

_Pattern variables can't be assigned inside the guard of the enclosing guarded
pattern._

#### Description

The analyzer produces this diagnostic when a pattern variable is assigned
a value inside a guard (`when`) clause.

#### Example

The following code produces this diagnostic because the variable `a` is
assigned a value inside the guard clause:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a when ([!a!] = 1) > 0) {
    print(a);
  }
}
{% endprettify %}

#### Common fixes

If there's a value you need to capture, then assign it to a different
variable:

{% prettify dart tag=pre+code %}
void f(int x) {
  var b;
  if (x case var a when (b = 1) > 0) {
    print(a + b);
  }
}
{% endprettify %}

If there isn't a value you need to capture, then remove the assignment:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a when 1 > 0) {
    print(a);
  }
}
{% endprettify %}

### platform_value_disallowed

_Keys in the `platforms` field can't have values._

#### Description

The analyzer produces this diagnostic when a key in the `platforms` map
has a value.
See the [documentation on platform declaration](https://dart.dev/tools/pub/pubspec#platforms)
for details.

#### Example

The following `pubspec.yaml` produces this diagnostic because the key
`web` has a value.

```yaml
name: example
platforms:
  web: [!"chrome"!]
```

#### Common fixes

Omit the value and leave the key without a value:

```yaml
name: example
platforms:
  web:
```

Values for keys in the `platforms` field are currently reserved for
potential future behavior.

### positional_field_in_object_pattern

_Object patterns can only use named fields._

#### Description

The analyzer produces this diagnostic when an object pattern contains a
field without specifying the getter name. Object pattern fields match
against values that the object's getters return. Without a getter name
specified, the pattern field can't access a value to attempt to match against.

#### Example

The following code produces this diagnostic because the object pattern
`String(1)` doesn't specify which getter of `String` to access and compare
with the value `1`:

{% prettify dart tag=pre+code %}
void f(Object o) {
  if (o case String([!1!])) {}
}
{% endprettify %}

#### Common fixes

Add the getter name to access the value, followed
by a colon before the pattern to match against:

{% prettify dart tag=pre+code %}
void f(Object o) {
  if (o case String(length: 1)) {}
}
{% endprettify %}

### positional_super_formal_parameter_with_positional_argument

_Positional super parameters can't be used when the super constructor invocation
has a positional argument._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A(int x, int y);
}

class B extends A {
  B(int x, super.[!y!]) : super(x);
}
{% endprettify %}

#### Common fixes

If all the positional parameters can be super parameters, then convert the
normal positional parameters to be super parameters:

{% prettify dart tag=pre+code %}
class A {
  A(int x, int y);
}

class B extends A {
  B(super.x, super.y);
}
{% endprettify %}

If some positional parameters can't be super parameters, then convert the
super parameters to be normal parameters:

{% prettify dart tag=pre+code %}
class A {
  A(int x, int y);
}

class B extends A {
  B(int x, int y) : super(x, y);
}
{% endprettify %}

### prefix_collides_with_top_level_member

_The name '{0}' is already used as an import prefix and can't be used to name a
top-level element._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' as f;

int [!f!]() => f.min(0, 1);
{% endprettify %}

#### Common fixes

If you want to use the name for the import prefix, then rename the
top-level declaration:

{% prettify dart tag=pre+code %}
import 'dart:math' as f;

int g() => f.min(0, 1);
{% endprettify %}

If you want to use the name for the top-level declaration, then rename the
import prefix:

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

int f() => math.min(0, 1);
{% endprettify %}

### prefix_identifier_not_followed_by_dot

_The name '{0}' refers to an import prefix, so it must be followed by '.'._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

void f() {
  print([!math!]);
}
{% endprettify %}

#### Common fixes

If the code is incomplete, then reference something in one of the libraries
associated with the prefix:

{% prettify dart tag=pre+code %}
import 'dart:math' as math;

void f() {
  print(math.pi);
}
{% endprettify %}

If the name is wrong, then correct the name.

### prefix_shadowed_by_local_declaration

_The prefix '{0}' can't be used here because it's shadowed by a local
declaration._

#### 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`:

{% prettify dart tag=pre+code %}
import 'dart:async' as a;

a.Future? f(int a) {
  [!a!].Future? x;
  return x;
}
{% endprettify %}

#### Common fixes

Rename either the prefix:

{% prettify dart tag=pre+code %}
import 'dart:async' as p;

p.Future? f(int a) {
  p.Future? x;
  return x;
}
{% endprettify %}

Or rename the local variable:

{% prettify dart tag=pre+code %}
import 'dart:async' as a;

a.Future? f(int p) {
  a.Future? x;
  return x;
}
{% endprettify %}

### private_collision_in_mixin_application

_The private name '{0}', defined by '{1}', conflicts with the same name defined
by '{2}'._

#### 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 `a.dart` containing the following code:

{% prettify dart tag=pre+code %}
mixin A {
  void _foo() {}
}

mixin B {
  void _foo() {}
}
{% endprettify %}

The following code produces this diagnostic because the mixins `A` and `B`
both define the method `_foo`:

{% prettify dart tag=pre+code %}
import 'a.dart';

class C extends Object with A, [!B!] {}
{% endprettify %}

#### Common fixes

If you don't need both of the mixins, then remove one of them from the
`with` clause:

{% prettify dart tag=pre+code %}
import 'a.dart';

class C extends Object with A, [!B!] {}
{% endprettify %}

If you need both of the mixins, then rename the conflicting member in one
of the two mixins.

### private_optional_parameter

_Named parameters can't start with an underscore._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  void m({int [!_x!] = 0}) {}
}
{% endprettify %}

#### Common fixes

Rename the parameter so that it doesn't start with an underscore:

{% prettify dart tag=pre+code %}
class C {
  void m({int x = 0}) {}
}
{% endprettify %}

### private_setter

_The setter '{0}' is private and can't be accessed outside the library that
declares it._

#### Description

The analyzer produces this diagnostic when a private setter is used in a
library where it isn't visible.

#### Example

Given a file `a.dart` that contains the following:

{% prettify dart tag=pre+code %}
class A {
  static int _f = 0;
}
{% endprettify %}

The following code produces this diagnostic because it references the
private setter `_f` even though the setter isn't visible:

{% prettify dart tag=pre+code %}
import 'a.dart';

void f() {
  A.[!_f!] = 0;
}
{% endprettify %}

#### Common fixes

If you're able to make the setter public, then do so:

{% prettify dart tag=pre+code %}
class A {
  static int f = 0;
}
{% endprettify %}

If you aren't able to make the setter public, then find a different way to
implement the code.

### read_potentially_unassigned_final

_The final variable '{0}' can't be read because it's potentially unassigned at
this point._

#### 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:

{% prettify dart tag=pre+code %}
int f() {
  final int x;
  return [!x!];
}
{% endprettify %}

#### Common fixes

Ensure that the variable has been initialized before it's read:

{% prettify dart tag=pre+code %}
int f(bool b) {
  final int x;
  if (b) {
    x = 0;
  } else {
    x = 1;
  }
  return x;
}
{% endprettify %}

### record_literal_one_positional_no_trailing_comma

_A record literal with exactly one positional field requires a trailing comma._

#### Description

The analyzer produces this diagnostic when a record literal with a single
positional field doesn't have a trailing comma after the field.

In some locations a record literal with a single positional field could
also be a parenthesized expression. A trailing comma is required to
disambiguate these two valid interpretations.

#### Example

The following code produces this diagnostic because the record literal has
one positional field but doesn't have a trailing comma:

{% prettify dart tag=pre+code %}
var r = const (1[!)!];
{% endprettify %}

#### Common fixes

Add a trailing comma:

{% prettify dart tag=pre+code %}
var r = const (1,);
{% endprettify %}

### record_type_one_positional_no_trailing_comma

_A record type with exactly one positional field requires a trailing comma._

#### Description

The analyzer produces this diagnostic when a record type annotation with a
single positional field doesn't have a trailing comma after the field.

In some locations a record type with a single positional field could also
be a parenthesized expression. A trailing comma is required to
disambiguate these two valid interpretations.

#### Example

The following code produces this diagnostic because the record type has
one positional field, but doesn't have a trailing comma:

{% prettify dart tag=pre+code %}
void f((int[!)!] r) {}
{% endprettify %}

#### Common fixes

Add a trailing comma:

{% prettify dart tag=pre+code %}
void f((int,) r) {}
{% endprettify %}

### recursive_compile_time_constant

_The compile-time constant expression depends on itself._

#### 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:

{% prettify dart tag=pre+code %}
const [!secondsPerHour!] = minutesPerHour * 60;
const [!minutesPerHour!] = secondsPerHour / 60;
{% endprettify %}

#### Common fixes

Break the cycle by finding an alternative way of defining at least one of
the constants:

{% prettify dart tag=pre+code %}
const secondsPerHour = minutesPerHour * 60;
const minutesPerHour = 60;
{% endprettify %}

### recursive_constructor_redirect

_Constructors can't redirect to themselves either directly or indirectly._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C.a() : [!this.b()!];
  C.b() : [!this.a()!];
}
{% endprettify %}

The following code produces this diagnostic because the factory
constructors `A` and `B` each redirect to the other:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = [!B!];
}
class B implements A {
  factory B() = [!A!];
  B.named();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b();
  C.b();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = B;
}
class B implements A {
  factory B() = B.named;
  B.named();
}
{% endprettify %}

- Not redirect to another constructor:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = B;
}
class B implements A {
  factory B() {
    return B.named();
  }

  B.named();
}
{% endprettify %}

- Not be a factory constructor:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = B;
}
class B implements A {
  B();
  B.named();
}
{% endprettify %}

### recursive_interface_inheritance

_'{0}' can't be a superinterface of itself: {1}._

_'{0}' can't extend itself._

_'{0}' can't implement itself._

_'{0}' can't use itself as a mixin._

_'{0}' can't use itself as a superclass constraint._

#### 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`:

{% prettify dart tag=pre+code %}
class [!A!] extends B {}
class B implements A {}
{% endprettify %}

#### Common fixes

Change the type hierarchy so that there's no circularity.

### redirect_generative_to_missing_constructor

_The constructor '{0}' couldn't be found in '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C.a() : [!this.b()!];
}
{% endprettify %}

#### Common fixes

If the missing constructor must be called, then define it:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b();
  C.b();
}
{% endprettify %}

If the missing constructor doesn't need to be called, then remove the
redirect:

{% prettify dart tag=pre+code %}
class C {
  C.a();
}
{% endprettify %}

### redirect_generative_to_non_generative_constructor

_Generative constructors can't redirect to a factory constructor._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  C.a() : [!this.b()!];
  factory C.b() => C.a();
}
{% endprettify %}

#### Common fixes

If the generative constructor doesn't need to redirect to another
constructor, then remove the redirect.

{% prettify dart tag=pre+code %}
class C {
  C.a();
  factory C.b() => C.a();
}
{% endprettify %}

If the generative constructor must redirect to another constructor, then
make the other constructor be a generative (non-factory) constructor:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b();
  C.b();
}
{% endprettify %}

### redirect_to_abstract_class_constructor

_The redirecting constructor '{0}' can't redirect to a constructor of the
abstract class '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  factory A() = [!B!];
}

abstract class B implements A {}
{% endprettify %}

#### Common fixes

If the code redirects to the correct constructor, then change the class so
that it isn't abstract:

{% prettify dart tag=pre+code %}
class A {
  factory A() = B;
}

class B implements A {}
{% endprettify %}

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

_The redirected constructor '{0}' has incompatible parameters with '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = [!B!];
}

class B implements A {
  B(int x);
  B.zero();
}
{% endprettify %}

The following code produces this diagnostic because the constructor for `A`
declares a named parameter (`y`) that the constructor for `B` doesn't
allow:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A(int x, {int y}) = [!B!];
}

class B implements A {
  B(int x);
}
{% endprettify %}

#### Common fixes

If there's a different constructor that is compatible with the redirecting
constructor, then redirect to that constructor:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A() = B.zero;
}

class B implements A {
  B(int x);
  B.zero();
}
{% endprettify %}

Otherwise, update the redirecting constructor to be compatible:

{% prettify dart tag=pre+code %}
abstract class A {
  factory A(int x) = B;
}

class B implements A {
  B(int x);
}
{% endprettify %}

### redirect_to_invalid_return_type

_The return type '{0}' of the redirected constructor isn't a subtype of '{1}'._

#### 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()`:

{% prettify dart tag=pre+code %}
class A {}

class B implements C {}

class C {
  factory C() = [!A!];
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A {}

class B implements C {}

class C {
  factory C() = B;
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A implements C {}

class B implements C {}

class C {
  factory C() = A;
}
{% endprettify %}

### redirect_to_missing_constructor

_The constructor '{0}' couldn't be found in '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  factory A() = [!B.name!];
}

class B implements A {
  B();
}
{% endprettify %}

#### Common fixes

If the constructor being redirected to is correct, then define the
constructor:

{% prettify dart tag=pre+code %}
class A {
  factory A() = B.name;
}

class B implements A {
  B();
  B.name();
}
{% endprettify %}

If a different constructor should be invoked, then update the redirect:

{% prettify dart tag=pre+code %}
class A {
  factory A() = B;
}

class B implements A {
  B();
}
{% endprettify %}

### redirect_to_non_class

_The name '{0}' isn't a type and can't be used in a redirected constructor._

#### 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:

{% prettify dart tag=pre+code %}
C f() => throw 0;

class C {
  factory C() = [!f!];
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
C f() => throw 0;

class C {
  factory C() => f();
}
{% endprettify %}

### redirect_to_non_const_constructor

_A constant redirecting constructor can't redirect to a non-constant
constructor._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  const C.a() : this.[!b!]();
  C.b();
}
{% endprettify %}

#### Common fixes

If the non-constant constructor can be marked as `const`, then mark it as
`const`:

{% prettify dart tag=pre+code %}
class C {
  const C.a() : this.b();
  const C.b();
}
{% endprettify %}

If the non-constant constructor can't be marked as `const`, then either
remove the redirect or remove `const` from the redirecting constructor:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b();
  C.b();
}
{% endprettify %}

### redirect_to_type_alias_expands_to_type_parameter

_A redirecting constructor can't redirect to a type alias that expands to a type
parameter._

#### 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`:

{% prettify dart tag=pre+code %}
class A implements C {}

typedef B<T> = T;

abstract class C {
  factory C() = [!B!]<A>;
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A implements C {}

abstract class C {
  factory C() = A;
}
{% endprettify %}

### referenced_before_declaration

_Local variable '{0}' can't be referenced before it is declared._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  print([!i!]);
  int i = 5;
}
{% endprettify %}

#### Common fixes

If you intended to reference the local variable, move the declaration
before the first reference:

{% prettify dart tag=pre+code %}
void f() {
  int i = 5;
  print(i);
}
{% endprettify %}

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.

{% prettify dart tag=pre+code %}
void f(int i) {
  print(i);
  int x = 5;
  print(x);
}
{% endprettify %}

### refutable_pattern_in_irrefutable_context

_Refutable patterns can't be used in an irrefutable context._

#### Description

The analyzer produces this diagnostic when a [refutable pattern][] is used
in a context where only an [irrefutable pattern][] is allowed.

The refutable patterns that are disallowed are:
- logical-or
- relational
- null-check
- constant

The contexts that are checked are:
- pattern-based variable declarations
- pattern-based for loops
- assignments with a pattern on the left-hand side

#### Example

The following code produces this diagnostic because the null-check
pattern, which is a refutable pattern, is in a pattern-based variable
declaration, which doesn't allow refutable patterns:

{% prettify dart tag=pre+code %}
void f(int? x) {
  var ([!_?!]) = x;
}
{% endprettify %}

#### Common fixes

Rewrite the code to not use a refutable pattern in an irrefutable context.

### relational_pattern_operand_type_not_assignable

_The constant expression type '{0}' is not assignable to the parameter type
'{1}' of the '{2}' operator._

#### Description

The analyzer produces this diagnostic when the operand of a relational
pattern has a type that isn't assignable to the parameter of the operator
that will be invoked.

#### Example

The following code produces this diagnostic because the operand in the
relational pattern (`0`) is an `int`, but the `>` operator defined in `C`
expects an object of type `C`:

{% prettify dart tag=pre+code %}
class C {
  const C();

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

void f(C c) {
  switch (c) {
    case > [!0!]:
      print('positive');
  }
}
{% endprettify %}

#### Common fixes

If the switch is using the correct value, then change the case to compare
the value to the right type of object:

{% prettify dart tag=pre+code %}
class C {
  const C();

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

void f(C c) {
  switch (c) {
    case > const C():
      print('positive');
  }
}
{% endprettify %}

If the switch is using the wrong value, then change the expression used to
compute the value being matched:

{% prettify dart tag=pre+code %}
class C {
  const C();

  bool operator >(C other) => true;

  int get toInt => 0;
}

void f(C c) {
  switch (c.toInt) {
    case > 0:
      print('positive');
  }
}
{% endprettify %}

### relational_pattern_operator_return_type_not_assignable_to_bool

_The return type of operators used in relational patterns must be assignable to
'bool'._

#### Description

The analyzer produces this diagnostic when a relational pattern references
an operator that doesn't produce a value of type `bool`.

#### Example

The following code produces this diagnostic because the operator `>`, used
in the relational pattern `> c2`, returns a value of type `int` rather
than a `bool`:

{% prettify dart tag=pre+code %}
class C {
  const C();

  int operator >(C c) => 3;

  bool operator <(C c) => false;
}

const C c2 = C();

void f(C c1) {
  if (c1 case [!>!] c2) {}
}
{% endprettify %}

#### Common fixes

If there's a different operator that should be used, then change the
operator:

{% prettify dart tag=pre+code %}
class C {
  const C();

  int operator >(C c) => 3;

  bool operator <(C c) => false;
}

const C c2 = C();

void f(C c1) {
  if (c1 case < c2) {}
}
{% endprettify %}

If the operator is expected to return `bool`, then update the declaration
of the operator:

{% prettify dart tag=pre+code %}
class C {
  const C();

  bool operator >(C c) => true;

  bool operator <(C c) => false;
}

const C c2 = C();

void f(C c1) {
  if (c1 case > c2) {}
}
{% endprettify %}

### rest_element_in_map_pattern

_A map pattern can't contain a rest pattern._

#### Description

The analyzer produces this diagnostic when a map pattern contains a rest
pattern. Map patterns match a map with more keys
than those explicitly given in the pattern (as long as the given keys match),
so a rest pattern is unnecessary.

#### Example

The following code produces this diagnostic because the map pattern contains
a rest pattern:

{% prettify dart tag=pre+code %}
void f(Map<int, String> x) {
  if (x case {0: _, [!...!]}) {}
}
{% endprettify %}

#### Common fixes

Remove the rest pattern:

{% prettify dart tag=pre+code %}
void f(Map<int, String> x) {
  if (x case {0: _}) {}
}
{% endprettify %}

### rethrow_outside_catch

_A rethrow must be inside of a catch clause._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  [!rethrow!];
}
{% endprettify %}

#### Common fixes

If you're trying to rethrow an exception, then wrap the `rethrow` statement
in a `catch` clause:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } catch (exception) {
    rethrow;
  }
}
{% endprettify %}

If you're trying to throw a new exception, then replace the `rethrow`
statement with a `throw` expression:

{% prettify dart tag=pre+code %}
void f() {
  throw UnsupportedError('Not yet implemented');
}
{% endprettify %}

### return_in_generative_constructor

_Constructors can't return values._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C() {
    return [!this!];
  }
}
{% endprettify %}

#### Common fixes

If the constructor should create a new instance, then remove either the
`return` statement or the expression:

{% prettify dart tag=pre+code %}
class C {
  C();
}
{% endprettify %}

If the constructor shouldn't create a new instance, then convert it to be a
factory constructor:

{% prettify dart tag=pre+code %}
class C {
  factory C() {
    return _instance;
  }

  static C _instance = C._();

  C._();
}
{% endprettify %}

### return_in_generator

_Can't return a value from a generator function that uses the 'async*' or
'sync*' modifier._

#### 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:

{% prettify dart tag=pre+code %}
Iterable<int> f() sync* {
  [!return!] 3;
}
{% endprettify %}

The following code produces this diagnostic because the function `f` is a
generator and is implicitly returning a value:

{% prettify dart tag=pre+code %}
Stream<int> f() async* [!=>!] 3;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
Stream<int> f() async* {
  yield 3;
}
{% endprettify %}

If the method is intended to be a generator, then use `yield` to return a
value:

{% prettify dart tag=pre+code %}
Iterable<int> f() sync* {
  yield 3;
}
{% endprettify %}

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):

{% prettify dart tag=pre+code %}
int f() {
  return 3;
}
{% endprettify %}

### return_of_do_not_store

_'{0}' is annotated with 'doNotStore' and shouldn't be returned unless '{1}' is
also annotated._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@doNotStore
int f() => 0;

int g() => [!f()!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@doNotStore
int f() => 0;

@doNotStore
int g() => f();
{% endprettify %}

Otherwise, return a different value from the function:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@doNotStore
int f() => 0;

int g() => 0;
{% endprettify %}

### return_of_invalid_type

_A value of type '{0}' can't be returned from the constructor '{2}' because it
has a return type of '{1}'._

_A value of type '{0}' can't be returned from the function '{2}' because it has
a return type of '{1}'._

_A value of type '{0}' can't be returned from the method '{2}' because it has a
return type of '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
String f() => [!3!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
String f() => 3.toString();
{% endprettify %}

If the value is correct, then change the return type to match:

{% prettify dart tag=pre+code %}
int f() => 3;
{% endprettify %}

### return_of_invalid_type_from_closure

_The return type '{0}' isn't a '{1}', as required by the closure's context._

#### 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`:

{% prettify dart tag=pre+code %}
String Function(String) f = (s) => [!3!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
String Function(String) f = (s) => 3.toString();
{% endprettify %}

### return_without_value

_The return value is missing after 'return'._

#### 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:

{% prettify dart tag=pre+code %}
int f() {
  [!return!];
}
{% endprettify %}

#### Common fixes

Add an expression that computes the value to be returned:

{% prettify dart tag=pre+code %}
int f() {
  return 0;
}
{% endprettify %}

### sdk_version_async_exported_from_core

_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._

#### 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
environment:
  sdk: '>=2.0.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
void f([!Future!] f) {}
{% endprettify %}

#### 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.

{% prettify dart tag=pre+code %}
import 'dart:async';

void f(Future f) {}
{% endprettify %}

### sdk_version_as_expression_in_const_context

_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._

#### 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
environment:
  sdk: '>=2.1.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces
this diagnostic:

{% prettify dart tag=pre+code %}
const num n = 3;
const int i = [!n as int!];
{% endprettify %}

#### 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][]:

{% prettify dart tag=pre+code %}
num x = 3;
int y = x as int;
{% endprettify %}

### sdk_version_bool_operator_in_const_context

_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._

#### 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
environment:
  sdk: '>=2.1.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
const bool a = true;
const bool b = false;
const bool c = a [!&!] b;
{% endprettify %}

#### 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][]:

{% prettify dart tag=pre+code %}
const bool a = true;
const bool b = false;
bool c = a & b;
{% endprettify %}

### sdk_version_constructor_tearoffs

_Tearing off a constructor requires the 'constructor-tearoffs' language
feature._

#### 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
environment:
  sdk: '>=2.9.0 <2.15.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
var setConstructor = [!Set.identity!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
var setConstructor = () => Set.identity();
{% endprettify %}

### sdk_version_eq_eq_operator_in_const_context

_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._

#### 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
environment:
  sdk: '>=2.1.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
class C {}
const C a = null;
const C b = null;
const bool same = a [!==!] b;
{% endprettify %}

#### 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][]:

{% prettify dart tag=pre+code %}
class C {}
const C a = null;
const C b = null;
bool same = a == b;
{% endprettify %}

### sdk_version_extension_methods

_Extension methods weren't supported until version 2.6.0, but this code is
required to be able to run on earlier versions._

#### 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
environment:
 sdk: '>=2.4.0 <2.7.0'
```

In the package that has that pubspec, code like the following produces
this diagnostic:

{% prettify dart tag=pre+code %}
[!extension!] E on String {
  void sayHello() {
    print('Hello $this');
  }
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
void sayHello(String s) {
  print('Hello $s');
}
{% endprettify %}

### sdk_version_gt_gt_gt_operator

_The operator '>>>' wasn't supported until version 2.14.0, but this code is
required to be able to run on earlier versions._

#### 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
environment:
 sdk: '>=2.0.0 <2.15.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
int x = 3 [!>>>!] 4;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int x = logicalShiftRight(3, 4);

int logicalShiftRight(int leftOperand, int rightOperand) {
  int divisor = 1 << rightOperand;
  if (divisor == 0) {
    return 0;
  }
  return leftOperand ~/ divisor;
}
{% endprettify %}

### sdk_version_is_expression_in_const_context

_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._

#### 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
environment:
  sdk: '>=2.1.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces
this diagnostic:

{% prettify dart tag=pre+code %}
const Object x = 4;
const y = [!x is int!] ? 0 : 1;
{% endprettify %}

#### 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][]:

{% prettify dart tag=pre+code %}
const Object x = 4;
var y = x is int ? 0 : 1;
{% endprettify %}

### sdk_version_never

_The type 'Never' wasn't supported until version 2.12.0, but this code is
required to be able to run on earlier versions._

#### 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
environment:
  sdk: '>=2.5.0 <2.6.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
[!Never!] n;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
dynamic x;
{% endprettify %}

### sdk_version_set_literal

_Set literals weren't supported until version 2.2, but this code is required to
be able to run on earlier versions._

#### 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
environment:
  sdk: '>=2.1.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces this
diagnostic:

{% prettify dart tag=pre+code %}
var s = [!<int>{}!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
var s = new Set<int>();
{% endprettify %}

### sdk_version_ui_as_code

_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._

#### 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
environment:
  sdk: '>=2.2.0 <2.4.0'
```

In the package that has that pubspec, code like the following produces
this diagnostic:

{% prettify dart tag=pre+code %}
var digits = [[!for (int i = 0; i < 10; i++) i!]];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
var digits = _initializeDigits();

List<int> _initializeDigits() {
  var digits = <int>[];
  for (int i = 0; i < 10; i++) {
    digits.add(i);
  }
  return digits;
}
{% endprettify %}

### sdk_version_ui_as_code_in_const_context

_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._

#### 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
environment:
  sdk: '>=2.4.0 <2.6.0'
```

In the package that has that pubspec, code like the following produces
this diagnostic:

{% prettify dart tag=pre+code %}
const a = [1, 2];
const b = [[!...a!]];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
const a = [1, 2];
const b = [1, 2];
{% endprettify %}

If that isn't possible, change the code so that the element isn't in a
[constant context][]:

{% prettify dart tag=pre+code %}
const a = [1, 2];
var b = [...a];
{% endprettify %}

### set_element_type_not_assignable

_The element type '{0}' can't be assigned to the set type '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
var s = <int>{[!'0'!]};
{% endprettify %}

#### Common fixes

If the element type of the set literal is wrong, then change the element
type of the set:

{% prettify dart tag=pre+code %}
var s = <String>{'0'};
{% endprettify %}

If the type of the element is wrong, then change the element:

{% prettify dart tag=pre+code %}
var s = <int>{'0'.length};
{% endprettify %}

### shared_deferred_prefix

_The prefix of a deferred import can't be used in other import directives._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' [!deferred!] as x;
import 'dart:convert' as x;

var y = x.json.encode(x.min(0, 1));
{% endprettify %}

#### Common fixes

If you can use a different name for the deferred import, then do so:

{% prettify dart tag=pre+code %}
import 'dart:math' deferred as math;
import 'dart:convert' as x;

var y = x.json.encode(math.min(0, 1));
{% endprettify %}

If you can use a different name for the other imports, then do so:

{% prettify dart tag=pre+code %}
import 'dart:math' deferred as x;
import 'dart:convert' as convert;

var y = convert.json.encode(x.min(0, 1));
{% endprettify %}

### size_annotation_dimensions

_'Array's must have an 'Array' annotation that matches the dimensions._

#### 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][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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  [!@Array(8, 8)!]
  external Array<Array<Array<Uint8>>> a0;
}
{% endprettify %}

#### Common fixes

If the type of the field is correct, then fix the annotation to have the
required number of dimensions:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8, 8, 4)
  external Array<Array<Array<Uint8>>> a0;
}
{% endprettify %}

If the type of the field is wrong, then fix the type of the field:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Array(8, 8)
  external Array<Array<Uint8>> a0;
}
{% endprettify %}

### static_access_to_instance_member

_Instance member '{0}' can't be accessed using static access._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  static int a;

  int b;
}

int f() => C.[!b!];
{% endprettify %}

#### Common fixes

If you intend to access a static field, then change the name of the field
to an existing static field:

{% prettify dart tag=pre+code %}
class C {
  static int a;

  int b;
}

int f() => C.a;
{% endprettify %}

If you intend to access the instance field, then use an instance of the
class to access the field:

{% prettify dart tag=pre+code %}
class C {
  static int a;

  int b;
}

int f(C c) => c.b;
{% endprettify %}

### subtype_of_base_or_final_is_not_base_final_or_sealed

_The mixin '{0}' must be 'base' because the supertype '{1}' is 'base'._

_The mixin '{0}' must be 'base' because the supertype '{1}' is 'final'._

_The type '{0}' must be 'base', 'final' or 'sealed' because the supertype '{1}'
is 'base'._

_The type '{0}' must be 'base', 'final' or 'sealed' because the supertype '{1}'
is 'final'._

#### Description

The analyzer produces this diagnostic when a class or mixin has a direct
or indirect supertype that is either `base` or `final`, but the class or
mixin itself isn't marked either `base`, `final`, or `sealed`.

#### Example

The following code produces this diagnostic because the class `B` is a
subtype of `A`, and `A` is a `base` class, but `B` is neither `base`,
`final` or `sealed`:

{% prettify dart tag=pre+code %}
base class A {}
class [!B!] extends A {}
{% endprettify %}

#### Common fixes

Add either `base`, `final` or `sealed` to the class or mixin declaration:

{% prettify dart tag=pre+code %}
base class A {}
final class B extends A {}
{% endprettify %}

### subtype_of_deferred_class

_Classes and mixins can't implement deferred classes._

_Classes can't extend deferred classes._

_Classes can't mixin deferred classes._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

Given a file `a.dart` that defines the class `A`:

{% prettify dart tag=pre+code %}
class A {}
{% endprettify %}

The following code produces this diagnostic because the superclass of `B`
is declared in a deferred library:

{% prettify dart tag=pre+code %}
import 'a.dart' deferred as a;

class B extends [!a.A!] {}
{% endprettify %}

#### Common fixes

If you need to create a subtype of a type from the deferred library, then
remove the `deferred` keyword:

{% prettify dart tag=pre+code %}
import 'a.dart' as a;

class B extends a.A {}
{% endprettify %}

### subtype_of_disallowed_type

_'{0}' can't be used as a superclass constraint._

_Classes and mixins can't implement '{0}'._

_Classes can't extend '{0}'._

_Classes can't mixin '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
class A extends [!String!] {}
{% endprettify %}

The following code produces this diagnostic because `String` is used in an
`implements` clause:

{% prettify dart tag=pre+code %}
class B implements [!String!] {}
{% endprettify %}

The following code produces this diagnostic because `String` is used in a
`with` clause:

{% prettify dart tag=pre+code %}
class C with [!String!] {}
{% endprettify %}

The following code produces this diagnostic because `String` is used in an
`on` clause:

{% prettify dart tag=pre+code %}
mixin M on [!String!] {}
{% endprettify %}

#### Common fixes

If a different type should be specified, then replace the type:

{% prettify dart tag=pre+code %}
class A extends Object {}
{% endprettify %}

If there isn't a different type that would be appropriate, then remove the
type, and possibly the whole clause:

{% prettify dart tag=pre+code %}
class B {}
{% endprettify %}

### subtype_of_ffi_class

_The class '{0}' can't extend '{1}'._

_The class '{0}' can't implement '{1}'._

_The class '{0}' can't mix in '{1}'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C` extends
`Double`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends [!Double!] {}
{% endprettify %}

#### Common fixes

If the class should extend either `Struct` or `Union`, then change the
declaration of the class:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  external int i;
}
{% endprettify %}

If the class shouldn't extend either `Struct` or `Union`, then remove any
references to FFI classes:

{% prettify dart tag=pre+code %}
final class C {}
{% endprettify %}

### subtype_of_sealed_class

_The class '{0}' shouldn't be extended, mixed in, or implemented because it's
sealed._

#### 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:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class A {}

@sealed
class B {}
{% endprettify %}

The following code produces this diagnostic because `C`, which isn't in the
same package as `B`, is extending the sealed class `B`:

{% prettify dart tag=pre+code %}
import 'package:a/a.dart';

[!class C extends B {}!]
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
import 'package:a/a.dart';

class B extends A {}
{% endprettify %}

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.

### subtype_of_struct_class

_The class '{0}' can't extend '{1}' because '{1}' is a subtype of 'Struct',
'Union', or 'AbiSpecificInteger'._

_The class '{0}' can't implement '{1}' because '{1}' is a subtype of 'Struct',
'Union', or 'AbiSpecificInteger'._

_The class '{0}' can't mix in '{1}' because '{1}' is a subtype of 'Struct',
'Union', or 'AbiSpecificInteger'._

#### 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][ffi].

#### Example

The following code produces this diagnostic because the class `C` extends
`S`, and `S` extends `Struct`:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class S extends Struct {
  external Pointer f;
}

final class C extends [!S!] {
  external Pointer g;
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:ffi';

final class S extends Struct {
  external Pointer f;
}

final class C extends Struct {
  external Pointer f;

  external Pointer g;
}
{% endprettify %}

### supertype_expands_to_type_parameter

_A type alias that expands to a type parameter can't be implemented._

_A type alias that expands to a type parameter can't be mixed in._

_A type alias that expands to a type parameter can't be used as a superclass
constraint._

_A type alias that expands to a type parameter can't be used as a superclass._

#### 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`:

{% prettify dart tag=pre+code %}
typedef T<S> = S;

class C extends [!T!]<Object> {}
{% endprettify %}

#### Common fixes

Use the value of the type argument directly:

{% prettify dart tag=pre+code %}
typedef T<S> = S;

class C extends Object {}
{% endprettify %}

### super_formal_parameter_type_is_not_subtype_of_associated

_The type '{0}' of this parameter isn't a subtype of the type '{1}' of the
associated super constructor parameter._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  A(num x);
}

class B extends A {
  B(String super.[!x!]);
}
{% endprettify %}

#### 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):

{% prettify dart tag=pre+code %}
class A {
  A(num x);
}

class B extends A {
  B(super.x);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
class A {
  A(num x);
}

class B extends A {
  B(int super.x);
}
{% endprettify %}

If the type of the super parameter can't be changed, then use a normal
parameter instead of a super parameter:

{% prettify dart tag=pre+code %}
class A {
  A(num x);
}

class B extends A {
  B(String x) : super(x.length);
}
{% endprettify %}

### super_formal_parameter_without_associated_named

_No associated named super constructor parameter._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  A({int? x});
}

class B extends A {
  B({super.[!y!]});
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A({int? x});
}

class B extends A {
  B({super.x});
}
{% endprettify %}

If the super parameter should be associated with a parameter that hasn't
yet been added to the super constructor, then add it:

{% prettify dart tag=pre+code %}
class A {
  A({int? x, int? y});
}

class B extends A {
  B({super.y});
}
{% endprettify %}

If the super parameter doesn't correspond to a named parameter from the
super constructor, then change it to be a normal parameter:

{% prettify dart tag=pre+code %}
class A {
  A({int? x});
}

class B extends A {
  B({int? y});
}
{% endprettify %}

### super_formal_parameter_without_associated_positional

_No associated positional super constructor parameter._

#### 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`:

{% prettify dart tag=pre+code %}
class A {
  A({int? x});
}

class B extends A {
  B(super.[!x!]);
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B(super.x, super.[!y!]);
}
{% endprettify %}

#### Common fixes

If the super constructor should have a positional parameter corresponding
to the super parameter, then update the super constructor appropriately:

{% prettify dart tag=pre+code %}
class A {
  A(int x, int y);
}

class B extends A {
  B(super.x, super.y);
}
{% endprettify %}

If the super constructor is correct, or can't be changed, then convert the
super parameter into a normal parameter:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B(super.x, int y);
}
{% endprettify %}

### super_invocation_not_last

<a id="invalid_super_invocation" aria-hidden="true"></a>_(Previously known as `invalid_super_invocation`)_

_The superconstructor call must be last in an initializer list: '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B(int x) : [!super!](x), assert(x >= 0);
}
{% endprettify %}

#### Common fixes

Move the invocation of the superclass' constructor to the end of the
initializer list:

{% prettify dart tag=pre+code %}
class A {
  A(int x);
}

class B extends A {
  B(int x) : assert(x >= 0), super(x);
}
{% endprettify %}

### super_in_enum_constructor

_The enum constructor can't have a 'super' initializer._

#### 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:

{% prettify dart tag=pre+code %}
enum E {
  e;

  const E() : [!super!]();
}
{% endprettify %}

#### Common fixes

Remove the super constructor invocation:

{% prettify dart tag=pre+code %}
enum E {
  e;

  const E();
}
{% endprettify %}

### super_in_extension

_The 'super' keyword can't be used in an extension because an extension doesn't
have a superclass._

#### 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:

{% prettify dart tag=pre+code %}
extension E on Object {
  String get displayString => [!super!].toString();
}
{% endprettify %}

#### Common fixes

Remove the `super` keyword :

{% prettify dart tag=pre+code %}
extension E on Object {
  String get displayString => toString();
}
{% endprettify %}

### super_in_invalid_context

_Invalid context for 'super' invocation._

#### Description

The analyzer produces this diagnostic when the keyword `super` is used
outside of an instance method.

#### Example

The following code produces this diagnostic because `super` is used in a
top-level function:

{% prettify dart tag=pre+code %}
void f() {
  [!super!].f();
}
{% endprettify %}

#### Common fixes

Rewrite the code to not use `super`.

### super_in_redirecting_constructor

_The redirecting constructor can't have a 'super' initializer._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b(), [!super()!];
  C.b();
}
{% endprettify %}

#### Common fixes

Remove the invocation of the `super` constructor:

{% prettify dart tag=pre+code %}
class C {
  C.a() : this.b();
  C.b();
}
{% endprettify %}

### switch_case_completes_normally

_The 'case' shouldn't complete normally._

#### 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:

{% prettify dart tag=pre+code %}
void f(int a) {
  switch (a) {
    [!case!] 0:
      print(0);
    default:
      return;
  }
}
{% endprettify %}

#### 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

_Type '{0}' of the switch expression isn't assignable to the type '{1}' of case
expressions._

#### 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`):

{% prettify dart tag=pre+code %}
void f(String s) {
  switch ([!s!]) {
    case 0:
      break;
  }
}
{% endprettify %}

#### Common fixes

If the type of the `case` expressions is correct, then change the
expression in the `switch` statement to have the correct type:

{% prettify dart tag=pre+code %}
void f(String s) {
  switch (int.parse(s)) {
    case 0:
      break;
  }
}
{% endprettify %}

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

{% prettify dart tag=pre+code %}
void f(String s) {
  switch (s) {
    case '0':
      break;
  }
}
{% endprettify %}

### tearoff_of_generative_constructor_of_abstract_class

_A generative constructor of an abstract class can't be torn off._

#### 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:

{% prettify dart tag=pre+code %}
abstract class C {
  C();
}

void f() {
  [!C.new!];
}
{% endprettify %}

#### Common fixes

Tear off the constructor of a concrete class.

### text_direction_code_point_in_comment

_The Unicode code point 'U+{0}' changes the appearance of text from how it's
interpreted by the compiler._

#### 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:

{% prettify dart tag=pre+code %}
var label = '[!I!]nteractive text[!'!];
{% endprettify %}

#### Common fixes

If the code points are intended to be included in the string literal,
then escape them:

{% prettify dart tag=pre+code %}
var label = '\u202AInteractive text\u202C';
{% endprettify %}

If the code points aren't intended to be included in the string literal,
then remove them:

{% prettify dart tag=pre+code %}
var label = 'Interactive text';
{% endprettify %}

### text_direction_code_point_in_literal

_The Unicode code point 'U+{0}' changes the appearance of text from how it's
interpreted by the compiler._

#### 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:

{% prettify dart tag=pre+code %}
var label = '[!I!]nteractive text[!'!];
{% endprettify %}

#### Common fixes

If the code points are intended to be included in the string literal,
then escape them:

{% prettify dart tag=pre+code %}
var label = '\u202AInteractive text\u202C';
{% endprettify %}

If the code points aren't intended to be included in the string literal,
then remove them:

{% prettify dart tag=pre+code %}
var label = 'Interactive text';
{% endprettify %}

### throw_of_invalid_type

_The type '{0}' of the thrown expression must be assignable to 'Object'._

#### 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`:

{% prettify dart tag=pre+code %}
void f(String? s) {
  throw [!s!];
}
{% endprettify %}

#### Common fixes

Add an explicit null-check to the expression:

{% prettify dart tag=pre+code %}
void f(String? s) {
  throw s!;
}
{% endprettify %}

### top_level_cycle

_The type of '{0}' can't be inferred because it depends on itself through the
cycle: {1}._

#### 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:

{% prettify dart tag=pre+code %}
var x = y;
var y = [!x!];
{% endprettify %}

#### Common fixes

If the two variables don't need to refer to each other, then break the
cycle:

{% prettify dart tag=pre+code %}
var x = 0;
var y = x;
{% endprettify %}

If the two variables need to refer to each other, then give at least one of
them an explicit type:

{% prettify dart tag=pre+code %}
int x = y;
var y = x;
{% endprettify %}

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

_Typedefs can't reference themselves directly or recursively via another
typedef._

#### 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`:

{% prettify dart tag=pre+code %}
typedef [!F!] = void Function(G);
typedef G = void Function(F);
{% endprettify %}

#### Common fixes

Change one or more of the typedefs in the cycle so that none of them refer
to themselves:

{% prettify dart tag=pre+code %}
typedef F = void Function(G);
typedef G = void Function(int);
{% endprettify %}

### type_annotation_deferred_class

_The deferred type '{0}' can't be used in a declaration, cast, or type test._

#### 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, check out
[Lazily loading a library](https://dart.dev/language/libraries#lazily-loading-a-library).

#### Example

The following code produces this diagnostic because the type of the
parameter `f` is imported from a deferred library:

{% prettify dart tag=pre+code %}
import 'dart:io' deferred as io;

void f([!io.File!] f) {}
{% endprettify %}

#### Common fixes

If you need to reference the imported type, then remove the `deferred`
keyword:

{% prettify dart tag=pre+code %}
import 'dart:io' as io;

void f(io.File f) {}
{% endprettify %}

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

_'{0}' doesn't conform to the bound '{2}' of the type parameter '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
class A<E extends num> {}

var a = A<[!String!]>();
{% endprettify %}

#### Common fixes

Change the type argument to be a subclass of the bounds:

{% prettify dart tag=pre+code %}
class A<E extends num> {}

var a = A<int>();
{% endprettify %}

### type_check_with_null

_Tests for non-null should be done with '!= null'._

_Tests for null should be done with '== null'._

#### 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:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if ([!s is Null!]) {
    return;
  }
  print(s);
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if ([!s is! Null!]) {
    print(s);
  }
}
{% endprettify %}

#### Common fixes

Replace the type check with the equivalent comparison with `null`:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if (s == null) {
    return;
  }
  print(s);
}
{% endprettify %}

### type_parameter_referenced_by_static

_Static members can't reference type parameters of the class._

#### 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`:

{% prettify dart tag=pre+code %}
class C<T> {
  static bool hasType(Object o) => o is [!T!];
}
{% endprettify %}

#### Common fixes

If the member can be an instance member, then remove the keyword `static`:

{% prettify dart tag=pre+code %}
class C<T> {
  bool hasType(Object o) => o is T;
}
{% endprettify %}

If the member must be a static member, then make the member be generic:

{% prettify dart tag=pre+code %}
class C<T> {
  static bool hasType<S>(Object o) => o is S;
}
{% endprettify %}

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

_'{0}' can't be a supertype of its upper bound._

#### 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`:

{% prettify dart tag=pre+code %}
class C<[!T!] extends T> {}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
class C<[!T1!] extends T2, T2 extends T1> {}
{% endprettify %}

#### Common fixes

If the type parameter needs to be a subclass of some type, then replace the
bound with the required type:

{% prettify dart tag=pre+code %}
class C<T extends num> {}
{% endprettify %}

If the type parameter can be any type, then remove the `extends` clause:

{% prettify dart tag=pre+code %}
class C<T> {}
{% endprettify %}

### type_test_with_non_type

_The name '{0}' isn't a type and can't be used in an 'is' expression._

#### 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:

{% prettify dart tag=pre+code %}
typedef B = int Function(int);

void f(Object a, B b) {
  if (a is [!b!]) {
    return;
  }
}
{% endprettify %}

#### Common fixes

If you intended to use a type test, then replace the right-hand side with a
type:

{% prettify dart tag=pre+code %}
typedef B = int Function(int);

void f(Object a, B b) {
  if (a is B) {
    return;
  }
}
{% endprettify %}

If you intended to use a different kind of test, then change the test:

{% prettify dart tag=pre+code %}
typedef B = int Function(int);

void f(Object a, B b) {
  if (a == b) {
    return;
  }
}
{% endprettify %}

### type_test_with_undefined_name

_The name '{0}' isn't defined, so it can't be used in an 'is' expression._

#### 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:

{% prettify dart tag=pre+code %}
void f(Object o) {
  if (o is [!Srting!]) {
    // ...
  }
}
{% endprettify %}

#### Common fixes

Replace the name with the name of a type:

{% prettify dart tag=pre+code %}
void f(Object o) {
  if (o is String) {
    // ...
  }
}
{% endprettify %}

### unchecked_use_of_nullable_value

_A nullable expression can't be used as a condition._

_A nullable expression can't be used as an iterator in a for-in loop._

_A nullable expression can't be used in a spread._

_A nullable expression can't be used in a yield-each statement._

_The function can't be unconditionally invoked because it can be 'null'._

_The method '{0}' can't be unconditionally invoked because the receiver can be
'null'._

_The operator '{0}' can't be unconditionally invoked because the receiver can be
'null'._

_The property '{0}' can't be unconditionally accessed because the receiver can
be 'null'._

#### 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:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if (s.[!length!] > 3) {
    // ...
  }
}
{% endprettify %}

#### 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`:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if (s != null && s.length > 3) {
    // ...
  }
}
{% endprettify %}

If the expression is a variable and the value should never be `null`, then
change the type of the variable to be non-nullable:

{% prettify dart tag=pre+code %}
void f(String s) {
  if (s.length > 3) {
    // ...
  }
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
void f(String? s) {
  if (s!.length > 3) {
    // ...
  }
}
{% endprettify %}

### undefined_annotation

_Undefined name '{0}' used as an annotation._

#### 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:

{% prettify dart tag=pre+code %}
[!@undefined!]
void f() {}
{% endprettify %}

#### Common fixes

If the name is correct, but it isn't declared yet, then declare the name as
a constant value:

{% prettify dart tag=pre+code %}
const undefined = 'undefined';

@undefined
void f() {}
{% endprettify %}

If the name is wrong, replace the name with the name of a valid constant:

{% prettify dart tag=pre+code %}
@deprecated
void f() {}
{% endprettify %}

Otherwise, remove the annotation.

### undefined_class

_Undefined class '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
class Point {}

void f([!Piont!] p) {}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class Point {}

void f(Point p) {}
{% endprettify %}

If the class is defined but isn't visible, then you probably need to add an
import.

### undefined_constructor_in_initializer

_The class '{0}' doesn't have a constructor named '{1}'._

_The class '{0}' doesn't have an unnamed constructor._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  A.n();
}
class B extends A {
  B() : [!super()!];
}
{% endprettify %}

The following code produces this diagnostic because `A` doesn't have a
constructor named `m`:

{% prettify dart tag=pre+code %}
class A {
  A.n();
}
class B extends A {
  B() : [!super.m()!];
}
{% endprettify %}

#### Common fixes

If the superclass defines a constructor that should be invoked, then change
the constructor being invoked:

{% prettify dart tag=pre+code %}
class A {
  A.n();
}
class B extends A {
  B() : super.n();
}
{% endprettify %}

If the superclass doesn't define an appropriate constructor, then define
the constructor being invoked:

{% prettify dart tag=pre+code %}
class A {
  A.m();
  A.n();
}
class B extends A {
  B() : super.m();
}
{% endprettify %}

### undefined_enum_constant

_There's no constant named '{0}' in '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {a, b}

var e = E.[!c!];
{% endprettify %}

#### Common fixes

If the constant should be defined, then add it to the declaration of the
enum:

{% prettify dart tag=pre+code %}
enum E {a, b, c}

var e = E.c;
{% endprettify %}

If the constant shouldn't be defined, then change the name to the name of
an existing constant:

{% prettify dart tag=pre+code %}
enum E {a, b}

var e = E.b;
{% endprettify %}

### undefined_enum_constructor

_The enum doesn't have a constructor named '{0}'._

_The enum doesn't have an unnamed constructor._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  [!c!]();

  const E.x();
}
{% endprettify %}

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`:

{% prettify dart tag=pre+code %}
enum E {
  c.[!x!]();

  const E.y();
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
enum E {
  c.x();

  const E.x();
}
{% endprettify %}

If the enum constant is being initialized by the unnamed constructor and
none of the named constructors are appropriate, then define the unnamed
constructor:

{% prettify dart tag=pre+code %}
enum E {
  c();

  const E();
}
{% endprettify %}

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):

{% prettify dart tag=pre+code %}
enum E {
  c.y();

  const E();
  const E.y();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
enum E {
  c.x();

  const E.x();
}
{% endprettify %}

### undefined_extension_getter

_The getter '{0}' isn't defined for the extension '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
extension E on String {
  String get a => 'a';
}

extension F on String {
  String get b => 'b';
}

void f() {
  E('c').[!b!];
}
{% endprettify %}

The following code produces this diagnostic because the extension `E`
doesn't declare a static getter named `a`:

{% prettify dart tag=pre+code %}
extension E on String {}

var x = E.[!a!];
{% endprettify %}

#### Common fixes

If the name of the getter is incorrect, then change it to the name of an
existing getter:

{% prettify dart tag=pre+code %}
extension E on String {
  String get a => 'a';
}

extension F on String {
  String get b => 'b';
}

void f() {
  E('c').a;
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
extension E on String {
  String get a => 'a';
}

extension F on String {
  String get b => 'b';
}

void f() {
  F('c').b;
}
{% endprettify %}

If the name of the getter and extension are both correct, but the getter
isn't defined, then define the getter:

{% prettify dart tag=pre+code %}
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;
}
{% endprettify %}

### undefined_extension_method

_The method '{0}' isn't defined for the extension '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
extension E on String {
  String a() => 'a';
}

extension F on String {
  String b() => 'b';
}

void f() {
  E('c').[!b!]();
}
{% endprettify %}

The following code produces this diagnostic because the extension `E`
doesn't declare a static method named `a`:

{% prettify dart tag=pre+code %}
extension E on String {}

var x = E.[!a!]();
{% endprettify %}

#### Common fixes

If the name of the method is incorrect, then change it to the name of an
existing method:

{% prettify dart tag=pre+code %}
extension E on String {
  String a() => 'a';
}

extension F on String {
  String b() => 'b';
}

void f() {
  E('c').a();
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
extension E on String {
  String a() => 'a';
}

extension F on String {
  String b() => 'b';
}

void f() {
  F('c').b();
}
{% endprettify %}

If the name of the method and extension are both correct, but the method
isn't defined, then define the method:

{% prettify dart tag=pre+code %}
extension E on String {
  String a() => 'a';
  String b() => 'z';
}

extension F on String {
  String b() => 'b';
}

void f() {
  E('c').b();
}
{% endprettify %}

### undefined_extension_operator

_The operator '{0}' isn't defined for the extension '{1}'._

#### 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 `*`:

{% prettify dart tag=pre+code %}
var x = E('') [!*!] 4;

extension E on String {}
{% endprettify %}

#### Common fixes

If the extension is expected to implement the operator, then add an
implementation of the operator to the extension:

{% prettify dart tag=pre+code %}
var x = E('') * 4;

extension E on String {
  int operator *(int multiplier) => length * multiplier;
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
var x = '' * 4;

extension E on String {}
{% endprettify %}

### undefined_extension_setter

_The setter '{0}' isn't defined for the extension '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
extension E on String {
  set a(String v) {}
}

extension F on String {
  set b(String v) {}
}

void f() {
  E('c').[!b!] = 'd';
}
{% endprettify %}

The following code produces this diagnostic because the extension `E`
doesn't declare a static setter named `a`:

{% prettify dart tag=pre+code %}
extension E on String {}

void f() {
  E.[!a!] = 3;
}
{% endprettify %}

#### Common fixes

If the name of the setter is incorrect, then change it to the name of an
existing setter:

{% prettify dart tag=pre+code %}
extension E on String {
  set a(String v) {}
}

extension F on String {
  set b(String v) {}
}

void f() {
  E('c').a = 'd';
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
extension E on String {
  set a(String v) {}
}

extension F on String {
  set b(String v) {}
}

void f() {
  F('c').b = 'd';
}
{% endprettify %}

If the name of the setter and extension are both correct, but the setter
isn't defined, then define the setter:

{% prettify dart tag=pre+code %}
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';
}
{% endprettify %}

### undefined_function

_The function '{0}' isn't defined._

#### 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:

{% prettify dart tag=pre+code %}
List<int> empty() => [];

void main() {
  print([!emty!]());
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
List<int> empty() => [];

void main() {
  print(empty());
}
{% endprettify %}

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

_The getter '{0}' isn't defined for the '{1}' function type._

_The getter '{0}' isn't defined for the type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
int f(String s) => s.[!len!];
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int f(String s) => s.length;
{% endprettify %}

### undefined_hidden_name

_The library '{0}' doesn't export a member with the hidden name '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
import 'dart:math' hide [!String!], max;

var x = min(0, 1);
{% endprettify %}

#### Common fixes

If a different name should be hidden, then correct the name. Otherwise,
remove the name from the list:

{% prettify dart tag=pre+code %}
import 'dart:math' hide max;

var x = min(0, 1);
{% endprettify %}

### undefined_identifier

_Undefined name '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
int min(int left, int right) => left <= [!rihgt!] ? left : right;
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int min(int left, int right) => left <= right ? left : right;
{% endprettify %}

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

_Undefined name 'await' in function body not marked with 'async'._

#### 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:

{% prettify dart tag=pre+code %}
void f(p) { [!await!] p; }
{% endprettify %}

#### Common fixes

Add the keyword `async` to the function body:

{% prettify dart tag=pre+code %}
void f(p) async { await p; }
{% endprettify %}

### undefined_method

_The method '{0}' isn't defined for the '{1}' function type._

_The method '{0}' isn't defined for the type '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
int f(List<int> l) => l.[!removeMiddle!]();
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
int f(List<int> l) => l.removeLast();
{% endprettify %}

### undefined_named_parameter

_The named parameter '{0}' isn't defined._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  m({int b}) {}
}

void f(C c) {
  c.m([!a!]: 1);
}
{% endprettify %}

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  m({int b}) {}
}

void f(C c) {
  c.m(b: 1);
}
{% endprettify %}

If a subclass adds a parameter with the name in question, then cast the
receiver to the subclass:

{% prettify dart tag=pre+code %}
class C {
  m({int b}) {}
}

class D extends C {
  m({int a, int b}) {}
}

void f(C c) {
  (c as D).m(a: 1);
}
{% endprettify %}

If the parameter should be added to the function, then add it:

{% prettify dart tag=pre+code %}
class C {
  m({int a, int b}) {}
}

void f(C c) {
  c.m(a: 1);
}
{% endprettify %}

### undefined_operator

_The operator '{0}' isn't defined for the type '{1}'._

#### 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 `+`:

{% prettify dart tag=pre+code %}
class C {}

C f(C c) => c [!+!] 2;
{% endprettify %}

#### Common fixes

If the operator should be defined for the class, then define it:

{% prettify dart tag=pre+code %}
class C {
  C operator +(int i) => this;
}

C f(C c) => c + 2;
{% endprettify %}

### undefined_prefixed_name

_The name '{0}' is being referenced through the prefix '{1}', but it isn't
defined in any of the libraries imported using that prefix._

#### 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`:

{% prettify dart tag=pre+code %}
import 'dart:core' as p;

void f() {
  p.[!a!];
}
{% endprettify %}

#### 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_referenced_parameter

_The parameter '{0}' isn't defined by '{1}'._

#### Description

The analyzer produces this diagnostic when an annotation of the form
[`UseResult.unless(parameterDefined: parameterName)`][meta-UseResult]
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`:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@UseResult.unless(parameterDefined: [!'b'!])
int f([int? a]) => a ?? 0;
{% endprettify %}

#### Common fixes

Change the argument named `parameterDefined` to match the name of one of
the parameters to the function:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

@UseResult.unless(parameterDefined: 'a')
int f([int? a]) => a ?? 0;
{% endprettify %}

### undefined_setter

_The setter '{0}' isn't defined for the '{1}' function type._

_The setter '{0}' isn't defined for the type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  int x = 0;
  void m(int y) {
    this.[!z!] = y;
  }
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int x = 0;
  void m(int y) {
    this.x = y;
  }
}
{% endprettify %}

### undefined_shown_name

_The library '{0}' doesn't export a member with the shown name '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
import 'dart:math' show min, [!String!];

var x = min(0, 1);
{% endprettify %}

#### Common fixes

If a different name should be shown, then correct the name. Otherwise,
remove the name from the list:

{% prettify dart tag=pre+code %}
import 'dart:math' show min;

var x = min(0, 1);
{% endprettify %}

### undefined_super_member

<a id="undefined_super_method" aria-hidden="true"></a>_(Previously known as `undefined_super_method`)_

_The getter '{0}' isn't defined in a superclass of '{1}'._

_The method '{0}' isn't defined in a superclass of '{1}'._

_The operator '{0}' isn't defined in a superclass of '{1}'._

_The setter '{0}' isn't defined in a superclass of '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  void m() {
    super.[!n!]();
  }
}
{% endprettify %}

The following code produces this diagnostic because `Object` doesn't define
a getter named `g`:

{% prettify dart tag=pre+code %}
class C {
  void m() {
    super.[!g!];
  }
}
{% endprettify %}

#### 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.

### unknown_platform

_The platform '{0}' is not a recognized platform._

#### Description

The analyzer produces this diagnostic when an unknown platform name is
used as a key in the `platforms` map.
See the [documentation on platform declaration](https://dart.dev/tools/pub/pubspec#platforms)
for details.

#### Example

The following `pubspec.yaml` produces this diagnostic because the platform
`browser` is unknown.

```yaml
name: example
platforms:
  [!browser:!]
```

#### Common fixes

If you can rely on automatic platform detection, then omit the
top-level `platforms` key.

```yaml
name: example
```

If you need to manually specify the list of supported platforms, then
write the `platforms` field as a map with known platform names as keys.

```yaml
name: example
platforms:
  # These are the known platforms
  android:
  ios:
  linux:
  macos:
  web:
  windows:
```

### unnecessary_cast

_Unnecessary cast._

#### 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:

{% prettify dart tag=pre+code %}
void f(num n) {
  if (n is int) {
    ([!n as int!]).isEven;
  }
}
{% endprettify %}

#### Common fixes

Remove the unnecessary cast:

{% prettify dart tag=pre+code %}
void f(num n) {
  if (n is int) {
    n.isEven;
  }
}
{% endprettify %}

### unnecessary_dev_dependency

_The dev dependency on {0} is unnecessary because there is also a normal
dependency on that package._

#### 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
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
name: example
dependencies:
  meta: ^1.0.2
```

### unnecessary_final

_The keyword 'final' isn't necessary because the parameter is implicitly
'final'._

#### Description

The analyzer produces this diagnostic when either a field initializing
parameter or a super parameter in a constructor has the keyword `final`.
In both cases the keyword is unnecessary because the parameter is
implicitly `final`.

#### Examples

The following code produces this diagnostic because the field initializing
parameter has the keyword `final`:

{% prettify dart tag=pre+code %}
class A {
  int value;

  A([!final!] this.value);
}
{% endprettify %}

The following code produces this diagnostic because the super parameter in
`B` has the keyword `final`:

{% prettify dart tag=pre+code %}
class A {
  A(int value);
}

class B extends A {
  B([!final!] super.value);
}
{% endprettify %}

#### Common fixes

Remove the unnecessary `final` keyword:

{% prettify dart tag=pre+code %}
class A {
  A(int value);
}

class B extends A {
  B(super.value);
}
{% endprettify %}

### unnecessary_import

_The import of '{0}' is unnecessary because all of the used elements are also
provided by the import of '{1}'._

#### 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 `a.dart` that contains the following:

{% prettify dart tag=pre+code %}
class A {}
{% endprettify %}

And, given a file `b.dart` that contains the following:

{% prettify dart tag=pre+code %}
export 'a.dart';

class B {}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
import [!'a.dart'!];
import 'b.dart';

void f(A a, B b) {}
{% endprettify %}

#### 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_nan_comparison

_A double can't equal 'double.nan', so the condition is always 'false'._

_A double can't equal 'double.nan', so the condition is always 'true'._

#### Description

The analyzer produces this diagnostic when a value is compared to
`double.nan` using either `==` or `!=`.

Dart follows the [IEEE 754] floating-point standard for the semantics of
floating point operations, which states that, for any floating point value
`x` (including NaN, positive infinity, and negative infinity),
- `NaN == x` is always false
- `NaN != x` is always true

As a result, comparing any value to NaN is pointless because the result is
already known (based on the comparison operator being used).

#### Example

The following code produces this diagnostic because `d` is being compared
to `double.nan`:

{% prettify dart tag=pre+code %}
bool isNaN(double d) => d [!== double.nan!];
{% endprettify %}

#### Common fixes

Use the getter `double.isNaN` instead:

{% prettify dart tag=pre+code %}
bool isNaN(double d) => d.isNaN;
{% endprettify %}

### unnecessary_non_null_assertion

_The '!' will have no effect because the receiver can't be null._

#### 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`:

{% prettify dart tag=pre+code %}
int f(int x) {
  return x[!!!];
}
{% endprettify %}

#### Common fixes

Remove the null check operator (`!`):

{% prettify dart tag=pre+code %}
int f(int x) {
  return x;
}
{% endprettify %}

### unnecessary_no_such_method

_Unnecessary 'noSuchMethod' declaration._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  @override
  dynamic noSuchMethod(x) => super.noSuchMethod(x);
}
class B extends A {
  @override
  dynamic [!noSuchMethod!](y) {
    return super.noSuchMethod(y);
  }
}
{% endprettify %}

#### Common fixes

Remove the unnecessary declaration:

{% prettify dart tag=pre+code %}
class A {
  @override
  dynamic noSuchMethod(x) => super.noSuchMethod(x);
}
class B extends A {}
{% endprettify %}

### unnecessary_null_assert_pattern

_The null-assert pattern will have no effect because the matched type isn't
nullable._

#### Description

The analyzer produces this diagnostic when a null-assert pattern is used
to match a value that isn't nullable.

#### Example

The following code produces this diagnostic because the variable `x` isn't
nullable:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a[!!!] when a > 0) {}
}
{% endprettify %}

#### Common fixes

Remove the null-assert pattern:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a when a > 0) {}
}
{% endprettify %}

### unnecessary_null_check_pattern

_The null-check pattern will have no effect because the matched type isn't
nullable._

#### Description

The analyzer produces this diagnostic when a null-check pattern is used to
match a value that isn't nullable.

#### Example

The following code produces this diagnostic because the value `x` isn't
nullable:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a[!?!] when a > 0) {}
}
{% endprettify %}

#### Common fixes

Remove the null-check pattern:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x case var a when a > 0) {}
}
{% endprettify %}

### unnecessary_null_comparison

_The operand can't be null, so the condition is always 'false'._

_The operand can't be null, so the condition is always 'true'._

#### 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`:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x [!!= null!]) {
    print(x);
  }
}
{% endprettify %}

The following code produces this diagnostic because `x` can never be
`null`, so the comparison always evaluates to `false`:

{% prettify dart tag=pre+code %}
void f(int x) {
  if (x [!== null!]) {
    throw ArgumentError("x can't be null");
  }
}
{% endprettify %}

#### Common fixes

If the other operand should be able to be `null`, then change the type of
the operand:

{% prettify dart tag=pre+code %}
void f(int? x) {
  if (x != null) {
    print(x);
  }
}
{% endprettify %}

If the other operand really can't be `null`, then remove the condition:

{% prettify dart tag=pre+code %}
void f(int x) {
  print(x);
}
{% endprettify %}

### unnecessary_question_mark

_The '?' is unnecessary because '{0}' is nullable without it._

#### 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:

{% prettify dart tag=pre+code %}
dynamic[!?!] x;
{% endprettify %}

#### Common fixes

Remove the unneeded question mark:

{% prettify dart tag=pre+code %}
dynamic x;
{% endprettify %}

### unnecessary_set_literal

_Braces unnecessarily wrap this expression in a set literal._

#### Description

The analyzer produces this diagnostic when a function that has a return
type of `void`, `Future<void>`, or `FutureOr<void>` uses an expression
function body (`=>`) and the returned value is a literal set containing a
single element.

Although the language allows it, returning a value from a `void` function
isn't useful because it can't be used at the call site. In this particular
case the return is often due to a misunderstanding about the syntax. The
braces aren't necessary and can be removed.

#### Example

The following code produces this diagnostic because the closure being
passed to `g` has a return type of `void`, but is returning a set:

{% prettify dart tag=pre+code %}
void f() {
  g(() => [!{1}!]);
}

void g(void Function() p) {}
{% endprettify %}

#### Common fixes

Remove the braces from around the value:

{% prettify dart tag=pre+code %}
void f() {
  g(() => 1);
}

void g(void Function() p) {}
{% endprettify %}

### unnecessary_type_check

_Unnecessary type check; the result is always 'false'._

_Unnecessary type check; the result is always 'true'._

#### 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`:

{% prettify dart tag=pre+code %}
bool f<T>(T a) => [!a is Object?!];
{% endprettify %}

#### Common fixes

If the type check doesn't check what you intended to check, then change the
test:

{% prettify dart tag=pre+code %}
bool f<T>(T a) => a is Object;
{% endprettify %}

If the type check does check what you intended to check, then replace the
type check with its known value or completely remove it:

{% prettify dart tag=pre+code %}
bool f<T>(T a) => true;
{% endprettify %}

### unqualified_reference_to_non_local_static_member

_Static members from supertypes must be qualified by the name of the defining
type._

#### 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:

{% prettify dart tag=pre+code %}
class A {
  static int x = 3;
}

class B extends A {
  int get g => [!x!];
}
{% endprettify %}

#### Common fixes

Prefix the name of the static member with the name of the declaring class:

{% prettify dart tag=pre+code %}
class A {
  static int x = 3;
}

class B extends A {
  int get g => A.x;
}
{% endprettify %}

### unqualified_reference_to_static_member_of_extended_type

_Static members from the extended type or one of its superclasses must be
qualified by the name of the defining type._

#### 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`:

{% prettify dart tag=pre+code %}
class C {
  static void m() {}
}

extension E on C {
  void f() {
    [!m!]();
  }
}
{% endprettify %}

#### 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:

{% prettify dart tag=pre+code %}
class C {
  static void m() {}
}

extension E on C {
  void f() {
    C.m();
  }
}
{% endprettify %}

If you're referencing a member that isn't declared yet, add a declaration:

{% prettify dart tag=pre+code %}
class C {
  static void m() {}
}

extension E on C {
  void f() {
    m();
  }

  void m() {}
}
{% endprettify %}

### unreachable_switch_case

_This case is covered by the previous cases._

#### Description

The analyzer produces this diagnostic when a `case` clause in a `switch`
statement doesn't match anything because all of the matchable values are
matched by an earlier `case` clause.

#### Example

The following code produces this diagnostic because the value `1` was
matched in the preceding case:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case 1:
      print('one');
    [!case!] 1:
      print('two');
  }
}
{% endprettify %}

#### Common fixes

Change one or both of the conflicting cases to match different values:

{% prettify dart tag=pre+code %}
void f(int x) {
  switch (x) {
    case 1:
      print('one');
    case 2:
      print('two');
  }
}
{% endprettify %}

### unused_catch_clause

_The exception variable '{0}' isn't used, so the 'catch' clause can be removed._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
    int.parse(';');
  } on FormatException catch ([!e!]) {
    // ignored
  }
}
{% endprettify %}

#### Common fixes

Remove the unused `catch` clause:

{% prettify dart tag=pre+code %}
void f() {
  try {
    int.parse(';');
  } on FormatException {
    // ignored
  }
}
{% endprettify %}

### unused_catch_stack

_The stack trace variable '{0}' isn't used and can be removed._

#### 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:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } catch (exception, [!stackTrace!]) {
    // ...
  }
}
{% endprettify %}

#### Common fixes

If you need to reference the stack trace parameter, then add a reference to
it. Otherwise, remove it:

{% prettify dart tag=pre+code %}
void f() {
  try {
    // ...
  } catch (exception) {
    // ...
  }
}
{% endprettify %}

### unused_element

_A value for optional parameter '{0}' isn't ever given._

_The declaration '{0}' isn't referenced._

#### 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 and all of their members
- Private members of public declarations
- Optional parameters of private functions for which a value is never
  passed

Not all references to an element will mark it as "used":
- Assigning a value to a top-level variable (with a standard `=`
  assignment, or a null-aware `??=` assignment) does not count as using
  it.
- Referring to an element in a doc comment reference does not count as
  using it.
- Referring to a class, mixin, or enum on the right side of an `is`
  expression does not count as using it.

#### Example

Assuming that no code in the library references `_C`, the following code
produces this diagnostic:

{% prettify dart tag=pre+code %}
class [!_C!] {}
{% endprettify %}

Assuming that no code in the library passes a value for `y` in any
invocation of `_m`, the following code produces this diagnostic:

{% prettify dart tag=pre+code %}
class C {
  void _m(int x, [int [!y!]]) {}

  void n() => _m(0);
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
class C {
  void _m(int x) {}

  void n() => _m(0);
}
{% endprettify %}

If the declaration is intended to be used, then add the code to use it.

### unused_field

_The value of the field '{0}' isn't used._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  final String [!_originalValue!];
  final String _currentValue;

  C(this._originalValue) : _currentValue = _originalValue;

  String get value => _currentValue;
}
{% endprettify %}

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

_Unused import: '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
import [!'dart:async'!];

void main() {}
{% endprettify %}

#### 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

_The label '{0}' isn't used._

#### 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:

{% prettify dart tag=pre+code %}
void f(int limit) {
  [!loop:!] for (int i = 0; i < limit; i++) {
    print(i);
  }
}
{% endprettify %}

#### Common fixes

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

{% prettify dart tag=pre+code %}
void f(int limit) {
  for (int i = 0; i < limit; i++) {
    print(i);
  }
}
{% endprettify %}

If the label is needed, then use it:

{% prettify dart tag=pre+code %}
void f(int limit) {
  loop: for (int i = 0; i < limit; i++) {
    print(i);
    if (i != 0) {
      break loop;
    }
  }
}
{% endprettify %}

### unused_local_variable

_The value of the local variable '{0}' isn't used._

#### 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:

{% prettify dart tag=pre+code %}
void main() {
  int [!count!] = 0;
}
{% endprettify %}

#### 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

_'{0}' should be used. {1}._

_The value of '{0}' should be used._

#### 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]:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @useResult
  int a() => 0;

  int b() => 0;
}

void f(C c) {
  c.[!a!]();
}
{% endprettify %}

#### Common fixes

If you intended to invoke the annotated function, then use the value that
was returned:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @useResult
  int a() => 0;

  int b() => 0;
}

void f(C c) {
  print(c.a());
}
{% endprettify %}

If you intended to invoke a different function, then correct the name of
the function being invoked:

{% prettify dart tag=pre+code %}
import 'package:meta/meta.dart';

class C {
  @useResult
  int a() => 0;

  int b() => 0;
}

void f(C c) {
  c.b();
}
{% endprettify %}

### unused_shown_name

_The name {0} is shown, but isn't used._

#### 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:

{% prettify dart tag=pre+code %}
import 'dart:math' show min, [!max!];

var x = min(0, 1);
{% endprettify %}

#### Common fixes

Either use the name or remove it:

{% prettify dart tag=pre+code %}
import 'dart:math' show min;

var x = min(0, 1);
{% endprettify %}

### uri_does_not_exist

_Target of URI doesn't exist: '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
import [!'lib.dart'!];
{% endprettify %}

#### 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

_Target of URI hasn't been generated: '{0}'._

#### 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:

{% prettify dart tag=pre+code %}
import [!'lib.g.dart'!];
{% endprettify %}

#### 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

_URIs can't use string interpolation._

#### 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:

{% prettify dart tag=pre+code %}
import [!'dart:$m'!];

const m = 'math';
{% endprettify %}

#### Common fixes

Remove the interpolation from the URI:

{% prettify dart tag=pre+code %}
import 'dart:math';

var zero = min(0, 0);
{% endprettify %}

### use_of_native_extension

_Dart native extensions are deprecated and aren't available in Dart 2.15._

#### 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`:

{% prettify dart tag=pre+code %}
import [!'dart-ext:x'!];
{% endprettify %}

#### Common fixes

Rewrite the code to use `dart:ffi` as a way of invoking the contents of the
native library.

### use_of_void_result

_This expression has a type of 'void' so its value can't be used._

#### 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:

{% prettify dart tag=pre+code %}
void f() {}

void g() {
  [!f()!].toString();
}
{% endprettify %}

#### 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

_A member named 'values' can't be declared in an enum._

#### 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`:

{% prettify dart tag=pre+code %}
enum E {
  v;
  void [!values!]() {}
}
{% endprettify %}

#### Common fixes

Change the name of the conflicting member:

{% prettify dart tag=pre+code %}
enum E {
  v;
  void getValues() {}
}
{% endprettify %}

### variable_pattern_keyword_in_declaration_context

_Variable patterns in declaration context can't specify 'var' or 'final'
keyword._

#### Description

The analyzer produces this diagnostic when a variable pattern is used
within a declaration context.

#### Example

The following code produces this diagnostic because the variable patterns
in the record pattern are in a declaration context:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  var ([!var!] x, y) = r;
  print(x + y);
}
{% endprettify %}

#### Common fixes

Remove the `var` or `final` keyword(s) within the variable pattern:

{% prettify dart tag=pre+code %}
void f((int, int) r) {
  var (x, y) = r;
  print(x + y);
}
{% endprettify %}

### variable_type_mismatch

_A value of type '{0}' can't be assigned to a const variable of type '{1}'._

#### 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`:

{% prettify dart tag=pre+code %}
const Object x = 0;
const String y = [!x!];
{% endprettify %}

#### Common fixes

If the declaration of the constant is correct, then change the value being
assigned to be of the correct type:

{% prettify dart tag=pre+code %}
const Object x = 0;
const String y = '$x';
{% endprettify %}

If the assigned value is correct, then change the declaration to have the
correct type:

{% prettify dart tag=pre+code %}
const Object x = 0;
const int y = x;
{% endprettify %}

### wrong_number_of_parameters_for_operator

_Operator '-' should declare 0 or 1 parameter, but {0} found._

_Operator '{0}' should declare exactly {1} parameters, but {2} found._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int operator [!+!](a, b) => 0;
}
{% endprettify %}

#### Common fixes

Add or remove parameters to match the required number:

{% prettify dart tag=pre+code %}
class C {
  int operator +(a) => 0;
}
{% endprettify %}

### wrong_number_of_parameters_for_setter

_Setters must declare exactly one required positional parameter._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  set [!s!](int x, int y) {}
}
{% endprettify %}

The following code produces this diagnostic because the setter `s` declares
one optional parameter:

{% prettify dart tag=pre+code %}
class C {
  set [!s!]([int x]) {}
}
{% endprettify %}

#### Common fixes

Change the declaration so that there's exactly one required positional
parameter:

{% prettify dart tag=pre+code %}
class C {
  set s(int x) {}
}
{% endprettify %}

### wrong_number_of_type_arguments

_The type '{0}' is declared with {1} type parameters, but {2} type arguments
were given._

#### 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:

{% prettify dart tag=pre+code %}
class C<E> {}

void f([!C<int, int>!] x) {}
{% endprettify %}

The following code produces this diagnostic because `C` declares one type
parameter, but two type arguments are provided when creating an instance:

{% prettify dart tag=pre+code %}
class C<E> {}

var c = [!C<int, int>!]();
{% endprettify %}

#### Common fixes

Add or remove type arguments, as necessary, to match the number of type
parameters defined for the type:

{% prettify dart tag=pre+code %}
class C<E> {}

void f(C<int> x) {}
{% endprettify %}

### wrong_number_of_type_arguments_constructor

_The constructor '{0}.{1}' doesn't have type parameters._

#### 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:

{% prettify dart tag=pre+code %}
class C<T> {
  C.named();
}
C f() => C.named[!<String>!]();
{% endprettify %}

#### Common fixes

If the type arguments are for the class' type parameters, then move the
type arguments to follow the class name:

{% prettify dart tag=pre+code %}
class C<T> {
  C.named();
}
C f() => C<String>.named();
{% endprettify %}

If the type arguments aren't for the class' type parameters, then remove
them:

{% prettify dart tag=pre+code %}
class C<T> {
  C.named();
}
C f() => C.named();
{% endprettify %}

### wrong_number_of_type_arguments_enum

_The enum is declared with {0} type parameters, but {1} type arguments were
given._

#### 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:

{% prettify dart tag=pre+code %}
enum E<T, U> {
  c[!<int>!]()
}
{% endprettify %}

#### Common fixes

If the number of type parameters is correct, then change the number of
type arguments to match the number of type parameters:

{% prettify dart tag=pre+code %}
enum E<T, U> {
  c<int, String>()
}
{% endprettify %}

If the number of type arguments is correct, then change the number of type
parameters to match the number of type arguments:

{% prettify dart tag=pre+code %}
enum E<T> {
  c<int>()
}
{% endprettify %}

### wrong_number_of_type_arguments_extension

_The extension '{0}' is declared with {1} type parameters, but {2} type
arguments were given._

#### 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:

{% prettify dart tag=pre+code %}
extension E<T> on List<T> {
  int get len => length;
}

void f(List<int> p) {
  E[!<int, String>!](p).len;
}
{% endprettify %}

#### Common fixes

Change the type arguments so that there are the same number of type
arguments as there are type parameters:

{% prettify dart tag=pre+code %}
extension E<T> on List<T> {
  int get len => length;
}

void f(List<int> p) {
  E<int>(p).len;
}
{% endprettify %}

### wrong_number_of_type_arguments_method

_The method '{0}' is declared with {1} type parameters, but {2} type arguments
are given._

#### 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:

{% prettify dart tag=pre+code %}
class C {
  int m<A>(A a) => 0;
}

int f(C c) => c.m[!<int, int>!](2);
{% endprettify %}

#### Common fixes

If the type arguments are necessary, then make them match the number of
type parameters by either adding or removing type arguments:

{% prettify dart tag=pre+code %}
class C {
  int m<A>(A a) => 0;
}

int f(C c) => c.m<int>(2);
{% endprettify %}

If the type arguments aren't necessary, then remove them:

{% prettify dart tag=pre+code %}
class C {
  int m<A>(A a) => 0;
}

int f(C c) => c.m(2);
{% endprettify %}

### yield_in_non_generator

_Yield statements must be in a generator function (one marked with either
'async*' or 'sync*')._

_Yield-each statements must be in a generator function (one marked with either
'async*' or 'sync*')._

#### 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:

{% prettify dart tag=pre+code %}
Iterable<int> get digits {
  yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
}
{% endprettify %}

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:

{% prettify dart tag=pre+code %}
Stream<int> get digits async {
  yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
}
{% endprettify %}

#### Common fixes

Add a modifier, or change the existing modifier to be either `async*` or
`sync*`:

{% prettify dart tag=pre+code %}
Iterable<int> get digits sync* {
  yield* [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
}
{% endprettify %}

### yield_of_invalid_type

_A yielded value of type '{0}' must be assignable to '{1}'._

_The type '{0}' implied by the 'yield*' expression must be assignable to '{1}'._

#### 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:

{% prettify dart tag=pre+code %}
Iterable<int> get zero sync* {
  yield [!'0'!];
}
{% endprettify %}

#### Common fixes

If the return type of the function is correct, then fix the expression
following the keyword `yield` to return the correct type:

{% prettify dart tag=pre+code %}
Iterable<int> get zero sync* {
  yield 0;
}
{% endprettify %}

If the expression following the `yield` is correct, then change the return
type of the function to allow it:

{% prettify dart tag=pre+code %}
Iterable<String> get zero sync* {
  yield '0';
}
{% endprettify %}
