Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,252
    • Issues 4,252
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 397
    • Merge Requests 397
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #18263

Closed
Open
Opened May 29, 2020 by Luke Lau@lukeDeveloper

Erroneous "The exact Name ‘foo’ is not in scope" error in Template Haskell

Summary

When reifying in the example below

{-# LANGUAGE TemplateHaskell #-}
module TH_reifyNewName where

import Language.Haskell.TH
import Language.Haskell.TH.Syntax

do
  n <- newName "x"
  addModFinalizer $ reify n >>= runIO . print
  [d| $(varP n) = 42 |]

GHC spits out two errors

The exact Name ‘x_aFi’ 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

and

    ‘x’ is not in the type environment at a reify

As noted in #12249, the first error message is bogus – the name x actually is in scope. This is ultimately caused by lookupGlobalOccRn_maybe adding an error, when it looks like it shouldn't be (a comment above it claims that it should never fail)

Expected behavior

We would expect just to have the one error here about x not being in the type environment.

Environment

  • GHC version used: ghc-HEAD
Edited May 29, 2020 by Luke Lau
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#18263