GitLab

This major commit was initially triggered by #11339, but it spiraled
into a major review of the way in which type signatures for bindings
are handled, especially partial type signatures.  On the way I fixed a
number of other bugs, namely
   #12069
   #12033
   #11700
   #11339
   #11670

The main change is that I completely reorganised the way in which type
signatures in bindings are handled. The new story is in TcSigs
Note [Overview of type signatures].  Some specific:

* Changes in the data types for signatures in TcRnTypes:
  TcIdSigInfo and new TcIdSigInst

* New module TcSigs deals with typechecking type signatures
  and pragmas. It contains code mostly moved from TcBinds,
  which is already too big

* HsTypes: I swapped the nesting of HsWildCardBndrs
  and HsImplicitBndsrs, so that the wildcards are on the
  oustide not the insidde in a LHsSigWcType.  This is just
  a matter of convenient, nothing deep.

There are a host of other changes as knock-on effects, and
it all took FAR longer than I anticipated :-).  But it is
a significant improvement, I think.

Lots of error messages changed slightly, some just variants but
some modest improvements.

New tests

* typecheck/should_compile
    * SigTyVars: a scoped-tyvar test
    * ExPat, ExPatFail: existential pattern bindings
    * T12069
    * T11700
    * T11339

* partial-sigs/should_compile
    * T12033
    * T11339a
    * T11670

One thing to check:

* Small change to output from ghc-api/landmines.
  Need to check with Alan Zimmerman

Summary:
MatchFixity was introduced to facilitate use of API Annotations.

HsMatchContext does the same thing with more detail, but is chased
through all over the place to provide context when processing a Match.

Since we already have MatchFixity in the Match, it may as well provide
the full context.

updates submodule haddock

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #12105

(cherry picked from commit 306ecad5)

It turns out that GHC 8.0 would accept entirely bogus
programs like

   f2 :: (True, _) -> Char
   Just f2 = Just (\x->x)

(which is now partial-sigs/should_fail/PatBind3)

This also fixes Trac #9478, test `PatBind2`.

For some reason a SigSkol had an ExpType in it, and there were
lots of places where we needed it to have a TcType.  And was indeed
always a Check.  All a lot of fuss about nothing.

Delete code, fewer failure points, types are more precise.
All good.

addDataConStupidTheta includes comments that the types list
might be longer than the tvs list. And the check in zipTvSubst
doesn't appear to be terribly recent. I am utterly flummoxed
as to why this worked before. It was clearly just broken.
And now it's fixed.

There were several smallish bugs here:
 - We had too small an InScopeSet when rejigging GADT return types.
 - When adding the extra_tvs with a datatype kind signature, we
   were sometimes changing Uniques of an explicitly bound kind var.
 - Using coercionKind in the flattener got the wrong visibility
   for a binder. Now we just zonk to get what we need.

Test case: dependent/should_compile/RaeJobTalk

There were two bugs here, both simple: we need to filter out
covars before calling isMetaTyVar in the solver, and TcPat had
a tcSubType the wrong way round.

test case: dependent/should_compile/T11711

Both gcc and clang tell which warning flag a reported warning can be
controlled with, this patch makes ghc do the same. More generally, this
allows for annotated compiler output, where an optional annotation is
displayed in brackets after the severity.

This also adds a new flag `-f(no-)show-warning-groups` to control
whether to show which warning-group (such as `-Wall` or `-Wcompat`)
a warning belongs to. This flag is on by default.

This implements #10752

Reviewed By: quchen, bgamari, hvr

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

See Note [TYPE] in TysPrim. There are still some outstanding
pieces in #11471 though, so this doesn't actually nail the bug.

This commit also contains a few performance improvements:

* Short-cut equality checking of nullary type syns

* Compare types before kinds in eqType

* INLINE coreViewOneStarKind

* Store tycon binders separately from kinds.

This resulted in a ~10% performance improvement in compiling
the Cabal package. No change in functionality other than
performance. (This affects the interface file format, though.)

This commit updates the haddock submodule.

It's just a small cleanup. There should be no change in
behaviour.

Test Plan: ./validate --slow

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, simonmar

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

This is the renaming that @simonpj requested:
```
· zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)

· zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
covars)

· zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
with TyBinders, not covars)
```
plus the `mk` variant.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: thomie, simonpj

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

GHC Trac Issues: #11371

The idea here is described in [wiki:Typechecker]. Briefly,
this refactor keeps solid track of "synthesis" mode vs
"checking" in GHC's bidirectional type-checking algorithm.
When in synthesis mode, the expected type is just an IORef
to write to.

In addition, this patch does a significant reworking of
RebindableSyntax, allowing much more freedom in the types
of the rebindable operators. For example, we can now have
`negate :: Int -> Bool` and
`(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
is in tcSyntaxOp.

This addresses tickets #11397, #11452, and #11458.

Tests:
  typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
  th/T11452

This was causing trouble as we had to remember when to use "unLifted"
and when to use "unlifted".

"unlifted" is used instead of "unLifted" as it's a single word.

Reviewers: austin, hvr, goldfire, bgamari

Subscribers: thomie

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

As Bartosz has discovered, the invariants for substitutions were
wrong, and in particular the "mkTop...Subst" and "zipTop..Subst"
functions were building substitutions that didn't obey even the
old invariants.

This patch kills of the bogus zipTopTCvSubst in favour of the
more robust zipOpenTCvSubst.

I tripped over this because my upcoming patch (concerning SetLevels,
Trac #11330) triggered an ASSERT failure in the substitution
well-formedness assertion in TyCoRep.

Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`.  But for some time now we have function `text` that
does the same.  Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`.  The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`.  I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.

Test Plan: ./validate

Reviewers: bgamari, austin, goldfire, hvr, alanz

Subscribers: goldfire, thomie, mpickering

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

This fixes Trac #11351.   The implementation is pretty
simple, happily.

I took the opportunity to re-order the prov/req context
in builder-ids, which was confusingly backwards.

This re-working of the typechecker algorithm is based on
the paper "Visible type application", by Richard Eisenberg,
Stephanie Weirich, and Hamidhasan Ahmed, to be published at
ESOP'16.

This patch introduces -XTypeApplications, which allows users
to say, for example `id @Int`, which has type `Int -> Int`. See
the changes to the user manual for details.

This patch addresses tickets #10619, #5296, #10589.

Various tickets have revealed bad shortcomings in the typechecking of
pattern type synonyms.  Discussed a lot in (the latter part of)
Trac #11224.

This patch fixes the most complex issues:

- Both parser and renamer now treat pattern synonyms as an
  ordinary LHsSigType.  Nothing special.  Hooray.

- tcPatSynSig (now in TcPatSyn) typechecks the signature, and
  decomposes it into its pieces.
  See Note [Pattern synonym signatures]

- tcCheckPatSyn has had a lot of refactoring.
  See Note [Checking against a pattern signature]

The result is a lot tidier and more comprehensible.
Plus, it actually works!

NB: this patch doesn't actually address the precise
    target of #11224, namely "inlining pattern synonym
    does not preserve semantics".  That's an unrelated
    bug, with a separate patch.

ToDo: better documentation in the user manual

Test Plan: Validate

Reviewers: austin, hvr, goldfire

Subscribers: goldfire, mpickering, thomie, simonpj

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

GHC Trac Issues: #11224

Summary:
Post #11019, there have been some new instances of RdrName that are not
located, in particular

```#!hs
data FieldOcc name = FieldOcc { rdrNameFieldOcc  :: RdrName
                              , selectorFieldOcc :: PostRn name name
                              }

data AmbiguousFieldOcc name
  = Unambiguous RdrName (PostRn name name)
  | Ambiguous   RdrName (PostTc name name)
  deriving (Typeable)
```
Add locations to them

Updates haddock submodule to match

Test Plan: ./validate

Reviewers: goldfire, hvr, bgamari, austin

Reviewed By: hvr

Subscribers: hvr, thomie, mpickering

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

GHC Trac Issues: #11258

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