Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Codegen bug: doesn't use qualified type in sqlType invocation #1475

Open
parsonsmatt opened this issue Feb 28, 2023 · 4 comments
Open

Codegen bug: doesn't use qualified type in sqlType invocation #1475

parsonsmatt opened this issue Feb 28, 2023 · 4 comments

Comments

@parsonsmatt
Copy link
Collaborator

This showed up in the migration to GHC 9.6 in our codebase. A type that should have been qualified was not. For some reason, GHC accepted this program with 9.4, but 9.6 it complained.

@parsonsmatt
Copy link
Collaborator Author

Huh - relevant code is here:

ftToType :: FieldType -> Type
ftToType = \case
    FTTypeCon Nothing t ->
        ConT $ mkName $ T.unpack t
    -- This type is generated from the Quasi-Quoter.
    -- Adding this special case avoids users needing to import Data.Int
    FTTypeCon (Just "Data.Int") "Int64" ->
        ConT ''Int64
    FTTypeCon (Just m) t ->
        ConT $ mkName $ unpack $ concat [m, ".", t]
    FTLit l ->
        LitT (typeLitToTyLit l)
    FTTypePromoted t ->
        PromotedT $ mkName $ T.unpack t
    FTApp x y ->
        ftToType x `AppT` ftToType y
    FTList x ->
        ListT `AppT` ftToType x

We are doing the qualification, but it's doing ConT (mkName (module . type)). I bet that's the bug - TH is changing how it reads that in.

@parsonsmatt
Copy link
Collaborator Author

parsonsmatt commented Feb 28, 2023

Upstream GHC issue. Weirdly enough, it doesn't happen in GHCi - all GHCs work fine 🤔

@alt-romes
Copy link

alt-romes commented Feb 28, 2023

I haven't been able to reproduce the issue, with the minimizer in the ghc's issue tracker, under any version.

However, "this special case avoids users needing to import Data.Int" doesn't sound quite right.
The following module compiles successfully

{-# LANGUAGE TemplateHaskell #-}
module A where

import Data.Int
import Language.Haskell.TH

import Data.Proxy

a :: Proxy $(conT (mkName "Data.Int.Int64"))
a = Proxy

, but if you remove the Data.Int import, we get the following error message, including in 9.4. I believe the user must import the module nonetheless.

blah.hs:8:13: error:
    • Not in scope: type constructor or class ‘Data.Int.Int64’
      NB: no module named ‘Data.Int’ is imported.
    • In the untyped splice: $(conT (mkName "Data.Int.Int64"))
  |
  | a :: Proxy $(conT (mkName "Data.Int.Int64"))

@parsonsmatt
Copy link
Collaborator Author

Yeah, it's a red herring - there's another spot in the code that's doing an unqualified mention.

Which makes me wonder how the 9.4 stuff ever worked 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants