#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
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
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. 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:IfaceTyp..., 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