sdk/pkg/analyzer/tool/diagnostics/diagnostics.md

title, description

title	description
Diagnostic messages	Details for diagnostics produced by the Dart analyzer.

{%- 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.

Glossary

This page uses the following terms:

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

Constant context

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

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

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

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

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

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

  const v = /*constant context*/;
  

• Annotations

• The expression in a case clause. Example:

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

Definite assignment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For additional details, see the specification of definite assignment.

Mixin application

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

class A {}

mixin M {}

class B extends A with M {}

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

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

class A {}

mixin M {}

class A_M = A with M;

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

class B extends A_M {}

Override inference

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

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

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

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

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

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

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

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

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

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

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

Part file

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

Potentially non-nullable

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

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

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

Public library

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

Diagnostics

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

abi_specific_integer_invalid

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

Description

The analyzer produces this diagnostic when a class that extends AbiSpecificInteger doesn't meet all of the following requirements:

• there must be exactly one constructor
• the constructor must be marked const
• there must not be any members of other than the one constructor
• there must not be any type parameters

Examples

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Common fixes

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

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

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

abi_specific_integer_mapping_extra

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

Description

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

Example

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

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

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

Common fixes

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

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

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

abi_specific_integer_mapping_missing

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

Description

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

Example

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

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

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

Common fixes

Add an AbiSpecificIntegerMapping annotation to the class:

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

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

abi_specific_integer_mapping_unsupported

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

Description

The analyzer produces this diagnostic when a value in the map argument of an AbiSpecificIntegerMapping annotation is anything other than one of the following integer types:

• Int8
• Int16
• Int32
• Int64
• Uint8
• Uint16
• UInt32
• Uint64

Example

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

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

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

Common fixes

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

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

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

abstract_field_initializer

Abstract fields can't have initializers.

Description

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

Examples

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

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

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

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

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

Common fixes

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

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

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

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

abstract_super_member_reference

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

Description

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

Example

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

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

Common fixes

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

ambiguous_export

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

Description

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

Example

Given a file named a.dart containing

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

And a file named b.dart containing

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

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

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

Common fixes

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

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

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

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

ambiguous_extension_member_access

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

Description

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

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

Example

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

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

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

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

Common fixes

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

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

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

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

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

ambiguous_import

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

Description

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

Example

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

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

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

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

The following code produces this diagnostic:

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

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

Common fixes

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

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

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

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

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

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

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

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

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

ambiguous_set_or_map_literal_both

The literal can't be either a map or a set because it contains at least one literal map entry or a spread operator spreading a 'Map', and at least one element which is neither of these.

Description

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

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

Example

The following code produces this diagnostic:

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

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

Common fixes

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

{% prettify dart tag=pre+code %} union(Map<String, String> a, List 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 %}

ambiguous_set_or_map_literal_either

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

Description

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

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

Example

The following code produces this diagnostic:

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

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

Common fixes

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

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

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

{% prettify dart tag=pre+code %} union(List 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 %}

annotation_on_pointer_field

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

Description

The analyzer produces this diagnostic when a field that's declared in a subclass of Struct and has the type Pointer also has an annotation associated with it.

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

Example

The following code produces this diagnostic because the field p, which has the type Pointer and is declared in a subclass of Struct, has the annotation @Double():

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

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

Common fixes

Remove the annotations from the field:

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

class C extends Struct { external Pointer p; } {% endprettify %}

argument_must_be_a_constant

Argument '{0}' must be a constant.

Description

The analyzer produces this diagnostic when an invocation of either Pointer.asFunction or DynamicLibrary.lookupFunction has an isLeaf argument whose value isn't a constant expression.

The analyzer also produces this diagnostic when the value of the exceptionalReturn argument of Pointer.fromFunction.

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

Example

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

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

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

Common fixes

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

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

const isLeaf = false;

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

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

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

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

argument_type_not_assignable

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

Description

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

Example

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

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

Common fixes

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

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

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

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

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

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

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

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

argument_type_not_assignable_to_error_handler

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

Description

The analyzer produces this diagnostic when an invocation of Future.catchError has an argument that is a function whose parameters aren't compatible with the arguments that will be passed to the function when it's invoked. The static type of the first argument to catchError is just Function, even though the function that is passed in is expected to have either a single parameter of type Object or two parameters of type Object and StackTrace.

Examples

The following code produces this diagnostic because the closure being passed to catchError doesn't take any parameters, but the function is required to take at least one parameter:

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

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

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

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

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

Common fixes

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

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

assert_in_redirecting_constructor

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

Description

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

Example

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

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

Common fixes

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

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

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

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

asset_directory_does_not_exist

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

Description

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

Example

Assuming that the directory assets doesn't exist, the following code produces this diagnostic because it's listed as a directory containing assets:

name: example
flutter:
  assets:
    - assets/

Common fixes

If the path is correct, then create a directory at that path.

If the path isn't correct, then change the path to match the path of the directory containing the assets.

asset_does_not_exist

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

Description

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

Example

Assuming that the file doesNotExist.gif doesn't exist, the following code produces this diagnostic because it's listed as an asset:

name: example
flutter:
  assets:
    - doesNotExist.gif

Common fixes

If the path is correct, then create a file at that path.

If the path isn't correct, then change the path to match the path of the file containing the asset.

asset_field_not_list

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

Description

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

Example

The following code produces this diagnostic because the value of the assets key is a string when a list is expected:

name: example
flutter:
  assets: assets/

Common fixes

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

name: example
flutter:
  assets:
    - assets/

asset_not_string

Assets are required to be file paths (strings).

Description

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

Example

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

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

Common fixes

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

name: example
flutter:
  assets:
    - image.gif

assignment_of_do_not_store

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

Description

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

Example

The following code produces this diagnostic because the value of the function f is being stored in the top-level variable x:

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

@doNotStore int f() => 1;

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

Common fixes

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

assignment_to_const

Constant variables can't be assigned a value.

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

assignment_to_final

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

Description

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

Example

The following code produces this diagnostic because v is final:

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

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

Common fixes

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

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

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

assignment_to_final_local

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

Description

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

Example

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

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

Common fixes

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

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

assignment_to_final_no_setter

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

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

assignment_to_function

Functions can't be assigned a value.

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

assignment_to_method

Methods can't be assigned a value.

Description

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

Example

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

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

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

Common fixes

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

assignment_to_type

Types can't be assigned a value.

Description

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

Example

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

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

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

Common fixes

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

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

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

async_for_in_wrong_context

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

Description

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

Example

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

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

Common fixes

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

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

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

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

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

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

await_in_late_local_variable_initializer

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

Description

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

Example

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

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

Common fixes

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

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

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

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

body_might_complete_normally

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

Description

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

Examples

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

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

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

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

Common fixes

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

{% prettify dart tag=pre+code %} class C { T 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 add an explicit return of null at the end of the method and change the return type so that it's valid to return null:

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

body_might_complete_normally_nullable

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

Description

The analyzer produces this diagnostic when a method or function can implicitly return null by falling off the end. While this is valid Dart code, it's better for the return of null to be explicit.

Example

The following code produces this diagnostic because the function f implicitly returns null:

{% prettify dart tag=pre+code %} String? !f! {} {% endprettify %}

Common fixes

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

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

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

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

break_label_on_switch_member

A break label resolves to the 'case' or 'default' statement.

Description

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

Example

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

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

Common fixes

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

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

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

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

built_in_identifier_as_type

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

Description

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

Example

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

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

Common fixes

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

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

built_in_identifier_in_declaration

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

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

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

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

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

Description

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

Example

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

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

Common fixes

Choose a different name for the declaration.

case_block_not_terminated

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

Description

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

Example

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

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

Common fixes

Add one of the required terminators:

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

case_expression_type_implements_equals

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

Description

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

Example

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

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

const C(this.value);

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

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

Common fixes

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

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

const C(this.value);

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

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

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

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

const C(this.value); }

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

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

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

const C(this.value);

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

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

case_expression_type_is_not_switch_expression_subtype

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

Description

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

Example

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

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

Common fixes

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

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

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

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

cast_to_non_type

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

Description

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

Example

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

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

Common fixes

Replace the name with the name of a type:

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

collection_element_from_deferred_library

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

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

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

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

Description

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

For more information, see the language tour's coverage of deferred loading.

Example

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

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

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

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

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

Common fixes

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

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

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

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

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

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

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

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

compound_implements_finalizable

The class '{0}' can't implement Finalizable.

Description

The analyzer produces this diagnostic when a subclass of either Struct or Union implements Finalizable.

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

Example

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

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

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

Common fixes

Try removing the implements clause from the class:

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

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

concrete_class_has_enum_superinterface

Concrete classes can't have 'Enum' as a superinterface.

Description

The analyzer produces this diagnostic when a concrete class indirectly has the class Enum as a superinterface.

Example

The following code produces this diagnostic because the concrete class B has Enum as a superinterface as a result of implementing A:

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

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

Common fixes

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

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

class B implements C {}

class C {} {% endprettify %}

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

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

class B implements A {} {% endprettify %}

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

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

class B {} {% endprettify %}

concrete_class_with_abstract_member

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

Description

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

Example

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

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

Common fixes

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

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

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

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

conflicting_constructor_and_static_member

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

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

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

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

Description

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

Examples

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

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

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

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

Common fixes

Rename either the member or the constructor.

conflicting_generic_interfaces

The class '{0}' can't implement both '{1}' and '{2}' because the type arguments are different.

Description

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

Example

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

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

Common fixes

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

{% prettify dart tag=pre+code %} class I {} class A implements I {} class B implements I {} class C extends A implements B {} {% endprettify %}

conflicting_type_variable_and_container

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

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

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

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

Description

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

Example

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

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

Common fixes

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

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

conflicting_type_variable_and_member

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

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

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

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

Description

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

Example

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

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

Common fixes

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

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

const_constructor_param_type_mismatch

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

Description

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

Example

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

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

const C(this.s); }

