Diagnostic messages

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.

Glossary

This page uses the following terms:

• constant context
• definite assignment
• mixin application
• override inference
• part file
• potentially non-nullable
• public library

Constant context

A constant context is a region of code in which it isn’t necessary to include the const keyword because it’s implied by the fact that everything in that region is required to be a constant. The following locations are constant contexts:

• Everything inside a list, map or set literal that’s prefixed by the const keyword. Example:

  var l = const [/*constant context*/];
  

• The arguments inside an invocation of a constant constructor. Example:

  var p = const Point(/*constant context*/);
  

• The initializer for a variable that’s prefixed by the const keyword. Example:

  const v = /*constant context*/;
  

• Annotations

• The expression in a case clause. Example:

  void f(int e) {
    switch (e) {
      case /*constant context*/:
        break;
    }
  }
  

Definite assignment

Definite assignment analysis is the process of determining, for each local variable at each point in the code, which of the following is true:

• The variable has definitely been assigned a value (definitely assigned).
• The variable has definitely not been assigned a value (definitely unassigned).
• The variable might or might not have been assigned a value, depending on the execution path taken to arrive at that point.

Definite assignment analysis helps find problems in code, such as places where a variable that might not have been assigned a value is being referenced, or places where a variable that can only be assigned a value one time is being assigned after it might already have been assigned a value.

For example, in the following code the variable s is definitely unassigned when it’s passed as an argument to print:

void f() {
  String s;
  print(s);
}

But in the following code, the variable s is definitely assigned:

void f(String name) {
  String s = 'Hello $name!';
  print(s);
}

Definite assignment analysis can even tell whether a variable is definitely assigned (or unassigned) when there are multiple possible execution paths. In the following code the print function is called if execution goes through either the true or the false branch of the if statement, but because s is assigned no matter which branch is taken, it’s definitely assigned before it’s passed to print:

void f(String name, bool casual) {
  String s;
  if (casual) {
    s = 'Hi $name!';
  } else {
    s = 'Hello $name!';
  }
  print(s);
}

In flow analysis, the end of the if statement is referred to as a join—a place where two or more execution paths merge back together. Where there’s a join, the analysis says that a variable is definitely assigned if it’s definitely assigned along all of the paths that are merging, and definitely unassigned if it’s definitely unassigned along all of the paths.

Sometimes a variable is assigned a value on one path but not on another, in which case the variable might or might not have been assigned a value. In the following example, the true branch of the if statement might or might not be executed, so the variable might or might be assigned a value:

void f(String name, bool casual) {
  String s;
  if (casual) {
    s = 'Hi $name!';
  }
  print(s);
}

The same is true if there is a false branch that doesn’t assign a value to s.

The analysis of loops is a little more complicated, but it follows the same basic reasoning. For example, the condition in a while loop is always executed, but the body might or might not be. So just like an if statement, there’s a join at the end of the while statement between the path in which the condition is true and the path in which the condition is false.

For additional details, see the specification of definite assignment.

Mixin application

A mixin application is the class created when a mixin is applied to a class. For example, consider the following declarations:

class A {}

mixin M {}

class B extends A with M {}

The class B is a subclass of the mixin application of M to A, sometimes nomenclated as A+M. The class A+M is a subclass of A and has members that are copied from M.

You can give an actual name to a mixin application by defining it as:

class A {}

mixin M {}

class A_M = A with M;

Given this declaration of A_M, the following declaration of B is equivalent to the declaration of B in the original example:

class B extends A_M {}

Override inference

Override inference is the process by which any missing types in a method declaration are inferred based on the corresponding types from the method or methods that it overrides.

If a candidate method (the method that’s missing type information) overrides a single inherited method, then the corresponding types from the overridden method are inferred. For example, consider the following code:

class A {
  int m(String s) => 0;
}

class B extends A {
  @override
  m(s) => 1;
}

The declaration of m in B is a candidate because it’s missing both the return type and the parameter type. Because it overrides a single method (the method m in A), the types from the overridden method will be used to infer the missing types and it will be as if the method in B had been declared as int m(String s) => 1;.

If a candidate method overrides multiple methods, and the function type one of those overridden methods, M_s, is a supertype of the function types of all of the other overridden methods, then M_s is used to infer the missing types. For example, consider the following code:

class A {
  int m(num n) => 0;
}

class B {
  num m(int i) => 0;
}

class C implements A, B {
  @override
  m(n) => 1;
}

