Panic in a user Template Haskell function is wrongly reported as a GHC bug

[SimonMeier]

GhcBangBug?.hs:1:1:ghc: panic! (the 'impossible' happened)

(GHC version 7.4.1 for x86_64-unknown-linux):

Could not convert (Strict,Type) to BangType?

(Unpacked,ConT GHC.Types.Int) Language/Haskell/Convert.hs:(64,5)-(65,42): Non-exhaustive patterns in function conv

See attached test file for further information.

[simonpj]

Looks like a bug in module Language.Haskell.Convert, which I don't recognise.

Why do you think it's a GHC bug? I'm closing as invalid but re-open if you think it's a GHC bug.

Simon

[SimonMeier]

Replying to simonpj:

Looks like a bug in module Language.Haskell.Convert, which I don't recognise.

You are right. This module is part of the derive package ( http://hackage.haskell.org/package/derive).

Why do you think it's a GHC bug? I'm closing as invalid but re-open if you think it's a GHC bug.

I thought it's a GHC bug because the error message was:

  GhcBangBug.hs:1:1:ghc: panic! (the 'impossible' happened)
    (GHC version 7.4.1 for x86_64-unknown-linux):
          Could not convert (Strict,Type) to BangType
         (Unpacked,ConT GHC.Types.Int)
  Language/Haskell/Convert.hs:(64,5)-(65,42): Non-exhaustive patterns in function conv

  Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

It seems as if the pattern match failure from executing the template haskell function bubbled up too high and led to this (partially) misleading error message. It seems that this is indeed a bug, as such a failure should lead to a standard compile error instead of a GHC panic. I would expect something along the line:

  Exception during execution of template haskell splice `..splice code':
    ...explanation of the exception....

Best regards, Simon

[simonpj]

Ah, I see. Yes, that is a good point, thank you. I've changed the title.

Ian or Paolo, might you look at this (in TcSplice I think)?

Simon

[pcapriotti]

The problem is that in Convert.hs an exception is thrown containing another exception in the thunk of its message.

The attached patch fixes the problem by forcing complete evaluation of the error message within the exception handler.

A testcase demonstrating the problem is also attached.

[simonpj]

Thanks. Just to check, we could do the safeShowException thing unconditionally, couldn't we? It's not necesary to do the conditional in show_exn, is it?

Simon

[pcapriotti]

You're right, safeShowException can be used regardless. I simplified the patch. Ok to push?

[simonpj]

Yes, fine except

• I suggest you put the failWithTc part into mk_msg, renaming it failWithException or something.
• Can you add a Note [Concealed exceptions] in TcSplice that gives a concrete example (along the lines of the test case you added) of what the deal here is? In two years time we will have forgotten, and a concrete example is a huge help.

Then, go ahead and commit. Thanks.

[p.capriotti@…]

commit e7e5e277eb58a5ef6207200174e7982fdb9780bb

Author: Paolo Capriotti <p.capriotti@gmail.com>
Date:   Fri Mar 30 12:30:28 2012 +0100

    Prevent nested TH exceptions from bubbling up to the top level (#5976)

 compiler/typecheck/TcSplice.lhs |   29 ++++++++++++++++++++++++-----
 compiler/utils/Panic.lhs        |   14 +++++++++++++-
 2 files changed, 37 insertions(+), 6 deletions(-)

[pcapriotti]

Merged as 921a1d5def070bc91b300949a0e873f549c965ca.