{%- comment %} WARNING: Do NOT EDIT this file directly. It is autogenerated by the script in pkg/analyzer/tool/diagnostics/generate.dart in the sdk repository. Update instructions: https://github.com/dart-lang/site-www/issues/1949 {% endcomment -%}
This page lists diagnostic messages produced by the Dart analyzer, with details about what those messages mean and how you can fix your code. For more information about the analyzer, see Customizing static analysis.
This page uses the following terms.
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; } }
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>.
The analyzer produces the following diagnostics for code that doesn't conform to the language specification or that might work in unexpected ways.
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:
{% prettify dart tag=pre+code %} abstract class A { int get a; } class B extends A { int get a => super.[!a!]; } {% endprettify %}
Remove the invocation of the abstract member, possibly replacing it with an invocation of a concrete member.
A member named ‘{0}’ is defined in extensions ‘{1}’ and ‘{2}’ and neither is 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:
{% prettify dart tag=pre+code %} extension E1 on String { int get charCount => 1; }
extension E2 on String { int get charCount => 2; }
void f(String s) { print(s.[!charCount!]); } {% endprettify %}
If you don't need both extensions, then you can delete or hide one of them.
If you need both, then explicitly select the one you want to use by using an extension override:
{% prettify dart tag=pre+code %} extension E1 on String { int get charCount => length; }
extension E2 on String { int get charCount => length; }
void f(String s) { print(E2(s).charCount); } {% endprettify %}
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):
{% prettify dart tag=pre+code %} class A {} class C {} {% endprettify %}
And a library (b.dart) that defines a different class with the same name:
{% prettify dart tag=pre+code %} class B {} class C {} {% endprettify %}
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} import ‘a.dart’; import ‘b.dart’;
void f([!C!] c1, [!C!] c2) {} {% endprettify %}
If any of the libraries aren't needed, then remove the import directives for them:
{% prettify dart tag=pre+code %} import ‘a.dart’;
void f(C c1, C c2) {} {% endprettify %}
If the name is still defined by more than one library, then add a hide clause to the import directives for all except one library:
{% prettify dart tag=pre+code %} import ‘a.dart’ hide C; import ‘b.dart’;
void f(C c1, C c2) {} {% endprettify %}
If you must be able to reference more than one of these types, then add a prefix to each of the import directives, and qualify the references with the appropriate prefix:
{% prettify dart tag=pre+code %} import ‘a.dart’ as a; import ‘b.dart’ as b;
void f(a.C c1, b.C c2) {} {% endprettify %}
This literal contains both ‘Map’ and ‘Iterable’ spreads, which makes it impossible to determine whether the literal is a map or a set.
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.
The analyzer produces this diagnostic when some of the expressions being spread have the type Iterable and others have the type Map, 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:
{% prettify dart tag=pre+code %} union(Map<String, String> a, List b, Map<String, String> c) => [!{...a, ...b, ...c}!]; {% endprettify %}
The list b can only be spread into a set, and the maps a and c can only be spread into a map, and the literal can't be both.
There are two common ways to fix this problem. The first is to remove all of the spread elements of one kind or another, so that the elements are consistent. In this case, that likely means removing the list and deciding what to do about the now unused parameter:
{% prettify dart tag=pre+code %} union(Map<String, String> a, List b, Map<String, String> c) => {...a, ...c}; {% endprettify %}
The second fix is to change the elements of one kind into elements that are consistent with the other elements. For example, you can add the elements of the list as keys that map to themselves:
{% prettify dart tag=pre+code %} union(Map<String, String> a, List b, Map<String, String> c) => {...a, for (String s in b) s: s, ...c}; {% endprettify %}
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:
{% prettify dart tag=pre+code %} union(a, b) => [!{...a, ...b}!]; {% endprettify %}
The problem occurs because there are no type arguments, and there is no information about the type of either a or b.
There are three common ways to fix this problem. The first is to add type arguments to the literal. For example, if the literal is intended to be a map literal, you might write something like this:
{% prettify dart tag=pre+code %} union(a, b) => <String, String>{...a, ...b}; {% endprettify %}
The second fix is to add type information so that the expressions have either the type Iterable or the type Map. You can add an explicit cast or, in this case, add types to the declarations of the two parameters:
{% prettify dart tag=pre+code %} union(List a, List b) => {...a, ...b}; {% endprettify %}
The third fix is to add context information. In this case, that means adding a return type to the function:
{% prettify dart tag=pre+code %} Set union(a, b) => {...a, ...b}; {% endprettify %}
In other cases, you might add a type somewhere else. For example, say the original code looks like this:
{% prettify dart tag=pre+code %} union(a, b) { var x = [!{...a, ...b}!]; return x; } {% endprettify %}
You might add a type annotation on x, like this:
{% prettify dart tag=pre+code %} union(a, b) { Map<String, String> x = {...a, ...b}; return x; } {% endprettify %}
The argument type ‘{0}’ can't be assigned to the parameter type ‘{1}’.
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:
{% prettify dart tag=pre+code %} String f(String x) => x; String g(num y) => f([!y!]); {% endprettify %}
If possible, rewrite the code so that the static type is assignable. In the example above you might be able to change the type of the parameter y:
{% prettify dart tag=pre+code %} String f(String x) => x; String g(String y) => f(y); {% endprettify %}
If that fix isn‘t possible, then add code to handle the case where the argument value isn’t the required type. One approach is to coerce other types to the required type:
{% prettify dart tag=pre+code %} String f(String x) => x; String g(num y) => f(y.toString()); {% endprettify %}
Another approach is to add explicit type tests and fallback code:
{% prettify dart tag=pre+code %} String f(String x) => x; String g(num y) => f(y is String ? y : ''); {% endprettify %}
If you believe that the runtime type of the argument will always be the same as the static type of the parameter, and you‘re willing to risk having an exception thrown at runtime if you’re wrong, then add an explicit cast:
{% prettify dart tag=pre+code %} String f(String x) => x; String g(num y) => f(y as String); {% endprettify %}
‘{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:
{% prettify dart tag=pre+code %} class C { final v = 0; }
f(C c) { c.[!v!] = 1; } {% endprettify %}
If you need to be able to set the value of the field, then remove the modifier final from the field:
{% prettify dart tag=pre+code %} class C { int v = 0; }
f(C c) { c.v = 1; } {% endprettify %}
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:
{% prettify dart tag=pre+code %} void f() { final x = 0; [!x!] = 3; print(x); } {% endprettify %}
Remove the keyword final, and replace it with var if there's no type annotation:
{% prettify dart tag=pre+code %} void f() { var x = 0; x = 3; print(x); } {% endprettify %}
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:
{% prettify dart tag=pre+code %} class C { int get x => 0; set y(int p) {} }
void f(C c) { c.[!x!] = 1; } {% endprettify %}
If you want to invoke an existing setter, then correct the name:
{% prettify dart tag=pre+code %} class C { int get x => 0; set y(int p) {} }
void f(C c) { c.y = 1; } {% endprettify %}
If you want to invoke the setter but it just doesn't exist yet, then declare it:
{% prettify dart tag=pre+code %} class C { int get x => 0; set x(int p) {} set y(int p) {} }
void f(C c) { c.x = 1; } {% endprettify %}
Methods can't be assigned a value.
The analyzer produces this diagnostic when the target of an assignment is a method.
The following code produces this diagnostic because f can‘t be assigned a value because it’s a method:
{% prettify dart tag=pre+code %} class C { void f() {}
void g() { [!f!] = null; } } {% endprettify %}
Rewrite the code so that there isn't an assignment to a method.
The body might complete normally, causing ‘null’ to be returned, but the return type is a potentially non-nullable type.
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.
The following code produces this diagnostic because the method m has an implicit return of null inserted at the end of the method, but the method is declared to not return null:
{% prettify dart tag=pre+code %} class C { int [!m!](int t) { print(t); } } {% endprettify %}
The following code produces this diagnostic because the method m has an implicit return of null inserted at the end of the method, but because the class C can be instantiated with a non-nullable type argument, the method is effectively declared to not return null:
{% prettify dart tag=pre+code %} class C { T [!m!](T t) { print(t); } } {% endprettify %}
If there's a reasonable value that can be returned, then add a return statement at the end of the method:
{% prettify dart tag=pre+code %} class C { T m(T t) { print(t); return t; } } {% endprettify %}
If the method won't reach the implicit return, then add a throw at the end of the method:
{% prettify dart tag=pre+code %} class C { T m(T t) { print(t); throw ''; } } {% endprettify %}
If the method intentionally returns null at the end, then change the return type so that it's valid to return null:
{% prettify dart tag=pre+code %} class C { T? m(T t) { print(t); } } {% endprettify %}
The built-in identifier ‘{0}’ can't be used as an extension name.
The analyzer produces this diagnostic when the name of an extension is a built-in identifier. Built-in identifiers can’t be used as extension names.
The following code produces this diagnostic because mixin is a built-in identifier:
{% prettify dart tag=pre+code %} extension [!mixin!] on int {} {% endprettify %}
Choose a different name for the extension.
The built-in identifier ‘{0}’ can't be used as a type.
The analyzer produces this diagnostic when a built-in identifier is used where a type name is expected.
The following code produces this diagnostic because import can‘t be used as a type because it’s a built-in identifier:
{% prettify dart tag=pre+code %} [!import!] x; {% endprettify %}
Replace the built-in identifier with the name of a valid type:
{% prettify dart tag=pre+code %} List x; {% endprettify %}
The last statement of the ‘case’ should be ‘break’, ‘continue’, ‘rethrow’, ‘return’, or ‘throw’.
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.
The following code produces this diagnostic because the case block ends with an assignment:
{% prettify dart tag=pre+code %} void f(int x) { switch (x) { [!case!] 0: x += 2; default: x += 1; } } {% endprettify %}
Add one of the required terminators:
{% prettify dart tag=pre+code %} void f(int x) { switch (x) { case 0: x += 2; break; default: x += 1; } } {% endprettify %}
The switch case expression type ‘{0}’ must be a subtype of the switch expression type ‘{1}’.
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.
The following code produces this diagnostic because 1 is an int, which isn't a subtype of String (the type of s):
{% prettify dart tag=pre+code %} void f(String s) { switch (s) { case [!1!]: break; } } {% endprettify %}
If the value of the case expression is wrong, then change the case expression so that it has the required type:
{% prettify dart tag=pre+code %} void f(String s) { switch (s) { case ‘1’: break; } } {% endprettify %}
If the value of the case expression is correct, then change the switch expression to have the required type:
{% prettify dart tag=pre+code %} void f(int s) { switch (s) { case 1: break; } } {% endprettify %}
The name ‘{0}’ isn‘t a type, so it can’t be used in an ‘as’ expression.
The analyzer produces this diagnostic when the name following the as in a cast expression is defined to be something other than a type.
The following code produces this diagnostic because x is a variable, not a type:
{% prettify dart tag=pre+code %} num x = 0; int y = x as [!x!]; {% endprettify %}
Replace the name with the name of a type:
{% prettify dart tag=pre+code %} num x = 0; int y = x as int; {% endprettify %}
‘{0}’ must have a method body because ‘{1}’ isn't abstract.
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.
The following code produces this diagnostic because m is an abstract method but C isn't an abstract class:
{% prettify dart tag=pre+code %} class C { [!void m();!] } {% endprettify %}
If it's valid to create instances of the class, provide an implementation for the member:
{% prettify dart tag=pre+code %} class C { void m() {} } {% endprettify %}
If it isn't valid to create instances of the class, mark the class as being abstract:
{% prettify dart tag=pre+code %} abstract class C { void m(); } {% endprettify %}
A value of type ‘{0}’ can't be assigned to a parameter of type ‘{1}’ in a const constructor.
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.
The following code produces this diagnostic because the runtime type of i is int, which can't be assigned to the static type of s:
{% prettify dart tag=pre+code %} class C { final String s;
const C(this.s); }
const dynamic i = 0;
void f() { const C([!i!]); } {% endprettify %}
Pass a value of the correct type to the constructor:
{% prettify dart tag=pre+code %} class C { final String s;
const C(this.s); }
const dynamic i = 0;
void f() { const C(‘$i’); } {% endprettify %}
Can't define a const constructor for a class with non-final fields.
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).
The following code produces this diagnostic because the field x isn't final:
{% prettify dart tag=pre+code %} class C { int x;
const !C!; } {% endprettify %}
If it's possible to mark all of the fields as final, then do so:
{% prettify dart tag=pre+code %} class C { final int x;
const C(this.x); } {% endprettify %}
If it isn't possible to mark all of the fields as final, then remove the keyword const from the constructor:
{% prettify dart tag=pre+code %} class C { int x;
C(this.x); } {% endprettify %}
Const variables must be initialized with a constant value.
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.
The following code produces this diagnostic because x isn't declared to be const:
{% prettify dart tag=pre+code %} var x = 0; const y = [!x!]; {% endprettify %}
If the value being assigned can be declared to be const, then change the declaration:
{% prettify dart tag=pre+code %} const x = 0; const y = x; {% endprettify %}
If the value can't be declared to be const, then remove the const modifier from the variable, possibly using final in its place:
{% prettify dart tag=pre+code %} var x = 0; final y = x; {% endprettify %}
Only static fields can be declared as const.
The analyzer produces this diagnostic when an instance field is marked as being const.
The following code produces this diagnostic because f is an instance field:
{% prettify dart tag=pre+code %} class C { [!const!] int f = 3; } {% endprettify %}
If the field needs to be an instance field, then remove the keyword const, or replace it with final:
{% prettify dart tag=pre+code %} class C { final int f = 3; } {% endprettify %}
If the field really should be a const field, then make it a static field:
{% prettify dart tag=pre+code %} class C { static const int f = 3; } {% endprettify %}
The constant ‘{0}’ must be initialized.
The analyzer produces this diagnostic when a variable that is declared to be a constant doesn't have an initializer.
The following code produces this diagnostic because c isn't initialized:
{% prettify dart tag=pre+code %} const [!c!]; {% endprettify %}
Add an initializer:
{% prettify dart tag=pre+code %} const c = ‘c’; {% endprettify %}
A list or a set is expected in this spread.
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.
The following code produces this diagnostic because the value of list1 is null, which is neither a list nor a set:
{% prettify dart tag=pre+code %} const List list1 = null; const List list2 = [...[!list1!]]; {% endprettify %}
Change the expression to something that evaluates to either a constant list or a constant set:
{% prettify dart tag=pre+code %} const List list1 = []; const List list2 = [...list1]; {% endprettify %}
A map is expected in this spread.
The analyzer produces this diagnostic when the expression of a spread operator in a constant map evaluates to something other than a map.
The following code produces this diagnostic because the value of map1 is null, which isn't a map:
{% prettify dart tag=pre+code %} const Map<String, int> map1 = null; const Map<String, int> map2 = {...[!map1!]}; {% endprettify %}
Change the expression to something that evaluates to a constant map:
{% prettify dart tag=pre+code %} const Map<String, int> map1 = {}; const Map<String, int> map2 = {...map1}; {% endprettify %}
The constructor being called isn't a const constructor.
The analyzer produces this diagnostic when the keyword const is used to invoke a constructor that isn't marked with const.
The following code produces this diagnostic because the constructor in A isn't a const constructor:
{% prettify dart tag=pre+code %} class A { A(); }
A f() => [!const!] A(); {% endprettify %}
If it's desirable and possible to make the class a constant class (by making all of the fields of the class, including inherited fields, final), then add the keyword const to the constructor:
{% prettify dart tag=pre+code %} class A { const A(); }
A f() => const A(); {% endprettify %}
Otherwise, remove the keyword const:
{% prettify dart tag=pre+code %} class A { A(); }
A f() => A(); {% endprettify %}
Arguments of a constant creation must be constant expressions.
The analyzer produces this diagnostic when a const constructor is invoked with an argument that isn't a constant expression.
The following code produces this diagnostic because i isn't a constant:
{% prettify dart tag=pre+code %} class C { final int i; const C(this.i); } C f(int i) => const C([!i!]); {% endprettify %}
Either make all of the arguments constant expressions, or remove the const keyword to use the non-constant form of the constructor:
{% prettify dart tag=pre+code %} class C { final int i; const C(this.i); } C f(int i) => C(i); {% endprettify %}
Dead code.
The analyzer produces this diagnostic when code is found that won't be executed because execution will never reach the code.
The following code produces this diagnostic because the invocation of print occurs after the function has returned:
{% prettify dart tag=pre+code %} void f() { return; [!print(‘here’);!] } {% endprettify %}
If the code isn't needed, then remove it:
{% prettify dart tag=pre+code %} void f() { return; } {% endprettify %}
If the code needs to be executed, then either move the code to a place where it will be executed:
{% prettify dart tag=pre+code %} void f() { print(‘here’); return; } {% endprettify %}
Or, rewrite the code before it, so that it can be reached:
{% prettify dart tag=pre+code %} void f({bool skipPrinting = true}) { if (skipPrinting) { return; } print(‘here’); } {% endprettify %}
Dead code: Catch clauses after a ‘catch (e)’ or an ‘on Object catch (e)’ are never reached.
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.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} void f() { try { } catch (e) { } [!on String { }!] } {% endprettify %}
If the clause should be selectable, then move the clause before the general clause:
{% prettify dart tag=pre+code %} void f() { try { } on String { } catch (e) { } } {% endprettify %}
If the clause doesn't need to be selectable, then remove it:
{% prettify dart tag=pre+code %} void f() { try { } catch (e) { } } {% endprettify %}
Dead code: This on-catch block won’t be executed because ‘{0}’ is a subtype of ‘{1}’ and hence will have been caught already.
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.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} void f() { try { } on num { } [!on int { }!] } {% endprettify %}
If the clause should be selectable, then move the clause before the general clause:
{% prettify dart tag=pre+code %} void f() { try { } on int { } on num { } } {% endprettify %}
If the clause doesn't need to be selectable, then remove it:
{% prettify dart tag=pre+code %} void f() { try { } on num { } } {% endprettify %}
The left operand can't be null, so the right operand is never executed.
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.
The following code produces this diagnostic because x can't be null:
{% prettify dart tag=pre+code %} int f(int x) { return x ?? [!0!]; } {% endprettify %}
The following code produces this diagnostic because f can't be null:
{% prettify dart tag=pre+code %} class C { int f = -1;
void m(int x) { f ??= [!x!]; } } {% endprettify %}
If the diagnostic is reported for an ?? operator, then remove the ?? operator and the right operand:
{% prettify dart tag=pre+code %} int f(int x) { return x; } {% endprettify %}
If the diagnostic is reported for an assignment, and the assignment isn't needed, then remove the assignment:
{% prettify dart tag=pre+code %} class C { int f = -1;
void m(int x) { } } {% endprettify %}
If the assignment is needed, but should be based on a different condition, then rewrite the code to use = and the different condition:
{% prettify dart tag=pre+code %} class C { int f = -1;
void m(int x) { if (f < 0) { f = x; } } } {% endprettify %}
The default ‘List’ constructor isn't available when null safety is enabled.
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.
Assuming the following code is opted in to null safety, it produces this diagnostic because it uses the default List constructor:
{% prettify dart tag=pre+code %} var l = !List!; {% endprettify %}
If no initial size is provided, then convert the code to use a list literal:
{% prettify dart tag=pre+code %} var l = []; {% endprettify %}
If an initial size needs to be provided and there is a single reasonable initial value for the elements, then use List.filled:
{% prettify dart tag=pre+code %} var l = List.filled(3, 0); {% endprettify %}
If an initial size needs to be provided but each element needs to be computed, then use List.generate:
{% prettify dart tag=pre+code %} var l = List.generate(3, (i) => i); {% endprettify %}
The late local variable ‘{0}’ is definitely unassigned at this point.
The analyzer produces this diagnostic when definite assignment analysis shows that a local variable that's marked as late is read before being assigned.
The following code produces this diagnostic because x wasn't assigned a value before being read:
{% prettify dart tag=pre+code %} void f(bool b) { late int x; print([!x!]); } {% endprettify %}
Assign a value to the variable before reading from it:
{% prettify dart tag=pre+code %} void f(bool b) { late int x; x = b ? 1 : 0; print(x); } {% endprettify %}
‘{0}’ is deprecated and shouldn't be used.
‘{0}’ is deprecated and shouldn't be used. {1}.
The analyzer produces this diagnostic when a deprecated library or class member is used in a different package.
If the method m in the class C is annotated with @deprecated, then the following code produces this diagnostic:
{% prettify dart tag=pre+code %} void f(C c) { c.!m!; } {% endprettify %}
The documentation for declarations that are annotated with @deprecated should indicate what code to use in place of the deprecated code.
‘{0}’ is deprecated and shouldn't be used.
‘{0}’ is deprecated and shouldn't be used. {1}.
The analyzer produces this diagnostic when a deprecated library member or class member is used in the same package in which it's declared.
The following code produces this diagnostic because x is deprecated:
{% prettify dart tag=pre+code %} @deprecated var x = 0; var y = [!x!]; {% endprettify %}
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.
The constructor with name ‘{0}’ is already defined.
The default constructor is already defined.
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.
The following code produces this diagnostic because there are two declarations for the unnamed constructor:
{% prettify dart tag=pre+code %} class C { C();
!C!; } {% endprettify %}
The following code produces this diagnostic because there are two declarations for the constructor named m:
{% prettify dart tag=pre+code %} class C { C.m();
!C.m!; } {% endprettify %}
If there are multiple unnamed constructors and all of the constructors are needed, then give all of them, or all except one of them, a name:
{% prettify dart tag=pre+code %} class C { C();
C.n(); } {% endprettify %}
If there are multiple unnamed constructors and all except one of them are unneeded, then remove the constructors that aren't needed:
{% prettify dart tag=pre+code %} class C { C(); } {% endprettify %}
If there are multiple named constructors and all of the constructors are needed, then rename all except one of them:
{% prettify dart tag=pre+code %} class C { C.m();
C.n(); } {% endprettify %}
If there are multiple named constructors and all except one of them are unneeded, then remove the constructorsthat aren't needed:
{% prettify dart tag=pre+code %} class C { C.m(); } {% endprettify %}
The name ‘{0}’ is already defined.
The analyzer produces this diagnostic when a name is declared, and there is a previous declaration with the same name in the same scope.
The following code produces this diagnostic because the name x is declared twice:
{% prettify dart tag=pre+code %} int x = 0; int [!x!] = 1; {% endprettify %}
Choose a different name for one of the declarations.
{% prettify dart tag=pre+code %} int x = 0; int y = 1; {% endprettify %}
Duplicate import.
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.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’; import [!‘package:meta/meta.dart’!];
@sealed class C {} {% endprettify %}
Remove the unnecessary import:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
@sealed class C {} {% endprettify %}
The argument for the named parameter ‘{0}’ was already specified.
The analyzer produces this diagnostic when an invocation has two or more named arguments that have the same name.
The following code produces this diagnostic because there are two arguments with the name a:
{% prettify dart tag=pre+code %} void f(C c) { c.m(a: 0, [!a!]: 1); }
class C { void m({int a, int b}) {} } {% endprettify %}
If one of the arguments should have a different name, then change the name:
{% prettify dart tag=pre+code %} void f(C c) { c.m(a: 0, b: 1); }
class C { void m({int a, int b}) {} } {% endprettify %}
If one of the arguments is wrong, then remove it:
{% prettify dart tag=pre+code %} void f(C c) { c.m(a: 1); }
class C { void m({int a, int b}) {} } {% endprettify %}
Two elements in a constant set literal can't be equal.
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.
The following code produces this diagnostic because the string 'a' is specified twice:
{% prettify dart tag=pre+code %} const Set set = {‘a’, [!‘a’!]}; {% endprettify %}
Remove one of the duplicate values:
{% prettify dart tag=pre+code %} const Set set = {‘a’}; {% endprettify %}
Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.
Two elements in a set literal shouldn't be equal.
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.
The following code produces this diagnostic because the element 1 appears twice:
{% prettify dart tag=pre+code %} const a = 1; const b = 1; var s = {a, [!b!]}; {% endprettify %}
If both elements should be included in the set, then change one of the elements:
{% prettify dart tag=pre+code %} const a = 1; const b = 2; var s = {a, b}; {% endprettify %}
If only one of the elements is needed, then remove the one that isn't needed:
{% prettify dart tag=pre+code %} const a = 1; var s = {a}; {% endprettify %}
Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.
Two keys in a constant map literal can't be equal.
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.
The following code produces this diagnostic because the key 1 is used twice:
{% prettify dart tag=pre+code %} const map = <int, String>{1: ‘a’, 2: ‘b’, [!1!]: ‘c’, 4: ‘d’}; {% endprettify %}
If both entries should be included in the map, then change one of the keys to be different:
{% prettify dart tag=pre+code %} const map = <int, String>{1: ‘a’, 2: ‘b’, 3: ‘c’, 4: ‘d’}; {% endprettify %}
If only one of the entries is needed, then remove the one that isn't needed:
{% prettify dart tag=pre+code %} const map = <int, String>{1: ‘a’, 2: ‘b’, 4: ‘d’}; {% endprettify %}
Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which keys and values are returned by an iterator.
Two keys in a map literal shouldn't be equal.
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.
The following code produces this diagnostic because the keys a and b have the same value:
{% prettify dart tag=pre+code %} const a = 1; const b = 1; var m = <int, String>{a: ‘a’, [!b!]: ‘b’}; {% endprettify %}
If both entries should be included in the map, then change one of the keys:
{% prettify dart tag=pre+code %} const a = 1; const b = 2; var m = <int, String>{a: ‘a’, b: ‘b’}; {% endprettify %}
If only one of the entries is needed, then remove the one that isn't needed:
{% prettify dart tag=pre+code %} const a = 1; var m = <int, String>{a: ‘a’}; {% endprettify %}
Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which the keys and values are returned by an iterator.
The symbol ‘{0}’ is defined in a legacy library, and can't be re-exported from a library with null safety enabled.
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.
Given a library that is opted out of null safety:
{% prettify dart tag=pre+code %} // @dart = 2.8 String s; {% endprettify %}
The following code produces this diagnostic because it's exporting symbols from an opted-out library:
{% prettify dart tag=pre+code %} export [!‘optedOut.dart’!];
class C {} {% endprettify %}
If you‘re able to do so, migrate the exported library so that it doesn’t need to opt out:
{% prettify dart tag=pre+code %} String? s; {% endprettify %}
If you can't migrate the library, then remove the export:
{% prettify dart tag=pre+code %} class C {} {% endprettify %}
If the exported library (the one that is opted out) itself exports an opted-in library, then it's valid for your library to indirectly export the symbols from the opted-in library. You can do so by adding a hide combinator to the export directive in your library that hides all of the names declared in the opted-out library.
Expressions can't be used in a map literal.
The analyzer produces this diagnostic when the analyzer finds an expression, rather than a map entry, in what appears to be a map literal.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} var map = <String, int>{‘a’: 0, ‘b’: 1, [!‘c’!]}; {% endprettify %}
If the expression is intended to compute either a key or a value in an entry, fix the issue by replacing the expression with the key or the value. For example:
{% prettify dart tag=pre+code %} var map = <String, int>{‘a’: 0, ‘b’: 1, ‘c’: 2}; {% endprettify %}
Classes can only extend other classes.
The analyzer produces this diagnostic when an extends clause contains a name that is declared to be something other than a class.
The following code produces this diagnostic because f is declared to be a function:
{% prettify dart tag=pre+code %} void f() {}
class C extends [!f!] {} {% endprettify %}
If you want the class to extend a class other than Object, then replace the name in the extends clause with the name of that class:
{% prettify dart tag=pre+code %} void f() {}
class C extends B {}
class B {} {% endprettify %}
If you want the class to extend Object, then remove the extends clause:
{% prettify dart tag=pre+code %} void f() {}
class C {} {% endprettify %}
Extension ‘{0}’ can't be used as an expression.
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.
The following code produces this diagnostic because E is an extension:
{% prettify dart tag=pre+code %} extension E on int { static String m() => ''; }
var x = [!E!]; {% endprettify %}
Replace the name of the extension with a name that can be referenced, such as a static member defined on the extension:
{% prettify dart tag=pre+code %} extension E on int { static String m() => ''; }
var x = E.m(); {% endprettify %}
Extension ‘{0}’ can't define static member ‘{1}’ and an instance member with the same name.
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.
The following code produces this diagnostic because the name a is being used for two different members:
{% prettify dart tag=pre+code %} extension E on Object { int get a => 0; static int !a! => 0; } {% endprettify %}
Rename or remove one of the members:
{% prettify dart tag=pre+code %} extension E on Object { int get a => 0; static int b() => 0; } {% endprettify %}
Extensions can't declare abstract members.
The analyzer produces this diagnostic when an abstract declaration is declared in an extension. Extensions can declare only concrete members.
The following code produces this diagnostic because the method a doesn't have a body:
{% prettify dart tag=pre+code %} extension E on String { int !a!; } {% endprettify %}
Either provide an implementation for the member or remove it.
Extensions can't declare constructors.
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.
The following code produces this diagnostic because there is a constructor declaration in E:
{% prettify dart tag=pre+code %} extension E on String { !E! : super(); } {% endprettify %}
Remove the constructor or replace it with a static method.
Extensions can't declare instance fields
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.
The following code produces this diagnostic because s is an instance field:
{% prettify dart tag=pre+code %} extension E on String { String [!s!]; } {% endprettify %}
Remove the field, make it a static field, or convert it to be a getter, setter, or method.
Extensions can't declare members with the same name as a member declared by ‘Object’.
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.
The following code produces this diagnostic because toString is defined by Object:
{% prettify dart tag=pre+code %} extension E on String { String !toString! => this; } {% endprettify %}
Remove the member or rename it so that the name doesn't conflict with the member in Object:
{% prettify dart tag=pre+code %} extension E on String { String displayString() => this; } {% endprettify %}
An extension override can't be used to access a static member from an extension.
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.
The following code produces this diagnostic because m is static:
{% prettify dart tag=pre+code %} extension E on String { static void m() {} }
void f() { E('').!m!; } {% endprettify %}
Replace the extension override with the name of the extension:
{% prettify dart tag=pre+code %} extension E on String { static void m() {} }
void f() { E.m(); } {% endprettify %}
The type of the argument to the extension override ‘{0}’ isn't assignable to the extended type ‘{1}’.
The analyzer produces this diagnostic when the argument to an extension override isn't assignable to the type being extended by the extension.
The following code produces this diagnostic because 3 isn't a String:
{% prettify dart tag=pre+code %} extension E on String { void method() {} }
void f() { E([!3!]).method(); } {% endprettify %}
If you're using the correct extension, then update the argument to have the correct type:
{% prettify dart tag=pre+code %} extension E on String { void method() {} }
void f() { E(3.toString()).method(); } {% endprettify %}
If there‘s a different extension that’s valid for the type of the argument, then either replace the name of the extension or unwrap the argument so that the correct extension is found.
An extension override can only be used to access instance members.
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.
The following code produces this diagnostic because E(i) isn't an expression:
{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }
void f(int i) { print([!E(i)!]); } {% endprettify %}
If you want to invoke one of the members of the extension, then add the invocation:
{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }
void f(int i) { print(E(i).a); } {% endprettify %}
If you don't want to invoke a member, then unwrap the argument:
{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }
void f(int i) { print(i); } {% endprettify %}
Extension overrides have no value so they can't be used as the receiver of a cascade expression.
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.
The following code produces this diagnostic because E(3) isn't an expression:
{% prettify dart tag=pre+code %} extension E on int { void m() {} } f() { !E!..m(); } {% endprettify %}
Use ‘.’ rather than ‘..’:
{% prettify dart tag=pre+code %} extension E on int { void m() {} } f() { E(3).m(); } {% endprettify %}
If there are multiple cascaded accesses, you'll need to duplicate the extension override for each one.
Too many positional arguments: {0} expected, but {1} found.
The analyzer produces this diagnostic when a method or function invocation has more positional arguments than the method or function allows.
The following code produces this diagnostic because f defines 2 parameters but is invoked with 3 arguments:
{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f[!(1, 2, 3)!]; } {% endprettify %}
Remove the arguments that don't correspond to parameters:
{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f(1, 2); } {% endprettify %}
Too many positional arguments: {0} expected, but {1} found.
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.
The following code produces this diagnostic because f defines 2 positional parameters but has a named parameter that could be used for the third argument:
{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f[!(1, 2, 3)!]; } {% endprettify %}
If some of the arguments should be values for named parameters, then add the names before the arguments:
{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f(1, 2, c: 3); } {% endprettify %}
Otherwise, remove the arguments that don't correspond to positional parameters:
{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f(1, 2); } {% endprettify %}
Fields can't be initialized in the constructor if they are final and were already initialized at their declaration.
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.
The following code produces this diagnostic because f is :
{% prettify dart tag=pre+code %} class C { final int f = 0; C() : [!f!] = 1; } {% endprettify %}
If the initialization doesn't depend on any values passed to the constructor, and if all of the constructors need to initialize the field to the same value, then remove the initializer from the constructor:
{% prettify dart tag=pre+code %} class C { final int f = 0; C(); } {% endprettify %}
If the initialization depends on a value passed to the constructor, or if different constructors need to initialize the field differently, then remove the initializer in the field's declaration:
{% prettify dart tag=pre+code %} class C { final int f; C() : f = 1; } {% endprettify %}
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}’.
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.
The following code produces this diagnostic because 0 has the type int, and an int can't be assigned to a field of type String:
{% prettify dart tag=pre+code %} class C { String s;
C() : s = [!0!]; } {% endprettify %}
If the type of the field is correct, then change the value assigned to it so that the value has a valid type:
{% prettify dart tag=pre+code %} class C { String s;
C() : s = ‘0’; } {% endprettify %}
If the type of the value is correct, then change the type of the field to allow the assignment:
{% prettify dart tag=pre+code %} class C { int s;
C() : s = 0; } {% endprettify %}
The final variable ‘{0}’ must be initialized.
The analyzer produces this diagnostic when a final field or variable isn't initialized.
The following code produces this diagnostic because x doesn't have an initializer:
{% prettify dart tag=pre+code %} final [!x!]; {% endprettify %}
For variables and static fields, you can add an initializer:
{% prettify dart tag=pre+code %} final x = 0; {% endprettify %}
For instance fields, you can add an initializer as shown in the previous example, or you can initialize the field in every constructor. You can initialize the field by using a field formal parameter:
{% prettify dart tag=pre+code %} class C { final int x; C(this.x); } {% endprettify %}
You can also initialize the field by using an initializer in the constructor:
{% prettify dart tag=pre+code %} class C { final int x; C(int y) : x = y * 2; } {% endprettify %}
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.
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.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} class C { final String value;
!C!; } {% endprettify %}
If the value should be passed in to the constructor directly, then use a field formal parameter to initialize the field value:
{% prettify dart tag=pre+code %} class C { final String value;
C(this.value); } {% endprettify %}
If the value should be computed indirectly from a value provided by the caller, then add a parameter and include an initializer:
{% prettify dart tag=pre+code %} class C { final String value;
C(Object o) : value = o.toString(); } {% endprettify %}
If the value of the field doesn't depend on values that can be passed to the constructor, then add an initializer for the field as part of the field declaration:
{% prettify dart tag=pre+code %} class C { final String value = '';
C(); } {% endprettify %}
If the value of the field doesn't depend on values that can be passed to the constructor but different constructors need to initialize it to different values, then add an initializer for the field in the initializer list:
{% prettify dart tag=pre+code %} class C { final String value;
C() : value = '';
C.named() : value = ‘c’; } {% endprettify %}
However, if the value is the same for all instances, then consider using a static field instead of an instance field:
{% prettify dart tag=pre+code %} class C { static const String value = '';
C(); } {% endprettify %}
The type ‘{0}’ used in the ‘for’ loop must implement {1}.
The analyzer produces this diagnostic when the expression following in in a for-in loop has a type that isn't a subclass of Iterable.
The following code produces this diagnostic because m is a Map, and Map isn't a subclass of Iterable:
{% prettify dart tag=pre+code %} void f(Map<String, String> m) { for (String s in [!m!]) { print(s); } } {% endprettify %}
Replace the expression with one that produces an iterable value:
{% prettify dart tag=pre+code %} void f(Map<String, String> m) { for (String s in m.values) { print(s); } } {% endprettify %}
Functions marked ‘async’ must have a return type assignable to ‘Future’.
The analyzer produces this diagnostic when the body of a function has the async modifier even though the return type of the function isn't assignable to Future.
The following code produces this diagnostic because the body of the function f has the async modifier even though the return type isn't assignable to Future:
{% prettify dart tag=pre+code %} [!int!] f() async { return 0; } {% endprettify %}
If the function should be asynchronous, then change the return type to be assignable to Future:
{% prettify dart tag=pre+code %} Future f() async { return 0; } {% endprettify %}
If the function should be synchronous, then remove the async modifier:
{% prettify dart tag=pre+code %} int f() { return 0; } {% endprettify %}
Classes and mixins can only implement other classes and mixins.
The analyzer produces this diagnostic when a name used in the implements clause of a class or mixin declaration is defined to be something other than a class or mixin.
The following code produces this diagnostic because x is a variable rather than a class or mixin:
{% prettify dart tag=pre+code %} var x; class C implements [!x!] {} {% endprettify %}
If the name is the name of an existing class or mixin that‘s already being imported, then add a prefix to the import so that the local definition of the name doesn’t shadow the imported name.
If the name is the name of an existing class or mixin that isn't being imported, then add an import, with a prefix, for the library in which it’s declared.
Otherwise, either replace the name in the implements clause with the name of an existing class or mixin, or remove the name from the implements clause.
‘{0}’ can only be implemented once.
The analyzer produces this diagnostic when a single class is specified more than once in an implements clause.
The following code produces this diagnostic because A is in the list twice:
{% prettify dart tag=pre+code %} class A {} class B implements A, [!A!] {} {% endprettify %}
Remove all except one occurrence of the class name:
{% prettify dart tag=pre+code %} class A {} class B implements A {} {% endprettify %}
The instance member ‘{0}’ can't be accessed in an initializer.
The analyzer produces this diagnostic when it finds a reference to an instance member in a constructor's initializer list.
The following code produces this diagnostic because defaultX is an instance member:
{% prettify dart tag=pre+code %} class C { int x;
C() : x = [!defaultX!];
int get defaultX => 0; } {% endprettify %}
If the member can be made static, then do so:
{% prettify dart tag=pre+code %} class C { int x;
C() : x = defaultX;
static int get defaultX => 0; } {% endprettify %}
If not, then replace the reference in the initializer with a different expression that doesn't use an instance member:
{% prettify dart tag=pre+code %} class C { int x;
C() : x = 0;
int get defaultX => 0; } {% endprettify %}
The library ‘{0}’ is internal and can't be imported.
The analyzer produces this diagnostic when it finds an import whose dart: URI references an internal library.
The following code produces this diagnostic because _interceptors is an internal library:
{% prettify dart tag=pre+code %} import [!‘dart:_interceptors’!]; {% endprettify %}
Remove the import directive.
Superinterfaces don't have a valid override for ‘{0}’: {1}.
The analyzer produces this diagnostic when a class inherits two or more conflicting signatures for a member and doesn't provide an implementation that satisfies all the inherited signatures.
The following code produces this diagnostic because C is inheriting the declaration of m from A, and that implementation isn‘t consistent with the signature of m that’s inherited from B:
{% prettify dart tag=pre+code %} class A { void m({int a}) {} }
class B { void m({int b}) {} }
class [!C!] extends A implements B { } {% endprettify %}
Add an implementation of the method that satisfies all the inherited signatures:
{% prettify dart tag=pre+code %} class A { void m({int a}) {} }
class B { void m({int b}) {} }
class C extends A implements B { void m({int a, int b}) {} } {% endprettify %}
‘{0}’ isn't a field in the enclosing class.
The analyzer produces this diagnostic when a constructor initializes a field that isn‘t declared in the class containing the constructor. Constructors can’t initialize fields that aren't declared and fields that are inherited from superclasses.
The following code produces this diagnostic because the initializer is initializing x, but x isn't a field in the class:
{% prettify dart tag=pre+code %} class C { int y;
C() : [!x = 0!]; } {% endprettify %}
If a different field should be initialized, then change the name to the name of the field:
{% prettify dart tag=pre+code %} class C { int y;
C() : y = 0; } {% endprettify %}
If the field must be declared, then add a declaration:
{% prettify dart tag=pre+code %} class C { int x; int y;
C() : x = 0; } {% endprettify %}
‘{0}’ isn't a field in the enclosing class.
The analyzer produces this diagnostic when a field formal parameter is found in a constructor in a class that doesn‘t declare the field being initialized. Constructors can’t initialize fields that aren't declared and fields that are inherited from superclasses.
The following code produces this diagnostic because the field x isn't defined:
{% prettify dart tag=pre+code %} class C { int y;
C([!this.x!]); } {% endprettify %}
If the field name was wrong, then change it to the name of an existing field:
{% prettify dart tag=pre+code %} class C { int y;
C(this.y); } {% endprettify %}
If the field name is correct but hasn't yet been defined, then declare the field:
{% prettify dart tag=pre+code %} class C { int x; int y;
C(this.x); } {% endprettify %}
If the parameter is needed but shouldn't initialize a field, then convert it to a normal parameter and use it:
{% prettify dart tag=pre+code %} class C { int y;
C(int x) : y = x * 2; } {% endprettify %}
If the parameter isn't needed, then remove it:
{% prettify dart tag=pre+code %} class C { int y;
C(); } {% endprettify %}
Static {1} ‘{0}’ can't be accessed through an instance.
The analyzer produces this diagnostic when an access operator is used to access a static member through an instance of the class.
The following code produces this diagnostic because zero is a static field, but it’s being accessed as if it were an instance field:
{% prettify dart tag=pre+code %} void f(C c) { c.[!zero!]; }
class C { static int zero = 0; } {% endprettify %}
Use the class to access the static member:
{% prettify dart tag=pre+code %} void f(C c) { C.zero; }
class C { static int zero = 0; } {% endprettify %}
Instance members can't be accessed from a factory constructor.
The analyzer produces this diagnostic when a factory constructor contains an unqualified reference to an instance member. In a generative constructor, the instance of the class is created and initialized before the body of the constructor is executed, so the instance can be bound to this and accessed just like it would be in an instance method. But, in a factory constructor, the instance isn‘t created before executing the body, so this can’t be used to reference it.
The following code produces this diagnostic because x isn't in scope in the factory constructor:
{% prettify dart tag=pre+code %} class C { int x; factory C() { return C.([!x!]); } C.(this.x); } {% endprettify %}
Rewrite the code so that it doesn't reference the instance member:
{% prettify dart tag=pre+code %} class C { int x; factory C() { return C.(0); } C.(this.x); } {% endprettify %}
Instance members can't be accessed from a static method.
The analyzer produces this diagnostic when a static method contains an unqualified reference to an instance member.
The following code produces this diagnostic because the instance field x is being referenced in a static method:
{% prettify dart tag=pre+code %} class C { int x;
static int m() { return [!x!]; } } {% endprettify %}
If the method must reference the instance member, then it can't be static, so remove the keyword:
{% prettify dart tag=pre+code %} class C { int x;
int m() { return x; } } {% endprettify %}
If the method can't be made an instance method, then add a parameter so that an instance of the class can be passed in:
{% prettify dart tag=pre+code %} class C { int x;
static int m(C c) { return c.x; } } {% endprettify %}
Abstract classes can't be instantiated.
The analyzer produces this diagnostic when it finds a constructor invocation and the constructor is declared in an abstract class. Even though you can't create an instance of an abstract class, abstract classes can declare constructors that can be invoked by subclasses.
The following code produces this diagnostic because C is an abstract class:
{% prettify dart tag=pre+code %} abstract class C {}
var c = new !C!; {% endprettify %}
If there's a concrete subclass of the abstract class that can be used, then create an instance of the concrete subclass.
A value of type ‘{0}’ can't be assigned to a variable of type ‘{1}’.
The analyzer produces this diagnostic when the static type of an expression that is assigned to a variable isn't assignable to the type of the variable.
The following code produces this diagnostic because the type of the initializer (int) isn't assignable to the type of the variable (String):
{% prettify dart tag=pre+code %} int i = 0; String s = [!i!]; {% endprettify %}
If the value being assigned is always assignable at runtime, even though the static types don't reflect that, then add an explicit cast.
Otherwise, change the value being assigned so that it has the expected type. In the previous example, this might look like:
{% prettify dart tag=pre+code %} int i = 0; String s = i.toString(); {% endprettify %}
If you can’t change the value, then change the type of the variable to be compatible with the type of the value being assigned:
{% prettify dart tag=pre+code %} int i = 0; int s = i; {% endprettify %}
Extension overrides must have exactly one argument: the value of ‘this’ in the extension method.
The analyzer produces this diagnostic when an extension override doesn't have exactly one argument. The argument is the expression used to compute the value of this within the extension method, so there must be one argument.
The following code produces this diagnostic because there are no arguments:
{% prettify dart tag=pre+code %} extension E on String { String join(String other) => ‘$this $other’; }
void f() { E[!()!].join(‘b’); } {% endprettify %}
And, the following code produces this diagnostic because there's more than one argument:
{% prettify dart tag=pre+code %} extension E on String { String join(String other) => ‘$this $other’; }
void f() { E[!(‘a’, ‘b’)!].join(‘c’); } {% endprettify %}
Provide one argument for the extension override:
{% prettify dart tag=pre+code %} extension E on String { String join(String other) => ‘$this $other’; }
void f() { E(‘a’).join(‘b’); } {% endprettify %}
The name of a factory constructor must be the same as the name of the immediately enclosing class.
The analyzer produces this diagnostic when the name of a factory constructor isn't the same as the name of the surrounding class.
The following code produces this diagnostic because the name of the factory constructor (A) isn't the same as the surrounding class (C):
{% prettify dart tag=pre+code %} class A {}
class C { factory !A! => throw 0; } {% endprettify %}
If the factory returns an instance of the surrounding class, then rename the factory:
{% prettify dart tag=pre+code %} class A {}
class C { factory C() => throw 0; } {% endprettify %}
If the factory returns an instance of a different class, then move the factory to that class:
{% prettify dart tag=pre+code %} class A { factory A() => throw 0; }
class C {} {% endprettify %}
If the factory returns an instance of a different class, but you can‘t modify that class or don’t want to move the factory, then convert it to be a static method:
{% prettify dart tag=pre+code %} class A {}
class C { static A a() => throw 0; } {% endprettify %}
Only const constructors can have the @literal annotation.
The analyzer produces this diagnostic when the @literal annotation is applied to anything other than a const constructor.
The following code produces this diagnostic because the constructor isn't a const constructor:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class C { [!@literal!] C(); } {% endprettify %}
The following code produces this diagnostic because x isn't a constructor:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
[!@literal!] var x; {% endprettify %}
If the annotation is on a constructor and the constructor should always be invoked with const, when possible, then mark the constructor with the const keyword:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class C { @literal const C(); } {% endprettify %}
If the constructor can't be marked as const, then remove the annotation.
If the annotation is on anything other than a constructor, then remove the annotation:
{% prettify dart tag=pre+code %} var x; {% endprettify %}
The receiver can‘t be null because of short-circuiting, so the null-aware operator ‘{0}’ can’t be used.
The receiver can‘t be null, so the null-aware operator ‘{0}’ can’t be used.
The analyzer produces this diagnostic when a null-aware operator (?., ?.., ?[, ?..[, or ...?) is used on a receiver that's known to be non-nullable.
The following code produces this diagnostic because s can't be null:
{% prettify dart tag=pre+code %} int? getLength(String s) { return s[!?.!]length; } {% endprettify %}
The following code produces this diagnostic because a can't be null:
{% prettify dart tag=pre+code %} var a = []; var b = [[!...?!]a]; {% endprettify %}
Replace the null-aware operator with a non-null-aware equivalent; for example, change ?. to .:
{% prettify dart tag=pre+code %} int getLength(String s) { return s.length; } {% endprettify %}
(Note that the return type was also changed to be non-nullable, which might not be appropriate in some cases.)
‘{1}.{0}’ (‘{2}’) isn‘t a valid override of ‘{3}.{0}’ (’{4}').
The analyzer produces this diagnostic when a member of a class is found that overrides a member from a supertype and the override isn't valid. An override is valid if all of these are true:
The following code produces this diagnostic because the type of the parameter s (String) isn't assignable to the type of the parameter i (int):
{% prettify dart tag=pre+code %} class A { void m(int i) {} }
class B extends A { void [!m!](String s) {} } {% endprettify %}
If the invalid method is intended to override the method from the superclass, then change it to conform:
{% prettify dart tag=pre+code %} class A { void m(int i) {} }
class B extends A { void m(int i) {} } {% endprettify %}
If it isn't intended to override the method from the superclass, then rename it:
{% prettify dart tag=pre+code %} class A { void m(int i) {} }
class B extends A { void m2(String s) {} } {% endprettify %}
Invalid reference to ‘this’ expression.
The analyzer produces this diagnostic when this is used outside of an instance method or a generative constructor. The reserved word this is only defined in the context of an instance method or a generative constructor.
The following code produces this diagnostic because v is a top-level variable:
{% prettify dart tag=pre+code %} C f() => [!this!];
class C {} {% endprettify %}
Use a variable of the appropriate type in place of this, declaring it if necessary:
{% prettify dart tag=pre+code %} C f(C c) => c;
class C {} {% endprettify %}
Invalid URI syntax: ‘{0}’.
The analyzer produces this diagnostic when a URI in a directive doesn't conform to the syntax of a valid URI.
The following code produces this diagnostic because '#' isn't a valid URI:
{% prettify dart tag=pre+code %} import [!‘#’!]; {% endprettify %}
Replace the invalid URI with a valid URI.
Can't have modifier ‘#lexeme’ in an extension.
The analyzer produces this diagnostic when a member declared inside an extension uses the keyword covariant in the declaration of a parameter. Extensions aren‘t classes and don’t have subclasses, so the keyword serves no purpose.
The following code produces this diagnostic because i is marked as being covariant:
{% prettify dart tag=pre+code %} extension E on String { void a([!covariant!] int i) {} } {% endprettify %}
Remove the ‘covariant’ keyword:
{% prettify dart tag=pre+code %} extension E on String { void a(int i) {} } {% endprettify %}
An expression whose value is always ‘null’ can't be dereferenced.
The analyzer produces this diagnostic when an expression whose value will always be null is dererenced.
The following code produces this diagnostic because x will always be null:
{% prettify dart tag=pre+code %} int f(Null x) { return [!x!].length; } {% endprettify %}
If the value is allowed to be something other than null, then change the type of the expression:
{% prettify dart tag=pre+code %} int f(String? x) { return x!.length; } {% endprettify %}
The member ‘{0}’ is annotated with ‘{1}’, but this annotation is only meaningful on declarations of public members.
The analyzer produces this diagnostic when either the @visibleForTemplate or @visibleForTesting annotation is applied to a non-public declaration.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
[!@visibleForTesting!] void _someFunction() {}
void f() => _someFunction(); {% endprettify %}
If the declaration doesn't need to be used by test code, then remove the annotation:
{% prettify dart tag=pre+code %} void _someFunction() {}
void f() => _someFunction(); {% endprettify %}
If it does, then make it public:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
@visibleForTesting void someFunction() {}
void f() => someFunction(); {% endprettify %}
The extension ‘{0}’ doesn‘t define a ‘call’ method so the override can’t be used in an invocation.
The analyzer produces this diagnostic when an extension override is used to invoke a function but the extension doesn't declare a call method.
The following code produces this diagnostic because the extension E doesn't define a call method:
{% prettify dart tag=pre+code %} extension E on String {}
void f() { !E('')!; } {% endprettify %}
If the extension is intended to define a call method, then declare it:
{% prettify dart tag=pre+code %} extension E on String { int call() => 0; }
void f() { E('')(); } {% endprettify %}
If the extended type defines a call method, then remove the extension override.
If the call method isn‘t defined, then rewrite the code so that it doesn’t invoke the call method.
‘{0}’ isn't a function.
The analyzer produces this diagnostic when it finds a function invocation, but the name of the function being invoked is defined to be something other than a function.
The following code produces this diagnostic because Binary is the name of a function type, not a function:
{% prettify dart tag=pre+code %} typedef Binary = int Function(int, int);
int f() { return [!Binary!](1, 2); } {% endprettify %}
Replace the name with the name of a function.
The expression doesn‘t evaluate to a function, so it can’t be invoked.
The analyzer produces this diagnostic when a function invocation is found, but the name being referenced isn‘t the name of a function, or when the expression computing the function doesn’t compute a function.
The following code produces this diagnostic because x isn't a function:
{% prettify dart tag=pre+code %} int x = 0;
int f() => x;
var y = !x!; {% endprettify %}
The following code produces this diagnostic because f() doesn't return a function:
{% prettify dart tag=pre+code %} int x = 0;
int f() => x;
var y = !f()!; {% endprettify %}
If you need to invoke a function, then replace the code before the argument list with the name of a function or with an expression that computes a function:
{% prettify dart tag=pre+code %} int x = 0;
int f() => x;
var y = f(); {% endprettify %}
The element type ‘{0}’ can't be assigned to the list type ‘{1}’.
The analyzer produces this diagnostic when the type of an element in a list literal isn't assignable to the element type of the list.
The following code produces this diagnostic because 2.5 is a double, and the list can hold only integers:
{% prettify dart tag=pre+code %} List x = [1, [!2.5!], 3]; {% endprettify %}
If you intended to add a different object to the list, then replace the element with an expression that computes the intended object:
{% prettify dart tag=pre+code %} List x = [1, 2, 3]; {% endprettify %}
If the object shouldn't be in the list, then remove the element:
{% prettify dart tag=pre+code %} List x = [1, 3]; {% endprettify %}
If the object being computed is correct, then widen the element type of the list to allow all of the different types of objects it needs to contain:
{% prettify dart tag=pre+code %} List x = [1, 2.5, 3]; {% endprettify %}
Map entries can only be used in a map literal.
The analyzer produces this diagnostic when a map entry (a key/value pair) is found in a set literal.
The following code produces this diagnostic because the literal has a map entry even though it's a set literal:
{% prettify dart tag=pre+code %} const collection = {[!‘a’ : ‘b’!]}; {% endprettify %}
If you intended for the collection to be a map, then change the code so that it is a map. In the previous example, you could do this by adding another type argument:
{% prettify dart tag=pre+code %} const collection = <String, String>{‘a’ : ‘b’}; {% endprettify %}
In other cases, you might need to change the explicit type from Set to Map.
If you intended for the collection to be a set, then remove the map entry, possibly by replacing the colon with a comma if both values should be included in the set:
{% prettify dart tag=pre+code %} const collection = {‘a’, ‘b’}; {% endprettify %}
The element type ‘{0}’ can't be assigned to the map key type ‘{1}’.
The analyzer produces this diagnostic when a key of a key-value pair in a map literal has a type that isn't assignable to the key type of the map.
The following code produces this diagnostic because 2 is an int, but the keys of the map are required to be Strings:
{% prettify dart tag=pre+code %} var m = <String, String>{[!2!] : ‘a’}; {% endprettify %}
If the type of the map is correct, then change the key to have the correct type:
{% prettify dart tag=pre+code %} var m = <String, String>{‘2’ : ‘a’}; {% endprettify %}
If the type of the key is correct, then change the key type of the map:
{% prettify dart tag=pre+code %} var m = <int, String>{2 : ‘a’}; {% endprettify %}
The element type ‘{0}’ can't be assigned to the map value type ‘{1}’.
The analyzer produces this diagnostic when a value of a key-value pair in a map literal has a type that isn't assignable to the the value type of the map.
The following code produces this diagnostic because 2 is an int, but/ the values of the map are required to be Strings:
{% prettify dart tag=pre+code %} var m = <String, String>{‘a’ : [!2!]}; {% endprettify %}
If the type of the map is correct, then change the value to have the correct type:
{% prettify dart tag=pre+code %} var m = <String, String>{‘a’ : ‘2’}; {% endprettify %}
If the type of the value is correct, then change the value type of the map:
{% prettify dart tag=pre+code %} var m = <String, int>{‘a’ : 2}; {% endprettify %}
The parameter ‘{0}’ can't have a value of ‘null’ because of its type, and no non-null default value is provided.
The analyzer produces this diagnostic when an optional parameter, whether positional or named, has a potentially non-nullable type and doesn‘t specify a default value. Optional parameters that have no explicit default value have an implicit default value of null. If the type of the parameter doesn’t allow the parameter to have a value of null, then the implicit default value isn't valid.
The following code produces this diagnostic because x can't be null, and no non-null default value is specified:
{% prettify dart tag=pre+code %} void f([int [!x!]]) {} {% endprettify %}
As does this:
{% prettify dart tag=pre+code %} void g({int [!x!]}) {} {% endprettify %}
If you want to use null to indicate that no value was provided, then you need to make the type nullable:
{% prettify dart tag=pre+code %} void f([int? x]) {} void g({int? x}) {} {% endprettify %}
If the parameter can't be null, then either provide a default value:
{% prettify dart tag=pre+code %} void f([int x = 1]) {} void g({int x = 2}) {} {% endprettify %}
or make the parameter a required parameter:
{% prettify dart tag=pre+code %} void f(int x) {} void g({required int x}) {} {% endprettify %}
Missing case clause for ‘{0}’.
The analyzer produces this diagnostic when a switch statement for an enum doesn't include an option for one of the values in the enumeration.
Note that null is always a possible value for an enum and therefore also must be handled.
The following code produces this diagnostic because the enum constant e2 isn't handled:
{% prettify dart tag=pre+code %} enum E { e1, e2 }
void f(E e) { [!switch (e)!] { case E.e1: break; } } {% endprettify %}
If there's special handling for the missing values, then add a case clause for each of the missing values:
{% prettify dart tag=pre+code %} enum E { e1, e2 }
void f(E e) { switch (e) { case E.e1: break; case E.e2: break; } } {% endprettify %}
If the missing values should be handled the same way, then add a default clause:
{% prettify dart tag=pre+code %} enum E { e1, e2 }
void f(E e) { switch (e) { case E.e1: break; default: break; } } {% endprettify %}
The named parameter ‘{0}’ is required, but there's no corresponding argument.
The analyzer produces this diagnostic when an invocation of a function is missing a required named parameter.
The following code produces this diagnostic because the invocation of f doesn't include a value for the required named parameter end:
{% prettify dart tag=pre+code %} void f(int start, {required int end}) {} void g() { !f!; } {% endprettify %}
Add a named argument corresponding to the missing required parameter:
{% prettify dart tag=pre+code %} void f(int start, {required int end}) {} void g() { f(3, end: 5); } {% endprettify %}
The parameter ‘{0}’ is required.
The parameter ‘{0}’ is required. {1}.
The analyzer produces this diagnostic when a method or function with a named parameter that is annotated as being required is invoked without providing a value for the parameter.
The following code produces this diagnostic because the named parameter x is required:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
void f({@required int x}) {}
void g() { !f!; } {% endprettify %}
Provide the required value:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
void f({@required int x}) {}
void g() { f(x: 2); } {% endprettify %}
This function has a return type of ‘{0}’, but doesn't end with a return statement.
Any function or method that doesn't end with either an explicit return or a throw implicitly returns null. This is rarely the desired behavior. The analyzer produces this diagnostic when it finds an implicit return.
The following code produces this diagnostic because f doesn't end with a return:
{% prettify dart tag=pre+code %} int [!f!](int x) { if (x < 0) { return 0; } } {% endprettify %}
Add a return statement that makes the return value explicit, even if null is the appropriate value.
Classes can only mix in mixins and classes.
The analyzer produces this diagnostic when a name in a with clause is defined to be something other than a mixin or a class.
The following code produces this diagnostic because F is defined to be a function type:
{% prettify dart tag=pre+code %} typedef F = int Function(String);
class C with [!F!] {} {% endprettify %}
Remove the invalid name from the list, possibly replacing it with the name of the intended mixin or class:
{% prettify dart tag=pre+code %} typedef F = int Function(String);
class C {} {% endprettify %}
The class ‘{0}’ shouldn't be used as a mixin constraint because it is sealed, and any class mixing in this mixin must have ‘{0}’ as a superclass.
The analyzer produces this diagnostic when the superclass constraint of a mixin is a class from a different package that was marked as @sealed. Classes that are sealed can't be extended, implemented, mixed in, or used as a superclass constraint.
If the package ‘p’ defines a sealed class:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
@sealed class C {} {% endprettify %}
Then, the following code, when in a package other than ‘p’, produces this diagnostic:
{% prettify dart tag=pre+code %} import ‘package:p/p.dart’;
[!mixin M on C {}!] {% endprettify %}
If the classes that use the mixin don't need to be subclasses of the sealed class, then consider adding a field and delegating to the wrapped instance of the sealed class.
Only classes and mixins can be used as superclass constraints.
The analyzer produces this diagnostic when a type following the on keyword in a mixin declaration is neither a class nor a mixin.
The following code produces this diagnostic because F is neither a class nor a mixin:
{% prettify dart tag=pre+code %} typedef F = void Function();
mixin M on [!F!] {} {% endprettify %}
If the type was intended to be a class but was mistyped, then replace the name.
Otherwise, remove the type from the on clause.
This class (or a class that this class inherits from) is marked as ‘@immutable’, but one or more of its instance fields aren't final: {0}
The analyzer produces this diagnostic when an immutable class defines one or more instance fields that aren‘t final. A class is immutable if it’s marked as being immutable using the annotation @immutable or if it's a subclass of an immutable class.
The following code produces this diagnostic because the field x isn't final:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
@immutable class [!C!] { int x;
C(this.x); } {% endprettify %}
If instances of the class should be immutable, then add the keyword final to all non-final field declarations:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
@immutable class C { final int x;
C(this.x); } {% endprettify %}
If the instances of the class should be mutable, then remove the
{% prettify dart tag=pre+code %} class C { int x;
C(this.x); } {% endprettify %}
This method overrides a method annotated as ‘@mustCallSuper’ in ‘{0}’, but doesn't invoke the overridden method.
The analyzer produces this diagnostic when a method that overrides a method that is annotated as @mustCallSuper doesn't invoke the overridden method as required.
The following code produces this diagnostic because the method m in B doesn't invoke the overridden method m in A:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class A { @mustCallSuper m() {} }
class B extends A { @override !m! {} } {% endprettify %}
Add an invocation of the overridden method in the overriding method:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class A { @mustCallSuper m() {} }
class B extends A { @override m() { super.m(); } } {% endprettify %}
The class ‘{0}’ doesn't have a default constructor.
The analyzer produces this diagnostic when an unnamed constructor is invoked on a class that defines named constructors but the class doesn’t have an unnamed constructor.
The following code produces this diagnostic because A doesn't define an unnamed constructor:
{% prettify dart tag=pre+code %} class A { A.a(); }
A f() => !A!; {% endprettify %}
If one of the named constructors does what you need, then use it:
{% prettify dart tag=pre+code %} class A { A.a(); }
A f() => A.a(); {% endprettify %}
If none of the named constructors does what you need, and you're able to add an unnamed constructor, then add the constructor:
{% prettify dart tag=pre+code %} class A { A(); A.a(); }
A f() => A(); {% endprettify %}
Missing concrete implementation of ‘{0}’.
Missing concrete implementations of ‘{0}’ and ‘{1}’.
Missing concrete implementations of ‘{0}’, ‘{1}’, ‘{2}’, ‘{3}’, and {4} more.
Missing concrete implementations of ‘{0}’, ‘{1}’, ‘{2}’, and ‘{3}’.
Missing concrete implementations of ‘{0}’, ‘{1}’, and ‘{2}’.
The analyzer produces this diagnostic when a concrete class inherits one or more abstract members, and doesn't provide or inherit an implementation for at least one of those abstract members.
The following code produces this diagnostic because the class B doesn't have a concrete implementation of m:
{% prettify dart tag=pre+code %} abstract class A { void m(); }
class [!B!] extends A {} {% endprettify %}
If the subclass can provide a concrete implementation for some or all of the abstract inherited members, then add the concrete implementations:
{% prettify dart tag=pre+code %} abstract class A { void m(); }
class B extends A { void m() {} } {% endprettify %}
If there is a mixin that provides an implementation of the inherited methods, then apply the mixin to the subclass:
{% prettify dart tag=pre+code %} abstract class A { void m(); }
class B extends A with M {}
mixin M { void m() {} } {% endprettify %}
If the subclass can't provide a concrete implementation for all of the abstract inherited members, then mark the subclass as being abstract:
{% prettify dart tag=pre+code %} abstract class A { void m(); }
abstract class B extends A {} {% endprettify %}
Conditions must have a static type of ‘bool’.
The analyzer produces this diagnostic when a condition, such as an if or while loop, doesn't have the static type bool.
The following code produces this diagnostic because x has the static type int:
{% prettify dart tag=pre+code %} void f(int x) { if ([!x!]) { // ... } } {% endprettify %}
Change the condition so that it produces a Boolean value:
{% prettify dart tag=pre+code %} void f(int x) { if (x == 0) { // ... } } {% endprettify %}
The expression in an assert must be of type ‘bool’.
The analyzer produces this diagnostic when the first expression in an assert has a type other than bool.
The following code produces this diagnostic because the type of p is int, but a bool is required:
{% prettify dart tag=pre+code %} void f(int p) { assert([!p!]); } {% endprettify %}
Change the expression so that it has the type bool:
{% prettify dart tag=pre+code %} void f(int p) { assert(p > 0); } {% endprettify %}
A negation operand must have a static type of ‘bool’.
The analyzer produces this diagnostic when the operand of the unary negation operator (!) doesn't have the type bool.
The following code produces this diagnostic because x is an int when it must be a bool:
{% prettify dart tag=pre+code %} int x = 0; bool y = ![!x!]; {% endprettify %}
Replace the operand with an expression that has the type bool:
{% prettify dart tag=pre+code %} int x = 0; bool y = !(x > 0); {% endprettify %}
The operands of the operator ‘{0}’ must be assignable to ‘bool’.
The analyzer produces this diagnostic when one of the operands of either the && or || operator doesn't have the type bool.
The following code produces this diagnostic because a isn't a Boolean value:
{% prettify dart tag=pre+code %} int a = 3; bool b = [!a!] || a > 1; {% endprettify %}
Change the operand to a Boolean value:
{% prettify dart tag=pre+code %} int a = 3; bool b = a == 0 || a > 1; {% endprettify %}
Annotation creation can only call a const constructor.
The analyzer produces this diagnostic when an annotation is the invocation of an existing constructor even though the invoked constructor isn't a const constructor.
The following code produces this diagnostic because the constructor for C isn't a const constructor:
{% prettify dart tag=pre+code %} [!@C()!] void f() { }
class C { C(); } {% endprettify %}
If it's valid for the class to have a const constructor, then create a const constructor that can be used for the annotation:
{% prettify dart tag=pre+code %} @C() void f() { }
class C { const C(); } {% endprettify %}
If it isn't valid for the class to have a const constructor, then either remove the annotation or use a different class for the annotation.
Case expressions must be constant.
The analyzer produces this diagnostic when the expression in a case clause isn't a constant expression.
The following code produces this diagnostic because j isn't a constant:
{% prettify dart tag=pre+code %} void f(int i, int j) { switch (i) { case [!j!]: // ... break; } } {% endprettify %}
Either make the expression a constant expression, or rewrite the switch statement as a sequence of if statements:
{% prettify dart tag=pre+code %} void f(int i, int j) { if (i == j) { // ... } } {% endprettify %}
The default value of an optional parameter must be constant.
The analyzer produces this diagnostic when an optional parameter, either named or positional, has a default value that isn't a compile-time constant.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} var defaultValue = 3;
void f([int value = [!defaultValue!]]) {} {% endprettify %}
If the default value can be converted to be a constant, then convert it:
{% prettify dart tag=pre+code %} const defaultValue = 3;
void f([int value = defaultValue]) {} {% endprettify %}
If the default value needs to change over time, then apply the default value inside the function:
{% prettify dart tag=pre+code %} var defaultValue = 3;
void f([int value]) { value ??= defaultValue; } {% endprettify %}
The values in a const list literal must be constants.
The analyzer produces this diagnostic when an element in a constant list literal isn‘t a constant value. The list literal can be constant either explicitly (because it’s prefixed by the const keyword) or implicitly (because it appears in a constant context).
The following code produces this diagnostic because x isn't a constant, even though it appears in an implicitly constant list literal:
{% prettify dart tag=pre+code %} var x = 2; var y = const [0, 1, [!x!]]; {% endprettify %}
If the list needs to be a constant list, then convert the element to be a constant. In the example above, you might add the const keyword to the declaration of x:
{% prettify dart tag=pre+code %} const x = 2; var y = const [0, 1, x]; {% endprettify %}
If the expression can‘t be made a constant, then the list can’t be a constant either, so you must change the code so that the list isn't a constant. In the example above this means removing the const keyword before the list literal:
{% prettify dart tag=pre+code %} var x = 2; var y = [0, 1, x]; {% endprettify %}
The elements in a const map literal must be constant.
The analyzer produces this diagnostic when an if element or a spread element in a constant map isn't a constant element.
The following code produces this diagnostic because it's attempting to spread a non-constant map:
{% prettify dart tag=pre+code %} var notConst = <int, int>{}; var map = const <int, int>{...[!notConst!]}; {% endprettify %}
Similarly, the following code produces this diagnostic because the condition in the if element isn't a constant expression:
{% prettify dart tag=pre+code %} bool notConst = true; var map = const <int, int>{if ([!notConst!]) 1 : 2}; {% endprettify %}
If the map needs to be a constant map, then make the elements constants. In the spread example, you might do that by making the collection being spread a constant:
{% prettify dart tag=pre+code %} const notConst = <int, int>{}; var map = const <int, int>{...notConst}; {% endprettify %}
If the map doesn't need to be a constant map, then remove the const keyword:
{% prettify dart tag=pre+code %} bool notConst = true; var map = <int, int>{if (notConst) 1 : 2}; {% endprettify %}
The keys in a const map literal must be constant.
The analyzer produces this diagnostic when a key in a constant map literal isn't a constant value.
The following code produces this diagnostic beause a isn't a constant:
{% prettify dart tag=pre+code %} var a = ‘a’; var m = const {[!a!]: 0}; {% endprettify %}
If the map needs to be a constant map, then make the key a constant:
{% prettify dart tag=pre+code %} const a = ‘a’; var m = const {a: 0}; {% endprettify %}
If the map doesn't need to be a constant map, then remove the const keyword:
{% prettify dart tag=pre+code %} var a = ‘a’; var m = {a: 0}; {% endprettify %}
The values in a const map literal must be constant.
The analyzer produces this diagnostic when a value in a constant map literal isn't a constant value.
The following code produces this diagnostic because a isn't a constant:
{% prettify dart tag=pre+code %} var a = ‘a’; var m = const {0: [!a!]}; {% endprettify %}
If the map needs to be a constant map, then make the key a constant:
{% prettify dart tag=pre+code %} const a = ‘a’; var m = const {0: a}; {% endprettify %}
If the map doesn't need to be a constant map, then remove the const keyword:
{% prettify dart tag=pre+code %} var a = ‘a’; var m = {0: a}; {% endprettify %}
The values in a const set literal must be constants.
The analyzer produces this diagnostic when a constant set literal contains an element that isn't a compile-time constant.
The following code produces this diagnostic because i isn't a constant:
{% prettify dart tag=pre+code %} var i = 0;
var s = const {[!i!]}; {% endprettify %}
If the element can be changed to be a constant, then change it:
{% prettify dart tag=pre+code %} const i = 0;
var s = const {i}; {% endprettify %}
If the element can't be a constant, then remove the keyword const:
{% prettify dart tag=pre+code %} var i = 0;
var s = {i}; {% endprettify %}
This instance creation must be ‘const’, because the {0} constructor is marked as ‘@literal’.
This instance creation must be ‘const’, because the {0} constructor is marked as ‘@literal’.
The analyzer produces this diagnostic when a constructor that has the @literal annotation is invoked without using the const keyword, but all of the arguments to the constructor are constants. The annotation indicates that the constructor should be used to create a constant value whenever possible.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class C { @literal const C(); }
C f() => [!C()!]; {% endprettify %}
Add the keyword const before the constructor invocation:
{% prettify dart tag=pre+code %} import ‘package:meta/meta.dart’;
class C { @literal const C(); }
void f() => const C(); {% endprettify %}
The name ‘{0}’ isn‘t a type so it can’t be used as a type argument.
The analyzer produces this diagnostic when an identifier that isn't a type is used as a type argument.
The following code produces this diagnostic because x is a variable, not a type:
{% prettify dart tag=pre+code %} var x = 0; List<[!x!]> xList = []; {% endprettify %}
Change the type argument to be a type:
{% prettify dart tag=pre+code %} var x = 0; List xList = []; {% endprettify %}
The name ‘{0}’ isn‘t a type and can’t be used in an on-catch clause.
The analyzer produces this diagnostic when the identifier following the on in a catch clause is defined to be something other than a type.
The following code produces this diagnostic because f is a function, not a type:
{% prettify dart tag=pre+code %} void f() { try { // ... } on [!f!] { // ... } } {% endprettify %}
Change the name to the type of object that should be caught:
{% prettify dart tag=pre+code %} void f() { try { // ... } on FormatException { // ... } } {% endprettify %}
The non-nullable local variable ‘{0}’ must be assigned before it can be used.
The analyzer produces this diagnostic when a local variable is referenced and has all these characteristics:
late.The following code produces this diagnostic because x can't have a value of null, but is referenced before a value was assigned to it:
{% prettify dart tag=pre+code %} String f() { int x; return [!x!].toString(); } {% endprettify %}
The following code produces this diagnostic because the assignment to x might not be executed, so it might have a value of null:
{% prettify dart tag=pre+code %} int g(bool b) { int x; if (b) { x = 1; } return [!x!] * 2; } {% endprettify %}
The following code produces this diagnostic because the analyzer can‘t prove, based on definite assignment analysis, that x won’t be referenced without having a value assigned to it:
{% prettify dart tag=pre+code %} int h(bool b) { int x; if (b) { x = 1; } if (b) { return [!x!] * 2; } return 0; } {% endprettify %}
If null is a valid value, then make the variable nullable:
{% prettify dart tag=pre+code %} String f() { int? x; return x!.toString(); } {% endprettify %}
If null isn’t a valid value, and there's a reasonable default value, then add an initializer:
{% prettify dart tag=pre+code %} int g(bool b) { int x = 2; if (b) { x = 1; } return x * 2; } {% endprettify %}
Otherwise, ensure that a value was assigned on every possible code path before the value is accessed:
{% prettify dart tag=pre+code %} int g(bool b) { int x; if (b) { x = 1; } else { x = 2; } return x * 2; } {% endprettify %}
You can also mark the variable as late, which removes the diagnostic, but if the variable isn‘t assigned a value before it’s accessed, then it results in an exception being thrown at runtime. This approach should only be used if you‘re sure that the variable will always be assigned, even though the analyzer can’t prove it based on definite assignment analysis.
{% prettify dart tag=pre+code %} int h(bool b) { late int x; if (b) { x = 1; } if (b) { return x * 2; } return 0; } {% endprettify %}
{0} isn't a type.
The analyzer produces this diagnostic when a name is used as a type but declared to be something other than a type.
The following code produces this diagnostic because f is a function:
{% prettify dart tag=pre+code %} f() {} g([!f!] v) {} {% endprettify %}
Replace the name with the name of a type.
{0} positional argument(s) expected, but {1} found.
The analyzer produces this diagnostic when a method or function invocation has fewer positional arguments than the number of required positional parameters.
The following code produces this diagnostic because f declares two required parameters, but only one argument is provided:
{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f[!(0)!]; } {% endprettify %}
Add arguments corresponding to the remaining parameters:
{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f(0, 1); } {% endprettify %}
Non-nullable instance field ‘{0}’ must be initialized.
Non-nullable instance field ‘{0}’ must be initialized.
The analyzer produces this diagnostic when a field is declared and has all these characteristics:
lateThe following code produces this diagnostic because x is implicitly initialized to null when it isn't allowed to be null:
{% prettify dart tag=pre+code %} class C { int [!x!]; } {% endprettify %}
Similarly, the following code produces this diagnostic because x is implicitly initialized to null, when it isn‘t allowed to be null, by one of the constructors, even though it’s initialized by other constructors:
{% prettify dart tag=pre+code %} class C { int x;
C(this.x);
[!C!].n(); } {% endprettify %}
If there's a reasonable default value for the field that’s the same for all instances, then add an initializer expression:
{% prettify dart tag=pre+code %} class C { int x = 0; } {% endprettify %}
If the value of the field should be provided when an instance is created, then add a constructor that sets the value of the field or update an existing constructor:
{% prettify dart tag=pre+code %} class C { int x;
C(this.x); } {% endprettify %}
You can also mark the field as late, which removes the diagnostic, but if the field isn‘t assigned a value before it’s accessed, then it results in an exception being thrown at runtime. This approach should only be used if you‘re sure that the field will always be assigned before it’s referenced.
{% prettify dart tag=pre+code %} class C { late int x; } {% endprettify %}
The non-nullable variable ‘{0}’ must be initialized.
The analyzer produces this diagnostic when a static field or top-level variable has a type that‘s non-nullable and doesn’t have an initializer. Fields and variables that don‘t have an initializer are normally initialized to null, but the type of the field or variable doesn’t allow it to be set to null, so an explicit initializer must be provided.
The following code produces this diagnostic because the field f can't be initialized to null:
{% prettify dart tag=pre+code %} class C { static int [!f!]; } {% endprettify %}
Similarly, the following code produces this diagnostic because the top-level variable v can't be initialized to null:
{% prettify dart tag=pre+code %} int [!v!]; {% endprettify %}
If the field or variable can't be initialized to null, then add an initializer that sets it to a non-null value:
{% prettify dart tag=pre+code %} class C { static int f = 0; } {% endprettify %}
If the field or variable should be initialized to null, then change the type to be nullable:
{% prettify dart tag=pre+code %} int? v; {% endprettify %}
If the field or variable can‘t be initialized in the declaration but will always be initialized before it’s referenced, then mark it as being late:
{% prettify dart tag=pre+code %} class C { static late int f; } {% endprettify %}
Spread elements in list or set literals must implement ‘Iterable’.
The analyzer produces this diagnostic when the static type of the expression of a spread element that appears in either a list literal or a set literal doesn't implement the type Iterable.
The following code produces this diagnostic:
{% prettify dart tag=pre+code %} var m = <String, int>{‘a’: 0, ‘b’: 1}; var s = {...[!m!]}; {% endprettify %}
The most common fix is to replace the expression with one that produces an iterable object:
{% prettify dart tag=pre+code %} var m = <String, int>{‘a’: 0, ‘b’: 1}; var s = {...m.keys}; {% endprettify %}
Spread elements in map literals must implement ‘Map’.
The analyzer produces this diagnostic when the static type of the expression of a spread element that appears in a map literal doesn't implement the type Map.
The following code produces this diagnostic because l isn't a Map:
{% prettify dart tag=pre+code %} var l = [‘a’, ‘b’]; var m = <int, String>{...[!l!]}; {% endprettify %}
The most common fix is to replace the expression with one that produces a map:
{% prettify dart tag=pre+code %} var l = [‘a’, ‘b’]; var m = <int, String>{...l.asMap()}; {% endprettify %}
Annotation creation must have arguments.
The analyzer produces this diagnostic when an annotation consists of a single identifier, but that identifier is the name of a class rather than a variable. To create an instance of the class, the identifier must be followed by an argument list.
The following code produces this diagnostic because C is a class, and a class can't be used as an annotation without invoking a const constructor from the class:
{% prettify dart tag=pre+code %} class C { const C(); }
[!@C!] var x; {% endprettify %}
Add the missing argument list:
{% prettify dart tag=pre+code %} class C { const C(); }
@C() var x; {% endprettify %}
A potentially nullable type can‘t be used in an ‘on’ clause because it isn’t valid to throw a nullable expression.
The analyzer produces this diagnostic when the type following on in a catch clause is a nullable type. It isn‘t valid to specify a nullable type because it isn’t possible to catch null (because it's a runtime error to throw null).
The following code produces this diagnostic because the exception type is specified to allow null when null can't be thrown:
{% prettify dart tag=pre+code %} void f() { try { // ... } on [!FormatException?!] { } } {% endprettify %}
Remove the question mark from the type:
{% prettify dart tag=pre+code %} void f() { try { // ... } on FormatException { } } {% endprettify %}
A class can't extend a nullable type.
The analyzer produces this diagnostic when a class declaration uses an extends clause to specify a superclass, and the superclass is followed by a ?.
It isn‘t valid to specify a nullable superclass because doing so would have no meaning; it wouldn’t change either the interface or implementation being inherited by the class containing the extends clause.
Note, however, that it is valid to use a nullable type as a type argument to the superclass, such as class A extends B<C?> {}.
The following code produces this diagnostic because A? is a nullable type, and nullable types can't be used in an extends clause:
{% prettify dart tag=pre+code %} class A {} class B extends [!A?!] {} {% endprettify %}
Remove the question mark from the type:
{% prettify dart tag=pre+code %} class A {} class B extends A {} {% endprettify %}
A class or mixin can't implement a nullable type.
The analyzer produces this diagnostic when a class or mixin declaration has an implements clause, and an interface is followed by a ?.
It isn‘t valid to specify a nullable interface because doing so would have no meaning; it wouldn’t change the interface being inherited by the class containing the implements clause.
Note, however, that it is valid to use a nullable type as a type argument to the interface, such as class A implements B<C?> {}.
The following code produces this diagnostic because A? is a nullable type, and nullable types can't be used in an implements clause:
{% prettify dart tag=pre+code %} class A {} class B implements [!A?!] {} {% endprettify %}
Remove the question mark from the type:
{% prettify dart tag=pre+code %} class A {} class B implements A {} {% endprettify %}
A mixin can't have a nullable type as a superclass constraint.
The analyzer produces this diagnostic when a mixin declaration uses an on clause to specify a superclass constraint, and the class that's specified is followed by a ?.
It isn‘t valid to specify a nullable superclass constraint because doing so would have no meaning; it wouldn’t change the interface being depended on by the mixin containing the on clause.
Note, however, that it is valid to use a nullable type as a type argument to the superclass constraint, such as mixin A on B<C?> {}.
The following code produces this diagnostic because A? is a nullable type and nullable types can't be used in an on clause:
{% prettify dart tag=pre+code %} class C {} mixin M on [!C?!] {} {% endprettify %}
Remove the question mark from the type:
{% prettify dart tag=pre+code %} class C {} mixin M on C {} {% endprettify %}
A class or mixin can't mix in a nullable type.
The analyzer produces this diagnostic when a class or mixin declaration has a with clause, and a mixin is followed by a ?.
It isn‘t valid to specify a nullable mixin because doing so would have no meaning; it wouldn’t change either the interface or implementation being inherited by the class containing the with clause.
Note, however, that it is valid to use a nullable type as a type argument to the mixin, such as class A with B<C?> {}.
The following code produces this diagnostic because A? is a nullable type, and nullable types can't be used in a with clause:
{% prettify dart tag=pre+code %} mixin M {} class C with [!M?!] {} {% endprettify %}
Remove the question mark from the type:
{% prettify dart tag=pre+code %} mixin M {} class C with M {} {% endprettify %}
The field doesn't override an inherited getter or setter.
The getter doesn't override an inherited getter.
The method doesn't override an inherited method.
The setter doesn't override an inherited setter.
The analyzer produces this diagnostic when a class member is annotated with the @override annotation, but the member isn’t declared in any of the supertypes of the class.
The following code produces this diagnostic because m isn't declared in any of the supertypes of C:
{% prettify dart tag=pre+code %} class C { @override String !m! => ''; } {% endprettify %}
If the member is intended to override a member with a different name, then update the member to have the same name:
{% prettify dart tag=pre+code %} class C { @override String toString() => ''; } {% endprettify %}
If the member is intended to override a member that was removed from the superclass, then consider removing the member from the subclass.
If the member can't be removed, then remove the annotation.
Expected this library to be part of ‘{0}’, not ‘{1}’.
The analyzer produces this diagnostic when a library attempts to include a file as a part of itself when the other file is a part of a different library.
Given a file named part.dart containing
{% prettify dart tag=pre+code %} part of ‘library.dart’; {% endprettify %}
The following code, in any file other than library.dart, produces this diagnostic because it attempts to include part.dart as a part of itself when part.dart is a part of a different library:
{% prettify dart tag=pre+code %} part [!‘package:a/part.dart’!]; {% endprettify %}
If the library should be using a different file as a part, then change the URI in the part directive to be the URI of the other file.
If the part file should be a part of this library, then update the URI (or library name) in the part-of directive to be the URI (or name) of the correct library.
The included part ‘{0}’ must have a part-of directive.
The analyzer produces this diagnostic when a part directive is found and the referenced file doesn't have a part-of directive.
Given a file (a.dart) containing:
{% prettify dart tag=pre+code %} class A {} {% endprettify %}
The following code produces this diagnostic because a.dart doesn't contain a part-of directive:
{% prettify dart tag=pre+code %} part [!‘a.dart’!]; {% endprettify %}
If the referenced file is intended to be a part of another library, then add a part-of directive to the file:
{% prettify dart tag=pre+code %} part of ‘test.dart’;
class A {} {% endprettify %}
If the referenced file is intended to be a library, then replace the part directive with an import directive:
{% prettify dart tag=pre+code %} import ‘a.dart’; {% endprettify %}
The name ‘{0}’ refers to an import prefix, so it must be followed by ‘.’.
The analyzer produces this diagnostic when an import prefix is used by itself, without accessing any of the names declared in the libraries associated with the prefix. Prefixes aren‘t variables, and therefore can’t be used as a value.
The following code produces this diagnostic because the prefix math is being used as if it were a variable:
{% prettify dart tag=pre+code %} import ‘dart:math’ as math;
void f() { print([!math!]); } {% endprettify %}
If the code is incomplete, then reference something in one of the libraries associated with the prefix:
{% prettify dart tag=pre+code %} import ‘dart:math’ as math;
void f() { print(math.pi); } {% endprettify %}
If the name is wrong, then correct the name.
The redirected constructor ‘{0}’ has incompatible parameters with ‘{1}’.
The analyzer produces this diagnostic when a factory constructor attempts to redirect to another constructor, but the two have incompatible parameters. The parameters are compatible if all of the parameters of the redirecting constructor can be passed to the other constructor and if the other constructor doesn‘t require any parameters that aren’t declared by the redirecting constructor.
The following code produces this diagnostic because the constructor for A doesn't declare a parameter that the constructor for B requires:
{% prettify dart tag=pre+code %} abstract class A { factory A() = [!B!]; }
class B implements A { B(int x); B.zero(); } {% endprettify %}
The following code produces this diagnostic because the constructor for A declares a named parameter (y) that the constructor for B doesn't allow:
{% prettify dart tag=pre+code %} abstract class A { factory A(int x, {int y}) = [!B!]; }
class B implements A { B(int x); } {% endprettify %}
If there's a different constructor that is compatible with the redirecting constructor, then redirect to that constructor:
{% prettify dart tag=pre+code %} abstract class A { factory A() = B.zero; }
class B implements A { B(int x); B.zero(); } {% endprettify %}
Otherwise, update the redirecting constructor to be compatible:
{% prettify dart tag=pre+code %} abstract class A { factory A(int x) = B; }
class B implements A { B(int x); } {% endprettify %}
The return type ‘{0}’ of the redirected constructor isn't a subtype of ‘{1}’.
The analyzer produces this diagnostic when a factory constructor redirects to a constructor whose return type isn't a subtype of the type that the factory constructor is declared to produce.
The following code produces this diagnostic because A isn‘t a subclass of C, which means that the value returned by the constructor A() couldn’t be returned from the constructor C():
{% prettify dart tag=pre+code %} class A {}
class B implements C {}
class C { factory C() = [!A!]; } {% endprettify %}
If the factory constructor is redirecting to a constructor in the wrong class, then update the factory constructor to redirect to the correct constructor:
{% prettify dart tag=pre+code %} class A {}
class B implements C {}
class C { factory C() = B; } {% endprettify %}
If the class defining the constructor being redirected to is the class that should be returned, then make it a subtype of the factory's return type:
{% prettify dart tag=pre+code %} class A implements C {}
class B implements C {}
class C { factory C() = A; } {% endprettify %}
The name ‘{0}’ isn‘t a type and can’t be used in a redirected constructor.
One way to implement a factory constructor is to redirect to another constructor by referencing the name of the constructor. The analyzer produces this diagnostic when the redirect is to something other than a constructor.
The following code produces this diagnostic because f is a function:
{% prettify dart tag=pre+code %} C f() => throw 0;
class C { factory C() = [!f!]; } {% endprettify %}
If the constructor isn't defined, then either define it or replace it with a constructor that is defined.
If the constructor is defined but the class that defines it isn't visible, then you probably need to add an import.
If you‘re trying to return the value returned by a function, then rewrite the constructor to return the value from the constructor’s body:
{% prettify dart tag=pre+code %} C f() => throw 0;
class C { factory C() => f(); } {% endprettify %}
Local variable ‘{0}’ can't be referenced before it is declared.
The analyzer produces this diagnostic when a variable is referenced before it’s declared. In Dart, variables are visible everywhere in the block in which they are declared, but can only be referenced after they are declared.
The analyzer also produces a context message that indicates where the declaration is located.
The following code produces this diagnostic because i is used before it is declared:
{% prettify dart tag=pre+code %} void f() { print([!i!]); int i = 5; } {% endprettify %}
If you intended to reference the local variable, move the declaration before the first reference:
{% prettify dart tag=pre+code %} void f() { int i = 5; print(i); } {% endprettify %}
If you intended to reference a name from an outer scope, such as a parameter, instance field or top-level variable, then rename the local declaration so that it doesn't hide the outer variable.
{% prettify dart tag=pre+code %} void f(int i) { print(i); int x = 5; print(x); } {% endprettify %}
Constructors can't return values.
The analyzer produces this diagnostic when a generative constructor contains a return statement that specifies a value to be returned. Generative constructors always return the object that was created, and therefore can't return a different object.
The following code produces this diagnostic because the return statement has an expression:
{% prettify dart tag=pre+code %} class C { C() { return [!this!]; } } {% endprettify %}
If the constructor should create a new instance, then remove either the return statement or the expression:
{% prettify dart tag=pre+code %} class C { C(); } {% endprettify %}
If the constructor shouldn't create a new instance, then convert it to be a factory constructor:
{% prettify dart tag=pre+code %} class C { factory C() { return _instance; }
static C instance = C.();
C._(); } {% endprettify %}
A value of type ‘{0}’ can't be returned from constructor ‘{2}’ because it has a return type of ‘{1}’.
A value of type ‘{0}’ can't be returned from function ‘{2}’ because it has a return type of ‘{1}’.
A value of type ‘{0}’ can't be returned from method ‘{2}’ because it has a return type of ‘{1}’.
The analyzer produces this diagnostic when a method or function returns a value whose type isn't assignable to the declared return type.
The following code produces this diagnostic because f has a return type of String but is returning an int:
{% prettify dart tag=pre+code %} String f() => [!3!]; {% endprettify %}
If the return type is correct, then replace the value being returned with a value of the correct type, possibly by converting the existing value:
{% prettify dart tag=pre+code %} String f() => 3.toString(); {% endprettify %}
If the value is correct, then change the return type to match:
{% prettify dart tag=pre+code %} int f() => 3; {% endprettify %}
The return type ‘{0}’ isn‘t a ‘{1}’, as required by the closure’s context.
The analyzer produces this diagnostic when the static type of a returned expression isn't assignable to the return type that the closure is required to have.
The following code produces this diagnostic because f is defined to be a function that returns a String, but the closure assigned to it returns an int:
{% prettify dart tag=pre+code %} String Function(String) f = (s) => [!3!]; {% endprettify %}
If the return type is correct, then replace the returned value with a value of the correct type, possibly by converting the existing value:
{% prettify dart tag=pre+code %} String Function(String) f = (s) => 3.toString(); {% endprettify %}
The return value is missing after ‘return’.
The analyzer produces this diagnostic when it finds a return statement without an expression in a function that declares a return type.
The following code produces this diagnostic because the function f is expected to return an int, but no value is being returned:
{% prettify dart tag=pre+code %} int f() { [!return!]; } {% endprettify %}
Add an expression that computes the value to be returned:
{% prettify dart tag=pre+code %} int f() { return 0; } {% endprettify %}
The class ‘{0}’ wasn't exported from ‘dart:core’ until version 2.1, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when either the class Future or Stream is referenced in a library that doesn‘t import dart:async in code that has an SDK constraint whose lower bound is less than 2.1.0. In earlier versions, these classes weren’t defined in dart:core, so the import was necessary.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.1.0:
environment: sdk: '>=2.0.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} void f([!Future!] f) {} {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the classes to be referenced:
environment: sdk: '>=2.1.0 <2.4.0'
If you need to support older versions of the SDK, then import the dart:async library.
{% prettify dart tag=pre+code %} import ‘dart:async’;
void f(Future f) {} {% endprettify %}
The use of an as expression in a constant expression wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when an as expression inside a constant context is found in code that has an SDK constraint whose lower bound is less than 2.3.2. Using an as expression in a constant context wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.3.2:
environment: sdk: '>=2.1.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} const num n = 3; const int i = [!n as int!]; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the expression to be used:
environment: sdk: '>=2.3.2 <2.4.0'
If you need to support older versions of the SDK, then either rewrite the code to not use an as expression, or change the code so that the as expression isn't in a constant context:
{% prettify dart tag=pre+code %} num x = 3; int y = x as int; {% endprettify %}
The use of the operator ‘{0}’ for ‘bool’ operands in a constant context wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when any use of the &, |, or ^ operators on the class bool inside a constant context is found in code that has an SDK constraint whose lower bound is less than 2.3.2. Using these operators in a constant context wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.3.2:
environment: sdk: '>=2.1.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} const bool a = true; const bool b = false; const bool c = a [!&!] b; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the operators to be used:
environment: sdk: '>=2.3.2 <2.4.0'
If you need to support older versions of the SDK, then either rewrite the code to not use these operators, or change the code so that the expression isn't in a constant context:
{% prettify dart tag=pre+code %} const bool a = true; const bool b = false; bool c = a & b; {% endprettify %}
Using the operator ‘==’ for non-primitive types wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when the operator == is used on a non-primitive type inside a constant context is found in code that has an SDK constraint whose lower bound is less than 2.3.2. Using this operator in a constant context wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.3.2:
environment: sdk: '>=2.1.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} class C {} const C a = null; const C b = null; const bool same = a [!==!] b; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the operator to be used:
environment: sdk: '>=2.3.2 <2.4.0'
If you need to support older versions of the SDK, then either rewrite the code to not use the == operator, or change the code so that the expression isn't in a constant context:
{% prettify dart tag=pre+code %} class C {} const C a = null; const C b = null; bool same = a == b; {% endprettify %}
Extension methods weren't supported until version 2.6.0, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when an extension declaration or an extension override is found in code that has an SDK constraint whose lower bound is less than 2.6.0. Using extensions wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.6.0:
environment: sdk: '>=2.4.0 <2.7.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} [!extension!] E on String { void sayHello() { print(‘Hello $this’); } } {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the syntax to be used:
environment: sdk: '>=2.6.0 <2.7.0'
If you need to support older versions of the SDK, then rewrite the code to not make use of extensions. The most common way to do this is to rewrite the members of the extension as top-level functions (or methods) that take the value that would have been bound to this as a parameter:
{% prettify dart tag=pre+code %} void sayHello(String s) { print(‘Hello $s’); } {% endprettify %}
The use of an is expression in a constant context wasn't supported until version 2.3.2, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when an is expression inside a constant context is found in code that has an SDK constraint whose lower bound is less than 2.3.2. Using an is expression in a constant context wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.3.2:
environment: sdk: '>=2.1.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} const x = 4; const y = [!x is int!] ? 0 : 1; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the expression to be used:
environment: sdk: '>=2.3.2 <2.4.0'
If you need to support older versions of the SDK, then either rewrite the code to not use the is operator, or, if that isn‘t possible, change the code so that the is expression isn’t in a constant context:
{% prettify dart tag=pre+code %} const x = 4; var y = x is int ? 0 : 1; {% endprettify %}
Set literals weren't supported until version 2.2, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when a set literal is found in code that has an SDK constraint whose lower bound is less than 2.2.0. Set literals weren‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.2.0:
environment: sdk: '>=2.1.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} var s = [!{}!]; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the syntax to be used:
environment: sdk: '>=2.2.0 <2.4.0'
If you do need to support older versions of the SDK, then replace the set literal with code that creates the set without the use of a literal:
{% prettify dart tag=pre+code %} var s = new Set(); {% endprettify %}
The for, if, and spread elements weren't supported until version 2.3.0, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when a for, if, or spread element is found in code that has an SDK constraint whose lower bound is less than 2.3.0. Using a for, if, or spread element wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.3.0:
environment: sdk: '>=2.2.0 <2.4.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} var digits = [[!for (int i = 0; i < 10; i++) i!]]; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the syntax to be used:
environment: sdk: '>=2.3.0 <2.4.0'
If you need to support older versions of the SDK, then rewrite the code to not make use of those elements:
{% prettify dart tag=pre+code %} var digits = _initializeDigits();
List _initializeDigits() { var digits = []; for (int i = 0; i < 10; i++) { digits.add(i); } return digits; } {% endprettify %}
The if and spread elements weren't supported in constant expressions until version 2.5.0, but this code is required to be able to run on earlier versions.
The analyzer produces this diagnostic when an if or spread element inside a constant context is found in code that has an SDK constraint whose lower bound is less than 2.5.0. Using an if or spread element inside a constant context wasn‘t supported in earlier versions, so this code won’t be able to run against earlier versions of the SDK.
Here's an example of a pubspec that defines an SDK constraint with a lower bound of less than 2.5.0:
environment: sdk: '>=2.4.0 <2.6.0'
In the package that has that pubspec, code like the following produces this diagnostic:
{% prettify dart tag=pre+code %} const a = [1, 2]; const b = [[!...a!]]; {% endprettify %}
If you don't need to support older versions of the SDK, then you can increase the SDK constraint to allow the syntax to be used:
environment: sdk: '>=2.5.0 <2.6.0'
If you need to support older versions of the SDK, then rewrite the code to not make use of those elements:
{% prettify dart tag=pre+code %} const a = [1, 2]; const b = [1, 2]; {% endprettify %}
If that isn‘t possible, change the code so that the element isn’t in a constant context:
{% prettify dart tag=pre+code %} const a = [1, 2]; var b = [...a]; {% endprettify %}
Instance member ‘{0}’ can't be accessed using static access.
The analyzer produces this diagnostic when a class name is used to access an instance field. Instance fields don't exist on a class; they exist only on an instance of the class.
The following code produces this diagnostic because x is an instance field:
{% prettify dart tag=pre+code %} class C { static int a;
int b; }
int f() => C.[!b!]; {% endprettify %}
If you intend to access a static field, then change the name of the field to an existing static field:
{% prettify dart tag=pre+code %} class C { static int a;
int b; }
int f() => C.a; {% endprettify %}
If you intend to access the instance field, then use an instance of the class to access the field:
{% prettify dart tag=pre+code %} class C { static int a;
int b; }
int f(C c) => c.b; {% endprettify %}
The ‘super’ keyword can‘t be used in an extension because an extension doesn’t have a superclass.
The analyzer produces this diagnostic when a member declared inside an extension uses the super keyword . Extensions aren‘t classes and don’t have superclasses, so the super keyword serves no purpose.
The following code produces this diagnostic because super can't be used in an extension:
{% prettify dart tag=pre+code %} extension E on Object { String get displayString => [!super!].toString(); } {% endprettify %}
Remove the super keyword :
{% prettify dart tag=pre+code %} extension E on Object { String get displayString => toString(); } {% endprettify %}
Invalid context for ‘super’ invocation.
The analyzer produces this diagnostic when the keyword super is used outside of a instance method.
The following code produces this diagnostic because super is used in a top-level function:
{% prettify dart tag=pre+code %} void f() { [!super!].f(); } {% endprettify %}
Rewrite the code to not use super.
Type ‘{0}’ of the switch expression isn't assignable to the type ‘{1}’ of case expressions.
The analyzer produces this diagnostic when the type of the expression in a switch statement isn't assignable to the type of the expressions in the case clauses.
The following code produces this diagnostic because the type of s (String) isn't assignable to the type of 0 (int):
{% prettify dart tag=pre+code %} void f(String s) { switch ([!s!]) { case 0: break; } } {% endprettify %}
If the type of the case expressions is correct, then change the expression in the switch statement to have the correct type:
{% prettify dart tag=pre+code %} void f(String s) { switch (int.parse(s)) { case 0: break; } } {% endprettify %}
If the type of the switch expression is correct, then change the case expressions to have the correct type:
{% prettify dart tag=pre+code %} void f(String s) { switch (s) { case ‘0’: break; } } {% endprettify %}
The type ‘{0}’ of the thrown expression must be assignable to ‘Object’.
The analyzer produces this diagnostic when the type of the expression in a throw expression isn‘t assignable to Object. It isn’t valid to throw null, so it isn't valid to use an expression that might evaluate to null.
The following code produces this diagnostic because s might be null:
{% prettify dart tag=pre+code %} void f(String? s) { throw [!s!]; } {% endprettify %}
Add an explicit null check to the expression:
{% prettify dart tag=pre+code %} void f(String? s) { throw s!; } {% endprettify %}
‘{0}’ doesn't extend ‘{1}’.
The analyzer produces this diagnostic when a type argument isn't the same as or a subclass of the bounds of the corresponding type parameter.
The following code produces this diagnostic because String isn't a subclass of num:
{% prettify dart tag=pre+code %} class A {}
var a = A<[!String!]>(); {% endprettify %}
Change the type argument to be a subclass of the bounds:
{% prettify dart tag=pre+code %} class A {}
var a = A(); {% endprettify %}
The name ‘{0}’ isn‘t defined, so it can’t be used in an ‘is’ expression.
The analyzer produces this diagnostic when the name following the is in a type test expression isn't defined.
The following code produces this diagnostic because the name Srting isn't defined:
{% prettify dart tag=pre+code %} void f(Object o) { if (o is [!Srting!]) { // ... } } {% endprettify %}
Replace the name with the name of a type:
{% prettify dart tag=pre+code %} void f(Object o) { if (o is String) { // ... } } {% endprettify %}
An expression whose value can be ‘null’ must be null-checked before it can be dereferenced.
The analyzer produces this diagnostic when an expression whose type is potentially non-nullable is dereferenced without first verifying that the value isn't null.
The following code produces this diagnostic because s can be null at the point where it's referenced:
{% prettify dart tag=pre+code %} void f(String? s) { if ([!s!].length > 3) { // ... } } {% endprettify %}
If the value really can be null, then add a test to ensure that members are only accessed when the value isn't null:
{% prettify dart tag=pre+code %} void f(String? s) { if (s != null && s.length > 3) { // ... } } {% endprettify %}
If the expression is a variable and the value should never be null, then change the type of the variable to be non-nullable:
{% prettify dart tag=pre+code %} void f(String s) { if (s.length > 3) { // ... } } {% endprettify %}
If you believe that the value of the expression should never be null, but you can‘t change the type of the variable, and you’re willing to risk having an exception thrown at runtime if you‘re wrong, then you can assert that the value isn’t null:
{% prettify dart tag=pre+code %} void f(String? s) { if (s!.length > 3) { // ... } } {% endprettify %}
Undefined name ‘{0}’ used as an annotation.
The analyzer produces this diagnostic when a name that isn't defined is used as an annotation.
The following code produces this diagnostic because the name undefined isn't defined:
{% prettify dart tag=pre+code %} [!@undefined!] void f() {} {% endprettify %}
If the name is correct, but it isn’t declared yet, then declare the name as a constant value:
{% prettify dart tag=pre+code %} const undefined = ‘undefined’;
@undefined void f() {} {% endprettify %}
If the name is wrong, replace the name with the name of a valid constant:
{% prettify dart tag=pre+code %} @deprecated void f() {} {% endprettify %}
Otherwise, remove the annotation.
Undefined class ‘{0}’.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of a class but either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because Piont isn't defined:
{% prettify dart tag=pre+code %} class Point {}
void f([!Piont!] p) {} {% endprettify %}
If the identifier isn't defined, then either define it or replace it with the name of a class that is defined. The example above can be corrected by fixing the spelling of the class:
{% prettify dart tag=pre+code %} class Point {}
void f(Point p) {} {% endprettify %}
If the class is defined but isn't visible, then you probably need to add an import.
The class ‘{0}’ doesn't have a constructor named ‘{1}’.
The class ‘{0}’ doesn't have an unnamed constructor.
The analyzer produces this diagnostic when a superclass constructor is invoked in the initializer list of a constructor, but the superclass doesn't define the constructor being invoked.
The following code produces this diagnostic because A doesn't have an unnamed constructor:
{% prettify dart tag=pre+code %} class A { A.n(); } class B extends A { B() : [!super()!]; } {% endprettify %}
The following code produces this diagnostic because A doesn't have a constructor named m:
{% prettify dart tag=pre+code %} class A { A.n(); } class B extends A { B() : [!super.m()!]; } {% endprettify %}
If the superclass defines a constructor that should be invoked, then change the constructor being invoked:
{% prettify dart tag=pre+code %} class A { A.n(); } class B extends A { B() : super.n(); } {% endprettify %}
If the superclass doesn't define an appropriate constructor, then define the constructor being invoked:
{% prettify dart tag=pre+code %} class A { A.m(); A.n(); } class B extends A { B() : super.m(); } {% endprettify %}
There's no constant named ‘{0}’ in ‘{1}’.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of an enum constant, and the name either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because E doesn't define a constant named c:
{% prettify dart tag=pre+code %} enum E {a, b}
var e = E.[!c!]; {% endprettify %}
If the constant should be defined, then add it to the declaration of the enum:
{% prettify dart tag=pre+code %} enum E {a, b, c}
var e = E.c; {% endprettify %}
If the constant shouldn't be defined, then change the name to the name of an existing constant:
{% prettify dart tag=pre+code %} enum E {a, b}
var e = E.b; {% endprettify %}
The getter ‘{0}’ isn't defined for the extension ‘{1}’.
The analyzer produces this diagnostic when an extension override is used to invoke a getter, but the getter isn‘t defined by the specified extension. The analyzer also produces this diagnostic when a static getter is referenced but isn’t defined by the specified extension.
The following code produces this diagnostic because the extension E doesn't declare an instance getter named b:
{% prettify dart tag=pre+code %} extension E on String { String get a => ‘a’; }
extension F on String { String get b => ‘b’; }
void f() { E(‘c’).[!b!]; } {% endprettify %}
The following code produces this diagnostic because the extension E doesn't declare a static getter named a:
{% prettify dart tag=pre+code %} extension E on String {}
var x = E.[!a!]; {% endprettify %}
If the name of the getter is incorrect, then change it to the name of an existing getter:
{% prettify dart tag=pre+code %} extension E on String { String get a => ‘a’; }
extension F on String { String get b => ‘b’; }
void f() { E(‘c’).a; } {% endprettify %}
If the name of the getter is correct but the name of the extension is wrong, then change the name of the extension to the correct name:
{% prettify dart tag=pre+code %} extension E on String { String get a => ‘a’; }
extension F on String { String get b => ‘b’; }
void f() { F(‘c’).b; } {% endprettify %}
If the name of the getter and extension are both correct, but the getter isn't defined, then define the getter:
{% prettify dart tag=pre+code %} extension E on String { String get a => ‘a’; String get b => ‘z’; }
extension F on String { String get b => ‘b’; }
void f() { E(‘c’).b; } {% endprettify %}
The method ‘{0}’ isn't defined for the extension ‘{1}’.
The analyzer produces this diagnostic when an extension override is used to invoke a method, but the method isn‘t defined by the specified extension. The analyzer also produces this diagnostic when a static method is referenced but isn’t defined by the specified extension.
The following code produces this diagnostic because the extension E doesn't declare an instance method named b:
{% prettify dart tag=pre+code %} extension E on String { String a() => ‘a’; }
extension F on String { String b() => ‘b’; }
void f() { E(‘c’).!b!; } {% endprettify %}
The following code produces this diagnostic because the extension E doesn't declare a static method named a:
{% prettify dart tag=pre+code %} extension E on String {}
var x = E.!a!; {% endprettify %}
If the name of the method is incorrect, then change it to the name of an existing method:
{% prettify dart tag=pre+code %} extension E on String { String a() => ‘a’; }
extension F on String { String b() => ‘b’; }
void f() { E(‘c’).a(); } {% endprettify %}
If the name of the method is correct, but the name of the extension is wrong, then change the name of the extension to the correct name:
{% prettify dart tag=pre+code %} extension E on String { String a() => ‘a’; }
extension F on String { String b() => ‘b’; }
void f() { F(‘c’).b(); } {% endprettify %}
If the name of the method and extension are both correct, but the method isn't defined, then define the method:
{% prettify dart tag=pre+code %} extension E on String { String a() => ‘a’; String b() => ‘z’; }
extension F on String { String b() => ‘b’; }
void f() { E(‘c’).b(); } {% endprettify %}
The setter ‘{0}’ isn't defined for the extension ‘{1}’.
The analyzer produces this diagnostic when an extension override is used to invoke a setter, but the setter isn‘t defined by the specified extension. The analyzer also produces this diagnostic when a static setter is referenced but isn’t defined by the specified extension.
The following code produces this diagnostic because the extension E doesn't declare an instance setter named b:
{% prettify dart tag=pre+code %} extension E on String { set a(String v) {} }
extension F on String { set b(String v) {} }
void f() { E(‘c’).[!b!] = ‘d’; } {% endprettify %}
The following code produces this diagnostic because the extension E doesn't declare a static setter named a:
{% prettify dart tag=pre+code %} extension E on String {}
void f() { E.[!a!] = 3; } {% endprettify %}
If the name of the setter is incorrect, then change it to the name of an existing setter:
{% prettify dart tag=pre+code %} extension E on String { set a(String v) {} }
extension F on String { set b(String v) {} }
void f() { E(‘c’).a = ‘d’; } {% endprettify %}
If the name of the setter is correct, but the name of the extension is wrong, then change the name of the extension to the correct name:
{% prettify dart tag=pre+code %} extension E on String { set a(String v) {} }
extension F on String { set b(String v) {} }
void f() { F(‘c’).b = ‘d’; } {% endprettify %}
If the name of the setter and extension are both correct, but the setter isn't defined, then define the setter:
{% prettify dart tag=pre+code %} extension E on String { set a(String v) {} set b(String v) {} }
extension F on String { set b(String v) {} }
void f() { E(‘c’).b = ‘d’; } {% endprettify %}
The function ‘{0}’ isn't defined.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of a function but either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because the name emty isn't defined:
{% prettify dart tag=pre+code %} List empty() => [];
void main() { print(!emty!); } {% endprettify %}
If the identifier isn't defined, then either define it or replace it with the name of a function that is defined. The example above can be corrected by fixing the spelling of the function:
{% prettify dart tag=pre+code %} List empty() => [];
void main() { print(empty()); } {% endprettify %}
If the function is defined but isn't visible, then you probably need to add an import or re-arrange your code to make the function visible.
The getter ‘{0}’ isn't defined for the type ‘{1}’.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of a getter but either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because String has no member named len:
{% prettify dart tag=pre+code %} int f(String s) => s.[!len!]; {% endprettify %}
If the identifier isn't defined, then either define it or replace it with the name of a getter that is defined. The example above can be corrected by fixing the spelling of the getter:
{% prettify dart tag=pre+code %} int f(String s) => s.length; {% endprettify %}
The library ‘{0}’ doesn't export a member with the hidden name ‘{1}’.
The analyzer produces this diagnostic when a hide combinator includes a name that isn't defined by the library being imported.
The following code produces this diagnostic because dart:math doesn't define the name String:
{% prettify dart tag=pre+code %} import ‘dart:math’ hide [!String!], max;
var x = min(0, 1); {% endprettify %}
If a different name should be hidden, then correct the name. Otherwise, remove the name from the list:
{% prettify dart tag=pre+code %} import ‘dart:math’ hide max;
var x = min(0, 1); {% endprettify %}
Undefined name ‘{0}’.
The analyzer produces this diagnostic when it encounters an identifier that either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because the name rihgt isn't defined:
{% prettify dart tag=pre+code %} int min(int left, int right) => left <= [!rihgt!] ? left : right; {% endprettify %}
If the identifier isn't defined, then either define it or replace it with an identifier that is defined. The example above can be corrected by fixing the spelling of the variable:
{% prettify dart tag=pre+code %} int min(int left, int right) => left <= right ? left : right; {% endprettify %}
If the identifier is defined but isn't visible, then you probably need to add an import or re-arrange your code to make the identifier visible.
Undefined name ‘await’ in function body not marked with ‘async’.
The analyzer produces this diagnostic when the name await is used in a method or function body without being declared, and the body isn't marked with the async keyword. The name await only introduces an await expression in an asynchronous function.
The following code produces this diagnostic because the name await is used in the body of f even though the body of f isn't marked with the async keyword:
{% prettify dart tag=pre+code %} void f(p) { [!await!] p; } {% endprettify %}
Add the keyword async to the function body:
{% prettify dart tag=pre+code %} void f(p) async { await p; } {% endprettify %}
The method ‘{0}’ isn't defined for the type ‘{1}’.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of a method but either isn‘t defined or isn’t visible in the scope in which it's being referenced.
The following code produces this diagnostic because the identifier removeMiddle isn't defined:
{% prettify dart tag=pre+code %} int f(List l) => l.!removeMiddle!; {% endprettify %}
If the identifier isn't defined, then either define it or replace it with the name of a method that is defined. The example above can be corrected by fixing the spelling of the method:
{% prettify dart tag=pre+code %} int f(List l) => l.removeLast(); {% endprettify %}
The named parameter ‘{0}’ isn't defined.
The analyzer produces this diagnostic when a method or function invocation has a named argument, but the method or function being invoked doesn't define a parameter with the same name.
The following code produces this diagnostic because m doesn't declare a named parameter named a:
{% prettify dart tag=pre+code %} class C { m({int b}) {} }
void f(C c) { c.m([!a!]: 1); } {% endprettify %}
If the argument name is mistyped, then replace it with the correct name. The example above can be fixed by changing a to b:
{% prettify dart tag=pre+code %} class C { m({int b}) {} }
void f(C c) { c.m(b: 1); } {% endprettify %}
If a subclass adds a parameter with the name in question, then cast the receiver to the subclass:
{% prettify dart tag=pre+code %} class C { m({int b}) {} }
class D extends C { m({int a, int b}) {} }
void f(C c) { (c as D).m(a: 1); } {% endprettify %}
If the parameter should be added to the function, then add it:
{% prettify dart tag=pre+code %} class C { m({int a, int b}) {} }
void f(C c) { c.m(a: 1); } {% endprettify %}
The operator ‘{0}’ isn't defined for the type ‘{1}’.
The analyzer produces this diagnostic when a user-definable operator is invoked on an object for which the operator isn't defined.
The following code produces this diagnostic because the class C doesn't define the operator +:
{% prettify dart tag=pre+code %} class C {}
C f(C c) => c [!+!] 2; {% endprettify %}
If the operator should be defined for the class, then define it:
{% prettify dart tag=pre+code %} class C { C operator +(int i) => this; }
C f(C c) => c + 2; {% endprettify %}
The name ‘{0}’ is being referenced through the prefix ‘{1}’, but it isn't defined in any of the libraries imported using that prefix.
The analyzer produces this diagnostic when a prefixed identifier is found where the prefix is valid, but the identifier isn't declared in any of the libraries imported using that prefix.
The following code produces this diagnostic because dart:core doesn't define anything named a:
{% prettify dart tag=pre+code %} import ‘dart:core’ as p;
void f() { p.[!a!]; } {% endprettify %}
If the library in which the name is declared isn't imported yet, add an import for the library.
If the name is wrong, then change it to one of the names that's declared in the imported libraries.
The setter ‘{0}’ isn't defined for the type ‘{1}’.
The analyzer produces this diagnostic when it encounters an identifier that appears to be the name of a setter but either isn‘t defined or isn’t visible in the scope in which the identifier is being referenced.
The following code produces this diagnostic because there isn't a setter named z:
{% prettify dart tag=pre+code %} class C { int x = 0; void m(int y) { this.[!z!] = y; } } {% endprettify %}
If the identifier isn't defined, then either define it or replace it with the name of a setter that is defined. The example above can be corrected by fixing the spelling of the setter:
{% prettify dart tag=pre+code %} class C { int x = 0; void m(int y) { this.x = y; } } {% endprettify %}
The library ‘{0}’ doesn't export a member with the shown name ‘{1}’.
The analyzer produces this diagnostic when a show combinator includes a name that isn't defined by the library being imported.
The following code produces this diagnostic because dart:math doesn't define the name String:
{% prettify dart tag=pre+code %} import ‘dart:math’ show min, [!String!];
var x = min(0, 1); {% endprettify %}
If a different name should be shown, then correct the name. Otherwise, remove the name from the list:
{% prettify dart tag=pre+code %} import ‘dart:math’ show min;
var x = min(0, 1); {% endprettify %}
The getter ‘{0}’ isn't defined in a superclass of ‘{1}’.
The method ‘{0}’ isn't defined in a superclass of ‘{1}’.
The operator ‘{0}’ isn't defined in a superclass of ‘{1}’.
The setter ‘{0}’ isn't defined in a superclass of ‘{1}’.
The analyzer produces this diagnostic when an inherited member is referenced using super, but there’s no member with that name in the superclass chain.
The following code produces this diagnostic because Object doesn't define a method named n:
{% prettify dart tag=pre+code %} class C { void m() { super.!n!; } } {% endprettify %}
The following code produces this diagnostic because Object doesn't define a getter named g:
{% prettify dart tag=pre+code %} class C { void m() { super.[!g!]; } } {% endprettify %}
If the inherited member you intend to invoke has a different name, then make the name of the invoked member match the inherited member.
If the member you intend to invoke is defined in the same class, then remove the super..
If not, then either add the member to one of the superclasses or remove the invocation.
Unnecessary cast.
The analyzer produces this diagnostic when the value being cast is already known to be of the type that it's being cast to.
The following code produces this diagnostic because n is already known to be an int as a result of the is test:
{% prettify dart tag=pre+code %} void f(num n) { if (n is int) { ([!n as int!]).isEven; } } {% endprettify %}
Remove the unnecessary cast:
{% prettify dart tag=pre+code %} void f(num n) { if (n is int) { n.isEven; } } {% endprettify %}
The ‘!’ will have no effect because the receiver can't be null.
The analyzer produces this diagnostic when the operand of the ! operator can't be null.
The following code produces this diagnostic because x can't be null:
{% prettify dart tag=pre+code %} int f(int x) { return x[!!!]; } {% endprettify %}
Remove the null check operator (!):
{% prettify dart tag=pre+code %} int f(int x) { return x; } {% endprettify %}
The operand can't be null, so the condition is always false.
The operand can't be null, so the condition is always true.
The analyzer produces this diagnostic when it finds an equality comparison (either == or !=) with one operand of null and the other operand can't be null. Such comparisons are always either true or false, so they serve no purpose.
The following code produces this diagnostic because x can never be null, so the comparison always evaluates to true:
{% prettify dart tag=pre+code %} void f(int x) { if (x [!!= null!]) { print(x); } } {% endprettify %}
The following code produces this diagnostic because x can never be null, so the comparison always evaluates to false:
{% prettify dart tag=pre+code %} void f(int x) { if (x [!== null!]) { throw ArgumentError(“x can't be null”); } } {% endprettify %}
If the other operand should be able to be null, then change the type of the operand:
{% prettify dart tag=pre+code %} void f(int? x) { if (x != null) { print(x); } } {% endprettify %}
If the other operand really can't be null, then remove the condition:
{% prettify dart tag=pre+code %} void f(int x) { print(x); } {% endprettify %}
Static members from the extended type or one of its superclasses must be qualified by the name of the defining type.
The analyzer produces this diagnostic when an undefined name is found, and the name is the same as a static member of the extended type or one of its superclasses.
The following code produces this diagnostic because m is a static member of the extended type C:
{% prettify dart tag=pre+code %} class C { static void m() {} }
extension E on C { void f() { !m!; } } {% endprettify %}
If you‘re trying to reference a static member that’s declared outside the extension, then add the name of the class or extension before the reference to the member:
{% prettify dart tag=pre+code %} class C { static void m() {} }
extension E on C { void f() { C.m(); } } {% endprettify %}
If you‘re referencing a member that isn’t declared yet, add a declaration:
{% prettify dart tag=pre+code %} class C { static void m() {} }
extension E on C { void f() { m(); }
void m() {} } {% endprettify %}
The exception variable ‘{0}’ isn't used, so the ‘catch’ clause can be removed.
The analyzer produces this diagnostic when a catch clause is found, and neither the exception parameter nor the optional stack trace parameter are used in the catch block.
The following code produces this diagnostic because e isn't referenced:
{% prettify dart tag=pre+code %} void f() { try { int.parse(‘;’); } on FormatException catch ([!e!]) { // ignored } } {% endprettify %}
Remove the unused catch clause:
{% prettify dart tag=pre+code %} void f() { try { int.parse(‘;’); } on FormatException { // ignored } } {% endprettify %}
The stack trace variable ‘{0}’ isn't used and can be removed.
The analyzer produces this diagnostic when the stack trace parameter in a catch clause isn't referenced within the body of the catch block.
The following code produces this diagnostic because stackTrace isn't referenced:
{% prettify dart tag=pre+code %} void f() { try { // ... } catch (exception, [!stackTrace!]) { // ... } } {% endprettify %}
If you need to reference the stack trace parameter, then add a reference to it. Otherwise, remove it:
{% prettify dart tag=pre+code %} void f() { try { // ... } catch (exception) { // ... } } {% endprettify %}
A value for optional parameter ‘{0}’ isn't ever given.
The declaration ‘{0}’ isn't referenced.
The analyzer produces this diagnostic when a private class, enum, mixin, typedef, top level variable, top level function, or method is declared but never referenced.
Assuming that no code in the library references _C, the following code produces this diagnostic:
{% prettify dart tag=pre+code %} class [!_C!] {} {% endprettify %}
If the declaration isn't needed, then remove it.
If the declaration was intended to be used, then add the missing code.
The value of the field ‘{0}’ isn't used.
The analyzer produces this diagnostic when a private field is declared but never read, even if it's written in one or more places.
The following code produces this diagnostic because _x isn't referenced anywhere in the library:
{% prettify dart tag=pre+code %} class Point { int [!_x!]; } {% endprettify %}
If the field isn't needed, then remove it.
If the field was intended to be used, then add the missing code.
Unused import: ‘{0}’.
The analyzer produces this diagnostic when an import isn't needed because none of the names that are imported are referenced within the importing library.
The following code produces this diagnostic because nothing defined in dart:async is referenced in the library:
{% prettify dart tag=pre+code %} import [!‘dart:async’!];
void main() {} {% endprettify %}
If the import isn't needed, then remove it.
If some of the imported names are intended to be used, then add the missing code.
The label ‘{0}’ isn't used.
The analyzer produces this diagnostic when a label that isn't used is found.
The following code produces this diagnostic because the label loop isn't referenced anywhere in the method:
{% prettify dart tag=pre+code %} void f(int limit) { [!loop:!] for (int i = 0; i < limit; i++) { print(i); } } {% endprettify %}
If the label isn't needed, then remove it:
{% prettify dart tag=pre+code %} void f(int limit) { for (int i = 0; i < limit; i++) { print(i); } } {% endprettify %}
If the label is needed, then use it:
{% prettify dart tag=pre+code %} void f(int limit) { loop: for (int i = 0; i < limit; i++) { print(i); break loop; } } {% endprettify %}
The value of the local variable ‘{0}’ isn't used.
The analyzer produces this diagnostic when a local variable is declared but never read, even if it's written in one or more places.
The following code produces this diagnostic because the value of count is never read:
{% prettify dart tag=pre+code %} void main() { int [!count!] = 0; } {% endprettify %}
If the variable isn't needed, then remove it.
If the variable was intended to be used, then add the missing code.
The name {0} is shown, but isn’t used.
The analyzer produces this diagnostic when a show combinator includes a name that isn‘t used within the library. Because it isn’t referenced, the name can be removed.
The following code produces this diagnostic because the function max isn't used:
{% prettify dart tag=pre+code %} import ‘dart:math’ show min, [!max!];
var x = min(0, 1); {% endprettify %}
Either use the name or remove it:
{% prettify dart tag=pre+code %} import ‘dart:math’ show min;
var x = min(0, 1); {% endprettify %}
Target of URI doesn't exist: ‘{0}’.
The analyzer produces this diagnostic when an import, export, or part directive is found where the URI refers to a file that doesn't exist.
If the file lib.dart doesn't exist, the following code produces this diagnostic:
{% prettify dart tag=pre+code %} import [!‘lib.dart’!]; {% endprettify %}
If the URI was mistyped or invalid, then correct the URI.
If the URI is correct, then create the file.
Target of URI hasn't been generated: ‘{0}’.
The analyzer produces this diagnostic when an import, export, or part directive is found where the URI refers to a file that doesn‘t exist and the name of the file ends with a pattern that’s commonly produced by code generators, such as one of the following:
.g.dart.pb.dart.pbenum.dart.pbserver.dart.pbjson.dart.template.dartIf the file lib.g.dart doesn't exist, the following code produces this diagnostic:
{% prettify dart tag=pre+code %} import [!‘lib.g.dart’!]; {% endprettify %}
If the file is a generated file, then run the generator that generates the file.
If the file isn't a generated file, then check the spelling of the URI or create the file.
This expression has a type of ‘void’ so its value can't be used.
The analyzer produces this diagnostic when it finds an expression whose type is void, and the expression is used in a place where a value is expected, such as before a member access or on the right-hand side of an assignment.
The following code produces this diagnostic because f doesn't produce an object on which toString can be invoked:
{% prettify dart tag=pre+code %} void f() {}
void g() { [!f()!].toString(); } {% endprettify %}
Either rewrite the code so that the expression has a value or rewrite the code so that it doesn't depend on the value.
A value of type ‘{0}’ can't be assigned to a const variable of type ‘{1}’.
The analyzer produces this diagnostic when the evaluation of a constant expression would result in a CastException.
The following code produces this diagnostic because the value of x is an int, which can‘t be assigned to y because an int isn’t a String:
{% prettify dart tag=pre+code %} const Object x = 0; const String y = [!x!]; {% endprettify %}
If the declaration of the constant is correct, then change the value being assigned to be of the correct type:
{% prettify dart tag=pre+code %} const Object x = 0; const String y = ‘$x’; {% endprettify %}
If the assigned value is correct, then change the declaration to have the correct type:
{% prettify dart tag=pre+code %} const Object x = 0; const int y = x; {% endprettify %}
Operator ‘{0}’ should declare exactly {1} parameters, but {2} found.
The analyzer produces this diagnostic when a declaration of an operator has the wrong number of parameters.
The following code produces this diagnostic because the operator + must have a single parameter corresponding to the right operand:
{% prettify dart tag=pre+code %} class C { int operator [!+!](a, b) => 0; } {% endprettify %}
Add or remove parameters to match the required number:
{% prettify dart tag=pre+code %} class C { int operator +(a) => 0; } {% endprettify %}
Setters must declare exactly one required positional parameter.
The analyzer produces this diagnostic when a setter is found that doesn't declare exactly one required positional parameter.
The following code produces this diagnostic because the setter s declares two required parameters:
{% prettify dart tag=pre+code %} class C { set [!s!](int x, int y) {} } {% endprettify %}
The following code produces this diagnostic because the setter s declares one optional parameter:
{% prettify dart tag=pre+code %} class C { set [!s!]([int x]) {} } {% endprettify %}
Change the declaration so that there's exactly one required positional parameter:
{% prettify dart tag=pre+code %} class C { set s(int x) {} } {% endprettify %}
The type ‘{0}’ is declared with {1} type parameters, but {2} type arguments were given.
The analyzer produces this diagnostic when a type that has type parameters is used and type arguments are provided, but the number of type arguments isn't the same as the number of type parameters.
The analyzer also produces this diagnostic when a constructor is invoked and the number of type arguments doesn't match the number of type parameters declared for the class.
The following code produces this diagnostic because C has one type parameter but two type arguments are provided when it is used as a type annotation:
{% prettify dart tag=pre+code %} class C {}
void f([!C<int, int>!] x) {} {% endprettify %}
The following code produces this diagnostic because C declares one type parameter, but two type arguments are provided when creating an instance:
{% prettify dart tag=pre+code %} class C {}
var c = !C<int, int>!; {% endprettify %}
Add or remove type arguments, as necessary, to match the number of type parameters defined for the type:
{% prettify dart tag=pre+code %} class C {}
void f(C x) {} {% endprettify %}