GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-05-25T17:17:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12562GHC panic on rebuild (idInfo r_XsTP)2021-05-25T17:17:59ZMoritz KieferGHC panic on rebuild (idInfo r_XsTP)### Steps to reproduce
```
git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic
cd llvm-general
cabal new-build llvm-general
curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2...### Steps to reproduce
```
git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic
cd llvm-general
cabal new-build llvm-general
curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch > out.patch
git apply out.patch
cabal new-build llvm-general
```
The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes).
### Output
```
In order, the following will be built (use -v for more details):
llvm-general-3.8.0.0
Preprocessing library llvm-general-3.8.0.0...
[84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o )
[85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed]
[89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH]
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
idInfo r_XsTP
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
### Comments
In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help.8.0.2Moritz KieferMoritz Kieferhttps://gitlab.haskell.org/ghc/ghc/-/issues/12559Don't ignore addTopDecls in module finalizers2019-07-07T18:26:06ZFacundo DomínguezDon't ignore addTopDecls in module finalizersThe following program fails to compile because `f` is not found.
```
-- main.hs
import M
main = print (f 0)
```
```
-- M.hs
{-# LANGUAGE TemplateHaskell #-}
module M where
import Language.Haskell.TH.Syntax
g :: IO ()
g = $(do addMod...The following program fails to compile because `f` is not found.
```
-- main.hs
import M
main = print (f 0)
```
```
-- M.hs
{-# LANGUAGE TemplateHaskell #-}
module M where
import Language.Haskell.TH.Syntax
g :: IO ()
g = $(do addModFinalizer (do d <- [d| f x = (2 :: Int) |]; addTopDecls d)
[| return ()|]
)
```
```
$ runghc main.hs
main.hs:3:15: Not in scope: ‘f’
```
This bug is problematic to produce top-level declarations which depend on the output of `reify` for local variables, which can only run in a finalizer.8.0.2Facundo DomínguezFacundo Domínguezhttps://gitlab.haskell.org/ghc/ghc/-/issues/12558GHCi Segmentation fault/access violation in generated code2019-07-07T18:26:06ZlazacGHCi Segmentation fault/access violation in generated codeGHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [Haskell Tools project](https://github.com/haskell-tools/haskell-tools) from GHCi. The program can be ...GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [Haskell Tools project](https://github.com/haskell-tools/haskell-tools) from GHCi. The program can be successfully compiled with the ghc compiler.
The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone.
I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff.
To try out use a minimal program:
```hs
module Main where
import Language.Haskell.Tools.Refactor
main = demoRefactor "" "." "A"
```
Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr
c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root.
That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem:
```hs
module A where
```
PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi Segmentation fault/access violation in generated code","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler.\r\n\r\nThe cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone.\r\n\r\nI can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff.\r\n\r\nTo try out use a minimal program:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport Language.Haskell.Tools.Refactor\r\n\r\nmain = demoRefactor \"\" \".\" \"A\"\r\n}}}\r\n\r\nExecute the `ghci -package ghc -isrc\\ast;src\\ast-ghc;sr\r\nc\\ast-trf;src\\ast-ppr;src\\ast-gen;src\\refactor;src Main` command from the project root.\r\n\r\nThat will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem:\r\n\r\n{{{#!hs\r\nmodule A where\r\n}}}\r\n\r\n\r\nPS: I tried to create a smaller example, but the problem just appears and disappears without \"reason\" when I try to modify the code. (For example importing a module that is not actually used.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12557Regression in type inference with RankNTypes2019-07-07T18:26:07ZslindleyRegression in type inference with RankNTypesConsider the following code:
```hs
{-# LANGUAGE RankNTypes #-}
module Test where
foo :: ((forall a.f a) -> f r) -> f r
foo g = undefined
```
In GHC 7.10.3:
```
*Main> :t \g -> foo g
\g -> foo g :: ((forall a. f a) -> f r) -> f r
```
...Consider the following code:
```hs
{-# LANGUAGE RankNTypes #-}
module Test where
foo :: ((forall a.f a) -> f r) -> f r
foo g = undefined
```
In GHC 7.10.3:
```
*Main> :t \g -> foo g
\g -> foo g :: ((forall a. f a) -> f r) -> f r
```
In GHC 8.0.1:
```
*Main> :t \g -> foo g
<interactive>:1:11: error:
• Couldn't match expected type ‘(forall a. f a) -> f r’
with actual type ‘t’
‘t’ is a rigid type variable bound by
the inferred type of it :: t -> f r at <interactive>:1:1
• In the first argument of ‘foo’, namely ‘g’
In the expression: foo g
In the expression: \ g -> foo g
• Relevant bindings include g :: t (bound at <interactive>:1:2)
```https://gitlab.haskell.org/ghc/ghc/-/issues/12555bindist configure checks involving the compiler are broken2019-07-07T18:26:07Zrwbartonbindist configure checks involving the compiler are brokenCommit 6554dc60304bbd4b2edb93be7e1658bff237e067 added this code to `distrib/configure.ac.in`:
```
BinDistNeedsLibdw=@HaveLibdw@
if test "x$BinDistNeedsLibdw" = "xyes" ; then
AC_CHECK_LIB(dw, dwfl_attach_state, [HaveLibdw=YES],
...Commit 6554dc60304bbd4b2edb93be7e1658bff237e067 added this code to `distrib/configure.ac.in`:
```
BinDistNeedsLibdw=@HaveLibdw@
if test "x$BinDistNeedsLibdw" = "xyes" ; then
AC_CHECK_LIB(dw, dwfl_attach_state, [HaveLibdw=YES],
[AC_MSG_ERROR([Binary distribution was built with libdw support but target system doesn't have supported libdw version (needs at least 0.158)])]
)];
fi
```
It occurs before any other autoconf command involving the compiler. So apparently the expansion of `AC_CHECK_LIB` includes the code responsible for checking how to invoke the compiler, checking the object file suffix, etc. (Yes, this is a crazy way to do it.) Since the official bindist has `BinDistNeedsLibdw=NO`, none of that code ever actually runs.
Later (in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`) the configure script uses ` AC_COMPILE_IFELSE` to check for features of the compiler like non-executable stack support, but these checks are broken because autoconf never actually determined basic information about the compiler. So the 8.0.1 bindist produces binaries with executable stacks, which is a problem on some systems.
It would be better anyways to move this `AC_CHECK_LIB` later in `distrib/configure.ac.in`, to after where we select flags to be used when invoking the compiler. There are also some other bugs in this code: there is an extra `];` and the correct value of `BinDistNeedsLibdw` is `YES` (not `yes`) so the code currently can never run anyways.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"bindist configure checks involving the compiler are broken","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":"Commit 6554dc60304bbd4b2edb93be7e1658bff237e067 added this code to `distrib/configure.ac.in`:\r\n{{{\r\nBinDistNeedsLibdw=@HaveLibdw@\r\nif test \"x$BinDistNeedsLibdw\" = \"xyes\" ; then\r\n AC_CHECK_LIB(dw, dwfl_attach_state, [HaveLibdw=YES],\r\n [AC_MSG_ERROR([Binary distribution was built with libdw support but target system doesn't have supported libdw version (needs at least 0.158)])]\r\n )];\r\nfi\r\n}}}\r\nIt occurs before any other autoconf command involving the compiler. So apparently the expansion of `AC_CHECK_LIB` includes the code responsible for checking how to invoke the compiler, checking the object file suffix, etc. (Yes, this is a crazy way to do it.) Since the official bindist has `BinDistNeedsLibdw=NO`, none of that code ever actually runs.\r\n\r\nLater (in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`) the configure script uses ` AC_COMPILE_IFELSE` to check for features of the compiler like non-executable stack support, but these checks are broken because autoconf never actually determined basic information about the compiler. So the 8.0.1 bindist produces binaries with executable stacks, which is a problem on some systems.\r\n\r\nIt would be better anyways to move this `AC_CHECK_LIB` later in `distrib/configure.ac.in`, to after where we select flags to be used when invoking the compiler. There are also some other bugs in this code: there is an extra `];` and the correct value of `BinDistNeedsLibdw` is `YES` (not `yes`) so the code currently can never run anyways.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12554Testsuite exhibits large amount of framework failures2019-07-07T18:26:07ZTamar ChristinaTestsuite exhibits large amount of framework failuresI've tried this on multiple computers and they all have the same issue.
I get around 400 testsuite failures with the error:
```
r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-inter...I've tried this on multiple computers and they all have the same issue.
I get around 400 testsuite failures with the error:
```
r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run')
r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run')
```
What they all have in common is that they are all using the latest MSYS2 and tools:
```
Tamar@Squid MINGW64 ~/ghc
$ python3 --version
Python 3.5.2
Tamar@Squid MINGW64 ~/ghc
$ uname -a
MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Testsuite exibits large amount of framework failures","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried this on multiple computers and they all have the same issue.\r\n\r\nI get around 400 testsuite failures with the error:\r\n\r\n{{{\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run')\r\n r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run')\r\n}}}\r\n\r\nWhat they all have in common is that they are all using the latest MSYS2 and tools:\r\n\r\n{{{\r\nTamar@Squid MINGW64 ~/ghc\r\n$ python3 --version\r\nPython 3.5.2\r\n\r\nTamar@Squid MINGW64 ~/ghc\r\n$ uname -a\r\nMINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12553Reference kind in a type instance declaration defined in another instance dec...2019-07-07T18:26:08ZIcelandjackReference kind in a type instance declaration defined in another instance declarationOld code:
```hs
data Full :: Type -> Type
data AST :: (Type -> Type) -> (Type -> Type)
-- ASTF :: (Type -> Type) -> (Type -> Type)
type ASTF dom a = AST dom (Full a)
class Syntactic a where
type Domain a :: Type -> Type
type In...Old code:
```hs
data Full :: Type -> Type
data AST :: (Type -> Type) -> (Type -> Type)
-- ASTF :: (Type -> Type) -> (Type -> Type)
type ASTF dom a = AST dom (Full a)
class Syntactic a where
type Domain a :: Type -> Type
type Internal a :: Type
desugar :: a -> ASTF (Domain a) (Internal a)
sugar :: ASTF (Domain a) (Internal a) -> a
```
----
New code with richer kinds
```hs
data Sig a = Full a | a :-> Sig a
data AST :: (Sig a -> Type) -> (Sig a -> Type)
data Sig a = Full a | a :-> Sig a
-- ASTF :: (Sig a -> Type) -> (a -> Type)
type ASTF dom a = AST dom (Full a)
class Syntactic a where
type Domain a :: Sig Type -> Type
type Internal a :: Type
desugar :: a -> ASTF (Domain a) (Internal a)
sugar :: ASTF (Domain a) (Internal a) -> a
```
As the type of `ASTF` hints at it could accept arguments of kind `Sig a -> Type` and `a`. I would like to reference the variable `a` from the kind of `Domain` in the kind of `Internal`, but this fails:
```hs
-- • Kind variable ‘u’ is implicitly bound in datatype
-- ‘Internal’, but does not appear as the kind of any
-- of its type variables. Perhaps you meant
-- to bind it (with TypeInType) explicitly somewhere?
-- Type variables with inferred kinds: a
-- • In the class declaration for ‘Syntactic’
class Syntactic a where
type Domain a :: Sig u -> Type
type Internal a :: u
desugar :: a -> ASTF (Domain a) (Internal a)
sugar :: ASTF (Domain a) (Internal a) -> a
```
----
Should the `u` in the kind of `Domain a` be quantified over (which makes this compile)?
```hs
type Domain a :: forall k. Sig k -> Type
```
- \*Edit\*\*: This doesn't work.https://gitlab.haskell.org/ghc/ghc/-/issues/12552Merge OpenBSD fixes2019-07-07T18:26:08ZBen GamariMerge OpenBSD fixesMerge the following to `ghc-8.0`,
- f9aa996f0af59f32dc7b1528ff78be41413a9c27Merge the following to `ghc-8.0`,
- f9aa996f0af59f32dc7b1528ff78be41413a9c278.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12550Inconsistent unicode display for kinds2019-07-07T18:26:08ZjohnleoInconsistent unicode display for kindsWith `:set -fprint-unicode-syntax`, the kind `*` should always be printed as `★`. However the output is extremely inconsistent. Here are a few examples from ghci, and I will add more as I run across them.
```
:t fmap
fmap ∷ ∀ {f ∷ ★ → ★...With `:set -fprint-unicode-syntax`, the kind `*` should always be printed as `★`. However the output is extremely inconsistent. Here are a few examples from ghci, and I will add more as I run across them.
```
:t fmap
fmap ∷ ∀ {f ∷ ★ → ★} {a} {b}. Functor f ⇒ (a → b) → f a → f b
:i fmap
class Functor (f ∷ * → *) where
fmap ∷ forall a b. (a → b) → f a → f b
-- (note that forall is also not displayed properly as ∀ here)
:k Functor
Functor ∷ (★ → ★) → Constraint
:m + GHC.Generics
:i Functor
-- (among other output)
instance ∀ (f ∷ * → ★). Functor f ⇒ Functor (Rec1 f)
-- Defined in ‘GHC.Generics’
instance Functor Par1 -- Defined in ‘GHC.Generics’
instance ∀ i (c ∷ Meta) (f ∷ * → ★). Functor f ⇒ Functor (M1 i c f)
-- Defined in ‘GHC.Generics’
instance ∀ i c. Functor (K1 i c) -- Defined in ‘GHC.Generics’
instance ∀ (f ∷ * → ★) (g ∷ * → *).
(Functor f, Functor g) ⇒
Functor (f :.: g)
-- Defined in ‘GHC.Generics’
instance ∀ (f ∷ * → ★) (g ∷ * → ★).
(Functor f, Functor g) ⇒
Functor (f :+: g)
-- Defined in ‘GHC.Generics’
instance ∀ (f ∷ * → ★) (g ∷ * → ★).
(Functor f, Functor g) ⇒
Functor (f :*: g)
-- Defined in ‘GHC.Generics’
:t datatypeName
datatypeName
∷ ∀ {d} {t ∷ ★ → (* → *) → ★ → ★} {f ∷ * → *} {a}.
Datatype ★ d ⇒
t d f a → [Char]
:i datatypeName
class Datatype k (d ∷ k) where
datatypeName ∷ forall {k1} (t ∷ k → (* → *) → k1 → *) (f ∷ *
→ *) (a ∷ k1).
t d f a → [Char]
...
-- Defined in ‘GHC.Generics’
:t (:*:)
(:*:) ∷ ∀ {g ∷ ★ → *} {p} {f ∷ ★ → *}. f p → g p → (:*:) ★ f g p
-- Note that ★ and * are reversed from what :i displays!
```
Note that `:t datatypeName` causes a panic in 8.1; I have filed a separate bug [https://ghc.haskell.org/trac/ghc/ticket/12549](https://ghc.haskell.org/trac/ghc/ticket/12549)8.2.1johnleojohnleohttps://gitlab.haskell.org/ghc/ghc/-/issues/12549Panic on ":t datatypeName"2019-07-07T18:26:09ZjohnleoPanic on ":t datatypeName"Reproduction:
```
GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/leo/.ghci
Prelude> :m + GHC.Generics
:m + GHC.Generics
Prelude GHC.Generics> :t datatypeName
:t datatypeName
gh...Reproduction:
```
GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/leo/.ghci
Prelude> :m + GHC.Generics
:m + GHC.Generics
Prelude GHC.Generics> :t datatypeName
:t datatypeName
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160826 for x86_64-apple-darwin):
ASSERT failed!
CallStack (from HasCallStack):
assertPprPanic, called at compiler/types/TyCoRep.hs:2094:44 in ghc:TyCoRep
checkValidSubst, called at compiler/types/TyCoRep.hs:2122:17 in ghc:TyCoRep
substTy, called at compiler/typecheck/TcMType.hs:793:24 in ghc:TcMType
in_scope InScope {k1_a1X8}
tenv [a1X0 :-> k1_a1X8[tau:3]]
cenv []
tys [k_a1X4[tau:3] → (k1_a1X0 → *) → k1_a1X0 → ★]
cos []
needInScope [a1X4 :-> k_a1X4[tau:3]]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.2.1johnleojohnleohttps://gitlab.haskell.org/ghc/ghc/-/issues/12548Exported pattern synonyms does not mark top-level bindings in RHS as used2019-07-07T18:26:09ZpkmxExported pattern synonyms does not mark top-level bindings in RHS as used```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo (pattern P) where
x :: Int
x = 0
pattern P :: Int
pattern P <- _ where
P = x
```
gives:
```
Foo.hs:6:1: warning: [-Wunused-top-binds]
Defined but not used: ‘x’
```
<deta...```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo (pattern P) where
x :: Int
x = 0
pattern P :: Int
pattern P <- _ where
P = x
```
gives:
```
Foo.hs:6:1: warning: [-Wunused-top-binds]
Defined but not used: ‘x’
```
<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":"Exported pattern synonyms does not mark top-level bindings in RHS as used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\nmodule Foo (pattern P) where\r\n\r\nx :: Int\r\nx = 0\r\n\r\npattern P :: Int\r\npattern P <- _ where\r\n P = x\r\n}}}\r\n\r\ngives:\r\n\r\n{{{\r\nFoo.hs:6:1: warning: [-Wunused-top-binds]\r\n Defined but not used: ‘x’\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12546GeneralizedNewtypeDeriving produces error messages with incorrect kind signat...2019-07-07T18:26:09ZAlexis KingGeneralizedNewtypeDeriving produces error messages with incorrect kind signaturesGiven the following program:
```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleInstances #-}
import Control.Monad.Reader
newtype AppM a = AppM (ReaderT Int IO a)
deriving (Functor, Applicative, Monad, Monad...Given the following program:
```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleInstances #-}
import Control.Monad.Reader
newtype AppM a = AppM (ReaderT Int IO a)
deriving (Functor, Applicative, Monad, MonadReader)
```
The `MonadReader` deriving declaration should be `MonadReader Int`. GHC produces the following error message:
```
• Expecting one more argument to ‘MonadReader’
Expected kind ‘* -> Constraint’,
but ‘MonadReader’ has kind ‘* -> (* -> *) -> Constraint’
• In the newtype declaration for ‘AppM’
```
This error message is confusing to me. The kind of `MonadReader` is `* -> (* -> *) -> Constraint`, as the error message states, which makes sense. However, the error message states that it expects kind `* -> Constraint`, despite the fact that `MonadReader Int` is actually of kind `(* -> *) -> Constraint`.
,,(This description is adapted from [this Stack Overflow question](http://stackoverflow.com/q/39172590/465378).),,8.0.2mniipmniiphttps://gitlab.haskell.org/ghc/ghc/-/issues/12545Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists ...2019-07-07T18:26:09Zmikhail.vorozhtsovCompilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:
```
$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rgh...After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:
```
$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>>
real 0m20.160s
user 0m19.937s
sys 0m0.197s
$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>>
real 2m10.195s
user 2m9.773s
sys 0m0.400s
```
Both versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well.
It is worth mentioning that turning off optimization makes the problem disappear:
```
$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>>
real 0m3.593s
user 0m3.507s
sys 0m0.073s
```
<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":"Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)","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":"After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:\r\n\r\n{{{\r\n$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>>\r\n\r\nreal\t0m20.160s\r\nuser\t0m19.937s\r\nsys\t0m0.197s\r\n$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>>\r\n\r\nreal\t2m10.195s\r\nuser\t2m9.773s\r\nsys\t0m0.400s\r\n}}}\r\n\r\nBoth versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well.\r\n\r\nIt is worth mentioning that turning off optimization makes the problem disappear:\r\n{{{\r\n$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>>\r\n\r\nreal\t0m3.593s\r\nuser\t0m3.507s\r\nsys\t0m0.073s\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12544Improved warning for redundant-constraints2019-07-07T18:26:10ZEric CrockettImproved warning for redundant-constraintsCurrently,
```
foo :: (Num a, Integral a) => a -> a
foo = id
```
produces the warning
```
Main.hs:1:1: warning: [-Wredundant-constraints]
• Redundant constraints: (Num a, Integral a)
• In the type signature for:
foo...Currently,
```
foo :: (Num a, Integral a) => a -> a
foo = id
```
produces the warning
```
Main.hs:1:1: warning: [-Wredundant-constraints]
• Redundant constraints: (Num a, Integral a)
• In the type signature for:
foo :: (Num a, Integral a) => a -> a
```
Since GHC can detect there is a redundancy, it would be nice it also told me which constraint was redundant. In #9939, I suggested that the warning include something to the effect of `(Num a) is implied by (Integral a)`. Lets make this as easy for the user as possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"Improved warning for redundant-constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, \r\n\r\n{{{\r\nfoo :: (Num a, Integral a) => a -> a\r\nfoo = id\r\n}}}\r\n\r\nproduces the warning\r\n\r\n{{{\r\nMain.hs:1:1: warning: [-Wredundant-constraints]\r\n • Redundant constraints: (Num a, Integral a)\r\n • In the type signature for:\r\n foo :: (Num a, Integral a) => a -> a\r\n}}}\r\n\r\nSince GHC can detect there is a redundancy, it would be nice it also told me which constraint was redundant. In #9939, I suggested that the warning include something to the effect of `(Num a) is implied by (Integral a)`. Lets make this as easy for the user as possible.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12539Possible typo causes Stack and Cabal installs to fail2019-07-07T18:26:10ZConorIAPossible typo causes Stack and Cabal installs to failHi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc.
However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC.
...Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc.
However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC.
The gist of the error thrown when using wither Cabal or Stack is:
```
<no location info>:
Warning: Couldn't figure out linker information!
Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc.
gcc: error: unrecognized command line option '-nopie'; did you mean '-no-pie'?
)
```
I am not sure where the error is, as I am really a non-expert. But the gcc linking option is "-no-pie", so if there is indeed an option "-nopie" being passed, it seems like it is a typo.
<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":"Possible typo causes Stack and Cabal installs to fail","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":"Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc. \r\n\r\nHowever, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC. \r\n\r\nThe gist of the error thrown when using wither Cabal or Stack is: \r\n\r\n{{{\r\n<no location info>:\r\nWarning: Couldn't figure out linker information!\r\nMake sure you're using GNU ld, GNU gold or the built in OS X linker, etc.\r\ngcc: error: unrecognized command line option '-nopie'; did you mean '-no-pie'?\r\n)\r\n}}}\r\n\r\nI am not sure where the error is, as I am really a non-expert. But the gcc linking option is \"-no-pie\", so if there is indeed an option \"-nopie\" being passed, it seems like it is a typo. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12538Incorrect usage of overlapping instances and data families sends GHC into loop2019-07-07T18:26:11ZpkmxIncorrect usage of overlapping instances and data families sends GHC into loopSorry for the lack of descriptive title as I can't nail down the source of the bug. This is the minimal example to trigger the loop:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{...Sorry for the lack of descriptive title as I can't nail down the source of the bug. This is the minimal example to trigger the loop:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module Main where
data Tagged t a = Tagged a
type family Tag a where
Tag (Tagged t a) = Tagged t a
Tag a = Tagged Int a
class (r ~ Tag a) => TagImpl a r | a -> r where
tag :: a -> r
instance {-# OVERLAPPING #-} (r ~ Tag (Tagged t a)) => TagImpl (Tagged t a) r where
tag = id
#ifdef WRONG
instance {-# OVERLAPPING #-} (r ~ Tagged t a, r ~ Tag a) => TagImpl a r where
#else
instance {-# OVERLAPPING #-} (r ~ Tagged Int a, r ~ Tag a) => TagImpl a r where
#endif
tag = Tagged @Int
data family DF x
data instance DF (Tagged t a) = DF (Tagged t a)
class ToDF a b | a -> b where
df :: a -> b
#ifdef WRONG
instance (TagImpl a a', b ~ DF a') => ToDF a b where
#else
instance (TagImpl a (Tagged t a'), b ~ DF (Tagged t a')) => ToDF a b where
#endif
df = DF . tag
main :: IO ()
main = pure ()
```
When compiled with `-DWRONG`, it causes GHC (both 8.0.1 and HEAD\@20160823) to loop:
```
$ ghc --version && ghc -fno-code Main.hs -DWRONG
The Glorious Glasgow Haskell Compilation System, version 8.1.20160823
[1 of 1] Compiling Main ( Main.hs, nothing )
(loops indefinitely...)
```https://gitlab.haskell.org/ghc/ghc/-/issues/12537Parallel cabal builds Segmentation Fault on PowerPC 64-bit2019-07-07T18:26:11ZmichelmnoParallel cabal builds Segmentation Fault on PowerPC 64-bitas detailed in attached log below the initial failure is a reported Segmentation Fault
and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith
<details><summary>Trac metadata</summary>
| Trac field ...as detailed in attached log below the initial failure is a reported Segmentation Fault
and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"ghc-openGL build Segmentation Fault for openSUSE ppc64le","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"as detailed in attached log below the initial failure is a reported Segmentation Fault\r\nand if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12536Clarify commentary surrounding unboxed tuples and kind invariant2019-07-07T18:26:11ZBen GamariClarify commentary surrounding unboxed tuples and kind invariant[ticket:12115\#comment:121013](https://gitlab.haskell.org//ghc/ghc/issues/12115#note_121013) notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?
<details><summary>Trac metadat...[ticket:12115\#comment:121013](https://gitlab.haskell.org//ghc/ghc/issues/12115#note_121013) notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?
<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":"Clarify commentary surrounding unboxed tuples and kind invariant","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ticket:12115#comment:8 notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/12534GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects2019-07-07T18:26:11ZRyan ScottGHC 8.0 accepts recursive kind signature that GHC 7.10 rejectsGHC 7.10 rejects this datatype:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
```
```
$ /opt/ghc/7.10.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5...GHC 7.10 rejects this datatype:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
```
```
$ /opt/ghc/7.10.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:1:
Kind variable also used as type variable: ‘a’
In the data type declaration for ‘T’
```
But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`:
```hs
data T a (a :: a)
```
Results in this error:
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:8: error:
Conflicting definitions for ‘a’
Bound at: Bug.hs:5:8
Bug.hs:5:11
Bug.hs:5:16: error:
Type variable ‘a’ used in a kind.
Did you mean to use TypeInType?
the data type declaration for ‘T’
```
But with this modification:
```hs
data T (a :: a) a
```
You won't get an error message about `a` being used as both a kind and type:
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:9: error:
Conflicting definitions for ‘a’
Bound at: Bug.hs:5:9
Bug.hs:5:17
```
To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
class C x
instance C (T (a :: a))
```
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:16: error:
Variable ‘a’ used as both a kind and a type
Did you intend to use TypeInType?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 7.10 rejects this datatype:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\ndata T (a :: a)\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/7.10.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:1:\r\n Kind variable also used as type variable: ‘a’\r\n In the data type declaration for ‘T’\r\n}}}\r\n\r\nBut GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`:\r\n\r\n{{{#!hs\r\ndata T a (a :: a)\r\n}}}\r\n\r\nResults in this error:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:8: error:\r\n Conflicting definitions for ‘a’\r\n Bound at: Bug.hs:5:8\r\n Bug.hs:5:11\r\n\r\nBug.hs:5:16: error:\r\n Type variable ‘a’ used in a kind.\r\n Did you mean to use TypeInType?\r\n the data type declaration for ‘T’\r\n}}}\r\n\r\nBut with this modification:\r\n\r\n{{{#!hs\r\ndata T (a :: a) a\r\n}}}\r\n\r\nYou won't get an error message about `a` being used as both a kind and type:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:9: error:\r\n Conflicting definitions for ‘a’\r\n Bound at: Bug.hs:5:9\r\n Bug.hs:5:17\r\n}}}\r\n\r\nTo make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\ndata T (a :: a)\r\n\r\nclass C x\r\ninstance C (T (a :: a))\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:8:16: error:\r\n Variable ‘a’ used as both a kind and a type\r\n Did you intend to use TypeInType?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/12533Internal error using redundant forall with default signature2019-07-07T18:26:12ZDavid FeuerInternal error using redundant forall with default signature```hs
{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}
class Foo x where
foo :: forall a . x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
GHC (7.8.3 and 8.0.1) c...```hs
{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}
class Foo x where
foo :: forall a . x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
GHC (7.8.3 and 8.0.1) chokes on the above with the message
```
Buggy.hs:7:19: error:
• GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [aoY :-> Type variable ‘x’ = x,
ap0 :-> Type variable ‘a’ = a,
ap1 :-> Identifier[x::x a, <NotTopLevel>]]
• In the first argument of ‘x’, namely ‘a’
In the type signature:
go :: x a
In an equation for ‘foo’:
foo x
= go
where
go :: x a
go = undefined
```
If I remove the redundant `forall` it works fine:
```hs
class Foo x where
foo :: x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
<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":"Internal error using redundant forall with default signature","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}\r\n\r\nclass Foo x where\r\n foo :: forall a . x a -> x a\r\n default foo :: forall a . x a -> x a\r\n foo x = go\r\n where go :: x a\r\n go = undefined\r\n}}}\r\n\r\nGHC (7.8.3 and 8.0.1) chokes on the above with the message\r\n\r\n{{{\r\nBuggy.hs:7:19: error:\r\n • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [aoY :-> Type variable ‘x’ = x,\r\n ap0 :-> Type variable ‘a’ = a,\r\n ap1 :-> Identifier[x::x a, <NotTopLevel>]]\r\n • In the first argument of ‘x’, namely ‘a’\r\n In the type signature:\r\n go :: x a\r\n In an equation for ‘foo’:\r\n foo x\r\n = go\r\n where\r\n go :: x a\r\n go = undefined\r\n}}}\r\n\r\nIf I remove the redundant `forall` it works fine:\r\n\r\n{{{#!hs\r\nclass Foo x where\r\n foo :: x a -> x a\r\n default foo :: forall a . x a -> x a\r\n foo x = go\r\n where go :: x a\r\n go = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2