Parse the (!) type operator and allow type operators in existential context
authorVladislav Zavialov <vlad.z.4096@gmail.com>
Thu, 4 Oct 2018 13:17:55 +0000 (09:17 -0400)
committerRyan Scott <ryan.gl.scott@gmail.com>
Thu, 4 Oct 2018 13:17:55 +0000 (09:17 -0400)
commitbd7898537768f936d05c0c83eef1cd9b00933347
treedb16292d6c32f6ef04ff829178cacc6709d00a6d
parentfc2ff6dd7496a33bf68165b28f37f40b7d647418
Parse the (!) type operator and allow type operators in existential context

Summary:
Improve the way `(!)`, `(~)`, and other type operators are handled in the parser,
fixing two issues at once:

1. `(!)` can now be used as a type operator
   that respects fixity and precedence (#15457)
2. Existential context of a data constructor
   no longer needs parentheses (#15675)

In addition to that, with this patch it is now trivial to adjust precedence of
the `{-# UNPACK #-}` pragma, as suggested in
https://ghc.haskell.org/trac/ghc/ticket/14761#comment:7

There was a small change to API Annotations. Before this patch, `(~)` was a
strange special case that produced an annotation unlike any other type
operator. After this patch, when `(~)` or `(!)` are used to specify strictness they
produce AnnTilde and AnnBang annotations respectively, and when they are used
as type operators, they produce no annotations.

Test Plan: Validate

Reviewers: simonpj, bgamari, alanz, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, mpickering, carter

GHC Trac Issues: #15457, #15675

Differential Revision: https://phabricator.haskell.org/D5180
26 files changed:
compiler/parser/Lexer.x
compiler/parser/Parser.y
compiler/parser/RdrHsSyn.hs
docs/users_guide/8.8.1-notes.rst
testsuite/tests/ghc-api/annotations/T11321.stdout
testsuite/tests/ghci/prog006/prog006.stderr
testsuite/tests/parser/should_compile/T15457.hs [new file with mode: 0644]
testsuite/tests/parser/should_compile/T15675.hs [new file with mode: 0644]
testsuite/tests/parser/should_compile/all.T
testsuite/tests/parser/should_fail/T3811b.stderr
testsuite/tests/parser/should_fail/T3811c.stderr
testsuite/tests/parser/should_fail/T3811f.stderr
testsuite/tests/parser/should_fail/all.T
testsuite/tests/parser/should_fail/strictnessDataCon_A.hs [new file with mode: 0644]
testsuite/tests/parser/should_fail/strictnessDataCon_A.stderr [new file with mode: 0644]
testsuite/tests/parser/should_fail/strictnessDataCon_B.hs [new file with mode: 0644]
testsuite/tests/parser/should_fail/strictnessDataCon_B.stderr [new file with mode: 0644]
testsuite/tests/parser/should_fail/typeopsDataCon_A.hs [new file with mode: 0644]
testsuite/tests/parser/should_fail/typeopsDataCon_A.stderr [new file with mode: 0644]
testsuite/tests/parser/should_fail/typeopsDataCon_B.hs [new file with mode: 0644]
testsuite/tests/parser/should_fail/typeopsDataCon_B.stderr [new file with mode: 0644]
testsuite/tests/rename/should_fail/rnfail053.stderr
testsuite/tests/typecheck/should_fail/T14761a.stderr
testsuite/tests/typecheck/should_fail/T14761b.stderr
testsuite/tests/typecheck/should_fail/T7210.stderr
testsuite/tests/typecheck/should_fail/T9634.stderr