Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Allow #[allow(clippy::mutable_key_type)] on type definitions #13865

Open
anko opened this issue Dec 22, 2024 · 0 comments
Open

Idea: Allow #[allow(clippy::mutable_key_type)] on type definitions #13865

anko opened this issue Dec 22, 2024 · 0 comments
Labels
C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages

Comments

@anko
Copy link

anko commented Dec 22, 2024

Description

Problem

I am getting false positives from mutable_key_type on a type I own. (Illustrative Playground.) The current options to silence them are:

  • Label each site at which it is used, with #[allow(clippy::mutable_key_type)].

    • Downside: The annotations add lots of noise if there are many use-sites. And since the actual type definition has no such annotations, it is possible someone might modify it to be mutable without realising that it's important not to.
  • Add the type to clippy.toml or other config, under the key ignore-interior-mutability.

    • Downside: Nothing in the code warns about the expected invariant. You have to realise to look in the clippy configuration file.

My solution so far has been to do the latter, and write a comment on the key type's definition, explaining the situation and referring to the clippy config file.

Idea

What if type definitions could also be annotated with #[allow(clippy::mutable_key_type)]?

It feels a lot more intuitive than the current options, and would simultaneously

  • make the lint ignore that type,
  • document the expected invariant for other contributors at the right location,
  • cause no noise at the call site where the code is already correct, and
  • fit into the lint tooling ecosystem, allowing the reasoning to be listed attached to the allow as a lint reason, instead of an impromptu comment.

Version

rustc 1.85.0-nightly (6d9f6ae36 2024-12-16)
binary: rustc
commit-hash: 6d9f6ae36ae1299d6126ba40c15191f7aa3b79d8
commit-date: 2024-12-16
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5

Additional Labels

@rustbot label +C-enhancement

@rustbot rustbot added the C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages label Dec 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Enhancement of lints, like adding more cases or adding help messages
Projects
None yet
Development

No branches or pull requests

2 participants