-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add error recovery mode? #56
Comments
moo.compile({
id: /\w+/,
ws: {match: /\s+/, lineBreaks: true},
// … rules rules rules …
ignore: /.+/, // skip to eol
}) If you meant the entire line gets ignored, not just the trailing lexically invalid part, that's a job for the parser, not the lexer, because there are almost always sequences of lexically valid tokens that are not syntactic. (For example, |
I tried that approach: compile({
...
lCurly: '{',
rCurly: '}',
invalid: /.+/
})
I'm willing to try and implement this in a PR if you guys think it's a good idea. |
You made me think of a much simpler way to implement it: let errorRe = /(?:(?!<re>).)+/my // <re> is `lexer.re`, i.e. all the valid stuff. When can't parse a valid a token, |
I still don't think that error recovery at the level of lexical analysis is what you want. Could you provide some examples from your language? |
Argh. I knew making keyword handling implicit would be a bad idea. Perhaps this is another reason to make keyword handling explicit (#53). |
Here are some suggestions:
|
In my language, lines with invalid stuff are considered comments. I know, insane, but I'd like to support that if possible. Currently,
{ error: true }
is extremely greedy and considers everything from the first error to be a single token.I propose an optional error tolerance mode that can be enabled with
{ error: true, recover: true }
:line
andcol
of recovery starting pointThe text was updated successfully, but these errors were encountered: