4 reduce/reduce parser conflicts resolved
authorUlya Trofimovich <skvadrik@gmail.com>
Mon, 3 Aug 2015 12:56:16 +0000 (14:56 +0200)
committerBen Gamari <ben@smart-cactus.org>
Mon, 3 Aug 2015 12:56:52 +0000 (14:56 +0200)
commit697079f118197931e7a8c0768e99bf60be4150fd
tree6a5720d4d18fb4cb2206188cc21f9c53c3b2a7e9
parent30b32f4ca83147544c4dafeb96fed70b791e40cd
4 reduce/reduce parser conflicts resolved

As GHC documentation (section 7.4.4, Type operators) says:
> "There is now some potential ambiguity in import and export lists;
for example if you write import M( (+) ) do you mean the function (+)
or the type constructor (+)? The default is the former, but with
-XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC
allows you to specify the latter by preceding it with the keyword type"

Turns out this ambiguity causes 4 of 6 reduce/reduce conflicts in GHC
parser.  All 4 conflicts arise from a single production:

    qcname
        :  qvar
        |  oqtycon

Recursive inlining of 'qvar' and 'oqtycon' helps reveal the faulty
productions:

    qcname
        :
    ...
        | '(' QVARSYM ')'
        | '(' VARSYM ')'
        | '(' '*'    ')'
        | '(' '-'    ')'

These productions can either be parsed as variable or type constructor,
but variable constuctor is always preferred. My patch removes ambiguity
while preserving the existing behaviour:

  - all unambigous productions are left as-is
  - ambigous productions for variable constuctors are left
  - ambigous productions for type constructors are removed (there's no
    way they could be triggered)

Updated comment.

Test Plan: Tested with 'make fasttest'

Reviewers: austin, simonpj, trofi, bgamari, simonmar

Reviewed By: trofi, bgamari, simonmar

Subscribers: thomie, mpickering

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D1111
compiler/parser/Parser.y