Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#12130 closed bug (fixed)

ghc: panic! (the 'impossible' happened): find_tycon Block []

Reported by: jeiea Owned by: adamgundry
Priority: high Milestone: 8.0.2
Component: Template Haskell Version: 8.0.1
Keywords: DisambiguateRecordFields Cc: adamgundry
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case: th/T12130
Blocked By: Blocking:
Related Tickets: #11228 Differential Rev(s): Phab:D2321
Wiki Page:


I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to $(widgetFile ...) yesod template haskell clause.

It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell).

~/yt> stack build
yt-0.0.0: configure
Configuring yt-0.0.0...
yt-0.0.0: build
Preprocessing library yt-0.0.0...
[1 of 9] Compiling Settings         ( Settings.hs, .stack-work/dist/x86_64-linux/Cabal- )
[2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack-work/dist/x86_64-linux/Cabal- )
[3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack-work/dist/x86_64-linux/Cabal- )
[4 of 9] Compiling Foundation       ( Foundation.hs, .stack-work/dist/x86_64-linux/Cabal- )
[5 of 9] Compiling Import           ( Import.hs, .stack-work/dist/x86_64-linux/Cabal- )
[6 of 9] Compiling Handler.Common   ( Handler/Common.hs, .stack-work/dist/x86_64-linux/Cabal- )
[7 of 9] Compiling Handler.Home     ( Handler/Home.hs, .stack-work/dist/x86_64-linux/Cabal- )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-unknown-linux):

Please report this as a GHC bug:

Completed 179 action(s).

--  While building package yt-0.0.0 using:
      /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal- --builddir=.stack-work/dist/x86_64-linux/Cabal- build lib:yt exe:yt --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

Attachments (1) (125.1 KB) - added by jeiea 3 years ago.

Download all attachments as: .zip

Change History (10)

Changed 3 years ago by jeiea

Attachment: added

comment:1 Changed 3 years ago by thomie

Cc: adamgundry added
Keywords: DisambiguateRecordFields added
Priority: normalhigh

Regression from 7.10. Here is a reproducer:


{-# Language TemplateHaskell #-}
{-# Language DisambiguateRecordFields #-}
-- DisambiguateRecordFields (or RecordWildCards) is necessary
-- to trigger the bug.

module A where

import B hiding (Block)  -- Hiding "Block" is necessary to trigger the bug.

b = $(block)

ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-unknown-linux):


{-# LANGUAGE TemplateHaskell #-}

module B where

import Language.Haskell.TH

data Block = Block
    { blockSelector :: ()

block :: Q Exp
block =
    [| Block {
         -- Using record syntax is neccesary to trigger the bug.
         blockSelector = ()

CC adamgundry, as he was the last to touch find_tycon.

The discussion in ticket:11228#comment:4 seems relevant.

comment:2 Changed 3 years ago by thomie

Milestone: 8.0.2

comment:3 Changed 3 years ago by adamgundry

Differential Rev(s): Phab:D2321
Status: newpatch
Test Case: th/T12130

Thanks for the great test case!

It turns out this bug was lingering already in 7.10, but laziness meant we didn't hit the panic by sheer luck. Simple fix: replace the panic with Nothing, which is reasonable in this context: if the datacon isn't in scope, don't use it for disambiguating record fields.

comment:4 Changed 3 years ago by adamgundry

Owner: set to adamgundry

comment:5 Changed 3 years ago by Ben Gamari <ben@…>

In 4d71cc89/ghc:

Avoid find_tycon panic if datacon is not in scope

When using TH to splice expressions involving record field construction,
the parent datacon may not be in scope.  We shouldn't panic about this,
because we will be renaming Exact RdrNames which don't require any

Test Plan: new test th/T12130

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision:

GHC Trac Issues: #12130

comment:6 Changed 3 years ago by bgamari

Status: patchmerge

Seems like a good candidate for 8.0.2.

comment:7 Changed 3 years ago by Simon Peyton Jones <simonpj@…>

In 2f8cd14/ghc:

Narrow the use of record wildcards slightly

In reviewing the fix to Trac #12130 I found the wild-card
fill-in code for ".." notation in record constructions hard
to understand.  It went to great contortions (including the
find_tycon code) to allow
    data T = C { x, y :: Int }
    f x = C { .. }
to expand to
    f x = C { x = x, y = y }
where 'y' is an /imported function/!  That seems way over the top
for what record wildcards are supposed to do.

So I have narrowed the record-wildcard expansion to include only
/locally-bound/ variables; i.e. not top level, and certainly not

I don't think anyone is using record wildcards in this bizarre way, so
I don't expect any fallout. Even if there is, you can easily
initialise fields with eponymous but imported values by hand.

An intermediate position would be to allow /local/ top-level
definitions.  But I doubt anyone is doing that either.

Let's see if there's any fallout.  It's a local change, easy to
revert, so I've just gone ahead to save everyone's time.

comment:8 Changed 3 years ago by bgamari

Resolution: fixed
Status: mergeclosed
Last edited 2 years ago by bgamari (previous) (diff)

comment:9 Changed 2 years ago by spl

For others who happen upon this problem with GHC 8.0.1, I've used the following workaround.

In each module where the error occurs, add {-# LANGUAGE NoDisambiguateRecordFields NoRecordWildCards #-} and remove all uses of disambiguated fields and record wildcards from that module.

Note: See TracTickets for help on using tickets.