indenting change causes internal error

[RichardG]

I found a bizarre little bug in GHC 6.12.1 on Mac OS X 10.6 (Haskell Platform 2010.1.0.0 i386). It only occurs when compiling through Cabal; it does not occur when using ghc --make or ghci.

The following code will compile without error but will generate a runtime error:

test = do
       E.throw Failure
       (return "No exception" :: IO String)
     `E.catches`
      [E.Handler (\Failure -> return "Exception")]

The following code will compile and run correctly:

test = do
      E.throw Failure
       (return "No exception" :: IO String)
     `E.catches`
      [E.Handler (\Failure -> return "Exception")]

The only difference between the 2 is that the second has one less leading space.

The generated error is:

test1: internal error: PAP object entered!
    (GHC version 6.12.1 for i386_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap

Deleting my ~/.ghc folder had no effect.

[RichardG]

Source code and Cabal files for tests

[RichardG]

I forgot to mention that the following will compile without warning:

test = do
       E.throw Failure
       return "No exception"
     `E.catches`
      [E.Handler (\Failure -> return "Exception")]

whereas

test = do
      E.throw Failure
       return "No exception"
     `E.catches`
      [E.Handler (\Failure -> return "Exception")]

generates the following error:

Test2.hs:19:7:
    Ambiguous type variable `m' in the constraint:
      `Monad m' arising from a use of `return' at Test2.hs:19:7-12
    Probable fix: add a type signature that fixes these type variable(s)

[igloo]

Note that the two definitions are not parsed the same; if you compile with -ddump-parsed then you see

test = do { E.throw Failure;
            (return "No exception" :: IO String) }
     `E.catches`
       [E.Handler (\ Failure -> return "Exception")]

vs

test = do { E.throw Failure (return "No exception" :: IO String) }
     `E.catches`
       [E.Handler (\ Failure -> return "Exception")]

I can reproduce this on amd64/Linux with 6.12.1 and the 6.12 branch, but not the HEAD.

[igloo]

To clarify: I can reproduce the "internal error: PAP object entered!". The different parses are correct.

[simonpj]

Turns out this is #2861 in another guise. I need to think about it.

Simon

[simonpj]

See alss #3961, #3983

Simon

[simonpj]

OK I think I have finally fixed this. It's all to do with eta expansion and bottoming functions; there are lots of notes in CoreArity

Fri Aug 13 17:11:51 BST 2010  simonpj@microsoft.com
  * Re-do the arity calculation mechanism again (fix Trac #3959)
  
  After rumination, yet again, on the subject of arity calculation,
  I have redone what an ArityType is (it's purely internal to the
  CoreArity module), and documented it better.  The result should
  fix #3959, and I hope the related #3961, #3983.
  
  There is lots of new documentation: in particular
   * Note [ArityType]  
     describes the new datatype for arity info
  
   * Note [State hack and bottoming functions] 
     says how bottoming functions are dealt with, particularly
     covering catch# and Trac #3959
  
  I also found I had to be careful not to eta-expand single-method
  class constructors; see Note [Newtype classes and eta expansion].
  I think this part could be done better, but it works ok.

Simon