Open pq opened 4 months ago
If this is about running lints on generated code, I assume lots of those probably should not apply.
In particular, all the stylistic ones. For instance avoid_renaming_method_parameters
would be a huge pain for macro authors to handle. Or prefer_double_quotes
vs prefer_single_quotes
doesn't have a finite answer.
Thanks @rrousselGit. Partly yes, this is about generated code. We expect most lints to not apply[*] in that case for exactly the reasons you mention.
Slightly more interesting are lints that might apply (in some potentially limited way) to macros and user created augmentation libraries.
*[]* Indeed, we're especially interested in the ones that should* and we don't have a good categorization for those. (Security lints come to mind... Certain error-protecting ones too...) Feedback welcome!
A meta-issue to discuss and track work on linter support for macros.
Existing Lints
Some existing lints will need tests (minimally) and possibly enhanced implementations.
always_put_control_body_on_new_line
always_use_package_imports
avoid_bool_literals_in_conditional_expressions
avoid_catches_without_on_clauses
avoid_catching_errors
avoid_double_and_int_checks
avoid_dynamic_calls
avoid_empty_else
avoid_escaping_inner_quotes
avoid_final_parameters
avoid_function_literals_in_foreach_calls
avoid_implementing_value_types
avoid_init_to_null
avoid_js_rounded_ints
avoid_multiple_declarations_per_line
avoid_null_checks_in_equality_operators
avoid_print
avoid_redundant_argument_values
avoid_relative_lib_imports
avoid_renaming_method_parameters
avoid_return_types_on_setters
avoid_returning_null_for_void
avoid_returning_this
avoid_shadowing_type_parameters
avoid_single_cascade_in_expression_statements
avoid_slow_async_io
avoid_type_to_string
avoid_types_as_parameter_names
avoid_types_on_closure_parameters
avoid_unnecessary_containers
avoid_void_async
avoid_web_libraries_in_flutter
await_only_futures
cancel_subscriptions
cascade_invocations
cast_nullable_to_non_nullable
close_sinks
collection_methods_unrelated_type
combinators_ordering
comment_references
conditional_uri_does_not_exist
control_flow_in_finally
curly_braces_in_flow_control_structures
dangling_library_doc_comments
depend_on_referenced_packages
deprecated_consistency
deprecated_member_use_from_same_package
diagnostic_describe_all_properties
directives_ordering
discarded_futures
do_not_use_environment
empty_catches
empty_constructor_bodies
empty_statements
eol_at_end_of_file
erase_dart_type_extension_types
exhaustive_cases
file_names
flutter_style_todos
implementation_imports
implicit_call_tearoffs
implicit_reopen
invalid_case_patterns
join_return_with_assignment
leading_newlines_in_multiline_strings
library_annotations
library_names
library_prefixes
library_private_types_in_public_api
lines_longer_than_80_chars
literal_only_boolean_expressions
matching_super_parameters
missing_whitespace_between_adjacent_strings
no_adjacent_strings_in_list
no_default_cases
no_duplicate_case_values
no_leading_underscores_for_library_prefixes
no_leading_underscores_for_local_identifiers
no_literal_bool_comparisons
no_logic_in_create_state
no_runtimeType_toString
no_self_assignments
no_wildcard_variable_uses
noop_primitive_operations
null_check_on_nullable_type_parameter
null_closures
omit_local_variable_types
only_throw_errors
package_names
package_prefixed_library_names
parameter_assignments
prefer_adjacent_string_concatenation
prefer_asserts_in_initializer_lists
prefer_asserts_with_message
prefer_collection_literals
prefer_conditional_assignment
prefer_const_declarations
prefer_const_literals_to_create_immutables
prefer_constructors_over_static_methods
prefer_contains
prefer_double_quotes
prefer_expression_function_bodies
prefer_final_in_for_each
prefer_final_locals
prefer_final_parameters
prefer_for_elements_to_map_fromIterable
prefer_foreach
prefer_function_declarations_over_variables
prefer_if_elements_to_conditional_expressions
prefer_if_null_operators
prefer_initializing_formals
prefer_inlined_adds
prefer_int_literals
prefer_interpolation_to_compose_strings
prefer_is_empty
prefer_is_not_empty
prefer_is_not_operator
prefer_iterable_whereType
prefer_mixin
prefer_null_aware_method_calls
prefer_null_aware_operators
prefer_relative_imports
prefer_single_quotes
prefer_spread_collections
provide_deprecation_message
recursive_getters
require_trailing_commas
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
tighten_type_of_initializing_formals
type_init_formals
type_literal_in_constant_pattern
unawaited_futures
unnecessary_await_in_return
unnecessary_brace_in_string_interps
unnecessary_breaks
unnecessary_const
unnecessary_constructor_name
unnecessary_final
unnecessary_lambdas
unnecessary_late
unnecessary_library_directive
unnecessary_new
unnecessary_null_aware_assignments
unnecessary_null_aware_operator_on_extension_on_nullable
unnecessary_null_checks
unnecessary_null_in_if_null_operators
unnecessary_nullable_for_final_variable_declarations
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_html
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_is_even_rather_than_modulo
use_key_in_widget_constructors
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_test_throws_matchers
use_to_and_as_if_applicable
valid_regexps
void_checks
General questions that have implications for a number of lints:
New Lints
Authors and users of macros (and augmentation classes) might benefit from some new lints.
🚧 Feedback welcome! 🚧
Analyzer / Server Support
Visibility
To whom and under what circumstances should we display diagnostics produced in macro generated files?
/fyi @dart-lang/language-team @bwilkerson @keertip @scheglov @srawlins