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/parser: No way to produce correct offsets when doing partial parsing #2706
Labels
Milestone
Comments
Labels changed: added priority-go1, removed priority-triage. Owner changed to @griesemer. Status changed to Accepted. |
1) The "//line :1" comment makes sure error messages returned by the parser have correct line:col: information. 2) You are correct that the offset is broken, for ParseExpr(...) it's also not defined. It's trivial to use that example and provide a custom implementation that returns the file set and makes the offset available (even though it may need to be corrected). For what it's worth, your code would benefit from a helper function: func (f *AutoCompleteFile) offset(pos token.Position) int { f.fset.Position(pos).Offset - f.correction // f.correction == fixlen in your code } and then you can just write: f.offset(f.TokPos) instead of the lengthy expression you have now. And then it doesn't matter if you have to correct the offset or not as it is only needed once. That is, having such a helper function would also be beneficial with the old parser API. There are several reasons for eliminating the special partial parser entry points: 1) As they were implemented, they didn't take any precautions with setting up the proper scopes. It could be done, but then the question arises if the scopes should be exposed or not, etc. 2) The question arises, why only have those special partial parsers? Why not have one for signatures, types, etc. It's a slippery slope that ends only when there is an entry point for each production. We don't want to go there. 3) Creating a custom version of ParseExpr is trivial. By using exactly one parser entry point (ParseFile), we can make sure that everything is always correctly set up. It's easy to correct position information if necessary. If you can provide me with a use case that cannot be handled this way, please let me know. Otherwise I will consider this as closed once we freeze the API for Go 1. Status changed to WaitingForReply. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: