Opened 3 years ago

Last modified 9 months ago

#5959 new bug

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

Reported by: mightybyte Owned by:
Priority: low Milestone: 7.12.1
Component: Compiler 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 Revisions:

Description

ghc: panic! (the 'impossible' happened)

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

nameModule b_a2PR{tv}

While working on this project https://github.com/mightybyte/snaplet-postgresql-simple 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 3 years ago.
Minimal test case

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Milestone set to 7.4.2
  • Priority changed from normal to high

Thanks for the report.

comment:2 Changed 3 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 (https://github.com/mightybyte/snaplet-postgresql-simple/blob/master/example/Site.hs).

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 3 years ago by pcapriotti

Minimal test case

comment:3 Changed 3 years ago by pcapriotti

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

comment:4 Changed 3 years ago by pcapriotti

  • Owner set to pcapriotti

comment:5 Changed 3 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 3 years ago by simonpj@…

commit cb5a3f2d66e4dac2f6f44f56e365d18df884c943

Author: Simon Peyton Jones <[email protected]>
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 3 years ago by simonpj

  • Test Case set to th/T5971

New error message is:

T5959.hs:8:1:
    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

T5971.hs:6:7:
    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 3 years ago by pcapriotti

  • Milestone changed from 7.4.2 to 7.6.1
  • Owner pcapriotti deleted
  • Type of failure changed from Compile-time crash to Incorrect warning at compile-time
  • Version changed from 7.4.1 to 7.5

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

comment:9 Changed 3 years ago by pcapriotti

  • Priority changed from high to low

comment:10 Changed 3 years ago by simonpj

  • Summary changed from GHC Panic: nameModule to Top level splice in Template Haskell has over-ambitious lexical scope?

Giving the ticket a better title.

comment:11 Changed 3 years ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:12 Changed 14 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.10.1

Moving to 7.10.1.

comment:13 Changed 9 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

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.

Note: See TracTickets for help on using tickets.