-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add server quickfixes/assists for all the lints #57878
Comments
This is great! Perhaps we should have a shorter list of quick fixes we intend to address sooner? We could start with the lints from package:pedantic, remove lints where quick fixes don't make sense, and possibly add one or two high value lints. |
Please tell me you have a script to update that table. 😄 |
Please please please |
|
Things already done by dartfmt --fix are lower pri for me :-)
…On Fri, Jan 18, 2019 at 2:09 PM Devon Carew ***@***.***> wrote:
slash_for_doc_comments? prefer_generic_function_type_aliases?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#57878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABCim4ActxdQYfjNZznfZSUE8dF2czaks5vEkYFgaJpZM4aItKC>
.
|
Sorry, I don't quite get the light bulb image. Does that mean a quickfix exists for that lint? |
I'm totally in favor of adding fixes where possible, but there are cases where a fix doesn't make sense, such as Also, we often choose to implement such "fixes" as quick assists, because then they're available to users even if they haven't enabled the lint. The scorecard doesn't take that into account (and I don't know how to compute that; there's no indication anywhere in the code that the assist is appropriate for the lint).
Great examples! We have assists for all of those. |
👍 https://github.com/dart-lang/linter/blob/master/tool/scorecard.dart
Sorry, yeah. May just as well have been a checkmark but assists are often displayed with lightbulbs in IDEs so I was trying to be cute.
Right. That's what I was trying to say with the "that can naturally be fixed automatically" qualifier above. Can you think of a better way to say that? However we describe it, I'd like to capture the information somewhere so we can exclude lints that aren't fixable from consideration. Ideas for where that should live most welcome! |
Yes, right (as in |
Addressing #57754 would address #57600, but I don't believe we have the resources to address either one this quarter, and I wouldn't want this to wait until we did. (And it won't be any harder to move 20 fixes to a plugin than to move 10.) That said, the right way (imo) to address this issue is to
|
See: https://github.com/dart-lang/linter/issues/1374. Change-Id: Ieeddf25718ddde77a9e52cb93cbcf34ca2c1f81f Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95542 Commit-Queue: Phil Quitslund <pquitslund@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
See: https://github.com/dart-lang/linter/issues/1374. Change-Id: I945d393b0b46cf87b5400be1bfdb501c31646988 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95669 Commit-Queue: Phil Quitslund <pquitslund@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
See: https://github.com/dart-lang/linter/issues/1374. Change-Id: I7e79ad37681afdbd94d7968451a768e74217578e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95708 Commit-Queue: Phil Quitslund <pquitslund@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
See: https://github.com/dart-lang/linter/issues/1374. Change-Id: Ia09f2530c9a943b8b80fda63fb313b752748264a Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95709 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Phil Quitslund <pquitslund@google.com>
showing support for prefer_final_in_for_each |
See: https://github.com/dart-lang/linter/issues/1374 Change-Id: I151170ee2374a726dc6be037b25e1c7a54729bec Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115266 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Phil Quitslund <pquitslund@google.com>
|
@DetachHead this issue is not really actionable (naturally every lint should have a quick fix or assist if applicable, but this is more of just a policy now than a concrete task); you will probably get more traction opening a request specifically for |
This list is stale. The current source of truth is: https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/lib/src/services/correction/error_fix_status.yaml and also tracked in the individual rule docs: |
Ideally we should have fixes (or assists) associated w/ all the lint rules (that can naturally be fixed automatically).
For context, this scorecard tells us where we currently stand.
always_declare_return_types
always_put_control_body_on_new_line
always_put_required_named_parameters_first
always_require_non_null_named_parameters
always_specify_types
annotate_overrides
avoid_annotating_with_dynamic
avoid_as
avoid_bool_literals_in_conditional_expressions
avoid_catches_without_on_clauses
avoid_catching_errors
avoid_classes_with_only_static_members
avoid_double_and_int_checks
avoid_empty_else
avoid_field_initializers_in_const_classes
avoid_function_literals_in_foreach_calls
avoid_implementing_value_types
avoid_init_to_null
avoid_js_rounded_ints
avoid_null_checks_in_equality_operators
avoid_positional_boolean_parameters
avoid_private_typedef_functions
avoid_relative_lib_imports
avoid_renaming_method_parameters
avoid_return_types_on_setters
avoid_returning_null
avoid_returning_null_for_future
avoid_returning_null_for_void
avoid_returning_this
avoid_setters_without_getters
avoid_shadowing_type_parameters
avoid_single_cascade_in_expression_statements
avoid_slow_async_io
avoid_types_as_parameter_names
avoid_types_on_closure_parameters
avoid_unused_constructor_parameters
avoid_void_async
await_only_futures
camel_case_types
cancel_subscriptions
cascade_invocations
close_sinks
comment_references
constant_identifier_names
control_flow_in_finally
curly_braces_in_flow_control_structures
directives_ordering
empty_catches
empty_constructor_bodies
empty_statements
file_names
flutter_style_todos
hash_and_equals
implementation_imports
invariant_booleans
0.1.252.0.0deprecatediterable_contains_unrelated_type
join_return_with_assignment
library_names
library_prefixes
lines_longer_than_80_chars
list_remove_unrelated_type
literal_only_boolean_expressions
no_adjacent_strings_in_list
no_duplicate_case_values
non_constant_identifier_names
null_closures
omit_local_variable_types
one_member_abstracts
only_throw_errors
overridden_fields
package_api_docs
package_names
package_prefixed_library_names
parameter_assignments
prefer_adjacent_string_concatenation
prefer_asserts_in_initializer_lists
prefer_bool_in_asserts
prefer_collection_literals
prefer_conditional_assignment
prefer_const_constructors
prefer_const_constructors_in_immutables
prefer_const_declarations
prefer_const_literals_to_create_immutables
prefer_constructors_over_static_methods
prefer_contains
prefer_equal_for_default_values
prefer_expression_function_bodies
prefer_final_fields
prefer_final_in_for_each
prefer_final_locals
prefer_foreach
prefer_function_declarations_over_variables
prefer_generic_function_type_aliases
prefer_initializing_formals
prefer_int_literals
prefer_interpolation_to_compose_strings
prefer_is_empty
prefer_is_not_empty
prefer_iterable_whereType
prefer_mixin
prefer_single_quotes
prefer_typing_uninitialized_variables
prefer_void_to_null
public_member_api_docs
recursive_getters
slash_for_doc_comments
sort_constructors_first
sort_pub_dependencies
sort_unnamed_constructors_first
super_goes_last
test_types_in_equals
throw_in_finally
type_annotate_public_apis
type_init_formals
unawaited_futures
unnecessary_await_in_return
unnecessary_brace_in_string_interps
unnecessary_const
unnecessary_getters_setters
unnecessary_lambdas
unnecessary_new
unnecessary_null_aware_assignments
unnecessary_null_in_if_null_operators
unnecessary_overrides
unnecessary_parenthesis
unnecessary_statements
unnecessary_this
unrelated_type_equality_checks
use_function_type_syntax_for_parameters
use_rethrow_when_possible
use_setters_to_change_properties
use_string_buffers
use_to_and_as_if_applicable
valid_regexps
void_checks
The text was updated successfully, but these errors were encountered: