[GHC] #14561: Panic on levity polymorphic very unsafe coerce

[GHC]

#14561: Panic on levity polymorphic very unsafe coerce
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
                                     |  LevityPolymorphism
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Ah, hum.  Lint rejects the program thus
 {{{
 *** Core Lint errors : in result of Desugar (after optimization) ***
 <no location info>: warning:
     [in body of lambda with binder v_B1 :: a_aVG]
     Levity-polymorphic binder: v_B1 :: (a_aVG :: TYPE r_aVF)
 *** Offending Program ***
 levityPolymorphicId :: forall (a :: TYPE r). a -> a
 [LclIdX]
 levityPolymorphicId
   = \ (@ (r_aVF :: RuntimeRep))
       (@ (a_aVG :: TYPE r_aVF))
       (v_B1 :: a_aVG) ->
       v_B1
 }}}
 This happens because we want to allow
 {{{
 unsafeCoerce# (x::Int#)
 }}}
 and expand it to
 {{{
 x |> (UnsafeCo ...)
 }}}
 So we give `unsafeCoerce#` the extremely dodgy unfolding
 {{{
 /\r1 r2 (a:Type r1) (b:Type r2) (x:a). x |> UnsafeCo ...
 }}}
 It's dodgy because it has a bad lambda: we can't lambda-bind a levity-
 polymorphic variable `x`.  It only works when `unsafeCoerce#` is
 saturated.

 This is tiresome.  The only paths forward I can see are

 * Do not allow `unsafeCoerce` on unboxed values.  I don't know how much it
 is used.

 * Check that all uses are saturated.  Perhaps in the desugarer.

 The latter would be least destabilising.

 Any thoughts?

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