GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:03:47Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15601Unexpected compile error on type level lists with a single element2019-07-07T18:03:47ZerikdUnexpected compile error on type level lists with a single elementTried this with ghc 8.0.2, 8.2.2 and 8.4.3 and all give an almost identical error on the following piece of code:
```hs
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeOpe...Tried this with ghc 8.0.2, 8.2.2 and 8.4.3 and all give an almost identical error on the following piece of code:
```hs
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE CPP #-}
{-# OPTIONS_GHC -Wall #-}
import Data.Singletons.Prelude.List
#if MIN_VERSION_singletons(2,4,0)
type (a :++ b) = a ++ b
#endif
data MyType = A | B | C | D | E | F
type TypeList1 = ['A, 'B]
type TypeList2 = TypeList1 :++ ['C, 'D]
-- Everything above is fine, but this line:
type TypeList3 = TypeList2 :++ ['F]
-- Gives the error:
--
-- type-level-list.hs:21:32: error:
-- • Expected kind ‘[MyType]’, but ‘[ 'F]’ has kind ‘*’
-- • In the second argument of ‘(:++)’, namely ‘[ 'F]’
-- In the type ‘TypeList2 :++ [ 'F]’
-- In the type declaration for ‘TypeList3’
-- |
-- 22 | type TypeList3 = TypeList2 :++ ['F]
-- If instead I write it like:
type TypeList4 = TypeList2 :++ '[F]
-- I get the warning:
--
-- type-level-list.hs:33:34: warning: [-Wunticked-promoted-constructors]
-- Unticked promoted constructor: ‘F’.
-- Use ‘'F’ instead of ‘F’.
-- The following actually seems to work, but I don't understand why type level
-- lists containing only one element are different.
type TypeList5 = TypeList2 :++ '[ 'F]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpected compile error on type level lists with a single element","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tried this with ghc 8.0.2, 8.2.2 and 8.4.3 and all give an almost identical error on the following piece of code:\r\n{{{#!hs\r\n\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE CPP #-}\r\n\r\n{-# OPTIONS_GHC -Wall #-}\r\n\r\nimport Data.Singletons.Prelude.List\r\n\r\n#if MIN_VERSION_singletons(2,4,0)\r\ntype (a :++ b) = a ++ b\r\n#endif\r\n\r\ndata MyType = A | B | C | D | E | F\r\n\r\ntype TypeList1 = ['A, 'B]\r\n\r\ntype TypeList2 = TypeList1 :++ ['C, 'D]\r\n\r\n-- Everything above is fine, but this line:\r\ntype TypeList3 = TypeList2 :++ ['F]\r\n-- Gives the error:\r\n--\r\n-- type-level-list.hs:21:32: error:\r\n-- • Expected kind ‘[MyType]’, but ‘[ 'F]’ has kind ‘*’\r\n-- • In the second argument of ‘(:++)’, namely ‘[ 'F]’\r\n-- In the type ‘TypeList2 :++ [ 'F]’\r\n-- In the type declaration for ‘TypeList3’\r\n-- |\r\n-- 22 | type TypeList3 = TypeList2 :++ ['F]\r\n\r\n-- If instead I write it like:\r\ntype TypeList4 = TypeList2 :++ '[F]\r\n-- I get the warning:\r\n--\r\n-- type-level-list.hs:33:34: warning: [-Wunticked-promoted-constructors]\r\n-- Unticked promoted constructor: ‘F’.\r\n-- Use ‘'F’ instead of ‘F’.\r\n\r\n-- The following actually seems to work, but I don't understand why type level \r\n-- lists containing only one element are different.\r\ntype TypeList5 = TypeList2 :++ '[ 'F]\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15600Bug while writing a simple parser with Parsec2019-07-07T18:03:48ZroehstBug while writing a simple parser with Parsec```hs
module Main where
import Control.Monad.Identity
import Control.Monad.State
import Data.List
import Text.ParserCombinators.Parsec
type Name = String
data Value = VlInt Int | VlBool Bool deriving Show
data Term =
TmVal Value
...```hs
module Main where
import Control.Monad.Identity
import Control.Monad.State
import Data.List
import Text.ParserCombinators.Parsec
type Name = String
data Value = VlInt Int | VlBool Bool deriving Show
data Term =
TmVal Value
| TmVar Name
| TmLet Name Term Term
| TmAdd Term Term
deriving Show
parseTerm :: Parser Term
parseTerm = parseVal <|> parseVar <|> parseLet <|> parseAdd
```
And then I get:
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
\[1 of 1\] Compiling Main ( Main.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
initTc: unsolved constraints
WC {wc_insol =
<table><tr><th>\[W\] parseVal_a2YR </th>
<td>t_a2YQ\[tau:1\] (CHoleCan: parseVal)</td></tr>
<tr><th>\[W\] parseVar_a2YY </th>
<td>t_a2YX\[tau:1\] (CHoleCan: parseVar)</td></tr>
<tr><th>\[W\] parseLet_a2Z5 </th>
<td>t_a2Z4\[tau:1\] (CHoleCan: parseLet)</td></tr>
<tr><th>\[W\] parseAdd_a2Z8 </th>
<td>t_a2Z7\[tau:1\] (CHoleCan: parseAdd)}</td></tr></table>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug while writing a simple parser with Parsec","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nmodule Main where\r\n\r\nimport Control.Monad.Identity\r\nimport Control.Monad.State\r\nimport Data.List\r\nimport Text.ParserCombinators.Parsec\r\n\r\ntype Name = String\r\n\r\ndata Value = VlInt Int | VlBool Bool deriving Show\r\n\r\ndata Term =\r\n TmVal Value\r\n | TmVar Name\r\n | TmLet Name Term Term\r\n | TmAdd Term Term\r\n deriving Show\r\n\r\nparseTerm :: Parser Term\r\nparseTerm = parseVal <|> parseVar <|> parseLet <|> parseAdd\r\n}}}\r\n\r\nAnd then I get:\r\n\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( Main.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n initTc: unsolved constraints\r\n WC {wc_insol =\r\n [W] parseVal_a2YR :: t_a2YQ[tau:1] (CHoleCan: parseVal)\r\n [W] parseVar_a2YY :: t_a2YX[tau:1] (CHoleCan: parseVar)\r\n [W] parseLet_a2Z5 :: t_a2Z4[tau:1] (CHoleCan: parseLet)\r\n [W] parseAdd_a2Z8 :: t_a2Z7[tau:1] (CHoleCan: parseAdd)}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15595Stack overflow in withArgs leads to infinite memory-consuming loop2019-07-07T18:03:58ZNeil MitchellStack overflow in withArgs leads to infinite memory-consuming loopGiven the program:
```hs
import System.Environment
main :: IO ()
main = do
putStrLn "Starting"
withArgs (replicate 1000 "") $ return ()
```
When run with:
```
ghc --make WithArgsBug.hs -rtsopts && WithArgsBug +RTS -K1K
```
T...Given the program:
```hs
import System.Environment
main :: IO ()
main = do
putStrLn "Starting"
withArgs (replicate 1000 "") $ return ()
```
When run with:
```
ghc --make WithArgsBug.hs -rtsopts && WithArgsBug +RTS -K1K
```
The program prints out "Starting", then loops forever, taking 1 CPU core and allocating memory (approx 1Gb per min), until the computer is unresponsive. The program does not respond to Ctrl-C and has to be killed from the task manager.
The `-K1K` flag limits the stack to approx 33Kb.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stack overflow in withArgs leads to infinite memory-consuming loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Given the program:\r\n\r\n{{{#!hs\r\nimport System.Environment\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn \"Starting\"\r\n withArgs (replicate 1000 \"\") $ return ()\r\n}}}\r\n\r\nWhen run with:\r\n\r\n{{{\r\nghc --make WithArgsBug.hs -rtsopts && WithArgsBug +RTS -K1K\r\n}}}\r\n\r\nThe program prints out \"Starting\", then loops forever, taking 1 CPU core and allocating memory (approx 1Gb per min), until the computer is unresponsive. The program does not respond to Ctrl-C and has to be killed from the task manager.\r\n\r\nThe {{{-K1K}}} flag limits the stack to approx 33Kb.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15594--abi-hash with Backpack incorrectly loads modules from dependent packages2020-09-28T07:11:37ZEdward Z. Yang--abi-hash with Backpack incorrectly loads modules from dependent packagesRepro at: https://github.com/alexbiehl/cabal-backpack-register-repro
If you use Backpack with data families, you might fail during `--abi-hash` with:
```
cabal:
'/nix/store/m338klajhqlw7v4jd61fiqd82wx305fj-ghc-8.4.3-with-packages/bin/g...Repro at: https://github.com/alexbiehl/cabal-backpack-register-repro
If you use Backpack with data families, you might fail during `--abi-hash` with:
```
cabal:
'/nix/store/m338klajhqlw7v4jd61fiqd82wx305fj-ghc-8.4.3-with-packages/bin/ghc'
exited with an error:
Failed to load interface for ‘Stuff’
no unit id matching ‘backpack-trans-0.1.0.0-L6CFTQZAAWWFpCQD2NXR4W-indef’ was
found
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15593QuantifiedConstraints: trouble with type family2019-07-07T18:03:59ZIcelandjackQuantifiedConstraints: trouble with type family```hs
{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances #-}
import Data.Kind
data TreeF a b = T0 | T1 a | T2 b b
-- from Data.Reify
class MuRef (a :: Type) where
type DeRef a :: Type -> Type
class ...```hs
{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances #-}
import Data.Kind
data TreeF a b = T0 | T1 a | T2 b b
-- from Data.Reify
class MuRef (a :: Type) where
type DeRef a :: Type -> Type
class (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree
instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree
```
fails with
```
$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 351.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 351.hs, interpreted )
351.hs:12:10: error:
• Couldn't match type ‘DeRef (tree xx)’ with ‘TreeF xx’
arising from the superclasses of an instance declaration
• In the instance declaration for ‘MuRef1 tree’
|
12 | instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
Prelude>
```
----
What I want to write:
```hs
{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes #-}
import Data.Kind
-- from Data.Reify
class MuRef (a :: Type) where
type DeRef a :: Type -> Type
type T = Type
type TT = T -> T
type TTT = T -> TT
class (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT)
instance (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT)
```
where I am trying to capture [MuRef1 & DeRef1](https://hackage.haskell.org/package/folds-0.7.4/docs/src/Data-Fold-Internal.html)
```hs
class MuRef1 (f :: TT) where
type DeRef1 f :: TTT
muRef1 :: proxy (f a) -> Dict (MuRef (f a), DeRef (f a) ~ DeRef1 f a)
```
----
Workarounds: I think splitting the class alias & quantification does the job (I haven't tested it but it compiles), I want to know if the first two programs are meant to compile or not
```hs
{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes, FlexibleContexts #-}
-- ..
class (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx
instance (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx
class (forall xx. cls xx) => Forall cls
instance (forall xx. cls xx) => Forall cls
class Forall (MuRef1_ f deRef1) => MuRef1 f deRef1
instance Forall (MuRef1_ f deRef1) => MuRef1 f deRef1
```
or as a regular type/constraint synonym (at the loss of partial application)
```hs
type MuRef1 f deRef1 = (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: trouble with type family","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["ConstraintKinds","QuantifiedConstraints,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances #-}\r\n\r\nimport Data.Kind\r\n\r\ndata TreeF a b = T0 | T1 a | T2 b b\r\n\r\n-- from Data.Reify\r\nclass MuRef (a :: Type) where\r\n type DeRef a :: Type -> Type\r\n\r\nclass (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree\r\ninstance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree\r\n}}}\r\n\r\nfails with\r\n\r\n{{{\r\n$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 351.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 351.hs, interpreted )\r\n\r\n351.hs:12:10: error:\r\n • Couldn't match type ‘DeRef (tree xx)’ with ‘TreeF xx’\r\n arising from the superclasses of an instance declaration\r\n • In the instance declaration for ‘MuRef1 tree’\r\n |\r\n12 | instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\n----\r\n\r\nWhat I want to write:\r\n\r\n{{{#!hs\r\n{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes #-}\r\n\r\nimport Data.Kind\r\n\r\n-- from Data.Reify\r\nclass MuRef (a :: Type) where\r\n type DeRef a :: Type -> Type\r\n\r\ntype T = Type\r\ntype TT = T -> T\r\ntype TTT = T -> TT\r\n\r\nclass (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT)\r\ninstance (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT)\r\n}}}\r\n\r\nwhere I am trying to capture [https://hackage.haskell.org/package/folds-0.7.4/docs/src/Data-Fold-Internal.html MuRef1 & DeRef1]\r\n\r\n{{{#!hs\r\nclass MuRef1 (f :: TT) where\r\n type DeRef1 f :: TTT\r\n muRef1 :: proxy (f a) -> Dict (MuRef (f a), DeRef (f a) ~ DeRef1 f a)\r\n}}}\r\n\r\n----\r\n\r\nWorkarounds: I think splitting the class alias & quantification does the job (I haven't tested it but it compiles), I want to know if the first two programs are meant to compile or not\r\n\r\n{{{#!hs\r\n{-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes, FlexibleContexts #-}\r\n\r\n-- ..\r\n\r\nclass (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx\r\ninstance (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx\r\n\r\nclass (forall xx. cls xx) => Forall cls\r\ninstance (forall xx. cls xx) => Forall cls\r\n\r\nclass Forall (MuRef1_ f deRef1) => MuRef1 f deRef1\r\ninstance Forall (MuRef1_ f deRef1) => MuRef1 f deRef1\r\n}}}\r\n\r\nor as a regular type/constraint synonym (at the loss of partial application)\r\n\r\n{{{#!hs\r\ntype MuRef1 f deRef1 = (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15590Existentials in newtypes2019-07-07T18:04:00ZNioBiumExistentials in newtypesPlease allow existential quantification of phantom type arguments in newtypes.
```
type role A nominal representational phantom -- Or inferred roles.
newtype B a b where
B :: A a b c -> B a b
```
<details><summary>Trac metadata</su...Please allow existential quantification of phantom type arguments in newtypes.
```
type role A nominal representational phantom -- Or inferred roles.
newtype B a b where
B :: A a b c -> B a b
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Existentials in newtypes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Please allow existential quantification of phantom type arguments in newtypes.\r\n\r\n{{{\r\ntype role A nominal representational phantom -- Or inferred roles.\r\nnewtype B a b where \r\n B :: A a b c -> B a b \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15589Always promoting metavariables during type inference may be wrong2019-07-07T18:04:00ZRichard Eisenbergrae@richarde.devAlways promoting metavariables during type inference may be wrongCurrently, when checking a type signature, GHC promotes all the metavariables that arise during checking as soon as it's done checking the signature. This may be incorrect sometimes.
Consider
```hs
{-# LANGUAGE ScopedTypeVariables, Typ...Currently, when checking a type signature, GHC promotes all the metavariables that arise during checking as soon as it's done checking the signature. This may be incorrect sometimes.
Consider
```hs
{-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies,
AllowAmbiguousTypes #-}
import Data.Proxy
import Data.Type.Equality
import Data.Type.Bool
import Data.Kind
data SameKind :: forall k. k -> k -> Type
type family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where
IfK (_ :: Proxy True) f _ = f
IfK (_ :: Proxy False) _ g = g
y :: forall (cb :: Bool) (c :: Proxy cb). cb :~: True -> ()
y Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d
x = undefined
in ()
```
This panics currently (#15588), but I'm pretty sure it will erroneously be rejected even after the panic is fixed. Let's walk through it.
- We can derive `IfK :: forall (j :: Bool) (m :: Type) (n :: Type). Proxy j -> m -> n -> If j m n`, where `If :: forall k. Bool -> k -> k -> k` is imported from `Data.Type.Bool` and is a straightforward conditional choice operator.
- In the type of `x`, we see that we need the kind of `IfK c b d` to match the kind of `d`. That is, if `b :: kappa[3]`, we have `[W] If cb kappa[3] a ~ a`. Here, the `forall` in `x`'s type is at level 3; the RHS of `y` is at level 2.
- If we could reduce `If cb kappa[3] a` to `kappa[3]`, then we would solve `kappa[3] := a`, but we can't make this reduction, because `cb` is a skolem.
- Instead, we finish checking the type of `x` and promote `kappa[3]` to `kappa[2]`.
- Later, we'll make an implication constraint with `[G] cb ~ True`. When solving that implication constraint, we'll get `[W] If True kappa[2] a ~ a` and simplify to `[W] kappa[2] ~ a`, but that will be insoluble because we'll be solving at level 3, and now `kappa[2]` is at level 2. We're too late.
Yet, I claim that this program should be accepted, and it would be if GHC tracked a set of ambient givens and used them in local calls to the solver. With these "ambient givens" (instead of putting them only in implication constraints), we would know `cb ~ True` the first time we try to solve, and then we'll succeed.
An alternative story is to change how levels are used with variables. Currently, levels are, essentially, the number of type variables available from an outer scope. Accordingly, we must make sure that the level of a variable is never higher than the ambient level. (If it were, we wouldn't know what extra variable(s) were in scope.) Instead, we could just store the list of variables that were in scope. We wouldn't then need to promote in this case -- promotion would happen only during floating. But tracking these lists is a real pain. (If we decide to pursue this further, I can add more details, but it's all in Chapter 6 in [my thesis](https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs) -- section 6.5 to be specific.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Always promoting metavariables during type inference may be wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, when checking a type signature, GHC promotes all the metavariables that arise during checking as soon as it's done checking the signature. This may be incorrect sometimes.\r\n\r\nConsider\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies,\r\n AllowAmbiguousTypes #-}\r\n\r\nimport Data.Proxy\r\nimport Data.Type.Equality\r\nimport Data.Type.Bool\r\nimport Data.Kind\r\n\r\ndata SameKind :: forall k. k -> k -> Type\r\ntype family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where\r\n IfK (_ :: Proxy True) f _ = f\r\n IfK (_ :: Proxy False) _ g = g\r\n\r\ny :: forall (cb :: Bool) (c :: Proxy cb). cb :~: True -> ()\r\ny Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d\r\n x = undefined\r\n in ()\r\n}}}\r\n\r\nThis panics currently (#15588), but I'm pretty sure it will erroneously be rejected even after the panic is fixed. Let's walk through it.\r\n\r\n* We can derive `IfK :: forall (j :: Bool) (m :: Type) (n :: Type). Proxy j -> m -> n -> If j m n`, where `If :: forall k. Bool -> k -> k -> k` is imported from `Data.Type.Bool` and is a straightforward conditional choice operator.\r\n\r\n* In the type of `x`, we see that we need the kind of `IfK c b d` to match the kind of `d`. That is, if `b :: kappa[3]`, we have `[W] If cb kappa[3] a ~ a`. Here, the `forall` in `x`'s type is at level 3; the RHS of `y` is at level 2.\r\n\r\n* If we could reduce `If cb kappa[3] a` to `kappa[3]`, then we would solve `kappa[3] := a`, but we can't make this reduction, because `cb` is a skolem.\r\n\r\n* Instead, we finish checking the type of `x` and promote `kappa[3]` to `kappa[2]`.\r\n\r\n* Later, we'll make an implication constraint with `[G] cb ~ True`. When solving that implication constraint, we'll get `[W] If True kappa[2] a ~ a` and simplify to `[W] kappa[2] ~ a`, but that will be insoluble because we'll be solving at level 3, and now `kappa[2]` is at level 2. We're too late.\r\n\r\nYet, I claim that this program should be accepted, and it would be if GHC tracked a set of ambient givens and used them in local calls to the solver. With these \"ambient givens\" (instead of putting them only in implication constraints), we would know `cb ~ True` the first time we try to solve, and then we'll succeed.\r\n\r\nAn alternative story is to change how levels are used with variables. Currently, levels are, essentially, the number of type variables available from an outer scope. Accordingly, we must make sure that the level of a variable is never higher than the ambient level. (If it were, we wouldn't know what extra variable(s) were in scope.) Instead, we could just store the list of variables that were in scope. We wouldn't then need to promote in this case -- promotion would happen only during floating. But tracking these lists is a real pain. (If we decide to pursue this further, I can add more details, but it's all in Chapter 6 in [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs my thesis] -- section 6.5 to be specific.)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15588Panic when abusing kind inference2019-07-07T18:04:01ZRichard Eisenbergrae@richarde.devPanic when abusing kind inferenceWhen I say
```hs
{-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies,
AllowAmbiguousTypes #-}
import Data.Proxy
import Data.Type.Equality
import Data.Type.Bool
import Data.Kind
data SameKind :: foral...When I say
```hs
{-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies,
AllowAmbiguousTypes #-}
import Data.Proxy
import Data.Type.Equality
import Data.Type.Bool
import Data.Kind
data SameKind :: forall k. k -> k -> Type
type family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where
IfK (_ :: Proxy True) f _ = f
IfK (_ :: Proxy False) _ g = g
y :: forall ck (c :: ck). ck :~: Proxy True -> ()
y Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d
x = undefined
in ()
```
HEAD says
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20180827 for x86_64-apple-darwin):
ASSERT failed!
Bad coercion hole co_a3iZ: If
j_a3j0[tau:2] m_a3j1[tau:2] a_a3gV[sk:3]
a_a3gV[sk:3]
nominal
If j_a3j0[tau:2] m_a3j1[tau:2] a_a3jj[sk:3] ~# a_a3jj[sk:3]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcMType.hs:316:25 in ghc:TcMType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
It's as yet unclear whether the program should be accepted. My best guess is that it should, but that (even with this panic fixed) GHC isn't up to the task.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic when abusing kind inference","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies,\r\n AllowAmbiguousTypes #-}\r\n\r\nimport Data.Proxy\r\nimport Data.Type.Equality\r\nimport Data.Type.Bool\r\nimport Data.Kind\r\n\r\ndata SameKind :: forall k. k -> k -> Type\r\ntype family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where\r\n IfK (_ :: Proxy True) f _ = f\r\n IfK (_ :: Proxy False) _ g = g\r\n\r\ny :: forall ck (c :: ck). ck :~: Proxy True -> ()\r\ny Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d\r\n x = undefined\r\n in ()\r\n}}}\r\n\r\nHEAD says\r\n\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20180827 for x86_64-apple-darwin):\r\n\tASSERT failed!\r\n Bad coercion hole co_a3iZ: If\r\n j_a3j0[tau:2] m_a3j1[tau:2] a_a3gV[sk:3]\r\n a_a3gV[sk:3]\r\n nominal\r\n If j_a3j0[tau:2] m_a3j1[tau:2] a_a3jj[sk:3] ~# a_a3jj[sk:3]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable\r\n assertPprPanic, called at compiler/typecheck/TcMType.hs:316:25 in ghc:TcMType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nIt's as yet unclear whether the program should be accepted. My best guess is that it should, but that (even with this panic fixed) GHC isn't up to the task.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15587traceEvent tests failing in slow validate2019-07-07T18:04:01ZÖmer Sinan AğacantraceEvent tests failing in slow validatetraceEvent tests are failing in slow validate when testing in GHCi way:
```
=====> traceEvent(ghci) 1 of 2 [0, 0, 0]
cd "rts/traceEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" traceEvent.hs -dcore-lint -dcmm-li...traceEvent tests are failing in slow validate when testing in GHCi way:
```
=====> traceEvent(ghci) 1 of 2 [0, 0, 0]
cd "rts/traceEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" traceEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceEvent.genscript
Actual stderr output differs from expected:
diff -uw "rts/traceEvent.run/traceEvent.stderr.normalised" "rts/traceEvent.run/traceEvent.run.stderr.normalised"
--- rts/traceEvent.run/traceEvent.stderr.normalised 2018-08-31 12:48:13.548375420 +0300
+++ rts/traceEvent.run/traceEvent.run.stderr.normalised 2018-08-31 12:48:13.548375420 +0300
@@ -1 +0,0 @@
-traceEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out
*** unexpected failure for traceEvent(ghci)
=====> traceBinaryEvent(ghci) 2 of 2 [0, 1, 0]
cd "rts/traceBinaryEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" traceBinaryEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceBinaryEvent.genscript
Actual stderr output differs from expected:
diff -uw "rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised" "rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised"
--- rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised 2018-08-31 12:48:13.712373185 +0300
+++ rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised 2018-08-31 12:48:13.712373185 +0300
@@ -1 +0,0 @@
-traceBinaryEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out
*** unexpected failure for traceBinaryEvent(ghci)
Unexpected results from:
TEST="traceBinaryEvent traceEvent"
```
I think GHCi doesn't generate eventlogs so there's no way to make these pass. I submitted [D5119](https://phabricator.haskell.org/D5119) to skip these tests in GHCi way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"traceEvent tests failing in slow validate","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"traceEvent tests are failing in slow validate when testing in GHCi way:\r\n\r\n{{{\r\n=====> traceEvent(ghci) 1 of 2 [0, 0, 0]\r\ncd \"rts/traceEvent.run\" && \"/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2\" traceEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceEvent.genscript\r\nActual stderr output differs from expected:\r\ndiff -uw \"rts/traceEvent.run/traceEvent.stderr.normalised\" \"rts/traceEvent.run/traceEvent.run.stderr.normalised\"\r\n--- rts/traceEvent.run/traceEvent.stderr.normalised 2018-08-31 12:48:13.548375420 +0300\r\n+++ rts/traceEvent.run/traceEvent.run.stderr.normalised 2018-08-31 12:48:13.548375420 +0300\r\n@@ -1 +0,0 @@\r\n-traceEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out\r\n*** unexpected failure for traceEvent(ghci)\r\n=====> traceBinaryEvent(ghci) 2 of 2 [0, 1, 0]\r\ncd \"rts/traceBinaryEvent.run\" && \"/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2\" traceBinaryEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceBinaryEvent.genscript\r\nActual stderr output differs from expected:\r\ndiff -uw \"rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised\" \"rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised\"\r\n--- rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised 2018-08-31 12:48:13.712373185 +0300\r\n+++ rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised 2018-08-31 12:48:13.712373185 +0300\r\n@@ -1 +0,0 @@\r\n-traceBinaryEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out\r\n*** unexpected failure for traceBinaryEvent(ghci)\r\n\r\nUnexpected results from:\r\nTEST=\"traceBinaryEvent traceEvent\"\r\n}}}\r\n\r\nI think GHCi doesn't generate eventlogs so there's no way to make these pass. I submitted Phab:D5119 to skip these tests in GHCi way.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15586Compilation panic! (the 'impossible' happened)2019-07-07T18:04:01ZsubaruruCompilation panic! (the 'impossible' happened)See attached zip for entire project causing error. I'd imagine it's pretty reproducible, just call stack build. I'm running standard lts-12.8 and it's just two small files that don't do anything yet!
Also included is panicmessage.txt sho...See attached zip for entire project causing error. I'd imagine it's pretty reproducible, just call stack build. I'm running standard lts-12.8 and it's just two small files that don't do anything yet!
Also included is panicmessage.txt showing the exact output, crucially:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
piResultTy
*
v_XabT
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type
```
Oh and sysinfo
```
uname -a
Linux @@@ 4.16.11-100.fc26.x86_64 #1 SMP Tue May 22 20:02:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Compilation panic! (the 'impossible' happened)","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"See attached zip for entire project causing error. I'd imagine it's pretty reproducible, just call stack build. I'm running standard lts-12.8 and it's just two small files that don't do anything yet!\r\nAlso included is panicmessage.txt showing the exact output, crucially:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n\tpiResultTy\r\n *\r\n v_XabT\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type\r\n\r\n}}}\r\n\r\nOh and sysinfo \r\n\r\n\r\n{{{\r\nuname -a\r\nLinux @@@ 4.16.11-100.fc26.x86_64 #1 SMP Tue May 22 20:02:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux\r\n}}}\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15585Testing2019-07-07T18:04:01ZBen GamariTestingHello world
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailu...Hello world
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello world","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15583Treating Constraint as Type when using (type C = Constraint)2019-07-07T18:04:02ZIcelandjackTreating Constraint as Type when using (type C = Constraint)This may be similar/same as #15412? I can't get to the latest GHC right now. Again the "culprit" is using `type C = Constraint`.
The code example should not compile, but the error it gives is unexpected. If we define the associated type...This may be similar/same as #15412? I can't get to the latest GHC right now. Again the "culprit" is using `type C = Constraint`.
The code example should not compile, but the error it gives is unexpected. If we define the associated type family `Ob_ (cat :: Cat ob) :: ob -> C` using `C`
```hs
{-# Language KindSignatures, PolyKinds, DataKinds, TypeInType, TypeFamilies, FlexibleInstances #-}
import Data.Kind
type T = Type
type C = Constraint
type Cat ob = ob -> ob -> T
class Category_ (cat :: Cat ob) where
type Ob_ (cat :: Cat ob) :: ob -> C
id_ :: Ob_ cat a => cat a a
class NoCls (a::k)
instance NoCls (a::k)
instance Category_ (->) where
type Ob_ (->) = NoCls
-- id_ :: NoCls a => (a -> a) -XInstanceSigs
id_ = ()
```
the definition of `id_` fails (as we expect), but the expected type (`Ob_ (->) a -> a -> a`) is wrong:
```
$ ghci -ignore-dot-ghci 348.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 348.hs, interpreted )
348.hs:22:9: error:
• Couldn't match expected type ‘Ob_ (->) a -> a -> a’
with actual type ‘()’
• In the expression: ()
In an equation for ‘id_’: id_ = ()
In the instance declaration for ‘Category_ (->)’
• Relevant bindings include
id_ :: Ob_ (->) a -> a -> a (bound at 348.hs:22:3)
|
22 | id_ = ()
| ^^
Failed, no modules loaded.
Prelude>
```
If we simply replace `Ob_` with `type Ob_ (cat :: Cat ob) :: ob -> Constraint`, the expected type (`a -> a`) matches my intuition:
```
348.hs:22:9: error:
• Couldn't match expected type ‘a -> a’ with actual type ‘()’
• In the expression: ()
In an equation for ‘id_’: id_ = ()
In the instance declaration for ‘Category_ (->)’
• Relevant bindings include id_ :: a -> a (bound at 348.hs:22:3)
|
22 | id_ = ()
| ^^
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15582Phabricator shows "drafts" by default2019-07-07T18:04:02ZKrzysztof GogolewskiPhabricator shows "drafts" by defaultBy default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default?
I've done this al...By default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default?
I've done this already on my account, but I think it makes sense to do this globally.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Phabricator shows \"drafts\" by default","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"By default, going to https://phabricator.haskell.org/differential/ shows \"Drafts\". This category isn't very useful. Is it possible to create a query for \"All open\" (Statuses: \"Any Open Status\") and make it the default?\r\n\r\nI've done this already on my account, but I think it makes sense to do this globally.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15581Unable to commit [negative number] bytes of memory2019-08-08T06:45:17ZNiklas Hambüchenmail@nh2.meUnable to commit [negative number] bytes of memoryIn issues like https://github.com/haskell/text/issues/221 we observe:
```
"<interactive>: internal error: Unable to commit -1604321280 bytes of memory
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug:...In issues like https://github.com/haskell/text/issues/221 we observe:
```
"<interactive>: internal error: Unable to commit -1604321280 bytes of memory
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Unable to commit a \*\*negative\*\* amount of bytes?
That looks like integer overflow somewhere.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to commit [negative number] bytes of memory","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"In issues like https://github.com/haskell/text/issues/221 we observe:\r\n\r\n{{{\r\n\"<interactive>: internal error: Unable to commit -1604321280 bytes of memory\r\n (GHC version 8.2.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nUnable to commit a **negative** amount of bytes?\r\n\r\nThat looks like integer overflow somewhere.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15580Specialize min/max functions for GHC provided instances.2019-07-07T18:04:02ZAndreas KlebingerSpecialize min/max functions for GHC provided instances.In particular for Int/Word/Float/Double we should aim to provide branchless code where reasonable.
Especially when using SSE we should just use `minss` instead of
```
ucomisd %xmm1,%xmm0
jp .Lc5vv
jbe .Lc5vw
```
which is worse i...In particular for Int/Word/Float/Double we should aim to provide branchless code where reasonable.
Especially when using SSE we should just use `minss` instead of
```
ucomisd %xmm1,%xmm0
jp .Lc5vv
jbe .Lc5vw
```
which is worse in all kinds of ways.
If someone feels like tackling this I'm happy to help with code review, answering questions, etc.
I won't get around to doing it myself any time soon.
As a starting point the instance declarations are in ghc-prim/GHC/Classes.hs.
I would look into solving this via adding a new MachOP/PrimOP but maybe there are even better ways.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Specialize min/max functions for GHC provided instances.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["CodeGen"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"In particular for Int/Word/Float/Double we should aim to provide branchless code where reasonable.\r\n\r\nEspecially when using SSE we should just use `minss` instead of\r\n{{{\r\n ucomisd %xmm1,%xmm0\r\n jp .Lc5vv\r\n jbe .Lc5vw\r\n}}}\r\nwhich is worse in all kinds of ways.\r\n\r\nIf someone feels like tackling this I'm happy to help with code review, answering questions, etc.\r\n\r\nI won't get around to doing it myself any time soon.\r\n\r\nAs a starting point the instance declarations are in ghc-prim/GHC/Classes.hs.\r\n\r\nI would look into solving this via adding a new MachOP/PrimOP but maybe there are even better ways.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15579topNormaliseType is wrong2019-07-07T18:04:02ZSimon Peyton JonestopNormaliseType is wrongI’m very puzzled about topNormaliseTYpe_maybe. Here it is:
```haskell
topNormaliseType_maybe env ty
= topNormaliseTypeX stepper mkTransCo ty
where
stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper
tyFamStepper r...I’m very puzzled about topNormaliseTYpe_maybe. Here it is:
```haskell
topNormaliseType_maybe env ty
= topNormaliseTypeX stepper mkTransCo ty
where
stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper
tyFamStepper rec_nts tc tys -- Try to step a type/data family
= let (args_co, ntys) = normaliseTcArgs env Representational tc tys in
-- NB: It's OK to use normaliseTcArgs here instead of
-- normalise_tc_args (which takes the LiftingContext described
-- in Note [Normalising types]) because the reduceTyFamApp below
-- works only at top level. We'll never recur in this function
-- after reducing the kind of a bound tyvar.
case reduceTyFamApp_maybe env Representational tc ntys of
Just (co, rhs) -> NS_Step rec_nts rhs (args_co `mkTransCo` co)
_ -> NS_Done
```
I have two puzzlements
1. First, it seems utterly wrong to normalise the arguments using Representational. Consider
```haskell
F (N Int)
where newtype N x = [x]
```
> We don’t want to reduce `(N Int)` to `[Int]`, and then try reducing `(F [Int])`!! That is totally bogus. Surely we should use (the role-aware) `normalise_tc_args` here?
1. I have literally no clue what `Note [Normalising types]` is all about. Moreover there is no Lifting Context passed to `normalise_tc_args`, so I don’t know what this stuff about `LiftingContext` is about. Is this historical baggage?
Richard and I discussed this. (1) is a bug; for (2) the comment is misleading and should be deleted.
Richard will do these things -- and will add examples to the mysterious `Note [Normalising types]`8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15576Hadrian puts its build tree in the wrong place2022-03-11T17:42:27ZSimon Peyton JonesHadrian puts its build tree in the wrong placeI have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically-connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the...I have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically-connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the corresponding source file in `/home/simonpj/ghc`.
But when I do
```
$ cd /playpen/ghc
$ hadrian/build.sh -c -j4 --flavour=quick
```
I find a new `_build` director in `/home/simonpj/ghc`. This is bad! It should be in `/playpen/ghc`. Otherwise (a) it's slower, (b) it creates backup churn and (c) as it happens, I ran out of space on the backed-up filestore.
Can this be fixed? It's a bad Hadrian shortcoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | andrey.mokhov@newcastle.ac.uk |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian puts its build tree in the wrong place","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["andrey.mokhov@newcastle.ac.uk"],"type":"Bug","description":"I have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically-connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the corresponding source file in `/home/simonpj/ghc`.\r\n\r\nBut when I do\r\n{{{\r\n$ cd /playpen/ghc\r\n$ hadrian/build.sh -c -j4 --flavour=quick \r\n}}}\r\nI find a new `_build` director in `/home/simonpj/ghc`. This is bad! It should be in `/playpen/ghc`. Otherwise (a) it's slower, (b) it creates backup churn and (c) as it happens, I ran out of space on the backed-up filestore.\r\n\r\nCan this be fixed? It's a bad Hadrian shortcoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15574C wrappers for Haskell foreign exports don't have finalizers (causes memory l...2019-07-07T18:04:04ZValoisaC wrappers for Haskell foreign exports don't have finalizers (causes memory leak).For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's...For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, \*\*consumed memory is not fully released after freeing the library\*\*.
\[\[br\]\]\[\[br\]\]
There are four files attached to this ticket.
- \*\*HaskellExports.hs\*\* contains exact one foreign export function;
- \*\*CWrapper.cpp\*\* is supposed to contain wrappers to the Haskell functions, described in *HaskellExports.hs*, but it doesn't because they make no difference;
- \*\*main.cpp\*\*: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);
- \*\*build.sh\*\* is a script for building the library.
\[\[br\]\]
The main program was built with MSVC 2015.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"C wrappers for Haskell foreign exports don't have finalizers (causes memory leak).","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**.\r\n[[br]][[br]]\r\nThere are four files attached to this ticket. \r\n* **HaskellExports.hs** contains exact one foreign export function;\r\n* **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference;\r\n* **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);\r\n* **build.sh** is a script for building the library.\r\n[[br]]\r\nThe main program was built with MSVC 2015.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15573Make bindings with multiple occurrences a join point instead of duplicating c...2019-07-07T18:04:04ZAndreas KlebingerMake bindings with multiple occurrences a join point instead of duplicating code during inlining.I have some intermediate core of the form:
```
-- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0}
cseAlts_s1dD [Occ=Once!T[1]] :: T -> Int#
[LclId, CallArity=1, Str=<S,1*U>]
cseAlts_s1dD
= \ (lamVar_s1dw [Occ=Once!, Dmd=<S,1*...I have some intermediate core of the form:
```
-- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0}
cseAlts_s1dD [Occ=Once!T[1]] :: T -> Int#
[LclId, CallArity=1, Str=<S,1*U>]
cseAlts_s1dD
= \ (lamVar_s1dw [Occ=Once!, Dmd=<S,1*U>, OS=OneShot] :: T) ->
case lamVar_s1dw of wild_Xc [Dmd=<L,A>] {
__DEFAULT -> 1#;
B -> 2#;
C -> 3#
}
-- RHS size: {terms: 14, types: 3, coercions: 0, joins: 0/0}
$wfmerge_s1cZ [InlPrag=NOUSERINLINE[0]] :: T -> T -> Int#
[LclId, Arity=2, CallArity=2, Str=<S,1*U><L,1*U>]
$wfmerge_s1cZ
= \ (w_s1cU [Occ=Once!, Dmd=<S,1*U>] :: T)
(w_s1cV [Occ=Once*, Dmd=<L,1*U>] :: T) ->
case w_s1cU of wild_XA [Dmd=<L,A>] {
__DEFAULT -> -1#;
A -> 2#;
B -> cseAlts_s1dD w_s1cV;
C -> cseAlts_s1dD w_s1cV
}
```
Which after the simplifier ran got inlined into the branches to give us:
```
fmerge
= \ (w_s1cU :: T) (w_s1cV :: T) ->
case w_s1cU of {
__DEFAULT -> GHC.Types.I# -1#;
A -> GHC.Types.I# 2#;
B ->
case w_s1cV of {
__DEFAULT -> GHC.Types.I# 1#;
B -> GHC.Types.I# 2#;
C -> GHC.Types.I# 3#
};
C ->
case w_s1cV of {
__DEFAULT -> GHC.Types.I# 1#;
B -> GHC.Types.I# 2#;
C -> GHC.Types.I# 3#
}
}
```
What I would really like GHC to do instead though is to make `cseAlts_s1dD` a join point when possible.
This would eliminate both the call overhead AND the call duplication.
The current behavior seems fine when we can't make it a join point. But when we can we should try to take advantage of that opportunity.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make bindings with multiple occurrences a join point instead of duplicating code during inlining.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["JoinPoints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"I have some intermediate core of the form:\r\n\r\n{{{\r\n-- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0}\r\ncseAlts_s1dD [Occ=Once!T[1]] :: T -> Int#\r\n[LclId, CallArity=1, Str=<S,1*U>]\r\ncseAlts_s1dD\r\n = \\ (lamVar_s1dw [Occ=Once!, Dmd=<S,1*U>, OS=OneShot] :: T) ->\r\n case lamVar_s1dw of wild_Xc [Dmd=<L,A>] {\r\n __DEFAULT -> 1#;\r\n B -> 2#;\r\n C -> 3#\r\n }\r\n\r\n-- RHS size: {terms: 14, types: 3, coercions: 0, joins: 0/0}\r\n$wfmerge_s1cZ [InlPrag=NOUSERINLINE[0]] :: T -> T -> Int#\r\n[LclId, Arity=2, CallArity=2, Str=<S,1*U><L,1*U>]\r\n$wfmerge_s1cZ\r\n = \\ (w_s1cU [Occ=Once!, Dmd=<S,1*U>] :: T)\r\n (w_s1cV [Occ=Once*, Dmd=<L,1*U>] :: T) ->\r\n case w_s1cU of wild_XA [Dmd=<L,A>] {\r\n __DEFAULT -> -1#;\r\n A -> 2#;\r\n B -> cseAlts_s1dD w_s1cV;\r\n C -> cseAlts_s1dD w_s1cV\r\n }\r\n}}}\r\n\r\nWhich after the simplifier ran got inlined into the branches to give us:\r\n\r\n{{{\r\nfmerge\r\n = \\ (w_s1cU :: T) (w_s1cV :: T) ->\r\n case w_s1cU of {\r\n __DEFAULT -> GHC.Types.I# -1#;\r\n A -> GHC.Types.I# 2#;\r\n B ->\r\n case w_s1cV of {\r\n __DEFAULT -> GHC.Types.I# 1#;\r\n B -> GHC.Types.I# 2#;\r\n C -> GHC.Types.I# 3#\r\n };\r\n C ->\r\n case w_s1cV of {\r\n __DEFAULT -> GHC.Types.I# 1#;\r\n B -> GHC.Types.I# 2#;\r\n C -> GHC.Types.I# 3#\r\n }\r\n }\r\n}}}\r\n\r\nWhat I would really like GHC to do instead though is to make `cseAlts_s1dD` a join point when possible.\r\nThis would eliminate both the call overhead AND the call duplication.\r\n\r\nThe current behavior seems fine when we can't make it a join point. But when we can we should try to take advantage of that opportunity.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15572TH improperly converts promoted data cons in ConT2019-10-24T22:39:13ZRyan ScottTH improperly converts promoted data cons in ConTIf you compile the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Language.Haskell.TH
$([d| type AbsoluteUnit1 = '() |])
$(pure [TySynD (...If you compile the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Language.Haskell.TH
$([d| type AbsoluteUnit1 = '() |])
$(pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())])
```
```
$ /opt/ghc/8.6.1/bin/ghci Bug.hs
GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:8:3-33: Splicing declarations
[d| type AbsoluteUnit1_a1HN = '() |]
======>
type AbsoluteUnit1_a4qs = '()
Bug.hs:9:3-54: Splicing declarations
pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())]
======>
type AbsoluteUnit2 = ()
```
You'll notice an unusual discrepancy between the two `-ddump-splices` logs. In the first one:
```hs
type AbsoluteUnit1_a4qs = '()
```
The `'()` constructor is properly preceded with a single quote. In the second one, however:
```hs
type AbsoluteUnit2 = ()
```
`'()` incorrectly appears without a single quote! The culprit is in the way `Convert` [handles](http://git.haskell.org/ghc.git/blob/154d4e219cc0cebbef8a845609bd63ec45fdbea6:/compiler/hsSyn/Convert.hs#l1307) `ConT`:
```hs
ConT nm -> do { nm' <- tconName nm
; mk_apps (HsTyVar noExt NotPromoted (noLoc nm')) tys'}
```
This code naïvely assumes that `ConT` will never contain a promoted data constructor name by hardcoding `NotPromoted`. We really ought to be checking if `nm'` is a data con `RdrName` here and using `Promoted` if so, and `NotPromoted` otherwise.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TH improperly converts promoted data cons in ConT","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you compile the following program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\nimport Language.Haskell.TH\r\n\r\n$([d| type AbsoluteUnit1 = '() |])\r\n$(pure [TySynD (mkName \"AbsoluteUnit2\") [] (ConT '())])\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghci Bug.hs\r\nGHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:8:3-33: Splicing declarations\r\n [d| type AbsoluteUnit1_a1HN = '() |]\r\n ======>\r\n type AbsoluteUnit1_a4qs = '()\r\nBug.hs:9:3-54: Splicing declarations\r\n pure [TySynD (mkName \"AbsoluteUnit2\") [] (ConT '())]\r\n ======>\r\n type AbsoluteUnit2 = ()\r\n}}}\r\n\r\nYou'll notice an unusual discrepancy between the two `-ddump-splices` logs. In the first one:\r\n\r\n{{{#!hs\r\n type AbsoluteUnit1_a4qs = '()\r\n}}}\r\n\r\nThe `'()` constructor is properly preceded with a single quote. In the second one, however:\r\n\r\n{{{#!hs\r\n type AbsoluteUnit2 = ()\r\n}}}\r\n\r\n`'()` incorrectly appears without a single quote! The culprit is in the way `Convert` [http://git.haskell.org/ghc.git/blob/154d4e219cc0cebbef8a845609bd63ec45fdbea6:/compiler/hsSyn/Convert.hs#l1307 handles] `ConT`:\r\n\r\n{{{#!hs\r\n ConT nm -> do { nm' <- tconName nm\r\n ; mk_apps (HsTyVar noExt NotPromoted (noLoc nm')) tys'}\r\n}}}\r\n\r\nThis code naïvely assumes that `ConT` will never contain a promoted data constructor name by hardcoding `NotPromoted`. We really ought to be checking if `nm'` is a data con `RdrName` here and using `Promoted` if so, and `NotPromoted` otherwise.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1