Linter: avoid_types_on_closure_parameters conflicts with strong_mode_implicit_dynamic_parameter

Created on 8 Jun 2017  路  9Comments  路  Source: dart-lang/linter

image

info: Avoid annotating types on function expression parameters. (avoid_types_on_closure_parameters at [fhir_designer] lib/app_code_generator/form_service_generator.dart:9)

When I remove Form I get

error: Missing parameter type for 'key'. (strong_mode_implicit_dynamic_parameter at [fhir_designer] lib/app_code_generator/form_service_generator.dart:9)

There is also no quick-fix to suppress the error.

analyzer:
#  enable_new_analysis_driver: true
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

linter:
  rules:
# Error Rules
    - avoid_empty_else
    - avoid_slow_async_io
    - cancel_subscriptions
    - close_sinks
    - comment_references
    - control_flow_in_finally
    - empty_statements
    - hash_and_equals
    - invariant_booleans
    - iterable_contains_unrelated_type
    - list_remove_unrelated_type
    - literal_only_boolean_expressions
    - no_adjacent_strings_in_list
    - no_duplicate_case_values
    - test_types_in_equals
    - throw_in_finally
    - unrelated_type_equality_checks
    - valid_regexps

# Style Rules
    - always_declare_return_types
#    - always_specify_types
    - annotate_overrides
#    - avoid_as
    - avoid_function_literals_in_foreach_calls
    - avoid_init_to_null
    - avoid_return_types_on_setters
    - await_only_futures
    - camel_case_types
    - cascade_invocations
    - constant_identifier_names
#    - directives_ordering
    - empty_catches
    - empty_constructor_bodies
    - implementation_imports
    - library_names
    - library_prefixes
    - non_constant_identifier_names
#    - omit_local_variable_types
    - one_member_abstracts
    - only_throw_errors
    - overridden_fields
    - package_api_docs
    - package_prefixed_library_names
    - prefer_adjacent_string_concatenation
    - prefer_collection_literals
    - prefer_const_constructors
    - prefer_contains
    - prefer_expression_function_bodies
    - prefer_function_declarations_over_variables
    - prefer_initializing_formals
    - prefer_interpolation_to_compose_strings
    - prefer_is_empty
    - prefer_is_not_empty
    - parameter_assignments
    - prefer_final_fields
    - prefer_final_locals
#    - public_member_api_docs
    - recursive_getters
    - slash_for_doc_comments
    - sort_constructor_first
    - sort_unnamed_constructors_first
    - super_goes_last
#    - type_annotate_public_apis
    - type_init_formals
    - unawaited_futures
    - unnecessary_brace_in_string_interps
    - unnecessary_getters_setters
    - unnecessary_lambdas
    - unnecessary_null_aware_assignments
    - unnecessary_null_in_if_null_operators

# Pub Rules
    - package_names
Dart VM version: 1.24.0-dev.6.8 (Mon Jun  5 15:26:29 2017) on "macos_x64"
strong-mode-conflict

Most helpful comment

I have been seeing this and definitely is annoying, will look at it in my next batch of fixes.

All 9 comments

Hmmmm. This looks like yet another place where we need to (re)consider strong mode implications.

@bwilkerson: thoughts?

Yes, I agree, the rule should be strong-mode aware.

Not sure this fits here

image

image

image

this works

final response = await childRef.set(_serializeCategory(category)) as Object;

the called set():

Future set(value) => handleThenable(jsObject.set(jsify(value)));

I have been seeing this and definitely is annoying, will look at it in my next batch of fixes.

One more example of this conflict:

// ignore: avoid_types_on_closure_parameters
final iterable = (int length, int value) sync* {
  var index = 0;
  while (index < length) {
    yield value;
  }
}(100, 1);

Here, types on closure need to be defined for inference to work.

It also happens in

          child: TypeAheadFormField<String>(
            textFieldConfiguration: TextFieldConfiguration<dynamic>(
              onSubmitted: (dynamic _) {
                ...
              },
            ),
            ...

With avoid_annotating_with_dynamic vs strong_mode_implicit_dynamic_parameter.

I guess I'll disable the former.

@pq bumping this issue since this seems like something that should be fixed considering we've had strong mode for over a year now.

The error code strong_mode_implicit_dynamic_parameter was removed in https://dart-review.googlesource.com/c/sdk/+/128821. That probably resolves this issue.

Was this page helpful?
0 / 5 - 0 ratings