The declaration of m in C is a candidate for override inference because it’s missing both the return type and the parameter type. It overrides both m in A and m in B, so we need to choose one of them from which the missing types can be inferred. But because the function type of m in A (int Function(num)) is a supertype of the function type of m in B (num Function(int)), the function in A is used to infer the missing types. The result is the same as declaring the method in C as int m(num n) => 1;.

It is an error if none of the overridden methods has a function type that is a supertype of all the other overridden methods.

Part file

A part file is a Dart source file that contains a part of directive.

Potentially non-nullable

A type is potentially non-nullable if it’s either explicitly non-nullable or if it’s a type parameter.

A type is explicitly non-nullable if it is a type name that isn’t followed by a question mark. Note that there are a few types that are always nullable, such as Null and dynamic, and that FutureOr is only non-nullable if it isn’t followed by a question mark and the type argument is non-nullable (such as FutureOr<String>).

Type parameters are potentially non-nullable because the actual runtime type (the type specified as a type argument) might be non-nullable. For example, given a declaration of class C<T> {}, the type C could be used with a non-nullable type argument as in C<int>.

Public library

A public library is a library that is located inside the package’s lib directory but not inside the lib/src directory.

Diagnostics

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

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:

import 'dart:ffi';

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

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

import 'dart:ffi';

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

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

import 'dart:ffi';

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

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

import 'dart:ffi';

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

  const C(this.i);
}

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

import 'dart:ffi';

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

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:

import 'dart:ffi';

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

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:

import 'dart:ffi';

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

Common fixes

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

import 'dart:ffi';

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

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:

import 'dart:ffi';

final class C extends AbiSpecificInteger {
  const C();
}

Common fixes

Add an AbiSpecificIntegerMapping annotation to the class:

import 'dart:ffi';

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

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:

import 'dart:ffi';

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

Common fixes

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

import 'dart:ffi';

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

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:

abstract class C {
  abstract int f = 0;
}

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

abstract class C {
  abstract int f;

  C() : f = 0;
}

Common fixes

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

abstract class C {
  abstract int f;
}

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

abstract class C {
  int f = 0;
}

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:

abstract sealed class C {}

Common fixes

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

abstract class C {}

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

sealed class C {}

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:

abstract class A {
  int get a;
}
class B extends A {
  int get a => super.a;
}

Common fixes

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

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

class C {}

And a file b.dart containing

class C {}

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

export 'a.dart';
export 'b.dart';

Common fixes

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

export 'a.dart';

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

export 'a.dart';
export 'b.dart' hide C;

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:

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

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

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

Common fixes

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

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

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

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

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

ambiguous_import

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

class A {}
class C {}

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

class B {}
class C {}

The following code produces this diagnostic:

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

void f(C c1, C c2) {}

Common fixes

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

import 'a.dart';

void f(C c1, C c2) {}

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

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

void f(C c1, C c2) {}

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

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

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

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:

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

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

Common fixes

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

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

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

union(Map<String, String> a, List<String> b, Map<String, String> c) =>
    {...a, for (String s in b) s: s, ...c};

ambiguous_set_or_map_literal_either

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:

union(a, b) => {...a, ...b};

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

Common fixes

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

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

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

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

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

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

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

union(a, b) {
  var x = {...a, ...b};
  return x;
}

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

union(a, b) {
  Map<String, String> x = {...a, ...b};
  return x;
}

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.

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

import 'dart:ffi';

final class C extends Struct {
  @Double()
  external Pointer<Int8> p;
}

Common fixes

Remove the annotations from the field:

import 'dart:ffi';

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

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.

Example

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

import 'dart:ffi';

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

Common fixes

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

import 'dart:ffi';

const isLeaf = false;

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

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

import 'dart:ffi';

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

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:

String f(String x) => x;
String g(num y) => f(y);

Common fixes

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

String f(String x) => x;
String g(String y) => f(y);

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

String f(String x) => x;
String g(num y) => f(y.toString());

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

String f(String x) => x;
String g(num y) => f(y is String ? y : '');

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

String f(String x) => x;
String g(num y) => f(y as String);

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:

void f(Future<int> f) {
  f.catchError(() => 0);
}

The following code produces this diagnostic because the closure being passed to catchError takes three parameters, but it can’t have more than two required parameters:

void f(Future<int> f) {
  f.catchError((one, two, three) => 0);
}

The following code produces this diagnostic because even though the closure being passed to catchError takes one parameter, the closure doesn’t have a type that is compatible with Object:

void f(Future<int> f) {
  f.catchError((String error) => 0);
}

Common fixes

Change the function being passed to catchError so that it has either one or two required parameters, and the parameters have the required types:

void f(Future<int> f) {
  f.catchError((Object error) => 0);
}

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:

class C {
  C(int x) : assert(x > 0), this.name();
  C.name() {}
}

Common fixes

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

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

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

class C {
  factory C(int x) {
    assert(x > 0);
    return C.name();
  }
  C.name() {}
}

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:

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:

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:

name: example
flutter:
  assets: assets/

Common fixes

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

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:

name: example
flutter:
  assets:
    - image.gif: true

Common fixes

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

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:

import 'package:meta/meta.dart';

@doNotStore
int f() => 1;

var x = f();

Common fixes

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

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:

const c = 0;

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

Common fixes

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

var c = 0;

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

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

const c = 0;

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

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:

class C {
  final v = 0;
}

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

Common fixes

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

class C {
  int v = 0;
}

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

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:

void f() {
  final x = 0;
  x = 3;
  print(x);
}

Common fixes

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

void f() {
  var x = 0;
  x = 3;
  print(x);
}

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:

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

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

Common fixes

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

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

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

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

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

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

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:

void f() {}

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

Common fixes

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

void f() {}

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

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

void Function() f = () {};

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

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:

class C {
  void f() {}

  void g() {
    f = null;
  }
}

Common fixes

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

assignment_to_type

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:

class C {}

void f() {
  C = null;
}

Common fixes

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

void f() {}

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

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:

void f(list) {
  await for (var e in list) {
    print(e);
  }
}

Common fixes

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

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

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

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

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

void f(list) {
  for (var e in list) {
    print(e);
  }
}

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:

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

Common fixes

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

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

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

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

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:

class C {
  int m(int t) {
    print(t);
  }
}

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

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

Common fixes

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

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

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

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

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

class C<T> {
  T? m(T t) {
    print(t);
    return null;
  }
}

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

void g(Future<int> f) {
  f.catchError((e, st) {});
}

Common fixes

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

void g(Future<int> f) {
  f.catchError((e, st) {
    return -1;
  });
}

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

void g(Future<void> f) {
  f.catchError((e, st) {});
}

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:

String? f() {}

Common fixes

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

String? f() {
  return null;
}

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

String? f() {
  return '';
}

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:

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

Common fixes

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

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

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

void f(int i) {
  switch (i) {
    l: case 0:
      break;
    case 1:
      continue l;
  }
}

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:

import<int> x;

Common fixes

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

List<int> x;

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:

extension mixin on int {}

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:

void f(int x) {
  switch (x) {
    case 0:
      x += 2;
    default:
      x += 1;
  }
}

Common fixes

Add one of the required terminators:

void f(int x) {
  switch (x) {
    case 0:
      x += 2;
      break;
    default:
      x += 1;
  }
}

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:

class C {
  final int value;

  const C(this.value);

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

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

Common fixes

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

class C {
  final int value;

  const C(this.value);

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

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

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

class C {
  final int value;

  const C(this.value);
}

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

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

class C {
  final int value;

  const C(this.value);

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

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

case_expression_type_is_not_switch_expression_subtype

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

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

Common fixes

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

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

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

void f(int s) {
  switch (s) {
    case 1:
      break;
  }
}

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:

void f() {
  num? x;
  x as int;
  print(x);
}

Common fixes

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

void f() {
  num? x = 3;
  x as int;
  print(x);
}

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

void f() {
  num? x;
  print(x);
}

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:

void f(Null n) {
  n as int;
}

Common fixes

Remove the unnecessary cast:

void f(Null n) {
  n;
}

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:

num x = 0;
int y = x as x;

Common fixes

Replace the name with the name of a type:

num x = 0;
int y = x as int;

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:

class M {}
class C with M {}

Common fixes

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

mixin M {}
class C with M {}

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

mixin class M {}
class C with M {}

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

Example

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

const zero = 0;

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

import 'a.dart' deferred as a;

var l = const [a.zero];

Common fixes

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

import 'a.dart' deferred as a;

var l = [a.zero];

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

import 'a.dart' as a;

var l = const [a.zero];

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

var l = const [0];

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.

Example

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

import 'dart:ffi';

final class S extends Struct implements Finalizable {
  external Pointer notEmpty;
}

Common fixes

Try removing the implements clause from the class:

import 'dart:ffi';

final class S extends Struct {
  external Pointer notEmpty;
}

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:

abstract class A implements Enum {}

class B implements A {}

Common fixes

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

abstract class A implements Enum {}

class B implements C {}

class C {}

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

abstract class A {}

class B implements A {}

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

abstract class A implements Enum {}

class B {}

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:

class C {
  void m();
}

Common fixes

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

class C {
  void m() {}
}

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

abstract class C {
  void m();
}

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:

class C {
  C.foo();
  static int foo = 0;
}

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

class C {
  C.foo();
  static void foo() {}
}

Common fixes

Rename either the member or the constructor.

conflicting_generic_interfaces

The class ‘{0}’ can’t implement both ‘{1}’ and ‘{2}’ 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 implementsB), but int and String aren’t the same type:

class I<T> {}
class A implements I<int> {}
class B implements I<String> {}
class C extends A implements B {}

Common fixes

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

class I<T> {}
class A<S> implements I<S> {}
class B implements I<String> {}
class C extends A<String> implements B {}

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:

class C<C> {}

Common fixes

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

class C<T> {}

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:

class C<T> {
  int T = 0;
}

Common fixes

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

class C<T> {
  int total = 0;
}

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:

void f(int x) {
  if (x case true) {}
}

Common fixes

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

void f(int x) {
  if (x case 3) {}
}

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

void f(bool x) {
  if (x case true) {}
}

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:

void f(int e, int i) {
  switch (e) {
    case i:
      break;
  }
}

Common fixes

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

void f(int e, int i) {
  switch (e) {
    case 0:
      break;
  }
}

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

void f(int e, int i) {
  if (e == i) {}
}

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:

class C {
  final String s;

