[GHC] #13163: Make type import/export API Annotation friendly
GHC
ghc-devs at haskell.org
Thu Jan 26 13:20:24 UTC 2017
#13163: Make type import/export API Annotation friendly
-------------------------------------+-------------------------------------
Reporter: alanz | Owner: alanz
Type: bug | Status: patch
Priority: normal | Milestone: 8.2.1
Component: Compiler | Version: 8.0.1
(Parser) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Incorrect API | Unknown/Multiple
annotation | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D3016
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Alan Zimmerman <alan.zimm@…>):
In [changeset:"0d1cb1574dd58d1026cac812e2098135823fa419/ghc"
0d1cb157/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="0d1cb1574dd58d1026cac812e2098135823fa419"
Make type import/export API Annotation friendly
Summary:
At the moment an export of the form
type C(..)
is parsed by the rule
```
| 'type' oqtycon {% amms (mkTypeImpExp (sLL $1 $> (unLoc
$2)))
[mj AnnType $1,mj AnnVal $2] }
```
This means that the origiinal oqtycon loses its location which is then
retained
in the AnnVal annotation.
The problem is if the oqtycon has its own annotations, these get lost.
e.g. in
type (?)(..)
the parens annotations for (?) get lost.
This patch adds a wrapper around the name in the IE type to
(a) provide a distinct location for the adornment annotation and
(b) identify the specific adornment, for use in the pretty printer rather
than
occName magic.
Updates haddock submodule
Test Plan: ./validate
Reviewers: mpickering, dfeuer, bgamari, austin
Reviewed By: dfeuer
Subscribers: dfeuer, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D3016
GHC Trac Issues: #13163
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13163#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list