Opened 2 years ago

Closed 2 years ago

#14080 closed bug (duplicate)

GHC panic while forcing the thunk for TyThing IsFile (regression)

Reported by: inaki Owned by:
Priority: high Milestone: 8.2.2
Component: Compiler Version: 8.2.1
Keywords: hs-boot Cc: ezyang
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case:
Blocked By: Blocking:
Related Tickets: #13803, #13981, #14382 Differential Rev(s):
Wiki Page:


Consider the following set of files:

-- A.hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeFamilies #-}

module A (AI(..)) where

import GHC.Exts (Constraint)

class AI (info :: *) where
    type S info :: * -> Constraint
-- C.hs
module C () where

import {-# SOURCE #-} qualified OC as OC
import {-# SOURCE #-} qualified OV as OV
-- IF.hs
module IF where

import qualified C as C
import {-# SOURCE #-} qualified OF as OF

class IsF o
-- IF.hs-boot
module IF where

class IsF o
-- OC.hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE EmptyDataDecls #-}

module OC () where

import A (AI(..))

data I
instance AI I where
    type S I = (~) ()
-- OC.hs-boot
module OC where
-- OF.hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE EmptyDataDecls #-}

module OF () where

import A (AI(..))

import {-# SOURCE #-} qualified IF as IF

data P
instance AI P where
    type S P = IF.IsF
-- OF.hs-boot
module OF where
-- OV.hs
module OV () where
-- OV.hs-boot
module OV where

This works with ghc-8.0.2 and earlier versions, but fails with ghc-8.2.1. When I run ghc IF for 8.2.1 I get

[ 1 of 10] Compiling A                ( A.hs, A.o )
[ 2 of 10] Compiling IF[boot]         ( IF.hs-boot, IF.o-boot )
[ 3 of 10] Compiling OC[boot]         ( OC.hs-boot, OC.o-boot )
[ 4 of 10] Compiling OC               ( OC.hs, OC.o )
[ 5 of 10] Compiling OF[boot]         ( OF.hs-boot, OF.o-boot )
[ 6 of 10] Compiling OF               ( OF.hs, OF.o )
[ 7 of 10] Compiling OV[boot]         ( OV.hs-boot, OV.o-boot )
[ 8 of 10] Compiling C                ( C.hs, C.o )
[ 9 of 10] Compiling IF               ( IF.hs, IF.o )
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.2.1 for x86_64-unknown-linux):
	tcIfaceGlobal (local): not found
  You are in a maze of twisty little passages, all alike.
  While forcing the thunk for TyThing IsF
  which was lazily initialized by initIfaceCheck typecheckLoop,
  I tried to tie the knot, but I couldn't find IsF
  in the current type environment.
  If you are developing GHC, please read Note [Tying the knot]
  and Note [Type-checking inside the knot].
  Consider rebuilding GHC with profiling for a better stack trace.
  Contents of current type environment: []
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
        pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface

Please report this as a GHC bug:

For context, this is a minimal testcase of the panic reported in #13803 for gi-gio, which persists after fixing the panic in the minimal testcase in ticket:13803#comment:9. (It seems like the original code was hitting more than one issue.)

Change History (12)

comment:1 Changed 2 years ago by RyanGlScott

Cc: ezyang added
Milestone: 8.2.2
Priority: normalhigh

comment:2 Changed 2 years ago by ezyang

Status: newinfoneeded

I can reproduce on 8.2.1, and I cannot reproduce on HEAD. I did test with my fix for #14075 so you may need to apply it (though I also tried with another random HEAD build I had lying around, and it was fine.)

comment:3 Changed 2 years ago by inaki

I just checked on HEAD, and the panic is not there anymore (with or without the fix to #14075). For the tip of the 8.2 branch, the panic is there with or without the fix to #14075.

Interestingly, the panic when building gi-gio originally reported in #13803 is gone in HEAD if I include the fix to #14075 (otherwise it is still present). This is great!

So I wonder if it is possible to backport to the 8.2 branch whatever fixed this in HEAD? Or alternatively, can you see any way of working around the panic reported above with 8.2?

comment:4 Changed 2 years ago by ezyang

The most relevant commit from me that might be how HEAD fixed it is 9e9fb57c37c62bb6c90f15b173c5d3632121c66a (but that is only because it is related to hs-boot things; it is hard to see how record wildcards is relevant to the example above). If this commit isn't the needed one, more sleuthing will be needed.

Last edited 2 years ago by ezyang (previous) (diff)

comment:5 Changed 2 years ago by inaki

That didn't work, unfortunately. If you have any other suggestion I would be glad to try, otherwise I will start bisecting...

comment:6 Changed 2 years ago by ezyang

I skimmed the commits but nothing popped out. I guess it's bisect time...

comment:7 Changed 2 years ago by inaki

I just finished bisecting, the commit that removes the panic is 69d9081d9fa3ff36fda36e4e11ef7e8f946ecf2a.

comment:8 Changed 2 years ago by ezyang

OK, that makes sense, but disappointingly, it may mean the underlying bug is still lurking, but under a different repro.

comment:9 Changed 2 years ago by inaki

That seems to be indeed the case. I cherry picked this commit (together with some related ones, as detailed in 13719#comment:8) into the 8.2 branch. This got rid of the issue reported here, but the original issue in #13803, ghc panicking when building gi-gio, is still there...

Sigh. Now I am not sure how to proceed. I can try to reduce the panic with the patches above applied to the 8.2 branch, and file yet another issue. Would that be the best way to proceed? Or should I reopen the original #13803?

In either case the whole process of reducing and bisecting is extremely time consuming, I would really appreciate some guidance (even if it is just a guess).

comment:10 Changed 2 years ago by ezyang

Thank you for the hard work inaki. Probably what is left to do now is someone (e.g., me) to do a full build with gi-gio and debug from there.

comment:11 Changed 2 years ago by _deepfire

Edward, this bug is marked infoneeded, which seems to put it in a dangerous category, but is it really warranted?

Sorry for meddling, just another worried user stuck on this.. : -)

comment:12 Changed 2 years ago by bgamari

Resolution: duplicate
Status: infoneededclosed

A dangerous category indeed. This was also reported as #14382.

Note: See TracTickets for help on using tickets.