  const C(this.s);
}

const dynamic i = 0;

void f() {
  const C(i);
}

Common fixes

Pass a value of the correct type to the constructor:

class C {
  final String s;

  const C(this.s);
}

const dynamic i = 0;

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

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:

class C {
  final String s = 3.toString();
  const C();
}

Common fixes

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

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

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

class C {
  final String s = 3.toString();
  C();
}

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:

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

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

Common fixes

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

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

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

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

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

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

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

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

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

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:

class C {
  int x;

  const C(this.x);
}

Common fixes

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

class C {
  final int x;

  const C(this.x);
}

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

class C {
  int x;

  C(this.x);
}

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.

Example

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

import 'dart:convert' deferred as convert;

const json2 = convert.JsonCodec();

Common fixes

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

import 'dart:convert' deferred as convert;

final json2 = convert.JsonCodec();

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

import 'dart:convert' as convert;

const json2 = convert.JsonCodec();

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:

var x = 0;
const y = x;

Common fixes

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

const x = 0;
const y = x;

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

var x = 0;
final y = x;

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.

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:

import 'dart:math' deferred as math;

const pi = math.pi;

Common fixes

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

import 'dart:math' as math;

const pi = math.pi;

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

const pi = 3.14;

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:

class C {
  const int f = 3;
}

Common fixes

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

class C {
  final int f = 3;
}

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

class C {
  static const int f = 3;
}

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

class C {
  const C();

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

const map = {C() : 0};

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:

class C {
  const C();

  int get hashCode => 3;
}

const map = {C() : 0};

Common fixes

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

class C {
  const C();
}

const map = {C() : 0};

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

class C {
  const C();

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

final map = {C() : 0};

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:

const c;

Common fixes

Add an initializer:

const c = 'c';

const_set_element_not_primitive_equality

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

class C {
  const C();

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

const set = {C()};

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:

class C {
  const C();

  int get hashCode => 3;
}

const map = {C()};

Common fixes

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

class C {
  const C();
}

const set = {C()};

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

class C {
  const C();

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

final set = {C()};

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:

const List<int> list1 = null;
const List<int> list2 = [...list1];

Common fixes

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

const List<int> list1 = [];
const List<int> list2 = [...list1];

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:

const Map<String, int> map1 = null;
const Map<String, int> map2 = {...map1};

Common fixes

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

const Map<String, int> map1 = {};
const Map<String, int> map2 = {...map1};

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:

class A {
  A();
}

A f() => const A();

Common fixes

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

class A {
  const A();
}

A f() => const A();

Otherwise, remove the keyword const:

class A {
  A();
}

A f() => A();

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:

class C {
  final int i;
  const C(this.i);
}
C f(int i) => const C(i);

Common fixes

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

class C {
  final int i;
  const C(this.i);
}
C f(int i) => C(i);

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:

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

C<T> newC<T>() => const C<T>();

Common fixes

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

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

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

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

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

C<T> newC<T>() => C<T>();

continue_label_invalid

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

void f(int i) {
  l: switch (i) {
    case 0:
      continue l;
  }
}

Common fixes

Find a different way to achieve the control flow you need; for example, by introducing a loop that re-executes the switch statement.

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.

Example

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

import 'dart:ffi';

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

void f() {
  C();
}

Common fixes

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

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);
}

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:

int f() => 0;

void g() {
  new f();
}

Common fixes

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

int f() => 0;

void g() {
  new Object();
}

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

int f() => 0;

void g() {
  f();
}

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:

void f() {
  return;
  print('here');
}

Common fixes

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

void f() {
  return;
}

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

void f() {
  print('here');
  return;
}

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

void f({bool skipPrinting = true}) {
  if (skipPrinting) {
    return;
  }
  print('here');
}

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:

void f() {
  try {
  } catch (e) {
  } on String {
  }
}

Common fixes

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

void f() {
  try {
  } on String {
  } catch (e) {
  }
}

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

void f() {
  try {
  } catch (e) {
  }
}

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:

void f() {
  try {
  } on num {
  } on int {
  }
}

Common fixes

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

void f() {
  try {
  } on int {
  } on num {
  }
}

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

void f() {
  try {
  } on num {
  }
}

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:

int f(int x) {
  return x ?? 0;
}

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

class C {
  int f = -1;

  void m(int x) {
    f ??= x;
  }
}

Common fixes

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

int f(int x) {
  return x;
}

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

class C {
  int f = -1;

  void m(int x) {
  }
}

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

class C {
  int f = -1;

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

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:

var l = List<int>();

Common fixes

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

var l = <int>[];

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

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

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

var l = List.generate(3, (i) => i);

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:

void f(void Function([int p = 0]) g) {
}

Common fixes

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

void f(void Function([int p]) g) {
}

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:

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

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

Common fixes

Remove the default value from the factory constructor:

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

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

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

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

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

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:

void log({required String message = 'no message'}) {}

Common fixes

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

void log({required String message}) {}

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

void log({String message = 'no message'}) {}

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.

Example

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

class C {}

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

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

import 'a.dart' deferred as a;

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

Common fixes

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

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

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

Adding a hide clause would look like this:

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

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

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

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

import 'a.dart' as a;

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

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:

void f(bool b) {
  late int x;
  print(x);
}

Common fixes

Assign a value to the variable before reading from it:

void f(bool b) {
  late int x;
  x = b ? 1 : 0;
  print(x);
}

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:

name: example
dependencies:
  - meta

Common fixes

Use a map as the value of the dependencies key:

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:

void f({int i : 0}) {}

Common fixes

Replace the colon with an equal sign.

void f({int i = 0}) {}

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:

class A {}

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

import 'a.dart';

@deprecated
export 'a.dart';

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

import 'b.dart';

A? a;

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

import 'a.dart';

A? a;

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:

name: example
author: 'Dash'

Common fixes

Remove the deprecated key:

name: example

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:

void f(C c) {
  c.m();
}

Common fixes

The documentation for declarations that are annotated with @deprecated should indicate what code to use in place of the deprecated code.

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

@deprecated
var x = 0;
var y = x;

Common fixes

The fix depends on what’s been deprecated and what the replacement is. The documentation for deprecated declarations should indicate what code to use in place of the deprecated code.

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

/// See [new C].
class C {
  C();
}

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

/// See [new C.c].
class C {
  C.c();
}

Common fixes

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

/// See [C.c].
class C {
  C.c();
}

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

/// See [C.new].
class C {
  C.c();
}

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:

class F extends Function {}

Common fixes

Remove the class Function from whichever clause it’s in, and remove the whole clause if Function is the only type in the clause:

class F {}

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:

int i = 1;

void f() {
  print(i<int>);
}

Common fixes

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

int i = 1;

void f() {
  print(i);
}

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:

int divide(num x, num y) => (x / y).toInt();

Common fixes

Use the integer division operator (~/):

int divide(num x, num y) => x ~/ y;

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:

class C {
  C();

  C();
}

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

class C {
  C.m();

  C.m();
}

Common fixes

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

class C {
  C();

  C.n();
}

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

class C {
  C();
}

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

class C {
  C.m();

  C.n();
}

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

class C {
  C.m();
}

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:

int x = 0;
int x = 1;

Common fixes

Choose a different name for one of the declarations.

int x = 0;
int y = 1;

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:

export 'package:meta/meta.dart';
export 'package:meta/meta.dart';

Common fixes

Remove the unnecessary export:

export 'package:meta/meta.dart';

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:

class C {
  int f;

  C(this.f, this.f) {}
}

Common fixes

Remove one of the initializing formal parameters:

class C {
  int f;

  C(this.f) {}
}

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:

var r = (a: 1, a: 2);

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:

void f((int a, {int a}) r) {}

Common fixes

Rename one or both of the fields:

var r = (a: 1, b: 2);

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:

import 'dart:math' hide min, min;

var x = pi;

Common fixes

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

import 'dart:math' hide max, min;

var x = pi;

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

import 'dart:math' hide min;

var x = pi;

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:

// ignore_for_file: unused_local_variable
void f() {
  // ignore: unused_local_variable
  var x = 0;
}

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

void f() {
  // ignore: unused_local_variable, unused_local_variable
  var x = 0;
}

Common fixes

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

// ignore_for_file: unused_local_variable
void f() {
  var x = 0;
}

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:

import 'package:meta/meta.dart';
import 'package:meta/meta.dart';

@sealed class C {}

Common fixes

Remove the unnecessary import:

import 'package:meta/meta.dart';

@sealed class C {}

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:

void f(C c) {
  c.m(a: 0, a: 1);
}

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

Common fixes

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

void f(C c) {
  c.m(a: 0, b: 1);
}

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

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

void f(C c) {
  c.m(a: 1);
}

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

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

part of lib;

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

library lib;

part 'part.dart';
part 'part.dart';

Common fixes

Remove all except the first of the duplicated part directives:

library lib;

part 'part.dart';

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

int f((int, int) r) {
  int a;
  (a, a) = r;
  return a;
}

Common fixes

If you need to capture all of the values, then use a unique variable for each of the subpatterns being matched:

int f((int, int) r) {
  int a, b;
  (a, b) = r;
  return a + b;
}

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:

int f((int, int) r) {
  int a;
  (_, a) = r;
  return a;
}

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:

void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, a: 2):
      return;
  }
}

The following code produces this diagnostic because the getter f is matched twice in the same object pattern:

void f(Object o) {
  switch (o) {
    case C(f: 1, f: 2):
      return;
  }
}
class C {
  int? f;
}

Common fixes

If the pattern should match for more than one value of the duplicated field, then use a logical-or pattern:

void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, b: _) || (a: 2, b: _):
      break;
  }
}

If the pattern should match against multiple fields, then change the name of one of the fields:

void f(({int a, int b}) r) {
  switch (r) {
    case (a: 1, b: 2):
      return;
  }
}

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:

void f(List<int> x) {
  if (x case [0, ..., ...]) {}
}

Common fixes

Remove all but one of the rest patterns:

void f(List<int> x) {
  if (x case [0, ...]) {}
}

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:

import 'dart:math' show min, min;

var x = min(2, min(0, 1));

Common fixes

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

import 'dart:math' show max, min;

var x = max(2, min(0, 1));

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

import 'dart:math' show min;

var x = min(2, min(0, 1));

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:

void f((int, int) r) {
  if (r case (var a, 0) && (0, var a)) {
    print(a);
  }
}

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:

void f((int, int) r) {
  if (r case (var a, 0) && (0, var b)) {
    print(a + b);
  }
}

If you only need to capture the matched value on one branch, then remove the variable pattern from all but one branch:

void f((int, int) r) {
  if (r case (var a, 0) && (0, _)) {
    print(a);
  }
}

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:

void f(Map<int, String> x) {
  if (x case {}) {}
}

Common fixes

If the pattern should match any map, then replace it with an object pattern:

void f(Map<int, String> x) {
  if (x case Map()) {}
}

If the pattern should only match an empty map, then check the length in the pattern:

void f(Map<int, String> x) {
  if (x case Map(isEmpty: true)) {}
}

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:

var r = (,);

Common fixes

If the record is intended to be empty, then remove the comma:

var r = ();

If the record is intended to have one or more fields, then add the expressions used to compute the values of those fields:

var r = (3, 4);

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:

void f((int, int, {}) r) {}

Common fixes

If the record is intended to have named fields, then add the types and names of the fields:

void f((int, int, {int z}) r) {}

If the record isn’t intended to have named fields, then remove the curly braces:

void f((int, int) r) {}

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:

void f((,) r) {}

Common fixes

If the record type is intended to be empty, then remove the comma:

void f(() r) {}

If the record type is intended to have one or more fields, then add the types of those fields:

void f((int, int) r) {}

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.

Example

The following code produces this diagnostic because the class C, which extends Struct, doesn’t declare any fields:

import 'dart:ffi';

final class C extends Struct {}

Common fixes

If the class is intended to be a struct, then declare one or more fields:

import 'dart:ffi';

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

If the class is intended to be used as a type argument to Pointer, then make it a subclass of Opaque:

import 'dart:ffi';

final class C extends Opaque {}

If the class isn’t intended to be a struct, then remove or change the extends clause:

class C {}

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:

enum E {
  E
}

Common fixes

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

enum E {
  e
}

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

enum F {
  E
}

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:

