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.

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

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

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

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

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

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

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

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

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

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

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

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

Add an AbiSpecificIntegerMapping annotation to the class:

import 'dart:ffi';

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

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

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

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

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 fields can't have initializers.

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

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

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

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

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.

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

abstract sealed class C {}

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 {}

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

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.

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

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

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

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

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';

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;

A member named '{0}' is defined in '{1}' and '{2}', and neither is more specific.

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

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.

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

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

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

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

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

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

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.

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.

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.

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

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

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.

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.

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

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

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.

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

Remove the annotations from the field:

import 'dart:ffi';

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

Argument '{0}' must be a constant.

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 an invocation of either Pointer.fromFunction or NativeCallable.isolateLocal has an exceptionalReturn argument whose value isn't a constant expression.

For more information about FFI, see C interop using dart:ffi.

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

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 to 'Native.addressOf' must be annotated with @Native

The analyzer produces this diagnostic when the argument passed to Native.addressOf isn't annotated with the Native annotation.

The following code produces this diagnostic because the argument to addressOf is a string, not a field, and strings can't be annotated:

import 'dart:ffi';

@Native<Void Function()>()
external void f();

void g() {
  print(Native.addressOf('f'));
}

The following code produces this diagnostic because the function f is being passed to addressOf but isn't annotated as being Native:

import 'dart:ffi';

external void f();

void g() {
  print(Native.addressOf<NativeFunction<Void Function()>>(f));
}

If the argument isn't either a field or a function, then replace the argument with a field or function that's annotated with Native:

import 'dart:ffi';

@Native<Void Function()>()
external void f();

void g() {
  print(Native.addressOf<NativeFunction<Void Function()>>(f));
}

If the argument is either a field or a function, then annotate the field of function with Native:

import 'dart:ffi';

@Native<Void Function()>()
external void f();

void g() {
  print(Native.addressOf<NativeFunction<Void Function()>>(f));
}

The argument type '{0}' can't be assigned to the parameter type '{1}'. {2}

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

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

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(Object 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);

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

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.

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

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

A redirecting constructor can't have an 'assert' initializer.

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.

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() {}
}

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() {}
}

The asset directory '{0}' doesn't exist.

The analyzer produces this diagnostic when an asset list contains a value referencing a directory that doesn't exist.

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/

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.

The asset file '{0}' doesn't exist.

The analyzer produces this diagnostic when an asset list contains a value referencing a file that doesn't exist.

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

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.

The value of the 'assets' field is expected to be a list of relative file paths.

The analyzer produces this diagnostic when the value of the assets key isn't a list.

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/

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

name: example
flutter:
  assets:
    - assets/

Asset map entry must contain a 'path' field.

The analyzer produces this diagnostic when an asset map is missing a path value.

The following code produces this diagnostic because the asset map is missing a path value:

name: example
flutter:
  assets:
    - flavors:
      - premium

Change the asset map so that it contains a path field with a string value (a valid POSIX-style file path):

name: example
flutter:
  assets:
    - path: assets/image.gif
      flavors:
      - premium

Assets are required to be file paths (strings).

The analyzer produces this diagnostic when an assets list contains a value that isn't a string.

The following code produces this diagnostic because the assets list contains a map:

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

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

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

An asset value is required to be a file path (string) or map.

The analyzer produces this diagnostic when an asset value isn't a string or a map.

The following code produces this diagnostic because the asset value is a list:

name: example
flutter:
  assets:
    - [one, two, three]

If you need to specify more than just the path to the asset, then replace the value with a map with a path key (a valid POSIX-style file path):

name: example
flutter:
  assets:
    - path: assets/image.gif
      flavors:
      - premium

If you only need to specify the path, then replace the value with the path to the asset (a valid POSIX-style file path):

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

Asset paths are required to be file paths (strings).

The analyzer produces this diagnostic when an asset map contains a path value that isn't a string.

The following code produces this diagnostic because the asset map contains a path value which is a list:

name: example
flutter:
  assets:
    - path: [one, two, three]
      flavors:
      - premium

Change the asset map so that it contains a path value which is a string (a valid POSIX-style file path):

name: example
flutter:
  assets:
    - path: image.gif
      flavors:
      - premium

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

The analyzer produces this diagnostic when the value of a function (including methods and getters) that is explicitly or implicitly marked by the doNotStore annotation is stored in either a field or top-level variable.

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

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

Constant variables can't be assigned a value.

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.

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

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

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

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.

The following code produces this diagnostic because v is final:

class C {
  final v = 0;
}

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

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

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

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

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

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

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

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

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.

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

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

Functions can't be assigned a value.

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

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

void f() {}

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

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 = () {};
}