Re: [GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters

#13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4105 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"821adee12e89dbd0a52fde872b633e4e2e9051dc/ghc" 821adee1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="821adee12e89dbd0a52fde872b633e4e2e9051dc" 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 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13986#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler