GitLab

During parsing, GHC collects lexical information about AST nodes and
stores it in a map. It is needed to faithfully restore original source
code, e.g. compare these expressions:

	a =  b
	a  = b

The position of the equality sign is not recorded in the AST, so it must
be stored elsewhere.

This system is described in Note [Api annotations].

Before this patch, the mapping was represented by:

	Map (SrcSpan, AnnKeywordId) SrcSpan

After this patch, the mapping is represented by:

	Map (RealSrcSpan, AnnKeywordId) RealSrcSpan

The motivation behind this change is to avoid using the Ord SrcSpan
instance (required by Map here), as it interferes with #17632 (see the
discussion there).

SrcSpan is isomorphic to  Either String RealSrcSpan,  but we shouldn't
use those strings as Map keys. Those strings are intended as hints to
the user, e.g. "<interactive>" or "<compiler-generated code>", so they
are not a valid way to identify nodes in the source code.

For an API annotation to be useful, it must not occur before the span
it is enclosed in.

So, for check-api-annotation output, a line such as

((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]),

should be flagged as an error, as the AnnOpenP location of 3:21
precedes its enclosing span of 3:22-26.

This patch does this.

Closes #16217

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