Fix a bug in 'alexInputPrevChar'
authorAlec Theriault <alec.theriault@gmail.com>
Wed, 25 Oct 2017 19:52:38 +0000 (15:52 -0400)
committerBen Gamari <ben@smart-cactus.org>
Wed, 25 Oct 2017 20:44:22 +0000 (16:44 -0400)
commit821adee12e89dbd0a52fde872b633e4e2e9051dc
treebeef26068d86bc80b5942e45e3534c039e5b4e74
parentf7f270eb6ba616feda79d370336db7e66f9ab79c
Fix a bug in 'alexInputPrevChar'

The lexer hacks around unicode by squishing any character into a 'Word8'
and then storing the actual character in its state. This happens at
'alexGetByte'.

That is all and well, but we ought to be careful that the characters we
retrieve via 'alexInputPrevChar' also fit this convention.

In fact, #13986 exposes nicely what can go wrong: the regex in the left
context of the type application rule uses the '$idchar' character set
which relies on the unicode hack. However, a left context corresponds
to a call to 'alexInputPrevChar', and we end up passing full blown
unicode characters to '$idchar', despite it not being equipped to deal
with these.

Test Plan: Added a regression test case

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13986

Differential Revision: https://phabricator.haskell.org/D4105
compiler/parser/Lexer.x
testsuite/tests/parser/should_compile/T13986.hs [new file with mode: 0644]
testsuite/tests/parser/should_compile/all.T