Floated error expressions get poor strictness, leaving bad arity

GHC is careful to ensure that

  f = \x.  case x of 
               [] -> error "urk"
               (y:ys) -> \z. <blah>

gets arity 2. It does this by giving error an infinite arity. But if the error call is floated out by full laziness thus

  lvl = error "urk"
  f = \x.  case x of 
               [] -> lvl
               (y:ys) -> \z. <blah>

it's a bit less obvious. But it's ok: the strictness analyser disovers that lvl diverges.

Alas, if f is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter:

  {-# INLINE f #-}
  f = \x. case x of
            [] -> error ("urk" ++ x)
            (y:ys) -> \z. <blah>

I think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem.

Trac metadata

Trac field	Value
Version	6.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture