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
go/types: incorrect scope positioning for variables defined by RangeStmt #15686
Comments
Too late for Go 1.7. |
@mdempsky I agree that this looks non-intrusive, but I believe @alandonovan has code that looks at scope ranges for various analyses. There may be subtle follow-up effects/errors that we don't foresee at the moment. I think it's better to leave for 1.8. |
@griesemer Fair enough. I found a reasonably robust and non-intrusive workaround anyway, so I'm fine with deferring this issue to 1.8. |
CL https://golang.org/cl/27290 mentions this issue. |
Go 1.8 included the fix for golang/go#15686, so no need to workaround it anymore. However, we also now have position information for imported objects, which interferes with scoping rules. go/types doesn't export Object.scopePos, so switch to using go/types.(*Scope).LookupParent instead.
In go/types/stmt.go:818,819, there's this code to handle declaring for a RangeStmt's Key and Value variables:
This is wrong though, because s refers to the RangeStmt itself, so s.End() is the closing brace. The consequence of this is if you try to use scope.LookupParent or types.Eval with a position inside the RangeStmt's block, it can't find the Key or Value variables.
I think the correct fix is to use s.X.End() instead.
Reviewing other check.declare calls, I think type switches are technically mishandled too. The spec says "the variable is declared at the beginning of the implicit block in each clause". I believe that should be the position of the "case" or "default" keywords, or at least at or immediately after the colon; not at the start of the first statement within the body.
These are preexisting issues, but fixing them should be very non-intrusive, so I'm hopeful it can still make 1.7.
/cc @griesemer @alandonovan
The text was updated successfully, but these errors were encountered: