[GHC] #14749: T13822 fails

[GHC]

#14749: T13822 fails
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  goldfire
            Type:  bug               |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:  fixed             |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
                                     |  typecheck/should_compile/T14749
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Richard Eisenberg <rae@…>):

 In [changeset:"faec8d358985e5d0bf363bd96f23fe76c9e281f7/ghc"
 faec8d35/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="faec8d358985e5d0bf363bd96f23fe76c9e281f7"
 Track type variable scope more carefully.

 The main job of this commit is to track more accurately the scope
 of tyvars introduced by user-written foralls. For example, it would
 be to have something like this:

   forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool

 In that type, a's kind must be k, but k isn't in scope. We had a
 terrible way of doing this before (not worth repeating or describing
 here, but see the old tcImplicitTKBndrs and friends), but now
 we have a principled approach: make an Implication when kind-checking
 a forall. Doing so then hooks into the existing machinery for
 preventing skolem-escape, performing floating, etc. This also means
 that we bump the TcLevel whenever going into a forall.

 The new behavior is done in TcHsType.scopeTyVars, but see also
 TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
 rewriting. There are several Notes near there to guide you. Of
 particular interest there is that Implication constraints can now
 have skolems that are out of order; this situation is reported in
 TcErrors.

 A major consequence of this is a slightly tweaked process for type-
 checking type declarations. The new Note [Use SigTvs in kind-checking
 pass] in TcTyClsDecls lays it out.

 The error message for dependent/should_fail/TypeSkolEscape has become
 noticeably worse. However, this is because the code in TcErrors goes to
 some length to preserve pre-8.0 error messages for kind errors. It's time
 to rip off that plaster and get rid of much of the kind-error-specific
 error messages. I tried this, and doing so led to a lovely error message
 for TypeSkolEscape. So: I'm accepting the error message quality regression
 for now, but will open up a new ticket to fix it, along with a larger
 error-message improvement I've been pondering. This applies also to
 dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.

 Other minor changes:
  - isUnliftedTypeKind didn't look for tuples and sums. It does now.

  - check_type used check_arg_type on both sides of an AppTy. But the left
    side of an AppTy isn't an arg, and this was causing a bad error
 message.
    I've changed it to use check_type on the left-hand side.

  - Some refactoring around when we print (TYPE blah) in error messages.
    The changes decrease the times when we do so, to good effect.
    Of course, this is still all controlled by
    -fprint-explicit-runtime-reps

 Fixes #14066 #14749

 Test cases: dependent/should_compile/{T14066a,T14749},
             dependent/should_fail/T14066{,c,d,e,f,g,h}
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14749#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler