[GHC] #12616: type synonyms confuse generalized newtype deriving role checking

[GHC]

#12616: type synonyms confuse generalized newtype deriving role checking
-------------------------------------+-------------------------------------
        Reporter:  daviddarais       |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  low               |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  generalized
                                     |  newtype deriving roles rankntypes
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"b612da667fe8fa5277fc78e972a86d4b35f98364/ghc" b612da6/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="b612da667fe8fa5277fc78e972a86d4b35f98364"
 Fix impredicativity (again)

 This patch fixes Trac #12616.

 Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
 support co- and contra-variance even for impredicative types.  With
 -XImpredicativeTYpes, this allowed a unification variable to be
 unified with a polytype (probably wrongly) and that caused later
 trouble in the constraint solver, where -XImpredicativeTypes was /not/
 on.  In effect, -XImpredicativeTypes can't be switched on locally.

 Why did we want ImpredicativeTypes locally?  Because the program
 generated by GND for a higher-rank method involved impredicative
 instantation of 'coerce':
       op = coerce op   -- where op has a higher rank type
 See Note [Newtype-deriving instances] in TcGenDeriv.

 Cure.

 1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
     feature) to instantiate coerce polymorphically.  Happily we
     now have Visible Type Application, so I've used that instead
     which should be solid and reliable.

 2.  I deleted the code in tc_sub_type_ds that allows the constraint
     solver to "look through" a unification variable to find a
     polytype.  That used to be essential in the days of ReturnTv,
     but it's utterly unreliable and should be consigned to the dustbin
     of history.  (We have ExpType now for the essential uses.)

 Tests involving ImpredicativeTypes are affected, but I'm not worried
 about them... it's advertised as a feature you can't rely on, and
 I want to reform it outright.
 }}}

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