Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Add a strict clippy config

Abierto
  • ¿Algo no está bien?
#4,071 0 comentarios 2 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 2 días

@seanmonstar ya está trabajando en esto.

Desde el 19/5/2026.

  • #4091 de @nakaryo716 — fusionado
  • #4120 de @yanns — abierto
  • #4121 de @yanns — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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
Lenguaje dominante
Rust
Estrellas
16.3k
Forks
1.8k
Merge medio
5 d 17 min
PR fusionados (30 d)
19

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hyperium/hyper

Todos los issues de hyperium/hyper

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.