const dynamic i = 0;

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

Common fixes

Pass a value of the correct type to the constructor:

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

const C(this.s); }

const dynamic i = 0;

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

const_constructor_with_field_initialized_by_non_const

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

Description

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

Example

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

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

Common fixes

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

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

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

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

const_constructor_with_non_const_super

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

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

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

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

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

const_constructor_with_non_final_field

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

Description

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

Example

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

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

const !C!; } {% endprettify %}

Common fixes

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

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

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

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

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

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

const_deferred_class

Deferred classes can't be created with 'const'.

Description

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

For more information, see the language tour's coverage of deferred loading.

Example

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

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

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

Common fixes

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

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

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

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

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

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

const_initialized_with_non_constant_value

Const variables must be initialized with a constant value.

Description

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

Example

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

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

Common fixes

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

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

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

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

const_initialized_with_non_constant_value_from_deferred_library

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

Description

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

For more information, see the language tour's coverage of deferred loading.

Example

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

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

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

Common fixes

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

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

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

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

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

const_instance_field

Only static fields can be declared as const.

Description

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

Example

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

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

Common fixes

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

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

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

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

const_map_key_expression_type_implements_equals

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

Description

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

Example

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

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

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

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

Common fixes

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

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

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

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

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

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

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

const_not_initialized

The constant '{0}' must be initialized.

Description

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

Example

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

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

Common fixes

Add an initializer:

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

const_set_element_type_implements_equals

The type of an element in a constant set can't override the '==' operator, but the type '{0}' does.

Description

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

Example

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

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

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

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

Common fixes

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

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

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

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

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

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

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

const_spread_expected_list_or_set

A list or a set is expected in this spread.

Description

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

Example

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

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

Common fixes

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

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

const_spread_expected_map

A map is expected in this spread.

Description

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

Example

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

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

Common fixes

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

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

const_with_non_const

The constructor being called isn't a const constructor.

Description

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

Example

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

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

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

Common fixes

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

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

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

Otherwise, remove the keyword const:

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

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

const_with_non_constant_argument

Arguments of a constant creation must be constant expressions.

Description

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

Example

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

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

Common fixes

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

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

const_with_type_parameters

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

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

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

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

continue_label_on_switch

A continue label resolves to a switch statement, but the label must be on a loop or a switch member.

Description

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

Example

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

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

Common fixes

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

creation_of_struct_or_union

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

Description

The analyzer produces this diagnostic when a subclass of either Struct or Union is instantiated using a generative constructor.

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

Example

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

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

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

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

Common fixes

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

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

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

void f() { final pointer = calloc.allocate(4); final c = pointer.ref; print(c); calloc.free(pointer); } {% endprettify %}

creation_with_non_type

The name '{0}' isn't a class.

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

dead_code

Dead code.

Description

The analyzer produces this diagnostic when code is found that won't be executed because execution will never reach the code.

Example

The following code produces this diagnostic because the invocation of print occurs after the function has returned:

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

Common fixes

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

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

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

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

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

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

dead_code_catch_following_catch

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

Description

The analyzer produces this diagnostic when a catch clause is found that can't be executed because it’s after a catch clause of the form catch (e) or on Object catch (e). The first catch clause that matches the thrown object is selected, and both of those forms will match any object, so no catch clauses that follow them will be selected.

Example

The following code produces this diagnostic:

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

Common fixes

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

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

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

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

dead_code_on_catch_subtype

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

Description

The analyzer produces this diagnostic when a catch clause is found that can't be executed because it is after a catch clause that catches either the same type or a supertype of the clause's type. The first catch clause that matches the thrown object is selected, and the earlier clause always matches anything matchable by the highlighted clause, so the highlighted clause will never be selected.

Example

The following code produces this diagnostic:

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

Common fixes

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

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

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

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

dead_null_aware_expression

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

Description

The analyzer produces this diagnostic in two cases.

The first is when the left operand of an ?? operator can't be null. The right operand is only evaluated if the left operand has the value null, and because the left operand can't be null, the right operand is never evaluated.

The second is when the left-hand side of an assignment using the ??= operator can't be null. The right-hand side is only evaluated if the left-hand side has the value null, and because the left-hand side can't be null, the right-hand side is never evaluated.

Examples

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

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

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

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

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

Common fixes

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

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

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

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

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

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

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

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

default_list_constructor

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

Description

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

Example

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

{% prettify dart tag=pre+code %} var l = !List!; {% endprettify %}

Common fixes

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

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

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

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

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

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

default_value_in_function_type

Parameters in a function type can't have default values.

Description

The analyzer produces this diagnostic when a function type associated with a parameter includes optional parameters that have a default value. This isn't allowed because the default values of parameters aren't part of the function's type, and therefore including them doesn't provide any value.

Example

The following code produces this diagnostic because the parameter p has a default value even though it's part of the type of the parameter g:

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

Common fixes

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

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

default_value_in_redirecting_factory_constructor

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

Description

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

Example

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

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

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

Common fixes

Remove the default value from the factory constructor:

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

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

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

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

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

default_value_on_required_parameter

Required named parameters can't have a default value.

Description

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

Example

The following code generates this diagnostic:

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

Common fixes

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

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

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

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

deferred_import_of_extension

Imports of deferred libraries must hide all extensions.

Description

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

For more information, see the language tour's coverage of deferred loading.

Example

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

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

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

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

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

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

Common fixes

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

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

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

Adding a hide clause would look like this:

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

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

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

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

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

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

definitely_unassigned_late_local_variable

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

Description

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

Example

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

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

Common fixes

Assign a value to the variable before reading from it:

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

dependencies_field_not_map

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

Description

The analyzer produces this diagnostic when the value of either the dependencies or dev_dependencies key isn't a map.

Example

The following code produces this diagnostic because the value of the top-level dependencies key is a list:

name: example
dependencies:
  - meta

Common fixes

Use a map as the value of the dependencies key:

name: example
dependencies:
  meta: ^1.0.2

deprecated_field

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

Description

The analyzer produces this diagnostic when a key is used in a pubspec.yaml file that was deprecated. Unused keys take up space and might imply semantics that are no longer valid.

Example

The following code produces this diagnostic because the author key is no longer being used:

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

Common fixes

Remove the deprecated key:

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

deprecated_member_use

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

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

Description

The analyzer produces this diagnostic when a deprecated library or class member is used in a different package.

Example

If the method m in the class C is annotated with @deprecated, then the following code produces this diagnostic:

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

Common fixes

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

deprecated_member_use_from_same_package

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

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

Description

The analyzer produces this diagnostic when a deprecated library member or class member is used in the same package in which it's declared.

Example

The following code produces this diagnostic because x is deprecated:

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

Common fixes

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

deprecated_new_in_comment_reference

Using the 'new' keyword in a comment reference is deprecated.

Description

The analyzer produces this diagnostic when a comment reference (the name of a declaration enclosed in square brackets in a documentation comment) uses the keyword new to refer to a constructor. This form is deprecated.

Examples

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

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

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

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

Common fixes

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

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

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

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

deprecated_subtype_of_function

Extending 'Function' is deprecated.

Implementing 'Function' has no effect.

Mixing in 'Function' is deprecated.

Description

The analyzer produces this diagnostic when the class Function is used in either the extends, implements, or with clause of a class or mixin. Using the class Function in this way has no semantic value, so it's effectively dead code.

Example

The following code produces this diagnostic because Function is used as the superclass of F:

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

Common fixes

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

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

disallowed_type_instantiation_expression

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

Description

The analyzer produces this diagnostic when an expression with a value that is anything other than one of the allowed kinds of values is followed by type arguments. The allowed kinds of values are:

• generic types,
• generic constructors, and
• generic functions, including top-level functions, static and instance members, and local functions.

Example

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

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

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

Common fixes

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

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

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

division_optimization

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

Description

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

Example

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

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

Common fixes

Use the integer division operator (~/):

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

duplicate_constructor

The constructor with name '{0}' is already defined.

The unnamed constructor is already defined.

Description

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

Examples

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

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

!C!; } {% endprettify %}

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

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

!C.m!; } {% endprettify %}

Common fixes

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

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

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

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

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

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

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

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

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

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

duplicate_definition

The name '{0}' is already defined.

Description

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

Example

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

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

Common fixes

Choose a different name for one of the declarations.

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

duplicate_field_formal_parameter

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

Description

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

Example

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

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

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

Common fixes

Remove one of the initializing formal parameters:

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

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

duplicate_hidden_name

Duplicate hidden name.

Description

The analyzer produces this diagnostic when a name occurs multiple times in a hide clause. Repeating the name is unnecessary.

Example

The following code produces this diagnostic because the name min is hidden more than once:

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

var x = pi; {% endprettify %}

Common fixes

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

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

var x = pi; {% endprettify %}

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

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

var x = pi; {% endprettify %}

duplicate_ignore

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

Description

The analyzer produces this diagnostic when a diagnostic name appears in an ignore comment, but the diagnostic is already being ignored, either because it's already included in the same ignore comment or because it appears in an ignore-in-file comment.

Examples

The following code produces this diagnostic because the diagnostic named unused_local_variable is already being ignored for the whole file so it doesn't need to be ignored on a specific line:

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

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

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

Common fixes

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

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

duplicate_import

Duplicate import.

Description

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

Example

The following code produces this diagnostic:

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

@sealed class C {} {% endprettify %}

Common fixes

Remove the unnecessary import:

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

@sealed class C {} {% endprettify %}

duplicate_named_argument

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

Description

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

Example

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

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

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

Common fixes

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

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

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

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

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

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

duplicate_part

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

Description

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

Example

Given a file named part.dart containing

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

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

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

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

Common fixes

Remove all except the first of the duplicated part directives:

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

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

duplicate_shown_name

Duplicate shown name.

Description

The analyzer produces this diagnostic when a name occurs multiple times in a show clause. Repeating the name is unnecessary.

Example

The following code produces this diagnostic because the name min is shown more than once:

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

var x = min(2, min(0, 1)); {% endprettify %}

Common fixes

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

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

var x = max(2, min(0, 1)); {% endprettify %}

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

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

var x = min(2, min(0, 1)); {% endprettify %}

empty_struct

The class '{0}' can't be empty because it's a subclass of '{1}'.

Description

The analyzer produces this diagnostic when a subclass of Struct or Union doesn't have any fields. Having an empty Struct or Union isn't supported.

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

Example

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

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

class [!C!] extends Struct {} {% endprettify %}

Common fixes

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

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

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

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

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

class C extends Opaque {} {% endprettify %}

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

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

enum_constant_same_name_as_enclosing

The name of the enum constant can't be the same as the enum's name.

Description

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

Example

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

{% prettify dart tag=pre+code %} enum E { [!E!] } {% endprettify %}

Common fixes

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

{% prettify dart tag=pre+code %} enum E { e } {% endprettify %}

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

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

enum_constant_with_non_const_constructor

The invoked constructor isn't a 'const' constructor.

Description

The analyzer produces this diagnostic when an enum constant is being created using either a factory constructor or a generative constructor that isn't marked as being const.

Example

The following code produces this diagnostic because the enum constant e is being initialized by a factory constructor:

{% prettify dart tag=pre+code %} enum E { !e!;

factory E() => e; } {% endprettify %}

Common fixes

Use a generative constructor marked as const:

{% prettify dart tag=pre+code %} enum E { e._();

factory E() => e;

const E._(); } {% endprettify %}

enum_mixin_with_instance_variable

Mixins applied to enums can't have instance variables.

Description

The analyzer produces this diagnostic when a mixin that's applied to an enum declares one or more instance variables. This isn't allowed because the enum constants are constant, and there isn't any way for the constructor in the enum to initialize any of the mixin's fields.

Example

The following code produces this diagnostic because the mixin M defines the instance field x:

{% prettify dart tag=pre+code %} mixin M { int x = 0; }

enum E with [!M!] { a } {% endprettify %}

Common fixes

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

{% prettify dart tag=pre+code %} mixin M { int get x => 0; }

enum E with M { a } {% endprettify %}

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

{% prettify dart tag=pre+code %} enum E { a } {% endprettify %}

enum_with_abstract_member

'{0}' must have a method body because '{1}' is an enum.

Description

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

Example

The following code produces this diagnostic because m is an abstract method and E is an enum:

{% prettify dart tag=pre+code %} enum E { e;

[!void m();!] } {% endprettify %}

Common fixes

Provide an implementation for the member:

{% prettify dart tag=pre+code %} enum E { e;

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

enum_with_name_values

The name 'values' is not a valid name for an enum.

Description

The analyzer produces this diagnostic when an enum is declared to have the name values. This isn't allowed because the enum has an implicit static field named values, and the two would collide.

Example

The following code produces this diagnostic because there's an enum declaration that has the name values:

{% prettify dart tag=pre+code %} enum [!values!] { c } {% endprettify %}

Common fixes

Rename the enum to something other than values.

equal_elements_in_const_set

Two elements in a constant set literal can't be equal.

Description

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

Example

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

{% prettify dart tag=pre+code %} const Set set = {'a', [!'a'!]}; {% endprettify %}

Common fixes

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.

equal_elements_in_set

Two elements in a set literal shouldn't be equal.

Description

The analyzer produces this diagnostic when an element in a non-constant set is the same as a previous element in the same set. If two elements are the same, then the second value is ignored, which makes having both elements pointless and likely signals a bug.

Example

The following code produces this diagnostic because the element 1 appears twice:

{% prettify dart tag=pre+code %} const a = 1; const b = 1; var s = {a, [!b!]}; {% endprettify %}

Common fixes

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

{% prettify dart tag=pre+code %} const a = 1; const b = 2; var s = {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.

equal_keys_in_const_map

Two keys in a constant map literal can't be equal.

Description

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

Example

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

{% prettify dart tag=pre+code %} const map = <int, String>{1: 'a', 2: 'b', [!1!]: 'c', 4: 'd'}; {% endprettify %}

Common fixes

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

{% prettify dart tag=pre+code %} const map = <int, String>{1: 'a', 2: 'b', 3: 'c', 4: 'd'}; {% endprettify %}

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

{% prettify dart tag=pre+code %} const map = <int, String>{1: 'a', 2: 'b', 4: 'd'}; {% endprettify %}

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

equal_keys_in_map

Two keys in a map literal shouldn't be equal.

Description

The analyzer produces this diagnostic when a key in a non-constant map is the same as a previous key in the same map. If two keys are the same, then the second value overwrites the first value, which makes having both pairs pointless and likely signals a bug.

Example

The following code produces this diagnostic because the keys a and b have the same value:

{% prettify dart tag=pre+code %} const a = 1; const b = 1; var m = <int, String>{a: 'a', [!b!]: 'b'}; {% endprettify %}

Common fixes

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

{% prettify dart tag=pre+code %} const a = 1; const b = 2; var m = <int, String>{a: 'a', b: 'b'}; {% endprettify %}

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

{% prettify dart tag=pre+code %} const a = 1; var m = <int, String>{a: 'a'}; {% endprettify %}

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

expected_one_list_type_arguments

List literals require one type argument or none, but {0} found.

Description

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

Example

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

{% prettify dart tag=pre+code %} var l = [!<int, int>!][]; {% endprettify %}

Common fixes

Remove all except one of the type arguments:

{% prettify dart tag=pre+code %} var l = []; {% endprettify %}

expected_one_set_type_arguments

Set literals require one type argument or none, but {0} were found.

Description

The analyzer produces this diagnostic when a set literal has more than one type argument.

Example

The following code produces this diagnostic because the set literal has three type arguments when it can have at most one:

{% prettify dart tag=pre+code %} var s = [!<int, String, int>!]{0, 'a', 1}; {% endprettify %}

Common fixes

Remove all except one of the type arguments:

{% prettify dart tag=pre+code %} var s = {0, 1}; {% endprettify %}

expected_two_map_type_arguments

Map literals require two type arguments or none, but {0} found.

Description

The analyzer produces this diagnostic when a map literal has either one or more than two type arguments.

Example

The following code produces this diagnostic because the map literal has three type arguments when it can have either two or zero:

{% prettify dart tag=pre+code %} var m = [!<int, String, int>!]{}; {% endprettify %}

Common fixes

Remove all except two of the type arguments:

{% prettify dart tag=pre+code %} var m = <int, String>{}; {% endprettify %}

export_internal_library

The library '{0}' is internal and can't be exported.

Description

The analyzer produces this diagnostic when it finds an export whose dart: URI references an internal library.

Example

The following code produces this diagnostic because _interceptors is an internal library:

{% prettify dart tag=pre+code %} export [!'dart:_interceptors'!]; {% endprettify %}

Common fixes

Remove the export directive.

export_legacy_symbol

The symbol '{0}' is defined in a legacy library, and can't be re-exported from a library with null safety enabled.

Description

The analyzer produces this diagnostic when a library that was opted in to null safety exports another library, and the exported library is opted out of null safety.

Example

Given a library that is opted out of null safety:

{% prettify dart tag=pre+code %} // @dart = 2.8 String s; {% endprettify %}

The following code produces this diagnostic because it's exporting symbols from an opted-out library:

{% prettify dart tag=pre+code %} export [!'optedOut.dart'!];

class C {} {% endprettify %}

Common fixes

If you're able to do so, migrate the exported library so that it doesn't need to opt out:

{% prettify dart tag=pre+code %} String? s; {% endprettify %}

If you can't migrate the library, then remove the export:

{% prettify dart tag=pre+code %} class C {} {% endprettify %}

If the exported library (the one that is opted out) itself exports an opted-in library, then it's valid for your library to indirectly export the symbols from the opted-in library. You can do so by adding a hide combinator to the export directive in your library that hides all of the names declared in the opted-out library.

export_of_non_library

The exported library '{0}' can't have a part-of directive.

Description

The analyzer produces this diagnostic when an export directive references a part rather than a library.

Example

Given a file named part.dart containing

{% prettify dart tag=pre+code %} part of lib; {% endprettify %}

The following code produces this diagnostic because the file part.dart is a part, and only libraries can be exported:

{% prettify dart tag=pre+code %} library lib;

export [!'part.dart'!]; {% endprettify %}

Common fixes

Either remove the export directive, or change the URI to be the URI of the library containing the part.

expression_in_map

Expressions can't be used in a map literal.

Description

The analyzer produces this diagnostic when the analyzer finds an expression, rather than a map entry, in what appears to be a map literal.

Example

The following code produces this diagnostic:

{% prettify dart tag=pre+code %} var map = <String, int>{'a': 0, 'b': 1, [!'c'!]}; {% endprettify %}

Common fixes

If the expression is intended to compute either a key or a value in an entry, fix the issue by replacing the expression with the key or the value. For example:

{% prettify dart tag=pre+code %} var map = <String, int>{'a': 0, 'b': 1, 'c': 2}; {% endprettify %}

extends_non_class

Classes can only extend other classes.

Description

The analyzer produces this diagnostic when an extends clause contains a name that is declared to be something other than a class.

Example

The following code produces this diagnostic because f is declared to be a function:

{% prettify dart tag=pre+code %} void f() {}

class C extends [!f!] {} {% endprettify %}

Common fixes

If you want the class to extend a class other than Object, then replace the name in the extends clause with the name of that class:

{% prettify dart tag=pre+code %} void f() {}

class C extends B {}

class B {} {% endprettify %}

If you want the class to extend Object, then remove the extends clause:

{% prettify dart tag=pre+code %} void f() {}

class C {} {% endprettify %}

extension_as_expression

Extension '{0}' can't be used as an expression.

Description

The analyzer produces this diagnostic when the name of an extension is used in an expression other than in an extension override or to qualify an access to a static member of the extension. Because classes define a type, the name of a class can be used to refer to the instance of Type representing the type of the class. Extensions, on the other hand, don't define a type and can't be used as a type literal.

Example

The following code produces this diagnostic because E is an extension:

{% prettify dart tag=pre+code %} extension E on int { static String m() => ''; }

var x = [!E!]; {% endprettify %}

Common fixes

Replace the name of the extension with a name that can be referenced, such as a static member defined on the extension:

{% prettify dart tag=pre+code %} extension E on int { static String m() => ''; }

var x = E.m(); {% endprettify %}

extension_conflicting_static_and_instance

An extension can't define static member '{0}' and an instance member with the same name.

Description

The analyzer produces this diagnostic when an extension declaration contains both an instance member and a static member that have the same name. The instance member and the static member can't have the same name because it's unclear which member is being referenced by an unqualified use of the name within the body of the extension.

Example

The following code produces this diagnostic because the name a is being used for two different members:

{% prettify dart tag=pre+code %} extension E on Object { int get a => 0; static int !a! => 0; } {% endprettify %}

Common fixes

Rename or remove one of the members:

{% prettify dart tag=pre+code %} extension E on Object { int get a => 0; static int b() => 0; } {% endprettify %}

extension_declares_abstract_member

Extensions can't declare abstract members.

Description

The analyzer produces this diagnostic when an abstract declaration is declared in an extension. Extensions can declare only concrete members.

Example

The following code produces this diagnostic because the method a doesn't have a body:

{% prettify dart tag=pre+code %} extension E on String { int !a!; } {% endprettify %}

Common fixes

Either provide an implementation for the member or remove it.

extension_declares_constructor

Extensions can't declare constructors.

Description

The analyzer produces this diagnostic when a constructor declaration is found in an extension. It isn't valid to define a constructor because extensions aren't classes, and it isn't possible to create an instance of an extension.

Example

The following code produces this diagnostic because there is a constructor declaration in E:

{% prettify dart tag=pre+code %} extension E on String { !E! : super(); } {% endprettify %}

Common fixes

Remove the constructor or replace it with a static method.

extension_declares_instance_field

Extensions can't declare instance fields

Description

The analyzer produces this diagnostic when an instance field declaration is found in an extension. It isn't valid to define an instance field because extensions can only add behavior, not state.

Example

The following code produces this diagnostic because s is an instance field:

{% prettify dart tag=pre+code %} extension E on String { String [!s!]; } {% endprettify %}

Common fixes

Remove the field, make it a static field, or convert it to be a getter, setter, or method.

extension_declares_member_of_object

Extensions can't declare members with the same name as a member declared by 'Object'.

Description

The analyzer produces this diagnostic when an extension declaration declares a member with the same name as a member declared in the class Object. Such a member can never be used because the member in Object is always found first.

Example

The following code produces this diagnostic because toString is defined by Object:

{% prettify dart tag=pre+code %} extension E on String { String !toString! => this; } {% endprettify %}

Common fixes

Remove the member or rename it so that the name doesn't conflict with the member in Object:

{% prettify dart tag=pre+code %} extension E on String { String displayString() => this; } {% endprettify %}

extension_override_access_to_static_member

An extension override can't be used to access a static member from an extension.

Description

The analyzer produces this diagnostic when an extension override is the receiver of the invocation of a static member. Similar to static members in classes, the static members of an extension should be accessed using the name of the extension, not an extension override.

Example

The following code produces this diagnostic because m is static:

{% prettify dart tag=pre+code %} extension E on String { static void m() {} }

void f() { E('').!m!; } {% endprettify %}

Common fixes

Replace the extension override with the name of the extension:

{% prettify dart tag=pre+code %} extension E on String { static void m() {} }

void f() { E.m(); } {% endprettify %}

extension_override_argument_not_assignable

The type of the argument to the extension override '{0}' isn't assignable to the extended type '{1}'.

Description

The analyzer produces this diagnostic when the argument to an extension override isn't assignable to the type being extended by the extension.

Example

The following code produces this diagnostic because 3 isn't a String:

{% prettify dart tag=pre+code %} extension E on String { void method() {} }

void f() { E([!3!]).method(); } {% endprettify %}

Common fixes

If you're using the correct extension, then update the argument to have the correct type:

{% prettify dart tag=pre+code %} extension E on String { void method() {} }

void f() { E(3.toString()).method(); } {% endprettify %}

If there's a different extension that's valid for the type of the argument, then either replace the name of the extension or unwrap the argument so that the correct extension is found.

extension_override_without_access

An extension override can only be used to access instance members.

Description

The analyzer produces this diagnostic when an extension override is found that isn't being used to access one of the members of the extension. The extension override syntax doesn't have any runtime semantics; it only controls which member is selected at compile time.

Example

The following code produces this diagnostic because E(i) isn't an expression:

{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }

void f(int i) { print([!E(i)!]); } {% endprettify %}

Common fixes

If you want to invoke one of the members of the extension, then add the invocation:

{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }

void f(int i) { print(E(i).a); } {% endprettify %}

If you don't want to invoke a member, then unwrap the argument:

{% prettify dart tag=pre+code %} extension E on int { int get a => 0; }

void f(int i) { print(i); } {% endprettify %}

extension_override_with_cascade

Extension overrides have no value so they can't be used as the receiver of a cascade expression.

Description

The analyzer produces this diagnostic when an extension override is used as the receiver of a cascade expression. The value of a cascade expression e..m is the value of the receiver e, but extension overrides aren't expressions and don't have a value.

Example

The following code produces this diagnostic because E(3) isn't an expression:

{% prettify dart tag=pre+code %} extension E on int { void m() {} } f() { !E!..m(); } {% endprettify %}

Common fixes

Use . rather than ..:

{% prettify dart tag=pre+code %} extension E on int { void m() {} } f() { E(3).m(); } {% endprettify %}

If there are multiple cascaded accesses, you'll need to duplicate the extension override for each one.

external_with_initializer

External fields can't have initializers.

External variables can't have initializers.

Description

The analyzer produces this diagnostic when a field or variable marked with the keyword external has an initializer, or when an external field is initialized in a constructor.

Examples

The following code produces this diagnostic because the external field x is assigned a value in an initializer:

{% prettify dart tag=pre+code %} class C { external int x; C() : [!x!] = 0; } {% endprettify %}

The following code produces this diagnostic because the external field x has an initializer:

{% prettify dart tag=pre+code %} class C { external final int [!x!] = 0; } {% endprettify %}

The following code produces this diagnostic because the external top level variable x has an initializer:

{% prettify dart tag=pre+code %} external final int [!x!] = 0; {% endprettify %}

Common fixes

Remove the initializer:

{% prettify dart tag=pre+code %} class C { external final int x; } {% endprettify %}

extra_annotation_on_struct_field

Fields in a struct class must have exactly one annotation indicating the native type.

Description

The analyzer produces this diagnostic when a field in a subclass of Struct has more than one annotation describing the native type of the field.

For more information about FFI, see C interop using dart:ffi.

Example

The following code produces this diagnostic because the field x has two annotations describing the native type of the field:

{% prettify dart tag=pre+code %} import 'dart:ffi';

class C extends Struct { @Int32() [!@Int16()!] external int x; } {% endprettify %}

Common fixes

Remove all but one of the annotations:

{% prettify dart tag=pre+code %} import 'dart:ffi'; class C extends Struct { @Int32() external int x; } {% endprettify %}

extra_positional_arguments

Too many positional arguments: {0} expected, but {1} found.

Description

The analyzer produces this diagnostic when a method or function invocation has more positional arguments than the method or function allows.

Example

The following code produces this diagnostic because f defines 2 parameters but is invoked with 3 arguments:

{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f(1, 2, [!3!]); } {% endprettify %}

Common fixes

Remove the arguments that don't correspond to parameters:

{% prettify dart tag=pre+code %} void f(int a, int b) {} void g() { f(1, 2); } {% endprettify %}

extra_positional_arguments_could_be_named

Too many positional arguments: {0} expected, but {1} found.

Description

The analyzer produces this diagnostic when a method or function invocation has more positional arguments than the method or function allows, but the method or function defines named parameters.

Example

The following code produces this diagnostic because f defines 2 positional parameters but has a named parameter that could be used for the third argument:

{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f(1, 2, [!3!]); } {% endprettify %}

Common fixes

If some of the arguments should be values for named parameters, then add the names before the arguments:

{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f(1, 2, c: 3); } {% endprettify %}

Otherwise, remove the arguments that don't correspond to positional parameters:

{% prettify dart tag=pre+code %} void f(int a, int b, {int c}) {} void g() { f(1, 2); } {% endprettify %}

extra_size_annotation_carray

'Array's must have exactly one 'Array' annotation.

Description

The analyzer produces this diagnostic when a field in a subclass of Struct has more than one annotation describing the size of the native array.

For more information about FFI, see C interop using dart:ffi.

Example

The following code produces this diagnostic because the field a0 has two annotations that specify the size of the native array:

{% prettify dart tag=pre+code %} import 'dart:ffi';

class C extends Struct { @Array(4) [!@Array(8)!] external Array a0; } {% endprettify %}

Common fixes

Remove all but one of the annotations:

{% prettify dart tag=pre+code %} import 'dart:ffi';

class C extends Struct { @Array(8) external Array a0; } {% endprettify %}

field_initialized_by_multiple_initializers

The field '{0}' can't be initialized twice in the same constructor.

Description

The analyzer produces this diagnostic when the initializer list of a constructor initializes a field more than once. There is no value to allow both initializers because only the last value is preserved.

Example

The following code produces this diagnostic because the field f is being initialized twice:

{% prettify dart tag=pre+code %} class C { int f;

C() : f = 0, [!f!] = 1; } {% endprettify %}

Common fixes

Remove one of the initializers:

{% prettify dart tag=pre+code %} class C { int f;

C() : f = 0; } {% endprettify %}

field_initialized_in_initializer_and_declaration

Fields can't be initialized in the constructor if they are final and were already initialized at their declaration.

Description

The analyzer produces this diagnostic when a final field is initialized in both the declaration of the field and in an initializer in a constructor. Final fields can only be assigned once, so it can't be initialized in both places.

Example

The following code produces this diagnostic because f is :

{% prettify dart tag=pre+code %} class C { final int f = 0; C() : [!f!] = 1; } {% endprettify %}

Common fixes

If the initialization doesn't depend on any values passed to the constructor, and if all of the constructors need to initialize the field to the same value, then remove the initializer from the constructor:

{% prettify dart tag=pre+code %} class C { final int f = 0; C(); } {% endprettify %}

If the initialization depends on a value passed to the constructor, or if different constructors need to initialize the field differently, then remove the initializer in the field's declaration:

{% prettify dart tag=pre+code %} class C { final int f; C() : f = 1; } {% endprettify %}

field_initialized_in_parameter_and_initializer

Fields can't be initialized in both the parameter list and the initializers.

Description

The analyzer produces this diagnostic when a field is initialized in both the parameter list and in the initializer list of a constructor.

Example

The following code produces this diagnostic because the field f is initialized both by an initializing formal parameter and in the initializer list:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f) : [!f!] = 0; } {% endprettify %}

Common fixes

If the field should be initialized by the parameter, then remove the initialization in the initializer list:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f); } {% endprettify %}

If the field should be initialized in the initializer list and the parameter isn't needed, then remove the parameter:

{% prettify dart tag=pre+code %} class C { int f;

C() : f = 0; } {% endprettify %}

If the field should be initialized in the initializer list and the parameter is needed, then make it a normal parameter:

{% prettify dart tag=pre+code %} class C { int f;

C(int g) : f = g * 2; } {% endprettify %}

field_initializer_factory_constructor

Initializing formal parameters can't be used in factory constructors.

Description

The analyzer produces this diagnostic when a factory constructor has an initializing formal parameter. Factory constructors can't assign values to fields because no instance is created; hence, there is no field to assign.

Example

The following code produces this diagnostic because the factory constructor uses an initializing formal parameter:

{% prettify dart tag=pre+code %} class C { int? f;

factory C([!this.f!]) => throw 0; } {% endprettify %}

Common fixes

Replace the initializing formal parameter with a normal parameter:

{% prettify dart tag=pre+code %} class C { int? f;

factory C(int f) => throw 0; } {% endprettify %}

field_initializer_in_struct

Constructors in subclasses of 'Struct' and 'Union' can't have field initializers.

Description

The analyzer produces this diagnostic when a constructor in a subclass of either Struct or Union has one or more field initializers.

