Opened 23 months ago

Last modified 22 months ago

#14382 new bug

The 'impossible' happened whilst installing gi-gtk via cabal

Reported by: maartenjacobs Owned by:
Priority: high Milestone: 8.2.3
Component: Compiler Version: 8.2.1
Keywords: gtk, pango, hs-boot Cc: inaki
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary.

...
[91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o )
ghc: 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 Layout
  which was lazily initialized by initIfaceCheck typecheckLoop,
  I tried to tie the knot, but I couldn't find Layout
  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:  http://www.haskell.org/ghc/reportabug

Failed to install gi-pango-1.0.15
cabal: Error: some packages failed to install:
gi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to
install.
gi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to
install.
gi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The
exception was:
ExitFailure 1

Change History (12)

comment:1 Changed 23 months ago by simonpj

Can anyone reproduce with 8.2.2? gtk is notoriously difficult to compile.

comment:2 Changed 23 months ago by bgamari

I'm trying.

comment:3 Changed 23 months ago by bgamari

Sadly I am indeed able to reproduce this with 8.2.2.

comment:4 Changed 23 months ago by simonpj

I have no idea how to reproduce this.

bash$ cabal unpack gi-pango-1.0.15
bash$ cd gi-pango-1.0.15
bash$ cabal install --with-ghc=/home/simonpj/5builds/ghc-8.2-branch/inplace/bin/ghc-stage2
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: gi-pango-1.0.15 (user goal)
next goal: haskell-gi (dependency of gi-pango-1.0.15)
rejecting: haskell-gi-0.20.3, haskell-gi-0.20.2, haskell-gi-0.20.1 (conflict:
requires pkg-config package gobject-introspection-1.0>=1.32, not found in the
pkg-config database)
rejecting: haskell-gi-0.20, haskell-gi-0.18, haskell-gi-0.17.4,
haskell-gi-0.17.3, haskell-gi-0.17.2, haskell-gi-0.17.1, haskell-gi-0.17,
haskell-gi-0.15, haskell-gi-0.14, haskell-gi-0.13, haskell-gi-0.12,
haskell-gi-0.11, haskell-gi-0.10.2, haskell-gi-0.10.1, haskell-gi-0.10,
haskell-gi-0.9, haskell-gi-0.8 (conflict: gi-pango => haskell-gi>=0.20.1 &&
<1)
Dependency tree exhaustively searched.

Moreover there seem be no source files.

Try building compiler with -DDEBUG and add HasDebugCallStack to tcIfaceGlobal.

In the panic in tcIfaceGlobal get hold of the if_loc field of the IfLclEnv and add that to the error message.

comment:5 Changed 23 months ago by bgamari

Alright, so I managed to reproduce this on HEAD as well. The call stack looks like,

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.3.20171026 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 IsFile
  which was lazily initialized by initIfaceCheck typecheckLoop,
  I tried to tie the knot, but I couldn't find IsFile
  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.
  This little catastrophe occurred while compiling GI.Gio.Interfaces.File
  Contents of current type environment: []
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable
        pprPanic, called at compiler/iface/TcIface.hs:1717:23 in ghc:TcIface
        tcIfaceGlobal, called at compiler/iface/TcIface.hs:1775:19 in ghc:TcIface
        tcIfaceTyCon, called at compiler/iface/TcIface.hs:1275:21 in ghc:TcIface
        tcIfaceType, called at compiler/iface/TcIface.hs:878:17 in ghc:TcIface
        tc_ax_branch, called at compiler/iface/TcIface.hs:866:37 in ghc:TcIface
        tc_ax_branches, called at compiler/iface/TcIface.hs:819:25 in ghc:TcIface
        tc_iface_decl, called at compiler/iface/TcIface.hs:640:15 in ghc:TcIface
        tcIfaceDecl, called at compiler/iface/LoadIface.hs:681:37 in ghc:LoadIface

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

Moreover, I was able to pare down the affected module quite far. Replacing the following modules from gi-gio-2.0.14 as follows still reproduces the issue,

-- GI/Gio/Interfaces/File.hs-boot
module GI.Gio.Interfaces.File where                                                                 
                                                                                                    
import qualified GI.Gio.Callbacks as Gio.Callbacks                                                  
import {-# SOURCE #-} qualified GI.Gio.Objects.FileEnumerator as Gio.FileEnumerator                 
import {-# SOURCE #-} qualified GI.Gio.Structs.FileAttributeInfoList as Gio.FileAttributeInfoList   
                                                                                                    
class GObject o => IsFile o


-- GI/Gio/Structs/FileAttributeInfoList.hs-boot
module GI.Gio.Structs.FileAttributeInfoList where            
-- This page intentionally left blank


-- GI/Gio/Objects/FileEnumerator.hs-boot
module GI.Gio.Objects.FileEnumerator where                               
-- This page intentionally left blank

Every line of this seems to be important; removing any one eliminates the panic.

I have a repro but it's quite involved. I'm going to try to reduce it further before trying to explain it.

Last edited 23 months ago by bgamari (previous) (diff)

comment:6 Changed 23 months ago by bgamari

I just noticed that comment:5 describes a different failure point from what the original reporter saw. There seems to be something odd going on in the haskell-gi package more generally.

I'm still trying to pin down the specific cause of this, but I suspect the fact that the package has a densely-connected set of hs-boot files is central to the issue.

comment:7 Changed 23 months ago by simonpj

May well be connected to #14396 (which is a much simpler case)

comment:8 Changed 23 months ago by simonpj

Keywords: hs-boot added

comment:9 Changed 23 months ago by bgamari

Milestone: 8.2.3
Priority: normalhigh

It turns out that this was also reported as #14080.

Unfortunately we won't be able to fix this for 8.2.2.

comment:10 Changed 23 months ago by inaki

Cc: inaki added

comment:11 Changed 23 months ago by ezyang

Can you please try https://phabricator.haskell.org/D4138 with this bug? It may address the problem here.

comment:12 Changed 22 months ago by bgamari

This may have been fixed by 6998772043a7f0b0360116eb5ffcbaa5630b21fb.

Note: See TracTickets for help on using tickets.