Opened 2 years ago

Closed 2 years ago

#14075 closed bug (fixed)

GHC panic with parallel make

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 Differential Rev(s): Phab:D3815
Wiki Page:

Description

Consider the following modules:

-- F.hs

module F () where
-- F.hs-boot

module F where

import O (O)

newtype F = F ()
instance O F where
-- O.hs

module O (O) where

class O a where
-- V.hs

module V () where

import {-# SOURCE #-} F ()
-- V.hs-boot
module V where

If I try to compile this with

ghc -j2 F O V

I get

[1 of 4] Compiling O                ( O.hs, O.o )
[2 of 4] Compiling F[boot]          ( F.hs-boot, F.o-boot )
[3 of 4] Compiling F                ( F.hs, F.o )

<no location info>: error:
    ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.2.0.20170720 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 F
  which was lazily initialized by initIfaceCheck typecheckLoop,
  I tried to tie the knot, but I couldn't find F
  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:
    [r1hL :-> Identifier ‘$trModule’]
  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

On the other hand

ghc -j1 F O V

works just fine, and gives the expected

[2 of 5] Compiling O                ( O.hs, O.o )
[3 of 5] Compiling F[boot]          ( F.hs-boot, F.o-boot )
[4 of 5] Compiling F                ( F.hs, F.o )

F.hs-boot:7:1: error:
    ‘F.F’ is exported by the hs-boot file, but not exported by the module
  |
7 | newtype F = F ()
  | ^^^^^^^^^^^^^^^^

F.hs:1:1: error:
    instance O.O F.F -- Defined at F.hs-boot:8:10
      is defined in the hs-boot file, but not in the module itself
  |
1 | -- F.hs
  | ^

The example is a little bit sick, in that the original code is not expected to compile. I run into this by accident when trying to construct a minimal example of the issue reported in #13803 (note that that bug is marked as closed, but the original issue reported there remains unfixed, I am trying to construct a minimal testcase for the original issue there).

Change History (9)

comment:1 Changed 2 years ago by RyanGlScott

Cc: ezyang added
Milestone: 8.4.1
Priority: normalhigh

This is a regression from GHC 8.0.2:

$ /opt/ghc/8.0.2/bin/ghc -j2 -fforce-recomp F O V
[1 of 4] Compiling O                ( O.hs, O.o )
[2 of 4] Compiling F[boot]          ( F.hs-boot, F.o-boot )
[3 of 4] Compiling F                ( F.hs, F.o )

F.hs-boot:7:1: error:
    ‘F.F’ is exported by the hs-boot file, but not exported by the module

F.hs:1:1: error:
    instance O.O F.F -- Defined at F.hs-boot:8:10
      is defined in the hs-boot file, but not in the module itself

comment:2 Changed 2 years ago by bgamari

Milestone: 8.4.18.2.2

In that case let's perhaps try fixing this for 8.2.2.

comment:3 Changed 2 years ago by ezyang

Keywords: hs-boot added

comment:4 Changed 2 years ago by ezyang

In parallel mode I see:

Re-typechecking loop: [F, F]
compile: input file F.hs
*** Checking old interface for F (use -ddump-hi-diffs for more details):
[3 of 4] Compiling F                ( F.hs, F.o )

which is wrong wrong wrong; the retypecheck loop MUST NOT contain F (compare with non-parallel output; nothing needs to get retypechecked before we do F). So this is definitely a parallel specific bug. Workaround should be to not use parallel compilation.

comment:5 Changed 2 years ago by ezyang

Differential Rev(s): Phab:D3815
Status: newpatch

comment:6 Changed 2 years ago by Ben Gamari <ben@…>

In 4717ce86/ghc:

Fix incorrect retypecheck loop in -j (#14075)

The parallel codepath was incorrectly retypechecking the
hs-boot ModIface prior to typechecking the hs file,
which was inconsistent with the non-parallel case.  The
non-parallel case gets it right: you don't want to retypecheck
the hs-boot file itself (forwarding its declarations to hs)
because you need it to be consistently knot-tied with itself
when you compare the interfaces.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, simonpj, austin

Reviewed By: bgamari

Subscribers: duog, rwbarton, thomie

GHC Trac Issues: #14075

Differential Revision: https://phabricator.haskell.org/D3815

comment:7 Changed 2 years ago by bgamari

Status: patchmerge

comment:8 Changed 2 years ago by bgamari

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

comment:9 Changed 2 years ago by bgamari

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.