blob: 477c26869b8b88247d7fc0d0362ba2ea382ac01c [file] [log] [blame]
<
# Copyright (c) 2021, the Dart project authors. Please see the AUTHORS file
# for details. All rights reserved. Use of this source code is governed by a
# BSD-style license that can be found in the LICENSE file.
# This file is organized as a two level map, where the outer key corresponds to
# the name of an analyzer error class (e.g. CompileTimeErrorCode), and the inner
# key corresponds to the name of a static variable in that class, describing a
# single diagnostic message. Ideally, each entry contains three parts:
#
# 1. A message template (problemMessage).
#
# 2. A suggestion for how to correct the problem (correctionMessage).
#
# 3. User-facing documentation for the problem (documentation).
#
# A message shouldn't indicate which kind of diagnostic it is, for example,
# warning or error. This is implied by the analyzer error class. For example,
# all entries in `StaticWarningCode` are warnings.
#
# See the file [lib/src/fasta/diagnostics.md] for more details on how to write
# good diagnostic messages.
#
# A message used for internal errors should have key that starts with
# "InternalProblem". This way, UX review can prioritize it accordingly.
#
# Eventually, we'd like to have all diagnostics in one shared location. However,
# for now, we have analyzer error codes and CFE error codes in separate files.
# See `pkg/front_end/messages.yaml` for the CFE error codes.
#
# ## Parameter Substitution in problemMessage and correctionMessage
#
# The fields `problemMessage` and `correctionMessage` are subject to parameter
# substitution. When the compiler reports a problem, it may also specify a list
# of values to be substituted into the message. Parameters are declared using
# placeholders of the form `{INTEGER}`, e.g. `{0}` is the zeroth parameter.
AnalysisOptionsErrorCode:
INCLUDED_FILE_PARSE_ERROR:
problemMessage: "{3} in {0}({1}..{2})"
comment: |-
An error code indicating that there is a syntactic error in the included
file.
Parameters:
0: the path of the file containing the error
1: the starting offset of the text in the file that contains the error
2: the ending offset of the text in the file that contains the error
3: the error message
PARSE_ERROR:
problemMessage: "{0}"
comment: |-
An error code indicating that there is a syntactic error in the file.
Parameters:
0: the error message from the parse error
AnalysisOptionsHintCode:
PREVIEW_DART_2_SETTING_DEPRECATED:
problemMessage: "The 'enablePreviewDart2' setting is deprecated."
correctionMessage: It is no longer necessary to explicitly enable Dart 2.
comment: |-
An error code indicating that the enablePreviewDart2 setting is
deprecated.
STRONG_MODE_SETTING_DEPRECATED:
problemMessage: "The 'strong-mode: true' setting is deprecated."
correctionMessage: It is no longer necessary to explicitly enable strong mode.
comment: "An error code indicating that strong-mode: true is deprecated."
SUPER_MIXINS_SETTING_DEPRECATED:
problemMessage: "The 'enableSuperMixins' setting is deprecated."
correctionMessage: "Support has been added to the language for 'mixin' based mixins."
comment: |-
An error code indicating that the enablePreviewDart2 setting is
deprecated.
AnalysisOptionsWarningCode:
ANALYSIS_OPTION_DEPRECATED:
problemMessage: "The option '{0}' is no longer supported."
comment: An error code indicating that the given option is deprecated.
INCLUDED_FILE_WARNING:
problemMessage: "Warning in the included options file {0}({1}..{2}): {3}"
comment: |-
An error code indicating a specified include file has a warning.
Parameters:
0: the path of the file containing the warnings
1: the starting offset of the text in the file that contains the warning
2: the ending offset of the text in the file that contains the warning
3: the warning message
INCLUDE_FILE_NOT_FOUND:
problemMessage: "The include file '{0}' in '{1}' can't be found when analyzing '{2}'."
comment: |-
An error code indicating a specified include file could not be found.
Parameters:
0: the uri of the file to be included
1: the path of the file containing the include directive
2: the path of the context being analyzed
INVALID_OPTION:
problemMessage: "Invalid option specified for '{0}': {1}"
comment: |-
An error code indicating that a plugin is being configured with an invalid
value for an option and a detail message is provided.
INVALID_SECTION_FORMAT:
problemMessage: "Invalid format for the '{0}' section."
comment: |-
An error code indicating an invalid format for an options file section.
Parameters:
0: the section name
SPEC_MODE_REMOVED:
problemMessage: "The option 'strong-mode: false' is no longer supported."
correctionMessage: "It's recommended to remove the 'strong-mode:' setting (and make your code Dart 2 compliant)."
comment: "An error code indicating that strong-mode: false is has been removed."
UNRECOGNIZED_ERROR_CODE:
problemMessage: "'{0}' isn't a recognized error code."
comment: |-
An error code indicating that an unrecognized error code is being used to
specify an error filter.
Parameters:
0: the unrecognized error code
UNSUPPORTED_OPTION_WITHOUT_VALUES:
problemMessage: "The option '{1}' isn't supported by '{0}'."
comment: |-
An error code indicating that a plugin is being configured with an
unsupported option and legal options are provided.
Parameters:
0: the plugin name
1: the unsupported option key
UNSUPPORTED_OPTION_WITH_LEGAL_VALUE:
problemMessage: "The option '{1}' isn't supported by '{0}'. Try using the only supported option: '{2}'."
comment: |-
An error code indicating that a plugin is being configured with an
unsupported option where there is just one legal value.
Parameters:
0: the plugin name
1: the unsupported option key
2: the legal value
UNSUPPORTED_OPTION_WITH_LEGAL_VALUES:
problemMessage: "The option '{1}' isn't supported by '{0}'."
correctionMessage: "Try using one of the supported options: {2}."
comment: |-
An error code indicating that a plugin is being configured with an
unsupported option and legal options are provided.
Parameters:
0: the plugin name
1: the unsupported option key
2: legal values
UNSUPPORTED_VALUE:
problemMessage: "The value '{1}' isn't supported by '{0}'."
correctionMessage: "Try using one of the supported options: {2}."
comment: |-
An error code indicating that an option entry is being configured with an
unsupported value.
Parameters:
0: the option name
1: the unsupported value
2: legal values
CompileTimeErrorCode:
ABSTRACT_FIELD_CONSTRUCTOR_INITIALIZER:
sharedName: ABSTRACT_FIELD_INITIALIZER
problemMessage: "Abstract fields can't have initializers."
correctionMessage: "Try removing the field initializer or the 'abstract' keyword from the field declaration."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
abstract class C {
abstract int [!f!] = 0;
}
```
The following code produces this diagnostic because `f` is marked as
`abstract` and there's an initializer in the constructor:
```dart
abstract class C {
abstract int f;
C() : [!f!] = 0;
}
```
#### Common fixes
If the field must be abstract, then remove the initializer:
```dart
abstract class C {
abstract int f;
}
```
If the field isn't required to be abstract, then remove the keyword:
```dart
abstract class C {
int f = 0;
}
```
ABSTRACT_FIELD_INITIALIZER:
problemMessage: "Abstract fields can't have initializers."
correctionMessage: "Try removing the initializer or the 'abstract' keyword."
hasPublishedDocs: true
comment: No parameters.
ABSTRACT_SUPER_MEMBER_REFERENCE:
problemMessage: "The {0} '{1}' is always abstract in the supertype."
hasPublishedDocs: true
comment: |-
Parameters:
0: the display name for the kind of the found abstract member
1: the name of the member
documentation: |-
#### 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`:
```dart
abstract class A {
int get a;
}
class B extends A {
int get a => super.[!a!];
}
```
#### Common fixes
Remove the invocation of the abstract member, possibly replacing it with an
invocation of a concrete member.
TODO(brianwilkerson) This either needs to be generalized (use 'member'
rather than '{0}') or split into multiple codes.
AMBIGUOUS_EXPORT:
problemMessage: "The name '{0}' is defined in the libraries '{1}' and '{2}'."
correctionMessage: Try removing the export of one of the libraries, or explicitly hiding the name in one of the export directives.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the ambiguous element
1: the name of the first library in which the type is found
2: the name of the second library in which the type is found
documentation: |-
#### 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
```dart
%uri="lib/a.dart"
class C {}
```
And a file named `b.dart` containing
```dart
%uri="lib/b.dart"
class C {}
```
The following code produces this diagnostic because the name `C` is being
exported from both `a.dart` and `b.dart`:
```dart
export 'a.dart';
export [!'b.dart'!];
```
#### Common fixes
If none of the names in one of the libraries needs to be exported, then
remove the unnecessary export directives:
```dart
export 'a.dart';
```
If all of the export directives are needed, then hide the name in all
except one of the directives:
```dart
export 'a.dart';
export 'b.dart' hide C;
```
AMBIGUOUS_EXTENSION_MEMBER_ACCESS:
problemMessage: "A member named '{0}' is defined in {1}, and none are more specific."
correctionMessage: Try using an extension override to specify the extension you want to be chosen.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the member
1: the names of the declaring extensions
documentation: |-
#### 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`:
```dart
extension E1 on String {
int get charCount => 1;
}
extension E2 on String {
int get charCount => 2;
}
void f(String s) {
print(s.[!charCount!]);
}
```
#### Common fixes
If you don't need both extensions, then you can delete or hide one of them.
If you need both, then explicitly select the one you want to use by using
an extension override:
```dart
extension E1 on String {
int get charCount => length;
}
extension E2 on String {
int get charCount => length;
}
void f(String s) {
print(E2(s).charCount);
}
```
AMBIGUOUS_IMPORT:
problemMessage: "The name '{0}' is defined in the libraries {1}."
correctionMessage: "Try using 'as prefix' for one of the import directives, or hiding the name from all but one of the imports."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the ambiguous type
1: the name of the first library that the type is found
2: the name of the second library that the type is found
documentation: |-
#### 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):
```dart
%uri="lib/a.dart"
class A {}
class C {}
```
And a library (`b.dart`) that defines a different class with the same name:
```dart
%uri="lib/b.dart"
class B {}
class C {}
```
The following code produces this diagnostic:
```dart
import 'a.dart';
import 'b.dart';
void f([!C!] c1, [!C!] c2) {}
```
#### Common fixes
If any of the libraries aren't needed, then remove the import directives
for them:
```dart
import 'a.dart';
void f(C c1, C c2) {}
```
If the name is still defined by more than one library, then add a `hide`
clause to the import directives for all except one library:
```dart
import 'a.dart' hide C;
import 'b.dart';
void f(C c1, C c2) {}
```
If you must be able to reference more than one of these types, then add a
prefix to each of the import directives, and qualify the references with
the appropriate prefix:
```dart
import 'a.dart' as a;
import 'b.dart' as b;
void f(a.C c1, b.C c2) {}
```
AMBIGUOUS_SET_OR_MAP_LITERAL_BOTH:
problemMessage: "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."
correctionMessage: Try removing or changing some of the elements so that all of the elements are consistent.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
[!{...a, ...b, ...c}!];
```
The list `b` can only be spread into a set, and the maps `a` and `c` can
only be spread into a map, and the literal can't be both.
#### Common fixes
There are two common ways to fix this problem. The first is to remove all
of the spread elements of one kind or another, so that the elements are
consistent. In this case, that likely means removing the list and deciding
what to do about the now unused parameter:
```dart
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
{...a, ...c};
```
The second fix is to change the elements of one kind into elements that are
consistent with the other elements. For example, you can add the elements
of the list as keys that map to themselves:
```dart
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
{...a, for (String s in b) s: s, ...c};
```
AMBIGUOUS_SET_OR_MAP_LITERAL_EITHER:
problemMessage: "This literal must be either a map or a set, but the elements don't have enough information for type inference to work."
correctionMessage: Try adding type arguments to the literal (one for sets, two for maps).
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
union(a, b) => [!{...a, ...b}!];
```
The problem occurs because there are no type arguments, and there is no
information about the type of either `a` or `b`.
#### Common fixes
There are three common ways to fix this problem. The first is to add type
arguments to the literal. For example, if the literal is intended to be a
map literal, you might write something like this:
```dart
union(a, b) => <String, String>{...a, ...b};
```
The second fix is to add type information so that the expressions have
either the type `Iterable` or the type `Map`. You can add an explicit cast
or, in this case, add types to the declarations of the two parameters:
```dart
union(List<int> a, List<int> b) => {...a, ...b};
```
The third fix is to add context information. In this case, that means
adding a return type to the function:
```dart
Set<String> union(a, b) => {...a, ...b};
```
In other cases, you might add a type somewhere else. For example, say the
original code looks like this:
```dart
union(a, b) {
var x = [!{...a, ...b}!];
return x;
}
```
You might add a type annotation on `x`, like this:
```dart
union(a, b) {
Map<String, String> x = {...a, ...b};
return x;
}
```
ARGUMENT_TYPE_NOT_ASSIGNABLE:
problemMessage: "The argument type '{0}' can't be assigned to the parameter type '{1}'."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the actual argument type
1: the name of the expected type
documentation: |-
#### 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`:
```dart
%language=2.9
String f(String x) => x;
String g(num y) => f([!y!]);
```
#### Common fixes
If possible, rewrite the code so that the static type is assignable. In the
example above you might be able to change the type of the parameter `y`:
```dart
%language=2.9
String f(String x) => x;
String g(String y) => f(y);
```
If that fix isn't possible, then add code to handle the case where the
argument value isn't the required type. One approach is to coerce other
types to the required type:
```dart
%language=2.9
String f(String x) => x;
String g(num y) => f(y.toString());
```
Another approach is to add explicit type tests and fallback code:
```dart
%language=2.9
String f(String x) => x;
String g(num y) => f(y is String ? y : '');
```
If you believe that the runtime type of the argument will always be the
same as the static type of the parameter, and you're willing to risk having
an exception thrown at runtime if you're wrong, then add an explicit cast:
```dart
String f(String x) => x;
String g(num y) => f(y as String);
```
ASSERT_IN_REDIRECTING_CONSTRUCTOR:
problemMessage: "A redirecting constructor can't have an 'assert' initializer."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
C(int x) : [!assert(x > 0)!], this.name();
C.name() {}
}
```
#### Common fixes
If the assert isn't needed, then remove it:
```dart
class C {
C(int x) : this.name();
C.name() {}
}
```
If the assert is needed, then convert the constructor into a factory
constructor:
```dart
class C {
factory C(int x) {
assert(x > 0);
return C.name();
}
C.name() {}
}
```
ASSIGNMENT_TO_CONST:
problemMessage: "Constant variables can't be assigned a value."
correctionMessage: "Try removing the assignment, or remove the modifier 'const' from the variable."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
const c = 0;
void f() {
[!c!] = 1;
print(c);
}
```
#### Common fixes
If the variable must be assignable, then remove the `const` modifier:
```dart
var c = 0;
void f() {
c = 1;
print(c);
}
```
If the constant shouldn't be changed, then either remove the assignment or
use a local variable in place of references to the constant:
```dart
const c = 0;
void f() {
var v = 1;
print(v);
}
```
ASSIGNMENT_TO_FINAL:
problemMessage: "'{0}' can't be used as a setter because it's final."
correctionMessage: "Try finding a different setter, or making '{0}' non-final."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the final variable
documentation: |-
#### 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:
```dart
class C {
final v = 0;
}
f(C c) {
c.[!v!] = 1;
}
```
#### Common fixes
If you need to be able to set the value of the field, then remove the
modifier `final` from the field:
```dart
class C {
int v = 0;
}
f(C c) {
c.v = 1;
}
```
ASSIGNMENT_TO_FINAL_LOCAL:
problemMessage: "The final variable '{0}' can only be set once."
correctionMessage: "Try making '{0}' non-final."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
void f() {
final x = 0;
[!x!] = 3;
print(x);
}
```
#### Common fixes
Remove the keyword `final`, and replace it with `var` if there's no type
annotation:
```dart
void f() {
var x = 0;
x = 3;
print(x);
}
```
ASSIGNMENT_TO_FINAL_NO_SETTER:
problemMessage: "There isn’t a setter named '{0}' in class '{1}'."
correctionMessage: Try correcting the name to reference an existing setter, or declare the setter.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
class C {
int get x => 0;
set y(int p) {}
}
void f(C c) {
c.[!x!] = 1;
}
```
#### Common fixes
If you want to invoke an existing setter, then correct the name:
```dart
class C {
int get x => 0;
set y(int p) {}
}
void f(C c) {
c.y = 1;
}
```
If you want to invoke the setter but it just doesn't exist yet, then
declare it:
```dart
class C {
int get x => 0;
set x(int p) {}
set y(int p) {}
}
void f(C c) {
c.x = 1;
}
```
ASSIGNMENT_TO_FUNCTION:
problemMessage: "Functions can't be assigned a value."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
void f() {}
void g() {
[!f!] = () {};
}
```
#### Common fixes
If the right-hand side should be assigned to something else, such as a
local variable, then change the left-hand side:
```dart
void f() {}
void g() {
var x = () {};
print(x);
}
```
If the intent is to change the implementation of the function, then define
a function-valued variable instead of a function:
```dart
void Function() f = () {};
void g() {
f = () {};
}
```
ASSIGNMENT_TO_METHOD:
problemMessage: "Methods can't be assigned a value."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
void f() {}
void g() {
[!f!] = null;
}
}
```
#### Common fixes
Rewrite the code so that there isn't an assignment to a method.
ASSIGNMENT_TO_TYPE:
problemMessage: "Types can't be assigned a value."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {}
void f() {
[!C!] = null;
}
```
#### Common fixes
If the right-hand side should be assigned to something else, such as a
local variable, then change the left-hand side:
```dart
void f() {}
void g() {
var c = null;
print(c);
}
```
ASYNC_FOR_IN_WRONG_CONTEXT:
problemMessage: The async for-in loop can only be used in an async function.
correctionMessage: "Try marking the function body with either 'async' or 'async*', or removing the 'await' before the for-in loop."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
void f(list) {
await for (var e [!in!] list) {
print(e);
}
}
```
#### Common fixes
If the function should return a `Future`, then mark the body with `async`:
```dart
Future<void> f(list) async {
await for (var e in list) {
print(e);
}
}
```
If the function should return a `Stream` of values, then mark the body with
`async*`:
```dart
Stream<void> f(list) async* {
await for (var e in list) {
print(e);
}
}
```
If the function should be synchronous, then remove the `await` before the
loop:
```dart
void f(list) {
for (var e in list) {
print(e);
}
}
```
AWAIT_IN_LATE_LOCAL_VARIABLE_INITIALIZER:
problemMessage: "The 'await' expression can't be used in a 'late' local variable's initializer."
correctionMessage: "Try removing the 'late' modifier, or rewriting the initializer without using the 'await' expression."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
Future<int> f() async {
late var v = [!await!] 42;
return v;
}
```
#### Common fixes
If the initializer can be rewritten to not use `await`, then rewrite it:
```dart
Future<int> f() async {
late var v = 42;
return v;
}
```
If the initializer can't be rewritten, then remove the `late` modifier:
```dart
Future<int> f() async {
var v = await 42;
return v;
}
```
AWAIT_IN_WRONG_CONTEXT:
problemMessage: The await expression can only be used in an async function.
correctionMessage: "Try marking the function body with either 'async' or 'async*'."
comment: |-
16.30 Await Expressions: It is a compile-time error if the function
immediately enclosing _a_ is not declared asynchronous. (Where _a_ is the
await expression.)
BODY_MIGHT_COMPLETE_NORMALLY:
problemMessage: "The body might complete normally, causing 'null' to be returned, but the return type, '{0}', is a potentially non-nullable type."
correctionMessage: Try adding either a return or a throw statement at the end.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
class C {
int [!m!](int t) {
print(t);
}
}
```
The following code produces this diagnostic because the method `m` has an
implicit return of `null` inserted at the end of the method, but because
the class `C` can be instantiated with a non-nullable type argument, the
method is effectively declared to not return `null`:
```dart
class C<T> {
T [!m!](T t) {
print(t);
}
}
```
#### Common fixes
If there's a reasonable value that can be returned, then add a `return`
statement at the end of the method:
```dart
class C<T> {
T m(T t) {
print(t);
return t;
}
}
```
If the method won't reach the implicit return, then add a `throw` at the
end of the method:
```dart
class C<T> {
T m(T t) {
print(t);
throw '';
}
}
```
If the method intentionally returns `null` at the end, then add an
explicit return of `null` at the end of the method and change the
return type so that it's valid to return `null`:
```dart
class C<T> {
T? m(T t) {
print(t);
return null;
}
}
```
BREAK_LABEL_ON_SWITCH_MEMBER:
problemMessage: "A break label resolves to the 'case' or 'default' statement."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
void f(int i) {
switch (i) {
l: case 0:
break;
case 1:
break [!l!];
}
}
```
#### Common fixes
If the intent is to transfer control to the statement after the switch,
then remove the label from the break statement:
```dart
void f(int i) {
switch (i) {
case 0:
break;
case 1:
break;
}
}
```
If the intent is to transfer control to a different case block, then use
`continue` rather than `break`:
```dart
void f(int i) {
switch (i) {
l: case 0:
break;
case 1:
continue l;
}
}
```
BUILT_IN_IDENTIFIER_AS_TYPE:
problemMessage: "The built-in identifier '{0}' can't be used as a type."
correctionMessage: Try correcting the name to match an existing type.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
documentation: |-
#### 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:
```dart
[!import!]<int> x;
```
#### Common fixes
Replace the built-in identifier with the name of a valid type:
```dart
List<int> x;
```
BUILT_IN_IDENTIFIER_AS_EXTENSION_NAME:
sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
problemMessage: "The built-in identifier '{0}' can't be used as an extension name."
correctionMessage: Try choosing a different name for the extension.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
documentation: |-
#### 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:
```dart
extension [!mixin!] on int {}
```
#### Common fixes
Choose a different name for the declaration.
BUILT_IN_IDENTIFIER_AS_PREFIX_NAME:
sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
problemMessage: "The built-in identifier '{0}' can't be used as a prefix name."
correctionMessage: Try choosing a different name for the prefix.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
BUILT_IN_IDENTIFIER_AS_TYPE_NAME:
sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
problemMessage: "The built-in identifier '{0}' can't be used as a type name."
correctionMessage: Try choosing a different name for the type.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
BUILT_IN_IDENTIFIER_AS_TYPE_PARAMETER_NAME:
sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
problemMessage: "The built-in identifier '{0}' can't be used as a type parameter name."
correctionMessage: Try choosing a different name for the type parameter.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
BUILT_IN_IDENTIFIER_AS_TYPEDEF_NAME:
sharedName: BUILT_IN_IDENTIFIER_IN_DECLARATION
problemMessage: "The built-in identifier '{0}' can't be used as a typedef name."
correctionMessage: Try choosing a different name for the typedef.
hasPublishedDocs: true
comment: |-
Parameters:
0: the built-in identifier that is being used
CASE_BLOCK_NOT_TERMINATED:
problemMessage: "The last statement of the 'case' should be 'break', 'continue', 'rethrow', 'return', or 'throw'."
correctionMessage: Try adding one of the required statements.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
%language=2.9
void f(int x) {
switch (x) {
[!case!] 0:
x += 2;
default:
x += 1;
}
}
```
#### Common fixes
Add one of the required terminators:
```dart
%language=2.9
void f(int x) {
switch (x) {
case 0:
x += 2;
break;
default:
x += 1;
}
}
```
CASE_EXPRESSION_TYPE_IMPLEMENTS_EQUALS:
problemMessage: "The switch case expression type '{0}' can't override the '==' operator."
hasPublishedDocs: true
comment: |-
Parameters:
0: the this of the switch case expression
documentation: |-
#### 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:
```dart
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
switch (c) {
case [!C(0)!]:
break;
}
}
```
#### Common fixes
If there isn't a strong reason not to do so, then rewrite the code to use
an if-else structure:
```dart
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
if (c == C(0)) {
// ...
}
}
```
If you can't rewrite the switch statement and the implementation of `==`
isn't necessary, then remove it:
```dart
class C {
final int value;
const C(this.value);
}
void f(C c) {
switch (c) {
case C(0):
break;
}
}
```
If you can't rewrite the switch statement and you can't remove the
definition of `==`, then find some other value that can be used to control
the switch:
```dart
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
switch (c.value) {
case 0:
break;
}
}
```
CASE_EXPRESSION_TYPE_IS_NOT_SWITCH_EXPRESSION_SUBTYPE:
problemMessage: "The switch case expression type '{0}' must be a subtype of the switch expression type '{1}'."
hasPublishedDocs: true
comment: |-
Parameters:
0: the type of the case expression
1: the type of the switch expression
documentation: |-
#### 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`):
```dart
void f(String s) {
switch (s) {
case [!1!]:
break;
}
}
```
#### Common fixes
If the value of the `case` expression is wrong, then change the `case`
expression so that it has the required type:
```dart
void f(String s) {
switch (s) {
case '1':
break;
}
}
```
If the value of the `case` expression is correct, then change the `switch`
expression to have the required type:
```dart
void f(int s) {
switch (s) {
case 1:
break;
}
}
```
CAST_TO_NON_TYPE:
problemMessage: "The name '{0}' isn't a type, so it can't be used in an 'as' expression."
correctionMessage: "Try changing the name to the name of an existing type, or creating a type with the name '{0}'."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
num x = 0;
int y = x as [!x!];
```
#### Common fixes
Replace the name with the name of a type:
```dart
num x = 0;
int y = x as int;
```
CLASS_INSTANTIATION_ACCESS_TO_INSTANCE_MEMBER:
sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
problemMessage: "The instance member '{0}' can't be accessed on a class instantiation."
correctionMessage: Try changing the member name to the name of a constructor.
comment: |-
Parameters:
0: the name of the member
CLASS_INSTANTIATION_ACCESS_TO_UNKNOWN_MEMBER:
sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
problemMessage: "The class '{0} doesn't have a constructor named '{1}."
correctionMessage: "Try invoking a different constructor, or defining a constructor named '{1}'."
comment: |-
Parameters:
0: the name of the member
CLASS_INSTANTIATION_ACCESS_TO_STATIC_MEMBER:
sharedName: CLASS_INSTANTIATION_ACCESS_TO_MEMBER
problemMessage: "The static member '{0}' can't be accessed on a class instantiation."
correctionMessage: Try removing the type arguments from the class name, or changing the member name to the name of a constructor.
comment: |-
Parameters:
0: the name of the member
NON_CONST_GENERATIVE_ENUM_CONSTRUCTOR:
problemMessage: Generative enum constructors must be 'const'.
correctionMessage: Try adding the keyword 'const'.
NON_CONSTANT_MAP_KEY_FROM_DEFERRED_LIBRARY:
sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
problemMessage: "Constant values from a deferred library can't be used as keys in a 'const' map literal."
correctionMessage: "Try removing the keyword 'const' from the map literal or removing the keyword 'deferred' from the import."
hasPublishedDocs: true
comment: No parameters.
NON_CONSTANT_LIST_ELEMENT_FROM_DEFERRED_LIBRARY:
sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
problemMessage: "Constant values from a deferred library can't be used as values in a 'const' list literal."
correctionMessage: "Try removing the keyword 'const' from the list literal or removing the keyword 'deferred' from the import."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).
#### Example
Given a file (`a.dart`) that defines the constant `zero`:
```dart
%uri="lib/a.dart"
const zero = 0;
```
The following code produces this diagnostic because the constant list
literal contains `a.zero`, which is imported using a `deferred` import:
```dart
import 'a.dart' deferred as a;
var l = const [[!a.zero!]];
```
#### Common fixes
If the collection literal isn't required to be constant, then remove the
`const` keyword:
```dart
import 'a.dart' deferred as a;
var l = [a.zero];
```
If the collection is required to be constant and the imported constant must
be referenced, then remove the keyword `deferred` from the import:
```dart
import 'a.dart' as a;
var l = const [a.zero];
```
If you don't need to reference the constant, then replace it with a
suitable value:
```dart
var l = const [0];
```
SET_ELEMENT_FROM_DEFERRED_LIBRARY:
sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
problemMessage: "Constant values from a deferred library can't be used as values in a 'const' set literal."
correctionMessage: "Try removing the keyword 'const' from the set literal or removing the keyword 'deferred' from the import."
hasPublishedDocs: true
comment: No parameters.
NON_CONSTANT_MAP_VALUE_FROM_DEFERRED_LIBRARY:
sharedName: COLLECTION_ELEMENT_FROM_DEFERRED_LIBRARY
problemMessage: "Constant values from a deferred library can't be used as values in a 'const' map literal."
correctionMessage: "Try removing the keyword 'const' from the map literal or removing the keyword 'deferred' from the import."
hasPublishedDocs: true
comment: No parameters.
CONCRETE_CLASS_HAS_ENUM_SUPERINTERFACE:
problemMessage: "Concrete classes can't have 'Enum' as a superinterface."
correctionMessage: Try specifying a different interface, or remove it from the list.
CONCRETE_CLASS_WITH_ABSTRACT_MEMBER:
problemMessage: "'{0}' must have a method body because '{1}' isn't abstract."
correctionMessage: "Try making '{1}' abstract, or adding a body to '{0}'."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the abstract method
1: the name of the enclosing class
documentation: |-
#### 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:
```dart
class C {
[!void m();!]
}
```
#### Common fixes
If it's valid to create instances of the class, provide an implementation
for the member:
```dart
class C {
void m() {}
}
```
If it isn't valid to create instances of the class, mark the class as being
abstract:
```dart
abstract class C {
void m();
}
```
CONFLICTING_CONSTRUCTOR_AND_STATIC_FIELD:
sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
problemMessage: "'{0}' can't be used to name both a constructor and a static field in this class."
correctionMessage: Try renaming either the constructor or the field.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the constructor and field
documentation: |-
#### 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:
```dart
class C {
C.[!foo!]();
static int foo = 0;
}
```
The following code produces this diagnostic because the static method `foo`
and the named constructor `foo` have the same name:
```dart
class C {
C.[!foo!]();
static void foo() {}
}
```
#### Common fixes
Rename either the member or the constructor.
CONFLICTING_CONSTRUCTOR_AND_STATIC_GETTER:
sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
problemMessage: "'{0}' can't be used to name both a constructor and a static getter in this class."
correctionMessage: Try renaming either the constructor or the getter.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the constructor and getter
CONFLICTING_CONSTRUCTOR_AND_STATIC_METHOD:
sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
problemMessage: "'{0}' can't be used to name both a constructor and a static method in this class."
correctionMessage: Try renaming either the constructor or the method.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the constructor
CONFLICTING_CONSTRUCTOR_AND_STATIC_SETTER:
sharedName: CONFLICTING_CONSTRUCTOR_AND_STATIC_MEMBER
problemMessage: "'{0}' can't be used to name both a constructor and a static setter in this class."
correctionMessage: Try renaming either the constructor or the setter.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the constructor and setter
CONFLICTING_FIELD_AND_METHOD:
problemMessage: "Class '{0}' can't define field '{1}' and have method '{2}.{1}' with the same name."
correctionMessage: "Try converting the getter to a method, or renaming the field to a name that doesn't conflict."
comment: |-
10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
error if `C` declares a getter or a setter with basename `n`, and has a
method named `n`.
Parameters:
0: the name of the class defining the conflicting field
1: the name of the conflicting field
2: the name of the class defining the method with which the field conflicts
CONFLICTING_GENERIC_INTERFACES:
problemMessage: "The class '{0}' can't implement both '{1}' and '{2}' because the type arguments are different."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the class implementing the conflicting interface
1: the first conflicting type
2: the second conflicting type
documentation: |-
#### Description
The analyzer produces this diagnostic when a class attempts to implement a
generic interface multiple times, and the values of the type arguments
aren't the same.
#### Example
The following code produces this diagnostic because `C` is defined to
implement both `I<int>` (because it extends `A`) and `I<String>` (because
it implements`B`), but `int` and `String` aren't the same type:
```dart
class I<T> {}
class A implements I<int> {}
class B implements I<String> {}
class [!C!] extends A implements B {}
```
#### Common fixes
Rework the type hierarchy to avoid this situation. For example, you might
make one or both of the inherited types generic so that `C` can specify the
same type for both type arguments:
```dart
class I<T> {}
class A<S> implements I<S> {}
class B implements I<String> {}
class C extends A<String> implements B {}
```
CONFLICTING_METHOD_AND_FIELD:
problemMessage: "Class '{0}' can't define method '{1}' and have field '{2}.{1}' with the same name."
correctionMessage: "Try converting the method to a getter, or renaming the method to a name that doesn't conflict."
comment: |-
10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
error if `C` declares a method named `n`, and has a getter or a setter
with basename `n`.
Parameters:
0: the name of the class defining the conflicting method
1: the name of the conflicting method
2: the name of the class defining the field with which the method conflicts
CONFLICTING_STATIC_AND_INSTANCE:
problemMessage: "Class '{0}' can't define static member '{1}' and have instance member '{2}.{1}' with the same name."
correctionMessage: "Try renaming the member to a name that doesn't conflict."
comment: |-
10.11 Class Member Conflicts: Let `C` be a class. It is a compile-time
error if `C` declares a static member with basename `n`, and has an
instance member with basename `n`.
Parameters:
0: the name of the class defining the conflicting member
1: the name of the conflicting static member
2: the name of the class defining the field with which the method conflicts
CONFLICTING_TYPE_VARIABLE_AND_CLASS:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
problemMessage: "'{0}' can't be used to name both a type variable and the class in which the type variable is defined."
correctionMessage: Try renaming either the type variable or the class.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
documentation: |-
#### 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:
```dart
class C<[!C!]> {}
```
#### Common fixes
Rename either the type parameter, or the class, mixin, or extension:
```dart
class C<T> {}
```
CONFLICTING_TYPE_VARIABLE_AND_ENUM:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
problemMessage: "'{0}' can't be used to name both a type variable and the enum in which the type variable is defined."
correctionMessage: Try renaming either the type variable or the enum.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONFLICTING_TYPE_VARIABLE_AND_EXTENSION:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
problemMessage: "'{0}' can't be used to name both a type variable and the extension in which the type variable is defined."
correctionMessage: Try renaming either the type variable or the extension.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONFLICTING_TYPE_VARIABLE_AND_MIXIN:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_CONTAINER
problemMessage: "'{0}' can't be used to name both a type variable and the mixin in which the type variable is defined."
correctionMessage: Try renaming either the type variable or the mixin.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONFLICTING_TYPE_VARIABLE_AND_MEMBER_CLASS:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
problemMessage: "'{0}' can't be used to name both a type variable and a member in this class."
correctionMessage: Try renaming either the type variable or the member.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
documentation: |-
#### 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`:
```dart
class C<[!T!]> {
int T = 0;
}
```
#### Common fixes
Rename either the type parameter or the member with which it conflicts:
```dart
class C<T> {
int total = 0;
}
```
CONFLICTING_TYPE_VARIABLE_AND_MEMBER_MIXIN:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
problemMessage: "'{0}' can't be used to name both a type variable and a member in this mixin."
correctionMessage: Try renaming either the type variable or the member.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONFLICTING_TYPE_VARIABLE_AND_MEMBER_ENUM:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
problemMessage: "'{0}' can't be used to name both a type variable and a member in this enum."
correctionMessage: Try renaming either the type variable or the member.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONFLICTING_TYPE_VARIABLE_AND_MEMBER_EXTENSION:
sharedName: CONFLICTING_TYPE_VARIABLE_AND_MEMBER
problemMessage: "'{0}' can't be used to name both a type variable and a member in this extension."
correctionMessage: Try renaming either the type variable or the member.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the type variable
CONST_CONSTRUCTOR_FIELD_TYPE_MISMATCH:
problemMessage: "In a const constructor, a value of type '{0}' can't be assigned to the field '{1}', which has type '{2}'."
correctionMessage: "Try using a subtype, or removing the keyword 'const'."
comment: |-
16.12.2 Const: It is a compile-time error if evaluation of a constant
object results in an uncaught exception being thrown.
CONST_CONSTRUCTOR_PARAM_TYPE_MISMATCH:
problemMessage: "A value of type '{0}' can't be assigned to a parameter of type '{1}' in a const constructor."
correctionMessage: "Try using a subtype, or removing the keyword 'const'."
hasPublishedDocs: true
comment: |-
Parameters:
0: the type of the runtime value of the argument
1: the static type of the parameter
documentation: |-
#### 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`:
```dart
class C {
final String s;
const C(this.s);
}
const dynamic i = 0;
void f() {
const C([!i!]);
}
```
#### Common fixes
Pass a value of the correct type to the constructor:
```dart
class C {
final String s;
const C(this.s);
}
const dynamic i = 0;
void f() {
const C('$i');
}
```
CONST_CONSTRUCTOR_THROWS_EXCEPTION:
problemMessage: "Const constructors can't throw exceptions."
correctionMessage: "Try removing the throw statement, or removing the keyword 'const'."
comment: |-
16.12.2 Const: It is a compile-time error if evaluation of a constant
object results in an uncaught exception being thrown.
CONST_CONSTRUCTOR_WITH_FIELD_INITIALIZED_BY_NON_CONST:
problemMessage: "Can't define the 'const' constructor because the field '{0}' is initialized with a non-constant value."
correctionMessage: "Try initializing the field to a constant value, or removing the keyword 'const' from the constructor."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the field
documentation: |-
#### 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:
```dart
class C {
final String s = 3.toString();
[!const!] C();
}
```
#### Common fixes
If the field can be initialized to a constant value, then change the
initializer to a constant expression:
```dart
class C {
final String s = '3';
const C();
}
```
If the field can't be initialized to a constant value, then remove the
keyword `const` from the constructor:
```dart
class C {
final String s = 3.toString();
C();
}
```
CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELD:
problemMessage: "This constructor can't be declared 'const' because a mixin adds the instance field: {0}."
correctionMessage: "Try removing the 'const' keyword or removing the 'with' clause from the class declaration, or removing the field from the mixin class."
comment: |-
7.6.3 Constant Constructors: The superinitializer that appears, explicitly
or implicitly, in the initializer list of a constant constructor must
specify a constant constructor of the superclass of the immediately
enclosing class or a compile-time error occurs.
12.1 Mixin Application: For each generative constructor named ... an
implicitly declared constructor named ... is declared. If Sq is a
generative const constructor, and M does not declare any fields, Cq is
also a const constructor.
Parameters:
0: the name of the instance field.
CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELDS:
sharedName: CONST_CONSTRUCTOR_WITH_MIXIN_WITH_FIELD
problemMessage: "This constructor can't be declared 'const' because the mixins add the instance fields: {0}."
correctionMessage: "Try removing the 'const' keyword or removing the 'with' clause from the class declaration, or removing the fields from the mixin classes."
comment: |-
7.6.3 Constant Constructors: The superinitializer that appears, explicitly
or implicitly, in the initializer list of a constant constructor must
specify a constant constructor of the superclass of the immediately
enclosing class or a compile-time error occurs.
12.1 Mixin Application: For each generative constructor named ... an
implicitly declared constructor named ... is declared. If Sq is a
generative const constructor, and M does not declare any fields, Cq is
also a const constructor.
Parameters:
0: the names of the instance fields.
CONST_CONSTRUCTOR_WITH_NON_CONST_SUPER:
problemMessage: "A constant constructor can't call a non-constant super constructor of '{0}'."
correctionMessage: "Try calling a constant constructor in the superclass, or removing the keyword 'const' from the constructor."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the superclass
documentation: |-
#### 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:
```dart
class A {
const A();
A.nonConst();
}
class B extends A {
const B() : [!super.nonConst()!];
}
```
#### Common fixes
If it isn't essential to invoke the superclass constructor that is
currently being invoked, then invoke a constant constructor from the
superclass:
```dart
class A {
const A();
A.nonConst();
}
class B extends A {
const B() : super();
}
```
If it's essential that the current constructor be invoked and if you can
modify it, then add `const` to the constructor in the superclass:
```dart
class A {
const A();
const A.nonConst();
}
class B extends A {
const B() : super.nonConst();
}
```
If it's essential that the current constructor be invoked and you can't
modify it, then remove `const` from the constructor in the subclass:
```dart
class A {
const A();
A.nonConst();
}
class B extends A {
B() : super.nonConst();
}
```
CONST_CONSTRUCTOR_WITH_NON_FINAL_FIELD:
problemMessage: "Can't define a const constructor for a class with non-final fields."
correctionMessage: "Try making all of the fields final, or removing the keyword 'const' from the constructor."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
int x;
const [!C!](this.x);
}
```
#### Common fixes
If it's possible to mark all of the fields as final, then do so:
```dart
class C {
final int x;
const C(this.x);
}
```
If it isn't possible to mark all of the fields as final, then remove the
keyword `const` from the constructor:
```dart
class C {
int x;
C(this.x);
}
```
CONST_DEFERRED_CLASS:
problemMessage: "Deferred classes can't be created with 'const'."
correctionMessage: "Try using 'new' to create the instance, or changing the import to not be deferred."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).
#### Example
The following code produces this diagnostic because it attempts to create a
`const` instance of a class from a deferred library:
```dart
import 'dart:convert' deferred as convert;
const json2 = [!convert.JsonCodec()!];
```
#### Common fixes
If the object isn't required to be a constant, then change the code so that
a non-constant instance is created:
```dart
import 'dart:convert' deferred as convert;
final json2 = convert.JsonCodec();
```
If the object must be a constant, then remove `deferred` from the import
directive:
```dart
import 'dart:convert' as convert;
const json2 = convert.JsonCodec();
```
CONST_EVAL_THROWS_EXCEPTION:
problemMessage: Evaluation of this constant expression throws an exception.
comment: |-
16.12.2 Const: It is a compile-time error if evaluation of a constant
object results in an uncaught exception being thrown.
CONST_EVAL_THROWS_IDBZE:
problemMessage: Evaluation of this constant expression throws an IntegerDivisionByZeroException.
comment: |-
16.12.2 Const: It is a compile-time error if evaluation of a constant
object results in an uncaught exception being thrown.
CONST_EVAL_TYPE_BOOL:
problemMessage: "In constant expressions, operands of this operator must be of type 'bool'."
comment: |-
16.12.2 Const: An expression of one of the forms !e, e1 && e2 or e1 || e2,
where e, e1 and e2 are constant expressions that evaluate to a boolean
value.
CONST_EVAL_TYPE_BOOL_INT:
problemMessage: "In constant expressions, operands of this operator must be of type 'bool' or 'int'."
comment: |-
16.12.2 Const: An expression of one of the forms !e, e1 && e2 or e1 || e2,
where e, e1 and e2 are constant expressions that evaluate to a boolean
value.
CONST_EVAL_TYPE_BOOL_NUM_STRING:
problemMessage: "In constant expressions, operands of this operator must be of type 'bool', 'num', 'String' or 'null'."
comment: |-
16.12.2 Const: An expression of one of the forms e1 == e2 or e1 != e2 where
e1 and e2 are constant expressions that evaluate to a numeric, string or
boolean value or to null.
CONST_EVAL_TYPE_INT:
problemMessage: "In constant expressions, operands of this operator must be of type 'int'."
comment: |-
16.12.2 Const: An expression of one of the forms ~e, e1 ^ e2, e1 & e2,
e1 | e2, e1 >> e2 or e1 << e2, where e, e1 and e2 are constant expressions
that evaluate to an integer value or to null.
CONST_EVAL_TYPE_NUM:
problemMessage: "In constant expressions, operands of this operator must be of type 'num'."
comment: |-
16.12.2 Const: An expression of one of the forms e, e1 + e2, e1 - e2, e1
e2, e1 / e2, e1 ~/ e2, e1 > e2, e1 < e2, e1 >= e2, e1 <= e2 or e1 % e2,
where e, e1 and e2 are constant expressions that evaluate to a numeric
value or to null.
CONST_EVAL_TYPE_TYPE:
problemMessage: "In constant expressions, operands of this operator must be of type 'Type'."
CONST_INITIALIZED_WITH_NON_CONSTANT_VALUE:
problemMessage: Const variables must be initialized with a constant value.
correctionMessage: Try changing the initializer to be a constant expression.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
var x = 0;
const y = [!x!];
```
#### Common fixes
If the value being assigned can be declared to be `const`, then change the
declaration:
```dart
const x = 0;
const y = x;
```
If the value can't be declared to be `const`, then remove the `const`
modifier from the variable, possibly using `final` in its place:
```dart
var x = 0;
final y = x;
```
CONST_INITIALIZED_WITH_NON_CONSTANT_VALUE_FROM_DEFERRED_LIBRARY:
problemMessage: "Constant values from a deferred library can't be used to initialize a 'const' variable."
correctionMessage: Try initializing the variable without referencing members of the deferred library, or changing the import to not be deferred.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).
#### Example
The following code produces this diagnostic because the variable `pi` is
being initialized using the constant `math.pi` from the library
`dart:math`, and `dart:math` is imported as a deferred library:
```dart
import 'dart:math' deferred as math;
const pi = [!math.pi!];
```
#### Common fixes
If you need to reference the value of the constant from the imported
library, then remove the keyword `deferred`:
```dart
import 'dart:math' as math;
const pi = math.pi;
```
If you don't need to reference the imported constant, then remove the
reference:
```dart
const pi = 3.14;
```
CONST_INSTANCE_FIELD:
problemMessage: Only static fields can be declared as const.
correctionMessage: "Try declaring the field as final, or adding the keyword 'static'."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
[!const!] int f = 3;
}
```
#### Common fixes
If the field needs to be an instance field, then remove the keyword
`const`, or replace it with `final`:
```dart
class C {
final int f = 3;
}
```
If the field really should be a const field, then make it a static field:
```dart
class C {
static const int f = 3;
}
```
CONST_MAP_KEY_EXPRESSION_TYPE_IMPLEMENTS_EQUALS:
problemMessage: "The type of a key in a constant map can't override the '==' operator, but the class '{0}' does."
correctionMessage: "Try using a different value for the key, or removing the keyword 'const' from the map."
hasPublishedDocs: true
comment: |-
Parameters:
0: the type of the entry's key
documentation: |-
#### 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 `==`:
```dart
class C {
const C();
bool operator ==(Object other) => true;
}
const map = {[!C()!] : 0};
```
#### Common fixes
If you can remove the implementation of `==` from the class, then do so:
```dart
class C {
const C();
}
const map = {C() : 0};
```
If you can't remove the implementation of `==` from the class, then make
the map be non-constant:
```dart
class C {
const C();
bool operator ==(Object other) => true;
}
final map = {C() : 0};
```
CONST_NOT_INITIALIZED:
problemMessage: "The constant '{0}' must be initialized."
correctionMessage: Try adding an initialization to the declaration.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the uninitialized final variable
documentation: |-
#### 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:
```dart
const [!c!];
```
#### Common fixes
Add an initializer:
```dart
const c = 'c';
```
CONST_SET_ELEMENT_TYPE_IMPLEMENTS_EQUALS:
problemMessage: "The type of an element in a constant set can't override the '==' operator, but the type '{0}' does."
correctionMessage: "Try using a different value for the element, or removing the keyword 'const' from the set."
hasPublishedDocs: true
comment: |-
Parameters:
0: the type of the element
documentation: |-
#### 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 `==`:
```dart
class C {
const C();
bool operator ==(Object other) => true;
}
const set = {[!C()!]};
```
#### Common fixes
If you can remove the implementation of `==` from the class, then do so:
```dart
class C {
const C();
}
const set = {C()};
```
If you can't remove the implementation of `==` from the class, then make
the set be non-constant:
```dart
class C {
const C();
bool operator ==(Object other) => true;
}
final set = {C()};
```
CONST_SPREAD_EXPECTED_LIST_OR_SET:
problemMessage: A list or a set is expected in this spread.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
%language=2.9
const List<int> list1 = null;
const List<int> list2 = [...[!list1!]];
```
#### Common fixes
Change the expression to something that evaluates to either a constant list
or a constant set:
```dart
%language=2.9
const List<int> list1 = [];
const List<int> list2 = [...list1];
```
CONST_SPREAD_EXPECTED_MAP:
problemMessage: A map is expected in this spread.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
%language=2.9
const Map<String, int> map1 = null;
const Map<String, int> map2 = {...[!map1!]};
```
#### Common fixes
Change the expression to something that evaluates to a constant map:
```dart
%language=2.9
const Map<String, int> map1 = {};
const Map<String, int> map2 = {...map1};
```
CONST_WITH_NON_CONST:
problemMessage: "The constructor being called isn't a const constructor."
correctionMessage: "Try removing 'const' from the constructor invocation."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class A {
A();
}
A f() => [!const!] A();
```
#### Common fixes
If it's desirable and possible to make the class a constant class (by
making all of the fields of the class, including inherited fields, final),
then add the keyword `const` to the constructor:
```dart
class A {
const A();
}
A f() => const A();
```
Otherwise, remove the keyword `const`:
```dart
class A {
A();
}
A f() => A();
```
CONST_WITH_NON_CONSTANT_ARGUMENT:
problemMessage: Arguments of a constant creation must be constant expressions.
correctionMessage: "Try making the argument a valid constant, or use 'new' to call the constructor."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
final int i;
const C(this.i);
}
C f(int i) => const C([!i!]);
```
#### Common fixes
Either make all of the arguments constant expressions, or remove the
`const` keyword to use the non-constant form of the constructor:
```dart
class C {
final int i;
const C(this.i);
}
C f(int i) => C(i);
```
CONST_WITH_TYPE_PARAMETERS:
problemMessage: "A constant creation can't use a type parameter as a type argument."
correctionMessage: Try replacing the type parameter with a different type.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C<T> {
const C();
}
C<T> newC<T>() => const C<[!T!]>();
```
#### Common fixes
If the type that will be used for the type parameter can be known at
compile time, then remove the use of the type parameter:
```dart
class C<T> {
const C();
}
C<int> newC() => const C<int>();
```
If the type that will be used for the type parameter can't be known until
runtime, then remove the keyword `const`:
```dart
class C<T> {
const C();
}
C<T> newC<T>() => C<T>();
```
CONST_WITH_TYPE_PARAMETERS_CONSTRUCTOR_TEAROFF:
sharedName: CONST_WITH_TYPE_PARAMETERS
problemMessage: "A constant constructor tearoff can't use a type parameter as a type argument."
correctionMessage: Try replacing the type parameter with a different type.
hasPublishedDocs: true
comment: No parameters.
CONST_WITH_TYPE_PARAMETERS_FUNCTION_TEAROFF:
sharedName: CONST_WITH_TYPE_PARAMETERS
problemMessage: "A constant function tearoff can't use a type parameter as a type argument."
correctionMessage: Try replacing the type parameter with a different type.
hasPublishedDocs: true
comment: No parameters.
CONST_WITH_UNDEFINED_CONSTRUCTOR:
problemMessage: "The class '{0}' doesn't have a constant constructor '{1}'."
correctionMessage: Try calling a different constructor.
comment: |-
16.12.2 Const: It is a compile-time error if <i>T.id</i> is not the name of
a constant constructor declared by the type <i>T</i>.
Parameters:
0: the name of the type
1: the name of the requested constant constructor
CONST_WITH_UNDEFINED_CONSTRUCTOR_DEFAULT:
problemMessage: "The class '{0}' doesn't have an unnamed constant constructor."
correctionMessage: Try calling a different constructor.
comment: |-
16.12.2 Const: It is a compile-time error if <i>T.id</i> is not the name of
a constant constructor declared by the type <i>T</i>.
Parameters:
0: the name of the type
CONTINUE_LABEL_ON_SWITCH:
problemMessage: A `continue` label resolves to a `switch` statement, but the label must be on a loop or a switch member.
hasPublishedDocs: true
documentation: |-
#### 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:
```dart
void f(int i) {
l: switch (i) {
case 0:
continue [!l!];
}
}
```
#### Common fixes
Find a different way to achieve the control flow you need; for example, by
introducing a loop that re-executes the `switch` statement.
COULD_NOT_INFER:
problemMessage: "Couldn't infer type parameter '{0}'.{1}"
comment: |-
Parameters:
0: the name of the type parameter
1: detail text explaining why the type could not be inferred
NEW_WITH_NON_TYPE:
sharedName: CREATION_WITH_NON_TYPE
problemMessage: "The name '{0}' isn't a class."
correctionMessage: Try correcting the name to match an existing class.
isUnresolvedIdentifier: true
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the non-type element
documentation: |-
#### 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:
```dart
int f() => 0;
void g() {
new [!f!]();
}
```
#### Common fixes
If a class should be created, then replace the invalid name with the name
of a valid class:
```dart
int f() => 0;
void g() {
new Object();
}
```
If the name is the name of a function and you want that function to be
invoked, then remove the `new` or `const` keyword:
```dart
int f() => 0;
void g() {
f();
}
```
CONST_WITH_NON_TYPE:
sharedName: CREATION_WITH_NON_TYPE
problemMessage: "The name '{0}' isn't a class."
correctionMessage: Try correcting the name to match an existing class.
isUnresolvedIdentifier: true
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the non-type element
DEFAULT_LIST_CONSTRUCTOR:
problemMessage: "The default 'List' constructor isn't available when null safety is enabled."
correctionMessage: "Try using a list literal, 'List.filled' or 'List.generate'."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
var l = [!List<int>!]();
```
#### Common fixes
If no initial size is provided, then convert the code to use a list
literal:
```dart
var l = <int>[];
```
If an initial size needs to be provided and there is a single reasonable
initial value for the elements, then use `List.filled`:
```dart
var l = List.filled(3, 0);
```
If an initial size needs to be provided but each element needs to be
computed, then use `List.generate`:
```dart
var l = List.generate(3, (i) => i);
```
DEFAULT_VALUE_IN_REDIRECTING_FACTORY_CONSTRUCTOR:
problemMessage: "Default values aren't allowed in factory constructors that redirect to another constructor."
correctionMessage: Try removing the default value.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
class A {
factory A([int [!x!] = 0]) = B;
}
class B implements A {
B([int x = 1]) {}
}
```
#### Common fixes
Remove the default value from the factory constructor:
```dart
class A {
factory A([int x]) = B;
}
class B implements A {
B([int x = 1]) {}
}
```
Note that this fix might change the value used when the optional parameter
is omitted. If that happens, and if that change is a problem, then consider
making the optional parameter a required parameter in the factory method:
```dart
class A {
factory A(int x) = B;
}
class B implements A {
B([int x = 1]) {}
}
```
DEFAULT_VALUE_ON_REQUIRED_PARAMETER:
problemMessage: "Required named parameters can't have a default value."
correctionMessage: "Try removing either the default value or the 'required' modifier."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
void log({required String [!message!] = 'no message'}) {}
```
#### Common fixes
If the parameter is really required, then remove the default value:
```dart
void log({required String message}) {}
```
If the parameter isn't always required, then remove the `required`
modifier:
```dart
void log({String message = 'no message'}) {}
```
DEFERRED_IMPORT_OF_EXTENSION:
problemMessage: Imports of deferred libraries must hide all extensions.
correctionMessage: Try adding either a show combinator listing the names you need to reference or a hide combinator listing all of the extensions.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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](https://dart.dev/guides/language/language-tour#lazily-loading-a-library).
#### Example
Given a file (`a.dart`) that defines a named extension:
```dart
%uri="lib/a.dart"
class C {}
extension E on String {
int get size => length;
}
```
The following code produces this diagnostic because the named extension is
visible to the library:
```dart
import [!'a.dart'!] deferred as a;
void f() {
a.C();
}
```
#### Common fixes
If the library must be imported as `deferred`, then either add a `show`
clause listing the names being referenced or add a `hide` clause listing
all of the named extensions. Adding a `show` clause would look like this:
```dart
import 'a.dart' deferred as a show C;
void f() {
a.C();
}
```
Adding a `hide` clause would look like this:
```dart
import 'a.dart' deferred as a hide E;
void f() {
a.C();
}
```
With the first fix, the benefit is that if new extensions are added to the
imported library, then the extensions won't cause a diagnostic to be
generated.
If the library doesn't need to be imported as `deferred`, or if you need to
make use of the extension method declared in it, then remove the keyword
`deferred`:
```dart
import 'a.dart' as a;
void f() {
a.C();
}
```
DEFINITELY_UNASSIGNED_LATE_LOCAL_VARIABLE:
problemMessage: "The late local variable '{0}' is definitely unassigned at this point."
correctionMessage: Ensure that it is assigned on necessary execution paths.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the variable that is invalid
documentation: |-
#### 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:
```dart
void f(bool b) {
late int x;
print([!x!]);
}
```
#### Common fixes
Assign a value to the variable before reading from it:
```dart
void f(bool b) {
late int x;
x = b ? 1 : 0;
print(x);
}
```
DISALLOWED_TYPE_INSTANTIATION_EXPRESSION:
problemMessage: Only a generic type, generic function, generic instance method, or generic constructor can have type arguments.
correctionMessage: Try removing the type arguments, or instantiating the type(s) of a generic type, generic function, generic instance method, or generic constructor.
comment: No parameters.
hasPublishedDocs: true
documentation: |-
#### 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:
```dart
int i = 1;
void f() {
print([!i!]<int>);
}
```
#### Common fixes
If the referenced value is correct, then remove the type arguments:
```dart
int i = 1;
void f() {
print(i);
}
```
DUPLICATE_CONSTRUCTOR_NAME:
sharedName: DUPLICATE_CONSTRUCTOR
problemMessage: "The constructor with name '{0}' is already defined."
correctionMessage: Try renaming one of the constructors.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the duplicate entity
DUPLICATE_CONSTRUCTOR_DEFAULT:
sharedName: DUPLICATE_CONSTRUCTOR
problemMessage: The unnamed constructor is already defined.
correctionMessage: Try giving one of the constructors a name.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
C();
[!C!]();
}
```
The following code produces this diagnostic because there are two
declarations for the constructor named `m`:
```dart
class C {
C.m();
[!C.m!]();
}
```
#### Common fixes
If there are multiple unnamed constructors and all of the constructors are
needed, then give all of them, or all except one of them, a name:
```dart
class C {
C();
C.n();
}
```
If there are multiple unnamed constructors and all except one of them are
unneeded, then remove the constructors that aren't needed:
```dart
class C {
C();
}
```
If there are multiple named constructors and all of the constructors are
needed, then rename all except one of them:
```dart
class C {
C.m();
C.n();
}
```
If there are multiple named constructors and all except one of them are
unneeded, then remove the constructorsthat aren't needed:
```dart
class C {
C.m();
}
```
DUPLICATE_DEFINITION:
problemMessage: "The name '{0}' is already defined."
correctionMessage: Try renaming one of the declarations.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the duplicate entity
documentation: |-
#### 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:
```dart
int x = 0;
int [!x!] = 1;
```
#### Common fixes
Choose a different name for one of the declarations.
```dart
int x = 0;
int y = 1;
```
DUPLICATE_FIELD_FORMAL_PARAMETER:
problemMessage: "The field '{0}' can't be initialized by multiple parameters in the same constructor."
correctionMessage: Try removing one of the parameters, or using different fields.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the field
documentation: |-
#### 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:
```dart
class C {
int f;
C(this.f, this.[!f!]) {}
}
```
#### Common fixes
Remove one of the initializing formal parameters:
```dart
class C {
int f;
C(this.f) {}
}
```
DUPLICATE_NAMED_ARGUMENT:
problemMessage: "The argument for the named parameter '{0}' was already specified."
correctionMessage: Try removing one of the named arguments, or correcting one of the names to reference a different named parameter.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the parameter that was duplicated
documentation: |-
#### 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`:
```dart
%language=2.9
void f(C c) {
c.m(a: 0, [!a!]: 1);
}
class C {
void m({int a, int b}) {}
}
```
#### Common fixes
If one of the arguments should have a different name, then change the name:
```dart
%language=2.9
void f(C c) {
c.m(a: 0, b: 1);
}
class C {
void m({int a, int b}) {}
}
```
If one of the arguments is wrong, then remove it:
```dart
%language=2.9
void f(C c) {
c.m(a: 1);
}
class C {
void m({int a, int b}) {}
}
```
DUPLICATE_PART:
problemMessage: "The library already contains a part with the URI '{0}'."
correctionMessage: Try removing all except one of the duplicated part directives.
hasPublishedDocs: true
comment: |-
Parameters:
0: the URI of the duplicate part
documentation: |-
#### Description
The analyzer produces this diagnostic when a single file is referenced in
multiple part directives.
#### Example
Given a file named `part.dart` containing
```dart
%uri="lib/part.dart"
part of lib;
```
The following code produces this diagnostic because the file `part.dart` is
included multiple times:
```dart
library lib;
part 'part.dart';
part [!'part.dart'!];
```
#### Common fixes
Remove all except the first of the duplicated part directives:
```dart
library lib;
part 'part.dart';
```
ENUM_CONSTANT_SAME_NAME_AS_ENCLOSING:
problemMessage: "The name of the enum constant can't be the same as the enum's name."
correctionMessage: Try renaming the constant.
hasPublishedDocs: true
documentation: |-
#### 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`:
```dart
enum E {
[!E!]
}
```
#### Common fixes
If the name of the enum is correct, then rename the constant:
```dart
enum E {
e
}
```
If the name of the constant is correct, then rename the enum:
```dart
enum F {
E
}
```
ENUM_CONSTANT_WITH_NON_CONST_CONSTRUCTOR:
problemMessage: The invoked constructor isn't a const constructor.
correctionMessage: Try invoking a const generative constructor.
ENUM_INSTANTIATED_TO_BOUNDS_IS_NOT_WELL_BOUNDED:
problemMessage: The result of instantiating the enum to bounds is not well-bounded.
correctionMessage: Try using different bounds for type parameters.
ENUM_MIXIN_WITH_INSTANCE_VARIABLE:
problemMessage: Mixins applied to enums can't have instance variables.
correctionMessage: Try replacing the instance variables with getters.
ENUM_WITH_ABSTRACT_MEMBER:
problemMessage: "'{0}' must have a method body because '{1}' is an enum."
correctionMessage: "Try adding a body to '{0}'."
comment: |-
Parameters:
0: the name of the abstract method
1: the name of the enclosing enum
ENUM_WITH_NAME_VALUES:
problemMessage: The name 'values' is not a valid name for an enum.
correctionMessage: Try using a different name.
EQUAL_ELEMENTS_IN_CONST_SET:
problemMessage: "Two elements in a constant set literal can't be equal."
correctionMessage: Change or remove the duplicate element.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
const Set<String> set = {'a', [!'a'!]};
```
#### Common fixes
Remove one of the duplicate values:
```dart
const Set<String> set = {'a'};
```
Note that literal sets preserve the order of their elements, so the choice
of which element to remove might affect the order in which elements are
returned by an iterator.
EQUAL_KEYS_IN_CONST_MAP:
problemMessage: "Two keys in a constant map literal can't be equal."
correctionMessage: Change or remove the duplicate key.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
const map = <int, String>{1: 'a', 2: 'b', [!1!]: 'c', 4: 'd'};
```
#### Common fixes
If both entries should be included in the map, then change one of the keys
to be different:
```dart
const map = <int, String>{1: 'a', 2: 'b', 3: 'c', 4: 'd'};
```
If only one of the entries is needed, then remove the one that isn't
needed:
```dart
const map = <int, String>{1: 'a', 2: 'b', 4: 'd'};
```
Note that literal maps preserve the order of their entries, so the choice
of which entry to remove might affect the order in which keys and values
are returned by an iterator.
EXPECTED_ONE_LIST_TYPE_ARGUMENTS:
problemMessage: "List literals require one type argument or none, but {0} found."
correctionMessage: Try adjusting the number of type arguments.
hasPublishedDocs: true
comment: |-
Parameters:
0: the number of provided type arguments
documentation: |-
#### 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:
```dart
var l = [!<int, int>!][];
```
#### Common fixes
Remove all except one of the type arguments:
```dart
var l = <int>[];
```
EXPECTED_ONE_SET_TYPE_ARGUMENTS:
problemMessage: "Set literals require one type argument or none, but {0} were found."
correctionMessage: Try adjusting the number of type arguments.
hasPublishedDocs: true
comment: |-
Parameters:
0: the number of provided type arguments
documentation: |-
#### 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:
```dart
var s = [!<int, String, int>!]{0, 'a', 1};
```
#### Common fixes
Remove all except one of the type arguments:
```dart
var s = <int>{0, 1};
```
EXPECTED_TWO_MAP_TYPE_ARGUMENTS:
problemMessage: "Map literals require two type arguments or none, but {0} found."
correctionMessage: Try adjusting the number of type arguments.
hasPublishedDocs: true
comment: |-
Parameters:
0: the number of provided type arguments
documentation: |-
#### 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:
```dart
var m = [!<int, String, int>!]{};
```
#### Common fixes
Remove all except two of the type arguments:
```dart
var m = <int, String>{};
```
EXPORT_INTERNAL_LIBRARY:
problemMessage: "The library '{0}' is internal and can't be exported."
hasPublishedDocs: true
comment: |-
Parameters:
0: the uri pointing to a library
documentation: |-
#### 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:
```dart
export [!'dart:_interceptors'!];
```
#### Common fixes
Remove the export directive.
EXPORT_LEGACY_SYMBOL:
problemMessage: "The symbol '{0}' is defined in a legacy library, and can't be re-exported from a library with null safety enabled."
correctionMessage: Try removing the export or migrating the legacy library.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of a symbol defined in a legacy library
documentation: |-
#### Description
The analyzer produces this diagnostic when a library that was opted in to
null safety exports another library, and the exported library is opted out
of null safety.
#### Example
Given a library that is opted out of null safety:
```dart
%uri="lib/optedOut.dart"
// @dart = 2.8
String s;
```
The following code produces this diagnostic because it's exporting symbols
from an opted-out library:
```dart
export [!'optedOut.dart'!];
class C {}
```
#### Common fixes
If you're able to do so, migrate the exported library so that it doesn't
need to opt out:
```dart
String? s;
```
If you can't migrate the library, then remove the export:
```dart
class C {}
```
If the exported library (the one that is opted out) itself exports an
opted-in library, then it's valid for your library to indirectly export the
symbols from the opted-in library. You can do so by adding a hide
combinator to the export directive in your library that hides all of the
names declared in the opted-out library.
EXPORT_OF_NON_LIBRARY:
problemMessage: "The exported library '{0}' can't have a part-of directive."
correctionMessage: Try exporting the library that the part is a part of.
hasPublishedDocs: true
comment: |-
Parameters:
0: the uri pointing to a non-library declaration
documentation: |-
#### 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
```dart
%uri="lib/part.dart"
part of lib;
```
The following code produces this diagnostic because the file `part.dart` is
a part, and only libraries can be exported:
```dart
library lib;
export [!'part.dart'!];
```
#### Common fixes
Either remove the export directive, or change the URI to be the URI of the
library containing the part.
EXPRESSION_IN_MAP:
problemMessage: "Expressions can't be used in a map literal."
correctionMessage: Try removing the expression or converting it to be a map entry.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
var map = <String, int>{'a': 0, 'b': 1, [!'c'!]};
```
#### Common fixes
If the expression is intended to compute either a key or a value in an
entry, fix the issue by replacing the expression with the key or the value.
For example:
```dart
var map = <String, int>{'a': 0, 'b': 1, 'c': 2};
```
EXTENDS_NON_CLASS:
problemMessage: Classes can only extend other classes.
correctionMessage: Try specifying a different superclass, or removing the extends clause.
isUnresolvedIdentifier: true
hasPublishedDocs: true
comment: |-
Parameters:
0: the name in the extends clause
documentation: |-
#### 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:
```dart
void f() {}
class C extends [!f!] {}
```
#### Common fixes
If you want the class to extend a class other than `Object`, then replace
the name in the `extends` clause with the name of that class:
```dart
void f() {}
class C extends B {}
class B {}
```
If you want the class to extend `Object`, then remove the `extends` clause:
```dart
void f() {}
class C {}
```
EXTENSION_AS_EXPRESSION:
problemMessage: "Extension '{0}' can't be used as an expression."
correctionMessage: Try replacing it with a valid expression.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the extension
documentation: |-
#### 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:
```dart
extension E on int {
static String m() => '';
}
var x = [!E!];
```
#### Common fixes
Replace the name of the extension with a name that can be referenced, such
as a static member defined on the extension:
```dart
extension E on int {
static String m() => '';
}
var x = E.m();
```
EXTENSION_CONFLICTING_STATIC_AND_INSTANCE:
problemMessage: "An extension can't define static member '{0}' and an instance member with the same name."
correctionMessage: "Try renaming the member to a name that doesn't conflict."
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the conflicting static member
documentation: |-
#### 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:
```dart
extension E on Object {
int get a => 0;
static int [!a!]() => 0;
}
```
#### Common fixes
Rename or remove one of the members:
```dart
extension E on Object {
int get a => 0;
static int b() => 0;
}
```
EXTENSION_DECLARES_MEMBER_OF_OBJECT:
problemMessage: "Extensions can't declare members with the same name as a member declared by 'Object'."
correctionMessage: Try specifying a different name for the member.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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`:
```dart
extension E on String {
String [!toString!]() => this;
}
```
#### Common fixes
Remove the member or rename it so that the name doesn't conflict with the
member in `Object`:
```dart
extension E on String {
String displayString() => this;
}
```
EXTENSION_OVERRIDE_ACCESS_TO_STATIC_MEMBER:
problemMessage: "An extension override can't be used to access a static member from an extension."
correctionMessage: Try using just the name of the extension.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
extension E on String {
static void m() {}
}
void f() {
E('').[!m!]();
}
```
#### Common fixes
Replace the extension override with the name of the extension:
```dart
extension E on String {
static void m() {}
}
void f() {
E.m();
}
```
EXTENSION_OVERRIDE_ARGUMENT_NOT_ASSIGNABLE:
problemMessage: "The type of the argument to the extension override '{0}' isn't assignable to the extended type '{1}'."
hasPublishedDocs: true
comment: |-
Parameters:
0: the type of the argument
1: the extended type
documentation: |-
#### 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`:
```dart
extension E on String {
void method() {}
}
void f() {
E([!3!]).method();
}
```
#### Common fixes
If you're using the correct extension, then update the argument to have the
correct type:
```dart
extension E on String {
void method() {}
}
void f() {
E(3.toString()).method();
}
```
If there's a different extension that's valid for the type of the argument,
then either replace the name of the extension or unwrap the argument so
that the correct extension is found.
EXTENSION_OVERRIDE_WITHOUT_ACCESS:
problemMessage: An extension override can only be used to access instance members.
correctionMessage: Consider adding an access to an instance member.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
extension E on int {
int get a => 0;
}
void f(int i) {
print([!E(i)!]);
}
```
#### Common fixes
If you want to invoke one of the members of the extension, then add the
invocation:
```dart
extension E on int {
int get a => 0;
}
void f(int i) {
print(E(i).a);
}
```
If you don't want to invoke a member, then unwrap the argument:
```dart
extension E on int {
int get a => 0;
}
void f(int i) {
print(i);
}
```
EXTENSION_OVERRIDE_WITH_CASCADE:
problemMessage: "Extension overrides have no value so they can't be used as the receiver of a cascade expression."
correctionMessage: "Try using '.' instead of '..'."
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
extension E on int {
void m() {}
}
f() {
[!E!](3)..m();
}
```
#### Common fixes
Use `.` rather than `..`:
```dart
extension E on int {
void m() {}
}
f() {
E(3).m();
}
```
If there are multiple cascaded accesses, you'll need to duplicate the
extension override for each one.
EXTERNAL_FIELD_CONSTRUCTOR_INITIALIZER:
sharedName: EXTERNAL_WITH_INITIALIZER
problemMessage: External fields can't have initializers.
correctionMessage: "Try removing the field initializer or the 'external' keyword from the field declaration."
hasPublishedDocs: true
documentation: |-
#### 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:
```dart
class C {
external int x;
C() : [!x!] = 0;
}
```
The following code produces this diagnostic because the external field `x`
has an initializer:
```dart
class C {
external final int [!x!] = 0;
}
```
The following code produces this diagnostic because the external top level
variable `x` has an initializer:
```dart
external final int [!x!] = 0;
```
#### Common fixes
Remove the initializer:
```dart
class C {
external final int x;
}
```
EXTERNAL_FIELD_INITIALIZER:
sharedName: EXTERNAL_WITH_INITIALIZER
problemMessage: External fields can't have initializers.
correctionMessage: "Try removing the initializer or the 'external' keyword."
hasPublishedDocs: true
EXTERNAL_VARIABLE_INITIALIZER:
sharedName: EXTERNAL_WITH_INITIALIZER
problemMessage: External variables can't have initializers.
correctionMessage: "Try removing the initializer or the 'external' keyword."
hasPublishedDocs: true
EXTRA_POSITIONAL_ARGUMENTS:
problemMessage: "Too many positional arguments: {0} expected, but {1} found."
correctionMessage: Try removing the extra arguments.
hasPublishedDocs: true
comment: |-
Parameters:
0: the maximum number of positional arguments
1: the actual number of positional arguments given
documentation: |-
#### 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:
```dart
void f(int a, int b) {}
void g() {
f(1, 2, [!3!]);
}
```
#### Common fixes
Remove the arguments that don't correspond to parameters:
```dart
void f(int a, int b) {}
void g() {
f(1, 2);
}
```
EXTRA_POSITIONAL_ARGUMENTS_COULD_BE_NAMED:
problemMessage: "Too many positional arguments: {0} expected, but {1} found."
correctionMessage: Try removing the extra positional arguments, or specifying the name for named arguments.
hasPublishedDocs: true
comment: |-
Parameters:
0: the maximum number of positional arguments
1: the actual number of positional arguments given
documentation: |-
#### 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:
```dart
%language=2.9
void f(int a, int b, {int c}) {}
void g() {
f(1, 2, [!3!]);
}
```
#### Common fixes
If some of the arguments should be values for named parameters, then add
the names before the arguments:
```dart
%language=2.9
void f(int a, int b, {int c}) {}
void g() {
f(1, 2, c: 3);
}
```
Otherwise, remove the arguments that don't correspond to positional
parameters:
```dart
%language=2.9
void f(int a, int b, {int c}) {}
void g() {
f(1, 2);
}
```
FIELD_INITIALIZED_BY_MULTIPLE_INITIALIZERS:
problemMessage: "The field '{0}' can't be initialized twice in the same constructor."
correctionMessage: Try removing one of the initializations.
hasPublishedDocs: true
comment: |-
Parameters:
0: the name of the field being initialized multiple times
documentation: |-
#### 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:
```dart
class C {
int f;
C() : f = 0, [!f!] = 1;
}
```
#### Common fixes
Remove one of the initializers:
```dart
class C {
int f;
C() : f = 0;
}
```
FIELD_INITIALIZED_IN_INITIALIZER_AND_DECLARATION:
problemMessage: "Fields can't be initialized in the constructor if they are final and were already initialized at their declaration."
correctionMessage: Try removing one of the initializations.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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 :
```dart
class C {
final int f = 0;
C() : [!f!] = 1;
}
```
#### Common fixes
If the initialization doesn't depend on any values passed to the
constructor, and if all of the constructors need to initialize the field to
the same value, then remove the initializer from the constructor:
```dart
class C {
final int f = 0;
C();
}
```
If the initialization depends on a value passed to the constructor, or if
different constructors need to initialize the field differently, then
remove the initializer in the field's declaration:
```dart
class C {
final int f;
C() : f = 1;
}
```
FIELD_INITIALIZED_IN_PARAMETER_AND_INITIALIZER:
problemMessage: "Fields can't be initialized in both the parameter list and the initializers."
correctionMessage: Try removing one of the initializations.
hasPublishedDocs: true
comment: No parameters.
documentation: |-
#### 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:
```dart
class C {
int f;
C(this.f) : [!f!] = 0;
}
```
#### Common fixes
If the field should be initialized by the parameter, then remove the
initialization in the initializer list:
```dart
class C {
int f;
C(this.f);
}
```