GitLab

When GHC attempts to unify a metavariable with a type containing
foralls, it will be rejected as an occurrence of impredicativity.
GHC was /not/ extending the same treatment to predicate types, such
as in the following (erroneous) example from #11514:

```haskell
foo :: forall a. (Show a => a -> a) -> ()
foo = undefined
```

This will attempt to instantiate `undefined` at
`(Show a => a -> a) -> ()`, which is impredicative. This patch
catches impredicativity arising from predicates in this fashion.

Since GHC is pickier about impredicative instantiations, some test
cases needed to be updated to be updated so as not to fall afoul of
the new validity check. (There were a surprising number of
impredicative uses of `undefined`!) Moreover, the `T14828` test case
now has slightly less informative types shown with `:print`. This is
due to a a much deeper issue with the GHCi debugger (see #14828).

Fixes #11514.

I believe removing __mingw_vsnwprintf from RtsSymbols fixed #16387.

See #16387.

Broke as -Wimplicit-kind-vars no longer exists. Specifically ghci024,
ghci057 and T9293.

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.

The GHCi debugger has never been that robust in the face of
higher-rank types, or even types that are _interally_ higher-rank,
such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
however, things became even worse, as the debugger would start to
_panic_ when a user tries passing the name of a higher-rank thing
to `:print`. This all ties back to a strange `isUnliftedType` check
in `Debugger` that was mysteriously added 11 years ago
(in commit 4d71f5ee) with no
explanation whatsoever.

After some experimentation, no one is quite sure what this
`isUnliftedType` check is actually accomplishing. The test suite
still passes if it's removed, and I am unable to observe any
differences in debugger before even with data types that _do_ have
fields of unlifted types (e.g., `data T = MkT Int#`). Given that
this is actively causing problems (see #14828), the prudent thing
to do seems to be just removing this `isUnliftedType` check, and
waiting to see if anyone shouts about it. This patch accomplishes
just that.

Note that this patch fix the underlying issues behind #14828, as the
debugger will still print unhelpful info if you try this:

```
λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
λ> :print f
f = (_t1::t1)
```

But fixing this will require much more work, so let's start with the
simple stuff for now.

Prevents some tests from failing just due to mismatched version numbers.

These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc9.

Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).

Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.

So we need to be sure to call captureTopConstraints to report
those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.

As a result the error messages from test T13466 improved slightly,
a happy outcome.

The type-variables-escaping-their-scope-via-kinds check in
`TcValidity` was failing to properly expand type synonyms, which led
to #16391. This is easily fixed by using `occCheckExpand` before
performing the validity check.

Along the way, I refactored this check out into its own function,
and sprinkled references to Notes to better explain all of the moving
parts. Many thanks to @simonpj for the suggestions.

Bumps the haddock submodule.

Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
Fixes Trac #16334, Trac #16315

With this patch, scoping rules for type and kind variables have been
unified: kind variables no longer receieve special treatment. This
simplifies both the language and the implementation.

User-facing changes
-------------------

* Kind variables are no longer implicitly quantified when an explicit
  forall is used:

    p ::             Proxy (a :: k)    -- still accepted
    p :: forall k a. Proxy (a :: k)    -- still accepted
    p :: forall   a. Proxy (a :: k)    -- no longer accepted

  In other words, now we adhere to the "forall-or-nothing" rule more
  strictly.

  Related function: RnTypes.rnImplicitBndrs

* The -Wimplicit-kind-vars warning has been deprecated.

* Kind variables are no longer implicitly quantified in constructor
  declarations:

    data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
    data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted

  Related function: RnTypes.extractRdrKindSigVars

* Implicitly quantified kind variables are no longer put in front of
  other variables:

    f :: Proxy (a :: k) -> Proxy (b :: j)

    f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
    f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order

  This is a breaking change for users of TypeApplications. Note that
  we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
  See "Ordering of specified variables" in the User's Guide.

  Related function: RnTypes.rnImplicitBndrs

* In type synonyms and type family equations, free variables on the RHS
  are no longer implicitly quantified unless used in an outermost kind
  annotation:

    type T = Just (Nothing :: Maybe a)         -- no longer accepted
    type T = Just Nothing :: Maybe (Maybe a)   -- still accepted

  The latter form is a workaround due to temporary lack of an explicit
  quantification method. Ideally, we would write something along these
  lines:

    type T @a = Just (Nothing :: Maybe a)

  Related function: RnTypes.extractHsTyRdrTyVarsKindVars

* Named wildcards in kinds are fixed (Trac #16334):

    x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)

  Related function: RnTypes.partition_nwcs

Implementation notes
--------------------

* One of the key changes is the removal of FKTV in RnTypes:

  - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
  -                          , fktv_tys    :: [Located RdrName] }
  + type FreeKiTyVars = [Located RdrName]

  We used to keep track of type and kind variables separately, but
  now that they are on equal footing when it comes to scoping, we
  can put them in the same list.

