-fignore-interface-pragmas and -fspecialise do not go well together

changed weight to 5

Can you post a minimal program which triggers this panic? I'm unable to construct one from the little info on this ticket.

Sorry, I wrongly assumed this was much easier to reproduce. Now that I try, it appears to be pretty specific, in fact I can't even simplify properly. This still needs a dependency on aeson-1.2.1.0:

A.hs

{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DeriveDataTypeable #-}

module A where

import GHC.Generics

data Foo = AltChooserSimpleQuick
  deriving (Generic)

B.hs

{-# OPTIONS_GHC -fno-pre-inlining #-}
{-# OPTIONS_GHC -fspecialise #-}
{-# OPTIONS_GHC -fignore-interface-pragmas #-}

module B where

import A
import qualified Data.Aeson.Types as Aeson

instance Aeson.FromJSON Foo where
  parseJSON = Aeson.genericParseJSON Aeson.defaultOptions
  {-# NOINLINE parseJSON #-}

I have made several attempts to reproduce this with a standalone class instead of the one from aeson, but failed to do so. It also appears that the panic disappears when there is no orphan instance in play (i.e. if you merge modules A/B).

Also note that simply replacing data Foo = AltChooseSimpleQuick with data Foo = AltChoose the panic disappears. Further testing suggests that it requires any constructor identifier with at least 21 characters to trigger the panic.

And now that I noticed this 21 character relevance, perhaps producing a standalone testcase without aeson is possible. But maybe it depends on some other random length of some textual representation or whatever? In that case creating a reliable smaller testcase might be a challenge.

To make things more interesting, I can reproduce this panic on GHC 8.0.2, but not on 8.2.1.

closed

After reading the source code some more, I believe this was properly fixed in GHC 8.2. Specifically, in commit d49b2bb2 (Allow top-level string literals in Core (#8472 (closed))). That patch made the following change:

diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs
index c93a121..fb650f6 100644 (file)
--- a/compiler/coreSyn/CorePrep.hs
+++ b/compiler/coreSyn/CorePrep.hs
@@ -1168,7 +1168,9 @@ deFloatTop (Floats _ floats)
   = foldrOL get [] floats
   where
     get (FloatLet b) bs = occurAnalyseRHSs b : bs
-    get b            _  = pprPanic "corePrepPgm" (ppr b)
+    get (FloatCase var body _) bs  =
+      occurAnalyseRHSs (NonRec var body) : bs
+    get b _ = pprPanic "corePrepPgm" (ppr b)
 
     -- See Note [Dead code in CorePrep]
     occurAnalyseRHSs (NonRec x e) = NonRec x (occurAnalyseExpr_NoBinderSwap e)

Before, get was being called on a FloatCase, which is the only constructor that could have given the output [True] $s$fSelectorMetaMetaSel_a = "_dconf_dump_annotations"#. But now that this case is covered properly, the issue appears to have gone away. So I'll opt to close this issue, since I can't reproduce the problem on 8.2, and coming up with a minimal regression test doesn't seem feasible.

Please feel free to re-open the issue if you come across the same panic on GHC 8.2 or later.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

thanks for looking into this!

added compiler crash label

added Pnormal label

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

-fignore-interface-pragmas and -fspecialise do not go well together

Child items 0

Activity