[GHC] #15627: Absent unlifted bindings

[GHC]

#15627: Absent unlifted bindings
-------------------------------------+-------------------------------------
        Reporter:  sgraf             |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  ⊥
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9279 #4328       |  Differential Rev(s):
  #11126                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by sgraf):

 * related:  #9279 #4328 => #9279 #4328 #11126


Comment:

 I just remember posting on ticket:11126#comment:17. While having the
 `absentError` mechanism around clearly is a sanity check, why only crash
 when it's entered? That's far too late to be a useful mechanism to debug
 the reason it crashed!

 So B) is just saying "If we messed up, at least crash with a marginally
 more descriptive error". Which isn't bad, but not nearly enough to debug
 this kind of crash across module boundaries.

 > I think -- but I am not sure -- that this literal should never occur in
 code generation. For example, we should never pass a rubbish value to a
 function. Before then dead-code elimination should have got rid of it I'm
 not 100% certain, but if this was true, it'd be a great sanity check.

 I'm thinking the same thing. If DCE didn't get rid of it, the demand
 analyser probably didn't agree with the occurrence analyser (who I presume
 is the final authority here), which is a bug that should be caught early
 to detect cross module symptoms like #11126 early.

 > Yes, `Literal` has `Eq` and `Ord` -- but I'm not sure why

 Actually, the very problems I had occurred in `cmpLit`, to which both seem
 to delegate. Regardless, I removed them. Let's try to see how far I get.

 > Do we need to spit out a RubbishLit in the Binary instance. This seems
 more likely, because perhaps these rubbish values can occur in unfoldings,
 which are serialised as their parse tree. But the we can just serialise
 the Type. It won't happen much.

 I'd like this, but there is no `Binary` instance for `Type`. I'm pretty
 much stuck here.

 I can see a hacky alternative here, namely to give `RubbishLit` the levity
 polymorphic `forall (r :: RuntimeRep) (a :: TYPE r)` type. Which is an
 unsafe lie again, because we only actually allow `AddrRep` and
 `UnliftedRep`. But this would allow to move the type application out of
 the literal.

 Or, looking at
 https://hackage.haskell.org/package/ghc-8.4.3/docs/IfaceType.html#t:IfaceType,
 maybe serialise that instead?

 Or add a new type `IfaceLiteral` to
 https://hackage.haskell.org/package/ghc-8.4.3/docs/IfaceSyn.html?

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