Skip to content

Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble

64 bit GHC has 64 bit Unique values, but they don't fit in a template-haskell NameU when cross-compiling to a 32 bit target.

In theory we can support Template Haskell in this situation with -fexternal-interpreter (and the earlier GHCJS implementation), but when the target cannot represent GHC's uniques in an Int, things go wrong:

from Language.Haskell.TH.Syntax:

type Uniq = Int

I think we can fix this for now by changing the synonym to type Uniq = Int64 (or even type Uniq = Integer), making the template-haskell Uniq at least as big as the GHC Unique in practice. This requires a change in DsMeta.

the uses of Int below should really be changed to Uniq

data NameFlavour
  = NameS           -- ^ An unqualified name; dynamically bound
  | NameQ ModName   -- ^ A qualified name; dynamically bound
  | NameU !Int      -- ^ A unique local name
  | NameL !Int      -- ^ Local name bound outside of the TH AST
  | NameG NameSpace PkgName ModName -- ^ Global name bound outside of the TH AST:
                -- An original name (occurrences only, not binders)
                -- Need the namespace too to be sure which
                -- thing we are naming
  deriving ( Data, Eq, Ord, Show, Generic )
-- Global variable to generate unique symbols
counter :: IORef Int
{-# NOINLINE counter #-}
counter = unsafePerformIO (newIORef 0)
Trac metadata
Trac field Value
Version 8.3
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information