[Extension type] linter support

[pq]

A meta-issue to discuss and track work on linter support for extension types.

Feature Spec

Existing Lints

Some existing lints will need tests (minimally) and possibly enhanced implementations.

• annotate_overrides support for extension types #59263
• avoid_catching_errors, see [Extension type] linter support #58838
• avoid_setters_without_getters support for extension types #59264
• avoid_shadowing_type_parameters support for extension types #59253
• avoid_slow_async_io, see [Extension type] linter support #58838
• avoid_types_as_parameter_types, see [Extension type] linter support #58838
• avoid_type_to_string support for extension types #59326
• avoid_types_as_parameter_names support for extension types #59294
• await_only_futures support for extension types #59252
• cancel_subscriptions, see [Extension type] linter support #58838
• camel_case_types support for extension types #59272
• collection_methods_unrelated_type, see [Extension type] linter support #58838
• close_sinks, see [Extension type] linter support #58838
• deprecated_member_use_from_same_package support for extension types #59271
• diagnostic_describe_all_properties support for extension types
• discarded_futures, see [Extension type] linter support #58838
• hash_and_equals support for extension types #59247
• library_private_types_in_public_api support for extension types #59242
• non_constant_identifier_names support for extension types #59254
• only_throw_errors, see [Extension type] linter support #58838
• overridden_fields support for extension types
• package_api_docs support for extension types
• prefer_asserts_in_initializer_lists support for extension types #59324
• prefer_const_constructors support for extension types #59274
• prefer_const_constructors_in_immutables support for extension types #59275
• prefer_const_declarations support for extension types
• prefer_const_literals_to_create_immutables support for extension types #59276
• prefer_constructors_over_static_methods support for extension types #59250
• prefer_final_fields support for extension types #59243
• prefer_void_to_null false positive for extension types #59308
• public_member_api_docs support for extension types #59239
• sort_constructors_first support for extension types #59245
• sort_unnamed_constructors_first support for extension types #59246
• type_annotate_public_apis support for extension types #59270
• unnecessary_constructor_name support for extension types #59249
• unnecessary_getters_setters support for extension types #59266
• unnecessary_overrides support for extension types
• unnecessary_this support for extension types #59248
• unreachable_from_main, see [Extension type] linter support #58838
• unrelated_type_equality_checks, see [Extension type] linter support #58838
• unsafe_html, see [Extension type] linter support #58838
• use_key_in_widget_constructors support for extension types
• use_late_for_private_fields_and_variables support for extension types #59251

🚧 Incomplete list: feedback welcome! 🚧

New Lints

Users of extension types might benefit from some new lints.

• proposal: annotate_redeclares #59297

See also: #53121

...

[IvanDembicki]

avoid_logic_in_view_classes

[bwilkerson]

@IvanDembicki Could you provide more information about what the proposed lint would actually do (either here or in a separate issue, the latter being my personal preference).

[IvanDembicki]

bwilkerson #58844

[pq]

@eernstg: in the spec you write:

we make no attempt to hide the representation type during the exhaustiveness analysis. The usage of such patterns is very similar to a cast into the extension type in the sense that it provides a reference of type V to an object without running any constructors of V. We will rely on lints in order to inform developers about such situations, similarly to the treatment of expressions like e as V.

Could you provide a bit of detail on the lints you had imagined?