rust-lang / rust-lang/rust-clippy

Add lint for inference hazards (0u64 < foo.into())

Open
#14,478 4 comments 8 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-lint
Dominant language
Rust
Stars
13.5k
Forks
2.2k
Avg merge
2d 10h
Merged PRs (30d)
32

Description

What it does

Recently, the release of deranged 0.4.1 broke a whole bunch of downstream code. Example from that issue:

error[E0283]: type annotations needed
   --> /Users/me/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/plist-1.7.0/src/stream/binary_reader.rs:252:58
    |
252 |                 if value < 0 || value > u64::max_value().into() {
    |                                       -                  ^^^^
    |                                       |
    |                                       type must be known at this point
    |
    = note: multiple `impl`s satisfying `i128: PartialOrd<_>` found in the following crates: `core`, `deranged`:
            - impl PartialOrd for i128;
            - impl<MIN, MAX> PartialOrd<deranged::RangedI128<MIN, MAX>> for i128
              where the constant `MIN` has type `i128`, the constant `MAX` has type `i128`;
help: try using a fully qualified path to specify the expected types
    |
252 |                 if value < 0 || value > <u64 as Into<T>>::into(u64::max_value()) {
    |                                         +++++++++++++++++++++++                ~

It would be nice if a clippy lint would suggest avoiding this kind of reliance on type inference, specifically in comparisons (which I think are more likely to suffer from this), and especially if the other side of the comparison contains a foreign type (if it's a local type, there should be no spooky action at a distance inference hazard). In this example, for example, clippy should suggest using i128::from(u64::max_value()).

Advantage

Robustness against inference hazards.

Drawbacks

The new code might be slightly more verbose, but will be more robust to inference hazards that can be introduced in any crate in your dependency graph.

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

The issue names no repository files, entry points, or tests. Start by reproducing the inference failure from the linked example and reviewing how existing Clippy lints and their tests are organized; done means a lint reliably identifies the described comparison hazard and offers an explicit-conversion suggestion.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.