enum E {
  e();

  factory E() => e;
}

Common fixes

Use a generative constructor marked as const:

enum E {
  e._();

  factory E() => e;

  const E._();
}

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:

mixin M {
  int x = 0;
}

enum E with M {
  a
}

Common fixes

If you need to apply the mixin, then change all instance fields into getter and setter pairs and implement them in the enum if necessary:

mixin M {
  int get x => 0;
}

enum E with M {
  a
}

If you don’t need to apply the mixin, then remove it:

enum E {
  a
}

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:

enum E {
  e;

  void m();
}

Common fixes

Provide an implementation for the member:

enum E {
  e;

  void m() {}
}

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:

enum values {
  c
}

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:

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

Common fixes

Remove one of the duplicate values:

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

Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.

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

const a = 1;
const b = 1;
var s = <int>{a, b};

Common fixes

If both elements should be included in the set, then change one of the elements:

const a = 1;
const b = 2;
var s = <int>{a, b};

If only one of the elements is needed, then remove the one that isn’t needed:

const a = 1;
var s = <int>{a};

Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.

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

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

Common fixes

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

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

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

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

Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which keys and values are returned by an iterator.

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:

const a = 1;
const b = 1;
var m = <int, String>{a: 'a', b: 'b'};

Common fixes

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

const a = 1;
const b = 2;
var m = <int, String>{a: 'a', b: 'b'};

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

const a = 1;
var m = <int, String>{a: 'a'};

Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which the keys and values are returned by an iterator.

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:

void f(Map<String, int> x) {
  if (x case {'a': 1, 'a': 2}) {}
}

Common fixes

If you are trying to match two different keys, then change one of the keys in the pattern:

void f(Map<String, int> x) {
  if (x case {'a': 1, 'b': 2}) {}
}

If you are trying to match the same key, but allow any one of multiple patterns to match, the use a logical-or pattern:

void f(Map<String, int> x) {
  if (x case {'a': 1 || 2}) {}
}

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:

void f(Object x) {
  if (x case <int, int>[0]) {}
}

Common fixes

Remove all but one of the type arguments:

void f(Object x) {
  if (x case <int>[0]) {}
}

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:

var l = <int, int>[];

Common fixes

Remove all except one of the type arguments:

var l = <int>[];

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:

var s = <int, String, int>{0, 'a', 1};

Common fixes

Remove all except one of the type arguments:

var s = <int>{0, 1};

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:

void f(Object x) {
  if (x case <int>{0: _}) {}
}

Common fixes

Add or remove type arguments until there are two, or none:

void f(Object x) {
  if (x case <int, int>{0: _}) {}
}

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:

var m = <int, String, int>{};

Common fixes

Remove all except two of the type arguments:

var m = <int, String>{};

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:

export 'dart:_interceptors';

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:

// @dart = 2.8
String s;

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

export 'optedOut.dart';

class C {}

Common fixes

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

String? s;

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

class C {}

If the exported library (the one that is opted out) itself exports an opted-in library, then it’s valid for your library to indirectly export the symbols from the opted-in library. You can do so by adding a hide combinator to the export directive in your library that hides all of the names declared in the opted-out library.

export_of_non_library

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

part of lib;

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

library lib;

export 'part.dart';

Common fixes

Either remove the export directive, or change the URI to be the URI of the library containing the part.

expression_in_map

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:

var map = <String, int>{'a': 0, 'b': 1, 'c'};

Common fixes

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

var map = <String, int>{'a': 0, 'b': 1, 'c': 2};

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:

void f() {}

class C extends f {}

Common fixes

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

void f() {}

class C extends B {}

class B {}

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

void f() {}

class C {}

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:

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

var x = E;

Common fixes

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

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

var x = E.m();

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:

extension E on Object {
  int get a => 0;
  static int a() => 0;
}

Common fixes

Rename or remove one of the members:

extension E on Object {
  int get a => 0;
  static int b() => 0;
}

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:

extension E on String {
  int a();
}

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:

extension E on String {
  E() : super();
}

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:

extension E on String {
  String s;
}

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:

extension E on String {
  String toString() => this;
}

Common fixes

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

extension E on String {
  String displayString() => this;
}

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:

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

void f() {
  E('').m();
}

Common fixes

Replace the extension override with the name of the extension:

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

void f() {
  E.m();
}

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:

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

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

Common fixes

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

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

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

If there’s a different extension that’s valid for the type of the argument, then either replace the name of the extension or unwrap the argument so that the correct extension is found.

extension_override_without_access

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:

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

void f(int i) {
  print(E(i));
}

Common fixes

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

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

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

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

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

