Skip to content

`TemplateHaskell` bug/behavior change in GHC 9.6 wrt qualified names

Summary

Between GHC 9.4 and GHC HEAD, a change has occurred with how TemplateHaskell handles mkName with a qualified input.

This persistent issue documents the problem on persistent's side, but it was encountered while checking that our codebase can build with GHC HEAD.

Briefly, we have a function ftToType :: FieldType -> Type, which has this case:

    FTTypeCon (Just m) t ->
        ConT $ mkName $ unpack $ concat [m, ".", t]

This would evaluate FTTypeCon (Just "Foo") "Bar" to ConT (mkName "Foo.Bar"). In GHC 9.4, this creates a qualified reference in the generated source code. However, in GHC HEAD, this appears to omit the qualification - the generated code has a bare reference to Bar.

Steps to reproduce

GHCi, version 9.4.3: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/matt/.dotfiles/haskell/ghci.symlink
Loaded GHCi configuration from /tmp/haskell-stack-ghci/2a3bbd58/ghci-script
λ> import qualified Data.Int as Int
λ> import Language.Haskell.TH
λ> :set -XTemplateHaskell
λ> import Data.Proxy
λ> Proxy :: Proxy $(conT (mkName "Int.Int64"))
Proxy
λ> :t Proxy :: Proxy $(conT (mkName "Int.Int64"))
Proxy :: Proxy $(conT (mkName "Int.Int64")) :: Proxy Int.Int64

I don't have a GHC 9.6 on my machine, but I'll ask a coworker real quick - and, uh, unfortunately, it appears to give identical results with GHC 9.6 alpha 3 and GHC 9.7 HEAD. So something more mysterious is afoot.

I'll come back to this.

Expected behavior

What do you expect the reproducer described above to do?

Environment

  • GHC version used:

Optional:

  • Operating System:
  • System Architecture:
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information