8000 simple: take assignments to blank identifiers into account · Issue #1106 · dominikh/go-tools · GitHub
[go: up one dir, main page]

Skip to content

simple: take assignments to blank identifiers into account #1106

Open

Description

@ainar-g

(Filing this as simple, although it could as well be a quickfix or an aggressive check.)

The code in question:

package main

import "fmt"

func main() {
        nums := make(chan int, 3)
        nums <- 1
        nums <- 2
        nums <- 3
        close(nums)

        for n := range nums {
                _ = n
                fmt.Println("hello")
        }
}

The code was probably either written before for range was legal or by someone who doesn't know about it. I would expect the code to trigger S1005 or a similar check, but it doesn't, probably because of how the value is “explicitly” unused. Of course, someone could leave it for ease of local debugging, but it still seems like something that people should generally avoid in published code.

Activity

  1. added
    aggressiveA set of checks that is more prone to false positives but is helpful during code review
    needs-decisionWe have to decide if this check is feasible and desirable
    and removed
    needs-triageNewly filed issue that needs triage
    on Oct 27, 2021
  2. dominikh commented on Oct 27, 2021

    @dominikh
    Owner

    It can probably go at least into aggressive. I am less sure about simple.

    Related: #253

  3. dominikh commented on Oct 27, 2021

    @dominikh
    Owner

    There's also a distinction to be made between flagging this in S1005, and flagging assignments to blank identifiers on a general basis. The former might be acceptable for simple while the latter isn't.

  4. ainar-g commented on Oct 27, 2021

    @ainar-g
    Author

    Issue 253 looks very relevant, thanks. In fact, feel free to close this issue as a dup or merge it into that one.

    I'm fine with it being in the aggressive checker instead of the plain simple.

  5. dominikh commented on Oct 27, 2021

    @dominikh
    Owner

    #253 is related, but not identical. #253 is concerned with removing assignments that are entirely redundant. That is, simply removing it will not cause compilation to fail. What you're asking for goes a step further. It wants to remove an assignment even if (or especially if?) it requires changing the surrounding code. I'll keep both issues for now.

  6. added this to the Staticcheck 2022.2 milestone on Jan 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    aggressiveA set of checks that is more prone to false positives but is helpful during code reviewneeds-decisionWe have to decide if this check is feasible and desirablenew-check

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0