[GHC] #14441: GHC HEAD regression involving type families in kinds

[GHC]

#14441: GHC HEAD regression involving type families in kinds
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:  TypeInType,
                                     |  TypeFamilies
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:  12919             |             Blocking:
 Related Tickets:  #13790            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

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

 In [changeset:"e3dbb44f53b2f9403d20d84e27f187062755a089/ghc"
 e3dbb44f/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="e3dbb44f53b2f9403d20d84e27f187062755a089"
 Fix #12919 by making the flattener homegeneous.

 This changes a key invariant of the flattener. Previously,
 flattening a type meant flattening its kind as well. But now,
 flattening is always homogeneous -- that is, the kind of the
 flattened type is the same as the kind of the input type.
 This is achieved by various wizardry in the TcFlatten.flatten_many
 function, as described in Note [flatten_many].

 There are several knock-on effects, including some refactoring
 in the canonicalizer to take proper advantage of the flattener's
 changed behavior. In particular, the tyvar case of can_eq_nc' no
 longer needs to take casts into account.

 Another effect is that flattening a tyconapp might change it
 into a casted tyconapp. This might happen if the result kind
 of the tycon contains a variable, and that variable changes
 during flattening. Because the flattener is homogeneous, it tacks
 on a cast to keep the tyconapp kind the same. However, this
 is problematic when flattening CFunEqCans, which need to have
 an uncasted tyconapp on the LHS and must remain homogeneous.
 The solution is a more involved canCFunEqCan, described in
 Note [canCFunEqCan].

 This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
 and the panic in typecheck/should_compile/T13822 (as reported in #14024).
 Actually, there were two bugs in T13822: the first was just some
 incorrect logic in tryFill (part of the unflattener) -- also fixed
 in this patch -- and the other was the main bug fixed in this ticket.

 The changes in this patch exposed a long-standing flaw in OptCoercion,
 in that breaking apart an AppCo sometimes has unexpected effects on
 kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
 problem and fix.

 Also here is a reversion of the major change in
 09bf135ace55ce2572bf4168124d631e386c64bb, affecting ctEvCoercion.
 It turns out that making the flattener homogeneous changes the
 invariants on the algorithm, making the change in that patch
 no longer necessary.

 This patch also fixes:
   #14038 (dependent/should_compile/T14038)
   #13910 (dependent/should_compile/T13910)
   #13938 (dependent/should_compile/T13938)
   #14441 (typecheck/should_compile/T14441)
   #14556 (dependent/should_compile/T14556)
   #14720 (dependent/should_compile/T14720)
   #14749 (typecheck/should_compile/T14749)

 Sadly, this patch negatively affects performance of type-family-
 heavy code. The following patch fixes these performance degradations.
 However, the performance fixes are somewhat invasive and so I've
 kept them as a separate patch, labeling this one as [skip ci] so
 that validation doesn't fail on the performance cases.
 }}}

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