[GHC] #11660: Remove Type pretty-printer in favor of IfaceType

GHC ghc-devs at haskell.org
Fri Oct 14 14:46:57 UTC 2016


#11660: Remove Type pretty-printer in favor of IfaceType
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  task              |               Status:  patch
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #12550, #12447,   |  Differential Rev(s):  Phab:D2528
  #11786, #11549, #12024, #12697,    |
  #12510                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > One thing slightly non-trivial issue that I've run into on this is that
 I seem to walk into holes while printing with the IfaceType printer which
 previously we avoided. For instance, `tcfail123` fails

 The typechecker is trying to unify a lifted type with an unlifted one.  So
 it produces
 {{{
 [W] ax1 :: TYPE IntRep ~ TYPE LiftedPtrRep
 }}}
 which of course it can't solve.  But rather than print that obscure
 message, it tries to print the offending type, which looks like
 {{{
  Int# |> (hole{ax1})
 }}}
 where `hole{ax1}` is the un-proven assertion above.  The type printer
 suppresses the coercion (though you can see it with current GHC using
 `-fprint-explicit-coercions`).

 So for this and debugging reasons we do want to be able to print types
 with coercion holes in them, although they should never end up in
 interface files.  So let's add `IfaceHoleProv` to `IfaceUnivCoProv`; and
 make `toIfaceType` use it.  But serialisation can barf.

 Clearly this will need a Note, taken from this comment

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


More information about the ghc-tickets mailing list