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

proposal: cmd/vet: detect values assigned but not used #23142

Open
rmanansa opened this issue Dec 14, 2017 · 12 comments
Open

proposal: cmd/vet: detect values assigned but not used #23142

rmanansa opened this issue Dec 14, 2017 · 12 comments
Labels
Analysis Issues related to static analysis (vet, x/tools/go/analysis) FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal Proposal-Hold
Milestone

Comments

@rmanansa
Copy link

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go1.9 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"

on MacOS X Sierra

What did you do?

I wrote this code below and then run go vet. err is never used or checked.

	defer resp.Body.Close()
	body, err := ioutil.ReadAll(resp.Body)

	return body, resp.StatusCode, nil
}

What did you expect to see?

I expect that when I run $> go vet then I should see some error
notification that this err variable is not used or something.

What did you see instead?

None.

@bradfitz bradfitz changed the title go vet does not catch when err is not used before a return cmd/vet: does not catch when err is not used before a return Dec 14, 2017
@bradfitz bradfitz added this to the Go1.11 milestone Dec 14, 2017
@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 14, 2017
@bradfitz
Copy link
Contributor

Please show complete code.

Is that a new err variable or an existing err? Maybe only body is new in that snippet. If so, that's a different feature request.

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Dec 14, 2017
@rmanansa
Copy link
Author

func (tc *RTClient) requestDo(req *http.Request, auth bool) ([]byte, int, error) {
	if auth {
		tokenBasic, err := tc.getToken()
		if err != nil {
			return nil, ExitCode, err
		}
		req.Header.Set(Authorization, Basic+" "+tokenBasic)
	}

	resp, err := tc.httpClient.Do(req)
	if err != nil {
		return nil, ExitCode, err
	}

	defer resp.Body.Close()
	body, err := ioutil.ReadAll(resp.Body)

	return body, resp.StatusCode, nil
}

@rmanansa
Copy link
Author

Hello @bradfitz thanks for the quick reply. The second to the last line of the function has err redeclared. Was expecting that running go vet will flag it when there are no usage of err var after it got redeclared.

@bradfitz
Copy link
Contributor

The err variable isn't redeclared there. Only body is declared. The err variable is just reassigned.

That is, your bug report or feature request is equivalent to:

package vettest

func foo() {
        a := 1
        if a == 2 {
                // ...
        }
        a = 3 // no vet warning here                                                                                                                                              
}               

@bradfitz bradfitz removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Dec 15, 2017
@bradfitz bradfitz changed the title cmd/vet: does not catch when err is not used before a return cmd/vet: assigned-but-not-used errors could be more aggressive Dec 15, 2017
@bradfitz bradfitz modified the milestones: Go1.11, Unplanned Dec 15, 2017
@dominikh
Copy link
Member

FTR, staticcheck as well as ineffassign catch this.

@rsc rsc changed the title cmd/vet: assigned-but-not-used errors could be more aggressive proposal: cmd/vet: detect values assigned but not used Jul 22, 2020
@rsc rsc modified the milestones: Unplanned, Proposal Jul 22, 2020
@rsc
Copy link
Contributor

rsc commented Jul 22, 2020

Moved this into the proposal process to replace #40286.
The proposal here is to have cmd/vet do more precise "assigned and not used" checks than the compiler does.
For example the compiler rejects:

 x := 1
 ... no use of x ...

but it does not flag the first assignment in:

x := 1
x = 2
... use of x ...

nor the second in:

x := 1
... use of x ...
x = 2

Vet could flag both of those cases (for all types of variables, not just errors).

@rsc
Copy link
Contributor

rsc commented Jul 22, 2020

What's needed here is a simple implementation and then some info about whether there are false positives or just too many reports on existing Go code.

@rsc
Copy link
Contributor

rsc commented Jul 22, 2020

@spf13 points out that some people like to write

x := T{}

instead of

var x T

and that we probably should not flag lack-of-use for a := declaration+assignment that is assigning a zero value.

@networkimprov
Copy link

I initialize a slice index to -1, so that if it's used without being reassigned, slice[index] gives a runtime error.

int x := -1
for x = 0; x < len(s) && s[x] != y ; x++ { }
f(&s[x])

@rsc
Copy link
Contributor

rsc commented Jul 29, 2020

Does anyone want to try writing this check and see how many false positives it has?

@rsc
Copy link
Contributor

rsc commented Aug 5, 2020

In theory this seems like a good idea, but there are many possible implementations with subtle differences.
Placing this issue on hold until we have more concrete details about a specific vet check to evaluate.

@dgryski
Copy link
Contributor

dgryski commented Aug 5, 2020

There are already two different implementations: staticcheck and ineffassign. In my experience, they have almost no false positives, or no worse than anything reported by go vet. And given that many devs already run staticcheck across their codebase, those ones are likely to be "assigned-but-not-used" clean, so I don't think this will be a huge burden to the community.

@rsc rsc moved this to Hold in Proposals Aug 10, 2022
@rsc rsc added this to Proposals Aug 10, 2022
@adonovan adonovan added the Analysis Issues related to static analysis (vet, x/tools/go/analysis) label Apr 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Analysis Issues related to static analysis (vet, x/tools/go/analysis) FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal Proposal-Hold
Projects
Status: Hold
Development

No branches or pull requests

8 participants