For more information about FFI, see C interop using dart:ffi.

Example

The following code produces this diagnostic because the class C has a constructor with an initializer for the field f:

{% prettify dart tag=pre+code %} // @dart = 2.9 import 'dart:ffi';

class C extends Struct { @Int32() int f;

C() : [!f = 0!]; } {% endprettify %}

Common fixes

Remove the field initializer:

{% prettify dart tag=pre+code %} // @dart = 2.9 import 'dart:ffi';

class C extends Struct { @Int32() int f;

C(); } {% endprettify %}

field_initializer_not_assignable

The initializer type '{0}' can't be assigned to the field type '{1}' in a const constructor.

The initializer type '{0}' can't be assigned to the field type '{1}'.

Description

The analyzer produces this diagnostic when the initializer list of a constructor initializes a field to a value that isn't assignable to the field.

Example

The following code produces this diagnostic because 0 has the type int, and an int can't be assigned to a field of type String:

{% prettify dart tag=pre+code %} class C { String s;

C() : s = [!0!]; } {% endprettify %}

Common fixes

If the type of the field is correct, then change the value assigned to it so that the value has a valid type:

{% prettify dart tag=pre+code %} class C { String s;

C() : s = '0'; } {% endprettify %}

If the type of the value is correct, then change the type of the field to allow the assignment:

{% prettify dart tag=pre+code %} class C { int s;

C() : s = 0; } {% endprettify %}

field_initializer_outside_constructor

Field formal parameters can only be used in a constructor.

Initializing formal parameters can only be used in constructors.

Description

The analyzer produces this diagnostic when an initializing formal parameter is used in the parameter list for anything other than a constructor.

Example

The following code produces this diagnostic because the initializing formal parameter this.x is being used in the method m:

{% prettify dart tag=pre+code %} class A { int x = 0;

m([[!this.x!] = 0]) {} } {% endprettify %}

Common fixes

Replace the initializing formal parameter with a normal parameter and assign the field within the body of the method:

{% prettify dart tag=pre+code %} class A { int x = 0;

m([int x = 0]) { this.x = x; } } {% endprettify %}

field_initializer_redirecting_constructor

The redirecting constructor can't have a field initializer.

Description

The analyzer produces this diagnostic when a redirecting constructor initializes a field in the object. This isn't allowed because the instance that has the field hasn't been created at the point at which it should be initialized.

Examples

The following code produces this diagnostic because the constructor C.zero, which redirects to the constructor C, has an initializing formal parameter that initializes the field f:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f);

C.zero([!this.f!]) : this(f); } {% endprettify %}

The following code produces this diagnostic because the constructor C.zero, which redirects to the constructor C, has an initializer that initializes the field f:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f);

C.zero() : [!f = 0!], this(1); } {% endprettify %}

Common fixes

If the initialization is done by an initializing formal parameter, then use a normal parameter:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f);

C.zero(int f) : this(f); } {% endprettify %}

If the initialization is done in an initializer, then remove the initializer:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f);

C.zero() : this(0); } {% endprettify %}

field_initializing_formal_not_assignable

The parameter type '{0}' is incompatible with the field type '{1}'.

Description

The analyzer produces this diagnostic when the type of an initializing formal parameter isn't assignable to the type of the field being initialized.

Example

The following code produces this diagnostic because the initializing formal parameter has the type String, but the type of the field is int. The parameter must have a type that is a subtype of the field's type.

{% prettify dart tag=pre+code %} class C { int f;

C([!String this.f!]); } {% endprettify %}

Common fixes

If the type of the field is incorrect, then change the type of the field to match the type of the parameter, and consider removing the type from the parameter:

{% prettify dart tag=pre+code %} class C { String f;

C(this.f); } {% endprettify %}

If the type of the parameter is incorrect, then remove the type of the parameter:

{% prettify dart tag=pre+code %} class C { int f;

C(this.f); } {% endprettify %}

If the types of both the field and the parameter are correct, then use an initializer rather than an initializing formal parameter to convert the parameter value into a value of the correct type:

{% prettify dart tag=pre+code %} class C { int f;

C(String s) : f = int.parse(s); } {% endprettify %}

field_in_struct_with_initializer

Fields in subclasses of 'Struct' and 'Union' can't have initializers.

Description

The analyzer produces this diagnostic when a field in a subclass of Struct has an initializer.

For more information about FFI, see C interop using dart:ffi.

Example

The following code produces this diagnostic because the field p has an initializer:

{% prettify dart tag=pre+code %} // @dart = 2.9 import 'dart:ffi';

class C extends Struct { Pointer [!p!] = nullptr; } {% endprettify %}

Common fixes

Remove the initializer:

{% prettify dart tag=pre+code %} // @dart = 2.9 import 'dart:ffi';

class C extends Struct { Pointer p; } {% endprettify %}

field_must_be_external_in_struct

Fields of 'Struct' and 'Union' subclasses must be marked external.

Description

The analyzer produces this diagnostic when a field in a subclass of either Struct or Union isn't marked as being external.

For more information about FFI, see C interop using dart:ffi.

Example

The following code produces this diagnostic because the field a isn't marked as being external:

{% prettify dart tag=pre+code %} import 'dart:ffi';

class C extends Struct { @Int16() int [!a!]; } {% endprettify %}