* extract_lty and family are no longer parametrized by TypeOrKind,
  as we now do not distinguish kind variables from type variables.

* PatSynExPE and the related Note [Pattern synonym existentials do not scope]
  have been removed (Trac #16315). With no implicit kind quantification,
  we can no longer trigger the error.

* reportFloatingKvs and the related Note [Free-floating kind vars]
  have been removed. With no implicit kind quantification,
  we can no longer trigger the error.

We use "touch -r" to set modification timestamps, which leads to precision loss
on Darwin. For example,

   before: 2019-02-25 01:11:23.807627350 +0300
   after:  2019-02-25 01:11:23.807627000 +0300
                                     ^^^
This means we can't trick GHCi into thinking the file hasn't been changed by
restoring its old timestamp, as we cannot faithfully restore all digits.

The solution is to nullify the insignificant digits before the first :load

This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
introducing a new ambiguity resolution system in the parser.

Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a command:

	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
	proc x -> do { (stuff) }        -- 'stuff' is a command

Until we encounter arrow syntax (-<) we don't know whether to parse
'stuff' as an expression or a command.

The old solution was to parse as HsExpr always, and rejig later:

	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)

This meant polluting 'HsExpr' with command-related constructors. In
other words, limitations of the parser were affecting the AST, and
all other code (the renamer, the typechecker) had to deal with these
extra constructors by panicking.

We fix this abstraction leak by parsing into an intermediate
representation, 'ExpCmd':

	data ExpCmdG b where
	  ExpG :: ExpCmdG HsExpr
	  CmdG :: ExpCmdG HsCmd

	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))

	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
	checkExp f = f ExpG  -- interpret as an expression
	checkCmd f = f CmdG  -- interpret as a command

See Note [Ambiguous syntactic categories] for details.

Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/command ambiguity.

Future work: apply the same principles to the expression/pattern
ambiguity.

This patch makes us fail fast in TcSimplify.solveLocalEqualities,
and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.

Previously we ploughed on even if there were insoluble constraints,
leading to a cascade of hard-to-understand type errors. Failing
eagerly is much better; hence a lot of testsuite error message
changes.  Eg if we have
          f :: [Maybe] -> blah
          f xs = e
then trying typecheck 'f x = e' with an utterly bogus type
is just asking for trouble.

I can't quite remember what provoked me to make this change,
but I think the error messages are notably improved, by
removing confusing clutter and focusing on the real error.

GHCi's `:info` command was pretty-printing Haskell98-style data types
with explicit return kinds if the return kind wasn't `Type`. This
leads to bizarre output like this:

```
λ> :i (##)
data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)
        -- Defined in ‘GHC.Prim’
```

Or, with unlifted newtypes:

```
λ> newtype T = MkT Int#
λ> :i T
newtype T :: TYPE 'IntRep = MkT Int#
        -- Defined at <interactive>:5:1
```

