Repository navigation
Migrate to span_clippy_lint #7797
Description
We have a handful of utils for emitting lints: span_lint, span_lint_and_help, etc. We'd like to replace these with one new util named span_clippy_lint. It was already implemented in #7668, but not yet merged.
Goals
- Be more consistent with rustc
- Potentially improve perf since allowed lints stop before computing output messages
- Enable trimmed paths (Enable trimmed paths #7798)
Question: Should we use .emit() like rustc, or use Drop to emit automatically?
Steps
- Add
span_clippy_lintfrom Enable trimmed paths #7668 and patch the metadata collector to work with it - Change all
span_lint_*calls tospan_clippy_lint - divide this into smaller parts?
- Remove
span_lint*utils and metadata collector support
Activity
xFrednet commentedon Jul 21, 2024
I took a small stab at this and refactored 40 restriction lints in #13136.
Check list
absolute_pathsalloc_instead_of_coreallow_attributesallow_attributes_without_reasonarithmetic_side_effectsas_conversionsas_underscoreassertions_on_result_statesbig_endian_bytescfg_not_testclone_on_ref_ptrcreate_dirdbg_macrodecimal_literal_representationdefault_numeric_fallbackdefault_union_representationderef_by_slicingdisallowed_script_identselse_if_without_elseempty_dropempty_enum_variants_with_bracketsempty_structs_with_bracketserror_impl_errorexhaustive_enumsexhaustive_structsexitexpect_usedfield_scoped_visibility_modifiersfiletype_is_filefloat_arithmeticfloat_cmp_constfn_to_numeric_cast_anyformat_push_stringget_unwraphost_endian_bytesif_then_some_else_noneimpl_trait_in_paramsimplicit_returnindexing_slicinginfinite_loopinline_asm_x86_att_syntaxinline_asm_x86_intel_syntaxinteger_divisioninteger_division_remainder_usediter_over_hash_typelarge_include_filelet_underscore_must_uselet_underscore_untypedlittle_endian_byteslossy_float_literalmap_err_ignoremem_forgetmin_ident_charsmissing_assert_messagemissing_asserts_for_indexingmissing_docs_in_private_itemsmissing_inline_in_public_itemsmissing_trait_methodsmixed_read_write_in_expressionmod_module_filesmodulo_arithmeticmultiple_inherent_implmultiple_unsafe_ops_per_blockmutex_atomicneedless_raw_stringsnon_ascii_literalpanicpanic_in_result_fnpartial_pub_fieldspattern_type_mismatchprint_stderrprint_stdoutpub_usepub_with_shorthandpub_without_shorthandquestion_mark_usedrc_bufferrc_mutexredundant_type_annotationsref_patternsrenamed_function_paramsrest_pat_in_fully_bound_structssame_name_methodself_named_module_filessemicolon_inside_blocksemicolon_outside_blockseparated_literal_suffixshadow_reuseshadow_sameshadow_unrelatedsingle_call_fnsingle_char_lifetime_namesstd_instead_of_allocstd_instead_of_corestr_to_stringstring_addstring_lit_chars_anystring_slicestring_to_stringsuspicious_xor_used_as_powtests_outside_test_moduletodotry_errundocumented_unsafe_blocksunimplementedunnecessary_safety_commentunnecessary_safety_docunnecessary_self_importsunneeded_field_patternunreachableunseparated_literal_suffixunwrap_in_resultunwrap_useduse_debugverbose_file_readswildcard_enum_match_arm@rustbot claim
Auto merge of #13144 - xFrednet:07797-restriction-and-then-what, r=y21
Auto merge of #13136 - xFrednet:07797-restriction-and-then, r=blyxyas
Auto merge of #13145 - xFrednet:07797-restriction-and-then-why, r=Jarcho
ada4a commentedon Aug 22, 2025
Sorry for necroposting (?); I wanted to ask what the status of this is, because AFAICT
span_clippy_lintis not really a thing anymore.But also, #13136 also cites this issue as the reason for the switch from
span_lint_and_{help,note,sugg}tospan_lint_and_then. AFAIU that's motivated by the laziness of the latter, but I personally like the brevity of the former, so maybe (a shot in the dark here, not really familiar with this stuff) the former could be rewritten to use the latter internally, so that we get to keep both brevity and laziness?camsteffen commentedon Sep 3, 2025
It never was a thing. See OP:
I assume by "laziness" you mean being able to defer logic to the closure?
The problem is that you are forced to build all the parts of the diagnostic upfront, which is a waste if the lint is not enabled.
Personally, I like the modularity of just using the diagnostic builder instead of creating another
span_lint_and_xxxfor every combination. And I think those methods effectively stop folks from considering using both a suggestion and a note, or two suggestions, etc.ada4a commentedon Sep 3, 2025
Yes
I thought the lint pass wouldn't run at all if the lint is disabled?.. Surely it's less expensive to check whether a particular node has the lint
allowed before runningvisit_*on it? I guess that wouldn't quite work with passes consisting of multiple lints though, among other problems.I see your point, but on the other hand, having these helpers does make it easier to onboard new contributors imo (based on personal experience)