-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Error reporting #946
Error reporting #946
Conversation
db14dc2
to
128baf4
Compare
This function returns any problems, such as would show up as ERROR, MISSING or UNEXPECTED in the printed SEXP for the immediate children of a TSNode. The intended use-case is to provide diagnostic feedback in a language server.
128baf4
to
6704c14
Compare
ba403ed
to
a79341b
Compare
👋 I think this is not quite the right way to report errors. To generate a useful error message, I think we need to actually indicate the location where the error was detected. Right now, this information is not stored: when recovering from an error, we pick out an arbitrary sequence of nodes surrounding the error-detection-point, and wrap those nodes in an What we need to do is tweak the error recovery procedure (during parsing) so that it records where the error initially occurred, and store this information on the Then, we would be able to compute what parse state we were in at the time the error was detected, and look up the set of tokens that would be valid in that parse state. |
a79341b
to
0c45af7
Compare
0c45af7
to
bcd3d57
Compare
@maxbrunsfeld After having experimented with this some, I agree with you. I was thinking the output would perhaps be in a tree form or something, but it's basically what you'd get from walking the tree (with a cursor) and collecting errors, which is something I already do in my language servers. I'd prefer to have something more like what you are describing where the actual parser state is described when an error occurs. I'll try to take a look at the parser to see if I can figure out how to do what you described. Any further suggestions you might have along those lines are appreciated. |
This PR adds error diagnostics based on @alanz's implementation mentioned here and is intended to fix #255.
I haven't had a chance to actually experiment with the results yet but I just wanted to get this PR in place so that there is some visibility for this. It would really be nice to have some sort of functionality like this ready for 1.0 (see #930).
Ultimately, I think it may be more useful to have JSON output of these error diagnostics (at least as an option) rather than plain strings. I will probably try to add that to this PR before marking it as ready.
/cc @maxbrunsfeld @alanz