GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:19:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13812deriveConstants: no objdump program given (OpenBSD)2019-07-07T18:19:59ZrolandderiveConstants: no objdump program given (OpenBSD)Building HEAD on OpenBSD 6.1 fails with:
```
inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "gcc" --gcc-flag -W
all --gc...Building HEAD on OpenBSD 6.1 fails with:
```
inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "gcc" --gcc-flag -W
all --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/di
st-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm" --target-os "openbsd"
deriveConstants: no objdump program given
```
This can be fixed in configure.ac (see attached patch).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"deriveConstants: no objdump program given (OpenBSD)","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building HEAD on OpenBSD 6.1 fails with:\r\n\r\n{{{\r\ninplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program \"gcc\" --gcc-flag -W\r\nall --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/di\r\nst-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program \"nm\" --target-os \"openbsd\"\r\nderiveConstants: no objdump program given\r\n}}}\r\n\r\nThis can be fixed in configure.ac (see attached patch).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13811eta reduction in GHCi for an educational purpose2019-07-07T18:19:59Zvantoeta reduction in GHCi for an educational purposeHello,\\\\
Is it possible to have in GHCi an eta reduction of an expression for an educational purpose?\\\\
We would have access by typing a command like this on the line
`:eta reduction <expr>` with the following annotation
`show the et...Hello,\\\\
Is it possible to have in GHCi an eta reduction of an expression for an educational purpose?\\\\
We would have access by typing a command like this on the line
`:eta reduction <expr>` with the following annotation
`show the eta reduction of <expr>` in short `:er <expr>`.\\\\
example:\\\\
```
Prelude> length xs = foldl (\n _ -> n+1) 0 xs
Prelude> :eta reduction length --or :er length
length = foldl (\n _ -> n+1) 0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"eta reduction in GHCi for an educational purpose","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Hello,\\\\\r\nIs it possible to have in GHCi an eta reduction of an expression for an educational purpose?\\\\\r\nWe would have access by typing a command like this on the line \r\n{{{:eta reduction <expr>}}} with the following annotation \r\n{{{show the eta reduction of <expr>}}} in short {{{:er <expr>}}}.\\\\\r\nexample:\\\\\r\n\r\n{{{\r\nPrelude> length xs = foldl (\\n _ -> n+1) 0 xs\r\nPrelude> :eta reduction length --or :er length\r\nlength = foldl (\\n _ -> n+1) 0\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13810Gold linker fails2019-07-07T18:19:59ZksaricGold linker failsWhen using gold linker in the project, the compilation fails.
The same error occurs even when using nix, without stack.
The bug can be reproduced very easily.
You can clone from here (https://github.com/ksaric/bronze-linker) and `stack...When using gold linker in the project, the compilation fails.
The same error occurs even when using nix, without stack.
The bug can be reproduced very easily.
You can clone from here (https://github.com/ksaric/bronze-linker) and `stack build`.
Or you can:
- `stack new project`
- `cd project`
- `stack build`
Now it builds.
- then add gold flags to cabal like here - https://github.com/ksaric/bronze-linker/blob/master/bronze-linker.cabal\#L22-L25
- `stack build`
Now it fails.
----
Linking .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/bronze-linker-exe/bronze-linker-exe ...
/nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: --hash-size=31: unknown option
/nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: use the --help option for usage information
collect2: error: ld returned 1 exit status
'cc' failed in phase 'Linker'. (Exit code: 1)
----
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Gold linker fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["linker"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using gold linker in the project, the compilation fails.\r\nThe same error occurs even when using nix, without stack.\r\n\r\nThe bug can be reproduced very easily. \r\n\r\nYou can clone from here (https://github.com/ksaric/bronze-linker) and `stack build`.\r\n\r\nOr you can:\r\n- `stack new project`\r\n- `cd project`\r\n- `stack build`\r\n\r\nNow it builds.\r\n\r\n- then add gold flags to cabal like here - https://github.com/ksaric/bronze-linker/blob/master/bronze-linker.cabal#L22-L25\r\n- `stack build`\r\n\r\nNow it fails.\r\n\r\n\r\n\r\n----\r\n\r\nLinking .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/bronze-linker-exe/bronze-linker-exe ...\r\n\r\n/nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: --hash-size=31: unknown option\r\n\r\n/nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: use the --help option for usage information\r\n\r\ncollect2: error: ld returned 1 exit status\r\n'cc' failed in phase 'Linker'. (Exit code: 1)\r\n\r\n\r\n----\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13809TH-reified type family and data family instances have a paucity of kinds2019-07-07T18:20:00ZRyan ScottTH-reified type family and data family instances have a paucity of kindsConsider this data family (and instances):
```hs
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo ((f :: * -> *) (a :: *))
data instance Foo ((f :: (* -> *) -> *) (a :: (* -> *)))
```
The...Consider this data family (and instances):
```hs
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo ((f :: * -> *) (a :: *))
data instance Foo ((f :: (* -> *) -> *) (a :: (* -> *)))
```
These are two data family instances that GHC distinguishes by the kinds of their type parameters. However, Template Haskell does not give me the same insight that GHC has, because if I call `Language.Haskell.TH.reify ''Foo`, I get this:
```hs
FamilyI
(DataFamilyD
Foo.Foo [ KindedTV a_6989586621679025989 StarT ] (Just StarT))
[ DataInstD
[]
Foo.Foo
[ AppT (VarT f_6989586621679026001) (VarT a_6989586621679026000) ]
Nothing
[]
[]
, DataInstD
[]
Foo.Foo
[ AppT (VarT f_6989586621679026007) (VarT a_6989586621679026006) ]
Nothing
[]
[]
]
```
Note that neither `f` nor `a` have a kind signature in either instance! This makes it completely impossible to tell which is which (aside from the order, which is brittle). It would make my life a lot easier if TH were to include kind signatures for each type variable in a data family instance. I can see two ways to accomplish this:
1. Include a `[TyVarBndr]` field in `DataInstD` and `NewtypeInstD` where each `TyVarBndr` is a `KindedTV`.
1. Walk over the `Type`s in a `DataInstD`/`NewtypeInstD` and ensure that every occurrence of a `VarT` is surrounded with `SigT` to indicate its kind.
While (1) is arguably the cleaner solution, since it makes the kinds easy to discover, it is a breaking change. Therefore, I'm inclined to implement option (2) instead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| 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-reified data family instances have a paucity of kinds","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this data family (and instances):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Foo where\r\n\r\ndata family Foo a\r\ndata instance Foo ((f :: * -> *) (a :: *))\r\ndata instance Foo ((f :: (* -> *) -> *) (a :: (* -> *)))\r\n}}}\r\n\r\nThese are two data family instances that GHC distinguishes by the kinds of their type parameters. However, Template Haskell does not give me the same insight that GHC has, because if I call `Language.Haskell.TH.reify ''Foo`, I get this:\r\n\r\n{{{#!hs\r\nFamilyI\r\n (DataFamilyD\r\n Foo.Foo [ KindedTV a_6989586621679025989 StarT ] (Just StarT))\r\n [ DataInstD\r\n []\r\n Foo.Foo\r\n [ AppT (VarT f_6989586621679026001) (VarT a_6989586621679026000) ]\r\n Nothing\r\n []\r\n []\r\n , DataInstD\r\n []\r\n Foo.Foo\r\n [ AppT (VarT f_6989586621679026007) (VarT a_6989586621679026006) ]\r\n Nothing\r\n []\r\n []\r\n ]\r\n}}}\r\n\r\nNote that neither `f` nor `a` have a kind signature in either instance! This makes it completely impossible to tell which is which (aside from the order, which is brittle). It would make my life a lot easier if TH were to include kind signatures for each type variable in a data family instance. I can see two ways to accomplish this:\r\n\r\n1. Include a `[TyVarBndr]` field in `DataInstD` and `NewtypeInstD` where each `TyVarBndr` is a `KindedTV`.\r\n2. Walk over the `Type`s in a `DataInstD`/`NewtypeInstD` and ensure that every occurrence of a `VarT` is surrounded with `SigT` to indicate its kind.\r\n\r\nWhile (1) is arguably the cleaner solution, since it makes the kinds easy to discover, it is a breaking change. Therefore, I'm inclined to implement option (2) instead.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/13808Bump Cabal submodule2019-07-07T18:20:00ZBen GamariBump Cabal submoduleCabal 2.0.0.1 will be released shortly
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | B...Cabal 2.0.0.1 will be released shortly
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bump Cabal submodule","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal 2.0.0.1 will be released shortly","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13807GHC 8.2 nondeterministic with foreign imports2019-07-07T18:20:00ZniteriaGHC 8.2 nondeterministic with foreign importsSee the attached Repro.hs.
Reproduction steps:
```
$ rm Repro.{o,hi}; ghc -O -dunique-increment=-1 Repro.hs; md5sum Repro.hi; rm Repro.{o,hi}; ghc -O -dunique-increment=1 Repro.hs; md5sum Repro.hi;
[1 of 1] Compiling Repro (...See the attached Repro.hs.
Reproduction steps:
```
$ rm Repro.{o,hi}; ghc -O -dunique-increment=-1 Repro.hs; md5sum Repro.hi; rm Repro.{o,hi}; ghc -O -dunique-increment=1 Repro.hs; md5sum Repro.hi;
[1 of 1] Compiling Repro ( Repro.hs, Repro.o )
97f005e3959b657bfac761aa3e8a9447 Repro.hi
[1 of 1] Compiling Repro ( Repro.hs, Repro.o )
691f891fb404eb874e8bedd7bda1c8b7 Repro.hi
```
The crucial difference comes from:
```
08fffd1551f79b5aca3cafdceaf865b9
mkStringWriter1 ::
Int -> State# RealWorld -> (# State# RealWorld, Ptr Int #)
{- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,
Unfolding: InlineRule (2, True, False)
(\ (ds :: Int) (s :: State# RealWorld) ->
case makeStablePtr# @ Int ds s of ds1 { (#,#) ipv ipv1 ->
case {__pkg_ccall Int#
-> StablePtr# Int
-> Addr#
-> Addr#
-> State# RealWorld
-> (# State# RealWorld, Addr# #)}
1#
ipv1
__label "Repro_d105" (function)
mkStringWriter2
ipv of wild { (#,#) ds2 ds3 ->
(# ds2, Ptr @ Int ds3 #) } }) -}
```
vs
```
a766a748e60cec63a74534e03db3bf30
mkStringWriter1 ::
Int -> State# RealWorld -> (# State# RealWorld, Ptr Int #)
{- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,
Unfolding: InlineRule (2, True, False)
(\ (ds :: Int) (s :: State# RealWorld) ->
case makeStablePtr# @ Int ds s of ds1 { (#,#) ipv ipv1 ->
case {__pkg_ccall Int#
-> StablePtr# Int
-> Addr#
-> Addr#
-> State# RealWorld
-> (# State# RealWorld, Addr# #)}
1#
ipv1
__label "Repro_d5k1wlNFGaX" (function)
mkStringWriter2
ipv of wild { (#,#) ds2 ds3 ->
(# ds2, Ptr @ Int ds3 #) } }) -}
```
Notice that the labels are different.
This doesn't reproduce under GHC 8.0.2, but that may be only because that version doesn't optimize it this way. This is what GHC 8.0.2 produces:
```
ccf55489bd76322a9404b365b7be7628
mkStringWriter :: Int -> IO (Ptr Int)
{- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,
Inline: [NEVER] -}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.2 nondeterministic with foreign imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See the attached Repro.hs.\r\n\r\nReproduction steps:\r\n{{{\r\n$ rm Repro.{o,hi}; ghc -O -dunique-increment=-1 Repro.hs; md5sum Repro.hi; rm Repro.{o,hi}; ghc -O -dunique-increment=1 Repro.hs; md5sum Repro.hi;\r\n[1 of 1] Compiling Repro ( Repro.hs, Repro.o )\r\n97f005e3959b657bfac761aa3e8a9447 Repro.hi\r\n[1 of 1] Compiling Repro ( Repro.hs, Repro.o )\r\n691f891fb404eb874e8bedd7bda1c8b7 Repro.hi\r\n}}}\r\n\r\nThe crucial difference comes from:\r\n\r\n{{{\r\n08fffd1551f79b5aca3cafdceaf865b9\r\n mkStringWriter1 ::\r\n Int -> State# RealWorld -> (# State# RealWorld, Ptr Int #)\r\n {- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,\r\n Unfolding: InlineRule (2, True, False)\r\n (\\ (ds :: Int) (s :: State# RealWorld) ->\r\n case makeStablePtr# @ Int ds s of ds1 { (#,#) ipv ipv1 ->\r\n case {__pkg_ccall Int#\r\n -> StablePtr# Int\r\n -> Addr#\r\n -> Addr#\r\n -> State# RealWorld\r\n -> (# State# RealWorld, Addr# #)}\r\n 1#\r\n ipv1\r\n __label \"Repro_d105\" (function)\r\n mkStringWriter2\r\n ipv of wild { (#,#) ds2 ds3 ->\r\n (# ds2, Ptr @ Int ds3 #) } }) -}\r\n}}}\r\n\r\nvs \r\n\r\n{{{\r\na766a748e60cec63a74534e03db3bf30\r\n mkStringWriter1 ::\r\n Int -> State# RealWorld -> (# State# RealWorld, Ptr Int #)\r\n {- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,\r\n Unfolding: InlineRule (2, True, False)\r\n (\\ (ds :: Int) (s :: State# RealWorld) ->\r\n case makeStablePtr# @ Int ds s of ds1 { (#,#) ipv ipv1 ->\r\n case {__pkg_ccall Int#\r\n -> StablePtr# Int\r\n -> Addr#\r\n -> Addr#\r\n -> State# RealWorld\r\n -> (# State# RealWorld, Addr# #)}\r\n 1#\r\n ipv1\r\n __label \"Repro_d5k1wlNFGaX\" (function)\r\n mkStringWriter2\r\n ipv of wild { (#,#) ds2 ds3 ->\r\n (# ds2, Ptr @ Int ds3 #) } }) -}\r\n}}}\r\n\r\nNotice that the labels are different.\r\n\r\n\r\nThis doesn't reproduce under GHC 8.0.2, but that may be only because that version doesn't optimize it this way. This is what GHC 8.0.2 produces:\r\n{{{\r\nccf55489bd76322a9404b365b7be7628\r\n mkStringWriter :: Int -> IO (Ptr Int)\r\n {- Arity: 2, HasNoCafRefs, Strictness: <L,U><S,U>,\r\n Inline: [NEVER] -}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1niterianiteriahttps://gitlab.haskell.org/ghc/ghc/-/issues/13806Invalid usage of TypeFamilies cause GHC Internal Error2019-07-07T18:20:00ZutdemirInvalid usage of TypeFamilies cause GHC Internal ErrorI couldn't be able to reproduce this with a valid program, but even on an invalid program seeing "GHC internal error" is unexpected. Only the second error should be enough in this case.
```
$ cat test.hs
{-# LANGUAGE TypeFamilies #-}
d...I couldn't be able to reproduce this with a valid program, but even on an invalid program seeing "GHC internal error" is unexpected. Only the second error should be enough in this case.
```
$ cat test.hs
{-# LANGUAGE TypeFamilies #-}
data Foo value
= Foo (T value)
class Cl t where
type T
mk :: t -> T
main :: IO ()
main = undefined
$ runhaskell test.hs
test.hs:4:10: error:
• GHC internal error: ‘T’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a10K :-> Type variable ‘value’ = value,
r10F :-> ATcTyCon Foo, r10G :-> APromotionErr RecDataConPE]
• In the type ‘T value’
In the definition of data constructor ‘Foo’
In the data declaration for ‘Foo’
test.hs:6:1: error:
• The associated type ‘T’
mentions none of the type or kind variables of the class ‘Cl t’
• In the class declaration for ‘Cl’
$ runhaskell --version
runghc 8.0.2
```https://gitlab.haskell.org/ghc/ghc/-/issues/13805GHC 8.0.2 fails to build on macOS 10.13/Xcode 9 - preprocessor error in ghc-pkg2019-07-07T18:20:00ZmistydemeoGHC 8.0.2 fails to build on macOS 10.13/Xcode 9 - preprocessor error in ghc-pkgBuilding GHC 8.0.2 on macOS 10.13 fails with the following error when building
```
utils/ghc-pkg/Main.hs:1269:40: error:
error: editor placeholder in source file
then termText (location db) <#> termText "\n (no pa...Building GHC 8.0.2 on macOS 10.13 fails with the following error when building
```
utils/ghc-pkg/Main.hs:1269:40: error:
error: editor placeholder in source file
then termText (location db) <#> termText "\n (no packages)\n"
^
```
I'm not very familiar with Haskell, but it looks to me like the C preprocessor is mistaking `<#>` for an invalid cpp directive instead of Haskell syntax.
This is using the Xcode 9 beta (and its associated CLT), which ships "Apple LLVM version 9.0.0 (clang-900.0.22.8)". The same version should be available in the Xcode 9 beta for 10.12, but I haven't tested.
The full build logs are available here: https://gist.github.com/anonymous/dc5f0c9d087f5d299f71393805c5d611
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.0.2 fails to build on macOS 10.13/Xcode 9 - preprocessor error in ghc-pkg","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building GHC 8.0.2 on macOS 10.13 fails with the following error when building \r\n\r\n{{{\r\nutils/ghc-pkg/Main.hs:1269:40: error:\r\n error: editor placeholder in source file\r\n then termText (location db) <#> termText \"\\n (no packages)\\n\"\r\n ^\r\n}}}\r\n\r\nI'm not very familiar with Haskell, but it looks to me like the C preprocessor is mistaking `<#>` for an invalid cpp directive instead of Haskell syntax.\r\n\r\nThis is using the Xcode 9 beta (and its associated CLT), which ships \"Apple LLVM version 9.0.0 (clang-900.0.22.8)\". The same version should be available in the Xcode 9 beta for 10.12, but I haven't tested.\r\n\r\nThe full build logs are available here: https://gist.github.com/anonymous/dc5f0c9d087f5d299f71393805c5d611","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13804MonoLocalBinds/RankNTypes type inference regression in GHC 8.22019-07-07T18:20:01ZRyan ScottMonoLocalBinds/RankNTypes type inference regression in GHC 8.2I encountered this problem when trying to compile the `ivory-bsp-stm32` library (unsuccessfully) with GHC 8.2. Here's a somewhat minimized example:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE...I encountered this problem when trying to compile the `ivory-bsp-stm32` library (unsuccessfully) with GHC 8.2. Here's a somewhat minimized example:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE KindSignatures #-}
-- Not enabling MonoLocalBinds makes it compile again
{-# LANGUAGE MonoLocalBinds #-}
{-# LANGUAGE RankNTypes #-}
module Bug where
import GHC.TypeLits
i2cPeripheralDriver :: I2CPeriph
-> ChanOutput ('Stored ITime)
-> Monitor e ()
i2cPeripheralDriver periph watchdog_per = do
let sendresult' :: Ivory eff ()
sendresult' = do
-- Commenting out the line below makes it compile again
clearSR1 periph
return undefined
sendresult = sendresult'
handler watchdog_per undefined $ do
callback $ \_ -> do
sendresult
return undefined
clearSR1 :: I2CPeriph -> Ivory eff ()
clearSR1 = undefined
-----
-- Auxiliary definitions
-----
data ITime
data I2CPeriph = I2CPeriph
data Ivory (eff :: Effects) a
instance Functor (Ivory eff)
instance Applicative (Ivory eff)
instance Monad (Ivory eff)
data Monitor e a
instance Functor (Monitor e)
instance Applicative (Monitor e)
instance Monad (Monitor e)
data ChanOutput (a :: Area *)
data RefScope =
Global
| forall s. Stack s
type ConstRef = Pointer 'Valid 'Const -- :: RefScope -> Area * -> *
data Nullability = Nullable | Valid
data Constancy = Const | Mutable
data Pointer (n :: Nullability)
(c :: Constancy)
(s :: RefScope)
(a :: Area *)
type AllocEffects s =
'Effects 'NoReturn 'NoBreak ('Scope s) -- :: Effects
data Effects = Effects ReturnEff BreakEff AllocEff
data ReturnEff =
forall t. Returns t
| NoReturn
data BreakEff = Break | NoBreak
data AllocEff =
forall s. Scope s
| NoAlloc
callback ::
(IvoryArea a,
IvoryZero a) =>
(forall (s :: RefScope) s'.
ConstRef s a
-> Ivory
(AllocEffects s') ())
-> Handler a e ()
callback _ = undefined
handler ::
(IvoryArea a,
IvoryZero a) =>
ChanOutput a -> String -> Handler a e () -> Monitor e ()
data Handler (area :: Area *) e a
handler = undefined
data Area k
= Struct Symbol
| Array Nat (Area k)
| CArray (Area k)
| Stored k
data Time
class IvoryArea (a :: Area *)
class IvoryZero (area :: Area *) where
class IvoryType t
instance IvoryType ITime
instance IvoryType a => IvoryArea ('Stored a)
class IvoryZeroVal a
instance IvoryZeroVal ITime
instance IvoryZeroVal a => IvoryZero ('Stored a)
```
In GHC 7.10 and 8.0, this compiles. With GHC 8.2, however, it errors:
```
GHCi, version 8.2.0.20170522: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:25:7: error:
• Couldn't match type ‘eff0’ with ‘AllocEffects s'’
because type variable ‘s'’ would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context:
forall (s :: RefScope) s'.
ConstRef s ('Stored ITime) -> Ivory (AllocEffects s') ()
at Bug.hs:(24,5)-(25,16)
Expected type: Ivory (AllocEffects s') ()
Actual type: Ivory eff0 ()
• In a stmt of a 'do' block: sendresult
In the expression: do sendresult
In the second argument of ‘($)’, namely ‘\ _ -> do sendresult’
• Relevant bindings include
sendresult :: Ivory eff0 () (bound at Bug.hs:21:7)
|
25 | sendresult
| ^^^^^^^^^^
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13803Panic while forcing the thunk for TyThing IsFile (regression)2019-07-07T18:20:01ZinakiPanic while forcing the thunk for TyThing IsFile (regression)(Apologies in advance for the very non-minimal testcase. I have been unsuccessfully trying to reduce the testcase for a few hours now, but I am flying blind, and the bug seems to depend on the interaction of various modules. The panic is...(Apologies in advance for the very non-minimal testcase. I have been unsuccessfully trying to reduce the testcase for a few hours now, but I am flying blind, and the bug seems to depend on the interaction of various modules. The panic is very reproducible for me, so I figured that better reporting even if I failed to obtain a simplified testcase. Maybe someone else has more luck isolating the issue.)
When compiling `gi-gio-2.0.12` I consistently get the following GHC panic:
```
[259 of 293] Compiling GI.Gio.Interfaces.File ( GI/Gio/Interfaces/File.hs, dist/build/GI/Gio/Interfaces/File.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found
You are in a maze of twisty little passages, all alike.
While forcing the thunk for TyThing IsFile
which was lazily initialized by initIfaceCheck typecheckLoop,
I tried to tie the knot, but I couldn't find IsFile
in the current type environment.
If you are developing GHC, please read Note [Tying the knot]
and Note [Type-checking inside the knot].
Consider rebuilding GHC with profiling for a better stack trace.
Contents of current type environment: []
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
To compile this code you will need the `glib2-devel` package installed. To compile
```
$ cabal get gi-gio-2.0.12
$ cd gi-gio-2.0.12
$ cabal sandbox init
$ cabal install --dependencies-only
$ cabal build
```
I am running version `8.2.0.20170507`, from https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.2.1/ .
The same code compiles in versions `7.8.x`, `7.10.x` and `8.0.x`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| 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 while forcing the thunk for TyThing IsFile (regression)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(Apologies in advance for the very non-minimal testcase. I have been unsuccessfully trying to reduce the testcase for a few hours now, but I am flying blind, and the bug seems to depend on the interaction of various modules. The panic is very reproducible for me, so I figured that better reporting even if I failed to obtain a simplified testcase. Maybe someone else has more luck isolating the issue.)\r\n\r\nWhen compiling `gi-gio-2.0.12` I consistently get the following GHC panic:\r\n{{{\r\n[259 of 293] Compiling GI.Gio.Interfaces.File ( GI/Gio/Interfaces/File.hs, dist/build/GI/Gio/Interfaces/File.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.0.20170507 for x86_64-unknown-linux):\r\n\ttcIfaceGlobal (local): not found\r\n You are in a maze of twisty little passages, all alike.\r\n While forcing the thunk for TyThing IsFile\r\n which was lazily initialized by initIfaceCheck typecheckLoop,\r\n I tried to tie the knot, but I couldn't find IsFile\r\n in the current type environment.\r\n If you are developing GHC, please read Note [Tying the knot]\r\n and Note [Type-checking inside the knot].\r\n Consider rebuilding GHC with profiling for a better stack trace.\r\n Contents of current type environment: []\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nTo compile this code you will need the `glib2-devel` package installed. To compile\r\n{{{\r\n$ cabal get gi-gio-2.0.12\r\n$ cd gi-gio-2.0.12\r\n$ cabal sandbox init\r\n$ cabal install --dependencies-only\r\n$ cabal build\r\n}}}\r\n\r\nI am running version `8.2.0.20170507`, from https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.2.1/ .\r\n\r\nThe same code compiles in versions `7.8.x`, `7.10.x` and `8.0.x`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13802Installation of yesod-auth-1.4.13.2 fails with "ghc: panic! (the 'impossible'...2019-07-07T18:20:01ZnvbtInstallation of yesod-auth-1.4.13.2 fails with "ghc: panic! (the 'impossible' happened)"I wanted to install hledger-web via "stack install hledger-web" which runs until it hits (this is the full output of the command, emphasis \[+\] was added):
```
yesod-auth-1.4.13.2: configure
yesod-auth-1.4.13.2: build
Progress: 1/3
-- ...I wanted to install hledger-web via "stack install hledger-web" which runs until it hits (this is the full output of the command, emphasis \[+\] was added):
```
yesod-auth-1.4.13.2: configure
yesod-auth-1.4.13.2: build
Progress: 1/3
-- While building package yesod-auth-1.4.13.2 using:
/Users/manuel/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.22.5.0_ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /Users/manuel/.stack/global-project/.stack-work/logs/yesod-auth-1.4.13.2.log
Configuring yesod-auth-1.4.13.2...
Building yesod-auth-1.4.13.2...
Preprocessing library yesod-auth-1.4.13.2...
[ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o )
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:166:31: Warning:
Defaulting the following constraint(s) to type ‘Integer’
(Integral b0)
arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31
(Num b0)
arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33
In the first argument of ‘(-)’, namely ‘2 ^ 32’
In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’
In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:419:1: Warning:
Defined but not used: ‘toStrict’
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:422:1: Warning:
Defined but not used: ‘fromStrict’
[ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o )
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:23:1: Warning:
The import of ‘mappend’ from module ‘Data.Monoid’ is redundant
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:698:1: Warning:
Defined but not used: ‘croatianMessage’
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:459:1: Warning:
Pattern match(es) are overlapped
In an equation for ‘finnishMessage’: finnishMessage Password = ...
/private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:459:1: Warning:
Pattern match(es) are non-exhaustive
In an equation for ‘finnishMessage’:
Patterns not matched: CurrentPassword
[ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o )
[ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o )
[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/ghc34454_0/libghc_21.dylib, 5): no suitable image found. Did find:
/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/ghc34454_0/libghc_21.dylib: malformed mach-o: load commands size (35400) > 32768
[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I have tried this installation multiple times over the last weeks, and have always failed with this error message.
If any further assistance is needed I will be happy to help.
<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":"Installation of yesod-auth-1.4.13.2 fails with \"ghc: panic! (the 'impossible' happened)\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":["install","panic,","stack,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wanted to install hledger-web via \"stack install hledger-web\" which runs until it hits (this is the full output of the command, emphasis [+] was added):\r\n\r\n\r\n{{{\r\nyesod-auth-1.4.13.2: configure\r\nyesod-auth-1.4.13.2: build\r\nProgress: 1/3\r\n-- While building package yesod-auth-1.4.13.2 using:\r\n /Users/manuel/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.22.5.0_ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n Logs have been written to: /Users/manuel/.stack/global-project/.stack-work/logs/yesod-auth-1.4.13.2.log\r\n\r\n Configuring yesod-auth-1.4.13.2...\r\n Building yesod-auth-1.4.13.2...\r\n Preprocessing library yesod-auth-1.4.13.2...\r\n [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o )\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:166:31: Warning:\r\n Defaulting the following constraint(s) to type ‘Integer’\r\n (Integral b0)\r\n arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31\r\n (Num b0)\r\n arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33\r\n In the first argument of ‘(-)’, namely ‘2 ^ 32’\r\n In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’\r\n In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:419:1: Warning:\r\n Defined but not used: ‘toStrict’\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/PasswordStore.hs:422:1: Warning:\r\n Defined but not used: ‘fromStrict’\r\n [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o )\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:23:1: Warning:\r\n The import of ‘mappend’ from module ‘Data.Monoid’ is redundant\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:698:1: Warning:\r\n Defined but not used: ‘croatianMessage’\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:459:1: Warning:\r\n Pattern match(es) are overlapped\r\n In an equation for ‘finnishMessage’: finnishMessage Password = ...\r\n\r\n /private/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/stack34153/yesod-auth-1.4.13.2/Yesod/Auth/Message.hs:459:1: Warning:\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘finnishMessage’:\r\n Patterns not matched: CurrentPassword\r\n [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o )\r\n [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o )\r\n\r\n[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-apple-darwin):\r\n \tLoading temp shared object failed: dlopen(/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/ghc34454_0/libghc_21.dylib, 5): no suitable image found. Did find:\r\n \t/var/folders/36/cmdfg5j90vjgjww3qjnvhkhw0000gn/T/ghc34454_0/libghc_21.dylib: malformed mach-o: load commands size (35400) > 32768\r\n[++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]\r\n\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI have tried this installation multiple times over the last weeks, and have always failed with this error message.\r\n\r\nIf any further assistance is needed I will be happy to help.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13801Make -main-is work with {thing} from arbitrary installed packages2019-07-07T18:20:01ZSimon Hengelsol@typeful.netMake -main-is work with {thing} from arbitrary installed packages# TL;DR
Conceptually, `-main-is {thing}` is useful when writing unit tests. It allows you to test the code in your "Main" module by allowing you to use a different name for it.
But using it that way will always result in double compila...# TL;DR
Conceptually, `-main-is {thing}` is useful when writing unit tests. It allows you to test the code in your "Main" module by allowing you to use a different name for it.
But using it that way will always result in double compilation (that is, all your code has to be compiled twice, once for your executable and once for your test suite).
The reason for this is that `{thing}` has to be part of the currently compiled package (aka the `main` package). As a consequent, when using `-is-main`, it is not possible to define a library that is used by both the executable and the test suite.
I propose that `-main-is` is extended so that `{thing}` can be from any *installed package*.
I'll give a somewhat detailed motivation below. Please feel free to fast-forward to the last section, which gives a test case (or rather acceptance criteria) for this feature request.
# The full story
## How to unit test code without the use of `-main-is`
This section shows a common way to structure code for an executable, so that it is possible to:
1. write unit tests for all the code
1. avoid double compilation between the executable and the test suite
(for the reminder of this text I call these two properties *desirable properties*)
### Code as a library
Define all your code outside of `Main`, including your `main` function.
As an example, let's assume we define our code in `src/My/Awesome/Tool.hs`, which defines the module `My.Awesome.Tool` and a "main" function named `run` in it:
```hs
-- src/My/Awesome/Tool.hs
module My.Awesome.Tool where
run :: IO ()
run = do
...
```
### Tests that use the library
It is then possible to write tests for that code by importing the library module, e.g.:
```hs
-- test/Main.hs
module Main where
imports My.Awesome.Tool
main = do
-- unit tests go here
...
```
### Executable as a thin wrapper around the library code
To compile an actual executable we create a *driver*. The driver imports the library module and defines a `main` function. For our example this would looks something like this:
```hs
-- driver/Main.hs
module Main where
import My.Awesome.Tool (run)
main = run
```
**Note:** The driver does not define any non-trivial code. This is to retain our first desirable property.
### Compiling everything with Cabal
It is then possible to compile everything with Cabal, using a Cabal file similar to this one:
```
-- my-awesome-tool.cabal
name: my-awesome-tool
library
hs-source-dirs: src
exposed-modules: My.Awesome.Tool
test-suite test
type: exitcode-stdio-1.0
build-depends: my-awesome-tool
hs-source-dirs: test
main-is: Main.hs
executable my-awesome-tool
build-depends: my-awesome-tool
hs-source-dirs: driver
main-is: Main.hs
```
**Note:** Both, the executable and the test suite depend on the library component. This avoids double compilation, one of our desirable properties.
## Removing the need for a driver by using `-main-is`
It is possible to get rid of the need for a driver by using `-main-is`:
```
-- my-awesome-tool.cabal
...
executable my-awesome-tool
hs-source-dirs: src
main-is: My/Awesome/Tool.hs
ghc-options: -main-is My.Awesome.Tool.run
```
But doing so results in double compilation: The executable can no longer depend on the library component.
This is expected behavior, as stated in the documentation:
> Strictly speaking, `-main-is` is not a link-phase flag at all; it has no effect on the link step. The flag must be specified when compiling the module containing the specified main function
## Shortcomings of `-main-is`
According to the documentation, the purpose of `-main-is` is:
> When testing, it is often convenient to change which function is the “main” one, and the `-main-is` flag allows you to do so.
It is not very explicit what "when testing" refers to here, but for the lack of any other evidence I assume this refers to unit testing.
As far as I can tell, there is no way to use `-main-is` for unit testing without double compilation.
**Or in other words:** If we use `-main-is` for it's stated purpose we always loose the second of our desirable properties.
Please correct me if you think that I'm wrong.
## How is `-main-is` implemented?
I haven't looked at any code, but my assumption is that GHC generates a driver module, similar to the one we have to write by hand if we don't use `-main-is`. Can somebody confirm (or negate) this?
## Proposed change
I propose that GHC always generates the driver when `-main-is {thing}` is specified. GHC should even generate the driver if `{thing}` is not part of the currently compiled package (specifically `{thing}` is defined in an *installed package*, not the `main` package).
## (manual) test case
This test case uses my `hpack` package (but any package that defines some function of type `IO ()` should work):
```
$ cabal install hpack
$ ghc -package hpack -main-is Hpack.main -o hpack
```
### expected result
An executable named `hpack` is compiled that uses `Hpack.main` from the installed package `hpack` as entry point.
### actual result
```
ghc: no input files
Usage: For basic information, try the `--help' option.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| 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":"Make -main-is work with {thing} from arbitrary installed packages","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"= TL;DR\r\nConceptually, `-main-is {thing}` is useful when writing unit tests. It allows you to test the code in your \"Main\" module by allowing you to use a different name for it.\r\n\r\nBut using it that way will always result in double compilation (that is, all your code has to be compiled twice, once for your executable and once for your test suite).\r\n\r\nThe reason for this is that `{thing}` has to be part of the currently compiled package (aka the `main` package). As a consequent, when using `-is-main`, it is not possible to define a library that is used by both the executable and the test suite.\r\n\r\nI propose that `-main-is` is extended so that `{thing}` can be from any ''installed package''.\r\n\r\nI'll give a somewhat detailed motivation below. Please feel free to fast-forward to the last section, which gives a test case (or rather acceptance criteria) for this feature request.\r\n\r\n= The full story\r\n\r\n== How to unit test code without the use of {{{-main-is}}}\r\n\r\nThis section shows a common way to structure code for an executable, so that it is possible to:\r\n\r\n1. write unit tests for all the code\r\n1. avoid double compilation between the executable and the test suite\r\n\r\n(for the reminder of this text I call these two properties ''desirable properties'')\r\n\r\n=== Code as a library\r\nDefine all your code outside of `Main`, including your `main` function.\r\n\r\n\r\nAs an example, let's assume we define our code in `src/My/Awesome/Tool.hs`, which defines the module `My.Awesome.Tool` and a \"main\" function named `run` in it:\r\n\r\n\r\n{{{#!hs\r\n-- src/My/Awesome/Tool.hs\r\nmodule My.Awesome.Tool where\r\n\r\nrun :: IO ()\r\nrun = do\r\n ...\r\n}}}\r\n=== Tests that use the library\r\nIt is then possible to write tests for that code by importing the library module, e.g.:\r\n\r\n{{{#!hs\r\n-- test/Main.hs\r\nmodule Main where\r\n\r\nimports My.Awesome.Tool\r\n\r\nmain = do\r\n -- unit tests go here\r\n ...\r\n}}}\r\n=== Executable as a thin wrapper around the library code\r\n\r\nTo compile an actual executable we create a ''driver''. The driver imports the library module and defines a `main` function. For our example this would looks something like this:\r\n\r\n{{{#!hs\r\n-- driver/Main.hs\r\nmodule Main where\r\n\r\nimport My.Awesome.Tool (run)\r\n\r\nmain = run\r\n}}}\r\n\r\n'''Note:''' The driver does not define any non-trivial code. This is to retain our first desirable property.\r\n\r\n=== Compiling everything with Cabal\r\nIt is then possible to compile everything with Cabal, using a Cabal file similar to this one:\r\n\r\n{{{\r\n-- my-awesome-tool.cabal\r\nname: my-awesome-tool\r\n\r\nlibrary\r\n hs-source-dirs: src\r\n exposed-modules: My.Awesome.Tool\r\n\r\ntest-suite test\r\n type: exitcode-stdio-1.0\r\n build-depends: my-awesome-tool\r\n hs-source-dirs: test\r\n main-is: Main.hs\r\n\r\nexecutable my-awesome-tool\r\n build-depends: my-awesome-tool\r\n hs-source-dirs: driver\r\n main-is: Main.hs\r\n}}}\r\n\r\n'''Note:''' Both, the executable and the test suite depend on the library component. This avoids double compilation, one of our desirable properties.\r\n\r\n== Removing the need for a driver by using `-main-is`\r\nIt is possible to get rid of the need for a driver by using `-main-is`:\r\n{{{\r\n-- my-awesome-tool.cabal\r\n\r\n...\r\n\r\nexecutable my-awesome-tool\r\n hs-source-dirs: src\r\n main-is: My/Awesome/Tool.hs\r\n ghc-options: -main-is My.Awesome.Tool.run\r\n}}}\r\n\r\nBut doing so results in double compilation: The executable can no longer depend on the library component.\r\n\r\nThis is expected behavior, as stated in the documentation:\r\n\r\n> Strictly speaking, `-main-is` is not a link-phase flag at all; it has no effect on the link step. The flag must be specified when compiling the module containing the specified main function\r\n\r\n== Shortcomings of `-main-is`\r\n\r\nAccording to the documentation, the purpose of `-main-is` is:\r\n\r\n> When testing, it is often convenient to change which function is the “main” one, and the `-main-is` flag allows you to do so.\r\n\r\nIt is not very explicit what \"when testing\" refers to here, but for the lack of any other evidence I assume this refers to unit testing.\r\n\r\nAs far as I can tell, there is no way to use `-main-is` for unit testing without double compilation.\r\n\r\n'''Or in other words:''' If we use `-main-is` for it's stated purpose we always loose the second of our desirable properties.\r\n\r\nPlease correct me if you think that I'm wrong.\r\n\r\n== How is `-main-is` implemented?\r\nI haven't looked at any code, but my assumption is that GHC generates a driver module, similar to the one we have to write by hand if we don't use `-main-is`. Can somebody confirm (or negate) this?\r\n\r\n== Proposed change\r\nI propose that GHC always generates the driver when `-main-is {thing}` is specified. GHC should even generate the driver if `{thing}` is not part of the currently compiled package (specifically `{thing}` is defined in an ''installed package'', not the `main` package).\r\n\r\n== (manual) test case\r\n\r\nThis test case uses my `hpack` package (but any package that defines some function of type `IO ()` should work):\r\n\r\n{{{\r\n$ cabal install hpack\r\n$ ghc -package hpack -main-is Hpack.main -o hpack\r\n}}}\r\n\r\n=== expected result\r\n\r\nAn executable named `hpack` is compiled that uses `Hpack.main` from the installed package `hpack` as entry point.\r\n\r\n=== actual result\r\n\r\n{{{\r\nghc: no input files\r\nUsage: For basic information, try the `--help' option.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13800ghc panic: No skolem info: s_a7aK[sk]2019-07-07T18:20:02Zhexoghc panic: No skolem info: s_a7aK[sk]Project is located at: https://github.com/hacxman/clock.git
Uses Ivory and Tower framerworks.
Error should be introduced by code in commit SSD1306 api wrapper ( https://github.com/hacxman/clock/commit/8075047381e3bcc572c2c12ccf83fd9410e...Project is located at: https://github.com/hacxman/clock.git
Uses Ivory and Tower framerworks.
Error should be introduced by code in commit SSD1306 api wrapper ( https://github.com/hacxman/clock/commit/8075047381e3bcc572c2c12ccf83fd9410ee285f ) in file src/Clock/SSD1306.hs lines 32-67.
When I run make blink-test, this happens:
stack build . --exec 'blink-test-gen --src-dir=build/blink-test --const-fold --verbose'
clock-0.1.0.0: build
Preprocessing library clock-0.1.0.0...
\[5 of 7\] Compiling Clock.SSD1306 ( src/Clock/SSD1306.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Clock/SSD1306.o )
/home/mzatko/src/embedded/clock/src/Clock/SSD1306.hs:241:11: error:ghc: panic! (the 'impossible' happened)
> (GHC version 8.0.2 for x86_64-unknown-linux):
No skolem info: s_a7aK\[sk\]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building package clock-0.1.0.0 using:
/home/mzatko/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:clock exe:blink-test-gen exe:oled-test-gen --ghc-options " -ddump-hi -ddump-to-file"
> Process exited with code: ExitFailure 1
Makefile:50: recipe for target 'blink-test' failed
make: \*\*\* \[blink-test\] Error 1
<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":"ghc panic: No skolem info: s_a7aK[sk]","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Project is located at: https://github.com/hacxman/clock.git\r\nUses Ivory and Tower framerworks.\r\n\r\nError should be introduced by code in commit SSD1306 api wrapper ( https://github.com/hacxman/clock/commit/8075047381e3bcc572c2c12ccf83fd9410ee285f ) in file src/Clock/SSD1306.hs lines 32-67.\r\n\r\nWhen I run make blink-test, this happens:\r\nstack build . --exec 'blink-test-gen --src-dir=build/blink-test --const-fold --verbose'\r\nclock-0.1.0.0: build\r\nPreprocessing library clock-0.1.0.0...\r\n[5 of 7] Compiling Clock.SSD1306 ( src/Clock/SSD1306.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Clock/SSD1306.o )\r\n\r\n/home/mzatko/src/embedded/clock/src/Clock/SSD1306.hs:241:11: error:ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n\tNo skolem info: s_a7aK[sk]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n-- While building package clock-0.1.0.0 using:\r\n /home/mzatko/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:clock exe:blink-test-gen exe:oled-test-gen --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\nMakefile:50: recipe for target 'blink-test' failed\r\nmake: *** [blink-test] Error 1","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13799-ddump-splices prints out declarations in the wrong order2019-07-07T18:20:02ZRyan Scott-ddump-splices prints out declarations in the wrong order```hs
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| data A = A
data B = B
|])
$([d| deriving instance Eq A
deriving instance Eq B
|])
...```hs
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| data A = A
data B = B
|])
$([d| deriving instance Eq A
deriving instance Eq B
|])
```
```
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(6,3)-(8,6): Splicing declarations
[d| data A_a13D = A_a13E
data B_a13B = B_a13C |]
======>
data A_a3IA = A_a3IB
data B_a3IC = B_a3ID
Bug.hs:(10,3)-(12,6): Splicing declarations
[d| deriving instance Eq B
deriving instance Eq A |]
======>
deriving instance Eq A
deriving instance Eq B
```
Notice that it printed
```hs
[d| deriving instance Eq B
deriving instance Eq A |]
```
instead of
```hs
[d| deriving instance Eq A
deriving instance Eq B |]
```
which is what I originally wrote.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| 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":"-ddump-splices prints out declarations in the wrong order","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE StandaloneDeriving #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\n$([d| data A = A\r\n data B = B\r\n |])\r\n\r\n$([d| deriving instance Eq A\r\n deriving instance Eq B\r\n |])\r\n}}}\r\n\r\n{{{\r\nGHCi, version 8.0.2: 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:(6,3)-(8,6): Splicing declarations\r\n [d| data A_a13D = A_a13E\r\n data B_a13B = B_a13C |]\r\n ======>\r\n data A_a3IA = A_a3IB\r\n data B_a3IC = B_a3ID\r\nBug.hs:(10,3)-(12,6): Splicing declarations\r\n [d| deriving instance Eq B\r\n deriving instance Eq A |]\r\n ======>\r\n deriving instance Eq A\r\n deriving instance Eq B\r\n}}}\r\n\r\nNotice that it printed\r\n\r\n{{{#!hs\r\n [d| deriving instance Eq B\r\n deriving instance Eq A |]\r\n}}}\r\n\r\ninstead of\r\n\r\n{{{#!hs\r\n [d| deriving instance Eq A\r\n deriving instance Eq B |]\r\n}}}\r\n\r\nwhich is what I originally wrote.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13798Invalid transformation in simplOptExpr2019-07-07T18:20:02ZSimon Peyton JonesInvalid transformation in simplOptExprPrior to [this commit](https://git.haskell.org/ghc.git/commitdiff/1722fa106e10e63160bb2322e2ccb830fd5b9ab3), `CoreOpt.simple_opt_expr` transforms
```
case e of (b :: t1 ~# t2)
DEFAULT -> rhs
==>
rhs
```
That was plain ...Prior to [this commit](https://git.haskell.org/ghc.git/commitdiff/1722fa106e10e63160bb2322e2ccb830fd5b9ab3), `CoreOpt.simple_opt_expr` transforms
```
case e of (b :: t1 ~# t2)
DEFAULT -> rhs
==>
rhs
```
That was plain wrong when `e` diverges, or calls `error`. Hence the commit.
But the commit does this
```
case Coercible_sc e of (b :: t1 ~# t2)
DEFAULT -> rhs
==>
rhs
```
narrowing the scope of the transformation
to when the scrutinee is application of the Coercible superclass selector
```
Coercible_sc :: Coercible a b -> (a ~R# b)
```
Here's the code from `CoreOpt`:
```
| isDeadBinder b
, [(DEFAULT, _, rhs)] <- as
, isCoercionType (varType b)
, (Var fun, _args) <- collectArgs e
, fun `hasKey` coercibleSCSelIdKey
-- without this last check, we get #11230
= go rhs
```
But that's bizarrely ad-hoc. And, worse, it is flat-out wrong... what if `e` diverges?
It's not actually hurting anyone right now, but what we should
really do is use `exprOkForSpeculation`; and teach `exprOkForSpeculation`
how to deal with class-op selectors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Invalid transformation in simplOptExpr","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Prior to [https://git.haskell.org/ghc.git/commitdiff/1722fa106e10e63160bb2322e2ccb830fd5b9ab3 this commit], `CoreOpt.simple_opt_expr` transforms\r\n{{{\r\n case e of (b :: t1 ~# t2)\r\n DEFAULT -> rhs\r\n==>\r\n rhs\r\n}}}\r\nThat was plain wrong when `e` diverges, or calls `error`. Hence the commit.\r\n\r\nBut the commit does this\r\n{{{\r\n case Coercible_sc e of (b :: t1 ~# t2)\r\n DEFAULT -> rhs\r\n==>\r\n rhs\r\n}}}\r\nnarrowing the scope of the transformation\r\nto when the scrutinee is application of the Coercible superclass selector\r\n{{{\r\n Coercible_sc :: Coercible a b -> (a ~R# b)\r\n}}}\r\nHere's the code from `CoreOpt`:\r\n{{{\r\n | isDeadBinder b\r\n , [(DEFAULT, _, rhs)] <- as\r\n , isCoercionType (varType b)\r\n , (Var fun, _args) <- collectArgs e\r\n , fun `hasKey` coercibleSCSelIdKey\r\n -- without this last check, we get #11230\r\n = go rhs\r\n}}}\r\nBut that's bizarrely ad-hoc. And, worse, it is flat-out wrong... what if `e` diverges?\r\n\r\nIt's not actually hurting anyone right now, but what we should\r\nreally do is use `exprOkForSpeculation`; and teach `exprOkForSpeculation`\r\nhow to deal with class-op selectors.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13797Mark negation injective2020-03-17T22:19:50ZIcelandjackMark negation injective```hs
{-# Language DataKinds, TypeOperators, TypeFamilyDependencies, UndecidableInstances #-}
import GHC.TypeLits
data N = O | S N
type family
U (a :: Nat) = (res :: N) | res -> a where
U 0 = O
U n = S (U (n-1))
```
gives
```
...```hs
{-# Language DataKinds, TypeOperators, TypeFamilyDependencies, UndecidableInstances #-}
import GHC.TypeLits
data N = O | S N
type family
U (a :: Nat) = (res :: N) | res -> a where
U 0 = O
U n = S (U (n-1))
```
gives
```
olates injectivity annotation.
Type variable ‘n’ cannot be inferred from the right-hand side.
In the type family equation:
U n = 'S (U (n - 1)) -- Defined at /tmp/a.hs:37:3
• In the equations for closed type family ‘U’
In the type family declaration for ‘U’
Failed, modules loaded: none.
```
I expect this to work, this depends on making `(-)` injective which depends on ["generalized injectivity"](https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Futureplansandideas)?
```hs
type family
(a :: Nat) - (b :: Nat) = (res :: Nat) | a b -> res, res a -> b, res b -> a where
{- built in -}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Mark negation injective","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["InjectiveFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language DataKinds, TypeOperators, TypeFamilyDependencies, UndecidableInstances #-}\r\n\r\nimport GHC.TypeLits\r\n\r\ndata N = O | S N\r\n\r\ntype family\r\n U (a :: Nat) = (res :: N) | res -> a where\r\n U 0 = O\r\n U n = S (U (n-1))\r\n}}}\r\n\r\ngives\r\n\r\n{{{\r\nolates injectivity annotation.\r\n Type variable ‘n’ cannot be inferred from the right-hand side.\r\n In the type family equation:\r\n U n = 'S (U (n - 1)) -- Defined at /tmp/a.hs:37:3\r\n • In the equations for closed type family ‘U’\r\n In the type family declaration for ‘U’\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nI expect this to work, this depends on making `(-)` injective which depends on [https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Futureplansandideas \"generalized injectivity\"]?\r\n\r\n{{{#!hs\r\ntype family\r\n (a :: Nat) - (b :: Nat) = (res :: Nat) | a b -> res, res a -> b, res b -> a where\r\n {- built in -}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13796hard to embed custom manifest on windows2019-07-07T18:20:02Zjoeyhesshard to embed custom manifest on windowsI want to use a custom manifest file on windows to enable long filename support. I tried several ghc options to find a way to do it, and it does not seem easily possible to do this.
First I thought, let's use -fno-gen-manifest, and sinc...I want to use a custom manifest file on windows to enable long filename support. I tried several ghc options to find a way to do it, and it does not seem easily possible to do this.
First I thought, let's use -fno-gen-manifest, and since ghc generates foo.exe.manifest when building foo.hs, I'll provide a file with that name and it'll pick it up. But it seems that -fno-gen-manifest implies -fno-embed-manifest, so it didn't run windres, and this didn't work.
Then I tried using -optwindres, hoping to pass windres -i foo.rc, and make that file point to my custom manifest. But, despite being documented as options that are passed to windres, -optwindres actually adds to the end of the windres --preprocessor option, so this caused it to run windres --preprocessor "gcc.exe ... -i foo.rc"
The only remaining option seems to be to use -pgmwindres with a wrapper program that runs windres with the options I want. It seemed easier to file a ghc bug at this point..
I feel that the best fix would be either to still run windres when -fno-gen-manifest is used, or to add a new option like -fuse-custom-manifest-file=filename
<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":"hard to embed custom manifest on windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to use a custom manifest file on windows to enable long filename support. I tried several ghc options to find a way to do it, and it does not seem easily possible to do this.\r\n\r\nFirst I thought, let's use -fno-gen-manifest, and since ghc generates foo.exe.manifest when building foo.hs, I'll provide a file with that name and it'll pick it up. But it seems that -fno-gen-manifest implies -fno-embed-manifest, so it didn't run windres, and this didn't work.\r\n\r\nThen I tried using -optwindres, hoping to pass windres -i foo.rc, and make that file point to my custom manifest. But, despite being documented as options that are passed to windres, -optwindres actually adds to the end of the windres --preprocessor option, so this caused it to run windres --preprocessor \"gcc.exe ... -i foo.rc\"\r\n\r\nThe only remaining option seems to be to use -pgmwindres with a wrapper program that runs windres with the options I want. It seemed easier to file a ghc bug at this point..\r\n\r\nI feel that the best fix would be either to still run windres when -fno-gen-manifest is used, or to add a new option like -fuse-custom-manifest-file=filename","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13795:kind! is not expanding type synonyms anymore2020-11-03T12:17:31ZHjulle:kind! is not expanding type synonyms anymoreGiven
```hs
type A = ()
:kind! A
```
Expected result:
```hs
A :: *
= ()
```
Actual result:
```hs
A :: *
= A
```
----
Some IRC conversation on the topic (on \#ghc):
```
23:37 < hjulle> :kind! does not seem to expand type synonyms ...Given
```hs
type A = ()
:kind! A
```
Expected result:
```hs
A :: *
= ()
```
Actual result:
```hs
A :: *
= A
```
----
Some IRC conversation on the topic (on \#ghc):
```
23:37 < hjulle> :kind! does not seem to expand type synonyms for me (in GHC 8.0.2), it just prints them
verbatim. Does anyone else have this problem? Example: "type A = ()" ":kind! A" will print out "A :: * = A" (which is not very helpful).
23:40 < hjulle> Is this a bug? The documentation
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:kind)
explicitly states that :kind! should expand type synonyms, so I think yes?
23:57 < RyanGlScott> hjulle: That's absolute a bug. File a ticket!
23:57 < RyanGlScott> *absolutely
23:58 < RyanGlScott> Moreover, I know why that's happening
23:59 < RyanGlScott> Internally, :kind! uses the normalise_type function to reduce type families:
http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/FamInstEnv.hs#l1408
23:59 < RyanGlScott> But see the comment there
Day changed to 07 jun 2017
00:00 < RyanGlScott> -- Try to not to disturb type synonyms if possible
00:01 < RyanGlScott> So fixing this would just be a matter of calling coreView afterwards (which expands
type synonyms)
00:02 < RyanGlScott> er, actually, expandTypeSynonyms is even better:
http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/Type.hs#l364
```
<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 | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":":kind! is not expanding type synonyms anymore","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Given\r\n{{{#!hs\r\ntype A = ()\r\n:kind! A\r\n}}}\r\n\r\nExpected result:\r\n{{{#!hs\r\nA :: *\r\n= ()\r\n}}}\r\n\r\nActual result:\r\n{{{#!hs\r\nA :: *\r\n= A\r\n}}}\r\n\r\n----\r\n\r\nSome IRC conversation on the topic (on #ghc):\r\n{{{\r\n23:37 < hjulle> :kind! does not seem to expand type synonyms for me (in GHC 8.0.2), it just prints them\r\n verbatim. Does anyone else have this problem? Example: \"type A = ()\" \":kind! A\" will print out \"A :: * = A\" (which is not very helpful).\r\n23:40 < hjulle> Is this a bug? The documentation\r\n (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:kind)\r\n explicitly states that :kind! should expand type synonyms, so I think yes?\r\n23:57 < RyanGlScott> hjulle: That's absolute a bug. File a ticket!\r\n23:57 < RyanGlScott> *absolutely\r\n23:58 < RyanGlScott> Moreover, I know why that's happening\r\n23:59 < RyanGlScott> Internally, :kind! uses the normalise_type function to reduce type families:\r\nhttp://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/FamInstEnv.hs#l1408\r\n23:59 < RyanGlScott> But see the comment there\r\nDay changed to 07 jun 2017\r\n00:00 < RyanGlScott> -- Try to not to disturb type synonyms if possible\r\n00:01 < RyanGlScott> So fixing this would just be a matter of calling coreView afterwards (which expands\r\n type synonyms)\r\n00:02 < RyanGlScott> er, actually, expandTypeSynonyms is even better:\r\nhttp://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/Type.hs#l364\r\n\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13794Stack update failed2019-07-07T18:20:03ZstevenspasboStack update failedStacktrace asked me to report this as a bug:
```shell
[1 of 1] Compiling Main ( /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/Setup.hs, /private/var/folders/yx/scmdmrjx25vf6y18kgl_sq...Stacktrace asked me to report this as a bug:
```shell
[1 of 1] Compiling Main ( /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/Setup.hs, /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )
Linking /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...
Configuring stack-1.4.0...
stack-1.4.0: build
Preprocessing library stack-1.4.0...
[ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )
[ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o )
[ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o )
[ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )
[ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )
[ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )
[ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )
[ 8 of 124] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )
[ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )
[ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )
[ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib, 5): no suitable image found. Did find:
/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib: malformed mach-o: load commands size (50752) > 32768
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Completed 26 action(s).
-- While building package stack-1.4.0 using:
/private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stack update failed","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Stacktrace asked me to report this as a bug:\r\n\r\n{{{#!shell\r\n[1 of 1] Compiling Main ( /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/Setup.hs, /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )\r\nLinking /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...\r\nConfiguring stack-1.4.0...\r\nstack-1.4.0: build\r\nPreprocessing library stack-1.4.0...\r\n[ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )\r\n[ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o )\r\n[ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o )\r\n[ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )\r\n[ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )\r\n[ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )\r\n[ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )\r\n[ 8 of 124] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )\r\n[ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )\r\n[ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )\r\n[ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-apple-darwin):\r\n Loading temp shared object failed: dlopen(/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib, 5): no suitable image found. Did find:\r\n /var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib: malformed mach-o: load commands size (50752) > 32768\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nCompleted 26 action(s).\r\n\r\n-- While building package stack-1.4.0 using:\r\n /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack-upgrade71650/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13793Simple program trips checkNurserySanity()2019-07-07T18:20:03ZniteriaSimple program trips checkNurserySanity()Error:
```
Repro: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 713
(GHC version 8.3.20170606 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Repro steps:
-...Error:
```
Repro: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 713
(GHC version 8.3.20170606 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Repro steps:
- Add `GhcRTSWays += thr_debug` to `mk/build.mk` to build threaded debug runtime
```
inplace/bin/ghc-stage2 -fforce-recomp -debug -rtsopts -threaded -main-is Repro Repro.hs
./Repro +RTS -A16m -DS
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simple program trips checkNurserySanity()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Error:\r\n{{{\r\nRepro: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 713\r\n\r\n (GHC version 8.3.20170606 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\nRepro steps:\r\n* Add `GhcRTSWays += thr_debug` to `mk/build.mk` to build threaded debug runtime\r\n{{{\r\ninplace/bin/ghc-stage2 -fforce-recomp -debug -rtsopts -threaded -main-is Repro Repro.hs\r\n./Repro +RTS -A16m -DS\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.3Simon MarlowSimon Marlow