GitLab

This exposes `template-haskell` functions for querying the language
extensions which are enabled when compiling a module,

- an `isExtEnabled` function to check whether an extension is enabled
- an `extsEnabled` function to obtain a full list of enabled extensions

To avoid code duplication this adds a `GHC.LanguageExtensions` module to
`ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
consequence of this is that the ungainly `DynFlags` lost around 500
lines. Moreover, flags corresponding to language extensions are now
clearly distinguished from other flags due to the `LangExt.*` prefix.

Updates haddock submodule.

This fixes #10820.

Test Plan: validate

Reviewers: austin, spinda, hvr, goldfire, alanz

Reviewed By: goldfire

Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie

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

GHC Trac Issues: #10820

This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).

There are several noteworthy changes with this patch:
 * We now have casts in types. These change the kind
   of a type. See new constructor `CastTy`.

 * All types and all constructors can be promoted.
   This includes GADT constructors. GADT pattern matches
   take place in type family equations. In Core,
   types can now be applied to coercions via the
   `CoercionTy` constructor.

 * Coercions can now be heterogeneous, relating types
   of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
   proves both that `t1` and `t2` are the same and also that
   `k1` and `k2` are the same.

 * The `Coercion` type has been significantly enhanced.
   The documentation in `docs/core-spec/core-spec.pdf` reflects
   the new reality.

 * The type of `*` is now `*`. No more `BOX`.

 * Users can write explicit kind variables in their code,
   anywhere they can write type variables. For backward compatibility,
   automatic inference of kind-variable binding is still permitted.

 * The new extension `TypeInType` turns on the new user-facing
   features.

 * Type families and synonyms are now promoted to kinds. This causes
   trouble with parsing `*`, leading to the somewhat awkward new
   `HsAppsTy` constructor for `HsType`. This is dispatched with in
   the renamer, where the kind `*` can be told apart from a
   type-level multiplication operator. Without `-XTypeInType` the
   old behavior persists. With `-XTypeInType`, you need to import
   `Data.Kind` to get `*`, also known as `Type`.

 * The kind-checking algorithms in TcHsType have been significantly
   rewritten to allow for enhanced kinds.

 * The new features are still quite experimental and may be in flux.

 * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.

 * TODO: Update user manual.

Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.

This patch began as a modest refactoring of HsType and friends, to
clarify and tidy up exactly where quantification takes place in types.
Although initially driven by making the implementation of wildcards more
tidy (and fixing a number of bugs), I gradually got drawn into a pretty
big process, which I've been doing on and off for quite a long time.

There is one compiler performance regression as a result of all
this, in perf/compiler/T3064.  I still need to look into that.

* The principal driving change is described in Note [HsType binders]
  in HsType.  Well worth reading!

* Those data type changes drive almost everything else.  In particular
  we now statically know where

       (a) implicit quantification only (LHsSigType),
           e.g. in instance declaratios and SPECIALISE signatures

       (b) implicit quantification and wildcards (LHsSigWcType)
           can appear, e.g. in function type signatures

* As part of this change, HsForAllTy is (a) simplified (no wildcards)
  and (b) split into HsForAllTy and HsQualTy.  The two contructors
  appear when and only when the correponding user-level construct
  appears.  Again see Note [HsType binders].

  HsExplicitFlag disappears altogether.

* Other simplifications

     - ExprWithTySig no longer needs an ExprWithTySigOut variant

     - TypeSig no longer needs a PostRn name [name] field
       for wildcards

     - PatSynSig records a LHsSigType rather than the decomposed
       pieces

     - The mysterious 'GenericSig' is now 'ClassOpSig'

* Renamed LHsTyVarBndrs to LHsQTyVars

* There are some uninteresting knock-on changes in Haddock,
  because of the HsSyn changes

I also did a bunch of loosely-related changes:

* We already had type synonyms CoercionN/CoercionR for nominal and
  representational coercions.  I've added similar treatment for

      TcCoercionN/TcCoercionR

      mkWpCastN/mkWpCastN

  All just type synonyms but jolly useful.

* I record-ised ForeignImport and ForeignExport

* I improved the (poor) fix to Trac #10896, by making
  TcTyClsDecls.checkValidTyCl recover from errors, but adding a
  harmless, abstract TyCon to the envt if so.

* I did some significant refactoring in RnEnv.lookupSubBndrOcc,
  for reasons that I have (embarrassingly) now totally forgotten.
  It had to do with something to do with import and export

Updates haddock submodule.

At the moment the API Annotations can only be used on the ParsedSource,
as there are changes made to the RenamedSource that prevent it from
being used to round trip source code.

It is possible to build a map from every Located Name in the
RenamedSource from its location to the Name, which can then be used when
resolved names are required when changing the ParsedSource.

However, there are instances where the identifier is not located,
specifically

  (GHC.VarPat name)
  (GHC.HsVar name)
  (GHC.UserTyVar name)
  (GHC.HsTyVar name)

Replace each of the name types above with (Located name)

Updates the haddock submodule.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: goldfire, thomie, mpickering

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

GHC Trac Issues: #11019

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 patch swaps the order of provided and required constraints in
a pattern signature, so it now goes

      pattern P :: req => prov => t1 -> ... tn -> res_ty

See the long discussion in Trac #10928.

I think I have found all the places, but I could have missed something
particularly in comments.

There is a Haddock changes; so a submodule update.

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

When pattern synonyms were introduced a new sum type was used
in places where DataCon used to be used. PatSyn and DataCon share many
of the same fields, this patch adds selectors to ConLike for these
fields.

Reviewers: austin, goldfire, bgamari

Subscribers: thomie

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

When examining #10615, I found the wildcard handling hard
to understand.  This patch refactors quite a bit, but with
no real change in behaviour.

 * Split out TcIdSigInfo from TcSigInfo, as a separate type,
   like TcPatSynInfo.

 * Make TcIdSigInfo express more invariants by pushing the
   wildard info into TcIdSigBndr

 * Remove all special treatment of unification variables that arise
   from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
   argument.

A ton of konck on changes.  The result is significantly simpler, I think.

This fixes Trac #10083.

The key change is in TcBinds.tcValBinds, where we construct
the prag_fn.  With this patch we add a NOINLINE pragma for
any functions that were exported by the hs-boot file for this
module.

See Note [Inlining and hs-boot files], and #10083, for details.

The commit touches several other files becuase I also changed the
representation of the "pragma function" from a function TcPragFun
to an environment, TcPragEnv. This makes it easer to extend
during construction.

When we have
  data instance T (a,b) = MkT a b
we make a represntation type
  data TPair a b = MkT a b
plus an axiom to connect the two
  ax a b :: T (a,b)  ~R  TPair a b

Previously this was a Nominal equality, and that worked ok
but seems illogical since Nominal equalities are between
types that the programmer thinks of as being equal.  But
TPair is not visible to the programmer; indeed we call it
the "representation TyCon".  So a Representational equality
seems more suitable here.

Trac #10516 pointed out that when reporting arity errors
(like "T needs 2 arguments but has been given 1"), we should
not count kind arguments, since they are implicit.  If we
include kind args in the count, we get very confusing error
messages indeed.

I did a little bit of refactoring which make some
error messages wobble around.  But the payload of
this fix is in TcValidity.tyConArityErr

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

This is a minor refactoring, but it simplifies the code quite a bit

* Decrease the number of variants of tcExtend in TcEnv
* Remove "not_actually_free" from TcEnv.tc_extend_local_env2
* Simplify plumbingof the "closed" flag
* Remove redundant scoping of wild-card variables

Summary:
SPJ's solution is to only bring the `TcId` (which includes the type) of a
binder into scope when it had a non-partial type signature.

Take care of this by only storing the `TcId` in `TcSigInfo` of non-partial
type signatures, hence the change to `sig_poly_id :: Maybe TcId`. Only in case
of a `Just` will we bring the `TcId` in scope. We still need to know the name
of the binder, even when it has a partial type signature, so add a `sig_name
:: Name` field. The field `sig_partial :: Bool` is no longer necessary, so
reimplement `isPartialSig` in terms of `sig_poly_id`.

Note that the new test case fails, but not because of a panic, but because the
`Num a` constraint is missing. Adding an extra-constraints wildcard to
`copy`'s signature would fix it.

Test Plan: validate

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #10045

As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
to behave exactly like $(n "...blah...").  But it doesn't!  This was outright
wrong: quasiquotes were being run even inside brackets.

Now that TH supports both typed and untyped splices, a quasi-quote is properly
regarded as a particular syntax for an untyped splice. But apart from that
they should be treated the same.  So this patch refactors the handling of
quasiquotes to do just that.

The changes touch quite a lot of files, but mostly in a routine way.
The biggest changes by far are in RnSplice, and more minor changes in
TcSplice.  These are the places where there was real work to be done.
Everything else is routine knock-on changes.

* No more QuasiQuote forms in declarations, expressions, types, etc.
  So we get rid of these data constructors
    * HsBinds.QuasiQuoteD
    * HsExpr.HsSpliceE
    * HsPat.QuasiQuotePat
    * HsType.HsQuasiQuoteTy

* We get rid of the HsQuasiQuote type altogether

* Instead, we augment the HsExpr.HsSplice type to have three
  consructors, for the three types of splice:
    * HsTypedSplice
    * HsUntypedSplice
    * HsQuasiQuote
  There are some related changes in the data types in HsExpr near HsSplice.
  Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.

* In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
  A smaller, clearer interface.

* We have to update the Haddock submodule, to accommodate the hsSyn changes

Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.

Reviewers: austin, jstolarek, hvr, goldfire

Reviewed By: austin, jstolarek

Subscribers: thomie, goldfire

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

GHC Trac Issues: #9986

Summary:
HsTyLit now has SourceText

Update documentation of HsSyn to reflect which annotations are attached to which element.

Ensure that the parser always keeps HsSCC and HsTickPragma values, to
be ignored in the desugar phase if not needed

Bringing in SourceText for pragmas

Add Location in NPlusKPat

Add Location in FunDep

Make RecCon payload Located

Explicitly add AnnVal to RdrName where it is compound

Add Location in IPBind

Add Location to name in IEThingAbs

Add Maybe (Located id,Bool) to Match to track fun_id,infix
  This includes converting Match into a record and adding a note about why
  the fun_id needs to be replicated in the Match.

Add Location in KindedTyVar

Sort out semi-colons for parsing

  - import statements
  - stmts
  - decls
  - decls_cls
  - decls_inst

This updates the haddock submodule.

Test Plan: ./validate

Reviewers: hvr, austin, goldfire, simonpj

Reviewed By: simonpj

Subscribers: thomie, carter

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

The idea was promted by Trac #9939, but it was Christmas, so I did
some recreational programming that went much further.

The idea is to warn when a constraint in a user-supplied context is
redundant.  Everything is described in detail in
  Note [Tracking redundant constraints]
in TcSimplify.

Main changes:

 * The new ic_status field in an implication, of type ImplicStatus.
   It replaces ic_insol, and includes information about redundant
   constraints.

 * New function TcSimplify.setImplicationStatus sets the ic_status.

 * TcSigInfo has sig_report_redundant field to say whenther a
   redundant constraint should be reported; and similarly
   the FunSigCtxt constructor of UserTypeCtxt

 * EvBinds has a field eb_is_given, to record whether it is a given
   or wanted binding. Some consequential chagnes to creating an evidence
   binding (so that we record whether it is given or wanted).

 * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
   see Note [Typechecking plan for instance declarations] in
   TcInstDcls

 * Some significant changes to the type checking of instance
   declarations; Note [Typechecking plan for instance declarations]
   in TcInstDcls.

 * I found that TcErrors.relevantBindings was failing to zonk the
   origin of the constraint it was looking at, and hence failing to
   find some relevant bindings.  Easy to fix, and orthogonal to
   everything else, but hard to disentangle.

Some minor refactorig:

 * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds

 * TcClassDcl and TcInstDcls now have their own code for typechecking
   a method body, rather than sharing a single function. The shared
   function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
   and the differences were growing confusing.

 * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
   use it

 * Add new function Bag.catBagMaybes, and use it in TcSimplify

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary: This patch changes the error message as suggested in trac issue #8815 comments.

Reviewers: jstolarek, austin

Reviewed By: jstolarek, austin

Subscribers: jstolarek, thomie, carter

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

GHC Trac Issues: #8815

Summary:
Add support for Partial Type Signatures, i.e. holes in types, see:
https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures

This requires an update to the Haddock submodule.

Test Plan: validate

Reviewers: austin, goldfire, simonpj

Reviewed By: simonpj

Subscribers: thomie, Iceland_jack, dominique.devriese, simonmar, carter, goldfire

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

GHC Trac Issues: #9478

(see #9838)

Summary:
AST changes to prepare for API annotations

Add locations to parts of the AST so that API annotations can
then be added.

The outline of the whole process is captured here
https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations

This change updates the haddock submodule.

Test Plan: sh ./validate

Reviewers: austin, simonpj, Mikolaj

Reviewed By: simonpj, Mikolaj

Subscribers: thomie, goldfire, carter

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

GHC Trac Issues: #9628

This is a pretty big patch, but which substantially iproves the subsumption
check.  Trac #9569 was the presenting example, showing how type inference could
depend rather delicately on eta expansion.  But there are other less exotic
examples; see Note [Co/contra-variance of subsumption checking] in TcUnify.

The driving change is to TcUnify.tcSubType.  But also

* HsWrapper gets a new constructor WpFun, which behaves very like CoFun:
       if     wrap1 :: exp_arg <= act_arg
              wrap2 :: act_res <= exp_res
       then   WpFun wrap1 wrap2 : (act_arg -> arg_res) <= (exp_arg -> exp_res)

* I generalised TcExp.tcApp to call tcSubType on the result,
  rather than tcUnifyType.  I think this just makes it consistent
  with everything else, notably tcWrapResult.

As usual I ended up doing some follow-on refactoring

* AmbigOrigin is gone (in favour of TypeEqOrigin)
* Combined BindPatSigCtxt and PatSigCxt into one
* Improved a bit of error message generation

Syntax is of the form

    pattern P :: (Prov b) => (Req a) => a -> b -> Int -> T a

which declares a pattern synonym called `P`, with argument types `a`, `b`,
and `Int`, and result type `T a`, with provided context `(Prov b)` and required
context `(Req a)`.

The Haddock submodule is also updated to use this new syntax in generated docs.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

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

This was a serious bug, exposed by Trac #9175.  The matcher and wrapper
must be LocalIds, like record selectors and dictionary functions, for
the reasons now documented in Note [Exported LocalIds] in Id.lhs

In fixing this I found
 - PatSyn should have an Id inside it (apart from the wrapper and matcher)
   It should be a Name.  Hence psId --> psName, with knock-on consequences

 - Tidying of PatSyns in TidyPgm was wrong

 - The keep-alive set in Desugar.deSugar (now) doesn't need pattern synonyms
   in it

I also cleaned up the interface to PatSyn a little, so there's a tiny knock-on
effect in Haddock; hence the haddock submodule update.

It's very hard to make a test for this bug, so I haven't.

We simply weren't giving anything like the right instantiating types
to patSynInstArgTys in matchOneConLike.

To get these instantiating types would have involved matching the
result type of the pattern synonym with the pattern type, which is
tiresome.  So instead I changed ConPatOut so that instead of recording
the type of the *whole* pattern (in old field pat_ty), it not records
the *instantiating* types (in new field pat_arg_tys).  Then we canuse
TcHsSyn.conLikeResTy to get the pattern type when needed.

There are lots of knock-on incidental effects, but they mostly made
the code simpler, so I'm happy.

This way, the Ids for the matchers/wrappers are reused by importing
modules, and thus unfoldings are kept.

Also updates haddock submodule to accomodate tweaks in PatSyn representation

In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to

- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
  any `{-# OPTIONS_GHC #-}`-lines.

- Moreover, if the list of language extensions fit into a single
  `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
  line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
  individual language extension. In both cases, try to keep the
  enumeration alphabetically ordered.
  (The latter layout is preferable as it's more diff-friendly)

While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.