rust-lang / rust-lang/rust-analyzer

[diagnostic] replace `<expr> == true` with `<expr>` and `<expr> == false` with `!<expr>`

Open
#11,037 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

A-diagnostics C-feature
Dominant language
Rust
Stars
16.9k
Forks
2.2k
Avg merge
1d 12h
Merged PRs (30d)
72

Description

Also as a degenerate case, !true and !false should become false and true respectively.
As a secondary case, != should do the opposite? At this point I feel like there's another issue but I can't find it.
This should probably only trigger if <expr> evaluates to bool (or !) and has no type errors because:

enum MyBool {
    True,
    False,
}

impl PartialEq<bool> for MyBool {
    fn eq(&self, other: &bool) -> bool {
        match self {
            Self::True => *other,
            Self::False => !*other,
        }
    }
}

fn foo() {
    // compiles
    if MyBool::True == false {
        panic!("True == false");
    }

    // doesn't compile: (`core::ops::Not` not implemented)
    // note that even if `core::ops::Not` was implemented, it probably wouldn't be 
    // if !MyBool::True {}

    // compiles
    if MyBool::True == true {}

    // doesn't compile: (expected `bool`)
    // if MyBool::True {}
}

but, when reviewing code today, I saw a surprising amount of code that is literally just <some expr that evals to bool> == false

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

No files, tests, or entry points are named; begin by locating rust-analyzer's existing diagnostic implementations and their tests for boolean expressions. Define the supported cases from the issue, including type checking and avoiding type-error expressions, then add focused tests for the requested rewrites; the handling of != remains an unresolved design question.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
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.