d5ce268074
A precedence annotation wrapping a sequence of characters now only affects how tightly those characters bind to *each other*, not how tightly they bind to the preceding character. This bug surfaced because a generated lexer was failing to recognize a '\n' character as a token, instead treating it as ubiquitous whitespace. It made this error because, even though anonymous ubiquitous tokens have the lowest precedence, the character immediately *after* the '\n' was part of a normal token, which had *normal* precedence (0). Advancing into that following token was incorrectly prioritized above accepting the line-break token. |
||
|---|---|---|
| .. | ||
| does_match_any_line_spec.cc | ||
| item_set_closure_spec.cc | ||
| lex_conflict_manager_spec.cc | ||
| lex_item_spec.cc | ||
| parse_conflict_manager_spec.cc | ||
| parse_item_spec.cc | ||
| rule_can_be_blank_spec.cc | ||