Warning about capture characters#119
Conversation
DmitrySoshnikov
left a comment
There was a problem hiding this comment.
Thanks for the PR! Some notes inline
| .replace(/"(\\.|[^"\\])*"/g, '') | ||
| .replace(/`(\\.|[^`\\])*`/g, '') | ||
| // module include | ||
| .replace(/%{[\n\s\S]*?%}/g, ''); |
There was a problem hiding this comment.
Not sure if we need to use all these replace calls, probably just can just do a simple regexp test for:
if (/@\d+/.test(grammar) {
// Warning
}There was a problem hiding this comment.
without those replaces, the warning would be displayed even when finding @ inside strings, comments, lex rules, etc, which isn't good, for example, css uses that character a lot, for media queries and stuff, so it could be part of a lexer rule if someone tries to make a parser for that language. im sure there are more languages that use that character.
also just using \d in the regex would not show the error when using named tokens (which i do a lot)
let me know if you want me to make that change anyway tho, after all its just a warning, not an error
There was a problem hiding this comment.
Yeah, sounds good - the only thing we need to make sure those replaces don't slow down much the handling.
There was a problem hiding this comment.
i tested it and it doesn't take even 0.015ms in a file of 10 millon characters, at least on my pc. also thats executed only once, and when generating the parser, it won't affect the parser itself at all, so i don't think it's a problem
|
OK, looks great, thanks! |
If you capture locations in the bnf grammar file used to generate a parser, without using the --loc option, the parser will be successfully generated, but it will throw an error at runtime because the location variables are not defined.
This shows a warning when generating the parser if the grammar file contains location capture characters and the --loc option is not provided.