diff options
| author | Kaz Kylheku <kaz@kylheku.com> | 2021-05-31 20:21:47 -0700 |
|---|---|---|
| committer | Kaz Kylheku <kaz@kylheku.com> | 2021-05-31 20:21:47 -0700 |
| commit | 63dabb4ea67cde0971474c4278d605394af0d1b3 (patch) | |
| tree | 17730286fb5e59475a4ffc0c433e90019bab581a /regex.c | |
| parent | 59beb217e76f3518ad35ea1d51b36452cf5723fd (diff) | |
| download | txr-63dabb4ea67cde0971474c4278d605394af0d1b3.tar.gz txr-63dabb4ea67cde0971474c4278d605394af0d1b3.tar.bz2 txr-63dabb4ea67cde0971474c4278d605394af0d1b3.zip | |
json: fix unquote parsing issue in quasiquotes.
The big comment I added above end_of_json_unquote summarizes
the issue. This issue has been uncovered by some test cases in
a JSON test suite, not yet committed.
* parser.l <JMARKER>: New start condition. Used as a reliable
marker in the start condition stack, based on which
end_of_json_quasiquote can intelligently fix-up the stack.
(JSON): In the transitions to the quasiquote scanning NESTED
state, push the JMARKER start condition before NESTED.
(JMARKER): The lexer should never read input in the JMARKER
state. If we don't put in a rule to catch this, if that ever
happens, the lexer will just copy the source code to standard
output. I ran into this during debugging.
(end_of_json_unquote): Rewrite the start condition stack
intelligently based on what the Lisp lookahead token has done
to it, so parsing can smoothly continue.
* lex.yy.c.shipped: Regenerated.
Diffstat (limited to 'regex.c')
0 files changed, 0 insertions, 0 deletions