GitLab

This should work,

    {-# DEPRECATED someFunction [] #-}

Test Plan: parser/should_compile/T3303

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: mpickering

Differential Revision: https://phabricator.haskell.org/D1433

GHC Trac Issues: #11044

At the moment BooleanFormula is defined as

  data BooleanFormula a = Var a | And [BooleanFormula a]
                        | Or [BooleanFormula a]
       deriving (Eq, Data, Typeable, Functor, Foldable, Traversable)

An API Annotation can only be attached to an item of the form Located a.

Replace this with a properly Located version, and attach the appropriate
API Annotations to it

Updates haddock submodule.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1384

GHC Trac Issues: #11017

A utility to check API Annotations was provided in
https://git.haskell.org/ghc.git/commitdiff/43751b2436f370d956d8021b3cdd3
eb77801470b

This commit had poor documentation.

This patch improves the output generated by the utility as well as
supplying better documentation

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: austin, bgamari

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1397

GHC Trac Issues: #10917

This is a follow on to the patch for Trac #10928.
It's a local renaming of variables only; no change in behaviour.

This patch implements an extension to pattern synonyms which allows user
to specify pattern synonyms using record syntax. Doing so generates
appropriate selectors and update functions.

=== Interaction with Duplicate Record Fields ===

The implementation given here isn't quite as general as it could be with
respect to the recently-introduced `DuplicateRecordFields` extension.

Consider the following module:

    {-# LANGUAGE DuplicateRecordFields #-}
    {-# LANGUAGE PatternSynonyms #-}

    module Main where

    pattern S{a, b} = (a, b)
    pattern T{a}    = Just a

    main = do
      print S{ a = "fst", b = "snd" }
      print T{ a = "a" }

In principle, this ought to work, because there is no ambiguity. But at
the moment it leads to a "multiple declarations of a" error. The problem
is that pattern synonym record selectors don't do the same name mangling
as normal datatypes when DuplicateRecordFields is enabled. They could,
but this would require some work to track the field label and selector
name separately.

In particular, we currently represent datatype selectors in the third
component of AvailTC, but pattern synonym selectors are just represented
as Avails (because they don't have a corresponding type constructor).
Moreover, the GlobalRdrElt for a selector currently requires it to have
a parent tycon.

(example due to Adam Gundry)

=== Updating Explicitly Bidirectional Pattern Synonyms ===

Consider the following

```
pattern Silly{a} <- [a] where
  Silly a = [a, a]

f1 = a [5] -- 5

f2 = [5] {a = 6} -- currently [6,6]
```

=== Fixing Polymorphic Updates ===

They were fixed by adding these two lines in `dsExpr`. This might break
record updates but will be easy to fix.

```
+ ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)

- , pat_wrap = idHsWrapper }
+, pat_wrap = req_wrap }
```

=== Mixed selectors error ===

Note [Mixed Record Field Updates]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Consider the following pattern synonym.

    data MyRec = MyRec { foo :: Int, qux :: String }

    pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}

This allows updates such as the following

    updater :: MyRec -> MyRec
    updater a = a {f1 = 1 }

It would also make sense to allow the following update (which we
reject).

    updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"

This leads to confusing behaviour when the selectors in fact refer the
same field.

    updater a = a {f1 = 1, foo = 2} ==? ???

For this reason, we reject a mixture of pattern synonym and normal
record selectors in the same update block. Although of course we still
allow the following.

    updater a = (a {f1 = 1}) {foo = 2}

    > updater (MyRec 0 "str")
    MyRec 2 "str"

This implements DuplicateRecordFields, the first part of the
OverloadedRecordFields extension, as described at
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields

This includes fairly wide-ranging changes in order to allow multiple
records within the same module to use the same field names.  Note that
it does *not* allow record selector functions to be used if they are
ambiguous, and it does not have any form of type-based disambiguation
for selectors (but it does for updates). Subsequent parts will make
overloading selectors possible using orthogonal extensions, as
described on the wiki pages.  This part touches quite a lot of the
codebase, and requires changes to several GHC API datatypes in order
to distinguish between field labels (which may be overloaded) and
selector function names (which are always unique).

The Haddock submodule has been adapted to compile with the GHC API
changes, but it will need further work to properly support modules
that use the DuplicateRecordFields extension.

Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
will be extended once the other parts are implemented.

Reviewers: goldfire, bgamari, simonpj, austin

Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
goldfire

Differential Revision: https://phabricator.haskell.org/D761

Among doing other things, Phab:D201 (bc2289e1)
tried to improve the error messages thrown by the parser. For example a missing
else clause now prints "parse error in if statement: else clause empty" instead
of "parse error (possibly incorrect indentation or mismatched brackets)".

Some error messages got much worse however (see tests), and the result seems to
be a net negative. Although not entirely satisfactory, this commits therefore
reverts those parser changes.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D1309

GHC Trac Issues: #10498

For example

```
pattern head `Cons` tail = head : tail
```

Reviewed By: goldfire, austin

Differential Revision: https://phabricator.haskell.org/D1295

GHC Trac Issues: #10747

For details see #6018, Phab:D202 and the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies

This patch also wires-in Maybe data type and updates haddock submodule.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar,
             carter

Differential Revision: https://phabricator.haskell.org/D202

GHC Trac Issues: #6018

Updates haddock submodule.

Reviewers: tibbe, goldfire, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: goldfire, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1069

Old syntax was deprecated 6 years ago in this commit
432b9c93 by simonpj:"New syntax for
GADT-style record declarations, and associated refactoring" discussed
in Trac #3306.

This patch removes 2 reduce/reduce conflicts in parser. Conflicting
productions were:

```
    gadt_constr -> con_list '::' sigtype
    gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype
```

Recursive inlining of `con_list` and `oqtycon` helped reveal the
conflict:

```
    gadt_constr -> '(' CONSYM ')' '::' sigtype
    gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype
```

between two types of GADT constructors (second form stands for
deprecated syntax).

Test Plan: `make fasttest`, one breakage TEST="records-fail" (parse
error instead of typecheck error due to removal of deprecated syntax).
Updated test.

Reviewers: simonmar, bgamari, austin, simonpj

Reviewed By: simonpj

Subscribers: thomie, mpickering, trofi

Differential Revision: https://phabricator.haskell.org/D1118

GHC Trac Issues: #3306

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

Summary:
Phab:D907 introduced SourceText for a number of data types, by replacing
FastString with (SourceText,FastString). Since this has an Outputable
instance, no warnings are generated when ppr is called on it, but
unexpected output is generated. See Phab:D1096 for an example of this.

Replace the (SourceText,FastString) tuples with a new data type,
```lang=hs
data StringLiteral = StringLiteral SourceText FastString
```

Update haddock submodule accordingly

Test Plan: ./validate

Reviewers: hvr, austin, rwbarton, trofi, bgamari

Reviewed By: trofi, bgamari

Subscribers: thomie, trofi, rwbarton, mpickering

Differential Revision: https://phabricator.haskell.org/D1101

GHC Trac Issues: #10692

This implements the `StrictData` language extension, which lets the
programmer default to strict data fields in datatype declarations on a
per-module basis.

Specification and motivation can be found at
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

This includes a tricky parser change due to conflicts regarding `~` in
the type level syntax: all ~'s are parsed as strictness annotations (see
`strict_mark` in Parser.y) and then turned into equality constraints at
the appropriate places using `RdrHsSyn.splitTilde`.

Updates haddock submodule.

Test Plan: Validate through Harbormaster.

Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari

Reviewed By: simonpj, tibbe, bgamari

Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering

Differential Revision: https://phabricator.haskell.org/D1033

GHC Trac Issues: #8347

Accept next docstrings (`-- | Docstring`) on GADT constructors.

I have confirmed that this adds no shift/reduce conflicts.

Test Plan: haddockA034

Reviewers: austin, simonpj, simonmar

Reviewed By: simonmar

Subscribers: Fuuzetsu, simonmar, thomie, mpickering, edsko

Differential Revision: https://phabricator.haskell.org/D1086

And remove unused imports and language pragmas.

I checked that the minimum Happy and Alex version requirements, as
listed in aclocal.m4, don't have to change. Before building ghc, I ran:
  - cabal install happy==1.19.4 --with-ghc=ghc-7.8.4
  - cabal install alex==3.1.0 --with-ghc=ghc-7.6.3

Differential Revision: https://phabricator.haskell.org/D1032

`parseFullStmt` and `parseStatement` exposed the same parser entry
point.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: gibiansky, alanz, thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1014

Each production produced a singleton list.

Similar treatment is applied to the decl_cls parser.

This changes the type of the parseDeclaration entry point to

`parseDeclaration :: P (LHsDecl RdrName)`

and

`parseTypeSignature :: P (LHsDecl RdrName)`

which is in line with the other parser entry points.

This patch also updates the conflict commentary.  There were 4 reduce/reduce
conflicts introduced by `ffc21506` which
refactored tuple constraints.

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1007

Reviewers: austin, thomie, alanz

Reviewed By: thomie, alanz

Subscribers: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1005

GHC Trac Issues: #10556

Summary:
Parsing

    {-# LANGUAGE TupleSections #-}

    baz = (1, "hello", 6.5,,) 'a' (Just ())

Results in the following AST fragment

    (L tests/examples/Tuple.hs:3:7-25
       (ExplicitTuple
          [ L tests/examples/Tuple.hs:3:8
              (Present
                 (L tests/examples/Tuple.hs:3:8
                    (HsOverLit
                       (OverLit
                          (HsIntegral [ '1' ] 1)
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:11-17
              (Present
                 (L tests/examples/Tuple.hs:3:11-17
                    (HsLit
                       (HsString
                          [ '"'
                          , 'h'
                          , 'e'
                          , 'l'
                          , 'l'
                          , 'o'
                          , '"'
                          ]
                          {abstract:FastString}))))
          , L tests/examples/Tuple.hs:3:20-22
              (Present
                 (L tests/examples/Tuple.hs:3:20-22
                    (HsOverLit
                       (OverLit
                          (HsFractional
                             (FL
                                [ '6' , '.' , '5' ]
                                (:% 13 2)))
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          ]

The final `Missing PlaceHolder` has a duplicated `SrcSpan`

Test Plan: ./validate

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, bgamari, mpickering

Differential Revision: https://phabricator.haskell.org/D995

GHC Trac Issues: #10537

Because sometimes types make more sense than docs.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D983

Summary:
Refactor wild card error reporting

* Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor
  `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two
  constructors: `AnonWildCard` and `NamedWildCard`.

* All partial type checks are removed from `RdrHsSyn.hs` and are now done
  during renaming in order to report better error messages. When wild cards
  are allowed in a type, the new function `rnLHsTypeWithWildCards` (or
  `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild
  cards into scope before renaming them. When this is not done, renaming will
  trigger "Unexpected wild card..." errors.

  Unfortunately, this has to be done separately for anonymous wild cards
  because they are given a fresh name during renaming, so they will not cause
  an out-of-scope error. They are handled in `tc_hs_type`, as a special case
  of a lookup that fails.

  The previous opt-out approach is replaced with an opt-in approach. No more
  panics because of forgotten checks!

* `[t| _ |]` isn't caught by the above two checks, so it is currently handled
  by a special case. The error message (generated in the `DsM` monad) doesn't
  provide as much context information as the other cases.

* Instead of three (!) functions that walk `HsType`, there is now only one
  pure function called `collectWildCards`.

* Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking
  at the `HsDocContext`. This will reduce the number of places to catch
  unwanted wild cards form three to one, and make the error messages more
  uniform, albeit less informative, as the error context for renaming is not
  as informative as the one for type checking. A new constructor of
  `HsDocContext` will be required for pattern synonyms signatures.

  Small problem: currently type-class type signatures can't be distinguished
  from type signatures using the `HsDocContext`.

This requires an update to the Haddock submodule.

Test Plan: validate

Reviewers: goldfire, simonpj, austin

Reviewed By: simonpj

Subscribers: bgamari, thomie, goldfire

Differential Revision: https://phabricator.haskell.org/D613

GHC Trac Issues: #10098

Summary:
The strings used in a WARNING pragma are captured via

    strings :: { Located ([AddAnn],[Located FastString]) }
        : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) }
    ..

The STRING token has a method getSTRINGs that returns the original
source text for a string.

A warning of the form

    {-# WARNING Logic
              , mkSolver
              , mkSimpleSolver
              , mkSolverForLogic
              , solverSetParams
              , solverPush
              , solverPop
              , solverReset
              , solverGetNumScopes
              , solverAssertCnstr
              , solverAssertAndTrack
              , solverCheck
              , solverCheckAndGetModel
              , solverGetReasonUnknown
              "New Z3 API support is still incomplete and fragile: \
              \you may experience segmentation faults!"
      #-}

returns the concatenated warning string rather than the original source.

This patch now deals with all remaining instances of getSTRING to bring
in a SourceText for each.

This updates the haddock submodule as well, for the AST change.

Test Plan: ./validate

Reviewers: hvr, austin, goldfire

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D907

GHC Trac Issues: #10313

Summary:
A collection of minor updates for the API Annotations.

1. The annotations for the implicity parameter is disconnected in the
   following

    type MPI = ?mpi_secret :: MPISecret

2. In the following, the annotation for one of the commas is disconeected.

    mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form)

3. In the following, the annotation for the parens becomes disconnected

    data MaybeDefault v where
        SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v
        SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v
                                                -> a -> MaybeDefault [a])

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D901

GHC Trac Issues: #10399

Summary:
In the following code fragment

    let ls :: Int = undefined

the `::` is attached to the ls function as a whole, rather than to the
pattern on the LHS.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D883

GHC Trac Issues: #10396

Summary:
In the following code, the extra set of parens around the context end up
with detached annotations.

    {-# LANGUAGE PartialTypeSignatures #-}
    module ParensAroundContext where

    f :: ((Eq a, _)) => a -> a -> Bool
    f x y = x == y

Trac ticket #10354

It turns out it was the TupleTy that was the culprit.

This may also solve #10315

Test Plan: ./validate

Reviewers: hvr, austin, goldfire

Reviewed By: austin

Subscribers: goldfire, bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D868

GHC Trac Issues: #10354, #10315

Summary:
When parsing

    {-# LANGUAGE ScopedTypeVariables #-}

    extremumNewton :: forall tag. forall tag1.
                       tag -> tag1 -> Int
    extremumNewton = undefined

the parser creates nested HsForAllTy's for the two forall statements.

These get flattened into a single one in `HsTypes.mk_forall_ty`

This patch removes the flattening, so that API Annotations are not lost in the
process.

Test Plan: ./validate

Reviewers: goldfire, austin, simonpj

Reviewed By: simonpj

Subscribers: bgamari, mpickering, thomie, goldfire

Differential Revision: https://phabricator.haskell.org/D836

GHC Trac Issues: #10278, #10315, #10354, #10363

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

- Haddock needs to absorb the change too; so there is a submodule update

This reverts multiple commits from Simon:

  - 04a484ea Test Trac #10359
  - a9ccd37a Test Trac #10403
  - c0aae6f6 Test Trac #10248
  - eb6ca851 Make the "matchable-given" check happen first
  - ca173aa3 Add a case to checkValidTyCon
  - 51cbad15 Update haddock submodule
  - 6e1174da Separate transCloVarSet from fixVarSet
  - a8493e03 Fix imports in HscMain (stage2)
  - a154944b Two wibbles to fix the build
  - 5910a1bc Change in capitalisation of error msg
  - 130e93aa Refactor tuple constraints
  - 8da785d5 Delete commented-out line

These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

Summary:
The production for decl_no_th starts

    decl_no_th :: { Located (OrdList (LHsDecl RdrName)) }
            : sigdecl               { $1 }

            | '!' aexp rhs  {% do { let { e = sLL $1 $> (SectionR (sL1 $1 (HsVar bang_RDR)) $2) };
                                    pat <- checkPattern empty e;
    ...

The e value should be just the pattern, excluding the rhs, but the span
created includes the rhs.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D873

GHC Trac Issues: #10358

Summary:
The Parser.y production for pquals is

    pquals :: { Located [[LStmt RdrName (LHsExpr RdrName)]] }
        : squals '|' pquals
                         {% addAnnotation (gl $ last $ unLoc $1) AnnVbar (gl $2) >>
                            return (sLL $1 $> (reverse (unLoc $1) : unLoc $3)) }
        | squals         { L (getLoc $1) [reverse (unLoc $1)] }

The squals are returned in reverse order, so the AnnVbar should be
attached to the head of the list, not the last.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D869

GHC Trac Issues: #10357

Summary:
The MINIMAL pragma is captured in the parser using a BooleanFormula.

The constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the
boolean formula as it is constructed.

This discards the original information, making round tripping
impossible.

Note: there is another version which provides a more API Annotations
friendly version of the MINIMAL pragma, but this requires changes to
haddock, which will cause problems for 7.10.2.

See https://github.com/alanz/ghc/tree/wip/10287

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, Fuuzetsu, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D837

GHC Trac Issues: #10287

Summary:
When mkGadtDecl is presented wih a HsFunTy it discards the SrcSpan, thus
disconnecting any annotations on the HsFunTy.

```
mkGadtDecl names (L ls (HsForAllTy imp Nothing qvars cxt tau))
  = return $ mk_gadt_con names
  where
    (details, res_ty)           -- See Note [Sorting out the result type]
      = case tau of
          L _ (HsFunTy (L l (HsRecTy flds)) res_ty)
                                            -> (RecCon (L l flds), res_ty)
          _other                                    -> (PrefixCon [], tau)
...
```

This can be triggered by the following

```
{-# LANGUAGE GADTs #-}
module GADTRecords2 (H1(..)) where

-- | h1
data H1 a b where
  C3 :: (Num a) => { field :: a -- ^ hello docs
                   } -> H1 Int Int
```

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D848

GHC Trac Issues: #10309

Summary:
The code for mkAtDefault is as follows.

    mkATDefault (L loc (TyFamInstDecl { tfid_eqn = L _ e }))
          | TyFamEqn { tfe_tycon = tc, tfe_pats = pats, tfe_rhs = rhs } <- e
          = do { tvs <- checkTyVars (ptext (sLit "default")) equalsDots tc (hswb_cts pats)
               ; return (L loc (TyFamEqn { tfe_tycon = tc
                                         , tfe_pats = tvs
                                         , tfe_rhs = rhs })) }

An associated type in a class of the form

    type FoldableConstraint t x = ()

has an AnnEqual attached to the location in tfid_eqn. Since the location
is discarded, this annotation is then disconnected from the AST.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D842

GHC Trac Issues: #10307

Summary:
The parser production for squals has

    : squals ',' transformqual
             {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >>
                ams (sLL $1 $> ()) (fst $ unLoc $3) >>
                return (sLL $1 $> [sLL $1 $> ((snd $ unLoc $3) (reverse (unLoc $1)))]) }

This attaches the comma to the wrong part of the squals, as it is
generated in reverse order.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D846

GHC Trac Issues: #10312

Summary:
For the following code

  {-# LANGUAGE TupleSections #-}

  foo = do
    liftIO $ atomicModifyIORef ciTokens ((,()) . f)

the annotation is missing for the comma.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie

Differential Revision: https://phabricator.haskell.org/D834

GHC Trac Issues: #10280