void f(int i) {
  print(i);
}

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:

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

Common fixes

Use . rather than ..:

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

If there are multiple cascaded accesses, you’ll need to duplicate the extension override for each one.

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

class C {
  external int x;
  C() : x = 0;
}

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

class C {
  external final int x = 0;
}

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

external final int x = 0;

Common fixes

Remove the initializer:

class C {
  external final int x;
}

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.

Example

The following code produces this diagnostic because the field x has two annotations describing the native type of the field:

import 'dart:ffi';

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

Common fixes

Remove all but one of the annotations:

import 'dart:ffi';
final class C extends Struct {
  @Int32()
  external int x;
}

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:

void f(int a, int b) {}
void g() {
  f(1, 2, 3);
}

Common fixes

Remove the arguments that don’t correspond to parameters:

void f(int a, int b) {}
void g() {
  f(1, 2);
}

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:

void f(int a, int b, {int c}) {}
void g() {
  f(1, 2, 3);
}

Common fixes

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

void f(int a, int b, {int c}) {}
void g() {
  f(1, 2, c: 3);
}

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

void f(int a, int b, {int c}) {}
void g() {
  f(1, 2);
}

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.

Example

The following code produces this diagnostic because the field a0 has two annotations that specify the size of the native array:

import 'dart:ffi';

final class C extends Struct {
  @Array(4)
  @Array(8)
  external Array<Uint8> a0;
}

Common fixes

Remove all but one of the annotations:

import 'dart:ffi';

final class C extends Struct {
  @Array(8)
  external Array<Uint8> a0;
}

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:

class C {
  int f;

  C() : f = 0, f = 1;
}

Common fixes

Remove one of the initializers:

class C {
  int f;

  C() : f = 0;
}

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 :

class C {
  final int f = 0;
  C() : f = 1;
}

Common fixes

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

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

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

class C {
  final int f;
  C() : f = 1;
}

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:

class C {
  int f;

  C(this.f) : f = 0;
}

Common fixes

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

class C {
  int f;

  C(this.f);
}

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

class C {
  int f;

  C() : f = 0;
}

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

class C {
  int f;

  C(int g) : f = g * 2;
}

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:

class C {
  int? f;

  factory C(this.f) => throw 0;
}

Common fixes

Replace the initializing formal parameter with a normal parameter:

class C {
  int? f;

  factory C(int f) => throw 0;
}

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.

Example

The following code produces this diagnostic because the class C has a constructor with an initializer for the field f:

// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  int f;

  C() : f = 0;
}

Common fixes

Remove the field initializer:

// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  @Int32()
  int f;

  C();
}

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:

class C {
  String s;

  C() : s = 0;
}

Common fixes

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

class C {
  String s;

  C() : s = '0';
}

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

class C {
  int s;

  C() : s = 0;
}

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:

class A {
  int x = 0;

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

Common fixes

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

class A {
  int x = 0;

  m([int x = 0]) {
    this.x = x;
  }
}

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:

class C {
  int f;

  C(this.f);

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

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

class C {
  int f;

  C(this.f);

  C.zero() : f = 0, this(1);
}

Common fixes

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

class C {
  int f;

  C(this.f);

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

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

class C {
  int f;

  C(this.f);

  C.zero() : this(0);
}

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.

class C {
  int f;

  C(String this.f);
}

Common fixes

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

class C {
  String f;

  C(this.f);
}

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

class C {
  int f;

  C(this.f);
}

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

class C {
  int f;

  C(String s) : f = int.parse(s);
}

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.

Example

The following code produces this diagnostic because the field p has an initializer:

// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  Pointer p = nullptr;
}

Common fixes

Remove the initializer:

// @dart = 2.9
import 'dart:ffi';

final class C extends Struct {
  Pointer p;
}

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.

Example

The following code produces this diagnostic because the field a isn’t marked as being external:

import 'dart:ffi';

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

Common fixes

Add the required external modifier:

import 'dart:ffi';

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

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:

class C {
  final int f = 0;

  C(this.f);
}

Common fixes

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

class C {
  final int f = 0;

  C();
}

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

class C {
  final int f;

  C(this.f);
}

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:

final x;

Common fixes

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

final x = 0;

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

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

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

class C {
  final int x;
  C(int y) : x = y * 2;
}

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:

class C {
  final String value;

  C();
}

Common fixes

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

class C {
  final String value;

  C(this.value);
}

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

class C {
  final String value;

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

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

class C {
  final String value = '';

  C();
}

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

class C {
  final String value;

  C() : value = '';

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

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

class C {
  static const String value = '';

  C();
}