-
Notifications
You must be signed in to change notification settings - Fork 554
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
Plumb location info through the parser #757
Comments
Thank you @ankrgyl -- I really appreciate you pushing this project along.
I agree this sound like a good plan
I am not quite sure what this would look like -- could you share a draft PR or rust pseudo code? cc @AugustoFKL |
Absolutely, here is a quick patch which shows what that would look like for
|
Got it -- this approach makes sense to me |
@alamb I've been working on this as part of a side project I'm building and wanted to put up a PR for your feedback: #790. There are a few other things in the PR (e.g. flipping stuff to |
@alamb @ankrgyl sorry for the delay, the last month, I barely was able to work, not my best phase. Either way, there are some part of the code that is really complex for me, and I can't spend that much time here, so I end up only getting the general idea, sorry. LMK once there are more advances (I already approved the last PR), so I can take a look as well |
This is a follow up to our discussion in #710 (comment) (and also referenced in #301, #179, and #524.
Now that location info is plumbed through the tokenizer, we can leverage these locations to:
From my understanding, the first task should be easier, since we wouldn't need to update the parse tree data structure (perhaps outside of a few edge cases). The main change should be updating the parser to use
TokenWithLocation
and then improving theParserError
messages to reference these locations. I would suggest changing the type ofTokenizerError
andParserError
to be richer than a string, and pass along the location information directly, so that consumers of the error can access it directly.The second task will be more difficult, however, since we'll need to either change all of the tree nodes to be structs instead of enums (to host the location information), or change each enum branch to be a struct with location information. I think the second approach will likely be easier to change incrementally, and for users to refactor against, and we can add a trait that homogenizes how users of the tree access the location info.
@alamb let me know your thoughts on the above.
The text was updated successfully, but these errors were encountered: