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

Jump to bottom

go/types: missing "declared but not used" error #23593

Closed
griesemer opened this issue Jan 28, 2018 · 3 comments
Closed

go/types: missing "declared but not used" error #23593

griesemer opened this issue Jan 28, 2018 · 3 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.11

Comments

@griesemer
Copy link
Contributor 

package main

func main() {
	var i int
        defer func() {}
}

type-checks with only one error:

x.go:5:24: function must be invoked in defer statement

It should also complain about i being declared but not used.

See also #23586.
@griesemer griesemer self-assigned this Jan 28, 2018
@griesemer griesemer added this to the Go1.11 milestone Jan 28, 2018
@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 28, 2018
@griesemer griesemer changed the title go/types: missing declared but not used error go/types: missing "declared but not used" error Jan 28, 2018
@griesemer
Copy link
Contributor Author

go test -run Check -files=x.go reports both errors; and rebuilding gotype doesn't seem to make a difference. Hmm...

@griesemer
Copy link
Contributor Author

The root cause for the current behavior is that the check that the defer expression is a function call happens at parse time; and if there are parse errors, gotype stops (and doesn't bother type-checking the code). go/types testing on the other hand continues, hence the discrepancy.

We cannot easily remove the parser check as it would require changing the field go/ast/DeferStmt.Call (which we know is a *go/ast/CallExpr) to an unchecked expression, which is a backward-incompatible change.

Instead, make gotype continue with type-checking even if there are parser errors.

@gopherbot
Copy link

Change https://golang.org/cl/93815 mentions this issue: go/types: make gotype continue after syntax errors

@golang golang locked and limited conversation to collaborators Feb 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
2 participants
@griesemer @gopherbot