Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Add a strict clippy config

Aberta
  • Algo errado?
#4,071 0 comentários 2 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@seanmonstar já está trabalhando nisso.

Desde 19/5/2026.

  • #4091 de @nakaryo716 — integrado
  • #4120 de @yanns — aberto
  • #4121 de @yanns — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

C-refactor E-easy E-pr-welcome

hyper for a long time never bothered with clippy. Mostly for historical reasons and opinions.

I've now come around to just turning clippy up to 11. What I'm currently leaning towards is keeping an allowlist, and otherwise denying pedantic and even restriction lints. Yes, I know there's a restriction lint against linting for the restriction group. An allowlist still makes a lot of sense to me. If after a bit it turns out to be just unbearable, we can convert it to a bigger deny list, I guess.

The initial config is in place, with a CI job that enforce it, so we won't regress with new code. Now, we just need to evaluate all the undecided lints, and either choose to allow them for sure, or fix them.

How to help

Look at the list of lints that need to be decided upon in the Cargo.toml (it's around there, the line might move slightly).

  1. Pick a lint.
  2. If it seems obviously an improvement:
    1. Fix up the code from the lint.
      • It might be as simple as cargo clippy --fix --features full.
      • It might be obvious enough for an LLM to automate fixing. (But only if you understand what changes it made.)
      • It might need manual adjustment in each case.
      • It might need to be #[allow(this_lint)] in specific cases, where the lint is usually useful.
    2. Remove the allowed lint from the Cargo.toml
    3. Submit a PR for one lint at a time.
  3. If it is not obviously an improvement:
    1. Move the lint down lower to the explicitly allowed list in the Cargo.toml
    2. Add a comment why the lint is being allowed
    3. Submit a PR (multiple lints solved this way is fine in a single PR)

Steps

  • #4075
  • address each one in in the todo list
    • arithmetic_side_effects = "allow" # TODO: consider
    • as_conversions = "allow" # TODO: tricky
    • borrow_as_ptr = "allow"
    • cast_lossless = "allow" # TODO: easy fix
    • cast_possible_truncation = "allow" # TODO: consider
    • cast_precision_loss = "allow" # TODO: consider
    • checked_conversions = "allow"
    • collapsible_match = "allow"
    • decimal_literal_representation = "allow" # TODO: consider
    • default_trait_access = "allow"
    • else_if_without_else = "allow"
    • empty_structs_with_brackets = "allow" # TODO: easy fix
    • enum_glob_use = "allow"
    • explicit_iter_loop = "allow" # TODO: easy fix
    • float_arithmetic = "allow"
    • ignored_unit_patterns = "allow"
    • indexing_slicing = "allow"
    • integer_division = "allow"
    • integer_division_remainder_used = "allow"
    • large_enum_variant = "allow"
    • let_unit_value = "allow"
    • manual_assert = "allow" # TODO: easy fix
    • manual_assert_eq = "allow" # TODO: easy fix
    • map_err_ignore = "allow"
    • map_unwrap_or = "allow"
    • match_wild_err_arm = "allow"
    • missing_fields_in_debug = "allow" # TODO: use finish_non_exhaustive
    • missing_errors_doc = "allow" # TODO: good to fix
    • missing_panics_doc = "allow" # TODO: might be false
    • multiple_inherent_impl = "allow"
    • multiple_unsafe_ops_per_block = "allow"
    • needless_continue = "allow"
    • needless_pass_by_value = "allow"
    • panic = "allow"
    • pattern_type_mismatch = "allow"
    • ptr_as_ptr = "allow"
    • question_mark = "allow" # TODO: probably easy fix
    • redundant_closure_for_method_calls = "allow"
    • redundant_else = "allow"
    • ref_option = "allow"
    • ref_patterns = "allow" # TODO: perhaps deny?
    • semicolon_if_nothing_returned = "allow" # TODO: easy fix
    • single_char_lifetime_names = "allow"
    • single_match_else = "allow" # TODO: easy fix
    • struct_excessive_bools = "allow" # TODO: bogus lint?
    • trivially_copy_pass_by_ref = "allow"
    • undocumented_unsafe_blocks = "allow" # TODO: fix me
    • uninlined_format_args = "allow" # TODO: easy fix
    • unnecessary_semicolon = "allow" # TODO: easy fix
    • unnecessary_trailing_comma = "allow"
    • unnested_or_patterns = "allow"
    • unused_async = "allow" # TODO: is it for API?
    • unused_trait_names = "allow" # TODO: kinda annoying, but might be good to deny
    • unwrap_in_result = "allow"
    • useless_borrows_in_formatting = "allow"
    • wildcard_enum_match_arm = "allow"
    • wildcard_imports = "allow" # TODO: never, except for tests
Linguagem predominante
Rust
Estrelas
16.4k
Forks
1.8k
Merge médio
2d 9h
PRs com merge (30d)
14

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de hyperium/hyper

Todas as issues de hyperium/hyper

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.