Common fixes

Add the required external modifier:

{% prettify dart tag=pre+code %} import 'dart:ffi';

class C extends Struct { @Int16() external int a; } {% endprettify %}

final_initialized_in_declaration_and_constructor

'{0}' is final and was given a value when it was declared, so it can't be set to a new value.

Description

The analyzer produces this diagnostic when a final field is initialized twice: once where it's declared and once by a constructor's parameter.

Example

The following code produces this diagnostic because the field f is initialized twice:

{% prettify dart tag=pre+code %} class C { final int f = 0;

C(this.[!f!]); } {% endprettify %}

Common fixes

If the field should have the same value for all instances, then remove the initialization in the parameter list:

{% prettify dart tag=pre+code %} class C { final int f = 0;

C(); } {% endprettify %}

If the field can have different values in different instances, then remove the initialization in the declaration:

{% prettify dart tag=pre+code %} class C { final int f;

C(this.f); } {% endprettify %}

final_not_initialized

The final variable '{0}' must be initialized.

Description

The analyzer produces this diagnostic when a final field or variable isn't initialized.

Example

The following code produces this diagnostic because x doesn't have an initializer:

{% prettify dart tag=pre+code %} final [!x!]; {% endprettify %}

Common fixes

For variables and static fields, you can add an initializer:

{% prettify dart tag=pre+code %} final x = 0; {% endprettify %}

For instance fields, you can add an initializer as shown in the previous example, or you can initialize the field in every constructor. You can initialize the field by using an initializing formal parameter:

{% prettify dart tag=pre+code %} class C { final int x; C(this.x); } {% endprettify %}

You can also initialize the field by using an initializer in the constructor:

{% prettify dart tag=pre+code %} class C { final int x; C(int y) : x = y * 2; } {% endprettify %}

final_not_initialized_constructor

All final variables must be initialized, but '{0}' and '{1}' aren't.

All final variables must be initialized, but '{0}' isn't.

All final variables must be initialized, but '{0}', '{1}', and {2} others aren't.

Description

The analyzer produces this diagnostic when a class defines one or more final instance fields without initializers and has at least one constructor that doesn't initialize those fields. All final instance fields must be initialized when the instance is created, either by the field's initializer or by the constructor.

Example

The following code produces this diagnostic:

{% prettify dart tag=pre+code %} class C { final String value;

!C!; } {% endprettify %}

Common fixes

If the value should be passed in to the constructor directly, then use an initializing formal parameter to initialize the field value:

{% prettify dart tag=pre+code %} class C { final String value;

C(this.value); } {% endprettify %}

If the value should be computed indirectly from a value provided by the caller, then add a parameter and include an initializer:

{% prettify dart tag=pre+code %} class C { final String value;

C(Object o) : value = o.toString(); } {% endprettify %}

If the value of the field doesn't depend on values that can be passed to the constructor, then add an initializer for the field as part of the field declaration:

{% prettify dart tag=pre+code %} class C { final String value = '';

C(); } {% endprettify %}

If the value of the field doesn't depend on values that can be passed to the constructor but different constructors need to initialize it to different values, then add an initializer for the field in the initializer list:

{% prettify dart tag=pre+code %} class C { final String value;

C() : value = '';

C.named() : value = 'c'; } {% endprettify %}

However, if the value is the same for all instances, then consider using a static field instead of an instance field:

{% prettify dart tag=pre+code %} class C { static const String value = '';

C(); } {% endprettify %}

flutter_field_not_map

The value of the 'flutter' field is expected to be a map.

Description

The analyzer produces this diagnostic when the value of the flutter key isn't a map.

Example

The following code produces this diagnostic because the value of the top-level flutter key is a string:

name: example
flutter: true

Common fixes

If you need to specify Flutter-specific options, then change the value to be a map:

name: example
flutter:
  uses-material-design: true

If you don't need to specify Flutter-specific options, then remove the flutter key:

name: example

for_in_of_invalid_element_type

The type '{0}' used in the 'for' loop must implement '{1}' with a type argument that can be assigned to '{2}'.

Description

The analyzer produces this diagnostic when the Iterable or Stream in a for-in loop has an element type that can't be assigned to the loop variable.

Example

The following code produces this diagnostic because <String>[] has an element type of String, and String can't be assigned to the type of e (int):

{% prettify dart tag=pre+code %} void f() { for (int e in [![]!]) { print(e); } } {% endprettify %}

Common fixes

If the type of the loop variable is correct, then update the type of the iterable:

{% prettify dart tag=pre+code %} void f() { for (int e in []) { print(e); } } {% endprettify %}

If the type of the iterable is correct, then update the type of the loop variable:

{% prettify dart tag=pre+code %} void f() { for (String e in []) { print(e); } } {% endprettify %}

for_in_of_invalid_type

The type '{0}' used in the 'for' loop must implement {1}.

Description

The analyzer produces this diagnostic when the expression following in in a for-in loop has a type that isn't a subclass of Iterable.

Example

The following code produces this diagnostic because m is a Map, and Map isn't a subclass of Iterable:

{% prettify dart tag=pre+code %} void f(Map<String, String> m) { for (String s in [!m!]) { print(s); } } {% endprettify %}

Common fixes

Replace the expression with one that produces an iterable value:

{% prettify dart tag=pre+code %} void f(Map<String, String> m) { for (String s in m.values) { print(s); } } {% endprettify %}

for_in_with_const_variable

A for-in loop variable can't be a 'const'.

Description

The analyzer produces this diagnostic when the loop variable declared in a for-in loop is declared to be a const. The variable can't be a const because the value can't be computed at compile time.

Example

The following code produces this diagnostic because the loop variable x is declared to be a const:

{% prettify dart tag=pre+code %} void f() { for ([!const!] x in [0, 1, 2]) { print(x); } } {% endprettify %}

Common fixes

If there's a type annotation, then remove the const modifier from the declaration.

If there's no type, then replace the const modifier with final, var, or a type annotation:

{% prettify dart tag=pre+code %} void f() { for (final x in [0, 1, 2]) { print(x); } } {% endprettify %}

generic_method_type_instantiation_on_dynamic

A method tear-off on a receiver whose type is 'dynamic' can't have type arguments.

Description

The analyzer produces this diagnostic when an instance method is being torn off from a receiver whose type is dynamic, and the tear-off includes type arguments. Because the analyzer can't know how many type parameters the method has, or whether it has any type parameters, there's no way it can validate that the type arguments are correct. As a result, the type arguments aren't allowed.

Example

The following code produces this diagnostic because the type of p is dynamic and the tear-off of m has type arguments:

{% prettify dart tag=pre+code %} void f(dynamic list) { [!list.fold!]; } {% endprettify %}

Common fixes

If you can use a more specific type than dynamic, then change the type of the receiver:

{% prettify dart tag=pre+code %} void f(List