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

cmd/compile: -G=3 mode correctly reports all "declared but not used" errors, but old compiler does not #46004

Closed
danscales opened this issue May 6, 2021 · 6 comments
Closed

cmd/compile: -G=3 mode correctly reports all "declared but not used" errors, but old compiler does not #46004

danscales opened this issue May 6, 2021 · 6 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Go1.18

Comments

@danscales
Copy link
Contributor

For current master, if you enable -G=3 in the compiler by adding 'Flag.G = 3' at the end of ParseFlags in cmd/compile/internal/base/flag.go, then this command fails

go test -count=1 -race -run=TestOutput runtime/race

This is one of the commands that is run under the "##### Testing race detector" section of the all.bash tests.

The reason is that types2 reports an error "main.go:4:2: x declared but not used" (which does seem most correct) for:

package main
func main() {
        done := make(chan bool)
        x := 0
        go func() {
                x = 42
                done <- true
        }()
        x = 43
        <-done
}

whereas the current compiler/typechecker (-G=0) does not report any error. (Note that 'go vet' does return the error "vet: ./test.go:4:2: x declared but not used".)

So, we have to decide if we can make this change in the behavior in the typechecker or not. If not, then we need to "fix" types2 to not report this error.

If it's OK to have this change in behavior, then we can make the test work for both by changing the test program (occurs several times in runtime/race/output_test.go) to end with:

        <-done
        _ = x
}
@danscales danscales added this to the Go1.18 milestone May 6, 2021
@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 6, 2021
@griesemer
Copy link
Contributor

See also: #8560 (comment)

@danscales
Copy link
Contributor Author

This test is clearly working now, since we have enabled -G=3 by default. I don't see any code in TestOutput() that disables the test. On the other hand, there is still the difference in behavior between -G=3 and -G=0 mode for the program described above. Haven't tried to narrow this down further as to when/how this was fixed.

@griesemer griesemer changed the title cmd/compile: if -G=3 fully enabled in compiler, 'go test -count=1 -race -run=TestOutput runtime/race" fails cmd/compile: -G=3 mode correctly reports some "declared but not used" errors, but old compiler does not Oct 28, 2021
@griesemer
Copy link
Contributor

Summary:

package main
func main() {
        p := true
        func() {
                p = true
        }()
}

The old compiler (-G=0) does not report an error.
The new compiler (-G=3, default) reports: p declared but not used. So does go vet.

Since go vet is reporting this error there are probably few programs in the wild that rely on gc's old behavior. It should be reasonably safe to accept the new behavior. I am leaning towards the correct behavior. Still, NeedsDecision.

@rsc any thoughts?

@griesemer griesemer changed the title cmd/compile: -G=3 mode correctly reports some "declared but not used" errors, but old compiler does not cmd/compile: -G=3 mode correctly reports all "declared but not used" errors, but old compiler does not Oct 28, 2021
@cuonglm
Copy link
Member

cuonglm commented Oct 28, 2021

FYI, @mdempsky has a CL to make old typechecker also reports the error: https://go-review.googlesource.com/c/go/+/238317

@griesemer griesemer mentioned this issue Oct 28, 2021
Closed
@griesemer
Copy link
Contributor

Filed proposal #49214 to decide whether we can make this change.

@griesemer
Copy link
Contributor

Per #49214 we will accept the correct behavior and document it in the release notes. If this ends up breaking a lot of code, we can re-open.

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@danscales @cuonglm @griesemer @gopherbot