Diagnostic messages
- Diagnostics
- abi_specific_integer_invalid
- abi_specific_integer_mapping_extra
- abi_specific_integer_mapping_missing
- abi_specific_integer_mapping_unsupported
- abstract_field_initializer
- abstract_sealed_class
- abstract_super_member_reference
- ambiguous_export
- ambiguous_extension_member_access
- ambiguous_import
- ambiguous_set_or_map_literal_both
- ambiguous_set_or_map_literal_either
- annotation_on_pointer_field
- argument_must_be_a_constant
- argument_must_be_native
- argument_type_not_assignable
- argument_type_not_assignable_to_error_handler
- assert_in_redirecting_constructor
- asset_directory_does_not_exist
- asset_does_not_exist
- asset_field_not_list
- asset_missing_path
- asset_not_string
- asset_not_string_or_map
- asset_path_not_string
- assignment_of_do_not_store
- assignment_to_const
- assignment_to_final
- assignment_to_final_local
- assignment_to_final_no_setter
- assignment_to_function
- assignment_to_method
- assignment_to_type
- async_for_in_wrong_context
- await_in_late_local_variable_initializer
- await_of_incompatible_type
- body_might_complete_normally
- body_might_complete_normally_catch_error
- body_might_complete_normally_nullable
- break_label_on_switch_member
- built_in_identifier_as_type
- built_in_identifier_in_declaration
- case_block_not_terminated
- case_expression_type_implements_equals
- case_expression_type_is_not_switch_expression_subtype
- cast_from_nullable_always_fails
- cast_from_null_always_fails
- cast_to_non_type
- class_used_as_mixin
- collection_element_from_deferred_library
- compound_implements_finalizable
- concrete_class_has_enum_superinterface
- concrete_class_with_abstract_member
- conflicting_constructor_and_static_member
- conflicting_generic_interfaces
- conflicting_type_variable_and_container
- conflicting_type_variable_and_member
- constant_pattern_never_matches_value_type
- constant_pattern_with_non_constant_expression
- const_constructor_param_type_mismatch
- const_constructor_with_field_initialized_by_non_const
- const_constructor_with_non_const_super
- const_constructor_with_non_final_field
- const_deferred_class
- const_initialized_with_non_constant_value
- const_initialized_with_non_constant_value_from_deferred_library
- const_instance_field
- const_map_key_not_primitive_equality
- const_not_initialized
- const_set_element_not_primitive_equality
- const_spread_expected_list_or_set
- const_spread_expected_map
- const_with_non_const
- const_with_non_constant_argument
- const_with_type_parameters
- continue_label_invalid
- creation_of_struct_or_union
- creation_with_non_type
- dead_code
- dead_code_catch_following_catch
- dead_code_on_catch_subtype
- dead_null_aware_expression
- default_list_constructor
- default_value_in_function_type
- default_value_in_redirecting_factory_constructor
- default_value_on_required_parameter
- deferred_import_of_extension
- definitely_unassigned_late_local_variable
- dependencies_field_not_map
- deprecated_colon_for_default_value
- deprecated_export_use
- deprecated_field
- deprecated_member_use
- deprecated_member_use_from_same_package
- deprecated_new_in_comment_reference
- deprecated_subtype_of_function
- disallowed_type_instantiation_expression
- division_optimization
- duplicate_constructor
- duplicate_definition
- duplicate_export
- duplicate_field_formal_parameter
- duplicate_field_name
- duplicate_hidden_name
- duplicate_ignore
- duplicate_import
- duplicate_named_argument
- duplicate_part
- duplicate_pattern_assignment_variable
- duplicate_pattern_field
- duplicate_rest_element_in_pattern
- duplicate_shown_name
- duplicate_variable_pattern
- empty_map_pattern
- empty_record_literal_with_comma
- empty_record_type_named_fields_list
- empty_record_type_with_comma
- empty_struct
- enum_constant_same_name_as_enclosing
- enum_constant_with_non_const_constructor
- enum_mixin_with_instance_variable
- enum_with_abstract_member
- enum_with_name_values
- equal_elements_in_const_set
- equal_elements_in_set
- equal_keys_in_const_map
- equal_keys_in_map
- equal_keys_in_map_pattern
- expected_one_list_pattern_type_arguments
- expected_one_list_type_arguments
- expected_one_set_type_arguments
- expected_two_map_pattern_type_arguments
- expected_two_map_type_arguments
- export_internal_library
- export_legacy_symbol
- export_of_non_library
- expression_in_map
- extends_non_class
- extension_as_expression
- extension_conflicting_static_and_instance
- extension_declares_abstract_member
- extension_declares_constructor
- extension_declares_instance_field
- extension_declares_member_of_object
- extension_override_access_to_static_member
- extension_override_argument_not_assignable
- extension_override_without_access
- extension_override_with_cascade
- extension_type_constructor_with_super_formal_parameter
- extension_type_constructor_with_super_invocation
- extension_type_declares_instance_field
- extension_type_declares_member_of_object
- extension_type_implements_disallowed_type
- extension_type_implements_itself
- extension_type_implements_not_supertype
- extension_type_implements_representation_not_supertype
- extension_type_inherited_member_conflict
- extension_type_representation_depends_on_itself
- extension_type_representation_type_bottom
- extension_type_with_abstract_member
- external_with_initializer
- extra_annotation_on_struct_field
- extra_positional_arguments
- extra_positional_arguments_could_be_named
- extra_size_annotation_carray
- ffi_native_invalid_duplicate_default_asset
- ffi_native_invalid_multiple_annotations
- ffi_native_must_be_external
- ffi_native_unexpected_number_of_parameters
- ffi_native_unexpected_number_of_parameters_with_receiver
- field_initialized_by_multiple_initializers
- field_initialized_in_initializer_and_declaration
- field_initialized_in_parameter_and_initializer
- field_initializer_factory_constructor
- field_initializer_in_struct
- field_initializer_not_assignable
- field_initializer_outside_constructor
- field_initializer_redirecting_constructor
- field_initializing_formal_not_assignable
- field_in_struct_with_initializer
- field_must_be_external_in_struct
- final_initialized_in_declaration_and_constructor
- final_not_initialized
- final_not_initialized_constructor
- flutter_field_not_map
- for_in_of_invalid_element_type
- for_in_of_invalid_type
- for_in_with_const_variable
- generic_method_type_instantiation_on_dynamic
- generic_struct_subclass
- getter_not_subtype_setter_types
- illegal_async_generator_return_type
- illegal_async_return_type
- illegal_concrete_enum_member
- illegal_enum_values
- illegal_sync_generator_return_type
- implements_non_class
- implements_repeated
- implements_super_class
- implicit_super_initializer_missing_arguments
- implicit_this_reference_in_initializer
- import_deferred_library_with_load_function
- import_internal_library
- import_of_legacy_library_into_null_safe
- import_of_non_library
- inconsistent_inheritance
- inconsistent_language_version_override
- inconsistent_pattern_variable_logical_or
- initializer_for_non_existent_field
- initializer_for_static_field
- initializing_formal_for_non_existent_field
- instance_access_to_static_member
- instance_member_access_from_factory
- instance_member_access_from_static
- instantiate_abstract_class
- instantiate_enum
- instantiate_type_alias_expands_to_type_parameter
- integer_literal_imprecise_as_double
- integer_literal_out_of_range
- invalid_annotation
- invalid_annotation_constant_value_from_deferred_library
- invalid_annotation_from_deferred_library
- invalid_annotation_target
- invalid_assignment
- invalid_dependency
- invalid_exception_value
- invalid_export_of_internal_element
- invalid_export_of_internal_element_indirectly
- invalid_extension_argument_count
- invalid_factory_method_decl
- invalid_factory_method_impl
- invalid_factory_name_not_a_class
- invalid_field_name
- invalid_field_type_in_struct
- invalid_implementation_override
- invalid_inline_function_type
- invalid_internal_annotation
- invalid_language_version_override
- invalid_literal_annotation
- invalid_modifier_on_constructor
- invalid_modifier_on_setter
- invalid_non_virtual_annotation
- invalid_null_aware_operator
- invalid_override
- invalid_override_of_non_virtual_member
- invalid_pattern_variable_in_shared_case_scope
- invalid_platforms_field
- invalid_reference_to_generative_enum_constructor
- invalid_reference_to_this
- invalid_return_type_for_catch_error
- invalid_sealed_annotation
- invalid_super_formal_parameter_location
- invalid_type_argument_in_const_literal
- invalid_uri
- invalid_use_of_covariant_in_extension
- invalid_use_of_internal_member
- invalid_use_of_null_value
- invalid_use_of_type_outside_library
- invalid_use_of_visible_for_overriding_member
- invalid_use_of_visible_for_testing_member
- invalid_visibility_annotation
- invalid_visible_for_overriding_annotation
- invalid_visible_outside_template_annotation
- invocation_of_extension_without_call
- invocation_of_non_function
- invocation_of_non_function_expression
- label_in_outer_scope
- label_undefined
- late_final_field_with_const_constructor
- late_final_local_already_assigned
- leaf_call_must_not_return_handle
- leaf_call_must_not_take_handle
- list_element_type_not_assignable
- main_first_positional_parameter_type
- main_has_required_named_parameters
- main_has_too_many_required_positional_parameters
- main_is_not_function
- map_entry_not_in_map
- map_key_type_not_assignable
- map_value_type_not_assignable
- mismatched_annotation_on_struct_field
- missing_annotation_on_struct_field
- missing_dart_library
- missing_default_value_for_parameter
- missing_dependency
- missing_enum_constant_in_switch
- missing_exception_value
- missing_field_type_in_struct
- missing_name
- missing_named_pattern_field_name
- missing_override_of_must_be_overridden
- missing_required_argument
- missing_required_param
- missing_return
- missing_size_annotation_carray
- missing_variable_pattern
- mixin_application_concrete_super_invoked_member_type
- mixin_application_not_implemented_interface
- mixin_application_no_concrete_super_invoked_member
- mixin_class_declaration_extends_not_object
- mixin_class_declares_constructor
- mixin_inherits_from_not_object
- mixin_instantiate
- mixin_of_non_class
- mixin_on_sealed_class
- mixin_super_class_constraint_deferred_class
- mixin_super_class_constraint_non_interface
- multiple_redirecting_constructor_invocations
- multiple_super_initializers
- must_be_a_native_function_type
- must_be_a_subtype
- must_be_immutable
- must_call_super
- must_return_void
- name_not_string
- native_field_invalid_type
- native_field_missing_type
- native_field_not_static
- new_with_undefined_constructor_default
- non_abstract_class_inherits_abstract_member
- non_bool_condition
- non_bool_expression
- non_bool_negation_expression
- non_bool_operand
- non_constant_annotation_constructor
- non_constant_case_expression
- non_constant_case_expression_from_deferred_library
- non_constant_default_value
- non_constant_default_value_from_deferred_library
- non_constant_list_element
- non_constant_map_element
- non_constant_map_key
- non_constant_map_pattern_key
- non_constant_map_value
- non_constant_relational_pattern_expression
- non_constant_set_element
- non_constant_type_argument
- non_const_argument_for_const_parameter
- non_const_call_to_literal_constructor
- non_const_generative_enum_constructor
- non_covariant_type_parameter_position_in_representation_type
- non_exhaustive_switch_expression
- non_exhaustive_switch_statement
- non_final_field_in_enum
- non_generative_constructor
- non_generative_implicit_constructor
- non_native_function_type_argument_to_pointer
- non_positive_array_dimension
- non_sized_type_argument
- non_sync_factory
- non_type_as_type_argument
- non_type_in_catch_clause
- non_void_return_for_operator
- non_void_return_for_setter
- not_assigned_potentially_non_nullable_local_variable
- not_a_type
- not_binary_operator
- not_enough_positional_arguments
- not_initialized_non_nullable_instance_field
- not_initialized_non_nullable_variable
- not_iterable_spread
- not_map_spread
- no_annotation_constructor_arguments
- no_combined_super_signature
- no_generative_constructors_in_superclass
- nullable_type_in_catch_clause
- nullable_type_in_extends_clause
- nullable_type_in_implements_clause
- nullable_type_in_on_clause
- nullable_type_in_with_clause
- null_argument_to_non_null_type
- null_check_always_fails
- obsolete_colon_for_default_value
- on_repeated
- optional_parameter_in_operator
- override_on_non_overriding_member
- packed_annotation
- packed_annotation_alignment
- part_of_different_library
- part_of_non_part
- part_of_unnamed_library
- path_does_not_exist
- path_not_posix
- path_pubspec_does_not_exist
- pattern_assignment_not_local_variable
- pattern_constant_from_deferred_library
- pattern_type_mismatch_in_irrefutable_context
- pattern_variable_assignment_inside_guard
- platform_value_disallowed
- positional_field_in_object_pattern
- positional_super_formal_parameter_with_positional_argument
- prefix_collides_with_top_level_member
- prefix_identifier_not_followed_by_dot
- prefix_shadowed_by_local_declaration
- private_collision_in_mixin_application
- private_optional_parameter
- private_setter
- read_potentially_unassigned_final
- record_literal_one_positional_no_trailing_comma
- record_type_one_positional_no_trailing_comma
- recursive_compile_time_constant
- recursive_constructor_redirect
- recursive_interface_inheritance
- redeclare_on_non_redeclaring_member
- redirect_generative_to_missing_constructor
- redirect_generative_to_non_generative_constructor
- redirect_to_abstract_class_constructor
- redirect_to_invalid_function_type
- redirect_to_invalid_return_type
- redirect_to_missing_constructor
- redirect_to_non_class
- redirect_to_non_const_constructor
- redirect_to_type_alias_expands_to_type_parameter
- referenced_before_declaration
- refutable_pattern_in_irrefutable_context
- relational_pattern_operand_type_not_assignable
- relational_pattern_operator_return_type_not_assignable_to_bool
- rest_element_in_map_pattern
- rethrow_outside_catch
- return_in_generative_constructor
- return_in_generator
- return_of_do_not_store
- return_of_invalid_type
- return_of_invalid_type_from_closure
- return_without_value
- sdk_version_async_exported_from_core
- sdk_version_as_expression_in_const_context
- sdk_version_bool_operator_in_const_context
- sdk_version_constructor_tearoffs
- sdk_version_eq_eq_operator_in_const_context
- sdk_version_extension_methods
- sdk_version_gt_gt_gt_operator
- sdk_version_is_expression_in_const_context
- sdk_version_never
- sdk_version_set_literal
- sdk_version_ui_as_code
- sdk_version_ui_as_code_in_const_context
- set_element_type_not_assignable
- shared_deferred_prefix
- size_annotation_dimensions
- static_access_to_instance_member
- subtype_of_base_or_final_is_not_base_final_or_sealed
- subtype_of_deferred_class
- subtype_of_disallowed_type
- subtype_of_ffi_class
- subtype_of_sealed_class
- subtype_of_struct_class
- supertype_expands_to_type_parameter
- super_formal_parameter_type_is_not_subtype_of_associated
- super_formal_parameter_without_associated_named
- super_formal_parameter_without_associated_positional
- super_invocation_not_last
- super_in_enum_constructor
- super_in_extension
- super_in_extension_type
- super_in_invalid_context
- super_in_redirecting_constructor
- switch_case_completes_normally
- switch_expression_not_assignable
- tearoff_of_generative_constructor_of_abstract_class
- text_direction_code_point_in_comment
- text_direction_code_point_in_literal
- throw_of_invalid_type
- top_level_cycle
- type_alias_cannot_reference_itself
- type_annotation_deferred_class
- type_argument_not_matching_bounds
- type_check_with_null
- type_parameter_referenced_by_static
- type_parameter_supertype_of_its_bound
- type_test_with_non_type
- type_test_with_undefined_name
- unchecked_use_of_nullable_value
- undefined_annotation
- undefined_class
- undefined_constructor_in_initializer
- undefined_enum_constant
- undefined_enum_constructor
- undefined_extension_getter
- undefined_extension_method
- undefined_extension_operator
- undefined_extension_setter
- undefined_function
- undefined_getter
- undefined_hidden_name
- undefined_identifier
- undefined_identifier_await
- undefined_method
- undefined_named_parameter
- undefined_operator
- undefined_prefixed_name
- undefined_referenced_parameter
- undefined_setter
- undefined_shown_name
- undefined_super_member
- unknown_platform
- unnecessary_cast
- unnecessary_dev_dependency
- unnecessary_final
- unnecessary_import
- unnecessary_nan_comparison
- unnecessary_non_null_assertion
- unnecessary_no_such_method
- unnecessary_null_assert_pattern
- unnecessary_null_check_pattern
- unnecessary_null_comparison
- unnecessary_question_mark
- unnecessary_set_literal
- unnecessary_type_check
- unqualified_reference_to_non_local_static_member
- unqualified_reference_to_static_member_of_extended_type
- unreachable_switch_case
- unreachable_switch_default
- unused_catch_clause
- unused_catch_stack
- unused_element
- unused_element_parameter
- unused_field
- unused_import
- unused_label
- unused_local_variable
- unused_result
- unused_shown_name
- uri_does_not_exist
- uri_does_not_exist_in_doc_import
- uri_has_not_been_generated
- uri_with_interpolation
- use_of_native_extension
- use_of_void_result
- values_declaration_in_enum
- variable_length_array_not_last
- variable_pattern_keyword_in_declaration_context
- variable_type_mismatch
- workspace_field_not_list
- workspace_value_not_string
- workspace_value_not_subdirectory
- wrong_number_of_parameters_for_operator
- wrong_number_of_parameters_for_setter
- wrong_number_of_type_arguments
- wrong_number_of_type_arguments_constructor
- wrong_number_of_type_arguments_enum
- wrong_number_of_type_arguments_extension
- wrong_number_of_type_arguments_method
- yield_in_non_generator
- yield_of_invalid_type
- always_declare_return_types
- always_put_control_body_on_new_line
- always_put_required_named_parameters_first
- always_use_package_imports
- annotate_overrides
- avoid_empty_else
- avoid_function_literals_in_foreach_calls
- avoid_futureor_void
- avoid_init_to_null
- avoid_print
- avoid_relative_lib_imports
- avoid_renaming_method_parameters
- avoid_return_types_on_setters
- avoid_returning_null_for_void
- avoid_shadowing_type_parameters
- avoid_single_cascade_in_expression_statements
- avoid_slow_async_io
- avoid_type_to_string
- avoid_types_as_parameter_names
- avoid_unnecessary_containers
- avoid_web_libraries_in_flutter
- await_only_futures
- camel_case_extensions
- camel_case_types
- cancel_subscriptions
- close_sinks
- collection_methods_unrelated_type
- constant_identifier_names
- control_flow_in_finally
- curly_braces_in_flow_control_structures
- dangling_library_doc_comments
- depend_on_referenced_packages
- empty_catches
- empty_constructor_bodies
- empty_statements
- file_names
- hash_and_equals
- implementation_imports
- implicit_call_tearoffs
- invalid_runtime_check_with_js_interop_types
- invalid_use_of_do_not_submit_member
- library_annotations
- library_names
- library_prefixes
- library_private_types_in_public_api
- literal_only_boolean_expressions
- no_adjacent_strings_in_list
- no_duplicate_case_values
- no_leading_underscores_for_library_prefixes
- no_leading_underscores_for_local_identifiers
- no_logic_in_create_state
- no_wildcard_variable_uses
- non_constant_identifier_names
- null_check_on_nullable_type_parameter
- overridden_fields
- package_names
- package_prefixed_library_names
- prefer_adjacent_string_concatenation
- prefer_collection_literals
- prefer_conditional_assignment
- prefer_const_constructors
- prefer_const_constructors_in_immutables
- prefer_const_declarations
- prefer_const_literals_to_create_immutables
- prefer_contains
- prefer_double_quotes
- prefer_final_fields
- prefer_for_elements_to_map_fromiterable
- prefer_function_declarations_over_variables
- prefer_generic_function_type_aliases
- prefer_if_null_operators
- prefer_initializing_formals
- prefer_inlined_adds
- prefer_interpolation_to_compose_strings
- prefer_is_empty
- prefer_is_not_empty
- prefer_is_not_operator
- prefer_iterable_wheretype
- prefer_null_aware_operators
- prefer_relative_imports
- prefer_single_quotes
- prefer_typing_uninitialized_variables
- prefer_void_to_null
- provide_deprecation_message
- recursive_getters
- secure_pubspec_urls
- sized_box_for_whitespace
- sized_box_shrink_expand
- slash_for_doc_comments
- sort_child_properties_last
- sort_constructors_first
- sort_pub_dependencies
- sort_unnamed_constructors_first
- test_types_in_equals
- throw_in_finally
- type_init_formals
- type_literal_in_constant_pattern
- unawaited_futures
- unintended_html_in_doc_comment
- unnecessary_brace_in_string_interps
- unnecessary_const
- unnecessary_constructor_name
- unnecessary_final
- unnecessary_getters_setters
- unnecessary_lambdas
- unnecessary_late
- unnecessary_library_name
- unnecessary_new
- unnecessary_null_aware_assignments
- unnecessary_null_in_if_null_operators
- unnecessary_nullable_for_final_variable_declarations
- unnecessary_overrides
- unnecessary_parenthesis
- unnecessary_raw_strings
- unnecessary_statements
- unnecessary_string_escapes
- unnecessary_string_interpolations
- unnecessary_this
- unnecessary_to_list_in_spreads
- unrelated_type_equality_checks
- unsafe_variance
- use_build_context_synchronously
- use_colored_box
- use_decorated_box
- use_full_hex_values_for_flutter_colors
- use_function_type_syntax_for_parameters
- use_if_null_to_convert_nulls_to_bools
- use_key_in_widget_constructors
- use_late_for_private_fields_and_variables
- use_named_constants
- use_raw_strings
- use_rethrow_when_possible
- use_setters_to_change_properties
- use_string_buffers
- use_string_in_part_of_directives
- use_super_parameters
- use_truncating_division
- valid_regexps
- void_checks
This page lists diagnostic messages produced by the Dart analyzer, with details about what those messages mean and how you can fix your code. For more information about the analyzer, see Customizing static analysis.
Diagnostics
#The analyzer produces the following diagnostics for code that doesn't conform to the language specification or that might work in unexpected ways.
abi_specific_integer_invalid
#Classes extending 'AbiSpecificInteger' must have exactly one const constructor, no other members, and no type parameters.
Description
#The analyzer produces this diagnostic when a class that extends AbiSpecificInteger
doesn't meet all of the following requirements:
- there must be exactly one constructor
- the constructor must be marked
const
- there must not be any members of other than the one constructor
- there must not be any type parameters
Examples
#The following code produces this diagnostic because the class C
doesn't define a const constructor:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
}
The following code produces this diagnostic because the constructor isn't a const
constructor:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
C();
}
The following code produces this diagnostic because the class C
defines multiple constructors:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
const C.zero();
const C.one();
}
The following code produces this diagnostic because the class C
defines a field:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
final int i;
const C(this.i);
}
The following code produces this diagnostic because the class C
has a type parameter:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C<T> extends AbiSpecificInteger { // type parameters
const C();
}
Common fixes
#Change the class so that it meets the requirements of having no type parameters and a single member that is a const
constructor:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
const C();
}
abi_specific_integer_mapping_extra
#Classes extending 'AbiSpecificInteger' must have exactly one 'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size.
Description
#The analyzer produces this diagnostic when a class that extends AbiSpecificInteger
has more than one AbiSpecificIntegerMapping
annotation.
Example
#The following code produces this diagnostic because there are two AbiSpecificIntegerMapping
annotations on the class C
:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
@AbiSpecificIntegerMapping({Abi.linuxX64 : Uint16()})
final class C extends AbiSpecificInteger {
const C();
}
Common fixes
#Remove all but one of the annotations, merging the arguments as appropriate:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8(), Abi.linuxX64 : Uint16()})
final class C extends AbiSpecificInteger {
const C();
}
abi_specific_integer_mapping_missing
#Classes extending 'AbiSpecificInteger' must have exactly one 'AbiSpecificIntegerMapping' annotation specifying the mapping from ABI to a 'NativeType' integer with a fixed size.
Description
#The analyzer produces this diagnostic when a class that extends AbiSpecificInteger
doesn't have an AbiSpecificIntegerMapping
annotation.
Example
#The following code produces this diagnostic because there's no AbiSpecificIntegerMapping
annotation on the class C
:
import 'dart:ffi';
final class C extends AbiSpecificInteger {
const C();
}
Common fixes
#Add an AbiSpecificIntegerMapping
annotation to the class:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
const C();
}
abi_specific_integer_mapping_unsupported
#Invalid mapping to '{0}'; only mappings to 'Int8', 'Int16', 'Int32', 'Int64', 'Uint8', 'Uint16', 'UInt32', and 'Uint64' are supported.
Description
#The analyzer produces this diagnostic when a value in the map argument of an AbiSpecificIntegerMapping
annotation is anything other than one of the following integer types:
Int8
Int16
Int32
Int64
Uint8
Uint16
UInt32
Uint64
Example
#The following code produces this diagnostic because the value of the map entry is Array<Uint8>
, which isn't a valid integer type:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Array<Uint8>(4)})
final class C extends AbiSpecificInteger {
const C();
}
Common fixes
#Use one of the valid types as a value in the map:
import 'dart:ffi';
@AbiSpecificIntegerMapping({Abi.macosX64 : Int8()})
final class C extends AbiSpecificInteger {
const C();
}
abstract_field_initializer
#Abstract fields can't have initializers.
Description
#The analyzer produces this diagnostic when a field that has the abstract
modifier also has an initializer.
Examples
#The following code produces this diagnostic because f
is marked as abstract
and has an initializer:
abstract class C {
abstract int f = 0;
}
The following code produces this diagnostic because f
is marked as abstract
and there's an initializer in the constructor:
abstract class C {
abstract int f;
C() : f = 0;
}
Common fixes
#If the field must be abstract, then remove the initializer:
abstract class C {
abstract int f;
}
If the field isn't required to be abstract, then remove the keyword:
abstract class C {
int f = 0;
}
abstract_sealed_class
#A 'sealed' class can't be marked 'abstract' because it's already implicitly abstract.
Description
#The analyzer produces this diagnostic when a class is declared using both the modifier abstract
and the modifier sealed
. Sealed classes are implicitly abstract, so explicitly using both modifiers is not allowed.
Example
#The following code produces this diagnostic because the class C
is declared using both abstract
and sealed
:
abstract sealed class C {}
Common fixes
#If the class should be abstract but not sealed, then remove the sealed
modifier:
abstract class C {}
If the class should be both abstract and sealed, then remove the abstract
modifier:
sealed class C {}
abstract_super_member_reference
#The {0} '{1}' is always abstract in the supertype.
Description
#The analyzer produces this diagnostic when an inherited member is referenced using super
, but there is no concrete implementation of the member in the superclass chain. Abstract members can't be invoked.
Example
#The following code produces this diagnostic because B
doesn't inherit a concrete implementation of a
:
abstract class A {
int get a;
}
class B extends A {
int get a => super.a;
}
Common fixes
#Remove the invocation of the abstract member, possibly replacing it with an invocation of a concrete member.
ambiguous_export
#The name '{0}' is defined in the libraries '{1}' and '{2}'.
Description
#The analyzer produces this diagnostic when two or more export directives cause the same name to be exported from multiple libraries.
Example
#Given a file a.dart
containing
class C {}
And a file b.dart
containing
class C {}
The following code produces this diagnostic because the name C
is being exported from both a.dart
and b.dart
:
export 'a.dart';
export 'b.dart';
Common fixes
#If none of the names in one of the libraries needs to be exported, then remove the unnecessary export directives:
export 'a.dart';
If all of the export directives are needed, then hide the name in all except one of the directives:
export 'a.dart';
export 'b.dart' hide C;
ambiguous_extension_member_access
#A member named '{0}' is defined in '{1}' and '{2}', and neither is more specific.
A member named '{0}' is defined in {1}, and none are more specific.
Description
#When code refers to a member of an object (for example, o.m()
or o.m
or o[i]
) where the static type of o
doesn't declare the member (m
or []
, for example), then the analyzer tries to find the member in an extension. For example, if the member is m
, then the analyzer looks for extensions that declare a member named m
and have an extended type that the static type of o
can be assigned to. When there's more than one such extension in scope, the extension whose extended type is most specific is selected.
The analyzer produces this diagnostic when none of the extensions has an extended type that's more specific than the extended types of all of the other extensions, making the reference to the member ambiguous.
Example
#The following code produces this diagnostic because there's no way to choose between the member in E1
and the member in E2
:
extension E1 on String {
int get charCount => 1;
}
extension E2 on String {
int get charCount => 2;
}
void f(String s) {
print(s.charCount);
}
Common fixes
#If you don't need both extensions, then you can delete or hide one of them.
If you need both, then explicitly select the one you want to use by using an extension override:
extension E1 on String {
int get charCount => length;
}
extension E2 on String {
int get charCount => length;
}
void f(String s) {
print(E2(s).charCount);
}
ambiguous_import
#The name '{0}' is defined in the libraries {1}.
Description
#The analyzer produces this diagnostic when a name is referenced that is declared in two or more imported libraries.
Example
#Given a library (a.dart
) that defines a class (C
in this example):
class A {}
class C {}
And a library (b.dart
) that defines a different class with the same name:
class B {}
class C {}
The following code produces this diagnostic:
import 'a.dart';
import 'b.dart';
void f(C c1, C c2) {}
Common fixes
#If any of the libraries aren't needed, then remove the import directives for them:
import 'a.dart';
void f(C c1, C c2) {}
If the name is still defined by more than one library, then add a hide
clause to the import directives for all except one library:
import 'a.dart' hide C;
import 'b.dart';
void f(C c1, C c2) {}
If you must be able to reference more than one of these types, then add a prefix to each of the import directives, and qualify the references with the appropriate prefix:
import 'a.dart' as a;
import 'b.dart' as b;
void f(a.C c1, b.C c2) {}
ambiguous_set_or_map_literal_both
#The literal can't be either a map or a set because it contains at least one literal map entry or a spread operator spreading a 'Map', and at least one element which is neither of these.
Description
#Because map and set literals use the same delimiters ({
and }
), the analyzer looks at the type arguments and the elements to determine which kind of literal you meant. When there are no type arguments, then the analyzer uses the types of the elements. If all of the elements are literal map entries and all of the spread operators are spreading a Map
then it's a Map
. If none of the elements are literal map entries and all of the spread operators are spreading an Iterable
, then it's a Set
. If neither of those is true then it's ambiguous.
The analyzer produces this diagnostic when at least one element is a literal map entry or a spread operator spreading a Map
, and at least one element is neither of these, making it impossible for the analyzer to determine whether you are writing a map literal or a set literal.
Example
#The following code produces this diagnostic:
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
{...a, ...b, ...c};
The list b
can only be spread into a set, and the maps a
and c
can only be spread into a map, and the literal can't be both.
Common fixes
#There are two common ways to fix this problem. The first is to remove all of the spread elements of one kind or another, so that the elements are consistent. In this case, that likely means removing the list and deciding what to do about the now unused parameter:
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
{...a, ...c};
The second fix is to change the elements of one kind into elements that are consistent with the other elements. For example, you can add the elements of the list as keys that map to themselves:
union(Map<String, String> a, List<String> b, Map<String, String> c) =>
{...a, for (String s in b) s: s, ...c};
ambiguous_set_or_map_literal_either
#This literal must be either a map or a set, but the elements don't have enough information for type inference to work.
Description
#Because map and set literals use the same delimiters ({
and }
), the analyzer looks at the type arguments and the elements to determine which kind of literal you meant. When there are no type arguments and all of the elements are spread elements (which are allowed in both kinds of literals) then the analyzer uses the types of the expressions that are being spread. If all of the expressions have the type Iterable
, then it's a set literal; if they all have the type Map
, then it's a map literal.
This diagnostic is produced when none of the expressions being spread have a type that allows the analyzer to decide whether you were writing a map literal or a set literal.
Example
#The following code produces this diagnostic:
union(a, b) => {...a, ...b};
The problem occurs because there are no type arguments, and there is no information about the type of either a
or b
.
Common fixes
#There are three common ways to fix this problem. The first is to add type arguments to the literal. For example, if the literal is intended to be a map literal, you might write something like this:
union(a, b) => <String, String>{...a, ...b};
The second fix is to add type information so that the expressions have either the type Iterable
or the type Map
. You can add an explicit cast or, in this case, add types to the declarations of the two parameters:
union(List<int> a, List<int> b) => {...a, ...b};
The third fix is to add context information. In this case, that means adding a return type to the function:
Set<String> union(a, b) => {...a, ...b};
In other cases, you might add a type somewhere else. For example, say the original code looks like this:
union(a, b) {
var x = {...a, ...b};
return x;
}
You might add a type annotation on x
, like this:
union(a, b) {
Map<String, String> x = {...a, ...b};
return x;
}
annotation_on_pointer_field
#Fields in a struct class whose type is 'Pointer' shouldn't have any annotations.
Description
#The analyzer produces this diagnostic when a field that's declared in a subclass of Struct
and has the type Pointer
also has an annotation associated with it.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the field p
, which has the type Pointer
and is declared in a subclass of Struct
, has the annotation @Double()
:
import 'dart:ffi';
final class C extends Struct {
@Double()
external Pointer<Int8> p;
}
Common fixes
#Remove the annotations from the field:
import 'dart:ffi';
final class C extends Struct {
external Pointer<Int8> p;
}
argument_must_be_a_constant
#Argument '{0}' must be a constant.
Description
#The analyzer produces this diagnostic when an invocation of either Pointer.asFunction
or DynamicLibrary.lookupFunction
has an isLeaf
argument whose value isn't a constant expression.
The analyzer also produces this diagnostic when an invocation of either Pointer.fromFunction
or NativeCallable.isolateLocal
has an exceptionalReturn
argument whose value isn't a constant expression.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the value of the isLeaf
argument is a parameter, and hence isn't a constant:
import 'dart:ffi';
int Function(int) fromPointer(
Pointer<NativeFunction<Int8 Function(Int8)>> p, bool isLeaf) {
return p.asFunction(isLeaf: isLeaf);
}
Common fixes
#If there's a suitable constant that can be used, then replace the argument with a constant:
import 'dart:ffi';
const isLeaf = false;
int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
return p.asFunction(isLeaf: isLeaf);
}
If there isn't a suitable constant, then replace the argument with a boolean literal:
import 'dart:ffi';
int Function(int) fromPointer(Pointer<NativeFunction<Int8 Function(Int8)>> p) {
return p.asFunction(isLeaf: true);
}
argument_must_be_native
#Argument to 'Native.addressOf' must be annotated with @Native
Description
#The analyzer produces this diagnostic when the argument passed to Native.addressOf
isn't annotated with the Native
annotation.
Examples
#The following code produces this diagnostic because the argument to addressOf
is a string, not a field, and strings can't be annotated:
import 'dart:ffi';
@Native<Void Function()>()
external void f();
void g() {
print(Native.addressOf('f'));
}
The following code produces this diagnostic because the function f
is being passed to addressOf
but isn't annotated as being Native
:
import 'dart:ffi';
external void f();
void g() {
print(Native.addressOf<NativeFunction<Void Function()>>(f));
}
Common fixes
#If the argument isn't either a field or a function, then replace the argument with a field or function that's annotated with Native
:
import 'dart:ffi';
@Native<Void Function()>()
external void f();
void g() {
print(Native.addressOf<NativeFunction<Void Function()>>(f));
}
If the argument is either a field or a function, then annotate the field of function with Native
:
import 'dart:ffi';
@Native<Void Function()>()
external void f();
void g() {
print(Native.addressOf<NativeFunction<Void Function()>>(f));
}
argument_type_not_assignable
#The argument type '{0}' can't be assigned to the parameter type '{1}'. {2}
Description
#The analyzer produces this diagnostic when the static type of an argument can't be assigned to the static type of the corresponding parameter.
Example
#The following code produces this diagnostic because a num
can't be assigned to a String
:
String f(String x) => x;
String g(num y) => f(y);
Common fixes
#If possible, rewrite the code so that the static type is assignable. In the example above you might be able to change the type of the parameter y
:
String f(String x) => x;
String g(String y) => f(y);
If that fix isn't possible, then add code to handle the case where the argument value isn't the required type. One approach is to coerce other types to the required type:
String f(String x) => x;
String g(num y) => f(y.toString());
Another approach is to add explicit type tests and fallback code:
String f(String x) => x;
String g(Object y) => f(y is String ? y : '');
If you believe that the runtime type of the argument will always be the same as the static type of the parameter, and you're willing to risk having an exception thrown at runtime if you're wrong, then add an explicit cast:
String f(String x) => x;
String g(num y) => f(y as String);
argument_type_not_assignable_to_error_handler
#The argument type '{0}' can't be assigned to the parameter type '{1} Function(Object)' or '{1} Function(Object, StackTrace)'.
Description
#The analyzer produces this diagnostic when an invocation of Future.catchError
has an argument that is a function whose parameters aren't compatible with the arguments that will be passed to the function when it's invoked. The static type of the first argument to catchError
is just Function
, even though the function that is passed in is expected to have either a single parameter of type Object
or two parameters of type Object
and StackTrace
.
Examples
#The following code produces this diagnostic because the closure being passed to catchError
doesn't take any parameters, but the function is required to take at least one parameter:
void f(Future<int> f) {
f.catchError(() => 0);
}
The following code produces this diagnostic because the closure being passed to catchError
takes three parameters, but it can't have more than two required parameters:
void f(Future<int> f) {
f.catchError((one, two, three) => 0);
}
The following code produces this diagnostic because even though the closure being passed to catchError
takes one parameter, the closure doesn't have a type that is compatible with Object
:
void f(Future<int> f) {
f.catchError((String error) => 0);
}
Common fixes
#Change the function being passed to catchError
so that it has either one or two required parameters, and the parameters have the required types:
void f(Future<int> f) {
f.catchError((Object error) => 0);
}
assert_in_redirecting_constructor
#A redirecting constructor can't have an 'assert' initializer.
Description
#The analyzer produces this diagnostic when a redirecting constructor (a constructor that redirects to another constructor in the same class) has an assert in the initializer list.
Example
#The following code produces this diagnostic because the unnamed constructor is a redirecting constructor and also has an assert in the initializer list:
class C {
C(int x) : assert(x > 0), this.name();
C.name() {}
}
Common fixes
#If the assert isn't needed, then remove it:
class C {
C(int x) : this.name();
C.name() {}
}
If the assert is needed, then convert the constructor into a factory constructor:
class C {
factory C(int x) {
assert(x > 0);
return C.name();
}
C.name() {}
}
asset_directory_does_not_exist
#The asset directory '{0}' doesn't exist.
Description
#The analyzer produces this diagnostic when an asset list contains a value referencing a directory that doesn't exist.
Example
#Assuming that the directory assets
doesn't exist, the following code produces this diagnostic because it's listed as a directory containing assets:
name: example
flutter:
assets:
- assets/
Common fixes
#If the path is correct, then create a directory at that path.
If the path isn't correct, then change the path to match the path of the directory containing the assets.
asset_does_not_exist
#The asset file '{0}' doesn't exist.
Description
#The analyzer produces this diagnostic when an asset list contains a value referencing a file that doesn't exist.
Example
#Assuming that the file doesNotExist.gif
doesn't exist, the following code produces this diagnostic because it's listed as an asset:
name: example
flutter:
assets:
- doesNotExist.gif
Common fixes
#If the path is correct, then create a file at that path.
If the path isn't correct, then change the path to match the path of the file containing the asset.
asset_field_not_list
#The value of the 'assets' field is expected to be a list of relative file paths.
Description
#The analyzer produces this diagnostic when the value of the assets
key isn't a list.
Example
#The following code produces this diagnostic because the value of the assets
key is a string when a list is expected:
name: example
flutter:
assets: assets/
Common fixes
#Change the value of the asset list so that it's a list:
name: example
flutter:
assets:
- assets/
asset_missing_path
#Asset map entry must contain a 'path' field.
Description
#The analyzer produces this diagnostic when an asset map is missing a path
value.
Example
#The following code produces this diagnostic because the asset map is missing a path
value:
name: example
flutter:
assets:
- flavors:
- premium
Common fixes
#Change the asset map so that it contains a path
field with a string value (a valid POSIX-style file path):
name: example
flutter:
assets:
- path: assets/image.gif
flavors:
- premium
asset_not_string
#Assets are required to be file paths (strings).
Description
#The analyzer produces this diagnostic when an assets
list contains a value that isn't a string.
Example
#The following code produces this diagnostic because the assets
list contains a map:
name: example
flutter:
assets:
- image.gif: true
Common fixes
#Change the assets
list so that it only contains valid POSIX-style file paths:
name: example
flutter:
assets:
- assets/image.gif
asset_not_string_or_map
#An asset value is required to be a file path (string) or map.
Description
#The analyzer produces this diagnostic when an asset value isn't a string or a map.
Example
#The following code produces this diagnostic because the asset value is a list:
name: example
flutter:
assets:
- [one, two, three]
Common fixes
#If you need to specify more than just the path to the asset, then replace the value with a map with a path
key (a valid POSIX-style file path):
name: example
flutter:
assets:
- path: assets/image.gif
flavors:
- premium
If you only need to specify the path, then replace the value with the path to the asset (a valid POSIX-style file path):
name: example
flutter:
assets:
- assets/image.gif
asset_path_not_string
#Asset paths are required to be file paths (strings).
Description
#The analyzer produces this diagnostic when an asset map contains a path
value that isn't a string.
Example
#The following code produces this diagnostic because the asset map contains a path
value which is a list:
name: example
flutter:
assets:
- path: [one, two, three]
flavors:
- premium
Common fixes
#Change the asset
map so that it contains a path
value which is a string (a valid POSIX-style file path):
name: example
flutter:
assets:
- path: image.gif
flavors:
- premium
assignment_of_do_not_store
#'{0}' is marked 'doNotStore' and shouldn't be assigned to a field or top-level variable.
Description
#The analyzer produces this diagnostic when the value of a function (including methods and getters) that is explicitly or implicitly marked by the doNotStore
annotation is stored in either a field or top-level variable.
Example
#The following code produces this diagnostic because the value of the function f
is being stored in the top-level variable x
:
import 'package:meta/meta.dart';
@doNotStore
int f() => 1;
var x = f();
Common fixes
#Replace references to the field or variable with invocations of the function producing the value.
assignment_to_const
#Constant variables can't be assigned a value.
Description
#The analyzer produces this diagnostic when it finds an assignment to a top-level variable, a static field, or a local variable that has the const
modifier. The value of a compile-time constant can't be changed at runtime.
Example
#The following code produces this diagnostic because c
is being assigned a value even though it has the const
modifier:
const c = 0;
void f() {
c = 1;
print(c);
}
Common fixes
#If the variable must be assignable, then remove the const
modifier:
var c = 0;
void f() {
c = 1;
print(c);
}
If the constant shouldn't be changed, then either remove the assignment or use a local variable in place of references to the constant:
const c = 0;
void f() {
var v = 1;
print(v);
}
assignment_to_final
#'{0}' can't be used as a setter because it's final.
Description
#The analyzer produces this diagnostic when it finds an invocation of a setter, but there's no setter because the field with the same name was declared to be final
or const
.
Example
#The following code produces this diagnostic because v
is final:
class C {
final v = 0;
}
f(C c) {
c.v = 1;
}
Common fixes
#If you need to be able to set the value of the field, then remove the modifier final
from the field:
class C {
int v = 0;
}
f(C c) {
c.v = 1;
}
assignment_to_final_local
#The final variable '{0}' can only be set once.
Description
#The analyzer produces this diagnostic when a local variable that was declared to be final is assigned after it was initialized.
Example
#The following code produces this diagnostic because x
is final, so it can't have a value assigned to it after it was initialized:
void f() {
final x = 0;
x = 3;
print(x);
}
Common fixes
#Remove the keyword final
, and replace it with var
if there's no type annotation:
void f() {
var x = 0;
x = 3;
print(x);
}
assignment_to_final_no_setter
#There isn't a setter named '{0}' in class '{1}'.
Description
#The analyzer produces this diagnostic when a reference to a setter is found; there is no setter defined for the type; but there is a getter defined with the same name.
Example
#The following code produces this diagnostic because there is no setter named x
in C
, but there is a getter named x
:
class C {
int get x => 0;
set y(int p) {}
}
void f(C c) {
c.x = 1;
}
Common fixes
#If you want to invoke an existing setter, then correct the name:
class C {
int get x => 0;
set y(int p) {}
}
void f(C c) {
c.y = 1;
}
If you want to invoke the setter but it just doesn't exist yet, then declare it:
class C {
int get x => 0;
set x(int p) {}
set y(int p) {}
}
void f(C c) {
c.x = 1;
}
assignment_to_function
#Functions can't be assigned a value.
Description
#The analyzer produces this diagnostic when the name of a function appears on the left-hand side of an assignment expression.
Example
#The following code produces this diagnostic because the assignment to the function f
is invalid:
void f() {}
void g() {
f = () {};
}
Common fixes
#If the right-hand side should be assigned to something else, such as a local variable, then change the left-hand side:
void f() {}
void g() {
var x = () {};
print(x);
}
If the intent is to change the implementation of the function, then define a function-valued variable instead of a function:
void Function() f = () {};
void g() {
f = () {};
}
assignment_to_method
#Methods can't be assigned a value.
Description
#The analyzer produces this diagnostic when the target of an assignment is a method.
Example
#The following code produces this diagnostic because f
can't be assigned a value because it's a method:
class C {
void f() {}
void g() {
f = null;
}
}
Common fixes
#Rewrite the code so that there isn't an assignment to a method.
assignment_to_type
#Types can't be assigned a value.
Description
#The analyzer produces this diagnostic when the name of a type name appears on the left-hand side of an assignment expression.
Example
#The following code produces this diagnostic because the assignment to the class C
is invalid:
class C {}
void f() {
C = null;
}
Common fixes
#If the right-hand side should be assigned to something else, such as a local variable, then change the left-hand side:
void f() {}
void g() {
var c = null;
print(c);
}
async_for_in_wrong_context
#The async for-in loop can only be used in an async function.
Description
#The analyzer produces this diagnostic when an async for-in loop is found in a function or method whose body isn't marked as being either async
or async*
.
Example
#The following code produces this diagnostic because the body of f
isn't marked as being either async
or async*
, but f
contains an async for-in loop:
void f(list) {
await for (var e in list) {
print(e);
}
}
Common fixes
#If the function should return a Future
, then mark the body with async
:
Future<void> f(list) async {
await for (var e in list) {
print(e);
}
}
If the function should return a Stream
of values, then mark the body with async*
:
Stream<void> f(list) async* {
await for (var e in list) {
print(e);
}
}
If the function should be synchronous, then remove the await
before the loop:
void f(list) {
for (var e in list) {
print(e);
}
}
await_in_late_local_variable_initializer
#The 'await' expression can't be used in a 'late' local variable's initializer.
Description
#The analyzer produces this diagnostic when a local variable that has the late
modifier uses an await
expression in the initializer.
Example
#The following code produces this diagnostic because an await
expression is used in the initializer for v
, a local variable that is marked late
:
Future<int> f() async {
late var v = await 42;
return v;
}
Common fixes
#If the initializer can be rewritten to not use await
, then rewrite it:
Future<int> f() async {
late var v = 42;
return v;
}
If the initializer can't be rewritten, then remove the late
modifier:
Future<int> f() async {
var v = await 42;
return v;
}
await_of_incompatible_type
#The 'await' expression can't be used for an expression with an extension type that is not a subtype of 'Future'.
Description
#The analyzer produces this diagnostic when the type of the expression in an await
expression is an extension type, and the extension type isn't a subclass of Future
.
Example
#The following code produces this diagnostic because the extension type E
isn't a subclass of Future
:
extension type E(int i) {}
void f(E e) async {
await e;
}
Common fixes
#If the extension type is correctly defined, then remove the await
:
extension type E(int i) {}
void f(E e) {
e;
}
If the extension type is intended to be awaitable, then add Future
(or a subtype of Future
) to the implements
clause (adding an implements
clause if there isn't one already), and make the representation type match:
extension type E(Future<int> i) implements Future<int> {}
void f(E e) async {
await e;
}
body_might_complete_normally
#The body might complete normally, causing 'null' to be returned, but the return type, '{0}', is a potentially non-nullable type.
Description
#The analyzer produces this diagnostic when a method or function has a return type that's potentially non-nullable but would implicitly return null
if control reached the end of the function.
Examples
#The following code produces this diagnostic because the method m
has an implicit return of null
inserted at the end of the method, but the method is declared to not return null
:
class C {
int m(int t) {
print(t);
}
}
The following code produces this diagnostic because the method m
has an implicit return of null
inserted at the end of the method, but because the class C
can be instantiated with a non-nullable type argument, the method is effectively declared to not return null
:
class C<T> {
T m(T t) {
print(t);
}
}
Common fixes
#If there's a reasonable value that can be returned, then add a return
statement at the end of the method:
class C<T> {
T m(T t) {
print(t);
return t;
}
}
If the method won't reach the implicit return, then add a throw
at the end of the method:
class C<T> {
T m(T t) {
print(t);
throw '';
}
}
If the method intentionally returns null
at the end, then add an explicit return of null
at the end of the method and change the return type so that it's valid to return null
:
class C<T> {
T? m(T t) {
print(t);
return null;
}
}
body_might_complete_normally_catch_error
#This 'onError' handler must return a value assignable to '{0}', but ends without returning a value.
Description
#The analyzer produces this diagnostic when the closure passed to the onError
parameter of the Future.catchError
method is required to return a non-null
value (because of the Future
s type argument) but can implicitly return null
.
Example
#The following code produces this diagnostic because the closure passed to the catchError
method is required to return an int
but doesn't end with an explicit return
, causing it to implicitly return null
:
void g(Future<int> f) {
f.catchError((e, st) {});
}
Common fixes
#If the closure should sometimes return a non-null
value, then add an explicit return to the closure:
void g(Future<int> f) {
f.catchError((e, st) {
return -1;
});
}
If the closure should always return null
, then change the type argument of the Future
to be either void
or Null
:
void g(Future<void> f) {
f.catchError((e, st) {});
}
body_might_complete_normally_nullable
#This function has a nullable return type of '{0}', but ends without returning a value.
Description
#The analyzer produces this diagnostic when a method or function can implicitly return null
by falling off the end. While this is valid Dart code, it's better for the return of null
to be explicit.
Example
#The following code produces this diagnostic because the function f
implicitly returns null
:
String? f() {}
Common fixes
#If the return of null
is intentional, then make it explicit:
String? f() {
return null;
}
If the function should return a non-null value along that path, then add the missing return statement:
String? f() {
return '';
}
break_label_on_switch_member
#A break label resolves to the 'case' or 'default' statement.
Description
#The analyzer produces this diagnostic when a break in a case clause inside a switch statement has a label that is associated with another case clause.
Example
#The following code produces this diagnostic because the label l
is associated with the case clause for 0
:
void f(int i) {
switch (i) {
l: case 0:
break;
case 1:
break l;
}
}
Common fixes
#If the intent is to transfer control to the statement after the switch, then remove the label from the break statement:
void f(int i) {
switch (i) {
case 0:
break;
case 1:
break;
}
}
If the intent is to transfer control to a different case block, then use continue
rather than break
:
void f(int i) {
switch (i) {
l: case 0:
break;
case 1:
continue l;
}
}
built_in_identifier_as_type
#The built-in identifier '{0}' can't be used as a type.
Description
#The analyzer produces this diagnostic when a built-in identifier is used where a type name is expected.
Example
#The following code produces this diagnostic because import
can't be used as a type because it's a built-in identifier:
import<int> x;
Common fixes
#Replace the built-in identifier with the name of a valid type:
List<int> x;
built_in_identifier_in_declaration
#The built-in identifier '{0}' can't be used as a prefix name.
The built-in identifier '{0}' can't be used as a type name.
The built-in identifier '{0}' can't be used as a type parameter name.
The built-in identifier '{0}' can't be used as a typedef name.
The built-in identifier '{0}' can't be used as an extension name.
The built-in identifier '{0}' can't be used as an extension type name.
Description
#The analyzer produces this diagnostic when the name used in the declaration of a class, extension, mixin, typedef, type parameter, or import prefix is a built-in identifier. Built-in identifiers can't be used to name any of these kinds of declarations.
Example
#The following code produces this diagnostic because mixin
is a built-in identifier:
extension mixin on int {}
Common fixes
#Choose a different name for the declaration.
case_block_not_terminated
#The last statement of the 'case' should be 'break', 'continue', 'rethrow', 'return', or 'throw'.
Description
#The analyzer produces this diagnostic when the last statement in a case
block isn't one of the required terminators: break
, continue
, rethrow
, return
, or throw
.
Example
#The following code produces this diagnostic because the case
block ends with an assignment:
void f(int x) {
switch (x) {
case 0:
x += 2;
default:
x += 1;
}
}
Common fixes
#Add one of the required terminators:
void f(int x) {
switch (x) {
case 0:
x += 2;
break;
default:
x += 1;
}
}
case_expression_type_implements_equals
#The switch case expression type '{0}' can't override the '==' operator.
Description
#The analyzer produces this diagnostic when the type of the expression following the keyword case
has an implementation of the ==
operator other than the one in Object
.
Example
#The following code produces this diagnostic because the expression following the keyword case
(C(0)
) has the type C
, and the class C
overrides the ==
operator:
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
switch (c) {
case C(0):
break;
}
}
Common fixes
#If there isn't a strong reason not to do so, then rewrite the code to use an if-else structure:
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
if (c == C(0)) {
// ...
}
}
If you can't rewrite the switch statement and the implementation of ==
isn't necessary, then remove it:
class C {
final int value;
const C(this.value);
}
void f(C c) {
switch (c) {
case C(0):
break;
}
}
If you can't rewrite the switch statement and you can't remove the definition of ==
, then find some other value that can be used to control the switch:
class C {
final int value;
const C(this.value);
bool operator ==(Object other) {
return false;
}
}
void f(C c) {
switch (c.value) {
case 0:
break;
}
}
case_expression_type_is_not_switch_expression_subtype
#The switch case expression type '{0}' must be a subtype of the switch expression type '{1}'.
Description
#The analyzer produces this diagnostic when the expression following case
in a switch
statement has a static type that isn't a subtype of the static type of the expression following switch
.
Example
#The following code produces this diagnostic because 1
is an int
, which isn't a subtype of String
(the type of s
):
void f(String s) {
switch (s) {
case 1:
break;
}
}
Common fixes
#If the value of the case
expression is wrong, then change the case
expression so that it has the required type:
void f(String s) {
switch (s) {
case '1':
break;
}
}
If the value of the case
expression is correct, then change the switch
expression to have the required type:
void f(int s) {
switch (s) {
case 1:
break;
}
}
cast_from_nullable_always_fails
#This cast will always throw an exception because the nullable local variable '{0}' is not assigned.
Description
#The analyzer produces this diagnostic when a local variable that has a nullable type hasn't been assigned and is cast to a non-nullable type. Because the variable hasn't been assigned it has the default value of null
, causing the cast to throw an exception.
Example
#The following code produces this diagnostic because the variable x
is cast to a non-nullable type (int
) when it's known to have the value null
:
void f() {
num? x;
x as int;
print(x);
}
Common fixes
#If the variable is expected to have a value before the cast, then add an initializer or an assignment:
void f() {
num? x = 3;
x as int;
print(x);
}
If the variable isn't expected to be assigned, then remove the cast:
void f() {
num? x;
print(x);
}
cast_from_null_always_fails
#This cast always throws an exception because the expression always evaluates to 'null'.
Description
#The analyzer produces this diagnostic when an expression whose type is Null
is being cast to a non-nullable type.
Example
#The following code produces this diagnostic because n
is known to always be null
, but it's being cast to a non-nullable type:
void f(Null n) {
n as int;
}
Common fixes
#Remove the unnecessary cast:
void f(Null n) {
n;
}
cast_to_non_type
#The name '{0}' isn't a type, so it can't be used in an 'as' expression.
Description
#The analyzer produces this diagnostic when the name following the as
in a cast expression is defined to be something other than a type.
Example
#The following code produces this diagnostic because x
is a variable, not a type:
num x = 0;
int y = x as x;
Common fixes
#Replace the name with the name of a type:
num x = 0;
int y = x as int;
class_used_as_mixin
#The class '{0}' can't be used as a mixin because it's neither a mixin class nor a mixin.
Description
#The analyzer produces this diagnostic when a class that is neither a mixin class
nor a mixin
is used in a with
clause.
Example
#The following code produces this diagnostic because the class M
is being used as a mixin, but it isn't defined as a mixin class
:
class M {}
class C with M {}
Common fixes
#If the class can be a pure mixin, then change class
to mixin
:
mixin M {}
class C with M {}
If the class needs to be both a class and a mixin, then add mixin
:
mixin class M {}
class C with M {}
collection_element_from_deferred_library
#Constant values from a deferred library can't be used as keys in a 'const' map literal.
Constant values from a deferred library can't be used as values in a 'const' constructor.
Constant values from a deferred library can't be used as values in a 'const' list literal.
Constant values from a deferred library can't be used as values in a 'const' map literal.
Constant values from a deferred library can't be used as values in a 'const' set literal.
Description
#The analyzer produces this diagnostic when a collection literal that is either explicitly (because it's prefixed by the const
keyword) or implicitly (because it appears in a constant context) a constant contains a value that is declared in a library that is imported using a deferred import. Constants are evaluated at compile time, and values from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#Given a file a.dart
that defines the constant zero
:
const zero = 0;
The following code produces this diagnostic because the constant list literal contains a.zero
, which is imported using a deferred
import:
import 'a.dart' deferred as a;
var l = const [a.zero];
Common fixes
#If the collection literal isn't required to be constant, then remove the const
keyword:
import 'a.dart' deferred as a;
var l = [a.zero];
If the collection is required to be constant and the imported constant must be referenced, then remove the keyword deferred
from the import:
import 'a.dart' as a;
var l = const [a.zero];
If you don't need to reference the constant, then replace it with a suitable value:
var l = const [0];
compound_implements_finalizable
#The class '{0}' can't implement Finalizable.
Description
#The analyzer produces this diagnostic when a subclass of either Struct
or Union
implements Finalizable
.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the class S
implements Finalizable
:
import 'dart:ffi';
final class S extends Struct implements Finalizable {
external Pointer notEmpty;
}
Common fixes
#Try removing the implements clause from the class:
import 'dart:ffi';
final class S extends Struct {
external Pointer notEmpty;
}
concrete_class_has_enum_superinterface
#Concrete classes can't have 'Enum' as a superinterface.
Description
#The analyzer produces this diagnostic when a concrete class indirectly has the class Enum
as a superinterface.
Example
#The following code produces this diagnostic because the concrete class B
has Enum
as a superinterface as a result of implementing A
:
abstract class A implements Enum {}
class B implements A {}
Common fixes
#If the implemented class isn't the class you intend to implement, then change it:
abstract class A implements Enum {}
class B implements C {}
class C {}
If the implemented class can be changed to not implement Enum
, then do so:
abstract class A {}
class B implements A {}
If the implemented class can't be changed to not implement Enum
, then remove it from the implements
clause:
abstract class A implements Enum {}
class B {}
concrete_class_with_abstract_member
#'{0}' must have a method body because '{1}' isn't abstract.
Description
#The analyzer produces this diagnostic when a member of a concrete class is found that doesn't have a concrete implementation. Concrete classes aren't allowed to contain abstract members.
Example
#The following code produces this diagnostic because m
is an abstract method but C
isn't an abstract class:
class C {
void m();
}
Common fixes
#If it's valid to create instances of the class, provide an implementation for the member:
class C {
void m() {}
}
If it isn't valid to create instances of the class, mark the class as being abstract:
abstract class C {
void m();
}
conflicting_constructor_and_static_member
#'{0}' can't be used to name both a constructor and a static field in this class.
'{0}' can't be used to name both a constructor and a static getter in this class.
'{0}' can't be used to name both a constructor and a static method in this class.
'{0}' can't be used to name both a constructor and a static setter in this class.
Description
#The analyzer produces this diagnostic when a named constructor and either a static method or static field have the same name. Both are accessed using the name of the class, so having the same name makes the reference ambiguous.
Examples
#The following code produces this diagnostic because the static field foo
and the named constructor foo
have the same name:
class C {
C.foo();
static int foo = 0;
}
The following code produces this diagnostic because the static method foo
and the named constructor foo
have the same name:
class C {
C.foo();
static void foo() {}
}
Common fixes
#Rename either the member or the constructor.
conflicting_generic_interfaces
#The {0} '{1}' can't implement both '{2}' and '{3}' because the type arguments are different.
Description
#The analyzer produces this diagnostic when a class attempts to implement a generic interface multiple times, and the values of the type arguments aren't the same.
Example
#The following code produces this diagnostic because C
is defined to implement both I<int>
(because it extends A
) and I<String>
(because it implementsB
), but int
and String
aren't the same type:
class I<T> {}
class A implements I<int> {}
class B implements I<String> {}
class C extends A implements B {}
Common fixes
#Rework the type hierarchy to avoid this situation. For example, you might make one or both of the inherited types generic so that C
can specify the same type for both type arguments:
class I<T> {}
class A<S> implements I<S> {}
class B implements I<String> {}
class C extends A<String> implements B {}
conflicting_type_variable_and_container
#'{0}' can't be used to name both a type parameter and the class in which the type parameter is defined.
'{0}' can't be used to name both a type parameter and the enum in which the type parameter is defined.
'{0}' can't be used to name both a type parameter and the extension in which the type parameter is defined.
'{0}' can't be used to name both a type parameter and the extension type in which the type parameter is defined.
'{0}' can't be used to name both a type parameter and the mixin in which the type parameter is defined.
Description
#The analyzer produces this diagnostic when a class, mixin, or extension declaration declares a type parameter with the same name as the class, mixin, or extension that declares it.
Example
#The following code produces this diagnostic because the type parameter C
has the same name as the class C
of which it's a part:
class C<C> {}
Common fixes
#Rename either the type parameter, or the class, mixin, or extension:
class C<T> {}
conflicting_type_variable_and_member
#'{0}' can't be used to name both a type parameter and a member in this class.
'{0}' can't be used to name both a type parameter and a member in this enum.
'{0}' can't be used to name both a type parameter and a member in this extension type.
'{0}' can't be used to name both a type parameter and a member in this extension.
'{0}' can't be used to name both a type parameter and a member in this mixin.
Description
#The analyzer produces this diagnostic when a class, mixin, or extension declaration declares a type parameter with the same name as one of the members of the class, mixin, or extension that declares it.
Example
#The following code produces this diagnostic because the type parameter T
has the same name as the field T
:
class C<T> {
int T = 0;
}
Common fixes
#Rename either the type parameter or the member with which it conflicts:
class C<T> {
int total = 0;
}
constant_pattern_never_matches_value_type
#The matched value type '{0}' can never be equal to this constant of type '{1}'.
Description
#The analyzer produces this diagnostic when a constant pattern can never match the value it's being tested against because the type of the constant is known to never match the type of the value.
Example
#The following code produces this diagnostic because the type of the constant pattern (true)
is bool
, and the type of the value being matched (x
) is int
, and a Boolean can never match an integer:
void f(int x) {
if (x case true) {}
}
Common fixes
#If the type of the value is correct, then rewrite the pattern to be compatible:
void f(int x) {
if (x case 3) {}
}
If the type of the constant is correct, then rewrite the value to be compatible:
void f(bool x) {
if (x case true) {}
}
constant_pattern_with_non_constant_expression
#The expression of a constant pattern must be a valid constant.
Description
#The analyzer produces this diagnostic when a constant pattern has an expression that isn't a valid constant.
Example
#The following code produces this diagnostic because the constant pattern i
isn't a constant:
void f(int e, int i) {
switch (e) {
case i:
break;
}
}
Common fixes
#If the value that should be matched is known, then replace the expression with a constant:
void f(int e, int i) {
switch (e) {
case 0:
break;
}
}
If the value that should be matched isn't known, then rewrite the code to not use a pattern:
void f(int e, int i) {
if (e == i) {}
}
const_constructor_param_type_mismatch
#A value of type '{0}' can't be assigned to a parameter of type '{1}' in a const constructor.
Description
#The analyzer produces this diagnostic when the runtime type of a constant value can't be assigned to the static type of a constant constructor's parameter.
Example
#The following code produces this diagnostic because the runtime type of i
is int
, which can't be assigned to the static type of s
:
class C {
final String s;
const C(this.s);
}
const dynamic i = 0;
void f() {
const C(i);
}
Common fixes
#Pass a value of the correct type to the constructor:
class C {
final String s;
const C(this.s);
}
const dynamic i = 0;
void f() {
const C('$i');
}
const_constructor_with_field_initialized_by_non_const
#Can't define the 'const' constructor because the field '{0}' is initialized with a non-constant value.
Description
#The analyzer produces this diagnostic when a constructor has the keyword const
, but a field in the class is initialized to a non-constant value.
Example
#The following code produces this diagnostic because the field s
is initialized to a non-constant value:
String x = '3';
class C {
final String s = x;
const C();
}
Common fixes
#If the field can be initialized to a constant value, then change the initializer to a constant expression:
class C {
final String s = '3';
const C();
}
If the field can't be initialized to a constant value, then remove the keyword const
from the constructor:
String x = '3';
class C {
final String s = x;
C();
}
const_constructor_with_non_const_super
#A constant constructor can't call a non-constant super constructor of '{0}'.
Description
#The analyzer produces this diagnostic when a constructor that is marked as const
invokes a constructor from its superclass that isn't marked as const
.
Example
#The following code produces this diagnostic because the const
constructor in B
invokes the constructor nonConst
from the class A
, and the superclass constructor isn't a const
constructor:
class A {
const A();
A.nonConst();
}
class B extends A {
const B() : super.nonConst();
}
Common fixes
#If it isn't essential to invoke the superclass constructor that is currently being invoked, then invoke a constant constructor from the superclass:
class A {
const A();
A.nonConst();
}
class B extends A {
const B() : super();
}
If it's essential that the current constructor be invoked and if you can modify it, then add const
to the constructor in the superclass:
class A {
const A();
const A.nonConst();
}
class B extends A {
const B() : super.nonConst();
}
If it's essential that the current constructor be invoked and you can't modify it, then remove const
from the constructor in the subclass:
class A {
const A();
A.nonConst();
}
class B extends A {
B() : super.nonConst();
}
const_constructor_with_non_final_field
#Can't define a const constructor for a class with non-final fields.
Description
#The analyzer produces this diagnostic when a constructor is marked as a const constructor, but the constructor is defined in a class that has at least one non-final instance field (either directly or by inheritance).
Example
#The following code produces this diagnostic because the field x
isn't final:
class C {
int x;
const C(this.x);
}
Common fixes
#If it's possible to mark all of the fields as final, then do so:
class C {
final int x;
const C(this.x);
}
If it isn't possible to mark all of the fields as final, then remove the keyword const
from the constructor:
class C {
int x;
C(this.x);
}
const_deferred_class
#Deferred classes can't be created with 'const'.
Description
#The analyzer produces this diagnostic when a class from a library that is imported using a deferred import is used to create a const
object. Constants are evaluated at compile time, and classes from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#The following code produces this diagnostic because it attempts to create a const
instance of a class from a deferred library:
import 'dart:convert' deferred as convert;
const json2 = convert.JsonCodec();
Common fixes
#If the object isn't required to be a constant, then change the code so that a non-constant instance is created:
import 'dart:convert' deferred as convert;
final json2 = convert.JsonCodec();
If the object must be a constant, then remove deferred
from the import directive:
import 'dart:convert' as convert;
const json2 = convert.JsonCodec();
const_initialized_with_non_constant_value
#Const variables must be initialized with a constant value.
Description
#The analyzer produces this diagnostic when a value that isn't statically known to be a constant is assigned to a variable that's declared to be a const
variable.
Example
#The following code produces this diagnostic because x
isn't declared to be const
:
var x = 0;
const y = x;
Common fixes
#If the value being assigned can be declared to be const
, then change the declaration:
const x = 0;
const y = x;
If the value can't be declared to be const
, then remove the const
modifier from the variable, possibly using final
in its place:
var x = 0;
final y = x;
const_initialized_with_non_constant_value_from_deferred_library
#Constant values from a deferred library can't be used to initialize a 'const' variable.
Description
#The analyzer produces this diagnostic when a const
variable is initialized using a const
variable from a library that is imported using a deferred import. Constants are evaluated at compile time, and values from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#The following code produces this diagnostic because the variable pi
is being initialized using the constant math.pi
from the library dart:math
, and dart:math
is imported as a deferred library:
import 'dart:math' deferred as math;
const pi = math.pi;
Common fixes
#If you need to reference the value of the constant from the imported library, then remove the keyword deferred
:
import 'dart:math' as math;
const pi = math.pi;
If you don't need to reference the imported constant, then remove the reference:
const pi = 3.14;
const_instance_field
#Only static fields can be declared as const.
Description
#The analyzer produces this diagnostic when an instance field is marked as being const.
Example
#The following code produces this diagnostic because f
is an instance field:
class C {
const int f = 3;
}
Common fixes
#If the field needs to be an instance field, then remove the keyword const
, or replace it with final
:
class C {
final int f = 3;
}
If the field really should be a const field, then make it a static field:
class C {
static const int f = 3;
}
const_map_key_not_primitive_equality
#The type of a key in a constant map can't override the '==' operator, or 'hashCode', but the class '{0}' does.
Description
#The analyzer produces this diagnostic when the class of object used as a key in a constant map literal implements either the ==
operator, the getter hashCode
, or both. The implementation of constant maps uses both the ==
operator and the hashCode
getter, so any implementation other than the ones inherited from Object
requires executing arbitrary code at compile time, which isn't supported.
Examples
#The following code produces this diagnostic because the constant map contains a key whose type is C
, and the class C
overrides the implementation of ==
:
class C {
const C();
bool operator ==(Object other) => true;
}
const map = {C() : 0};
The following code produces this diagnostic because the constant map contains a key whose type is C
, and the class C
overrides the implementation of hashCode
:
class C {
const C();
int get hashCode => 3;
}
const map = {C() : 0};
Common fixes
#If you can remove the implementation of ==
and hashCode
from the class, then do so:
class C {
const C();
}
const map = {C() : 0};
If you can't remove the implementation of ==
and hashCode
from the class, then make the map non-constant:
class C {
const C();
bool operator ==(Object other) => true;
}
final map = {C() : 0};
const_not_initialized
#The constant '{0}' must be initialized.
Description
#The analyzer produces this diagnostic when a variable that is declared to be a constant doesn't have an initializer.
Example
#The following code produces this diagnostic because c
isn't initialized:
const c;
Common fixes
#Add an initializer:
const c = 'c';
const_set_element_not_primitive_equality
#const_set_element_type_implements_equals
)
An element in a constant set can't override the '==' operator, or 'hashCode', but the type '{0}' does.
Description
#The analyzer produces this diagnostic when the class of object used as an element in a constant set literal implements either the ==
operator, the getter hashCode
, or both. The implementation of constant sets uses both the ==
operator and the hashCode
getter, so any implementation other than the ones inherited from Object
requires executing arbitrary code at compile time, which isn't supported.
Example
#The following code produces this diagnostic because the constant set contains an element whose type is C
, and the class C
overrides the implementation of ==
:
class C {
const C();
bool operator ==(Object other) => true;
}
const set = {C()};
The following code produces this diagnostic because the constant set contains an element whose type is C
, and the class C
overrides the implementation of hashCode
:
class C {
const C();
int get hashCode => 3;
}
const map = {C()};
Common fixes
#If you can remove the implementation of ==
and hashCode
from the class, then do so:
class C {
const C();
}
const set = {C()};
If you can't remove the implementation of ==
and hashCode
from the class, then make the set non-constant:
class C {
const C();
bool operator ==(Object other) => true;
}
final set = {C()};
const_spread_expected_list_or_set
#A list or a set is expected in this spread.
Description
#The analyzer produces this diagnostic when the expression of a spread operator in a constant list or set evaluates to something other than a list or a set.
Example
#The following code produces this diagnostic because the value of list1
is null
, which is neither a list nor a set:
const dynamic list1 = 42;
const List<int> list2 = [...list1];
Common fixes
#Change the expression to something that evaluates to either a constant list or a constant set:
const dynamic list1 = [42];
const List<int> list2 = [...list1];
const_spread_expected_map
#A map is expected in this spread.
Description
#The analyzer produces this diagnostic when the expression of a spread operator in a constant map evaluates to something other than a map.
Example
#The following code produces this diagnostic because the value of map1
is null
, which isn't a map:
const dynamic map1 = 42;
const Map<String, int> map2 = {...map1};
Common fixes
#Change the expression to something that evaluates to a constant map:
const dynamic map1 = {'answer': 42};
const Map<String, int> map2 = {...map1};
const_with_non_const
#The constructor being called isn't a const constructor.
Description
#The analyzer produces this diagnostic when the keyword const
is used to invoke a constructor that isn't marked with const
.
Example
#The following code produces this diagnostic because the constructor in A
isn't a const constructor:
class A {
A();
}
A f() => const A();
Common fixes
#If it's desirable and possible to make the class a constant class (by making all of the fields of the class, including inherited fields, final), then add the keyword const
to the constructor:
class A {
const A();
}
A f() => const A();
Otherwise, remove the keyword const
:
class A {
A();
}
A f() => A();
const_with_non_constant_argument
#Arguments of a constant creation must be constant expressions.
Description
#The analyzer produces this diagnostic when a const constructor is invoked with an argument that isn't a constant expression.
Example
#The following code produces this diagnostic because i
isn't a constant:
class C {
final int i;
const C(this.i);
}
C f(int i) => const C(i);
Common fixes
#Either make all of the arguments constant expressions, or remove the const
keyword to use the non-constant form of the constructor:
class C {
final int i;
const C(this.i);
}
C f(int i) => C(i);
const_with_type_parameters
#A constant constructor tearoff can't use a type parameter as a type argument.
A constant creation can't use a type parameter as a type argument.
A constant function tearoff can't use a type parameter as a type argument.
Description
#The analyzer produces this diagnostic when a type parameter is used as a type argument in a const
invocation of a constructor. This isn't allowed because the value of the type parameter (the actual type that will be used at runtime) can't be known at compile time.
Example
#The following code produces this diagnostic because the type parameter T
is being used as a type argument when creating a constant:
class C<T> {
const C();
}
C<T> newC<T>() => const C<T>();
Common fixes
#If the type that will be used for the type parameter can be known at compile time, then remove the use of the type parameter:
class C<T> {
const C();
}
C<int> newC() => const C<int>();
If the type that will be used for the type parameter can't be known until runtime, then remove the keyword const
:
class C<T> {
const C();
}
C<T> newC<T>() => C<T>();
continue_label_invalid
#continue_label_on_switch
)
The label used in a 'continue' statement must be defined on either a loop or a switch member.
Description
#The analyzer produces this diagnostic when the label in a continue
statement resolves to a label on a switch
statement.
Example
#The following code produces this diagnostic because the label l
, used to label a switch
statement, is used in the continue
statement:
void f(int i) {
l: switch (i) {
case 0:
continue l;
}
}
Common fixes
#Find a different way to achieve the control flow you need; for example, by introducing a loop that re-executes the switch
statement.
creation_of_struct_or_union
#Subclasses of 'Struct' and 'Union' are backed by native memory, and can't be instantiated by a generative constructor.
Description
#The analyzer produces this diagnostic when a subclass of either Struct
or Union
is instantiated using a generative constructor.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the class C
is being instantiated using a generative constructor:
import 'dart:ffi';
final class C extends Struct {
@Int32()
external int a;
}
void f() {
C();
}
Common fixes
#If you need to allocate the structure described by the class, then use the ffi
package to do so:
import 'dart:ffi';
import 'package:ffi/ffi.dart';
final class C extends Struct {
@Int32()
external int a;
}
void f() {
final pointer = calloc.allocate<C>(4);
final c = pointer.ref;
print(c);
calloc.free(pointer);
}
creation_with_non_type
#The name '{0}' isn't a class.
Description
#The analyzer produces this diagnostic when an instance creation using either new
or const
specifies a name that isn't defined as a class.
Example
#The following code produces this diagnostic because f
is a function rather than a class:
int f() => 0;
void g() {
new f();
}
Common fixes
#If a class should be created, then replace the invalid name with the name of a valid class:
int f() => 0;
void g() {
new Object();
}
If the name is the name of a function and you want that function to be invoked, then remove the new
or const
keyword:
int f() => 0;
void g() {
f();
}
dead_code
#Dead code.
Dead code: The assigned-to wildcard variable is marked late and can never be referenced so this initializer will never be evaluated.
Description
#The analyzer produces this diagnostic when code is found that won't be executed because execution will never reach the code.
Example
#The following code produces this diagnostic because the invocation of print
occurs after the function has returned:
void f() {
return;
print('here');
}
Common fixes
#If the code isn't needed, then remove it:
void f() {
return;
}
If the code needs to be executed, then either move the code to a place where it will be executed:
void f() {
print('here');
return;
}
Or, rewrite the code before it, so that it can be reached:
void f({bool skipPrinting = true}) {
if (skipPrinting) {
return;
}
print('here');
}
dead_code_catch_following_catch
#Dead code: Catch clauses after a 'catch (e)' or an 'on Object catch (e)' are never reached.
Description
#The analyzer produces this diagnostic when a catch
clause is found that can't be executed because it's after a catch
clause of the form catch (e)
or on Object catch (e)
. The first catch
clause that matches the thrown object is selected, and both of those forms will match any object, so no catch
clauses that follow them will be selected.
Example
#The following code produces this diagnostic:
void f() {
try {
} catch (e) {
} on String {
}
}
Common fixes
#If the clause should be selectable, then move the clause before the general clause:
void f() {
try {
} on String {
} catch (e) {
}
}
If the clause doesn't need to be selectable, then remove it:
void f() {
try {
} catch (e) {
}
}
dead_code_on_catch_subtype
#Dead code: This on-catch block won't be executed because '{0}' is a subtype of '{1}' and hence will have been caught already.
Description
#The analyzer produces this diagnostic when a catch
clause is found that can't be executed because it is after a catch
clause that catches either the same type or a supertype of the clause's type. The first catch
clause that matches the thrown object is selected, and the earlier clause always matches anything matchable by the highlighted clause, so the highlighted clause will never be selected.
Example
#The following code produces this diagnostic:
void f() {
try {
} on num {
} on int {
}
}
Common fixes
#If the clause should be selectable, then move the clause before the general clause:
void f() {
try {
} on int {
} on num {
}
}
If the clause doesn't need to be selectable, then remove it:
void f() {
try {
} on num {
}
}
dead_null_aware_expression
#The left operand can't be null, so the right operand is never executed.
Description
#The analyzer produces this diagnostic in two cases.
The first is when the left operand of an ??
operator can't be null
. The right operand is only evaluated if the left operand has the value null
, and because the left operand can't be null
, the right operand is never evaluated.
The second is when the left-hand side of an assignment using the ??=
operator can't be null
. The right-hand side is only evaluated if the left-hand side has the value null
, and because the left-hand side can't be null
, the right-hand side is never evaluated.
Examples
#The following code produces this diagnostic because x
can't be null
:
int f(int x) {
return x ?? 0;
}
The following code produces this diagnostic because f
can't be null
:
class C {
int f = -1;
void m(int x) {
f ??= x;
}
}
Common fixes
#If the diagnostic is reported for an ??
operator, then remove the ??
operator and the right operand:
int f(int x) {
return x;
}
If the diagnostic is reported for an assignment, and the assignment isn't needed, then remove the assignment:
class C {
int f = -1;
void m(int x) {
}
}
If the assignment is needed, but should be based on a different condition, then rewrite the code to use =
and the different condition:
class C {
int f = -1;
void m(int x) {
if (f < 0) {
f = x;
}
}
}
default_list_constructor
#The default 'List' constructor isn't available when null safety is enabled.
Description
#The analyzer produces this diagnostic when it finds a use of the default constructor for the class List
in code that has opted in to null safety.
Example
#Assuming the following code is opted in to null safety, it produces this diagnostic because it uses the default List
constructor:
var l = List<int>();
Common fixes
#If no initial size is provided, then convert the code to use a list literal:
var l = <int>[];
If an initial size needs to be provided and there is a single reasonable initial value for the elements, then use List.filled
:
var l = List.filled(3, 0);
If an initial size needs to be provided but each element needs to be computed, then use List.generate
:
var l = List.generate(3, (i) => i);
default_value_in_function_type
#Parameters in a function type can't have default values.
Description
#The analyzer produces this diagnostic when a function type associated with a parameter includes optional parameters that have a default value. This isn't allowed because the default values of parameters aren't part of the function's type, and therefore including them doesn't provide any value.
Example
#The following code produces this diagnostic because the parameter p
has a default value even though it's part of the type of the parameter g
:
void f(void Function([int p = 0]) g) {
}
Common fixes
#Remove the default value from the function-type's parameter:
void f(void Function([int p]) g) {
}
default_value_in_redirecting_factory_constructor
#Default values aren't allowed in factory constructors that redirect to another constructor.
Description
#The analyzer produces this diagnostic when a factory constructor that redirects to another constructor specifies a default value for an optional parameter.
Example
#The following code produces this diagnostic because the factory constructor in A
has a default value for the optional parameter x
:
class A {
factory A([int x = 0]) = B;
}
class B implements A {
B([int x = 1]) {}
}
Common fixes
#Remove the default value from the factory constructor:
class A {
factory A([int x]) = B;
}
class B implements A {
B([int x = 1]) {}
}
Note that this fix might change the value used when the optional parameter is omitted. If that happens, and if that change is a problem, then consider making the optional parameter a required parameter in the factory method:
class A {
factory A(int x) = B;
}
class B implements A {
B([int x = 1]) {}
}
default_value_on_required_parameter
#Required named parameters can't have a default value.
Description
#The analyzer produces this diagnostic when a named parameter has both the required
modifier and a default value. If the parameter is required, then a value for the parameter is always provided at the call sites, so the default value can never be used.
Example
#The following code generates this diagnostic:
void log({required String message = 'no message'}) {}
Common fixes
#If the parameter is really required, then remove the default value:
void log({required String message}) {}
If the parameter isn't always required, then remove the required
modifier:
void log({String message = 'no message'}) {}
deferred_import_of_extension
#Imports of deferred libraries must hide all extensions.
Description
#The analyzer produces this diagnostic when a library that is imported using a deferred import declares an extension that is visible in the importing library. Extension methods are resolved at compile time, and extensions from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#Given a file a.dart
that defines a named extension:
class C {}
extension E on String {
int get size => length;
}
The following code produces this diagnostic because the named extension is visible to the library:
import 'a.dart' deferred as a;
void f() {
a.C();
}
Common fixes
#If the library must be imported as deferred
, then either add a show
clause listing the names being referenced or add a hide
clause listing all of the named extensions. Adding a show
clause would look like this:
import 'a.dart' deferred as a show C;
void f() {
a.C();
}
Adding a hide
clause would look like this:
import 'a.dart' deferred as a hide E;
void f() {
a.C();
}
With the first fix, the benefit is that if new extensions are added to the imported library, then the extensions won't cause a diagnostic to be generated.
If the library doesn't need to be imported as deferred
, or if you need to make use of the extension method declared in it, then remove the keyword deferred
:
import 'a.dart' as a;
void f() {
a.C();
}
definitely_unassigned_late_local_variable
#The late local variable '{0}' is definitely unassigned at this point.
Description
#The analyzer produces this diagnostic when definite assignment analysis shows that a local variable that's marked as late
is read before being assigned.
Example
#The following code produces this diagnostic because x
wasn't assigned a value before being read:
void f(bool b) {
late int x;
print(x);
}
Common fixes
#Assign a value to the variable before reading from it:
void f(bool b) {
late int x;
x = b ? 1 : 0;
print(x);
}
dependencies_field_not_map
#The value of the '{0}' field is expected to be a map.
Description
#The analyzer produces this diagnostic when the value of either the dependencies
or dev_dependencies
key isn't a map.
Example
#The following code produces this diagnostic because the value of the top-level dependencies
key is a list:
name: example
dependencies:
- meta
Common fixes
#Use a map as the value of the dependencies
key:
name: example
dependencies:
meta: ^1.0.2
deprecated_colon_for_default_value
#Using a colon as the separator before a default value is deprecated and will not be supported in language version 3.0 and later.
Description
#The analyzer produces this diagnostic when a colon (:
) is used as the separator before the default value of an optional named parameter. While this syntax is allowed, it is deprecated in favor of using an equal sign (=
).
Example
#The following code produces this diagnostic because a colon is being used before the default value of the optional parameter i
:
void f({int i : 0}) {}
Common fixes
#Replace the colon with an equal sign.
void f({int i = 0}) {}
deprecated_export_use
#The ability to import '{0}' indirectly is deprecated.
Description
#The analyzer produces this diagnostic when one library imports a name from a second library, and the second library exports the name from a third library but has indicated that it won't export the third library in the future.
Example
#Given a library a.dart
defining the class A
:
class A {}
And a second library b.dart
that exports a.dart
but has marked the export as being deprecated:
import 'a.dart';
@deprecated
export 'a.dart';
The following code produces this diagnostic because the class A
won't be exported from b.dart
in some future version:
import 'b.dart';
A? a;
Common fixes
#If the name is available from a different library that you can import, then replace the existing import with an import for that library (or add an import for the defining library if you still need the old import):
import 'a.dart';
A? a;
If the name isn't available, then look for instructions from the library author or contact them directly to find out how to update your code.
deprecated_field
#The '{0}' field is no longer used and can be removed.
Description
#The analyzer produces this diagnostic when a key is used in a pubspec.yaml
file that was deprecated. Unused keys take up space and might imply semantics that are no longer valid.
Example
#The following code produces this diagnostic because the author
key is no longer being used:
name: example
author: 'Dash'
Common fixes
#Remove the deprecated key:
name: example
deprecated_member_use
#'{0}' is deprecated and shouldn't be used.
'{0}' is deprecated and shouldn't be used. {1}
Description
#The analyzer produces this diagnostic when a deprecated library or class member is used in a different package.
Example
#If the method m
in the class C
is annotated with @deprecated
, then the following code produces this diagnostic:
void f(C c) {
c.m();
}
Common fixes
#The documentation for declarations that are annotated with @deprecated
should indicate what code to use in place of the deprecated code.
deprecated_member_use_from_same_package
#'{0}' is deprecated and shouldn't be used.
'{0}' is deprecated and shouldn't be used. {1}
Description
#The analyzer produces this diagnostic when a deprecated library member or class member is used in the same package in which it's declared.
Example
#The following code produces this diagnostic because x
is deprecated:
@deprecated
var x = 0;
var y = x;
Common fixes
#The fix depends on what's been deprecated and what the replacement is. The documentation for deprecated declarations should indicate what code to use in place of the deprecated code.
deprecated_new_in_comment_reference
#Using the 'new' keyword in a comment reference is deprecated.
Description
#The analyzer produces this diagnostic when a comment reference (the name of a declaration enclosed in square brackets in a documentation comment) uses the keyword new
to refer to a constructor. This form is deprecated.
Examples
#The following code produces this diagnostic because the unnamed constructor is being referenced using new C
:
/// See [new C].
class C {
C();
}
The following code produces this diagnostic because the constructor named c
is being referenced using new C.c
:
/// See [new C.c].
class C {
C.c();
}
Common fixes
#If you're referencing a named constructor, then remove the keyword new
:
/// See [C.c].
class C {
C.c();
}
If you're referencing the unnamed constructor, then remove the keyword new
and append .new
after the class name:
/// See [C.new].
class C {
C.c();
}
deprecated_subtype_of_function
#Extending 'Function' is deprecated.
Implementing 'Function' has no effect.
Mixing in 'Function' is deprecated.
Description
#The analyzer produces this diagnostic when the class Function
is used in either the extends
, implements
, or with
clause of a class or mixin. Using the class Function
in this way has no semantic value, so it's effectively dead code.
Example
#The following code produces this diagnostic because Function
is used as the superclass of F
:
class F extends Function {}
Common fixes
#Remove the class Function
from whichever clause it's in, and remove the whole clause if Function
is the only type in the clause:
class F {}
disallowed_type_instantiation_expression
#Only a generic type, generic function, generic instance method, or generic constructor can have type arguments.
Description
#The analyzer produces this diagnostic when an expression with a value that is anything other than one of the allowed kinds of values is followed by type arguments. The allowed kinds of values are:
- generic types,
- generic constructors, and
- generic functions, including top-level functions, static and instance members, and local functions.
Example
#The following code produces this diagnostic because i
is a top-level variable, which isn't one of the allowed cases:
int i = 1;
void f() {
print(i<int>);
}
Common fixes
#If the referenced value is correct, then remove the type arguments:
int i = 1;
void f() {
print(i);
}
division_optimization
#The operator x ~/ y is more efficient than (x / y).toInt().
Description
#The analyzer produces this diagnostic when the result of dividing two numbers is converted to an integer using toInt
. Dart has a built-in integer division operator that is both more efficient and more concise.
Example
#The following code produces this diagnostic because the result of dividing x
and y
is converted to an integer using toInt
:
int divide(int x, int y) => (x / y).toInt();
Common fixes
#Use the integer division operator (~/
):
int divide(int x, int y) => x ~/ y;
duplicate_constructor
#The constructor with name '{0}' is already defined.
The unnamed constructor is already defined.
Description
#The analyzer produces this diagnostic when a class declares more than one unnamed constructor or when it declares more than one constructor with the same name.
Examples
#The following code produces this diagnostic because there are two declarations for the unnamed constructor:
class C {
C();
C();
}
The following code produces this diagnostic because there are two declarations for the constructor named m
:
class C {
C.m();
C.m();
}
Common fixes
#If there are multiple unnamed constructors and all of the constructors are needed, then give all of them, or all except one of them, a name:
class C {
C();
C.n();
}
If there are multiple unnamed constructors and all except one of them are unneeded, then remove the constructors that aren't needed:
class C {
C();
}
If there are multiple named constructors and all of the constructors are needed, then rename all except one of them:
class C {
C.m();
C.n();
}
If there are multiple named constructors and all except one of them are unneeded, then remove the constructors that aren't needed:
class C {
C.m();
}
duplicate_definition
#The name '{0}' is already defined.
Description
#The analyzer produces this diagnostic when a name is declared, and there is a previous declaration with the same name in the same scope.
Example
#The following code produces this diagnostic because the name x
is declared twice:
int x = 0;
int x = 1;
Common fixes
#Choose a different name for one of the declarations.
int x = 0;
int y = 1;
duplicate_export
#Duplicate export.
Description
#The analyzer produces this diagnostic when an export directive is found that is the same as an export before it in the file. The second export doesn't add value and should be removed.
Example
#The following code produces this diagnostic because the same library is being exported twice:
export 'package:meta/meta.dart';
export 'package:meta/meta.dart';
Common fixes
#Remove the unnecessary export:
export 'package:meta/meta.dart';
duplicate_field_formal_parameter
#The field '{0}' can't be initialized by multiple parameters in the same constructor.
Description
#The analyzer produces this diagnostic when there's more than one initializing formal parameter for the same field in a constructor's parameter list. It isn't useful to assign a value that will immediately be overwritten.
Example
#The following code produces this diagnostic because this.f
appears twice in the parameter list:
class C {
int f;
C(this.f, this.f) {}
}
Common fixes
#Remove one of the initializing formal parameters:
class C {
int f;
C(this.f) {}
}
duplicate_field_name
#The field name '{0}' is already used in this record.
Description
#The analyzer produces this diagnostic when either a record literal or a record type annotation contains a field whose name is the same as a previously declared field in the same literal or type.
Examples
#The following code produces this diagnostic because the record literal has two fields named a
:
var r = (a: 1, a: 2);
The following code produces this diagnostic because the record type annotation has two fields named a
, one a positional field and the other a named field:
void f((int a, {int a}) r) {}
Common fixes
#Rename one or both of the fields:
var r = (a: 1, b: 2);
duplicate_hidden_name
#Duplicate hidden name.
Description
#The analyzer produces this diagnostic when a name occurs multiple times in a hide
clause. Repeating the name is unnecessary.
Example
#The following code produces this diagnostic because the name min
is hidden more than once:
import 'dart:math' hide min, min;
var x = pi;
Common fixes
#If the name was mistyped in one or more places, then correct the mistyped names:
import 'dart:math' hide max, min;
var x = pi;
If the name wasn't mistyped, then remove the unnecessary name from the list:
import 'dart:math' hide min;
var x = pi;
duplicate_ignore
#The diagnostic '{0}' doesn't need to be ignored here because it's already being ignored.
Description
#The analyzer produces this diagnostic when a diagnostic name appears in an ignore
comment, but the diagnostic is already being ignored, either because it's already included in the same ignore
comment or because it appears in an ignore-in-file
comment.
Examples
#The following code produces this diagnostic because the diagnostic named unused_local_variable
is already being ignored for the whole file so it doesn't need to be ignored on a specific line:
// ignore_for_file: unused_local_variable
void f() {
// ignore: unused_local_variable
var x = 0;
}
The following code produces this diagnostic because the diagnostic named unused_local_variable
is being ignored twice on the same line:
void f() {
// ignore: unused_local_variable, unused_local_variable
var x = 0;
}
Common fixes
#Remove the ignore comment, or remove the unnecessary diagnostic name if the ignore comment is ignoring more than one diagnostic:
// ignore_for_file: unused_local_variable
void f() {
var x = 0;
}
duplicate_import
#Duplicate import.
Description
#The analyzer produces this diagnostic when an import directive is found that is the same as an import before it in the file. The second import doesn't add value and should be removed.
Example
#The following code produces this diagnostic:
import 'package:meta/meta.dart';
import 'package:meta/meta.dart';
@sealed class C {}
Common fixes
#Remove the unnecessary import:
import 'package:meta/meta.dart';
@sealed class C {}
duplicate_named_argument
#The argument for the named parameter '{0}' was already specified.
Description
#The analyzer produces this diagnostic when an invocation has two or more named arguments that have the same name.
Example
#The following code produces this diagnostic because there are two arguments with the name a
:
void f(C c) {
c.m(a: 0, a: 1);
}
class C {
void m({int? a, int? b}) {}
}
Common fixes
#If one of the arguments should have a different name, then change the name:
void f(C c) {
c.m(a: 0, b: 1);
}
class C {
void m({int? a, int? b}) {}
}
If one of the arguments is wrong, then remove it:
void f(C c) {
c.m(a: 1);
}
class C {
void m({int? a, int? b}) {}
}
duplicate_part
#The library already contains a part with the URI '{0}'.
Description
#The analyzer produces this diagnostic when a single file is referenced in multiple part directives.
Example
#Given a file part.dart
containing
part of 'test.dart';
The following code produces this diagnostic because the file part.dart
is included multiple times:
part 'part.dart';
part 'part.dart';
Common fixes
#Remove all except the first of the duplicated part directives:
part 'part.dart';
duplicate_pattern_assignment_variable
#The variable '{0}' is already assigned in this pattern.
Description
#The analyzer produces this diagnostic when a single pattern variable is assigned a value more than once in the same pattern assignment.
Example
#The following code produces this diagnostic because the variable a
is assigned twice in the pattern (a, a)
:
int f((int, int) r) {
int a;
(a, a) = r;
return a;
}
Common fixes
#If you need to capture all of the values, then use a unique variable for each of the subpatterns being matched:
int f((int, int) r) {
int a, b;
(a, b) = r;
return a + b;
}
If some of the values don't need to be captured, then use a wildcard pattern _
to avoid having to bind the value to a variable:
int f((int, int) r) {
int a;
(_, a) = r;
return a;
}
duplicate_pattern_field
#The field '{0}' is already matched in this pattern.
Description
#The analyzer produces this diagnostic when a record pattern matches the same field more than once, or when an object pattern matches the same getter more than once.
Examples
#The following code produces this diagnostic because the record field a
is matched twice in the same record pattern:
void f(({int a, int b}) r) {
switch (r) {
case (a: 1, a: 2):
return;
}
}
The following code produces this diagnostic because the getter f
is matched twice in the same object pattern:
void f(Object o) {
switch (o) {
case C(f: 1, f: 2):
return;
}
}
class C {
int? f;
}
Common fixes
#If the pattern should match for more than one value of the duplicated field, then use a logical-or pattern:
void f(({int a, int b}) r) {
switch (r) {
case (a: 1, b: _) || (a: 2, b: _):
break;
}
}
If the pattern should match against multiple fields, then change the name of one of the fields:
void f(({int a, int b}) r) {
switch (r) {
case (a: 1, b: 2):
return;
}
}
duplicate_rest_element_in_pattern
#At most one rest element is allowed in a list or map pattern.
Description
#The analyzer produces this diagnostic when there's more than one rest pattern in either a list or map pattern. A rest pattern will capture any values unmatched by other subpatterns, making subsequent rest patterns unnecessary because there's nothing left to capture.
Example
#The following code produces this diagnostic because there are two rest patterns in the list pattern:
void f(List<int> x) {
if (x case [0, ..., ...]) {}
}
Common fixes
#Remove all but one of the rest patterns:
void f(List<int> x) {
if (x case [0, ...]) {}
}
duplicate_shown_name
#Duplicate shown name.
Description
#The analyzer produces this diagnostic when a name occurs multiple times in a show
clause. Repeating the name is unnecessary.
Example
#The following code produces this diagnostic because the name min
is shown more than once:
import 'dart:math' show min, min;
var x = min(2, min(0, 1));
Common fixes
#If the name was mistyped in one or more places, then correct the mistyped names:
import 'dart:math' show max, min;
var x = max(2, min(0, 1));
If the name wasn't mistyped, then remove the unnecessary name from the list:
import 'dart:math' show min;
var x = min(2, min(0, 1));
duplicate_variable_pattern
#The variable '{0}' is already defined in this pattern.
Description
#The analyzer produces this diagnostic when a branch of a logical-and pattern declares a variable that is already declared in an earlier branch of the same pattern.
Example
#The following code produces this diagnostic because the variable a
is declared in both branches of the logical-and pattern:
void f((int, int) r) {
if (r case (var a, 0) && (0, var a)) {
print(a);
}
}
Common fixes
#If you need to capture the matched value in multiple branches, then change the names of the variables so that they are unique:
void f((int, int) r) {
if (r case (var a, 0) && (0, var b)) {
print(a + b);
}
}
If you only need to capture the matched value on one branch, then remove the variable pattern from all but one branch:
void f((int, int) r) {
if (r case (var a, 0) && (0, _)) {
print(a);
}
}
empty_map_pattern
#A map pattern must have at least one entry.
Description
#The analyzer produces this diagnostic when a map pattern is empty.
Example
#The following code produces this diagnostic because the map pattern is empty:
void f(Map<int, String> x) {
if (x case {}) {}
}
Common fixes
#If the pattern should match any map, then replace it with an object pattern:
void f(Map<int, String> x) {
if (x case Map()) {}
}
If the pattern should only match an empty map, then check the length in the pattern:
void f(Map<int, String> x) {
if (x case Map(isEmpty: true)) {}
}
empty_record_literal_with_comma
#A record literal without fields can't have a trailing comma.
Description
#The analyzer produces this diagnostic when a record literal that has no fields has a trailing comma. Empty record literals can't contain a comma.
Example
#The following code produces this diagnostic because the empty record literal has a trailing comma:
var r = (,);
Common fixes
#If the record is intended to be empty, then remove the comma:
var r = ();
If the record is intended to have one or more fields, then add the expressions used to compute the values of those fields:
var r = (3, 4);
empty_record_type_named_fields_list
#The list of named fields in a record type can't be empty.
Description
#The analyzer produces this diagnostic when a record type has an empty list of named fields.
Example
#The following code produces this diagnostic because the record type has an empty list of named fields:
void f((int, int, {}) r) {}
Common fixes
#If the record is intended to have named fields, then add the types and names of the fields:
void f((int, int, {int z}) r) {}
If the record isn't intended to have named fields, then remove the curly braces:
void f((int, int) r) {}
empty_record_type_with_comma
#A record type without fields can't have a trailing comma.
Description
#The analyzer produces this diagnostic when a record type that has no fields has a trailing comma. Empty record types can't contain a comma.
Example
#The following code produces this diagnostic because the empty record type has a trailing comma:
void f((,) r) {}
Common fixes
#If the record type is intended to be empty, then remove the comma:
void f(() r) {}
If the record type is intended to have one or more fields, then add the types of those fields:
void f((int, int) r) {}
empty_struct
#The class '{0}' can't be empty because it's a subclass of '{1}'.
Description
#The analyzer produces this diagnostic when a subclass of Struct
or Union
doesn't have any fields. Having an empty Struct
or Union
isn't supported.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the class C
, which extends Struct
, doesn't declare any fields:
import 'dart:ffi';
final class C extends Struct {}
Common fixes
#If the class is intended to be a struct, then declare one or more fields:
import 'dart:ffi';
final class C extends Struct {
@Int32()
external int x;
}
If the class is intended to be used as a type argument to Pointer
, then make it a subclass of Opaque
:
import 'dart:ffi';
final class C extends Opaque {}
If the class isn't intended to be a struct, then remove or change the extends clause:
class C {}
enum_constant_same_name_as_enclosing
#The name of the enum value can't be the same as the enum's name.
Description
#The analyzer produces this diagnostic when an enum value has the same name as the enum in which it's declared.
Example
#The following code produces this diagnostic because the enum value E
has the same name as the enclosing enum E
:
enum E {
E
}
Common fixes
#If the name of the enum is correct, then rename the constant:
enum E {
e
}
If the name of the constant is correct, then rename the enum:
enum F {
E
}
enum_constant_with_non_const_constructor
#The invoked constructor isn't a 'const' constructor.
Description
#The analyzer produces this diagnostic when an enum value is being created using either a factory constructor or a generative constructor that isn't marked as being const
.
Example
#The following code produces this diagnostic because the enum value e
is being initialized by a factory constructor:
enum E {
e();
factory E() => e;
}
Common fixes
#Use a generative constructor marked as const
:
enum E {
e._();
factory E() => e;
const E._();
}
enum_mixin_with_instance_variable
#Mixins applied to enums can't have instance variables.
Description
#The analyzer produces this diagnostic when a mixin that's applied to an enum declares one or more instance variables. This isn't allowed because the enum values are constant, and there isn't any way for the constructor in the enum to initialize any of the mixin's fields.
Example
#The following code produces this diagnostic because the mixin M
defines the instance field x
:
mixin M {
int x = 0;
}
enum E with M {
a
}
Common fixes
#If you need to apply the mixin, then change all instance fields into getter and setter pairs and implement them in the enum if necessary:
mixin M {
int get x => 0;
}
enum E with M {
a
}
If you don't need to apply the mixin, then remove it:
enum E {
a
}
enum_with_abstract_member
#'{0}' must have a method body because '{1}' is an enum.
Description
#The analyzer produces this diagnostic when a member of an enum is found that doesn't have a concrete implementation. Enums aren't allowed to contain abstract members.
Example
#The following code produces this diagnostic because m
is an abstract method and E
is an enum:
enum E {
e;
void m();
}
Common fixes
#Provide an implementation for the member:
enum E {
e;
void m() {}
}
enum_with_name_values
#The name 'values' is not a valid name for an enum.
Description
#The analyzer produces this diagnostic when an enum is declared to have the name values
. This isn't allowed because the enum has an implicit static field named values
, and the two would collide.
Example
#The following code produces this diagnostic because there's an enum declaration that has the name values
:
enum values {
c
}
Common fixes
#Rename the enum to something other than values
.
equal_elements_in_const_set
#Two elements in a constant set literal can't be equal.
Description
#The analyzer produces this diagnostic when two elements in a constant set literal have the same value. The set can only contain each value once, which means that one of the values is unnecessary.
Example
#The following code produces this diagnostic because the string 'a'
is specified twice:
const Set<String> set = {'a', 'a'};
Common fixes
#Remove one of the duplicate values:
const Set<String> set = {'a'};
Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.
equal_elements_in_set
#Two elements in a set literal shouldn't be equal.
Description
#The analyzer produces this diagnostic when an element in a non-constant set is the same as a previous element in the same set. If two elements are the same, then the second value is ignored, which makes having both elements pointless and likely signals a bug.
Example
#The following code produces this diagnostic because the element 1
appears twice:
const a = 1;
const b = 1;
var s = <int>{a, b};
Common fixes
#If both elements should be included in the set, then change one of the elements:
const a = 1;
const b = 2;
var s = <int>{a, b};
If only one of the elements is needed, then remove the one that isn't needed:
const a = 1;
var s = <int>{a};
Note that literal sets preserve the order of their elements, so the choice of which element to remove might affect the order in which elements are returned by an iterator.
equal_keys_in_const_map
#Two keys in a constant map literal can't be equal.
Description
#The analyzer produces this diagnostic when a key in a constant map is the same as a previous key in the same map. If two keys are the same, then the second value would overwrite the first value, which makes having both pairs pointless.
Example
#The following code produces this diagnostic because the key 1
is used twice:
const map = <int, String>{1: 'a', 2: 'b', 1: 'c', 4: 'd'};
Common fixes
#If both entries should be included in the map, then change one of the keys to be different:
const map = <int, String>{1: 'a', 2: 'b', 3: 'c', 4: 'd'};
If only one of the entries is needed, then remove the one that isn't needed:
const map = <int, String>{1: 'a', 2: 'b', 4: 'd'};
Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which keys and values are returned by an iterator.
equal_keys_in_map
#Two keys in a map literal shouldn't be equal.
Description
#The analyzer produces this diagnostic when a key in a non-constant map is the same as a previous key in the same map. If two keys are the same, then the second value overwrites the first value, which makes having both pairs pointless and likely signals a bug.
Example
#The following code produces this diagnostic because the keys a
and b
have the same value:
const a = 1;
const b = 1;
var m = <int, String>{a: 'a', b: 'b'};
Common fixes
#If both entries should be included in the map, then change one of the keys:
const a = 1;
const b = 2;
var m = <int, String>{a: 'a', b: 'b'};
If only one of the entries is needed, then remove the one that isn't needed:
const a = 1;
var m = <int, String>{a: 'a'};
Note that literal maps preserve the order of their entries, so the choice of which entry to remove might affect the order in which the keys and values are returned by an iterator.
equal_keys_in_map_pattern
#Two keys in a map pattern can't be equal.
Description
#The analyzer produces this diagnostic when a map pattern contains more than one key with the same name. The same key can't be matched twice.
Example
#The following code produces this diagnostic because the key 'a'
appears twice:
void f(Map<String, int> x) {
if (x case {'a': 1, 'a': 2}) {}
}
Common fixes
#If you are trying to match two different keys, then change one of the keys in the pattern:
void f(Map<String, int> x) {
if (x case {'a': 1, 'b': 2}) {}
}
If you are trying to match the same key, but allow any one of multiple patterns to match, the use a logical-or pattern:
void f(Map<String, int> x) {
if (x case {'a': 1 || 2}) {}
}
expected_one_list_pattern_type_arguments
#List patterns require one type argument or none, but {0} found.
Description
#The analyzer produces this diagnostic when a list pattern has more than one type argument. List patterns can have either zero type arguments or one type argument, but can't have more than one.
Example
#The following code produces this diagnostic because the list pattern ([0]
) has two type arguments:
void f(Object x) {
if (x case <int, int>[0]) {}
}
Common fixes
#Remove all but one of the type arguments:
void f(Object x) {
if (x case <int>[0]) {}
}
expected_one_list_type_arguments
#List literals require one type argument or none, but {0} found.
Description
#The analyzer produces this diagnostic when a list literal has more than one type argument.
Example
#The following code produces this diagnostic because the list literal has two type arguments when it can have at most one:
var l = <int, int>[];
Common fixes
#Remove all except one of the type arguments:
var l = <int>[];
expected_one_set_type_arguments
#Set literals require one type argument or none, but {0} were found.
Description
#The analyzer produces this diagnostic when a set literal has more than one type argument.
Example
#The following code produces this diagnostic because the set literal has three type arguments when it can have at most one:
var s = <int, String, int>{0, 'a', 1};
Common fixes
#Remove all except one of the type arguments:
var s = <int>{0, 1};
expected_two_map_pattern_type_arguments
#Map patterns require two type arguments or none, but {0} found.
Description
#The analyzer produces this diagnostic when a map pattern has either one type argument or more than two type arguments. Map patterns can have either two type arguments or zero type arguments, but can't have any other number.
Example
#The following code produces this diagnostic because the map pattern (<int>{}
) has one type argument:
void f(Object x) {
if (x case <int>{0: _}) {}
}
Common fixes
#Add or remove type arguments until there are two, or none:
void f(Object x) {
if (x case <int, int>{0: _}) {}
}
expected_two_map_type_arguments
#Map literals require two type arguments or none, but {0} found.
Description
#The analyzer produces this diagnostic when a map literal has either one or more than two type arguments.
Example
#The following code produces this diagnostic because the map literal has three type arguments when it can have either two or zero:
var m = <int, String, int>{};
Common fixes
#Remove all except two of the type arguments:
var m = <int, String>{};
export_internal_library
#The library '{0}' is internal and can't be exported.
Description
#The analyzer produces this diagnostic when it finds an export whose dart:
URI references an internal library.
Example
#The following code produces this diagnostic because _interceptors
is an internal library:
export 'dart:_interceptors';
Common fixes
#Remove the export directive.
export_legacy_symbol
#The symbol '{0}' is defined in a legacy library, and can't be re-exported from a library with null safety enabled.
Description
#The analyzer produces this diagnostic when a library that was opted in to null safety exports another library, and the exported library is opted out of null safety.
Example
#Given a library that is opted out of null safety:
// @dart = 2.8
String s;
The following code produces this diagnostic because it's exporting symbols from an opted-out library:
export 'optedOut.dart';
class C {}
Common fixes
#If you're able to do so, migrate the exported library so that it doesn't need to opt out:
String? s;
If you can't migrate the library, then remove the export:
class C {}
If the exported library (the one that is opted out) itself exports an opted-in library, then it's valid for your library to indirectly export the symbols from the opted-in library. You can do so by adding a hide combinator to the export directive in your library that hides all of the names declared in the opted-out library.
export_of_non_library
#The exported library '{0}' can't have a part-of directive.
Description
#The analyzer produces this diagnostic when an export directive references a part rather than a library.
Example
#Given a file part.dart
containing
part of lib;
The following code produces this diagnostic because the file part.dart
is a part, and only libraries can be exported:
library lib;
export 'part.dart';
Common fixes
#Either remove the export directive, or change the URI to be the URI of the library containing the part.
expression_in_map
#Expressions can't be used in a map literal.
Description
#The analyzer produces this diagnostic when the analyzer finds an expression, rather than a map entry, in what appears to be a map literal.
Example
#The following code produces this diagnostic:
var map = <String, int>{'a': 0, 'b': 1, 'c'};
Common fixes
#If the expression is intended to compute either a key or a value in an entry, fix the issue by replacing the expression with the key or the value. For example:
var map = <String, int>{'a': 0, 'b': 1, 'c': 2};
extends_non_class
#Classes can only extend other classes.
Description
#The analyzer produces this diagnostic when an extends
clause contains a name that is declared to be something other than a class.
Example
#The following code produces this diagnostic because f
is declared to be a function:
void f() {}
class C extends f {}
Common fixes
#If you want the class to extend a class other than Object
, then replace the name in the extends
clause with the name of that class:
void f() {}
class C extends B {}
class B {}
If you want the class to extend Object
, then remove the extends
clause:
void f() {}
class C {}
extension_as_expression
#Extension '{0}' can't be used as an expression.
Description
#The analyzer produces this diagnostic when the name of an extension is used in an expression other than in an extension override or to qualify an access to a static member of the extension. Because classes define a type, the name of a class can be used to refer to the instance of Type
representing the type of the class. Extensions, on the other hand, don't define a type and can't be used as a type literal.
Example
#The following code produces this diagnostic because E
is an extension:
extension E on int {
static String m() => '';
}
var x = E;
Common fixes
#Replace the name of the extension with a name that can be referenced, such as a static member defined on the extension:
extension E on int {
static String m() => '';
}
var x = E.m();
extension_conflicting_static_and_instance
#An extension can't define static member '{0}' and an instance member with the same name.
Description
#The analyzer produces this diagnostic when an extension declaration contains both an instance member and a static member that have the same name. The instance member and the static member can't have the same name because it's unclear which member is being referenced by an unqualified use of the name within the body of the extension.
Example
#The following code produces this diagnostic because the name a
is being used for two different members:
extension E on Object {
int get a => 0;
static int a() => 0;
}
Common fixes
#Rename or remove one of the members:
extension E on Object {
int get a => 0;
static int b() => 0;
}
extension_declares_abstract_member
#Extensions can't declare abstract members.
Description
#The analyzer produces this diagnostic when an abstract declaration is declared in an extension. Extensions can declare only concrete members.
Example
#The following code produces this diagnostic because the method a
doesn't have a body:
extension E on String {
int a();
}
Common fixes
#Either provide an implementation for the member or remove it.
extension_declares_constructor
#Extensions can't declare constructors.
Description
#The analyzer produces this diagnostic when a constructor declaration is found in an extension. It isn't valid to define a constructor because extensions aren't classes, and it isn't possible to create an instance of an extension.
Example
#The following code produces this diagnostic because there is a constructor declaration in E
:
extension E on String {
E() : super();
}
Common fixes
#Remove the constructor or replace it with a static method.
extension_declares_instance_field
#Extensions can't declare instance fields
Description
#The analyzer produces this diagnostic when an instance field declaration is found in an extension. It isn't valid to define an instance field because extensions can only add behavior, not state.
Example
#The following code produces this diagnostic because s
is an instance field:
extension E on String {
String s;
}
Common fixes
#Remove the field, make it a static field, or convert it to be a getter, setter, or method.
extension_declares_member_of_object
#Extensions can't declare members with the same name as a member declared by 'Object'.
Description
#The analyzer produces this diagnostic when an extension declaration declares a member with the same name as a member declared in the class Object
. Such a member can never be used because the member in Object
is always found first.
Example
#The following code produces this diagnostic because toString
is defined by Object
:
extension E on String {
String toString() => this;
}
Common fixes
#Remove the member or rename it so that the name doesn't conflict with the member in Object
:
extension E on String {
String displayString() => this;
}
extension_override_access_to_static_member
#An extension override can't be used to access a static member from an extension.
Description
#The analyzer produces this diagnostic when an extension override is the receiver of the invocation of a static member. Similar to static members in classes, the static members of an extension should be accessed using the name of the extension, not an extension override.
Example
#The following code produces this diagnostic because m
is static:
extension E on String {
static void m() {}
}
void f() {
E('').m();
}
Common fixes
#Replace the extension override with the name of the extension:
extension E on String {
static void m() {}
}
void f() {
E.m();
}
extension_override_argument_not_assignable
#The type of the argument to the extension override '{0}' isn't assignable to the extended type '{1}'.
Description
#The analyzer produces this diagnostic when the argument to an extension override isn't assignable to the type being extended by the extension.
Example
#The following code produces this diagnostic because 3
isn't a String
:
extension E on String {
void method() {}
}
void f() {
E(3).method();
}
Common fixes
#If you're using the correct extension, then update the argument to have the correct type:
extension E on String {
void method() {}
}
void f() {
E(3.toString()).method();
}
If there's a different extension that's valid for the type of the argument, then either replace the name of the extension or unwrap the argument so that the correct extension is found.
extension_override_without_access
#An extension override can only be used to access instance members.
Description
#The analyzer produces this diagnostic when an extension override is found that isn't being used to access one of the members of the extension. The extension override syntax doesn't have any runtime semantics; it only controls which member is selected at compile time.
Example
#The following code produces this diagnostic because E(i)
isn't an expression:
extension E on int {
int get a => 0;
}
void f(int i) {
print(E(i));
}
Common fixes
#If you want to invoke one of the members of the extension, then add the invocation:
extension E on int {
int get a => 0;
}
void f(int i) {
print(E(i).a);
}
If you don't want to invoke a member, then unwrap the argument:
extension E on int {
int get a => 0;
}
void f(int i) {
print(i);
}
extension_override_with_cascade
#Extension overrides have no value so they can't be used as the receiver of a cascade expression.
Description
#The analyzer produces this diagnostic when an extension override is used as the receiver of a cascade expression. The value of a cascade expression e..m
is the value of the receiver e
, but extension overrides aren't expressions and don't have a value.
Example
#The following code produces this diagnostic because E(3)
isn't an expression:
extension E on int {
void m() {}
}
f() {
E(3)..m();
}
Common fixes
#Use .
rather than ..
:
extension E on int {
void m() {}
}
f() {
E(3).m();
}
If there are multiple cascaded accesses, you'll need to duplicate the extension override for each one.
extension_type_constructor_with_super_formal_parameter
#Extension type constructors can't declare super formal parameters.
Description
#The analyzer produces this diagnostic when a constructor in an extension type has a super parameter. Super parameters aren't valid because extension types don't have a superclass.
Example
#The following code produces this diagnostic because the named constructor n
contains a super parameter:
extension type E(int i) {
E.n(this.i, super.foo);
}
Common fixes
#If you need the parameter, replace the super parameter with a normal parameter:
extension type E(int i) {
E.n(this.i, String foo);
}
If you don't need the parameter, remove the super parameter:
extension type E(int i) {
E.n(this.i);
}
extension_type_constructor_with_super_invocation
#Extension type constructors can't include super initializers.
Description
#The analyzer produces this diagnostic when a constructor in an extension type includes an invocation of a super constructor in the initializer list. Because extension types don't have a superclass, there's no constructor to invoke.
Example
#The following code produces this diagnostic because the constructor E.n
invokes a super constructor in its initializer list:
extension type E(int i) {
E.n() : i = 0, super.n();
}
Common fixes
#Remove the invocation of the super constructor:
extension type E(int i) {
E.n() : i = 0;
}
extension_type_declares_instance_field
#Extension types can't declare instance fields.
Description
#The analyzer produces this diagnostic when there's a field declaration in the body of an extension type declaration.
Example
#The following code produces this diagnostic because the extension type E
declares a field named f
:
extension type E(int i) {
final int f = 0;
}
Common fixes
#If you don't need the field, then remove it or replace it with a getter and/or setter:
extension type E(int i) {
int get f => 0;
}
If you need the field, then convert the extension type into a class:
class E {
final int i;
final int f = 0;
E(this.i);
}
extension_type_declares_member_of_object
#Extension types can't declare members with the same name as a member declared by 'Object'.
Description
#The analyzer produces this diagnostic when the body of an extension type declaration contains a member with the same name as one of the members declared by Object
.
Example
#The following code produces this diagnostic because the class Object
already defines a member named hashCode
:
extension type E(int i) {
int get hashCode => 0;
}
Common fixes
#If you need a member with the implemented semantics, then rename the member:
extension type E(int i) {
int get myHashCode => 0;
}
If you don't need a member with the implemented semantics, then remove the member:
extension type E(int i) {}
extension_type_implements_disallowed_type
#Extension types can't implement '{0}'.
Description
#The analyzer produces this diagnostic when an extension type implements a type that it isn't allowed to implement.
Example
#The following code produces this diagnostic because extension types can't implement the type dynamic
:
extension type A(int i) implements dynamic {}
Common fixes
#Remove the disallowed type from the implements clause:
extension type A(int i) {}
extension_type_implements_itself
#The extension type can't implement itself.
Description
#The analyzer produces this diagnostic when an extension type implements itself, either directly or indirectly.
Example
#The following code produces this diagnostic because the extension type A
directly implements itself:
extension type A(int i) implements A {}
The following code produces this diagnostic because the extension type A
indirectly implements itself (through B
):
extension type A(int i) implements B {}
extension type B(int i) implements A {}
Common fixes
#Break the cycle by removing a type from the implements clause of at least one of the types involved in the cycle:
extension type A(int i) implements B {}
extension type B(int i) {}
extension_type_implements_not_supertype
#'{0}' is not a supertype of '{1}', the representation type.
Description
#The analyzer produces this diagnostic when an extension type implements a type that isn't a supertype of the representation type.
Example
#The following code produces this diagnostic because the extension type A
implements String
, but String
isn't a supertype of the representation type int
:
extension type A(int i) implements String {}
Common fixes
#If the representation type is correct, then remove or replace the type in the implements clause:
extension type A(int i) {}
If the representation type isn't correct, then replace it with the correct type:
extension type A(String s) implements String {}
extension_type_implements_representation_not_supertype
#'{0}', the representation type of '{1}', is not a supertype of '{2}', the representation type of '{3}'.
Description
#The analyzer produces this diagnostic when an extension type implements another extension type, and the representation type of the implemented extension type isn't a subtype of the representation type of the implementing extension type.
Example
#The following code produces this diagnostic because the extension type B
implements A
, but the representation type of A
(num
) isn't a subtype of the representation type of B
(String
):
extension type A(num i) {}
extension type B(String s) implements A {}
Common fixes
#Either change the representation types of the two extension types so that the representation type of the implemented type is a supertype of the representation type of the implementing type:
extension type A(num i) {}
extension type B(int n) implements A {}
Or remove the implemented type from the implements clause:
extension type A(num i) {}
extension type B(String s) {}
extension_type_inherited_member_conflict
#The extension type '{0}' has more than one distinct member named '{1}' from implemented types.
Description
#The analyzer produces this diagnostic when an extension type implements two or more other types, and at least two of those types declare a member with the same name.
Example
#The following code produces this diagnostic because the extension type C
implements both A
and B
, and both declare a member named m
:
class A {
void m() {}
}
extension type B(A a) {
void m() {}
}
extension type C(A a) implements A, B {}
Common fixes
#If the extension type doesn't need to implement all of the listed types, then remove all but one of the types introducing the conflicting members:
class A {
void m() {}
}
extension type B(A a) {
void m() {}
}
extension type C(A a) implements A {}
If the extension type needs to implement all of the listed types but you can rename the members in those types, then give the conflicting members unique names:
class A {
void m() {}
}
extension type B(A a) {
void n() {}
}
extension type C(A a) implements A, B {}
extension_type_representation_depends_on_itself
#The extension type representation can't depend on itself.
Description
#The analyzer produces this diagnostic when an extension type has a representation type that depends on the extension type itself, either directly or indirectly.
Example
#The following code produces this diagnostic because the representation type of the extension type A
depends on A
directly:
extension type A(A a) {}
The following two code examples produce this diagnostic because the representation type of the extension type A
depends on A
indirectly through the extension type B
:
extension type A(B b) {}
extension type B(A a) {}
extension type A(List<B> b) {}
extension type B(List<A> a) {}
Common fixes
#Remove the dependency by choosing a different representation type for at least one of the types in the cycle:
extension type A(String s) {}
extension_type_representation_type_bottom
#The representation type can't be a bottom type.
Description
#The analyzer produces this diagnostic when the representation type of an extension type is the bottom type Never
. The type Never
can't be the representation type of an extension type because there are no values that can be extended.
Example
#The following code produces this diagnostic because the representation type of the extension type E
is Never
:
extension type E(Never n) {}
Common fixes
#Replace the extension type with a different type:
extension type E(String s) {}
extension_type_with_abstract_member
#'{0}' must have a method body because '{1}' is an extension type.
Description
#The analyzer produces this diagnostic when an extension type declares an abstract member. Because extension type member references are resolved statically, an abstract member in an extension type could never be executed.
Example
#The following code produces this diagnostic because the method m
in the extension type E
is abstract:
extension type E(String s) {
void m();
}
Common fixes
#If the member is intended to be executable, then provide an implementation of the member:
extension type E(String s) {
void m() {}
}
If the member isn't intended to be executable, then remove it:
extension type E(String s) {}
external_with_initializer
#External fields can't have initializers.
External variables can't have initializers.
Description
#The analyzer produces this diagnostic when a field or variable marked with the keyword external
has an initializer, or when an external field is initialized in a constructor.
Examples
#The following code produces this diagnostic because the external field x
is assigned a value in an initializer:
class C {
external int x;
C() : x = 0;
}
The following code produces this diagnostic because the external field x
has an initializer:
class C {
external final int x = 0;
}
The following code produces this diagnostic because the external top level variable x
has an initializer:
external final int x = 0;
Common fixes
#Remove the initializer:
class C {
external final int x;
}
extra_annotation_on_struct_field
#Fields in a struct class must have exactly one annotation indicating the native type.
Description
#The analyzer produces this diagnostic when a field in a subclass of Struct
has more than one annotation describing the native type of the field.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the field x
has two annotations describing the native type of the field:
import 'dart:ffi';
final class C extends Struct {
@Int32()
@Int16()
external int x;
}
Common fixes
#Remove all but one of the annotations:
import 'dart:ffi';
final class C extends Struct {
@Int32()
external int x;
}
extra_positional_arguments
#Too many positional arguments: {0} expected, but {1} found.
Description
#The analyzer produces this diagnostic when a method or function invocation has more positional arguments than the method or function allows.
Example
#The following code produces this diagnostic because f
defines 2 parameters but is invoked with 3 arguments:
void f(int a, int b) {}
void g() {
f(1, 2, 3);
}
Common fixes
#Remove the arguments that don't correspond to parameters:
void f(int a, int b) {}
void g() {
f(1, 2);
}
extra_positional_arguments_could_be_named
#Too many positional arguments: {0} expected, but {1} found.
Description
#The analyzer produces this diagnostic when a method or function invocation has more positional arguments than the method or function allows, but the method or function defines named parameters.
Example
#The following code produces this diagnostic because f
defines 2 positional parameters but has a named parameter that could be used for the third argument:
void f(int a, int b, {int? c}) {}
void g() {
f(1, 2, 3);
}
Common fixes
#If some of the arguments should be values for named parameters, then add the names before the arguments:
void f(int a, int b, {int? c}) {}
void g() {
f(1, 2, c: 3);
}
Otherwise, remove the arguments that don't correspond to positional parameters:
void f(int a, int b, {int? c}) {}
void g() {
f(1, 2);
}
extra_size_annotation_carray
#'Array's must have exactly one 'Array' annotation.
Description
#The analyzer produces this diagnostic when a field in a subclass of Struct
has more than one annotation describing the size of the native array.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the field a0
has two annotations that specify the size of the native array:
import 'dart:ffi';
final class C extends Struct {
@Array(4)
@Array(8)
external Array<Uint8> a0;
}
Common fixes
#Remove all but one of the annotations:
import 'dart:ffi';
final class C extends Struct {
@Array(8)
external Array<Uint8> a0;
}
ffi_native_invalid_duplicate_default_asset
#There may be at most one @DefaultAsset annotation on a library.
Description
#The analyzer produces this diagnostic when a library directive has more than one DefaultAsset
annotation associated with it.
Example
#The following code produces this diagnostic because the library directive has two DefaultAsset
annotations associated with it:
@DefaultAsset('a')
@DefaultAsset('b')
library;
import 'dart:ffi';
Common fixes
#Remove all but one of the DefaultAsset
annotations:
@DefaultAsset('a')
library;
import 'dart:ffi';
ffi_native_invalid_multiple_annotations
#Native functions and fields must have exactly one @Native
annotation.
Description
#The analyzer produces this diagnostic when there is more than one Native
annotation on a single declaration.
Example
#The following code produces this diagnostic because the function f
has two Native
annotations associated with it:
import 'dart:ffi';
@Native<Int32 Function(Int32)>()
@Native<Int32 Function(Int32)>(isLeaf: true)
external int f(int v);
Common fixes
#Remove all but one of the annotations:
import 'dart:ffi';
@Native<Int32 Function(Int32)>(isLeaf: true)
external int f(int v);
ffi_native_must_be_external
#Native functions must be declared external.
Description
#The analyzer produces this diagnostic when a function annotated as being @Native
isn't marked as external
.
Example
#The following code produces this diagnostic because the function free
is annotated as being @Native
, but the function isn't marked as external
:
import 'dart:ffi';
@Native<Void Function(Pointer<Void>)>()
void free(Pointer<Void> ptr) {}
Common fixes
#If the function is a native function, then add the modifier external
before the return type:
import 'dart:ffi';
@Native<Void Function(Pointer<Void>)>()
external void free(Pointer<Void> ptr);
ffi_native_unexpected_number_of_parameters
#Unexpected number of Native annotation parameters. Expected {0} but has {1}.
Description
#The analyzer produces this diagnostic when the number of parameters in the function type used as a type argument for the @Native
annotation doesn't match the number of parameters in the function being annotated.
Example
#The following code produces this diagnostic because the function type used as a type argument for the @Native
annotation (Void Function(Double)
) has one argument and the type of the annotated function (void f(double, double)
) has two arguments:
import 'dart:ffi';
@Native<Void Function(Double)>(symbol: 'f')
external void f(double x, double y);
Common fixes
#If the annotated function is correct, then update the function type in the @Native
annotation to match:
import 'dart:ffi';
@Native<Void Function(Double, Double)>(symbol: 'f')
external void f(double x, double y);
If the function type in the @Native
annotation is correct, then update the annotated function to match:
import 'dart:ffi';
@Native<Void Function(Double)>(symbol: 'f')
external void f(double x);
ffi_native_unexpected_number_of_parameters_with_receiver
#Unexpected number of Native annotation parameters. Expected {0} but has {1}. Native instance method annotation must have receiver as first argument.
Description
#The analyzer produces this diagnostic when the type argument used on the @Native
annotation of a native method doesn't include a type for the receiver of the method.
Example
#The following code produces this diagnostic because the type argument on the @Native
annotation (Void Function(Double)
) doesn't include a type for the receiver of the method:
import 'dart:ffi';
class C {
@Native<Void Function(Double)>()
external void f(double x);
}
Common fixes
#Add an initial parameter whose type is the same as the class in which the native method is being declared:
import 'dart:ffi';
class C {
@Native<Void Function(C, Double)>()
external void f(double x);
}
field_initialized_by_multiple_initializers
#The field '{0}' can't be initialized twice in the same constructor.
Description
#The analyzer produces this diagnostic when the initializer list of a constructor initializes a field more than once. There is no value to allow both initializers because only the last value is preserved.
Example
#The following code produces this diagnostic because the field f
is being initialized twice:
class C {
int f;
C() : f = 0, f = 1;
}
Common fixes
#Remove one of the initializers:
class C {
int f;
C() : f = 0;
}
field_initialized_in_initializer_and_declaration
#Fields can't be initialized in the constructor if they are final and were already initialized at their declaration.
Description
#The analyzer produces this diagnostic when a final field is initialized in both the declaration of the field and in an initializer in a constructor. Final fields can only be assigned once, so it can't be initialized in both places.
Example
#The following code produces this diagnostic because f
is :
class C {
final int f = 0;
C() : f = 1;
}
Common fixes
#If the initialization doesn't depend on any values passed to the constructor, and if all of the constructors need to initialize the field to the same value, then remove the initializer from the constructor:
class C {
final int f = 0;
C();
}
If the initialization depends on a value passed to the constructor, or if different constructors need to initialize the field differently, then remove the initializer in the field's declaration:
class C {
final int f;
C() : f = 1;
}
field_initialized_in_parameter_and_initializer
#Fields can't be initialized in both the parameter list and the initializers.
Description
#The analyzer produces this diagnostic when a field is initialized in both the parameter list and in the initializer list of a constructor.
Example
#The following code produces this diagnostic because the field f
is initialized both by an initializing formal parameter and in the initializer list:
class C {
int f;
C(this.f) : f = 0;
}
Common fixes
#If the field should be initialized by the parameter, then remove the initialization in the initializer list:
class C {
int f;
C(this.f);
}
If the field should be initialized in the initializer list and the parameter isn't needed, then remove the parameter:
class C {
int f;
C() : f = 0;
}
If the field should be initialized in the initializer list and the parameter is needed, then make it a normal parameter:
class C {
int f;
C(int g) : f = g * 2;
}
field_initializer_factory_constructor
#Initializing formal parameters can't be used in factory constructors.
Description
#The analyzer produces this diagnostic when a factory constructor has an initializing formal parameter. Factory constructors can't assign values to fields because no instance is created; hence, there is no field to assign.
Example
#The following code produces this diagnostic because the factory constructor uses an initializing formal parameter:
class C {
int? f;
factory C(this.f) => throw 0;
}
Common fixes
#Replace the initializing formal parameter with a normal parameter:
class C {
int? f;
factory C(int f) => throw 0;
}
field_initializer_in_struct
#Constructors in subclasses of 'Struct' and 'Union' can't have field initializers.
Description
#The analyzer produces this diagnostic when a constructor in a subclass of either Struct
or Union
has one or more field initializers.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the class C
has a constructor with an initializer for the field f
:
// @dart = 2.9
import 'dart:ffi';
final class C extends Struct {
@Int32()
int f;
C() : f = 0;
}
Common fixes
#Remove the field initializer:
// @dart = 2.9
import 'dart:ffi';
final class C extends Struct {
@Int32()
int f;
C();
}
field_initializer_not_assignable
#The initializer type '{0}' can't be assigned to the field type '{1}' in a const constructor.
The initializer type '{0}' can't be assigned to the field type '{1}'.
Description
#The analyzer produces this diagnostic when the initializer list of a constructor initializes a field to a value that isn't assignable to the field.
Example
#The following code produces this diagnostic because 0
has the type int
, and an int
can't be assigned to a field of type String
:
class C {
String s;
C() : s = 0;
}
Common fixes
#If the type of the field is correct, then change the value assigned to it so that the value has a valid type:
class C {
String s;
C() : s = '0';
}
If the type of the value is correct, then change the type of the field to allow the assignment:
class C {
int s;
C() : s = 0;
}
field_initializer_outside_constructor
#Field formal parameters can only be used in a constructor.
Initializing formal parameters can only be used in constructors.
Description
#The analyzer produces this diagnostic when an initializing formal parameter is used in the parameter list for anything other than a constructor.
Example
#The following code produces this diagnostic because the initializing formal parameter this.x
is being used in the method m
:
class A {
int x = 0;
m([this.x = 0]) {}
}
Common fixes
#Replace the initializing formal parameter with a normal parameter and assign the field within the body of the method:
class A {
int x = 0;
m([int x = 0]) {
this.x = x;
}
}
field_initializer_redirecting_constructor
#The redirecting constructor can't have a field initializer.
Description
#The analyzer produces this diagnostic when a redirecting constructor initializes a field in the object. This isn't allowed because the instance that has the field hasn't been created at the point at which it should be initialized.
Examples
#The following code produces this diagnostic because the constructor C.zero
, which redirects to the constructor C
, has an initializing formal parameter that initializes the field f
:
class C {
int f;
C(this.f);
C.zero(this.f) : this(f);
}
The following code produces this diagnostic because the constructor C.zero
, which redirects to the constructor C
, has an initializer that initializes the field f
:
class C {
int f;
C(this.f);
C.zero() : f = 0, this(1);
}
Common fixes
#If the initialization is done by an initializing formal parameter, then use a normal parameter:
class C {
int f;
C(this.f);
C.zero(int f) : this(f);
}
If the initialization is done in an initializer, then remove the initializer:
class C {
int f;
C(this.f);
C.zero() : this(0);
}
field_initializing_formal_not_assignable
#The parameter type '{0}' is incompatible with the field type '{1}'.
Description
#The analyzer produces this diagnostic when the type of an initializing formal parameter isn't assignable to the type of the field being initialized.
Example
#The following code produces this diagnostic because the initializing formal parameter has the type String
, but the type of the field is int
. The parameter must have a type that is a subtype of the field's type.
class C {
int f;
C(String this.f);
}
Common fixes
#If the type of the field is incorrect, then change the type of the field to match the type of the parameter, and consider removing the type from the parameter:
class C {
String f;
C(this.f);
}
If the type of the parameter is incorrect, then remove the type of the parameter:
class C {
int f;
C(this.f);
}
If the types of both the field and the parameter are correct, then use an initializer rather than an initializing formal parameter to convert the parameter value into a value of the correct type:
class C {
int f;
C(String s) : f = int.parse(s);
}
field_in_struct_with_initializer
#Fields in subclasses of 'Struct' and 'Union' can't have initializers.
Description
#The analyzer produces this diagnostic when a field in a subclass of Struct
has an initializer.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the field p
has an initializer:
// @dart = 2.9
import 'dart:ffi';
final class C extends Struct {
Pointer p = nullptr;
}
Common fixes
#Remove the initializer:
// @dart = 2.9
import 'dart:ffi';
final class C extends Struct {
Pointer p;
}
field_must_be_external_in_struct
#Fields of 'Struct' and 'Union' subclasses must be marked external.
Description
#The analyzer produces this diagnostic when a field in a subclass of either Struct
or Union
isn't marked as being external
.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the field a
isn't marked as being external
:
import 'dart:ffi';
final class C extends Struct {
@Int16()
int a;
}
Common fixes
#Add the required external
modifier:
import 'dart:ffi';
final class C extends Struct {
@Int16()
external int a;
}
final_initialized_in_declaration_and_constructor
#'{0}' is final and was given a value when it was declared, so it can't be set to a new value.
Description
#The analyzer produces this diagnostic when a final field is initialized twice: once where it's declared and once by a constructor's parameter.
Example
#The following code produces this diagnostic because the field f
is initialized twice:
class C {
final int f = 0;
C(this.f);
}
Common fixes
#If the field should have the same value for all instances, then remove the initialization in the parameter list:
class C {
final int f = 0;
C();
}
If the field can have different values in different instances, then remove the initialization in the declaration:
class C {
final int f;
C(this.f);
}
final_not_initialized
#The final variable '{0}' must be initialized.
Description
#The analyzer produces this diagnostic when a final field or variable isn't initialized.
Example
#The following code produces this diagnostic because x
doesn't have an initializer:
final x;
Common fixes
#For variables and static fields, you can add an initializer:
final x = 0;
For instance fields, you can add an initializer as shown in the previous example, or you can initialize the field in every constructor. You can initialize the field by using an initializing formal parameter:
class C {
final int x;
C(this.x);
}
You can also initialize the field by using an initializer in the constructor:
class C {
final int x;
C(int y) : x = y * 2;
}
final_not_initialized_constructor
#All final variables must be initialized, but '{0}' and '{1}' aren't.
All final variables must be initialized, but '{0}' isn't.
All final variables must be initialized, but '{0}', '{1}', and {2} others aren't.
Description
#The analyzer produces this diagnostic when a class defines one or more final instance fields without initializers and has at least one constructor that doesn't initialize those fields. All final instance fields must be initialized when the instance is created, either by the field's initializer or by the constructor.
Example
#The following code produces this diagnostic:
class C {
final String value;
C();
}
Common fixes
#If the value should be passed in to the constructor directly, then use an initializing formal parameter to initialize the field value
:
class C {
final String value;
C(this.value);
}
If the value should be computed indirectly from a value provided by the caller, then add a parameter and include an initializer:
class C {
final String value;
C(Object o) : value = o.toString();
}
If the value of the field doesn't depend on values that can be passed to the constructor, then add an initializer for the field as part of the field declaration:
class C {
final String value = '';
C();
}
If the value of the field doesn't depend on values that can be passed to the constructor but different constructors need to initialize it to different values, then add an initializer for the field in the initializer list:
class C {
final String value;
C() : value = '';
C.named() : value = 'c';
}
However, if the value is the same for all instances, then consider using a static field instead of an instance field:
class C {
static const String value = '';
C();
}
flutter_field_not_map
#The value of the 'flutter' field is expected to be a map.
Description
#The analyzer produces this diagnostic when the value of the flutter
key isn't a map.
Example
#The following code produces this diagnostic because the value of the top-level flutter
key is a string:
name: example
flutter: true
Common fixes
#If you need to specify Flutter-specific options, then change the value to be a map:
name: example
flutter:
uses-material-design: true
If you don't need to specify Flutter-specific options, then remove the flutter
key:
name: example
for_in_of_invalid_element_type
#The type '{0}' used in the 'for' loop must implement '{1}' with a type argument that can be assigned to '{2}'.
Description
#The analyzer produces this diagnostic when the Iterable
or Stream
in a for-in loop has an element type that can't be assigned to the loop variable.
Example
#The following code produces this diagnostic because <String>[]
has an element type of String
, and String
can't be assigned to the type of e
(int
):
void f() {
for (int e in <String>[]) {
print(e);
}
}
Common fixes
#If the type of the loop variable is correct, then update the type of the iterable:
void f() {
for (int e in <int>[]) {
print(e);
}
}
If the type of the iterable is correct, then update the type of the loop variable:
void f() {
for (String e in <String>[]) {
print(e);
}
}
for_in_of_invalid_type
#The type '{0}' used in the 'for' loop must implement '{1}'.
Description
#The analyzer produces this diagnostic when the expression following in
in a for-in loop has a type that isn't a subclass of Iterable
.
Example
#The following code produces this diagnostic because m
is a Map
, and Map
isn't a subclass of Iterable
:
void f(Map<String, String> m) {
for (String s in m) {
print(s);
}
}
Common fixes
#Replace the expression with one that produces an iterable value:
void f(Map<String, String> m) {
for (String s in m.values) {
print(s);
}
}
for_in_with_const_variable
#A for-in loop variable can't be a 'const'.
Description
#The analyzer produces this diagnostic when the loop variable declared in a for-in loop is declared to be a const
. The variable can't be a const
because the value can't be computed at compile time.
Example
#The following code produces this diagnostic because the loop variable x
is declared to be a const
:
void f() {
for (const x in [0, 1, 2]) {
print(x);
}
}
Common fixes
#If there's a type annotation, then remove the const
modifier from the declaration.
If there's no type, then replace the const
modifier with final
, var
, or a type annotation:
void f() {
for (final x in [0, 1, 2]) {
print(x);
}
}
generic_method_type_instantiation_on_dynamic
#A method tear-off on a receiver whose type is 'dynamic' can't have type arguments.
Description
#The analyzer produces this diagnostic when an instance method is being torn off from a receiver whose type is dynamic
, and the tear-off includes type arguments. Because the analyzer can't know how many type parameters the method has, or whether it has any type parameters, there's no way it can validate that the type arguments are correct. As a result, the type arguments aren't allowed.
Example
#The following code produces this diagnostic because the type of p
is dynamic
and the tear-off of m
has type arguments:
void f(dynamic list) {
list.fold<int>;
}
Common fixes
#If you can use a more specific type than dynamic
, then change the type of the receiver:
void f(List<Object> list) {
list.fold<int>;
}
If you can't use a more specific type, then remove the type arguments:
void f(dynamic list) {
list.cast;
}
generic_struct_subclass
#The class '{0}' can't extend 'Struct' or 'Union' because '{0}' is generic.
Description
#The analyzer produces this diagnostic when a subclass of either Struct
or Union
has a type parameter.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because the class S
defines the type parameter T
:
import 'dart:ffi';
final class S<T> extends Struct {
external Pointer notEmpty;
}
Common fixes
#Remove the type parameters from the class:
import 'dart:ffi';
final class S extends Struct {
external Pointer notEmpty;
}
getter_not_subtype_setter_types
#The return type of getter '{0}' is '{1}' which isn't a subtype of the type '{2}' of its setter '{3}'.
Description
#The analyzer produces this diagnostic when the return type of a getter isn't a subtype of the type of the parameter of a setter with the same name.
The subtype relationship is a requirement whether the getter and setter are in the same class or whether one of them is in a superclass of the other.
Example
#The following code produces this diagnostic because the return type of the getter x
is num
, the parameter type of the setter x
is int
, and num
isn't a subtype of int
:
class C {
num get x => 0;
set x(int y) {}
}
Common fixes
#If the type of the getter is correct, then change the type of the setter:
class C {
num get x => 0;
set x(num y) {}
}
If the type of the setter is correct, then change the type of the getter:
class C {
int get x => 0;
set x(int y) {}
}
illegal_async_generator_return_type
#Functions marked 'async*' must have a return type that is a supertype of 'Stream
Description
#The analyzer produces this diagnostic when the body of a function has the async*
modifier even though the return type of the function isn't either Stream
or a supertype of Stream
.
Example
#The following code produces this diagnostic because the body of the function f
has the 'async*' modifier even though the return type int
isn't a supertype of Stream
:
int f() async* {}
Common fixes
#If the function should be asynchronous, then change the return type to be either Stream
or a supertype of Stream
:
Stream<int> f() async* {}
If the function should be synchronous, then remove the async*
modifier:
int f() => 0;
illegal_async_return_type
#Functions marked 'async' must have a return type which is a supertype of 'Future'.
Description
#The analyzer produces this diagnostic when the body of a function has the async
modifier even though the return type of the function isn't assignable to Future
.
Example
#The following code produces this diagnostic because the body of the function f
has the async
modifier even though the return type isn't assignable to Future
:
int f() async {
return 0;
}
Common fixes
#If the function should be asynchronous, then change the return type to be assignable to Future
:
Future<int> f() async {
return 0;
}
If the function should be synchronous, then remove the async
modifier:
int f() => 0;
illegal_concrete_enum_member
#A concrete instance member named '{0}' can't be declared in a class that implements 'Enum'.
A concrete instance member named '{0}' can't be inherited from '{1}' in a class that implements 'Enum'.
Description
#The analyzer produces this diagnostic when either an enum declaration, a class that implements Enum
, or a mixin with a superclass constraint of Enum
, declares or inherits a concrete instance member named either index
, hashCode
, or ==
.
Examples
#The following code produces this diagnostic because the enum E
declares an instance getter named index
:
enum E {
v;
int get index => 0;
}
The following code produces this diagnostic because the class C
, which implements Enum
, declares an instance field named hashCode
:
abstract class C implements Enum {
int hashCode = 0;
}
The following code produces this diagnostic because the class C
, which indirectly implements Enum
through the class A
, declares an instance getter named hashCode
:
abstract class A implements Enum {}
abstract class C implements A {
int get hashCode => 0;
}
The following code produces this diagnostic because the mixin M
, which has Enum
in the on
clause, declares an explicit operator named ==
:
mixin M on Enum {
bool operator ==(Object other) => false;
}
Common fixes
#Rename the conflicting member:
enum E {
v;
int get getIndex => 0;
}
illegal_enum_values
#An instance member named 'values' can't be declared in a class that implements 'Enum'.
An instance member named 'values' can't be inherited from '{0}' in a class that implements 'Enum'.
Description
#The analyzer produces this diagnostic when either a class that implements Enum
or a mixin with a superclass constraint of Enum
has an instance member named values
.
Examples
#The following code produces this diagnostic because the class C
, which implements Enum
, declares an instance field named values
:
abstract class C implements Enum {
int get values => 0;
}
The following code produces this diagnostic because the class B
, which implements Enum
, inherits an instance method named values
from A
:
abstract class A {
int values() => 0;
}
abstract class B extends A implements Enum {}
Common fixes
#Change the name of the conflicting member:
abstract class C implements Enum {
int get value => 0;
}
illegal_sync_generator_return_type
#Functions marked 'sync*' must have a return type that is a supertype of 'Iterable
Description
#The analyzer produces this diagnostic when the body of a function has the sync*
modifier even though the return type of the function isn't either Iterable
or a supertype of Iterable
.
Example
#The following code produces this diagnostic because the body of the function f
has the 'sync*' modifier even though the return type int
isn't a supertype of Iterable
:
int f() sync* {}
Common fixes
#If the function should return an iterable, then change the return type to be either Iterable
or a supertype of Iterable
:
Iterable<int> f() sync* {}
If the function should return a single value, then remove the sync*
modifier:
int f() => 0;
implements_non_class
#Classes and mixins can only implement other classes and mixins.
Description
#The analyzer produces this diagnostic when a name used in the implements
clause of a class or mixin declaration is defined to be something other than a class or mixin.
Example
#The following code produces this diagnostic because x
is a variable rather than a class or mixin:
var x;
class C implements x {}
Common fixes
#If the name is the name of an existing class or mixin that's already being imported, then add a prefix to the import so that the local definition of the name doesn't shadow the imported name.
If the name is the name of an existing class or mixin that isn't being imported, then add an import, with a prefix, for the library in which it's declared.
Otherwise, either replace the name in the implements
clause with the name of an existing class or mixin, or remove the name from the implements
clause.
implements_repeated
#'{0}' can only be implemented once.
Description
#The analyzer produces this diagnostic when a single class is specified more than once in an implements
clause.
Example
#The following code produces this diagnostic because A
is in the list twice:
class A {}
class B implements A, A {}
Common fixes
#Remove all except one occurrence of the class name:
class A {}
class B implements A {}
implements_super_class
#'{0}' can't be used in both the 'extends' and 'implements' clauses.
'{0}' can't be used in both the 'extends' and 'with' clauses.
Description
#The analyzer produces this diagnostic when a class is listed in the extends
clause of a class declaration and also in either the implements
or with
clause of the same declaration.
Example
#The following code produces this diagnostic because the class A
is used in both the extends
and implements
clauses for the class B
:
class A {}
class B extends A implements A {}
The following code produces this diagnostic because the class A
is used in both the extends
and with
clauses for the class B
:
mixin class A {}
class B extends A with A {}
Common fixes
#If you want to inherit the implementation from the class, then remove the class from the implements
clause:
class A {}
class B extends A {}
If you don't want to inherit the implementation from the class, then remove the extends
clause:
class A {}
class B implements A {}
implicit_super_initializer_missing_arguments
#The implicitly invoked unnamed constructor from '{0}' has required parameters.
Description
#The analyzer produces this diagnostic when a constructor implicitly invokes the unnamed constructor from the superclass, the unnamed constructor of the superclass has a required parameter, and there's no super parameter corresponding to the required parameter.
Examples
#The following code produces this diagnostic because the unnamed constructor in the class B
implicitly invokes the unnamed constructor in the class A
, but the constructor in A
has a required positional parameter named x
:
class A {
A(int x);
}
class B extends A {
B();
}
The following code produces this diagnostic because the unnamed constructor in the class B
implicitly invokes the unnamed constructor in the class A
, but the constructor in A
has a required named parameter named x
:
class A {
A({required int x});
}
class B extends A {
B();
}
Common fixes
#If you can add a parameter to the constructor in the subclass, then add a super parameter corresponding to the required parameter in the superclass' constructor. The new parameter can either be required:
class A {
A({required int x});
}
class B extends A {
B({required super.x});
}
or it can be optional:
class A {
A({required int x});
}
class B extends A {
B({super.x = 0});
}
If you can't add a parameter to the constructor in the subclass, then add an explicit super constructor invocation with the required argument:
class A {
A(int x);
}
class B extends A {
B() : super(0);
}
implicit_this_reference_in_initializer
#The instance member '{0}' can't be accessed in an initializer.
Description
#The analyzer produces this diagnostic when it finds a reference to an instance member in a constructor's initializer list.
Example
#The following code produces this diagnostic because defaultX
is an instance member:
class C {
int x;
C() : x = defaultX;
int get defaultX => 0;
}
Common fixes
#If the member can be made static, then do so:
class C {
int x;
C() : x = defaultX;
static int get defaultX => 0;
}
If not, then replace the reference in the initializer with a different expression that doesn't use an instance member:
class C {
int x;
C() : x = 0;
int get defaultX => 0;
}
import_deferred_library_with_load_function
#The imported library defines a top-level function named 'loadLibrary' that is hidden by deferring this library.
Description
#The analyzer produces this diagnostic when a library that declares a function named loadLibrary
is imported using a deferred import. A deferred import introduces an implicit function named loadLibrary
. This function is used to load the contents of the deferred library, and the implicit function hides the explicit declaration in the deferred library.
For more information, check out Lazily loading a library.
Example
#Given a file a.dart
that defines a function named loadLibrary
:
void loadLibrary(Library library) {}
class Library {}
The following code produces this diagnostic because the implicit declaration of a.loadLibrary
is hiding the explicit declaration of loadLibrary
in a.dart
:
import 'a.dart' deferred as a;
void f() {
a.Library();
}
Common fixes
#If the imported library isn't required to be deferred, then remove the keyword deferred
:
import 'a.dart' as a;
void f() {
a.Library();
}
If the imported library is required to be deferred and you need to reference the imported function, then rename the function in the imported library:
void populateLibrary(Library library) {}
class Library {}
If the imported library is required to be deferred and you don't need to reference the imported function, then add a hide
clause:
import 'a.dart' deferred as a hide loadLibrary;
void f() {
a.Library();
}
import_internal_library
#The library '{0}' is internal and can't be imported.
Description
#The analyzer produces this diagnostic when it finds an import whose dart:
URI references an internal library.
Example
#The following code produces this diagnostic because _interceptors
is an internal library:
import 'dart:_interceptors';
Common fixes
#Remove the import directive.
import_of_legacy_library_into_null_safe
#The library '{0}' is legacy, and shouldn't be imported into a null safe library.
Description
#The analyzer produces this diagnostic when a library that is null safe imports a library that isn't null safe.
Example
#Given a file a.dart
that contains the following:
// @dart = 2.9
class A {}
The following code produces this diagnostic because a library that null safe is importing a library that isn't null safe:
import 'a.dart';
A? f() => null;
Common fixes
#If you can migrate the imported library to be null safe, then migrate it and update or remove the migrated library's language version.
If you can't migrate the imported library, then the importing library needs to have a language version that is before 2.12, when null safety was enabled by default.
import_of_non_library
#The imported library '{0}' can't have a part-of directive.
Description
#The analyzer produces this diagnostic when a part file is imported into a library.
Example
#Given a part file named part.dart
containing the following:
part of lib;
The following code produces this diagnostic because imported files can't have a part-of directive:
library lib;
import 'part.dart';
Common fixes
#Import the library that contains the part file rather than the part file itself.
inconsistent_inheritance
#Superinterfaces don't have a valid override for '{0}': {1}.
Description
#The analyzer produces this diagnostic when a class inherits two or more conflicting signatures for a member and doesn't provide an implementation that satisfies all the inherited signatures.
Example
#The following code produces this diagnostic because C
is inheriting the declaration of m
from A
, and that implementation isn't consistent with the signature of m
that's inherited from B
:
class A {
void m({int? a}) {}
}
class B {
void m({int? b}) {}
}
class C extends A implements B {
}
Common fixes
#Add an implementation of the method that satisfies all the inherited signatures:
class A {
void m({int? a}) {}
}
class B {
void m({int? b}) {}
}
class C extends A implements B {
void m({int? a, int? b}) {}
}
inconsistent_language_version_override
#Parts must have exactly the same language version override as the library.
Description
#The analyzer produces this diagnostic when a part file has a language version override comment that specifies a different language version than the one being used for the library to which the part belongs.
Example
#Given a part file named part.dart
that contains the following:
// @dart = 2.14
part of 'test.dart';
The following code produces this diagnostic because the parts of a library must have the same language version as the defining compilation unit:
// @dart = 2.15
part 'part.dart';
Common fixes
#Remove the language version override from the part file, so that it implicitly uses the same version as the defining compilation unit:
part of 'test.dart';
If necessary, either adjust the language version override in the defining compilation unit to be appropriate for the code in the part, or migrate the code in the part file to be consistent with the new language version.
inconsistent_pattern_variable_logical_or
#The variable '{0}' has a different type and/or finality in this branch of the logical-or pattern.
Description
#The analyzer produces this diagnostic when a pattern variable that is declared on all branches of a logical-or pattern doesn't have the same type on every branch. It is also produced when the variable has a different finality on different branches. A pattern variable declared on multiple branches of a logical-or pattern is required to have the same type and finality in each branch, so that the type and finality of the variable can be known in code that's guarded by the logical-or pattern.
Examples
#The following code produces this diagnostic because the variable a
is defined to be an int
on one branch and a double
on the other:
void f(Object? x) {
if (x case (int a) || (double a)) {
print(a);
}
}
The following code produces this diagnostic because the variable a
is final
in the first branch and isn't final
in the second branch:
void f(Object? x) {
if (x case (final int a) || (int a)) {
print(a);
}
}
Common fixes
#If the finality of the variable is different, decide whether it should be final
or not final
and make the cases consistent:
void f(Object? x) {
if (x case (int a) || (int a)) {
print(a);
}
}
If the type of the variable is different and the type isn't critical to the condition being matched, then ensure that the variable has the same type on both branches:
void f(Object? x) {
if (x case (num a) || (num a)) {
print(a);
}
}
If the type of the variable is different and the type is critical to the condition being matched, then consider breaking the condition into multiple if
statements or case
clauses:
void f(Object? x) {
if (x case int a) {
print(a);
} else if (x case double a) {
print(a);
}
}
initializer_for_non_existent_field
#'{0}' isn't a field in the enclosing class.
Description
#The analyzer produces this diagnostic when a constructor initializes a field that isn't declared in the class containing the constructor. Constructors can't initialize fields that aren't declared and fields that are inherited from superclasses.
Example
#The following code produces this diagnostic because the initializer is initializing x
, but x
isn't a field in the class:
class C {
int? y;
C() : x = 0;
}
Common fixes
#If a different field should be initialized, then change the name to the name of the field:
class C {
int? y;
C() : y = 0;
}
If the field must be declared, then add a declaration:
class C {
int? x;
int? y;
C() : x = 0;
}
initializer_for_static_field
#'{0}' is a static field in the enclosing class. Fields initialized in a constructor can't be static.
Description
#The analyzer produces this diagnostic when a static field is initialized in a constructor using either an initializing formal parameter or an assignment in the initializer list.
Example
#The following code produces this diagnostic because the static field a
is being initialized by the initializing formal parameter this.a
:
class C {
static int? a;
C(this.a);
}
Common fixes
#If the field should be an instance field, then remove the keyword static
:
class C {
int? a;
C(this.a);
}
If you intended to initialize an instance field and typed the wrong name, then correct the name of the field being initialized:
class C {
static int? a;
int? b;
C(this.b);
}
If you really want to initialize the static field, then move the initialization into the constructor body:
class C {
static int? a;
C(int? c) {
a = c;
}
}
initializing_formal_for_non_existent_field
#'{0}' isn't a field in the enclosing class.
Description
#The analyzer produces this diagnostic when an initializing formal parameter is found in a constructor in a class that doesn't declare the field being initialized. Constructors can't initialize fields that aren't declared and fields that are inherited from superclasses.
Example
#The following code produces this diagnostic because the field x
isn't defined:
class C {
int? y;
C(this.x);
}
Common fixes
#If the field name was wrong, then change it to the name of an existing field:
class C {
int? y;
C(this.y);
}
If the field name is correct but hasn't yet been defined, then declare the field:
class C {
int? x;
int? y;
C(this.x);
}
If the parameter is needed but shouldn't initialize a field, then convert it to a normal parameter and use it:
class C {
int y;
C(int x) : y = x * 2;
}
If the parameter isn't needed, then remove it:
class C {
int? y;
C();
}
instance_access_to_static_member
#The static {1} '{0}' can't be accessed through an instance.
Description
#The analyzer produces this diagnostic when an access operator is used to access a static member through an instance of the class.
Example
#The following code produces this diagnostic because zero
is a static field, but it's being accessed as if it were an instance field:
void f(C c) {
c.zero;
}
class C {
static int zero = 0;
}
Common fixes
#Use the class to access the static member:
void f(C c) {
C.zero;
}
class C {
static int zero = 0;
}
instance_member_access_from_factory
#Instance members can't be accessed from a factory constructor.
Description
#The analyzer produces this diagnostic when a factory constructor contains an unqualified reference to an instance member. In a generative constructor, the instance of the class is created and initialized before the body of the constructor is executed, so the instance can be bound to this
and accessed just like it would be in an instance method. But, in a factory constructor, the instance isn't created before executing the body, so this
can't be used to reference it.
Example
#The following code produces this diagnostic because x
isn't in scope in the factory constructor:
class C {
int x;
factory C() {
return C._(x);
}
C._(this.x);
}
Common fixes
#Rewrite the code so that it doesn't reference the instance member:
class C {
int x;
factory C() {
return C._(0);
}
C._(this.x);
}
instance_member_access_from_static
#Instance members can't be accessed from a static method.
Description
#The analyzer produces this diagnostic when a static method contains an unqualified reference to an instance member.
Example
#The following code produces this diagnostic because the instance field x
is being referenced in a static method:
class C {
int x = 0;
static int m() {
return x;
}
}
Common fixes
#If the method must reference the instance member, then it can't be static, so remove the keyword:
class C {
int x = 0;
int m() {
return x;
}
}
If the method can't be made an instance method, then add a parameter so that an instance of the class can be passed in:
class C {
int x = 0;
static int m(C c) {
return c.x;
}
}
instantiate_abstract_class
#Abstract classes can't be instantiated.
Description
#The analyzer produces this diagnostic when it finds a constructor invocation and the constructor is declared in an abstract class. Even though you can't create an instance of an abstract class, abstract classes can declare constructors that can be invoked by subclasses.
Example
#The following code produces this diagnostic because C
is an abstract class:
abstract class C {}
var c = new C();
Common fixes
#If there's a concrete subclass of the abstract class that can be used, then create an instance of the concrete subclass.
instantiate_enum
#Enums can't be instantiated.
Description
#The analyzer produces this diagnostic when an enum is instantiated. It's invalid to create an instance of an enum by invoking a constructor; only the instances named in the declaration of the enum can exist.
Example
#The following code produces this diagnostic because the enum E
is being instantiated:
// @dart = 2.16
enum E {a}
var e = E();
Common fixes
#If you intend to use an instance of the enum, then reference one of the constants defined in the enum:
// @dart = 2.16
enum E {a}
var e = E.a;
If you intend to use an instance of a class, then use the name of that class in place of the name of the enum.
instantiate_type_alias_expands_to_type_parameter
#Type aliases that expand to a type parameter can't be instantiated.
Description
#The analyzer produces this diagnostic when a constructor invocation is found where the type being instantiated is a type alias for one of the type parameters of the type alias. This isn't allowed because the value of the type parameter is a type rather than a class.
Example
#The following code produces this diagnostic because it creates an instance of A
, even though A
is a type alias that is defined to be equivalent to a type parameter:
typedef A<T> = T;
void f() {
const A<int>();
}
Common fixes
#Use either a class name or a type alias defined to be a class, rather than a type alias defined to be a type parameter:
typedef A<T> = C<T>;
void f() {
const A<int>();
}
class C<T> {
const C();
}
integer_literal_imprecise_as_double
#The integer literal is being used as a double, but can't be represented as a 64-bit double without overflow or loss of precision: '{0}'.
Description
#The analyzer produces this diagnostic when an integer literal is being implicitly converted to a double, but can't be represented as a 64-bit double without overflow or loss of precision. Integer literals are implicitly converted to a double if the context requires the type double
.
Example
#The following code produces this diagnostic because the integer value 9223372036854775807
can't be represented exactly as a double:
double x = 9223372036854775807;
Common fixes
#If you need to use the exact value, then use the class BigInt
to represent the value:
var x = BigInt.parse('9223372036854775807');
If you need to use a double, then change the value to one that can be represented exactly:
double x = 9223372036854775808;
integer_literal_out_of_range
#The integer literal {0} can't be represented in 64 bits.
Description
#The analyzer produces this diagnostic when an integer literal has a value that is too large (positive) or too small (negative) to be represented in a 64-bit word.
Example
#The following code produces this diagnostic because the value can't be represented in 64 bits:
var x = 9223372036854775810;
Common fixes
#If you need to represent the current value, then wrap it in an instance of the class BigInt
:
var x = BigInt.parse('9223372036854775810');
invalid_annotation
#Annotation must be either a const variable reference or const constructor invocation.
Description
#The analyzer produces this diagnostic when an annotation is found that is using something that is neither a variable marked as const
or the invocation of a const
constructor.
Getters can't be used as annotations.
Examples
#The following code produces this diagnostic because the variable v
isn't a const
variable:
var v = 0;
@v
void f() {
}
The following code produces this diagnostic because f
isn't a variable:
@f
void f() {
}
The following code produces this diagnostic because f
isn't a constructor:
@f()
void f() {
}
The following code produces this diagnostic because g
is a getter:
@g
int get g => 0;
Common fixes
#If the annotation is referencing a variable that isn't a const
constructor, add the keyword const
to the variable's declaration:
const v = 0;
@v
void f() {
}
If the annotation isn't referencing a variable, then remove it:
int v = 0;
void f() {
}
invalid_annotation_constant_value_from_deferred_library
#Constant values from a deferred library can't be used in annotations.
Description
#The analyzer produces this diagnostic when a constant defined in a library that is imported as a deferred library is referenced in the argument list of an annotation. Annotations are evaluated at compile time, and values from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#The following code produces this diagnostic because the constant pi
is being referenced in the argument list of an annotation, even though the library that defines it is being imported as a deferred library:
import 'dart:math' deferred as math;
class C {
const C(double d);
}
@C(math.pi)
void f () {}
Common fixes
#If you need to reference the imported constant, then remove the deferred
keyword:
import 'dart:math' as math;
class C {
const C(double d);
}
@C(math.pi)
void f () {}
If the import is required to be deferred and there's another constant that is appropriate, then use that constant in place of the constant from the deferred library.
invalid_annotation_from_deferred_library
#Constant values from a deferred library can't be used as annotations.
Description
#The analyzer produces this diagnostic when a constant from a library that is imported using a deferred import is used as an annotation. Annotations are evaluated at compile time, and constants from deferred libraries aren't available at compile time.
For more information, check out Lazily loading a library.
Example
#The following code produces this diagnostic because the constant pi
is being used as an annotation when the library dart:math
is imported as deferred
:
import 'dart:math' deferred as math;
@math.pi
void f() {}
Common fixes
#If you need to reference the constant as an annotation, then remove the keyword deferred
from the import:
import 'dart:math' as math;
@math.pi
void f() {}
If you can use a different constant as an annotation, then replace the annotation with a different constant:
@deprecated
void f() {}
invalid_annotation_target
#The annotation '{0}' can only be used on {1}.
Description
#The analyzer produces this diagnostic when an annotation is applied to a kind of declaration that it doesn't support.
Example
#The following code produces this diagnostic because the optionalTypeArgs
annotation isn't defined to be valid for top-level variables:
import 'package:meta/meta.dart';
@optionalTypeArgs
int x = 0;
Common fixes
#Remove the annotation from the declaration.
invalid_assignment
#A value of type '{0}' can't be assigned to a variable of type '{1}'.
Description
#The analyzer produces this diagnostic when the static type of an expression that is assigned to a variable isn't assignable to the type of the variable.
Example
#The following code produces this diagnostic because the type of the initializer (int
) isn't assignable to the type of the variable (String
):
int i = 0;
String s = i;
Common fixes
#If the value being assigned is always assignable at runtime, even though the static types don't reflect that, then add an explicit cast.
Otherwise, change the value being assigned so that it has the expected type. In the previous example, this might look like:
int i = 0;
String s = i.toString();
If you can't change the value, then change the type of the variable to be compatible with the type of the value being assigned:
int i = 0;
int s = i;
invalid_dependency
#Publishable packages can't have '{0}' dependencies.
Description
#The analyzer produces this diagnostic when a publishable package includes a package in the dependencies
list of its pubspec.yaml
file that isn't a pub-hosted dependency.
To learn more about the different types of dependency sources, check out Package dependencies.
Example
#The following code produces this diagnostic because the dependency on the package transmogrify
isn't a pub-hosted dependency.
name: example
dependencies:
transmogrify:
path: ../transmogrify
Common fixes
#If you want to publish the package to pub.dev
, then change the dependency to a hosted package that is published on pub.dev
.
If the package isn't intended to be published on pub.dev
, then add a publish_to: none
entry to its pubspec.yaml
file to mark it as not intended to be published:
name: example
publish_to: none
dependencies:
transmogrify:
path: ../transmogrify
invalid_exception_value
#The method {0} can't have an exceptional return value (the second argument) when the return type of the function is either 'void', 'Handle' or 'Pointer'.
Description
#The analyzer produces this diagnostic when an invocation of the method Pointer.fromFunction
or NativeCallable.isolateLocal
has a second argument (the exceptional return value) and the type to be returned from the invocation is either void
, Handle
or Pointer
.
For more information about FFI, see C interop using dart:ffi.
Example
#The following code produces this diagnostic because a second argument is provided when the return type of f
is void
:
import 'dart:ffi';
typedef T = Void Function(Int8);
void f(int i) {}
void g() {
Pointer.fromFunction<T>(f, 42);
}
Common fixes
#Remove the exception value:
import 'dart:ffi';
typedef T = Void Function(Int8);
void