The solution is simple: just delete one part from `IfaceSyn` where
GHC mistakenly pretty-prints the return kinds for non-GADTs.

This eliminates most uses of run_command in the testsuite in favor of the more
structured makefile_test.

This reverts commit 76c8fd67.

This is the last failing test on Darwin preventing us from disallowing CI
failures. See #16201.

A bunch of tests for `integer-simple` were now broken for a foolish reason:
unlike the `integer-gmp` case, there is no CorePrep optimization for turning
small integers directly into applications of `S#`.

Rather than port this optimization to `integer-simple` (which would involve
moving a bunch of `integer-simple` names into `PrelNames`), I switched
as many tests as possible to use `Int`.

The printing of `Integer` is already tested in `print037`.

Instead of parsing and executing a statement or declaration directly we
now parse them first and then execute in a separate step. This gives us
the flexibility to inspect the parsed declaration before execution.
Using this we now inspect parsed declarations, and if it's a single
declaration of form `x = y` we execute it as `let x = y` instead, fixing
a ton of problems caused by poor declaration support in GHCi.

To avoid any users of the modules I left `execStmt` and `runDecls`
unchanged and added `execStmt'` and `runDecls'` which work on parsed
statements/declarations.

Summary:
This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
application, just like in term-level.

There are a few remaining issues with this patch, as documented in
ticket #16082.

Includes a submodule update for Haddock.

Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a

Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack

Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter

GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`

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

Summary:
GHCi's `:info` command was pretty-printined GADT
constructors suboptimally in the following ways:

1. Sometimes, fields were parenthesized when they did not need it,
   e.g.,

```lang=haskell
data Foo a where
  MkFoo :: (Maybe a) -> Foo a
```

   I fixed this by refactoring some code in `pprIfaceConDecl` to be a
   little smarter with respect to GADT syntax. See `pprFieldArgTy`
   and `pprArgTy`.
2. With `-fprint-explicit-kinds` enabled, there would be times when
   specified arguments would be printed without a leading `@` in GADT
   return types, e.g.,

```lang=haskell
data Bar @k (a :: k) where
  MkBar :: Bar k a
```

   It turns out that `ppr_tc_app`, the function which pretty-prints
   these return types, was not using the proper machinery to print
   out the arguments, which caused the visibilities to be forgotten
   entirely. I refactored `ppr_tc_app` to do this correctly.

Test Plan: make test TEST=T16030

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #16030

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

Summary:
See #8959, this is one more place where we
can pretty-print Unicode syntax.

Test Plan: validate

Reviewers: nomeata, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #8959

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

`ghci -fno-implicit-import-qualified` didn't start with error message:

```
GHCi, version 8.6.2: http://www.haskell.org/ghc/  :? for help

<interactive>:1:6: error:
    Not in scope: ‘System.IO.hSetBuffering’
        No module named ‘System.IO’ is imported.

...
```

This change fixes it and update test T2452 to cover this.

Test Plan:
  TEST=T2452 make accept

harbormaster build runs

Reviewers: simonmar, bgamari, RyanGlScott

Reviewed By: simonmar

Subscribers: rwbarton, carter

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

Towards fixing #16043.

My original goal was (Trac #15809) to move towards using level numbers
as the basis for deciding which type variables to generalise, rather
than searching for the free varaibles of the environment.  However
it has turned into a truly major refactoring of the kind inference
engine.

Let's deal with the level-numbers part first:

* Augment quantifyTyVars to calculate the type variables to
  quantify using level numbers, and compare the result with
  the existing approach.  That is; no change in behaviour,
  just a WARNing if the two approaches give different answers.

* To do this I had to get the level number right when calling
  quantifyTyVars, and this entailed a bit of care, especially
  in the code for kind-checking type declarations.

* However, on the way I was able to eliminate or simplify
  a number of calls to solveEqualities.

This work is incomplete: I'm not /using/ level numbers yet.
When I subsequently get rid of any remaining WARNings in
quantifyTyVars, that the level-number answers differ from
the current answers, then I can rip out the current
"free vars of the environment" stuff.

Anyway, this led me into deep dive into kind inference for type and
class declarations, which is an increasingly soggy part of GHC.
Richard already did some good work recently in

   commit 5e45ad10
   Date:   Thu Sep 13 09:56:02 2018 +0200

    Finish fix for #14880.

    The real change that fixes the ticket is described in
    Note [Naughty quantification candidates] in TcMType.

but I kept turning over stones. So this patch has ended up
with a pretty significant refactoring of that code too.

Kind inference for types and classes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Major refactoring in the way we generalise the inferred kind of
  a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
  function, generaliseTcTyCon.  Plus a new Note to explain it
  Note [Inferring kinds for type declarations].

* We decided (Trac #15592) not to treat class type variables specially
  when dealing with Inferred/Specified/Required for associated types.
  That simplifies things quite a bit. I also rewrote
  Note [Required, Specified, and Inferred for types]

* Major refactoring of the crucial function kcLHsQTyVars:
  I split it into
       kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
  because the two are really quite different. The CUSK case is
  almost entirely rewritten, and is much easier because of our new
  decision not to treat the class variables specially

* I moved all the error checks from tcTyClTyVars (which was a bizarre
  place for it) into generaliseTcTyCon and/or the CUSK case of
  kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.

* I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
  now there is no difference between tcImplicitTKBndrs and
  kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
  Same for kc/tcExplicitTKBndrs.  None of them monkey with level
  numbers, nor build implication constraints.  scopeTyVars is gone
  entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.

  I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
  the bnew bindExplicitTKBndrs.

Quantification
~~~~~~~~~~~~~~
* I now deal with the "naughty quantification candidates"
  of the previous patch in candidateQTyVars, rather than in
  quantifyTyVars; see Note [Naughty quantification candidates]
  in TcMType.

  I also killed off closeOverKindsCQTvs in favour of the same
  strategy that we use for tyCoVarsOfType: namely, close over kinds
  at the occurrences.

  And candidateQTyVars no longer needs a gbl_tvs argument.

* Passing the ContextKind, rather than the expected kind itself,
  to tc_hs_sig_type_and_gen makes it easy to allocate the expected
  result kind (when we are in inference mode) at the right level.

Type families
~~~~~~~~~~~~~~
* I did a major rewrite of the impenetrable tcFamTyPats. The result
  is vastly more comprehensible.

* I got rid of kcDataDefn entirely, quite a big function.

* I re-did the way that checkConsistentFamInst works, so
  that it allows alpha-renaming of invisible arguments.

* The interaction of kind signatures and family instances is tricky.
    Type families: see Note [Apparently-nullary families]
    Data families: see Note [Result kind signature for a data family instance]
                   and Note [Eta-reduction for data families]

* The consistent instantation of an associated type family is tricky.
  See Note [Checking consistent instantiation] and
      Note [Matching in the consistent-instantation check]
  in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
  when we have the relevant info to hand.

* I got tired of the compromises in etaExpandFamInst, so I did the
  job properly by adding a field cab_eta_tvs to CoAxBranch.
  See Coercion.etaExpandCoAxBranch.

tcInferApps and friends
~~~~~~~~~~~~~~~~~~~~~~~
* I got rid of the mysterious and horrible ClsInstInfo argument
  to tcInferApps, checkExpectedKindX, and various checkValid
  functions.  It was horrible!

* I got rid of [Type] result of tcInferApps.  This list was used
  only in tcFamTyPats, when checking the LHS of a type instance;
  and if there is a cast in the middle, the list is meaningless.
  So I made tcInferApps simpler, and moved the complexity
  (not much) to tcInferApps.

  Result: tcInferApps is now pretty comprehensible again.

* I refactored the many function in TcMType that instantiate skolems.

Smaller things

* I rejigged the error message in checkValidTelescope; I think it's
  quite a bit better now.

* checkValidType was not rejecting constraints in a kind signature
     forall (a :: Eq b => blah). blah2
  That led to further errors when we then do an ambiguity check.
  So I make checkValidType reject it more aggressively.

* I killed off quantifyConDecl, instead calling kindGeneralize
  directly.

* I fixed an outright bug in tyCoVarsOfImplic, where we were not
  colleting the tyvar of the kind of the skolems

* Renamed ClsInstInfo to AssocInstInfo, and made it into its
  own data type

* Some fiddling around with pretty-printing of family
  instances which was trickier than I thought.  I wanted
  wildcards to print as plain "_" in user messages, although
  they each need a unique identity in the CoAxBranch.

Some other oddments

* Refactoring around the trace messages from reportUnsolved.
* A bit of extra tc-tracing in TcHsSyn.commitFlexi

This patch fixes a raft of bugs, and includes tests for them.

 * #14887
 * #15740
 * #15764
 * #15789
 * #15804
 * #15817
 * #15870
 * #15874
 * #15881

Summary:
The iface pretty-printer had a special case for an
application of an infix type constructor to two arguments. But this
didn't take the visibilities of the arguments into account, which
could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when
`-fprint-explicit-kinds` was enabled (#15941). The fix is relatively
straightforward: simply plumb through the visibilities of each
argument, and only trigger the special case for infix applications
if both arguments are visible (i.e., required).

Test Plan: make test TEST=T15941

Reviewers: goldfire, bgamari, monoidal

Reviewed By: goldfire, monoidal

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15941

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

Summary:
When `-fprint-explicit-foralls` is enabled, type family
equations are either printed without an explict `forall` entirely,
or with a bizarre square bracket syntax (in the case of closed type
families). I find neither satisfying, so in this patch, I introduce
support for printing explicit `forall`s in open type-family, closed
type-family, and data-family equations when appropriate. (By "when
appropriate", I refer to the conditions laid out in
`Note [When to print foralls]` in `IfaceType`.)

One tricky point in the implementation is that I had to pick a
visibility for each type variable in a `CoAxiom`/`FamInst` in order
to be able to pass it to `pprUserIfaceForAll` //et al.// Because
the type variables in a type family instance equation can't be
instantiated by the programmer anyway, the choice only really matters
for pretty-printing purposes, so I simply went with good ol'
trustworthy `Specified`. (This design choice is documented in
`Note [Printing foralls in type family instances]` in `IfaceType`.)

Test Plan: make test TEST=T15827

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15827

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

This patch changes the behavior of `-fprint-explicit-kinds`
so that it displays kind argument using visible kind application.
In other words, the flag now:

1. Prints instantiations of specified variables with `@(...)`.
2. Prints instantiations of inferred variables with `@{...}`.

In addition, this patch removes the `Use -fprint-explicit-kinds to
see the kind arguments` error message that often arises when a type
mismatch occurs due to different kinds. Instead, whenever there is a
kind mismatch, we now enable the `-fprint-explicit-kinds` flag
locally to help cue to the programmer where the error lies.
(See `Note [Kind arguments in error messages]` in `TcErrors`.)
As a result, these funny `@{...}` things can now appear to the user
even without turning on the `-fprint-explicit-kinds` flag explicitly,
so I took the liberty of documenting them in the users' guide.

Test Plan: ./validate

Reviewers: goldfire, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15871

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

Test Plan: ./validate

Reviewers: bgamari, simonmar

Subscribers: rwbarton, carter

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

Summary:
validate is currently broken [1] on master, this patches addresses
the failure by removing an expected stdout file for T15898 since no output
is generated there.

[1]: https://circleci.com/gh/ghc/ghc/11416

Test Plan: TEST=T15898 ./validate

Reviewers: bgamari

Subscribers: rwbarton, carter

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

Fix Trac #15898, by being smarter about when to print
a space before a promoted data constructor, in a HsType.
I had to implement a mildly tiresome function
    HsType.lhsTypeHasLeadingPromotionQuote
It has multiple cases, of course, but it's very simple.

The patch improves the error-message output in a bunch of
cases, and (to my surprise) actually fixes a bug in the
output of T14343 (Trac #14343), thus

  -  In the expression: _ :: Proxy '('( 'True,  'False),  'False)
  +  In the expression: _ :: Proxy '( '( 'True, 'False), 'False)

I discovered that there were two copies of the PromotionFlag
type (a boolean, with helpfully named data cons), one in
IfaceType and one in HsType.  So I combined into one,
PromotionFlag, and moved it to BasicTypes.  That's why
quite a few files are touched, but it's all routine.

Per feature request, add `HasCallStack` to `fromJust` in `Data.Maybe`
and use `error` instead of `errorWithoutStackTrace`. This allows
`fromJust` to print call stacks when throwing the error.

Also add a new test case for the behaviour, modify existing test cases
for new signature

Test Plan: New test cases

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: ulysses4ever, rwbarton, carter

GHC Trac Issues: #15559

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

The real change that fixes the ticket is described in
Note [Naughty quantification candidates] in TcMType.

Fixing this required reworking candidateQTyVarsOfType, the function
that extracts free variables as candidates for quantification.
One consequence is that we now must be more careful when quantifying:
any skolems around must be quantified manually, and quantifyTyVars
will now only quantify over metavariables. This makes good sense,
as skolems are generally user-written and are listed in the AST.

As a bonus, we now have more control over the ordering of such
skolems.

Along the way, this commit fixes #15711 and refines the fix
to #14552 (by accepted a program that was previously rejected,
as we can now accept that program by zapping variables to Any).

This commit also does a fair amount of rejiggering kind inference
of datatypes. Notably, we now can skip the generalization step
in kcTyClGroup for types with CUSKs, because we get the
kind right the first time. This commit also thus fixes #15743 and
 #15592, which both concern datatype kind generalisation.
(#15591 is also very relevant.) For this aspect of the commit, see
Note [Required, Specified, and Inferred in types] in TcTyClsDecls.

Test cases: dependent/should_fail/T14880{,-2},
            dependent/should_fail/T15743[cd]
            dependent/should_compile/T15743{,e}
            ghci/scripts/T15743b
            polykinds/T15592
            dependent/should_fail/T15591[bc]
            ghci/scripts/T15591

Summary:
In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten
edge case in ALR, since `maybe_layout` (which handles the non-ALR layout)
already deals with the 'ITlcase' token properly.

Test Plan: make TEST=T10453 && make TEST=T13087

Reviewers: bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #10453, #13087

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

Enabling -Werror=compat in the testsuite allows us to easily see the
impact that a new warning has on code. It also means that in the period
between adding the warning and making the actual breaking change, all
new test cases that are being added to the testsuite will be
forwards-compatible. This is good because it will make the actual
breaking change contain less irrelevant testsuite updates.

Things that -Wcompat warns about are things that are going to break in
the future, so we can be proactive and keep our testsuite
forwards-compatible.

This patch consists of two main changes:

* Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
* Fix all broken test cases.

Test Plan: Validate

Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott

Reviewed By: goldfire, RyanGlScott

Subscribers: rwbarton, carter

GHC Trac Issues: #15278

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

Summary:
This simply makes explicit what is already the case. Due to special
treatment in the parser, `->` has the lowest fixity. This patch propagates
that information to:

  * GHCi, where `:info ->` now return the right fixity
  * TH, where `reifyFixity` returns the right fixity
  * the generated sources for `GHC.Prim`

See #15235.

Test Plan: make test

Reviewers: bgamari, alanz, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter

GHC Trac Issues: #15235

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

Currently forall-types with a lot of type variables,
or type variables with big kinds, are pretty-printed too
horizontally, and dribble off to the right in an illegible
way.

This patch treats the type variables as a group, and uses
'fsep' to lay them out decently.