-
Notifications
You must be signed in to change notification settings - Fork 297
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
Comments
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 |
Upstream GHC issue. Weirdly enough, it doesn't happen in GHCi - all GHCs work fine 🤔 |
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. {-# 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
|
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 🤔 |
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.
The text was updated successfully, but these errors were encountered: