Opened 5 years ago

Last modified 13 months ago

#5959 new bug

Top level splice in Template Haskell has over-ambitious lexical scope?

Reported by: mightybyte Owned by:
Priority: low Milestone:
Component: Template Haskell Version: 7.5
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Incorrect warning at compile-time Test Case: th/T5971
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


ghc: panic! (the 'impossible' happened)

(GHC version 7.4.1 for x86_64-unknown-linux):

nameModule b_a2PR{tv}

While working on this project I encountered a GHC panic. To reproduce, check out revision 6573d4359c5cb7699c931c44ebf1bf135099f83b (currently HEAD of the master branch), cabal install it, then go to the example directory and build with "ghc --make Site.hs".

This has caused the crash for me on two different Linux systems with GHC 7.4.1. I realize it requires building a large number of package dependencies, but I have no idea of how to construct a smaller test case. It should be pretty easy to build these dependencies with cabal or cabal-dev.

Attachments (1)

Lens.hs (595 bytes) - added by pcapriotti 5 years ago.
Minimal test case

Download all attachments as: .zip

Change History (17)

comment:1 Changed 5 years ago by simonmar

difficulty: Unknown
Milestone: 7.4.2
Priority: normalhigh

Thanks for the report.

comment:2 Changed 5 years ago by mightybyte

I played around with this a little more. First of all, I did some general work to the code in the snaplet-postgresql-simple code and the GHC panic still happens in the most recent code I've committed.

Secondly, the panic goes away and the app builds cleanly if I remove the existential on line 31 of example/Site.hs and use "App" instead of the type variable on line 34 (

With this in mind, I played around a little bit trying to create a minimal test case that demonstrates the problem, but thus far I've been unsuccessful.

Changed 5 years ago by pcapriotti

Attachment: Lens.hs added

Minimal test case

comment:3 Changed 5 years ago by pcapriotti

Here is a minimal test case that reproduces the problem on GHC HEAD.

comment:4 Changed 5 years ago by pcapriotti

Owner: set to pcapriotti

comment:5 Changed 5 years ago by pcapriotti

The problem here is when we have Exact names in what should be an implicit forall type. After TH splicing, we get

Lens app b_aIy

where b_aIy is an Exact name (out of scope). The renamer implicitly assumes that all exact names are in scope in a type signature, so the type checker panics.

The error here is actually in the Lens library, since it generates a type signature with incorrectly quantified type variables, when the record is existentially quantified. However, GHC should report a "type variable not in scope" error.

I'm not sure how this can fixed. The local renamer environment doesn't keep track of exact names, so there's no way it can determine whether a type variable with an Exact name is in scope or not. Maybe we should add exact names to the environment? Any other ideas?

comment:6 Changed 5 years ago by simonpj@…

commit cb5a3f2d66e4dac2f6f44f56e365d18df884c943

Author: Simon Peyton Jones <>
Date:   Wed Mar 28 09:57:57 2012 +0100

    Make the LocalRdrEnv keep track of all the Names that are in scope
    This allows us to give a sensible error message when a Template Haskell
    splice generates an occurrence without a binding site.
    Fixes Trac #5959 and #5971

 compiler/basicTypes/Name.lhs    |    2 +-
 compiler/basicTypes/RdrName.lhs |   36 +++++++++++++++++++++++++-----------
 compiler/rename/RnEnv.lhs       |   25 ++++++++++++++++++++++---
 compiler/rename/RnNames.lhs     |    6 +++---
 compiler/rename/RnTypes.lhs     |    2 +-
 5 files changed, 52 insertions(+), 19 deletions(-)

comment:7 Changed 5 years ago by simonpj

Test Case: th/T5971

New error message is:

    The exact Name `b_aUU' is not in scope
      Probable cause: you used a unique name (NameU) in Template Haskell but did not bind it

This isn't as good as the new message in #5971, which is

    The exact Name `x_aOV' is not in scope
      Probable cause: you used newName in Template Haskell but did not bind it
    In the result of the splice:
      $(newName "x" >>= varE)
    To see what the splice expanded to, use -ddump-splices
    In the expression: $(newName "x" >>= varE)
    In a pattern binding: _ = $(newName "x" >>= varE)

Sadly there is a reason that it's not quite as good in this case. In this case, #5959, there's a top-level declaration splice, which is renamed in a mutually recursive group with the declarations that follow. So this works:

$(f 4) -- Expands to:   h x = g (x-1)
g x = h x

So the splice expands to a declaration that uses the declarations that follow the splice.

I think it likely that this feature is never used, but it means that we can't wrap the helpful context info around when we rename the splice itself. Sigh.

I'm going to leave the ticket open for now... maybe it would be better to rename and typecheck the result of a top-level splice all by itself?

comment:8 Changed 5 years ago by pcapriotti

Owner: pcapriotti deleted
Type of failure: Compile-time crashIncorrect warning at compile-time

The fix for the crash is merged as 961b2e55e73db37daecea305505241b7e242eb87, so I'll re-milestone this ticket to 7.6.1.

comment:9 Changed 5 years ago by pcapriotti

Priority: highlow

comment:10 Changed 5 years ago by simonpj

Summary: GHC Panic: nameModuleTop level splice in Template Haskell has over-ambitious lexical scope?

Giving the ticket a better title.

comment:11 Changed 4 years ago by igloo


comment:12 Changed 3 years ago by thoughtpolice


Moving to 7.10.1.

comment:13 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:14 Changed 18 months ago by thoughtpolice


Milestone renamed

comment:15 Changed 17 months ago by thomie

Component: CompilerTemplate Haskell

To reproduce: download Lens.hs from comment:3, then run ghc Main.hs, with Main.hs containing:

{-# LANGUAGE ExistentialQuantification, TemplateHaskell #-}
import Lens

data App = forall b . App { _auth :: b }

makeLens ''App

main = return ()

The error message should be improved, see comment:7. With ghc-7.11.20150909 I get:

    The exact Name ‘b_a65q’ is not in scope
      Probable cause: you used a unique Template Haskell name (NameU), 
      perhaps via newName, but did not bind it
      If that's it, then -ddump-splices might be useful

comment:16 Changed 13 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.