oxidecomputer / oxidecomputer/hubris

We've suppressed a bunch of useful warnings pending cleanup.

Open
#1,895 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

During the last two toolchain updates, I had to contend with new Clippy warnings. Rather than clean up all existing code, I wound up suppressing some. It would be great to get these turned back on, either at the workspace level, or in individual crates (as an incremental step).

The warnings that are currently globally suppressed, but probably should not be, are:

  • clippy::missing_safety_doc -- our intention is to have safety docs on every unsafe operation and every unsafe block, to simplify auditing. We don't currently.
  • clippy::wildcard_imports -- see #1894 for specific tracking on this
  • clippy::too_many_arguments -- if individual functions really believe they need that many arguments, they can suppress the warning on just the function.
  • clippy::identity_op -- may indicate a logic error, easy to suppress locally if it does not.
  • clippy::manual_inspect -- inspect became stable on more APIs a while back and should generally be preferred to map if you're just looking at the data passing by -- it makes it harder to accidentally alter it, and should be easier for the compiler to simplify.
  • clippy::single_match -- in almost every case if let is preferable, and this can be suppressed in the very rare cases where a match is right (example: generated code)

And just to get out of the habit of suppressing Clippy warnings, we will eventually also want to deal with these, but they're more work since they require rewrapping/flowing comments -- and Clippy and (neo)vim disagree on how to flow Markdown, so you have to do it manually.

  • clippy::too_long_first_doc_paragraph -- possibly my least favorite Clippy lint, this has developed opinions about how long the initial sentence in your docs can be
  • clippy::doc_lazy_continuation -- this is slightly more important, it catches improperly constructed bulleted list in doc comments.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the workspace-level and individual-crate Clippy suppression settings, then review the listed lints and the related tracking issue #1894. Done means the useful warnings are re-enabled where practical, existing violations are cleaned up, and exceptional cases use local suppressions; the two comment-formatting lints may remain for later work.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.