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 |