GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:35:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10436Excessive numbers of packages loaded for TH2019-07-07T18:35:55ZduncanExcessive numbers of packages loaded for THWhen using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases:
```
ghc --make Blah.hs
```
vs
```
ghc --make Blah.hs -package foo
```
In the first case, ghc will work out for itself which...When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases:
```
ghc --make Blah.hs
```
vs
```
ghc --make Blah.hs -package foo
```
In the first case, ghc will work out for itself which packages it needs to load to run the TH code in `Blah.hs` while in the second case, ghc will unconditionally load package `foo` in addition to anything else.
Why is this a problem? Consider a real example (reported on IRC):
```
ghc --make Main.hs
[1 of 4] Compiling Uplink ( Uplink.hs, Uplink.o )
[2 of 4] Compiling FlightData ( FlightData.hs, FlightData.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[3 of 4] Compiling Joystick ( Joystick.hs, Joystick.o )
[4 of 4] Compiling Main ( Main.hs, Main.o )
Linking Main.exe ...
```
This just loads `base` and its deps. Great, it works.
Now the exact same `Main.hs` built by cabal (which of course uses `-package-id` flags):
```
cabal build
Building jpl-0.1.0.0...
Preprocessing executable 'jpl' for jpl-0.1.0.0...
[1 of 4] Compiling Uplink ( Uplink.hs, dist\build\jpl\jpl-tmp\Uplink.o )
[2 of 4] Compiling FlightData ( FlightData.hs, dist\build\jpl\jpl-tmp\FlightData.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package SHA-1.6.4.2 ... linking ... done.
Loading package text-1.2.0.4 ... linking ... done.
```
1. .. snip a further 80, **yes 80 packages** ...
```
Loading package linear-1.18.0.1 ... linking ... done.
Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0'
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
```
1. .. snip more boring details of the linker errors ...
So yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place.
So the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider `-package` flags to be instructions to load these packages for running TH code.
As a bonus it'll be quicker and our build output shorter.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Excessive numbers of packages loaded for TH","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases:\r\n\r\n{{{\r\nghc --make Blah.hs\r\n}}}\r\nvs\r\n{{{\r\nghc --make Blah.hs -package foo\r\n}}}\r\n\r\nIn the first case, ghc will work out for itself which packages it needs to load to run the TH code in `Blah.hs` while in the second case, ghc will unconditionally load package `foo` in addition to anything else.\r\n\r\nWhy is this a problem? Consider a real example (reported on IRC):\r\n\r\n{{{\r\nghc --make Main.hs\r\n[1 of 4] Compiling Uplink ( Uplink.hs, Uplink.o )\r\n[2 of 4] Compiling FlightData ( FlightData.hs, FlightData.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[3 of 4] Compiling Joystick ( Joystick.hs, Joystick.o )\r\n[4 of 4] Compiling Main ( Main.hs, Main.o )\r\n \r\nLinking Main.exe ...\r\n}}}\r\n\r\nThis just loads `base` and its deps. Great, it works.\r\n\r\nNow the exact same `Main.hs` built by cabal (which of course uses `-package-id` flags):\r\n\r\n{{{\r\ncabal build\r\nBuilding jpl-0.1.0.0...\r\nPreprocessing executable 'jpl' for jpl-0.1.0.0...\r\n[1 of 4] Compiling Uplink ( Uplink.hs, dist\\build\\jpl\\jpl-tmp\\Uplink.o )\r\n[2 of 4] Compiling FlightData ( FlightData.hs, dist\\build\\jpl\\jpl-tmp\\FlightData.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package bytestring-0.10.4.0 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package binary-0.7.1.0 ... linking ... done.\r\nLoading package SHA-1.6.4.2 ... linking ... done.\r\nLoading package text-1.2.0.4 ... linking ... done.\r\n}}}\r\n... snip a further 80, '''yes 80 packages''' ...\r\n{{{\r\nLoading package linear-1.18.0.1 ... linking ... done.\r\nLoading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0'\r\nghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup\r\nghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup\r\nghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup\r\n}}}\r\n... snip more boring details of the linker errors ...\r\n\r\nSo yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place.\r\n\r\nSo the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider `-package` flags to be instructions to load these packages for running TH code.\r\n\r\nAs a bonus it'll be quicker and our build output shorter.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10437RunHaskell error in HSExtra on Win642019-07-07T18:35:55ZScottSedgwickRunHaskell error in HSExtra on Win64I ran the following command, and got this error:
```
$ runhaskell shakefile.hs clean
shakefile.hs: C:\Users\Scott Sedgwick\AppData\Roaming\cabal\x86_64-windows-ghc-7.8.3\extra-1.2\HSextra-1.2.o: Not x86_64 PEi386
shakefile.hs: shakefile...I ran the following command, and got this error:
```
$ runhaskell shakefile.hs clean
shakefile.hs: C:\Users\Scott Sedgwick\AppData\Roaming\cabal\x86_64-windows-ghc-7.8.3\extra-1.2\HSextra-1.2.o: Not x86_64 PEi386
shakefile.hs: shakefile.hs: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-mingw32):
loadObj "C:\\Users\\Scott Sedgwick\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.8.3\\extra-1.2\\HSextra-1.2.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The shakefile in question looks like this:
```
import Development.Shake
import Development.Shake.FilePath
--import System.Info
srcFiles = [
"source/main.hs",
"source/DBDataStructures.hs",
"source/FormatDBData.hs",
"source/GetDBData.hs",
"source/ParseDBData.hs"]
exeFile = "dist/build/mssql-er/mssql-er.exe"
depFiles = [
"dependencies/erd/erd.exe",
"dependencies/dot/Pathplan.dll",
"dependencies/dot/config6",
"dependencies/dot/gvc.dll",
"dependencies/dot/iconv.dll",
"dependencies/dot/libfontconfig-1.dll",
"dependencies/dot/libgmodule-2.0-0.dll",
"dependencies/dot/libpango-1.0-0.dll",
"dependencies/dot/libpangowin32-1.0-0.dll",
"dependencies/dot/ltdl.dll",
"dependencies/dot/cdt.dll",
"dependencies/dot/dot.exe",
"dependencies/dot/gvplugin_dot_layout.dll",
"dependencies/dot/libcairo-2.dll",
"dependencies/dot/libfreetype-6.dll",
"dependencies/dot/libgobject-2.0-0.dll",
"dependencies/dot/libpangocairo-1.0-0.dll",
"dependencies/dot/libpng14-14.dll",
"dependencies/dot/zlib1.dll",
"dependencies/dot/cgraph.dll",
"dependencies/dot/freetype6.dll",
"dependencies/dot/gvplugin_pango.dll",
"dependencies/dot/libexpat.dll",
"dependencies/dot/libglib-2.0-0.dll",
"dependencies/dot/libgthread-2.0-0.dll",
"dependencies/dot/libpangoft2-1.0-0.dll",
"dependencies/dot/libxml2.dll"]
copyDep :: FilePath -> Action()
copyDep src = do
let dst = "dist" </> (dropDirectory1 (dropDirectory1 src))
copyFile' src dst
main :: IO()
main = shakeArgs shakeOptions $ do
want ["deploy"]
"clean" ~> do
cmd "cabal" "clean"
"dist/setup-config" *> \_ -> do
need ["mssql-er.cabal"]
cmd "cabal" "configure" "--enable-tests"
"configure" ~> do
need ["dist/setup-config"]
exeFile *> \_ -> do
need (["configure"] ++ srcFiles)
cmd "cabal" "build"
"build" ~> do
need [exeFile, "test"]
"test" ~> do
need srcFiles
cmd "cabal" "test"
"deploy" ~> do
need ["build"]
mapM_ copyDep depFiles
```
Strangely, if I compile that shakefile using ghc, then run it, it works correctly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"RunHaskell error in HSExtra on Win64","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["runhaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran the following command, and got this error:\r\n{{{\r\n$ runhaskell shakefile.hs clean\r\nshakefile.hs: C:\\Users\\Scott Sedgwick\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.8.3\\extra-1.2\\HSextra-1.2.o: Not x86_64 PEi386\r\nshakefile.hs: shakefile.hs: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-unknown-mingw32):\r\n loadObj \"C:\\\\Users\\\\Scott Sedgwick\\\\AppData\\\\Roaming\\\\cabal\\\\x86_64-windows-ghc-7.8.3\\\\extra-1.2\\\\HSextra-1.2.o\": failed\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe shakefile in question looks like this:\r\n{{{\r\nimport Development.Shake\r\nimport Development.Shake.FilePath\r\n--import System.Info\r\n\r\nsrcFiles = [\r\n\t\"source/main.hs\",\r\n\t\"source/DBDataStructures.hs\",\r\n\t\"source/FormatDBData.hs\",\r\n\t\"source/GetDBData.hs\",\r\n\t\"source/ParseDBData.hs\"]\r\n\r\nexeFile = \"dist/build/mssql-er/mssql-er.exe\"\r\n\r\ndepFiles = [\r\n\t\"dependencies/erd/erd.exe\",\r\n\t\"dependencies/dot/Pathplan.dll\", \r\n\t\"dependencies/dot/config6\", \r\n\t\"dependencies/dot/gvc.dll\", \r\n\t\"dependencies/dot/iconv.dll\",\r\n\t\"dependencies/dot/libfontconfig-1.dll\",\r\n\t\"dependencies/dot/libgmodule-2.0-0.dll\", \r\n\t\"dependencies/dot/libpango-1.0-0.dll\",\r\n\t\"dependencies/dot/libpangowin32-1.0-0.dll\",\r\n\t\"dependencies/dot/ltdl.dll\",\r\n\t\"dependencies/dot/cdt.dll\", \r\n\t\"dependencies/dot/dot.exe\",\r\n\t\"dependencies/dot/gvplugin_dot_layout.dll\",\r\n\t\"dependencies/dot/libcairo-2.dll\",\r\n\t\"dependencies/dot/libfreetype-6.dll\",\r\n\t\"dependencies/dot/libgobject-2.0-0.dll\",\r\n\t\"dependencies/dot/libpangocairo-1.0-0.dll\",\r\n\t\"dependencies/dot/libpng14-14.dll\",\r\n\t\"dependencies/dot/zlib1.dll\",\r\n\t\"dependencies/dot/cgraph.dll\",\r\n\t\"dependencies/dot/freetype6.dll\",\r\n\t\"dependencies/dot/gvplugin_pango.dll\",\r\n\t\"dependencies/dot/libexpat.dll\",\r\n\t\"dependencies/dot/libglib-2.0-0.dll\",\r\n\t\"dependencies/dot/libgthread-2.0-0.dll\", \r\n\t\"dependencies/dot/libpangoft2-1.0-0.dll\",\r\n\t\"dependencies/dot/libxml2.dll\"]\r\n\r\ncopyDep :: FilePath -> Action()\r\ncopyDep src = do\r\n\tlet dst = \"dist\" </> (dropDirectory1 (dropDirectory1 src))\r\n\tcopyFile' src dst\r\n\r\nmain :: IO()\r\nmain = shakeArgs shakeOptions $ do\r\n\twant [\"deploy\"]\r\n \t\r\n \t\"clean\" ~> do\r\n \t\tcmd \"cabal\" \"clean\"\r\n\r\n \t\"dist/setup-config\" *> \\_ -> do\r\n \t\tneed [\"mssql-er.cabal\"]\r\n \t\tcmd \"cabal\" \"configure\" \"--enable-tests\"\r\n\r\n \t\"configure\" ~> do\r\n \t\tneed [\"dist/setup-config\"]\r\n\r\n\texeFile *> \\_ -> do\r\n\t\tneed ([\"configure\"] ++ srcFiles)\r\n\t\tcmd \"cabal\" \"build\"\r\n\r\n\t\"build\" ~> do\r\n\t\tneed [exeFile, \"test\"]\r\n\r\n\t\"test\" ~> do\r\n\t\tneed srcFiles\r\n\t\tcmd \"cabal\" \"test\"\r\n\r\n\t\"deploy\" ~> do\r\n\t\tneed [\"build\"]\r\n\t\tmapM_ copyDep depFiles\r\n}}}\r\n\r\nStrangely, if I compile that shakefile using ghc, then run it, it works correctly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10438GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings2019-07-07T18:35:55Zrpglover64GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings```hs
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE TypeFamilies #-}
module Bad
where
foo f = g
where g r = x
where x :: _
x = r
```
When compiled, it produces the following output:
```
[1 of 1] Compi...```hs
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE TypeFamilies #-}
module Bad
where
foo f = g
where g r = x
where x :: _
x = r
```
When compiled, it produces the following output:
```
[1 of 1] Compiling Bad ( src/Bad.hs, src/Bad.o )
src/Bad.hs:8:22: Warning:
Found hole ‘_’ with type: w_1
Where: ‘w_1’ is a rigid type variable bound by
the inferred type of g :: w_1 -> w_1 at src/Bad.hs:7:9
Relevant bindings include
r :: w_1 (bound at src/Bad.hs:7:11)
g :: w_1 -> w_1 (bound at src/Bad.hs:7:9)
f :: t (bound at src/Bad.hs:6:5)
foo :: t -> w_ -> w_ (bound at src/Bad.hs:6:1)
In the type signature for ‘x’: _
In an equation for ‘g’:
g r
= x
where
x :: _
x = r
In an equation for ‘foo’:
foo f
= g
where
g r
= x
where
x :: _
x = r
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
StgCmmEnv: variable not found
x_alC
local binds for:
f_sv5
r_sv6
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE PartialTypeSignatures #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bad\r\nwhere\r\n\r\nfoo f = g\r\n where g r = x\r\n where x :: _\r\n x = r\r\n}}}\r\n\r\nWhen compiled, it produces the following output:\r\n\r\n{{{\r\n[1 of 1] Compiling Bad ( src/Bad.hs, src/Bad.o )\r\n\r\nsrc/Bad.hs:8:22: Warning:\r\n Found hole ‘_’ with type: w_1\r\n Where: ‘w_1’ is a rigid type variable bound by\r\n the inferred type of g :: w_1 -> w_1 at src/Bad.hs:7:9\r\n Relevant bindings include\r\n r :: w_1 (bound at src/Bad.hs:7:11)\r\n g :: w_1 -> w_1 (bound at src/Bad.hs:7:9)\r\n f :: t (bound at src/Bad.hs:6:5)\r\n foo :: t -> w_ -> w_ (bound at src/Bad.hs:6:1)\r\n In the type signature for ‘x’: _\r\n In an equation for ‘g’:\r\n g r\r\n = x\r\n where\r\n x :: _\r\n x = r\r\n In an equation for ‘foo’:\r\n foo f\r\n = g\r\n where\r\n g r\r\n = x\r\n where\r\n x :: _\r\n x = r\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n\tStgCmmEnv: variable not found\r\n x_alC\r\n local binds for:\r\n f_sv5\r\n r_sv6\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10462GHCi doesn't work Any and missing RealWorld foreign prim imports2019-07-07T18:35:48ZEdward Z. YangGHCi doesn't work Any and missing RealWorld foreign prim importsHere are two issues with our GHCi support for foreign prim imports:
Here is a program that works:
```
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import ...Here are two issues with our GHCi support for foreign prim imports:
Here is a program that works:
```
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim "cheneycopy" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #)
```
If I remove the world token passing, as in here:
```
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim "cheneycopy" cheneycopy :: Word# -> Word#
```
I get:
```
(GHC version 7.10.1 for x86_64-unknown-linux):
ByteCodeGen.generateCCall: missing or invalid World token?
```
Another error is if I try to pass Any as an argument:
```
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim "cheneycopy" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #)
```
Then I get:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
primRepToFFIType
```
Note to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi doesn't work Any and missing RealWorld foreign prim imports","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Here are two issues with our GHCi support for foreign prim imports:\r\n\r\nHere is a program that works:\r\n\r\n{{{\r\n{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}\r\nmodule Serum where\r\nimport GHC.Exts\r\n\r\nforeign import prim \"cheneycopy\" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #)\r\n}}}\r\n\r\nIf I remove the world token passing, as in here:\r\n\r\n{{{\r\n{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}\r\nmodule Serum where\r\nimport GHC.Exts\r\n\r\nforeign import prim \"cheneycopy\" cheneycopy :: Word# -> Word#\r\n}}}\r\n\r\nI get:\r\n\r\n{{{\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n\tByteCodeGen.generateCCall: missing or invalid World token?\r\n}}}\r\n\r\nAnother error is if I try to pass Any as an argument:\r\n\r\n{{{\r\n{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}\r\nmodule Serum where\r\nimport GHC.Exts\r\n\r\nforeign import prim \"cheneycopy\" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #)\r\n}}}\r\n\r\nThen I get:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n\tprimRepToFFIType\r\n}}}\r\n\r\nNote to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10469ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange cl...2019-07-07T18:35:47Zjoeyhessghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure typeghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240
(GHC version 7.10.1 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> Aborted
I can consistently get ei...ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240
(GHC version 7.10.1 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> Aborted
I can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any "Compiling" lines, or within the first 1 or 2 files compiled.
I got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash.
The hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103.
I was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem.
Happy to debug further, although this machine is a bit resource constrained to do things like building ghc on it.
ghc 7.8.4 and 7.10.1 both crash the same way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":" ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240\r\n (GHC version 7.10.1 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n Aborted\r\n\r\nI can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any \"Compiling\" lines, or within the first 1 or 2 files compiled.\r\n\r\nI got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash.\r\n\r\nThe hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103.\r\n\r\nI was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem.\r\n\r\nHappy to debug further, although this machine is a bit resource constrained to do things like building ghc on it.\r\n\r\nghc 7.8.4 and 7.10.1 both crash the same way.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10503The impossible happened (no skolem info) - untouchable kind variable2019-07-07T18:35:38ZAlekseyKligerThe impossible happened (no skolem info) - untouchable kind variable```hs
{-# LANGUAGE RankNTypes, PolyKinds, DataKinds, TypeFamilies #-}
module GHCBug where
data Proxy p = Proxy
data KProxy (a :: *) = KProxy
h :: forall r . (Proxy ('KProxy :: KProxy k) ~ Proxy ('KProxy :: KProxy *) => r) -> r
h = und...```hs
{-# LANGUAGE RankNTypes, PolyKinds, DataKinds, TypeFamilies #-}
module GHCBug where
data Proxy p = Proxy
data KProxy (a :: *) = KProxy
h :: forall r . (Proxy ('KProxy :: KProxy k) ~ Proxy ('KProxy :: KProxy *) => r) -> r
h = undefined
```
GHC reports
```
GHCBug.hs:8:6:
Couldn't match kind ‘k’ with ‘*’
‘k’ is untouchable
inside the constraints (Proxy 'KProxy ~ Proxy 'KProxy)
bound by the type signature for
h :: (Proxy 'KProxy ~ Proxy 'KProxy) => r
at GHCBug.hs:8:6-87ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
No skolem info: k_amc[sk]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"The impossible happened (no skolem info) - untouchable kind variable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE RankNTypes, PolyKinds, DataKinds, TypeFamilies #-}\r\nmodule GHCBug where\r\n\r\ndata Proxy p = Proxy\r\n\r\ndata KProxy (a :: *) = KProxy\r\n\r\nh :: forall r . (Proxy ('KProxy :: KProxy k) ~ Proxy ('KProxy :: KProxy *) => r) -> r\r\nh = undefined\r\n}}}\r\n\r\nGHC reports\r\n\r\n{{{\r\nGHCBug.hs:8:6:\r\n Couldn't match kind ‘k’ with ‘*’\r\n ‘k’ is untouchable\r\n inside the constraints (Proxy 'KProxy ~ Proxy 'KProxy)\r\n bound by the type signature for\r\n h :: (Proxy 'KProxy ~ Proxy 'KProxy) => r\r\n at GHCBug.hs:8:6-87ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n\tNo skolem info: k_amc[sk]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10504GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled2020-11-21T11:30:28ZNiklas Hambüchenmail@nh2.meGHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabledMinimal example code: https://github.com/nh2/ghc-omit-interface-pragmas-dsImpSpecs-bug/
I'm encountering a problem that prevents me from using Haskell program coverage on a code base, getting a GHC panic referring to `dsImpSpecs`.
This...Minimal example code: https://github.com/nh2/ghc-omit-interface-pragmas-dsImpSpecs-bug/
I'm encountering a problem that prevents me from using Haskell program coverage on a code base, getting a GHC panic referring to `dsImpSpecs`.
This looks pretty much like this old bug: #4870
I checked that it happens on GHC 7.8.4 and GHC 7.10.1.
----
The problem happens when I run `cabal build --ghc-options "-fhpc"`, giving me
```
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...
Building ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...
Preprocessing library ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...
[1 of 2] Compiling A ( src/A.hs, dist/build/A.o )
[2 of 2] Compiling B ( src/B.hs, dist/build/B.o )
src/B.hs:5:1: Warning:
SPECIALISE pragma for non-overloaded function ‘myfun’
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
dsImpSpecs
ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
$ cabal --version
cabal-install version 1.18.0.8
using version 1.18.1.5 of the Cabal library
```
This doesn't happen when I compile directly with `ghc --make`:
```
$ cd src && ghc --make -fhpc -fomit-interface-pragmas B.hs -Wall
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
```
So running cabal with `-v`, I see that the problem happens in:
```
/home/niklas/opt/ghc-7.8/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -XHaskell98 B A -Wall -fhpc
[1 of 2] Compiling A ( src/A.hs, dist/build/A.o )
[2 of 2] Compiling B ( src/B.hs, dist/build/B.o )
src/B.hs:5:1: Warning:
SPECIALISE pragma for non-overloaded function ‘myfun’
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
dsImpSpecs
ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
So there it be some flag that cabal passes to GHC that makes this GHC crash appear.
Nevertheless, it's a panic, so I guess it's a bug in GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Minimal example code: https://github.com/nh2/ghc-omit-interface-pragmas-dsImpSpecs-bug/\r\n\r\nI'm encountering a problem that prevents me from using Haskell program coverage on a code base, getting a GHC panic referring to `dsImpSpecs`.\r\n\r\nThis looks pretty much like this old bug: https://ghc.haskell.org/trac/ghc/ticket/4870\r\n\r\nI checked that it happens on GHC 7.8.4 and GHC 7.10.1.\r\n\r\n\r\n----\r\n\r\nThe problem happens when I run `cabal build --ghc-options \"-fhpc\"`, giving me\r\n\r\n{{{\r\nPackage has never been configured. Configuring with default flags. If this\r\nfails, please run configure manually.\r\nResolving dependencies...\r\nConfiguring ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...\r\nBuilding ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...\r\nPreprocessing library ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0...\r\n[1 of 2] Compiling A ( src/A.hs, dist/build/A.o )\r\n[2 of 2] Compiling B ( src/B.hs, dist/build/B.o )\r\n\r\nsrc/B.hs:5:1: Warning:\r\n SPECIALISE pragma for non-overloaded function ‘myfun’\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.4 for x86_64-unknown-linux):\r\n dsImpSpecs\r\n ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.8.4\r\n$ cabal --version\r\ncabal-install version 1.18.0.8\r\nusing version 1.18.1.5 of the Cabal library\r\n}}}\r\n\r\nThis doesn't happen when I compile directly with `ghc --make`:\r\n\r\n{{{\r\n$ cd src && ghc --make -fhpc -fomit-interface-pragmas B.hs -Wall\r\n[1 of 2] Compiling A ( A.hs, A.o )\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n}}}\r\n\r\nSo running cabal with `-v`, I see that the problem happens in:\r\n\r\n{{{\r\n/home/niklas/opt/ghc-7.8/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -XHaskell98 B A -Wall -fhpc\r\n[1 of 2] Compiling A ( src/A.hs, dist/build/A.o )\r\n[2 of 2] Compiling B ( src/B.hs, dist/build/B.o )\r\n\r\nsrc/B.hs:5:1: Warning:\r\n SPECIALISE pragma for non-overloaded function ‘myfun’\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.4 for x86_64-unknown-linux):\r\n\tdsImpSpecs\r\n ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nSo there it be some flag that cabal passes to GHC that makes this GHC crash appear.\r\n\r\nNevertheless, it's a panic, so I guess it's a bug in GHC.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10518unregisterised GHC generates incorrect 0xUL literals for certain onstants2019-07-07T18:35:35ZSergei Trofimovichunregisterised GHC generates incorrect 0xUL literals for certain onstantsjakzale reports:
21:47:27 \< int-e\> Oh, nice. Yes, indeed pprHexVal (2\^32\^) W32 (function from cmm/PprC.hs) would result in 0xU.
21:50:29 \< jakzale\> int-e: yes, truncInt takes module 2\^32\^, then go returns empty string (I guess)
...jakzale reports:
21:47:27 \< int-e\> Oh, nice. Yes, indeed pprHexVal (2\^32\^) W32 (function from cmm/PprC.hs) would result in 0xU.
21:50:29 \< jakzale\> int-e: yes, truncInt takes module 2\^32\^, then go returns empty string (I guess)
Here comes the test:
```
$ cat a.cmm
foo() {
bits64 a;
a = 0x10000000000000000; // overflows 64 bits
return (a);
}
$ inplace/bin/ghc-stage2 -c a.cmm
/tmp/ghc8580_0/ghc_2.hc: In function 'foo':
/tmp/ghc8580_0/ghc_2.hc:8:7: error:
error: invalid suffix "xUL" on integer constant
_c0 = 0xUL;
^
```
I've broke it with commit:43f1b2ecd1960fa7377cf55a2b97c66059a701ef
when introduced truncation that can generate more zeroes.7.10.2Sergei TrofimovichSergei Trofimovichhttps://gitlab.haskell.org/ghc/ghc/-/issues/10539ghc internal error compiling simple template haskell + lens program2019-07-07T18:35:25Zandrew.wjaghc internal error compiling simple template haskell + lens programThe following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue.
```sh
Building la...The following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue.
```sh
Building language-arithmetic-0.1.0.0...
Preprocessing library language-arithmetic-0.1.0.0...
[1 of 2] Compiling Language.Arithmetic.Syntax ( src/Language/Arithmetic/Syntax.hs, dist/build/Language/Arithmetic/Syntax.o )
ghc: internal error: stg_ap_v_ret
(GHC version 7.10.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
```hs
module Language.Arithmetic.Syntax where
import Control.Applicative hiding (Const)
import Control.Lens hiding (Const)
import Control.Lens.Plated
import Prelude hiding (const)
import Data.Data
data Arith a b c = Plus { _left :: (Arith a b c), _right :: (Arith a b c) }
| Minus { _left :: (Arith a b c), _right :: (Arith a b c) }
| Times { _left :: (Arith a b c), _right :: (Arith a b c) }
| Divide { _left :: (Arith a b c), _right :: (Arith a b c) }
| Modulo { _left :: (Arith a b c), _right :: (Arith a b c) }
| Parens { _subexp :: (Arith a b c) }
| FunCall{ _name :: String, _subexp :: (Arith a b c) }
| Const { _const :: a}
| Var { _var :: b }
| Embed { _embed :: c }
deriving (Show, Eq, Ord, Data, Typeable)
makeLenses ''Arith
instance Plated (Arith a b c) where
plate = uniplate
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"ghc internal error compiling simple template haskell + lens program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["lens","template-haskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue.\r\n\r\n{{{#!sh\r\nBuilding language-arithmetic-0.1.0.0...\r\nPreprocessing library language-arithmetic-0.1.0.0...\r\n[1 of 2] Compiling Language.Arithmetic.Syntax ( src/Language/Arithmetic/Syntax.hs, dist/build/Language/Arithmetic/Syntax.o )\r\nghc: internal error: stg_ap_v_ret\r\n (GHC version 7.10.1 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted (core dumped)\r\n}}}\r\n\r\n{{{#!hs\r\nmodule Language.Arithmetic.Syntax where\r\nimport Control.Applicative hiding (Const)\r\nimport Control.Lens hiding (Const)\r\nimport Control.Lens.Plated\r\nimport Prelude hiding (const)\r\nimport Data.Data\r\n\r\ndata Arith a b c = Plus { _left :: (Arith a b c), _right :: (Arith a b c) }\r\n | Minus { _left :: (Arith a b c), _right :: (Arith a b c) }\r\n | Times { _left :: (Arith a b c), _right :: (Arith a b c) }\r\n | Divide { _left :: (Arith a b c), _right :: (Arith a b c) }\r\n | Modulo { _left :: (Arith a b c), _right :: (Arith a b c) }\r\n | Parens { _subexp :: (Arith a b c) }\r\n | FunCall{ _name :: String, _subexp :: (Arith a b c) }\r\n | Const { _const :: a}\r\n | Var { _var :: b }\r\n | Embed { _embed :: c }\r\n deriving (Show, Eq, Ord, Data, Typeable)\r\n\r\nmakeLenses ''Arith\r\n\r\ninstance Plated (Arith a b c) where\r\n plate = uniplate\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10574«the 'impossible' happened» when compiling singletons2019-07-07T18:35:11Zzardoz«the 'impossible' happened» when compiling singletonsWhen building the «singletons» package (v1.1.2.1 from hackage) in a fresh sandbox, GHC panics.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...When building the «singletons» package (v1.1.2.1 from hackage) in a fresh sandbox, GHC panics.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"«the 'impossible' happened» when compiling singletons","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When building the «singletons» package (v1.1.2.1 from hackage) in a fresh sandbox, GHC panics.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10602ghc panic: Template variable unbound in rewrite rule when compiling with -O22023-11-29T14:00:15Zpacakghc panic: Template variable unbound in rewrite rule when compiling with -O2I've seen a few related tickets, but they are market as closed.
```
% ghc -O2 binlist.hs
[1 of 1] Compiling Main ( binlist.hs, binlist.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1.20150630 for x86_64-u...I've seen a few related tickets, but they are market as closed.
```
% ghc -O2 binlist.hs
[1 of 1] Compiling Main ( binlist.hs, binlist.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1.20150630 for x86_64-unknown-linux):
Template variable unbound in rewrite rule
sg_s5zh
[sc_s5zf, sc_s5zg, sg_s5zh, sg_s5zi]
[sc_s5zf, sc_s5zg, sg_s5zh, sg_s5zi]
[: @ a_a3fo sc_s5zf sc_s5zg]
[: @ a_a3fo sc_s5zb sc_s5zc]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
% cat binlist.hs
import Control.Monad
import Data.Binary
import Data.List
newtype A a = A [a]
instance Binary a => Binary (A a) where
put (A xs) = case splitAt 254 xs of
(_, []) -> mapM_ put xs
(a, b) -> put (A b)
get = do xs <- replicateM 254 get
A ys <- get
return $ A $ xs ++ ys
main :: IO ()
main = undefined
```7.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10618HEAD@d71b65f53a panics: ``get_op (--$)''2019-07-07T18:35:00ZBen PriceHEAD@d71b65f53a panics: ``get_op (--$)''(Note that 7.10.1 works as expected)
This one line generates a panic:
```hs
panic = GarbageConstructorName $ a --$ b
```
(in an otherwise blank file, when passed to `ghc ` or `ghci`. Just the right hand side panics `ghci` interactivel...(Note that 7.10.1 works as expected)
This one line generates a panic:
```hs
panic = GarbageConstructorName $ a --$ b
```
(in an otherwise blank file, when passed to `ghc ` or `ghci`. Just the right hand side panics `ghci` interactively.)
Error message:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150708 for x86_64-unknown-linux):
get_op (--$)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
`uname -a: Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux`
```
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
```
With `ghc -v` (Was built with `BuildFlavour = devel2`, default `build.mk` otherwise):
```
Glasgow Haskell Compiler, Version 7.11.20150708, stage 2 booted by GHC version 7.8.2
Using binary package database: /5playpen/t-bepric/ghc-build/inplace/lib/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.2.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.11.20150708-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.2.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.11.20150708-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *GetOpCrash.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-07-08 15:09:13 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file GetOpCrash.hs
Created temporary directory: /tmp/ghc22576_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( GetOpCrash.hs, GetOpCrash.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /tmp/ghc22576_0/ghc_1.s
Warning: deleting non-existent /tmp/ghc22576_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /tmp/ghc22576_0
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150708 for x86_64-unknown-linux):
get_op (--$)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| 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":"HEAD@d71b65f53a panics: ``get_op (--$)''","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"(Note that 7.10.1 works as expected)\r\n\r\nThis one line generates a panic:\r\n{{{#!hs\r\npanic = GarbageConstructorName $ a --$ b\r\n}}}\r\n(in an otherwise blank file, when passed to {{{ghc }}} or {{{ghci}}}. Just the right hand side panics {{{ghci}}} interactively.)\r\n\r\nError message:\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150708 for x86_64-unknown-linux):\r\n get_op (--$)\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n{{{uname -a: Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux}}}\r\n{{{\r\ngcc -v:\r\nUsing built-in specs.\r\nCOLLECT_GCC=gcc\r\nCOLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper\r\nTarget: x86_64-linux-gnu\r\nConfigured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu\r\nThread model: posix\r\ngcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)\r\n}}}\r\n\r\nWith {{{ghc -v}}} (Was built with {{{BuildFlavour = devel2}}}, default {{{build.mk}}} otherwise):\r\n{{{\r\nGlasgow Haskell Compiler, Version 7.11.20150708, stage 2 booted by GHC version 7.8.2\r\nUsing binary package database: /5playpen/t-bepric/ghc-build/inplace/lib/package.conf.d/package.cache\r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace\r\nwired-in package base mapped to base-4.8.2.0-inplace\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace\r\nwired-in package ghc mapped to ghc-7.11.20150708-inplace\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags: \r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace\r\nwired-in package base mapped to base-4.8.2.0-inplace\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace\r\nwired-in package ghc mapped to ghc-7.11.20150708-inplace\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *GetOpCrash.hs\r\nStable obj: []\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2015-07-08 15:09:13 UTC\r\n ms_mod = Main,\r\n ms_textual_imps = [import (implicit) Prelude]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting: \r\ncompile: input file GetOpCrash.hs\r\nCreated temporary directory: /tmp/ghc22576_0\r\n*** Checking old interface for Main:\r\n[1 of 1] Compiling Main ( GetOpCrash.hs, GetOpCrash.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Deleting temp files:\r\nDeleting: /tmp/ghc22576_0/ghc_1.s\r\nWarning: deleting non-existent /tmp/ghc22576_0/ghc_1.s\r\n*** Deleting temp dirs:\r\nDeleting: /tmp/ghc22576_0\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150708 for x86_64-unknown-linux):\r\n get_op (--$)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/10627Regression: cabal install of numeric-prelude hangs2021-08-04T05:08:52Zgeorge.colpittsRegression: cabal install of numeric-prelude hangsWhile trying to do cabal install species with HP 7.10.2rc2 I discovered that it hangs compiling numeric-prelude in src/Algebra/RealRing.h. It doesn't seem to be busy computing as cpu usage is 0%.
It also hangs with HP 7.10.1.20150612 but...While trying to do cabal install species with HP 7.10.2rc2 I discovered that it hangs compiling numeric-prelude in src/Algebra/RealRing.h. It doesn't seem to be busy computing as cpu usage is 0%.
It also hangs with HP 7.10.1.20150612 but works with HP 7.10.1.20150601
```
ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150630
cabal install --verbose=3 numeric-prelude
...
[39 of 97] Compiling Algebra.RealRing ( src/Algebra/RealRing.hs, dist/build/Algebra/RealRing.o )
...
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True})
= {terms: 3,506, types: 3,224, coercions: 4}
*** Common sub-expression:
Result size of Common sub-expression
```7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10631Report of GHC Panic loading temp shared object2019-07-07T18:34:57ZseewalkerReport of GHC Panic loading temp shared objectI'll just copy here the error message; I wouldn't say I have the judgement to interpret it:
```
''ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/fo...I'll just copy here the error message; I wouldn't say I have the judgement to interpret it:
```
''ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib, 5): Symbol not found: _AlexSzuELoZZpfyhWUk8IXGTl3Kiel_ModulesziDBTypes_zdfPersistFieldLinkTag_closure
Referenced from: /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib
Expected in: flat namespace
in /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug''
```
This occurred while interactively developing a website with "yesod devel". After the compiler crashed, I killed the program, invoked "yesod devel" again without changing anything in my source code. This next time, no error occurred.https://gitlab.haskell.org/ghc/ghc/-/issues/10647Notice about lack of SIMD support.2019-07-07T18:34:53ZmniipNotice about lack of SIMD support.In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages.
The simplest example is
```hs
{-# LANGUAGE...In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages.
The simplest example is
```hs
{-# LANGUAGE MagicHash #-}
module Foo where
import GHC.Prim
data V = V Int8X16#
```
In 7.8.4 this crashes with
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
Size.intSize W128
```
According to osa1, in HEAD this still crashes, but with
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150717 for x86_64-unknown-linux):
Format.intFormat W128
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| 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":"Notice about lack of SIMD support.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages.\r\n\r\nThe simplest example is\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash #-}\r\nmodule Foo where\r\nimport GHC.Prim\r\ndata V = V Int8X16#\r\n}}}\r\n\r\nIn 7.8.4 this crashes with\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.4 for x86_64-unknown-linux):\r\n\tSize.intSize W128\r\n}}}\r\n\r\nAccording to osa1, in HEAD this still crashes, but with\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150717 for x86_64-unknown-linux):\r\n Format.intFormat W128\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/10665INLINE breaks rewrite rules when '-g' is used2020-05-08T14:38:17ZSergei TrofimovichINLINE breaks rewrite rules when '-g' is usedThe bug is found when building conduit-1.2.4.2 package with '-O2 -g' options. The distilled sample looks like that:
```hs
{-# LANGUAGE BangPatterns #-}
module RewriteBug (bug) where
bug :: () -> ()
bug () = bug ()
{-# NOINLINE bug #-}...The bug is found when building conduit-1.2.4.2 package with '-O2 -g' options. The distilled sample looks like that:
```hs
{-# LANGUAGE BangPatterns #-}
module RewriteBug (bug) where
bug :: () -> ()
bug () = bug ()
{-# NOINLINE bug #-}
a2 :: ()
a2 = ()
{-# INLINE[1] a2 #-}
{-# RULES "bug a2" [0] bug a2 = () #-}
{-
Crashes as:
$ inplace/bin/ghc-stage2 -c -O1 -fforce-recomp RewriteBug.hs -g
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150721 for x86_64-unknown-linux):
Tick in rule ()
-}
```
My theory of sequence of actions is the following:
- rewrite rule gets read as-is by GHC (gentle phase)
- a2 INLINE changes LHS of rewrite rule (phase 1)
- when time comes to apply 'bug a2' rule GHC detects INLINE problem (phase 0)
In real code it happened across multiple files.
The bug is reproducible in both ghc-7.10.2-rc2 and today's HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.2-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | scpmw, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"INLINE breaks rewrite rules when '-g' is used","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["scpmw","simonpj"],"type":"Bug","description":"The bug is found when building conduit-1.2.4.2 package with '-O2 -g' options. The distilled sample looks like that:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\n\r\nmodule RewriteBug (bug) where\r\n\r\nbug :: () -> ()\r\nbug () = bug ()\r\n{-# NOINLINE bug #-}\r\n\r\na2 :: ()\r\na2 = ()\r\n{-# INLINE[1] a2 #-}\r\n\r\n{-# RULES \"bug a2\" [0] bug a2 = () #-}\r\n\r\n{-\r\n Crashes as:\r\n $ inplace/bin/ghc-stage2 -c -O1 -fforce-recomp RewriteBug.hs -g\r\n ghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150721 for x86_64-unknown-linux):\r\n Tick in rule ()\r\n-}\r\n}}}\r\n\r\nMy theory of sequence of actions is the following:\r\n- rewrite rule gets read as-is by GHC (gentle phase)\r\n- a2 INLINE changes LHS of rewrite rule (phase 1)\r\n- when time comes to apply 'bug a2' rule GHC detects INLINE problem (phase 0)\r\n\r\nIn real code it happened across multiple files.\r\n\r\nThe bug is reproducible in both ghc-7.10.2-rc2 and today's HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10667'-g' option generates invalid assembly when '*/*' operator is used2019-07-07T18:34:44ZSergei Trofimovich'-g' option generates invalid assembly when '*/*' operator is usedBug is observed when building cpphs-1.19
```hs
module A where
x */* y = 42
```
```
$ ghc -fforce-recomp A -g
[1 of 1] Compiling A ( A.hs, A.o )
/tmp/ghc23923_0/ghc_2.s: Assembler messages:
/tmp/ghc23923_0/ghc_2.s:17:0:...Bug is observed when building cpphs-1.19
```hs
module A where
x */* y = 42
```
```
$ ghc -fforce-recomp A -g
[1 of 1] Compiling A ( A.hs, A.o )
/tmp/ghc23923_0/ghc_2.s: Assembler messages:
/tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression
/tmp/ghc23923_0/ghc_2.s:17:0:
Warning: missing operand; zero assumed
...
```
The problem here is the following assembly snippet:
```
.text
.align 8
.loc 1 3 1 /* */* */
.quad 12884901911
.quad 0
.quad 15
```
Would it be worthwile using ';' as a comment instead?
Don't know if it's universally portable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.2-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | scpmw |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"'-g' option generates invalid assembly when '*/*' operator is used","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":["scpmw"],"type":"Bug","description":"Bug is observed when building cpphs-1.19\r\n\r\n{{{#!hs\r\nmodule A where\r\n\r\nx */* y = 42\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp A -g\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n/tmp/ghc23923_0/ghc_2.s: Assembler messages:\r\n\r\n/tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression\r\n\r\n/tmp/ghc23923_0/ghc_2.s:17:0:\r\n Warning: missing operand; zero assumed\r\n...\r\n}}}\r\n\r\nThe problem here is the following assembly snippet:\r\n{{{\r\n.text\r\n .align 8\r\n .loc 1 3 1 /* */* */\r\n .quad 12884901911\r\n .quad 0\r\n .quad 15\r\n\r\n}}}\r\n\r\nWould it be worthwile using ';' as a comment instead?\r\nDon't know if it's universally portable.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10670panic! ASSERT failed compiler/types/Type.hs line 17122019-07-07T18:34:44ZBen Pricepanic! ASSERT failed compiler/types/Type.hs line 1712The following code causes a panic when loaded into GHCi
(more complicated code below makes GHC panic also)
```hs
{-# LANGUAGE GADTs , PolyKinds #-}
module Bug where
data TyConT (a::k) = TyConT String
tyConTArr :: TyConT (->)
tyConTAr...The following code causes a panic when loaded into GHCi
(more complicated code below makes GHC panic also)
```hs
{-# LANGUAGE GADTs , PolyKinds #-}
module Bug where
data TyConT (a::k) = TyConT String
tyConTArr :: TyConT (->)
tyConTArr = TyConT "(->)"
data G2 c a where
G2 :: TyConT a -> TyConT b -> G2 c (c a b)
getT2 :: TyConT (c :: k2 -> k1 -> k) -> TyConT (a :: k) -> Maybe (G2 c a)
getT2 (TyConT c) (TyConT a) = Nothing
s tf = case getT2 tyConTArr tf
of Just (G2 _ _) -> Nothing
_ -> Nothing
```
`ghci Bug.hs` yields
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150717 for x86_64-unknown-linux):
ASSERT failed!
file compiler/types/Type.hs line 1712
a_ame -> b_amf
k_anj
```
And for GHC:
```hs
{-# LANGUAGE GADTs , PolyKinds #-}
module Bug2 where
import Unsafe.Coerce
data TyConT (a::k) = TyConT String
eqTyConT :: TyConT a -> TyConT b -> Bool
eqTyConT (TyConT a) (TyConT b) = a == b
tyConTArr :: TyConT (->)
tyConTArr = TyConT "(->)"
data TypeRepT (a::k) where
TRCon :: TyConT a -> TypeRepT a
TRApp :: TypeRepT a -> TypeRepT b -> TypeRepT (a b)
data GetAppT a where
GA :: TypeRepT a -> TypeRepT b -> GetAppT (a b)
getAppT :: TypeRepT a -> Maybe (GetAppT a)
getAppT (TRApp a b) = Just $ GA a b
getAppT _ = Nothing
eqTT :: TypeRepT (a::k1) -> TypeRepT (b::k2) -> Bool
eqTT (TRCon a) (TRCon b) = eqTyConT a b
eqTT (TRApp c a) (TRApp d b) = eqTT c d && eqTT a b
eqTT _ _ = False
data G2 c a where
G2 :: TypeRepT a -> TypeRepT b -> G2 c (c a b)
getT2 :: TypeRepT (c :: k2 -> k1 -> k) -> TypeRepT (a :: k) -> Maybe (G2 c a)
getT2 c t = do GA t' b <- getAppT t
GA c' a <- getAppT t'
if eqTT c c'
then Just (unsafeCoerce $ G2 a b :: G2 c a)
else Nothing
tyRepTArr :: TypeRepT (->)
tyRepTArr = TRCon tyConTArr
s tf = case getT2 tyRepTArr tf
of Just (G2 _ _) -> Nothing
_ -> Nothing
```
`ghc Bug2.hs` yields
```
[1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150717 for x86_64-unknown-linux):
ASSERT failed!
file compiler/types/Type.hs line 1712
a_amr -> b_ams
k_a1c2
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This is a regression from 7.10.1 (fails at 1224bb55cac502fe04005345aad47a6bc5c4a297)
`uname -a`:
`Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux`
using GCC 4.6.3
`gcc -v` output:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
```
`ghc -v Bug2.hs`:
```
Glasgow Haskell Compiler, Version 7.11.20150717, stage 2 booted by GHC version 7.10.1
Using binary package database: /5playpen/t-bepric/ghc-build/inplace/lib/package.conf.d/package.cache
Using binary package database: /home/t-bepric/.ghc/x86_64-linux-7.11.20150717/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.2.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.11.20150717-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.2.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.11.20150717-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Bug2.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-07-22 15:01:01 UTC
ms_mod = Bug2,
ms_textual_imps = [import (implicit) Prelude, import Unsafe.Coerce]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Bug2.hs
Created temporary directory: /tmp/ghc33699_0
*** Checking old interface for Bug2:
[1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar (before optimization)
= {terms: 206, types: 667, coercions: 24}
Result size of Desugar (after optimization)
= {terms: 133, types: 421, coercions: 10}
*** Simplifier:
*** Deleting temp files:
Deleting: /tmp/ghc33699_0/ghc_1.s
Warning: deleting non-existent /tmp/ghc33699_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /tmp/ghc33699_0
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150717 for x86_64-unknown-linux):
ASSERT failed!
file compiler/types/Type.hs line 1712
a_amr -> b_ams
k_a1c2
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10672GHCi linker does not understand C++ exception tables on Windows2019-07-07T18:34:43ZlukexiGHCi linker does not understand C++ exception tables on WindowsWhen compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes:
```
[2 of 2] Compiling Main ( app\Main.hs, dist\build\main\main-tmp\Main.o )
ghc.exe: internal error: checkProdda...When compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes:
```
[2 of 2] Compiling Main ( app\Main.hs, dist\build\main\main-tmp\Main.o )
ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000360564
(GHC version 7.10.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I've boiled this down into a minimal reproduction of a library that includes a .cpp file, and an executable that depends on it.
To test:
```
git clone https://github.com/lukexi/cxx-link-fail-repro
cabal run
```
The crash does not occur in the repro unless I use C++ exceptions in the library, and use Template Haskell in the executable, but in the project I boiled this down from (http://github.com/lukexi/bullet-mini) the problem occurs even with `cc-options: -fno-exceptions`.
Some more details are at https://github.com/lukexi/cxx-link-fail-repro
The platform is Windows 8.1 under MSYS2 (GHC is still using its inbuilt mingw). I've also tried 7.10.2-RC1 with the same result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #8237, #9297, #10563 |
| Blocking | |
| CC | ezyang, simonmar, thomie |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"checkProddableBlock crash during Template Haskell linking","status":"New","operating_system":"","component":"Compiler","related":[8237,9297,10563],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang","simonmar","thomie"],"type":"Bug","description":"When compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes:\r\n{{{\r\n[2 of 2] Compiling Main ( app\\Main.hs, dist\\build\\main\\main-tmp\\Main.o )\r\nghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000360564\r\n (GHC version 7.10.1 for x86_64_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\nI've boiled this down into a minimal reproduction of a library that includes a .cpp file, and an executable that depends on it.\r\nTo test:\r\n{{{\r\ngit clone https://github.com/lukexi/cxx-link-fail-repro\r\ncabal run\r\n}}}\r\n\r\nThe crash does not occur in the repro unless I use C++ exceptions in the library, and use Template Haskell in the executable, but in the project I boiled this down from (http://github.com/lukexi/bullet-mini) the problem occurs even with {{{cc-options: -fno-exceptions}}}.\r\n\r\nSome more details are at https://github.com/lukexi/cxx-link-fail-repro\r\n\r\nThe platform is Windows 8.1 under MSYS2 (GHC is still using its inbuilt mingw). I've also tried 7.10.2-RC1 with the same result.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/10701-fth-dec-file uses qualified names from hidden modules2019-07-07T18:34:35ZFabian-fth-dec-file uses qualified names from hidden modulesIn cross compilation builds, the current TH situation is a bit of a showstopper. However, much TH code is 'safe' to cross-compile. Before the TH situation is solved, it would be great if GHC could automate as much of the work-around proc...In cross compilation builds, the current TH situation is a bit of a showstopper. However, much TH code is 'safe' to cross-compile. Before the TH situation is solved, it would be great if GHC could automate as much of the work-around process as possible. -dth-dec-file is a big step on the way to create a non-TH version of the source. However, there are some problems with the generated code. One is that qualified names from hidden modules are used. A instance declaration for Aeson.ToJSON is outputted as follows:
```hs
instance Data.Aeson.Types.Class.ToJSON InputDropboxFiles where
```
Ideally, GHC would be able to combine the splice output with the original file, replacing all $() with the corresponding splice, and even generate correct imports. I personally think this would be a great solution to the TH problem. Most cross-compilation projects could just generate the non-TH version with the host GHC, and the few that depends on architecture specific variables can be edited before cross-compiled
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"-fth-dec-file uses qualified names from hidden modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["TH"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In cross compilation builds, the current TH situation is a bit of a showstopper. However, much TH code is 'safe' to cross-compile. Before the TH situation is solved, it would be great if GHC could automate as much of the work-around process as possible. -dth-dec-file is a big step on the way to create a non-TH version of the source. However, there are some problems with the generated code. One is that qualified names from hidden modules are used. A instance declaration for Aeson.ToJSON is outputted as follows:\r\n\r\n{{{#!hs\r\ninstance Data.Aeson.Types.Class.ToJSON InputDropboxFiles where\r\n}}}\r\n\r\nIdeally, GHC would be able to combine the splice output with the original file, replacing all $() with the corresponding splice, and even generate correct imports. I personally think this would be a great solution to the TH problem. Most cross-compilation projects could just generate the non-TH version with the host GHC, and the few that depends on architecture specific variables can be edited before cross-compiled","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10737GHC panic durring MVar operation2019-07-07T18:34:15Zdohaqatar7GHC panic durring MVar operationThe following error message was displayed while loading a program into ghci by executing `:r` in a ghci session:
```
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-mingw32):
thread blocked in...The following error message was displayed while loading a program into ghci by executing `:r` in a ghci session:
```
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The only edit made to the source file before compiling was the removal of an unnecessary `do` on line 20 of the source file. The `do` was used even though the monodic computations were written in a single line style.
I have not been able to reproduce the panic at all. The source file, unedited since the panic, now compiles without error.
The ghci session leading up to the crash is below
```
*Main> :t runState (filterM untouchable [1..3]) M.empty
runState (filterM untouchable [1..3]) M.empty :: ([Int], M.Map Int Int)
*Main> runState (filterM untouchable [1..3]) M.empty
([2],fromList [(1,1),(2,1),(3,1),(4,3)])
*Main> runState (filterM untouchable [1..10]) M.empty
([2,5],fromList [(1,1),(2,1),(3,1),(4,3),(5,1),(6,6),(7,1),(8,7),(9,4),(10,8),(11,1),(12,16),(13,1),(14,10),(15,9),(16,15),(17,1),(18,21),(19,1),(20,22),(21,11),(22,14),(23,1),(24,36),(25,6),(26,16),(27,13),(28,28),(29,1),(30,42),(31,1),(32,31),(33,15),(34,20),(35,13),(36,55),(37,1),(38,22),(39,17),(40,50),(41,1),(42,54),(43,1),(44,40),(45,33),(46,26),(47,1),(48,76),(49,8),(50,43),(51,21),(52,46),(53,1),(54,66),(55,17),(56,64),(57,23),(58,32),(59,1),(60,108),(61,1),(62,34),(63,41),(64,63),(65,19),(66,78),(67,1),(68,58),(69,27),(70,74),(71,1)(72,123),(73,1),(74,40),(75,49),(76,64),(77,19),(78,90),(79,1),(80,106),(81,40)])
*Main> runState (filterM untouchable [1..100]) M.empty
([2,5,52,88Interrupted.
*Main> *Main>
*Main>
*Main>
*Main>
*Main>
*Main>
*Main>
*Main> :r
[1 of 1] Compiling Main ( C:\Users\admin\Programming\Haskell\codegolf\Untouchable.hs, interpreted )
Ok, modules loaded: Main.
*Main>
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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 panic durring MVar operation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following error message was displayed while loading a program into ghci by executing `:r` in a ghci session:\r\n\r\n{{{\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-unknown-mingw32):\r\n thread blocked indefinitely in an MVar operation\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe only edit made to the source file before compiling was the removal of an unnecessary `do` on line 20 of the source file. The `do` was used even though the monodic computations were written in a single line style.\r\n\r\nI have not been able to reproduce the panic at all. The source file, unedited since the panic, now compiles without error.\r\n\r\nThe ghci session leading up to the crash is below\r\n\r\n{{{\r\n*Main> :t runState (filterM untouchable [1..3]) M.empty\r\nrunState (filterM untouchable [1..3]) M.empty :: ([Int], M.Map Int Int)\r\n*Main> runState (filterM untouchable [1..3]) M.empty\r\n([2],fromList [(1,1),(2,1),(3,1),(4,3)])\r\n*Main> runState (filterM untouchable [1..10]) M.empty\r\n([2,5],fromList [(1,1),(2,1),(3,1),(4,3),(5,1),(6,6),(7,1),(8,7),(9,4),(10,8),(11,1),(12,16),(13,1),(14,10),(15,9),(16,15),(17,1),(18,21),(19,1),(20,22),(21,11),(22,14),(23,1),(24,36),(25,6),(26,16),(27,13),(28,28),(29,1),(30,42),(31,1),(32,31),(33,15),(34,20),(35,13),(36,55),(37,1),(38,22),(39,17),(40,50),(41,1),(42,54),(43,1),(44,40),(45,33),(46,26),(47,1),(48,76),(49,8),(50,43),(51,21),(52,46),(53,1),(54,66),(55,17),(56,64),(57,23),(58,32),(59,1),(60,108),(61,1),(62,34),(63,41),(64,63),(65,19),(66,78),(67,1),(68,58),(69,27),(70,74),(71,1)(72,123),(73,1),(74,40),(75,49),(76,64),(77,19),(78,90),(79,1),(80,106),(81,40)])\r\n*Main> runState (filterM untouchable [1..100]) M.empty\r\n([2,5,52,88Interrupted.\r\n*Main> *Main>\r\n*Main>\r\n*Main>\r\n*Main>\r\n*Main>\r\n*Main>\r\n*Main>\r\n*Main> :r\r\n[1 of 1] Compiling Main ( C:\\Users\\admin\\Programming\\Haskell\\codegolf\\Untouchable.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main>\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-unknown-mingw32):\r\n thread blocked indefinitely in an MVar operation\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10761GHC panic when compiling vimus: failed to map segment from shared object2019-07-07T18:34:05ZhaasnGHC panic when compiling vimus: failed to map segment from shared objectWhen trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module:
```
λ cabal build
Building vimus-0.2.1...
Preprocessing library vimus-0.2.1...
[38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dis...When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module:
```
λ cabal build
Building vimus-0.2.1...
Preprocessing library vimus-0.2.1...
[38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I don't know why it's only this particular module of this particular library that fails.
I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). That said, I checked ‘dmesg’ and there's no occurrence of a grsec exception.https://gitlab.haskell.org/ghc/ghc/-/issues/10764GHC panic (no skolem info)2019-07-07T18:34:04ZzardozGHC panic (no skolem info)The attached program causes GHC 7.10.2 to panic with the following output:
```
bug.hs:6:19:
Found hole ‘_’ with type: t1 → t2 → m1 a1 → m1 a1
Where: ‘t1’ is a rigid type variable bound by
the inferred type of
...The attached program causes GHC 7.10.2 to panic with the following output:
```
bug.hs:6:19:
Found hole ‘_’ with type: t1 → t2 → m1 a1 → m1 a1
Where: ‘t1’ is a rigid type variable bound by
the inferred type of
whenMultipleOf ∷ MonadPlus m1 ⇒ t1 → t2 → m1 a1 → m1 a1
at bug.hs:7:1
‘a1’ is a rigid type variable bound by
the inferred type of
whenMultipleOf ∷ MonadPlus m1 ⇒ t1 → t2 → m1 a1 → m1 a1
at bug.hs:7:1
‘m1’ is a rigid type variable bound by
the inferred type of
whenMultipleOf ∷ MonadPlus m1 ⇒ t1 → t2 → m1 a1 → m1 a1
at bug.hs:7:1
‘t2’ is a rigid type variable bound by
the inferred type of
whenMultipleOf ∷ MonadPlus m1 ⇒ t1 → t2 → m1 a1 → m1 a1
at bug.hs:7:1
To use the inferred type, enable PartialTypeSignatures
In the type signature for ‘whenMultipleOf’: _
bug.hs:7:1:
No instance for (MonadPlus m)
When checking that ‘whenMultipleOf’ has the specified type
whenMultipleOf ∷ ∀ t a (m ∷ * → *) t1. t → t1 → m a → m a
Probable cause: the inferred type is ambiguous
bug.hs:10:62:
Couldn't match type ‘a1’ with ‘t’
‘a1’ is a rigid type variable bound by
the type signature for
sumOfMultiples ∷ Integral a1 ⇒ [a1] → a1 → [a1]
at bug.hs:9:19ghci-ng: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
No skolem info: t_a7vV[sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/10777Overlong linker arguments on Windows leads to broken builds with confusing er...2019-07-07T18:33:55ZMichael Snoymanmichael@snoyman.comOverlong linker arguments on Windows leads to broken builds with confusing error messagesI've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user:
https://github.com/yesodweb/yesod/issues/1020
https://github.com/commercialhaskell/stack/i...I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user:
https://github.com/yesodweb/yesod/issues/1020
https://github.com/commercialhaskell/stack/issues/466
https://github.com/commercialhaskell/stack/issues/795
The problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Overlong linker arguments on Windows leads to broken builds with confusing error messages","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user:\r\n\r\nhttps://github.com/yesodweb/yesod/issues/1020\r\nhttps://github.com/commercialhaskell/stack/issues/466\r\nhttps://github.com/commercialhaskell/stack/issues/795\r\n\r\nThe problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Michael Snoymanmichael@snoyman.comMichael Snoymanmichael@snoyman.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/10795Upgrade gcc in 7.102019-07-07T18:33:50Zjoozek78Upgrade gcc in 7.10See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files ar...See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files are not used properly by older gcc.
**gcc was upgraded for 7.12 in #10726 so this just needs to be backported**
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Upgrade gcc in 7.10","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [[http://sourceforge.net/p/mingw-w64/mailman/message/29339395/|this mail thread]]). That's because response files are not used properly by older gcc.\r\n\r\n'''gcc was upgraded for 7.12 in #10726 so this just needs to be backported'''","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10801ghc returns ExitFailure (-4) when compiling some projects on ARM2019-07-07T18:33:49ZAnsibleghc returns ExitFailure (-4) when compiling some projects on ARMI'm trying to get either yesod or scotty to build on my raspberry pi 2, which is running arch.
Arch sports the newest working compiler for ghc, 7.8.2. Unfortunately llvm on arch is TOO new, and one must downgrade llvm, and the llvm down...I'm trying to get either yesod or scotty to build on my raspberry pi 2, which is running arch.
Arch sports the newest working compiler for ghc, 7.8.2. Unfortunately llvm on arch is TOO new, and one must downgrade llvm, and the llvm downgrade packages are not available anywhere officially. I, however, happen to have these packages. These are for llvm 3.4.2-1.1.
At any rate, I find I'm at an impasse with both Yesod and with Scotty.
Sample output is attached. There's quite a bit of success, having compiled a lot of libraries, but it fails at the end.
I thought it might be a lack of memory, so I gave it a try with a 1G swapfile as well, but that didn't help.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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 returns ExitFailure (-4) when compiling some projects on ARM","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to get either yesod or scotty to build on my raspberry pi 2, which is running arch. \r\n\r\nArch sports the newest working compiler for ghc, 7.8.2. Unfortunately llvm on arch is TOO new, and one must downgrade llvm, and the llvm downgrade packages are not available anywhere officially. I, however, happen to have these packages. These are for llvm 3.4.2-1.1. \r\n\r\nAt any rate, I find I'm at an impasse with both Yesod and with Scotty. \r\n\r\nSample output is attached. There's quite a bit of success, having compiled a lot of libraries, but it fails at the end. \r\n\r\nI thought it might be a lack of memory, so I gave it a try with a 1G swapfile as well, but that didn't help. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10852ghc 7.8.4 on arm - panic: Simplifier ticks exhausted2019-07-07T18:33:29ZAndrew U. Frankghc 7.8.4 on arm - panic: Simplifier ticks exhaustedi tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF Cortex A20) and get in file `NLP.Corpora.Conll` a panic:
```
[ 9 of 23] Compiling NLP.Corpora....i tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF Cortex A20) and get in file `NLP.Corpora.Conll` a panic:
```
[ 9 of 23] Compiling NLP.Corpora.Conll ( src/NLP/Corpora/Conll.hs, dist/build/NLP/Corpora/Conll.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for arm-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone $fGSerialize:*:_$s<$>
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 2748218
```
i do not notice anything particular in the code, except a very long data type with enumerated values. I tried with a higher value for tick-factor (1000) with no improvement.
i will now try to run 7.10.2-2 from experimental.https://gitlab.haskell.org/ghc/ghc/-/issues/10876stack overflow regression2019-07-07T18:33:20Zdmwitstack overflow regressionI would like to teach GHC that `<=` is transitive. I tried a module that looks like this:
```hs
{-# LANGUAGE GADTs, Rank2Types, TypeOperators #-}
import GHC.TypeLits
trans :: (a <= b, b <= c) => ((a <= c) => d) -> d
trans = undefined
``...I would like to teach GHC that `<=` is transitive. I tried a module that looks like this:
```hs
{-# LANGUAGE GADTs, Rank2Types, TypeOperators #-}
import GHC.TypeLits
trans :: (a <= b, b <= c) => ((a <= c) => d) -> d
trans = undefined
```
In 7.8, this is a type error; in 7.10 the compiler thinks a long time before emitting a stack overflow exception.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.2 |
| 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":"stack overflow regression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I would like to teach GHC that `<=` is transitive. I tried a module that looks like this:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs, Rank2Types, TypeOperators #-}\r\nimport GHC.TypeLits\r\ntrans :: (a <= b, b <= c) => ((a <= c) => d) -> d\r\ntrans = undefined\r\n}}}\r\n\r\nIn 7.8, this is a type error; in 7.10 the compiler thinks a long time before emitting a stack overflow exception.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10880The 'impossible' happend2019-07-07T18:33:14ZdreverThe 'impossible' happendThe compiler told me to file this report. I hope this helps!
```
drever$ cabal build
Building xxx-0.0...
Preprocessing library xxx-0.0...
In-place registering xxx-0.0...
Preprocessing executable 'xxx' for xxx-0.0...
[21 of 21] Compiling...The compiler told me to file this report. I hope this helps!
```
drever$ cabal build
Building xxx-0.0...
Preprocessing library xxx-0.0...
In-place registering xxx-0.0...
Preprocessing executable 'xxx' for xxx-0.0...
[21 of 21] Compiling Main ( src/main.hs, dist/build/xxx/xxx-tmp/Main.o )
src/main.hs:107:19:
Couldn't match kind `* -> *' with `*'
Expected type: FileName -> ReaderT XXXEnvironment IO t0
Actual type: FileName -> ReaderT XXXEnvironment IO t0
Kind incompatibility when matching types:
FileName :: * -> *
FileName :: *
The function `lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-apple-darwin):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```hs
generatecode :: (Entity -> [EntitySample]) -> ReaderT MyEnvironment IO ()
generatecode sample = do
domain_xsd <- lift xsdEntities "test"
```
```hs
xsdEntities :: String -> IO [Entity]
xsdEntities f = do
maybeEntities <- runX ((XS.gettypes f) BaseWrite)
return $ catMaybes $ concat maybeEntities
```
```hs
gettypes :: String -> MyType -> IOSLA (XIOState s) a [Maybe S.Entity]
gettypes f t = (cris f) >>>
(arr $ filterExtends BaseWrite) >>>
(arr getComplexTypes) >>>
(arr (map complexTypeToEntity))
```https://gitlab.haskell.org/ghc/ghc/-/issues/10897Incorrect ASSERT for buildPatSyn2019-07-07T18:33:09ZEdward Z. YangIncorrect ASSERT for buildPatSynConsider the following two files:
```
-- A.hs
{-# LANGUAGE PatternSynonyms #-}
module A where
pattern Single :: a -> a
pattern Single x = x
-- B.hs
module B where
import A
Single y = True
```
When I build these using one-shot compilat...Consider the following two files:
```
-- A.hs
{-# LANGUAGE PatternSynonyms #-}
module A where
pattern Single :: a -> a
pattern Single x = x
-- B.hs
module B where
import A
Single y = True
```
When I build these using one-shot compilation using a debugged GHC (i.e. with ASSERTs) I get the following error:
```
[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c A.hs -fforce-recomp
[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c B.hs -fforce-recomp
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150918 for x86_64-unknown-linux):
ASSERT failed! file compiler/iface/BuildTyCl.hs, line 210
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I expanded the assert and discovered it was claiming the universal type variables of the matcher should be equal to the type variables of the pattern declaration. This assert cannot possibly be right: the matcher and the pattern declaration are typechecked separately and there's no reason that the local binders should actually be the same. The equality test here should be done up to alpha-renaming.
The other thing I found a bit puzzling was whether or not it mattered whether or not we used the local type variables from the matcher or the freshly bound ones. I suppose if we are consistent it shouldn't matter, so I don't think the code is buggy, just a bad ASSERT.
BTW: this assert problem doesn't show up with `--make` because the assert occurs during typechecking of interface files, and with `--make` we don't need to typecheck an interface file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.11 |
| 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":"Incorrect ASSERT for buildPatSyn","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"cactus"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following two files:\r\n\r\n{{{\r\n-- A.hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\nmodule A where\r\npattern Single :: a -> a\r\npattern Single x = x\r\n\r\n-- B.hs\r\nmodule B where\r\nimport A\r\nSingle y = True\r\n}}}\r\n\r\nWhen I build these using one-shot compilation using a debugged GHC (i.e. with ASSERTs) I get the following error:\r\n\r\n{{{\r\n[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c A.hs -fforce-recomp \r\n[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c B.hs -fforce-recomp \r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150918 for x86_64-unknown-linux):\r\n ASSERT failed! file compiler/iface/BuildTyCl.hs, line 210\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI expanded the assert and discovered it was claiming the universal type variables of the matcher should be equal to the type variables of the pattern declaration. This assert cannot possibly be right: the matcher and the pattern declaration are typechecked separately and there's no reason that the local binders should actually be the same. The equality test here should be done up to alpha-renaming.\r\n\r\nThe other thing I found a bit puzzling was whether or not it mattered whether or not we used the local type variables from the matcher or the freshly bound ones. I suppose if we are consistent it shouldn't matter, so I don't think the code is buggy, just a bad ASSERT.\r\n\r\nBTW: this assert problem doesn't show up with `--make` because the assert occurs during typechecking of interface files, and with `--make` we don't need to typecheck an interface file.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/10919ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised2019-07-07T18:33:03Zrecursion-ninjaghc: panic! (the 'impossible' happened) ... Dynamic linker not initialisedWhen trying to build the CUDA accelerate backend I get the following "complier panic":
```
me@box:~/accelerate-cuda-0.15.0.0$ cabal build
Building accelerate-cuda-0.15.0.0...
Preprocessing library accelerate-cuda-0.15.0.0...
Data/Array...When trying to build the CUDA accelerate backend I get the following "complier panic":
```
me@box:~/accelerate-cuda-0.15.0.0$ cabal build
Building accelerate-cuda-0.15.0.0...
Preprocessing library accelerate-cuda-0.15.0.0...
Data/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning:
-XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
[ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o )
<no location info>:
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Dynamic linker not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o )
<no location info>:
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Dynamic linker not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o )
<no location info>:
<command line>: can't load .so/.DLL for: /home/me/.cabal/lib/x86_64-linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory)
```
This is the accelerate cuda package version 0.15.0.0:
https://hackage.haskell.org/package/accelerate-cuda
I changed the constraints from base==4.7.\* to base==4.8.\* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did.
I'd like to get this library to build with the newest version of GHC so please let me know how to proceed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["impossible","initialized","linker","panic"],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"When trying to build the CUDA accelerate backend I get the following \"complier panic\":\r\n\r\n{{{\r\nme@box:~/accelerate-cuda-0.15.0.0$ cabal build\r\nBuilding accelerate-cuda-0.15.0.0...\r\nPreprocessing library accelerate-cuda-0.15.0.0...\r\n\r\nData/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning:\r\n -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS\r\n[ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o )\r\n\r\n<no location info>:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tDynamic linker not initialised\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o )\r\n\r\n<no location info>:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tDynamic linker not initialised\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o )\r\n\r\n<no location info>:\r\n <command line>: can't load .so/.DLL for: /home/me/.cabal/lib/x86_64-linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory)\r\n}}}\r\n\r\nThis is the accelerate cuda package version 0.15.0.0:\r\nhttps://hackage.haskell.org/package/accelerate-cuda\r\n\r\nI changed the constraints from base==4.7.* to base==4.8.* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did. \r\n\r\nI'd like to get this library to build with the newest version of GHC so please let me know how to proceed.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10924Template variable unbound in rewrite rule2019-07-07T18:33:02ZEric CrockettTemplate variable unbound in rewrite ruleThe only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
Temp...The only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
TemplateHaskell, TypeFamilies, UndecidableInstances #-}
module Bug where
-- needed to use Nat's Num instance for +
import qualified GHC.Num as Num
import Data.Singletons.Prelude
import Data.Singletons.TH
import Data.Type.Natural
import Data.Typeable
-- | Copied from Data.Type.Natural because the data-level version
-- is not exported there.
(<<=) :: Nat -> Nat -> Bool
Z <<= _ = True
S _ <<= Z = False
S n <<= S m = n <<= m
singletons [d|
newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable)
|]
singletons [d|
ppMul :: PrimePower -> [PrimePower] -> [PrimePower]
ppMul x [] = [x]
ppMul x@(PP(p,e)) pps@(PP (p',e'):pps')
| p == p' = PP(p,e Num.+ e'):pps'
| p <<= p' = x:pps
| otherwise = (PP(p',e')):ppMul x pps'
|]
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Template variable unbound in rewrite rule
t_XexU
[t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT,
sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57]
[t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP,
sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88]
[TYPE Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5,
TYPE ipv_sfxT,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (sg_sg55
:: R:Sing(,)z '(n0_aeyH, n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (sg_sg56
:: R:SingPrimePowerz
('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))
~R# Sing
(Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))),
sc_sg57]
[TYPE Let1627437970XSym7
n0_aeyH
n1_aeyI
n0_XeB0
n1_XeB2
ipv_XfzF
(Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5)
ipv_sfxT,
TYPE ipv_XfzF,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (Sub (Sym (TFCo:R:Sing(,)z[0] <Nat>_N <Nat>_N)) (Sym
(TFCo:R:Apply(,)kTuple2Sym1l0[0]
<Nat>_N
<Nat>_N
<n1_aeyI>_N
<n0_aeyH>_N)
; (Apply
(Sym
(TFCo:R:Apply(->)kTuple2Sym0l0[0]
<Nat>_N
<Nat>_N
<n0_aeyH>_N))
<n1_aeyI>_N)_N)
:: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym
(TFCo:R:ApplyPrimePower(,)PPSym0l0[0]
<(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N))
:: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))),
ipv_sfxW]
```
I'd love a workaround if possible; I've been unable to find one.7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10934Iface type variable out of scope2019-07-07T18:32:59ZmjmrotekIface type variable out of scopeI'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.
I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which...I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.
I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message:
```
/home/marcin/haskell/pipes-key-value-csv/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi
Declaration for $fFromKeyValuesf:3:
Iface type variable out of scope: k
Cannot continue after interface file error
```
when I uncomment the
```hs
. KV.foldHeader
```
line in https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/test/Test/KeyValue.hs
The thing is, this function does not even use the "FromKeyValues" type class mentioned - https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs
KV.parseLine, which does, compiles fine (the test suite runs and fails with "Prelude: undefined". They're both defined here: https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs
I've tried "stack clean", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Iface type variable out of scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["interface"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.\r\n\r\nI'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message:\r\n{{{\r\n/home/marcin/haskell/pipes-key-value-csv/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi\r\nDeclaration for $fFromKeyValuesf:3:\r\n Iface type variable out of scope: k\r\nCannot continue after interface file error\r\n}}}\r\nwhen I uncomment the\r\n{{{#!hs\r\n. KV.foldHeader\r\n}}}\r\nline in https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/test/Test/KeyValue.hs\r\n\r\nThe thing is, this function does not even use the \"FromKeyValues\" type class mentioned - https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs\r\n\r\nKV.parseLine, which does, compiles fine (the test suite runs and fails with \"Prelude: undefined\". They're both defined here: https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs\r\n\r\nI've tried \"stack clean\", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10938DeriveAnyClass + deriving Bifunctor causes GHC panic2019-07-07T18:32:58ZerantapaaDeriveAnyClass + deriving Bifunctor causes GHC panicAttempting the derive Bifunctor with DeriveAnyClass caused this message from GHC:
```
$ ghc Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Var/Type length mismatch:
[a_an7, b_an8]
[]
Var/Type length mismatch:
[a_an7,...Attempting the derive Bifunctor with DeriveAnyClass caused this message from GHC:
```
$ ghc Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Var/Type length mismatch:
[a_an7, b_an8]
[]
Var/Type length mismatch:
[a_an7, b_an8]
[]
Var/Type length mismatch:
[a_an7, b_an8]
[]
Foo.hs:8:13:ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
tcTyVarDetails a_an7
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The code:
```hs
{-# LANGUAGE DeriveAnyClass #-}
module Foo where
import Data.Bifunctor
data Blah a b = A a | B b
deriving (Bifunctor)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DeriveAnyClass + deriving Bifunctor causes GHC panic","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["DeriveAnyClass"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attempting the derive Bifunctor with DeriveAnyClass caused this message from GHC:\r\n\r\n{{{\r\n$ ghc Foo.hs\r\n[1 of 1] Compiling Foo ( Foo.hs, Foo.o )\r\nVar/Type length mismatch:\r\n [a_an7, b_an8]\r\n []\r\nVar/Type length mismatch:\r\n [a_an7, b_an8]\r\n []\r\nVar/Type length mismatch:\r\n [a_an7, b_an8]\r\n []\r\n\r\nFoo.hs:8:13:ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-apple-darwin):\r\n\ttcTyVarDetails a_an7\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n\r\nmodule Foo where\r\n\r\nimport Data.Bifunctor\r\n\r\ndata Blah a b = A a | B b\r\n deriving (Bifunctor)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10946Typed hole inside typed Template Haskell bracket causes panic2022-01-29T16:06:57ZJan Stolarekjan.stolarek@ed.ac.ukTyped hole inside typed Template Haskell bracket causes panicWhen I say:
```hs
m :: a -> a
m x = $$([||_||])
```
I get:
```
T10946.hs:47:13:ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
No skolem info: a_apJ[sk]
```
This happens both with GHC ...When I say:
```hs
m :: a -> a
m x = $$([||_||])
```
I get:
```
T10946.hs:47:13:ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
No skolem info: a_apJ[sk]
```
This happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typed hole inside typed Template Haskell bracket causes panic","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"When I say:\r\n\r\n{{{#!hs\r\nm :: a -> a\r\nm x = $$([||_||])\r\n}}}\r\nI get:\r\n{{{\r\nT10946.hs:47:13:ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n No skolem info: a_apJ[sk]\r\n}}}\r\nThis happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e).","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10950Sphinx "RecursionError: maximum recursion depth exceeded while pickling an ob...2019-10-06T23:25:29ZEdward Z. YangSphinx "RecursionError: maximum recursion depth exceeded while pickling an object"During a recent validate with Sphinx (sphinx-build) 1.3.1 (as packaged by Arch Linux), I got this failure:
```
reading sources... [ 33%] glasgow_exts
Exception occurred:
File "/usr/lib/python3....During a recent validate with Sphinx (sphinx-build) 1.3.1 (as packaged by Arch Linux), I got this failure:
```
reading sources... [ 33%] glasgow_exts
Exception occurred:
File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 863, in read_doc
pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL)
RecursionError: maximum recursion depth exceeded while pickling an object
The full traceback has been saved in /tmp/sphinx-err-11x82xjc.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
docs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed
make[1]: *** [docs/users_guide/ghc.1] Error 1
Makefile:121: recipe for target 'all' failed
make: *** [all] Error 2
```
The contents of the referenced log:
```
# Sphinx version: 1.3.1
# Python version: 3.5.0 (CPython)
# Docutils version: 0.12 release
# Jinja2 version: 2.8
# Last messages:
# reading sources... [ 6%] bugs
# reading sources... [ 9%] codegens
# reading sources... [ 12%] debugging
# reading sources... [ 15%] editing-guide
# reading sources... [ 18%] extending_ghc
# reading sources... [ 21%] ffi-chap
# reading sources... [ 24%] flags
# reading sources... [ 27%] ghc
# reading sources... [ 30%] ghci
# reading sources... [ 33%] glasgow_exts
# Loaded extensions:
# sphinx.ext.extlinks (1.3.1) from /usr/lib/python3.5/site-packages/sphinx/ext/extlinks.py
# alabaster (0.7.6) from /usr/lib/python3.5/site-packages/alabaster/__init__.py
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/sphinx/cmdline.py", line 245, in main
app.build(opts.force_all, filenames)
File "/usr/lib/python3.5/site-packages/sphinx/application.py", line 264, in build
self.builder.build_update()
File "/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py", line 240, in build_update
self.build(['__all__'], to_build)
File "/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py", line 259, in build
self.doctreedir, self.app))
File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 618, in update
self._read_serial(docnames, app)
File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 638, in _read_serial
self.read_doc(docname, app)
File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 863, in read_doc
pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL)
RecursionError: maximum recursion depth exceeded while pickling an object
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Sphinx \"RecursionError: maximum recursion depth exceeded while pickling an object\"","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"During a recent validate with Sphinx (sphinx-build) 1.3.1 (as packaged by Arch Linux), I got this failure:\r\n\r\n{{{\r\nreading sources... [ 33%] glasgow_exts \r\nException occurred:\r\n File \"/usr/lib/python3.5/site-packages/sphinx/environment.py\", line 863, in read_doc\r\n pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL)\r\nRecursionError: maximum recursion depth exceeded while pickling an object\r\nThe full traceback has been saved in /tmp/sphinx-err-11x82xjc.log, if you want to report the issue to the developers.\r\nPlease also report this if it was a user error, so that a better error message can be provided next time.\r\nA bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!\r\ndocs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed\r\nmake[1]: *** [docs/users_guide/ghc.1] Error 1\r\nMakefile:121: recipe for target 'all' failed\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nThe contents of the referenced log:\r\n\r\n{{{\r\n# Sphinx version: 1.3.1 \r\n# Python version: 3.5.0 (CPython) \r\n# Docutils version: 0.12 release \r\n# Jinja2 version: 2.8 \r\n# Last messages: \r\n# reading sources... [ 6%] bugs \r\n# reading sources... [ 9%] codegens \r\n# reading sources... [ 12%] debugging \r\n# reading sources... [ 15%] editing-guide \r\n# reading sources... [ 18%] extending_ghc \r\n# reading sources... [ 21%] ffi-chap \r\n# reading sources... [ 24%] flags \r\n# reading sources... [ 27%] ghc \r\n# reading sources... [ 30%] ghci \r\n# reading sources... [ 33%] glasgow_exts \r\n# Loaded extensions:\r\n# sphinx.ext.extlinks (1.3.1) from /usr/lib/python3.5/site-packages/sphinx/ext/extlinks.py\r\n# alabaster (0.7.6) from /usr/lib/python3.5/site-packages/alabaster/__init__.py\r\nTraceback (most recent call last):\r\n File \"/usr/lib/python3.5/site-packages/sphinx/cmdline.py\", line 245, in main\r\n app.build(opts.force_all, filenames)\r\n File \"/usr/lib/python3.5/site-packages/sphinx/application.py\", line 264, in build\r\n self.builder.build_update()\r\n File \"/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py\", line 240, in build_update\r\n self.build(['__all__'], to_build) \r\n File \"/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py\", line 259, in build\r\n self.doctreedir, self.app)) \r\n File \"/usr/lib/python3.5/site-packages/sphinx/environment.py\", line 618, in update\r\n self._read_serial(docnames, app)\r\n File \"/usr/lib/python3.5/site-packages/sphinx/environment.py\", line 638, in _read_serial\r\n self.read_doc(docname, app)\r\n File \"/usr/lib/python3.5/site-packages/sphinx/environment.py\", line 863, in read_doc\r\n pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL)\r\nRecursionError: maximum recursion depth exceeded while pickling an object\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10999ghc: panic! (the 'impossible' happened)2019-07-07T18:32:44Zresghc: panic! (the 'impossible' happened)The attached program elicits the following error from GHC 7.10.2:
```
Couldn't match type ‘a’ with ‘(t0, t1, t2)’
‘a’ is untouchable
inside the constraints ()
bound by the inferred type of
upda...The attached program elicits the following error from GHC 7.10.2:
```
Couldn't match type ‘a’ with ‘(t0, t1, t2)’
‘a’ is untouchable
inside the constraints ()
bound by the inferred type of
updateKeytab :: FilePath -> Handle -> IO ()
at /u/res/g/src/remctl-tools/foo.hs:(58,1)-(69,26)ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
No skolem info: a_akOb[sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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! (the 'impossible' happened)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program elicits the following error from GHC 7.10.2:\r\n\r\n{{{\r\n Couldn't match type ‘a’ with ‘(t0, t1, t2)’\r\n ‘a’ is untouchable\r\n inside the constraints ()\r\n bound by the inferred type of\r\n updateKeytab :: FilePath -> Handle -> IO ()\r\n at /u/res/g/src/remctl-tools/foo.hs:(58,1)-(69,26)ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tNo skolem info: a_akOb[sk]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11045Loading temp shared object failed - undefined symbol2019-07-07T18:32:25ZSimon JakobiLoading temp shared object failed - undefined symbolWhile re-compiling [stack](https://github.com/commercialhaskell/stack):
```
$ stack install --ghc-options -O2
stack-0.1.7.0: configure
Configuring stack-0.1.7.0...
stack-0.1.7.0: build
Preprocessing library stack-0.1.7.0...
[30 of 74] C...While re-compiling [stack](https://github.com/commercialhaskell/stack):
```
$ stack install --ghc-options -O2
stack-0.1.7.0: configure
Configuring stack-0.1.7.0...
stack-0.1.7.0: build
Preprocessing library stack-0.1.7.0...
[30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o )
[31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o )
[32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o )
[33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed]
[34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed]
[35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o )
[36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed]
[37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed]
[38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o )
[39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed]
[40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed]
[41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed]
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building package stack-0.1.7.0 using:
/home/simon/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
$ git show
commit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad
Author: Emanuel Borsboom <manny@fpcomplete.com>
Date: Sun Nov 1 05:21:16 2015 -0800
<snip>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Loading temp shared object failed - undefined symbol","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While re-compiling [https://github.com/commercialhaskell/stack stack]:\r\n\r\n{{{\r\n$ stack install --ghc-options -O2\r\nstack-0.1.7.0: configure\r\nConfiguring stack-0.1.7.0...\r\nstack-0.1.7.0: build\r\nPreprocessing library stack-0.1.7.0...\r\n[30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o )\r\n[31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o )\r\n[32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o )\r\n[33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed]\r\n[34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed]\r\n[35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o )\r\n[36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed]\r\n[37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed]\r\n[38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o )\r\n[39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed]\r\n[40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed]\r\n[41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed]\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure\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 stack-0.1.7.0 using:\r\n /home/simon/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n\r\n$ git show\r\ncommit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad\r\nAuthor: Emanuel Borsboom <manny@fpcomplete.com>\r\nDate: Sun Nov 1 05:21:16 2015 -0800\r\n\r\n<snip>\r\n \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11050[bug] ModOrigin: hidden module redefined2024-01-30T11:44:35Zcodeonwort[bug] ModOrigin: hidden module redefined```hs
1 import Haste
2 import Haste.DOM
3 import Haste.Graphics.Canvas
4 import Control.Monad
5
6 mkCanvas width height = do
7 canvas <- newElem "canvas"
8 setProp canvas "width" $ show width
9 setProp canvas "hei...```hs
1 import Haste
2 import Haste.DOM
3 import Haste.Graphics.Canvas
4 import Control.Monad
5
6 mkCanvas width height = do
7 canvas <- newElem "canvas"
8 setProp canvas "width" $ show width
9 setProp canvas "height" $ show height
10 let conf = [("display", "block"), ("border", "1px solid black"), ("margin", "0px auto 0 aut o"), ("backgroundColor", "black")]
11 mapM_ (\(style, value) -> setStyle canvas style value) conf
12 return canvas
13
14 picture = fill $ rect (0, 0) (600, 600)
15
16 main = do
17 canv <- mkCanvas 600 600
18 addChild canv documentBody
19 Just canv <- getCanvas canv
20 render canv picture
```
------------------------------------------------------------------------
hello.hs:18:3: Warning:hastec: hastec: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
> ModOrigin: hidden module redefined
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
------------------------------------------------------------------------
I was following the tutorial on http://ifeanyi.co/posts/client-side-haskell/ and got this bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"[bug] ModOrigin: hidden module redefined","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n 1 import Haste\r\n 2 import Haste.DOM\r\n 3 import Haste.Graphics.Canvas\r\n 4 import Control.Monad\r\n 5\r\n 6 mkCanvas width height = do\r\n 7 canvas <- newElem \"canvas\"\r\n 8 setProp canvas \"width\" $ show width\r\n 9 setProp canvas \"height\" $ show height\r\n 10 let conf = [(\"display\", \"block\"), (\"border\", \"1px solid black\"), (\"margin\", \"0px auto 0 aut o\"), (\"backgroundColor\", \"black\")]\r\n 11 mapM_ (\\(style, value) -> setStyle canvas style value) conf\r\n 12 return canvas\r\n 13\r\n 14 picture = fill $ rect (0, 0) (600, 600)\r\n 15\r\n 16 main = do\r\n 17 canv <- mkCanvas 600 600\r\n 18 addChild canv documentBody\r\n 19 Just canv <- getCanvas canv\r\n 20 render canv picture\r\n}}}\r\n\r\n------------------------------------------------------------------------\r\nhello.hs:18:3: Warning:hastec: hastec: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n ModOrigin: hidden module redefined\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n------------------------------------------------------------------------\r\n\r\nI was following the tutorial on http://ifeanyi.co/posts/client-side-haskell/ and got this bug.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11055GHC 7.8.4 crash on ARM while building Stack 0.1.72019-07-07T18:32:21ZLokathorGHC 7.8.4 crash on ARM while building Stack 0.1.7I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configur...I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring stack-0.1.7.0...
Building stack-0.1.7.0...
Preprocessing library stack-0.1.7.0...
[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )
ghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c
(GHC version 7.8.4 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
```
The folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| 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 7.8.4 crash on ARM while building Stack 0.1.7","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:\r\n\r\n{{{\r\ndaniel@pixie stack $ cabal build\r\nPackage has never been configured. Configuring with default flags. If this\r\nfails, please run configure manually.\r\nResolving dependencies...\r\nConfiguring stack-0.1.7.0...\r\nBuilding stack-0.1.7.0...\r\nPreprocessing library stack-0.1.7.0...\r\n[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )\r\nghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c\r\n (GHC version 7.8.4 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n}}}\r\n\r\nThe folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11073GHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.02019-07-07T18:32:13ZhighflyGHC ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0GHC reports :
```
[4 of 7] Compiling Data.Sequences ( src/Data/Sequences.hs, dist/build/Data/Sequences.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /tmp/ghc12990_0/ghc_35.ll /tmp/ghc12990_0/ghc_1.hscpp
W...GHC reports :
```
[4 of 7] Compiling Data.Sequences ( src/Data/Sequences.hs, dist/build/Data/Sequences.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /tmp/ghc12990_0/ghc_35.ll /tmp/ghc12990_0/ghc_1.hscpp
Warning: deleting non-existent /tmp/ghc12990_0/ghc_35.ll
*** Deleting temp dirs:
Deleting: /tmp/ghc12990_0
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for arm-unknown-linux):
ASSERT failed!
file compiler/typecheck/TcEvidence.hs line 597 Sym cobox_a2uDU
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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 ASSERT when compiling Data.Sequences in the mono-traversable-0.10.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC reports :\r\n\r\n{{{\r\n[4 of 7] Compiling Data.Sequences ( src/Data/Sequences.hs, dist/build/Data/Sequences.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Deleting temp files:\r\nDeleting: /tmp/ghc12990_0/ghc_35.ll /tmp/ghc12990_0/ghc_1.hscpp\r\nWarning: deleting non-existent /tmp/ghc12990_0/ghc_35.ll\r\n*** Deleting temp dirs:\r\nDeleting: /tmp/ghc12990_0\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for arm-unknown-linux):\r\n ASSERT failed!\r\n file compiler/typecheck/TcEvidence.hs line 597 Sym cobox_a2uDU\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11136Associated type family: panic due to mismatch in arity of default instances2019-07-07T18:31:48ZairiniAssociated type family: panic due to mismatch in arity of default instancesHaving extra type parameters in the definition of default instances for an associated type family causes a ghc panic error (should be detected as a not valid instance). Smallest case example:
```hs
class C a where
type D a
type inst...Having extra type parameters in the definition of default instances for an associated type family causes a ghc panic error (should be detected as a not valid instance). Smallest case example:
```hs
class C a where
type D a
type instance D a x = x
```
It produces the error:
```
[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
splitKindFunTysN 1 *
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Crashes similarly for additional parameters in the default instance:
```hs
class C a where
type D a
type instance D a x y = x
```
```
[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
splitKindFunTysN 2 *
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Presumably the arity is not compared correctly to that of the family declaration when the kind is default `*` since the following (and equivalent) causes the panic crash:
```hs
class C a where
type D a :: *
type instance D a x = x
```
but increasing the arity of the family's kind
```hs
class C a where
type D a :: * -> *
type instance D a x = x
```
raises the appropriate error:
```
[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )
SplitKindFun.hs:6:3:
Number of parameters must match family declaration; expected 1
In the default type instance declaration for ‘D’
In the class declaration for ‘C’
Failed, modules loaded: none.
```
Longer verbose compiler output of the original error:
```
$ ghc -v SplitKindFun.hs
Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.10.1.20150612
Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/lib/ghc-7.10.2/package.conf.d/package.cache
Using binary package database: /Users/uu/.ghc/x86_64-darwin-7.10.2/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea
wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea
wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *SplitKindFun.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-11-26 15:20:15 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file SplitKindFun.hs
Created temporary directory: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( SplitKindFun.hs, SplitKindFun.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s
Warning: deleting non-existent /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
splitKindFunTysN 1 *
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.2 |
| 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":"Associated type family: panic due to mismatch in arity of default instances","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Having extra type parameters in the definition of default instances for an associated type family causes a ghc panic error (should be detected as a not valid instance). Smallest case example:\r\n\r\n{{{#!hs\r\nclass C a where\r\n type D a\r\n type instance D a x = x\r\n}}}\r\n\r\nIt produces the error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-apple-darwin):\r\n\tsplitKindFunTysN 1 *\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nCrashes similarly for additional parameters in the default instance:\r\n\r\n{{{#!hs\r\nclass C a where\r\n type D a\r\n type instance D a x y = x\r\n}}}\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-apple-darwin):\r\n\tsplitKindFunTysN 2 *\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nPresumably the arity is not compared correctly to that of the family declaration when the kind is default `*` since the following (and equivalent) causes the panic crash:\r\n\r\n{{{#!hs\r\nclass C a where\r\n type D a :: *\r\n type instance D a x = x\r\n}}}\r\n\r\nbut increasing the arity of the family's kind\r\n\r\n{{{#!hs\r\nclass C a where\r\n type D a :: * -> *\r\n type instance D a x = x\r\n}}}\r\n\r\nraises the appropriate error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( SplitKindFun.hs, interpreted )\r\n\r\nSplitKindFun.hs:6:3:\r\n Number of parameters must match family declaration; expected 1\r\n In the default type instance declaration for ‘D’\r\n In the class declaration for ‘C’\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nLonger verbose compiler output of the original error:\r\n\r\n{{{\r\n$ ghc -v SplitKindFun.hs \r\nGlasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.10.1.20150612\r\nUsing binary package database: /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/lib/ghc-7.10.2/package.conf.d/package.cache\r\nUsing binary package database: /Users/uu/.ghc/x86_64-darwin-7.10.2/package.conf.d/package.cache\r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482\r\nwired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea\r\nwired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags: \r\nwired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482\r\nwired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea\r\nwired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *SplitKindFun.hs\r\nStable obj: []\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2015-11-26 15:20:15 UTC\r\n ms_mod = Main,\r\n ms_textual_imps = [import (implicit) Prelude]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting: \r\ncompile: input file SplitKindFun.hs\r\nCreated temporary directory: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0\r\n*** Checking old interface for Main:\r\n[1 of 1] Compiling Main ( SplitKindFun.hs, SplitKindFun.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Deleting temp files:\r\nDeleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s\r\nWarning: deleting non-existent /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s\r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-apple-darwin):\r\n\tsplitKindFunTysN 1 *\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/11154Problems using GHC-API on MacOS X2019-07-07T18:31:44ZsvenkProblems using GHC-API on MacOS XI followed the instructions on the Haskell wiki "GHC/As a library" to compile a Haskell file:
**Main.hs**
```hs
import GHC
import GHC.Paths ( libdir )
import DynFlags
main =
defaultErrorHandler defaultFatalMessager defaultFlushOu...I followed the instructions on the Haskell wiki "GHC/As a library" to compile a Haskell file:
**Main.hs**
```hs
import GHC
import GHC.Paths ( libdir )
import DynFlags
main =
defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags
target <- guessTarget "test.hs" Nothing
setTargets [target]
load LoadAllTargets
```
**test.hs**
```hs
main = putStrLn "hello"
```
I compile with ghc -package ghc -package ghc-paths --make Main.hs. When I execute ./Main, I get the following linking error:
```
ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _szZ_info from test.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
final section layout:
__TEXT/__text addr=0x100000D40, size=0x00000206, fileOffset=0x00000D40, type=1
__TEXT/__stubs addr=0x100000F46, size=0x0000001E, fileOffset=0x00000F46, type=28
__TEXT/__stub_helper addr=0x100000F64, size=0x00000042, fileOffset=0x00000F64, type=32
__TEXT/__const addr=0x100000FA8, size=0x0000000C, fileOffset=0x00000FA8, type=0
__TEXT/__eh_frame addr=0x100000FB8, size=0x00000040, fileOffset=0x00000FB8, type=19
__DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=30
__DATA/__got addr=0x100001028, size=0x00000010, fileOffset=0x00001028, type=29
__DATA/__nl_symbol_ptr addr=0x100001038, size=0x00000010, fileOffset=0x00001038, type=29
__DATA/__la_symbol_ptr addr=0x100001048, size=0x00000028, fileOffset=0x00001048, type=27
__DATA/__const addr=0x100001070, size=0x00000028, fileOffset=0x00001070, type=0
__DATA/__data addr=0x100001098, size=0x00000060, fileOffset=0x00001098, type=0
__DATA/__common addr=0x1000010F8, size=0x00000020, fileOffset=0x00000000, type=25
ld: 32-bit RIP relative reference out of range (-4294970840 max is +/-4GB): from _szZ_info (0x100000D98) to _ghczmprim_GHCziCString_unpackCStringzh_closure@0x0004A460 (0x00000000) in '_szZ_info' from test.o for architecture x86_64
clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)
```
I'm running the Nix package manager on MacOS X. Here are the compiler and linker commands for the GHC-API case.
```
*** Assembler:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s -o test.o
Upsweep completely successful.
*** Deleting temp files:
Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s
Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c
Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s
link: linkables are ...
LinkableM (2015-12-02 09:23:41 UTC) Main
[DotO test.o]
Linking test ...
*** C Compiler:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__
*** Linker:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -Wl,-rpath -Wl,/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -Wl,-rpath -Wl,/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw-ghc7.10.2 -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2 -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2 -lHSrts-ghc7.10.2 -lffi -liconv -lgmp -lm -ldl
```
And here is the compilation command for vanilla GHC:
```
*** Assembler:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s -o test.o
Upsweep completely successful.
*** Deleting temp files:
Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s
Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c
Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s
link: linkables are ...
LinkableM (2015-12-02 09:21:48 UTC) Main
[DotO test.o]
Linking test ...
*** C Compiler:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__
*** Linker:
/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -liconv -lgmp -lm -ldl
```
I noticed the following differences: Some of the linked libraries in the API case contain a -ghc7.10.2 suffix, e.g. -lHSrts-ghc7.10.2. When I execute the linking command without the suffix everything works fine.
So I looked into the directories of the referenced libraries. The rts directory contains the following content:
```
libCffi.a
libCffi_debug.a
libCffi_l.a
libCffi_p.a
libCffi_thr.a
libCffi_thr_debug.a
libCffi_thr_l.a
libCffi_thr_p.a
libHSrts-ghc7.10.2.dylib
libHSrts.a
libHSrts_debug-ghc7.10.2.dylib
libHSrts_debug.a
libHSrts_l-ghc7.10.2.dylib
libHSrts_l.a
libHSrts_p.a
libHSrts_thr-ghc7.10.2.dylib
libHSrts_thr.a
libHSrts_thr_debug-ghc7.10.2.dylib
libHSrts_thr_debug.a
libHSrts_thr_l-ghc7.10.2.dylib
libHSrts_thr_l.a
libHSrts_thr_p.a
libffi.dylib
```
It seams that only the library with the .dylib extension also have the `-ghc7.10.2` suffix in the file name. So, is this an issue with ghc, MacOS X or Nix?
Best,
Sven
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Problems using GHC-API on MacOS X","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I followed the instructions on the Haskell wiki \"GHC/As a library\" to compile a Haskell file:\r\n\r\n'''Main.hs'''\r\n{{{#!hs\r\nimport GHC\r\nimport GHC.Paths ( libdir )\r\nimport DynFlags\r\n\r\nmain = \r\n defaultErrorHandler defaultFatalMessager defaultFlushOut $ do\r\n runGhc (Just libdir) $ do\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags\r\n target <- guessTarget \"test.hs\" Nothing\r\n setTargets [target]\r\n load LoadAllTargets\r\n}}}\r\n\r\n'''test.hs'''\r\n{{{#!hs\r\nmain = putStrLn \"hello\"\r\n}}}\r\n\r\nI compile with ghc -package ghc -package ghc-paths --make Main.hs. When I execute ./Main, I get the following linking error:\r\n\r\n{{{\r\nld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _szZ_info from test.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie\r\nfinal section layout:\r\n __TEXT/__text addr=0x100000D40, size=0x00000206, fileOffset=0x00000D40, type=1\r\n __TEXT/__stubs addr=0x100000F46, size=0x0000001E, fileOffset=0x00000F46, type=28\r\n __TEXT/__stub_helper addr=0x100000F64, size=0x00000042, fileOffset=0x00000F64, type=32\r\n __TEXT/__const addr=0x100000FA8, size=0x0000000C, fileOffset=0x00000FA8, type=0\r\n __TEXT/__eh_frame addr=0x100000FB8, size=0x00000040, fileOffset=0x00000FB8, type=19\r\n __DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=30\r\n __DATA/__got addr=0x100001028, size=0x00000010, fileOffset=0x00001028, type=29\r\n __DATA/__nl_symbol_ptr addr=0x100001038, size=0x00000010, fileOffset=0x00001038, type=29\r\n __DATA/__la_symbol_ptr addr=0x100001048, size=0x00000028, fileOffset=0x00001048, type=27\r\n __DATA/__const addr=0x100001070, size=0x00000028, fileOffset=0x00001070, type=0\r\n __DATA/__data addr=0x100001098, size=0x00000060, fileOffset=0x00001098, type=0\r\n __DATA/__common addr=0x1000010F8, size=0x00000020, fileOffset=0x00000000, type=25\r\nld: 32-bit RIP relative reference out of range (-4294970840 max is +/-4GB): from _szZ_info (0x100000D98) to _ghczmprim_GHCziCString_unpackCStringzh_closure@0x0004A460 (0x00000000) in '_szZ_info' from test.o for architecture x86_64\r\nclang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)\r\n}}}\r\n\r\nI'm running the Nix package manager on MacOS X. Here are the compiler and linker commands for the GHC-API case.\r\n\r\n{{{\r\n*** Assembler:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s -o test.o\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s\r\nWarning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c\r\nWarning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s\r\nlink: linkables are ...\r\nLinkableM (2015-12-02 09:23:41 UTC) Main\r\n [DotO test.o]\r\nLinking test ...\r\n*** C Compiler:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__\r\n*** Linker:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -Wl,-rpath -Wl,/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -Wl,-rpath -Wl,/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw-ghc7.10.2 -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2 -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2 -lHSrts-ghc7.10.2 -lffi -liconv -lgmp -lm -ldl\r\n}}}\r\n\r\nAnd here is the compilation command for vanilla GHC:\r\n\r\n{{{\r\n*** Assembler:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s -o test.o\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s\r\nWarning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c\r\nWarning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s\r\nlink: linkables are ...\r\nLinkableM (2015-12-02 09:21:48 UTC) Main\r\n [DotO test.o]\r\nLinking test ...\r\n*** C Compiler:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__\r\n*** Linker:\r\n/nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store/aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -liconv -lgmp -lm -ldl\r\n}}}\r\n\r\nI noticed the following differences: Some of the linked libraries in the API case contain a -ghc7.10.2 suffix, e.g. -lHSrts-ghc7.10.2. When I execute the linking command without the suffix everything works fine.\r\nSo I looked into the directories of the referenced libraries. The rts directory contains the following content:\r\n\r\n{{{\r\nlibCffi.a\r\nlibCffi_debug.a\r\nlibCffi_l.a\r\nlibCffi_p.a\r\nlibCffi_thr.a\r\nlibCffi_thr_debug.a\r\nlibCffi_thr_l.a\r\nlibCffi_thr_p.a\r\nlibHSrts-ghc7.10.2.dylib\r\nlibHSrts.a\r\nlibHSrts_debug-ghc7.10.2.dylib\r\nlibHSrts_debug.a\r\nlibHSrts_l-ghc7.10.2.dylib\r\nlibHSrts_l.a\r\nlibHSrts_p.a\r\nlibHSrts_thr-ghc7.10.2.dylib\r\nlibHSrts_thr.a\r\nlibHSrts_thr_debug-ghc7.10.2.dylib\r\nlibHSrts_thr_debug.a\r\nlibHSrts_thr_l-ghc7.10.2.dylib\r\nlibHSrts_thr_l.a\r\nlibHSrts_thr_p.a\r\nlibffi.dylib\r\n}}}\r\n\r\nIt seams that only the library with the .dylib extension also have the `-ghc7.10.2` suffix in the file name. So, is this an issue with ghc, MacOS X or Nix?\r\n\r\nBest,\r\nSven","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11157(Optimized prime generation) ghc: panic! (the 'impossible' happened)2019-07-07T18:31:43Zjachymb(Optimized prime generation) ghc: panic! (the 'impossible' happened)I try to compile the example from https://wiki.haskell.org/Prime_numbers\#Using_ST_Array
```hs
{-# OPTIONS_GHC -O2 #-}
import Control.Monad
import Control.Monad.ST
import Data.Array.ST
import Data.Array.Unboxed
sieveUA :: Int -> UArr...I try to compile the example from https://wiki.haskell.org/Prime_numbers\#Using_ST_Array
```hs
{-# OPTIONS_GHC -O2 #-}
import Control.Monad
import Control.Monad.ST
import Data.Array.ST
import Data.Array.Unboxed
sieveUA :: Int -> UArray Int Bool
sieveUA top = runSTUArray $ do
let m = (top-1) `div` 2
r = floor . sqrt $ fromIntegral top + 1
sieve <- newArray (1,m) True -- :: ST s (STUArray s Int Bool)
forM_ [1..r `div` 2] $ \i -> do
isPrime <- readArray sieve i
when isPrime $ do -- ((2*i+1)^2-1)`div`2 == 2*i*(i+1)
forM_ [2*i*(i+1), 2*i*(i+2)+1..m] $ \j -> do
writeArray sieve j False
return sieve
```
I get the following error:
```
[1 of 1] Compiling Main ( p111.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
floatExpr tick break<29>()
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The error does not happen if I remove the OPTIONS_GHC -O2 directive.
I use ArchLinux and the GHC compiled package from it's standard repositories.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"(Optimized prime generation) ghc: panic! (the 'impossible' happened)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nI try to compile the example from https://wiki.haskell.org/Prime_numbers#Using_ST_Array \r\n{{{#!hs\r\n{-# OPTIONS_GHC -O2 #-}\r\n\r\nimport Control.Monad\r\nimport Control.Monad.ST\r\nimport Data.Array.ST\r\nimport Data.Array.Unboxed\r\n \r\nsieveUA :: Int -> UArray Int Bool\r\nsieveUA top = runSTUArray $ do\r\n let m = (top-1) `div` 2\r\n r = floor . sqrt $ fromIntegral top + 1\r\n sieve <- newArray (1,m) True -- :: ST s (STUArray s Int Bool)\r\n forM_ [1..r `div` 2] $ \\i -> do\r\n isPrime <- readArray sieve i\r\n when isPrime $ do -- ((2*i+1)^2-1)`div`2 == 2*i*(i+1)\r\n forM_ [2*i*(i+1), 2*i*(i+2)+1..m] $ \\j -> do\r\n writeArray sieve j False\r\n return sieve\r\n}}}\r\n\r\nI get the following error:\r\n{{{\r\n[1 of 1] Compiling Main ( p111.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tfloatExpr tick break<29>()\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n\r\nThe error does not happen if I remove the OPTIONS_GHC -O2 directive.\r\nI use ArchLinux and the GHC compiled package from it's standard repositories. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11171the 'impossible' happened when messing with existenial quantification and typ...2019-07-07T18:31:39ZTheKing42the 'impossible' happened when messing with existenial quantification and typed holesFirst of all, I am quite honored that I was able to do something that GHC considered impossible. (Funny too. Just the other day, I was trying to break GHC and failed. Today, I was doing something I thought was rather mundane (although it...First of all, I am quite honored that I was able to do something that GHC considered impossible. (Funny too. Just the other day, I was trying to break GHC and failed. Today, I was doing something I thought was rather mundane (although it was acting somewhat funky anyway)). Anyway, here is my error message:
```
*Main> :r
[1 of 1] Compiling Main ( pad.lhs, interpreted )
pad.lhs:12:25:
Couldn't match type ‘f1’ with ‘f’
‘f1’ is a rigid type variable bound by
the type signature for
wrap :: Functor f1 => f1 (CoInd f1) -> CoInd f1
at pad.lhs:11:11ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
No skolem info: f_abyA[sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
And here is the code
```hs
> {-# LANGUAGE DeriveFunctor, Rank2Types, ExistentialQuantification #-}
> newtype Ind f = Ind {flipinduct :: forall r. (f r -> r) -> r}
> induction = flip flipinduct
> data CoInd f = forall r. Coinduction (r -> f r) r
> coinduction = Coinduction
> data StringF rec = Nil | Cons Char rec deriving Functor
> wrap :: (Functor f) => f (CoInd f) -> CoInd f
> wrap fc = coinduction igo Nothing where
> igo :: Maybe (CoInd f) -> _
> igo Nothing = fmap Just fc
> igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed
> convert :: (Functor f) => Ind f -> CoInd f
> convert = induction wrap
> cowrap :: (Functor f) => Ind f -> f (Ind f)
> cowrap = induction igo where
> igo :: f (f (Ind f)) -> f (Ind f)
> igo = fmap (\fInd -> Ind $ \fold -> fold $ fmap (`flipinduct` fold) fInd)
> convert' :: (Functor f) => Ind f -> CoInd f
> convert' = coinduction cowrap
```
I think the important parts are only "CoInd", "wrap", and "igo", but I included it all just to be sure (and I'm lazy).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"the 'impossible' happened when messing with existenial quantification and typed holes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all, I am quite honored that I was able to do something that GHC considered impossible. (Funny too. Just the other day, I was trying to break GHC and failed. Today, I was doing something I thought was rather mundane (although it was acting somewhat funky anyway)). Anyway, here is my error message:\r\n\r\n\r\n{{{\r\n*Main> :r\r\n[1 of 1] Compiling Main ( pad.lhs, interpreted )\r\n\r\npad.lhs:12:25:\r\n Couldn't match type ‘f1’ with ‘f’\r\n ‘f1’ is a rigid type variable bound by\r\n the type signature for\r\n wrap :: Functor f1 => f1 (CoInd f1) -> CoInd f1\r\n at pad.lhs:11:11ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n No skolem info: f_abyA[sk]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nAnd here is the code\r\n\r\n{{{#!hs\r\n> {-# LANGUAGE DeriveFunctor, Rank2Types, ExistentialQuantification #-}\r\n\r\n> newtype Ind f = Ind {flipinduct :: forall r. (f r -> r) -> r}\r\n> induction = flip flipinduct\r\n\r\n> data CoInd f = forall r. Coinduction (r -> f r) r\r\n> coinduction = Coinduction\r\n\r\n> data StringF rec = Nil | Cons Char rec deriving Functor\r\n\r\n> wrap :: (Functor f) => f (CoInd f) -> CoInd f\r\n> wrap fc = coinduction igo Nothing where\r\n> igo :: Maybe (CoInd f) -> _\r\n> igo Nothing = fmap Just fc\r\n> igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed\r\n\r\n> convert :: (Functor f) => Ind f -> CoInd f\r\n> convert = induction wrap\r\n\r\n> cowrap :: (Functor f) => Ind f -> f (Ind f)\r\n> cowrap = induction igo where\r\n> igo :: f (f (Ind f)) -> f (Ind f)\r\n> igo = fmap (\\fInd -> Ind $ \\fold -> fold $ fmap (`flipinduct` fold) fInd)\r\n\r\n> convert' :: (Functor f) => Ind f -> CoInd f\r\n> convert' = coinduction cowrap\r\n}}}\r\n\r\nI think the important parts are only \"CoInd\", \"wrap\", and \"igo\", but I included it all just to be sure (and I'm lazy). ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11192Induced `Eq` constraint on numeric literal + partial type signature = panic!2019-07-07T18:31:32ZkwfInduced `Eq` constraint on numeric literal + partial type signature = panic!When I use a partial type signature in a non-top-level let-binding (or where clause), *and* the type is sufficiently ambiguous, *and* the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the infer...When I use a partial type signature in a non-top-level let-binding (or where clause), *and* the type is sufficiently ambiguous, *and* the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the inferred type of the hole.
So, this breaks:
```hs
module Fails where
fails :: a
fails =
let go :: _
go 0 a = a
in go (0 :: Int) undefined
```
```
Fails.hs:7:11:
Couldn't match expected type ‘a’ with actual type ‘Int’
‘a’ is untouchable
inside the constraints ()
bound by the type signature for fails :: a1
at Fails.hs:3:10ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
No skolem info: a_a1iD[sk]
```
1. ..but this succeeds:
```hs
module Succeeds where
succeeds :: a
succeeds =
let go :: _
go _ a = a
in go (0 :: Int) undefined
```
```
Succeeds.hs:13:14:
Found hole ‘_’ with type: t -> t1 -> t1
Where: ‘t’ is a rigid type variable bound by
the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8
‘t1’ is a rigid type variable bound by
the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8
To use the inferred type, enable PartialTypeSignatures
<snip>
```
The **only** difference between these two modules is the use of a numeric literal in a pattern match; that is, the troublesome line boils down to:
```hs
go 0 a = a
```
vs.
```hs
go _ a = a
```
Note that GHC gives us several pieces of feedback before talking about the panic. Before the above-quoted error, we get:
```
Fails.hs:5:14:
Found hole ‘_’ with type: a2 -> t1 -> t1
Where: ‘t1’ is a rigid type variable bound by
the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1
at Fails.hs:6:8
‘a2’ is a rigid type variable bound by
the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1
at Fails.hs:6:8
To use the inferred type, enable PartialTypeSignatures
<snip>
Fails.hs:6:8:
No instance for (Eq a)
When checking that ‘go’ has the specified type
go :: forall t a. a -> t -> t
Probable cause: the inferred type is ambiguous
<snip>
Fails.hs:7:7:
Couldn't match expected type ‘a1’ with actual type ‘t’
because type variable ‘a1’ would escape its scope
This (rigid, skolem) type variable is bound by
the type signature for fails :: a1
at Fails.hs:3:10
<snip>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.2 |
| 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":"Induced `Eq` constraint on numeric literal + partial type signature = panic!","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["happened,","impossible","literal,","numeric","panic","partial","signature,","the","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I use a partial type signature in a non-top-level let-binding (or where clause), ''and'' the type is sufficiently ambiguous, ''and'' the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the inferred type of the hole.\r\n\r\nSo, this breaks:\r\n\r\n{{{#!hs\r\nmodule Fails where\r\n\r\nfails :: a\r\nfails =\r\n let go :: _\r\n go 0 a = a\r\n in go (0 :: Int) undefined\r\n}}}\r\n\r\n{{{\r\nFails.hs:7:11:\r\n Couldn't match expected type ‘a’ with actual type ‘Int’\r\n ‘a’ is untouchable\r\n inside the constraints ()\r\n bound by the type signature for fails :: a1\r\n at Fails.hs:3:10ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-apple-darwin):\r\n No skolem info: a_a1iD[sk]\r\n}}}\r\n\r\n...but this succeeds:\r\n\r\n{{{#!hs\r\nmodule Succeeds where\r\n\r\nsucceeds :: a\r\nsucceeds = \r\n let go :: _\r\n go _ a = a\r\n in go (0 :: Int) undefined\r\n}}}\r\n\r\n{{{\r\nSucceeds.hs:13:14:\r\n Found hole ‘_’ with type: t -> t1 -> t1\r\n Where: ‘t’ is a rigid type variable bound by\r\n the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8\r\n ‘t1’ is a rigid type variable bound by\r\n the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8\r\n To use the inferred type, enable PartialTypeSignatures\r\n <snip>\r\n}}}\r\n\r\nThe '''only''' difference between these two modules is the use of a numeric literal in a pattern match; that is, the troublesome line boils down to:\r\n\r\n{{{#!hs\r\ngo 0 a = a\r\n}}}\r\n\r\nvs.\r\n\r\n{{{#!hs\r\ngo _ a = a\r\n}}}\r\n\r\nNote that GHC gives us several pieces of feedback before talking about the panic. Before the above-quoted error, we get:\r\n\r\n{{{\r\nFails.hs:5:14:\r\n Found hole ‘_’ with type: a2 -> t1 -> t1\r\n Where: ‘t1’ is a rigid type variable bound by\r\n the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1\r\n at Fails.hs:6:8\r\n ‘a2’ is a rigid type variable bound by\r\n the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1\r\n at Fails.hs:6:8\r\n To use the inferred type, enable PartialTypeSignatures\r\n <snip>\r\n\r\nFails.hs:6:8:\r\n No instance for (Eq a)\r\n When checking that ‘go’ has the specified type\r\n go :: forall t a. a -> t -> t\r\n Probable cause: the inferred type is ambiguous\r\n <snip>\r\n\r\nFails.hs:7:7:\r\n Couldn't match expected type ‘a1’ with actual type ‘t’\r\n because type variable ‘a1’ would escape its scope\r\n This (rigid, skolem) type variable is bound by\r\n the type signature for fails :: a1\r\n at Fails.hs:3:10\r\n <snip>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11195New pattern-match check can be non-performant2020-02-27T09:15:11ZRichard Eisenbergrae@richarde.devNew pattern-match check can be non-performantIn my work in merging [D808](https://phabricator.haskell.org/D808) (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (\~10GB) to check !OptCoercion in the stage-2 compiler....In my work in merging [D808](https://phabricator.haskell.org/D808) (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (\~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times.
To reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode.
So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file.
There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help.
NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"New pattern-match check can be non-performant","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In my work in merging Phab:D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times.\r\n\r\nTo reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode.\r\n\r\nSo that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file.\r\n\r\nThere is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help.\r\n\r\nNB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11202T10667 and debug tests are broken on OS X2019-07-07T18:31:29ZBen GamariT10667 and debug tests are broken on OS XThis is due to the use of `-g` by this testcase, which apparently the broken on Darwin. The test fails with,
```
=====> T10667(normal) 2 of 18 [0, 1, 0]
cd ./codeGen/should_compile && "/Users/bgamari/ghc/inplace/test spaces/ghc-stag...This is due to the use of `-g` by this testcase, which apparently the broken on Darwin. The test fails with,
```
=====> T10667(normal) 2 of 18 [0, 1, 0]
cd ./codeGen/should_compile && "/Users/bgamari/ghc/inplace/test spaces/ghc-stage2" -c T10667.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -g > T10667.comp.stderr 2>&1
Compile failed (status 256) errors were:
/var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:101:2: error:
error: unknown directive
.hword 3
^
/var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:129:2: error:
error: unknown directive
.hword 1
^
/var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:131:2: error:
error: unknown directive
.hword 13
^
.
.
.
```
[Apparently](https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF101) we should be using `.short` on Darwin.8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11205Validation on ARM fails to due Corex-A8 erratum check2019-07-07T18:31:28ZBen GamariValidation on ARM fails to due Corex-A8 erratum checkNumerous tests fail during validation on ARM due to linking issues. All seem to be of the flavor,
```
=====> RolesIArray(normal) 74 of 4859 [0, 18, 1]
--- /dev/null 2015-12-11 10:17:52.480000000 +0100
+++ ./warnings/should_compile/T1...Numerous tests fail during validation on ARM due to linking issues. All seem to be of the flavor,
```
=====> RolesIArray(normal) 74 of 4859 [0, 18, 1]
--- /dev/null 2015-12-11 10:17:52.480000000 +0100
+++ ./warnings/should_compile/T10890/T10890.comp.stderr.normalised 2015-12-11 22:25:38.453251095 +0100
@@ -0,0 +1,174 @@
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Either.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Typeable.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Signal.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Sync.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Err.o) for Cortex-A8 erratum because it has no mapping symbols.
+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Exception.o) for Cortex-A8 erratum because it has no mapping symbols.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"Validation on ARM fails to due Corex-A8 erratum check","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Numerous tests fail during validation on ARM due to linking issues. All seem to be of the flavor,\r\n{{{\r\n=====> RolesIArray(normal) 74 of 4859 [0, 18, 1] \r\n--- /dev/null 2015-12-11 10:17:52.480000000 +0100\r\n+++ ./warnings/should_compile/T10890/T10890.comp.stderr.normalised 2015-12-11 22:25:38.453251095 +0100\r\n@@ -0,0 +1,174 @@\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Either.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Typeable.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Signal.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Sync.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Err.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n+/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Exception.o) for Cortex-A8 erratum because it has no mapping symbols.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11220Stack overflow instead of type check failure in Servant route2019-07-07T18:31:25ZLeonid OnokhovStack overflow instead of type check failure in Servant routeGHC 7.10.3 eats a lot of memory and segfaults compiling this.
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE TypeOperators #-}
module Main where
import Data.Proxy
import Servant...GHC 7.10.3 eats a lot of memory and segfaults compiling this.
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE TypeOperators #-}
module Main where
import Data.Proxy
import Servant.API -- requires servant
data A
apiP :: Proxy Api
apiP = Proxy
-- Users
type Api = "variants" :> Get '[JSON] ()
routeL :: URI
routeL = safeLink apiP
(Proxy :: Proxy ("variants" :> Get '[A] ()))
-- Should result in type error
-- '[JSON] in route but '[A] here
main = print routeL
```
There is `'[ JSON ]` in `Api` type, but `'[A]` in `Proxy` type passed to `safeLink`, so it should result in type error.
Correct program compiles without problems.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11223Runtime linker performs eager loading of all object files2021-11-11T17:51:13ZTamar ChristinaRuntime linker performs eager loading of all object filesThe runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1...The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error.
### A workaround
The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile.
```
128 emptyPLS :: DynFlags -> PersistentLinkerState
129 emptyPLS _ = PersistentLinkerState {
130 closure_env = emptyNameEnv,
131 itbl_env = emptyNameEnv,
132 pkgs_loaded = init_pkgs,
133 bcos_loaded = [],
134 objs_loaded = [],
135 temp_sos = [] }
136
137 -- Packages that don't need loading, because the compiler
138 -- shares them with the interpreted program.
139 --
140 -- The linker's symbol table is populated with RTS symbols using an
141 -- explicit list. See rts/Linker.c for details.
142 where init_pkgs = [rtsUnitId]
```
I've tried 2 approaches which haven't worked completely:
1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach.
1. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors.
What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet.
### Example
```hs
-- LogFloat.hs
module Main (main) where
import Data.Number.LogFloat (log1p)
main :: IO ()
main = print $ log1p 1.0
```
`runGhc LogFloat.hs` will fail:
```
Loading package logfloat-0.13.3.3 ...
linking ...
LogFloat.hs: ...\x86_64-windows-ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p'
LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3'
```8.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/11274Confused type checker with typed holes and a missing instance (also panic)2019-07-07T18:31:10ZXandarosConfused type checker with typed holes and a missing instance (also panic)If your file contains a typed hole and a case where an instance is missing, the type checker will not find the missing instance and only report the hole.
If -fdefer-typed-holes is set, this results in a panic.
(Using ghci, the panic occu...If your file contains a typed hole and a case where an instance is missing, the type checker will not find the missing instance and only report the hole.
If -fdefer-typed-holes is set, this results in a panic.
(Using ghci, the panic occurs when any definition of the module is being evaluated)
Minimal working example:
```hs
{-# OPTIONS_GHC -fdefer-typed-holes #-}
data Asd = Asd
someHole = _asd
missingInstance :: Asd -> Asd -> Bool
missingInstance x y = x == y
```
<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":"Confused type checker with typed holes and a missing instance (also panic)","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":"If your file contains a typed hole and a case where an instance is missing, the type checker will not find the missing instance and only report the hole.\r\nIf -fdefer-typed-holes is set, this results in a panic.\r\n(Using ghci, the panic occurs when any definition of the module is being evaluated)\r\n\r\nMinimal working example:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fdefer-typed-holes #-}\r\ndata Asd = Asd\r\n\r\nsomeHole = _asd\r\n\r\nmissingInstance :: Asd -> Asd -> Bool\r\nmissingInstance x y = x == y\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11283PatternSynonms and DisambiguateRecordFields causes panic2019-07-07T18:31:07ZAdam GundryPatternSynonms and DisambiguateRecordFields causes panicThe following module causes a panic in HEAD:
```hs
{-# LANGUAGE PatternSynonyms, DisambiguateRecordFields #-}
data P a = MkP a
pattern S{x} = MkP x
e = S{x = 3}
```
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11...The following module causes a panic in HEAD:
```hs
{-# LANGUAGE PatternSynonyms, DisambiguateRecordFields #-}
data P a = MkP a
pattern S{x} = MkP x
e = S{x = 3}
```
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151223 for x86_64-unknown-linux):
find_tycon
S
[S pattern synonym defined at PatSynBug.hs:3:1]
```
This is essentially the same bug as #9975; for some reason it became slightly harder to tickle. Fix incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"PatternSynonms and DisambiguateRecordFields causes panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"adamgundry"},"version":"7.11","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following module causes a panic in HEAD:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, DisambiguateRecordFields #-}\r\ndata P a = MkP a\r\npattern S{x} = MkP x\r\ne = S{x = 3}\r\n}}}\r\n\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20151223 for x86_64-unknown-linux):\r\n\tfind_tycon\r\n S\r\n [S pattern synonym defined at PatSynBug.hs:3:1]\r\n}}}\r\n\r\nThis is essentially the same bug as #9975; for some reason it became slightly harder to tickle. Fix incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/11291DfltProb1(optasm): panic CoreToStg.myCollectArgs2019-07-07T18:31:05ZThomas MiedemaDfltProb1(optasm): panic CoreToStg.myCollectArgsThe program looks like this:
```hs
module DfltProb1 where
import Control.Monad.ST
import Prelude hiding (traverse)
traverse :: a -> ST s [a]
traverse = undefined
-- WORKS with signature test :: Num a => [a]
test = runST (traverse 1)
...The program looks like this:
```hs
module DfltProb1 where
import Control.Monad.ST
import Prelude hiding (traverse)
traverse :: a -> ST s [a]
traverse = undefined
-- WORKS with signature test :: Num a => [a]
test = runST (traverse 1)
main = print test
```
This is the failure:
```
$ ghc-7.11.20151225 -O DfltProb1.hs
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151224 for x86_64-unknown-linux):
CoreToStg.myCollectArgs
(case traverse of _ [Occ=Dead] { }) realWorld#
```8.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/11334GHC panic when calling typeOf on a promoted data constructor2019-07-07T18:30:53ZRyan ScottGHC panic when calling typeOf on a promoted data constructorHere's what I did in GHCi to trigger the panic:
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160101: http://www.haskell.org/ghc/ :? for help
λ> :set -XDataKinds
λ> :m Data.Typeable Data.Functor.Compose
λ> typeOf (Prox...Here's what I did in GHCi to trigger the panic:
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160101: http://www.haskell.org/ghc/ :? for help
λ> :set -XDataKinds
λ> :m Data.Typeable Data.Functor.Compose
λ> typeOf (Proxy :: Proxy 'Compose)
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160101 for x86_64-unknown-linux):
piResultTy
*
TYPE 'Lifted *
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Enabling `-XPolyKinds` doesn't trigger the error, though; #10343 will be triggered instead:
```
λ> :set -XPolyKinds
λ> typeOf (Proxy :: Proxy 'Compose)
<interactive>:5:1: error:
• No instance for (Typeable a0) arising from a use of ‘typeOf’
• In the expression: typeOf (Proxy :: Proxy Compose)
In an equation for ‘it’: it = typeOf (Proxy :: Proxy Compose)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic when calling typeOf on a promoted data constructor","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"Here's what I did in GHCi to trigger the panic:\r\n\r\n{{{\r\n$ inplace/bin/ghc-stage2 --interactive\r\nGHCi, version 8.1.20160101: http://www.haskell.org/ghc/ :? for help\r\nλ> :set -XDataKinds\r\nλ> :m Data.Typeable Data.Functor.Compose\r\nλ> typeOf (Proxy :: Proxy 'Compose)\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160101 for x86_64-unknown-linux):\r\n piResultTy\r\n *\r\n TYPE 'Lifted *\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nEnabling `-XPolyKinds` doesn't trigger the error, though; #10343 will be triggered instead:\r\n\r\n{{{\r\nλ> :set -XPolyKinds\r\nλ> typeOf (Proxy :: Proxy 'Compose)\r\n\r\n<interactive>:5:1: error:\r\n • No instance for (Typeable a0) arising from a use of ‘typeOf’\r\n • In the expression: typeOf (Proxy :: Proxy Compose)\r\n In an equation for ‘it’: it = typeOf (Proxy :: Proxy Compose)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11336GHC craches on this combination of ViewPatterns and PatternSynonyms2019-11-08T20:24:44ZbaramogloGHC craches on this combination of ViewPatterns and PatternSynonymsThe attached file crashes:
```
$ ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Prelude.last: empty list
```
I wasn't able to ...The attached file crashes:
```
$ ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Prelude.last: empty list
```
I wasn't able to shrink the example further despite many attepts.
Tested on GHC 7.8.3 and 7.10.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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 craches on this combination of ViewPatterns and PatternSynonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached file crashes:\r\n\r\n{{{\r\n$ ghc Bug.hs \r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for x86_64-unknown-linux):\r\n\tPrelude.last: empty list\r\n}}}\r\n\r\nI wasn't able to shrink the example further despite many attepts.\r\n\r\nTested on GHC 7.8.3 and 7.10.2.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11356GHC panic2019-07-07T18:30:46ZIcelandjackGHC panicThe attached file causes GHC (version 8.1.20160102) panic.
I tried shrinking, attached code is bogus at this point.
Interestingly inlining the type synonym `T = Nat` into Category's superclass context fixes the panic, and causes a regu...The attached file causes GHC (version 8.1.20160102) panic.
I tried shrinking, attached code is bogus at this point.
Interestingly inlining the type synonym `T = Nat` into Category's superclass context fixes the panic, and causes a regular error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.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 panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached file causes GHC (version 8.1.20160102) panic.\r\n\r\nI tried shrinking, attached code is bogus at this point.\r\n\r\nInterestingly inlining the type synonym `T = Nat` into Category's superclass context fixes the panic, and causes a regular error.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11380Compiling a 10.000 line file exhausts memory2021-03-31T16:06:53ZkennethbCompiling a 10.000 line file exhausts memoryI have a project that depends on happy/alex to generate parsers.
(https://github.com/TOSPIO/pyn)
Running `cabal repl` on my laptop with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic.
Problem arises ...I have a project that depends on happy/alex to generate parsers.
(https://github.com/TOSPIO/pyn)
Running `cabal repl` on my laptop with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic.
Problem arises when compiling the giant happy-generated dist/build/Language/Python/Parser/Parse.hs file. The memory usage is flat (\~1.5G) within the first 2 mins, and the soars up to over 10GB within seconds.
`cabal build` and `cabal repl --ghc-options=-fobject-code` works fine.https://gitlab.haskell.org/ghc/ghc/-/issues/11399Ill-kinded instance head involving -XTypeInType can invoke GHC panic2019-07-07T18:30:35ZRyan ScottIll-kinded instance head involving -XTypeInType can invoke GHC panicThis code:
```hs
{-# LANGUAGE FlexibleInstances, TypeInType #-}
module FvProvFallsIntoAHole where
import Data.Kind
newtype UhOh (k :: * -> *) (a :: k *) = UhOh (k *)
instance Functor k => Functor (UhOh k) where
```
produces this GHC ...This code:
```hs
{-# LANGUAGE FlexibleInstances, TypeInType #-}
module FvProvFallsIntoAHole where
import Data.Kind
newtype UhOh (k :: * -> *) (a :: k *) = UhOh (k *)
instance Functor k => Functor (UhOh k) where
```
produces this GHC panic:
```
$ /opt/ghc/head/bin/ghc FvProvFallsIntoAHole.hs
[1 of 1] Compiling FvProvFallsIntoAHole ( FvProvFallsIntoAHole.hs, FvProvFallsIntoAHole.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.1.20160108 for x86_64-unknown-linux):
fvProv falls into a hole {aq6}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ill-kinded instance head involving -XTypeInType can invoke GHC panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"This code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE FlexibleInstances, TypeInType #-}\r\nmodule FvProvFallsIntoAHole where\r\n\r\nimport Data.Kind\r\n\r\nnewtype UhOh (k :: * -> *) (a :: k *) = UhOh (k *)\r\ninstance Functor k => Functor (UhOh k) where\r\n}}}\r\n\r\nproduces this GHC panic:\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghc FvProvFallsIntoAHole.hs\r\n[1 of 1] Compiling FvProvFallsIntoAHole ( FvProvFallsIntoAHole.hs, FvProvFallsIntoAHole.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160108 for x86_64-unknown-linux):\r\n fvProv falls into a hole {aq6}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11442Segfault when showing (undefined :: Type)2019-07-07T18:30:24ZIcelandjackSegfault when showing (undefined :: Type)This [comment](https://ghc.haskell.org/trac/ghc/ticket/11311#comment:3) made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`:
#11311?replyto=3\##11442
```hs
{-# LANGUAGE TypeSyn...This [comment](https://ghc.haskell.org/trac/ghc/ticket/11311#comment:3) made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`:
#11311?replyto=3\##11442
```hs
{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-
import Data.Kind (Type)
instance Show Type where
show _ = "..."
main = print (undefined :: Type)
```
running gives:
```
$ runghc --version
runghc 8.1.20160113
$ runghc -ignore-dot-ghci Segfault.hs
Segmentation fault (core dumped)
```
Verbose log attached.https://gitlab.haskell.org/ghc/ghc/-/issues/11516Panic, "falls into a hole"2019-07-07T18:30:06ZIcelandjackPanic, "falls into a hole"```hs
{-# language PolyKinds #-}
{-# language FlexibleContexts #-}
{-# language ConstraintKinds #-}
{-# language FlexibleInstances #-}
{-# language FunctionalDependencies #-}
import GHC.Types (Constraint)
class Ríki (p :: i -> i -> *)
...```hs
{-# language PolyKinds #-}
{-# language FlexibleContexts #-}
{-# language ConstraintKinds #-}
{-# language FlexibleInstances #-}
{-# language FunctionalDependencies #-}
import GHC.Types (Constraint)
class Ríki (p :: i -> i -> *)
class (Ríki p) => Varpi p q f | f -> p q
instance Varpi () () f => Varpi (->) (->) (Either f) where
```
causes
```
% ghci -ignore-dot-ghci /tmp/testing.hs
GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/testing.hs, interpreted )
/tmp/testing.hs:11:10: error:ghc: panic! (the 'impossible' happened)
(GHC version 8.1.20160117 for x86_64-unknown-linux):
fvProv falls into a hole {a13R}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
Leaving GHCi.
```
<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":"Panic, \"falls into a hole\"","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":"{{{#!hs\r\n{-# language PolyKinds #-}\r\n{-# language FlexibleContexts #-}\r\n{-# language ConstraintKinds #-}\r\n{-# language FlexibleInstances #-}\r\n{-# language FunctionalDependencies #-}\r\n\r\nimport GHC.Types (Constraint)\r\n\r\nclass Ríki (p :: i -> i -> *)\r\nclass (Ríki p) => Varpi p q f | f -> p q\r\ninstance Varpi () () f => Varpi (->) (->) (Either f) where\r\n}}}\r\n\r\ncauses\r\n\r\n{{{\r\n% ghci -ignore-dot-ghci /tmp/testing.hs \r\nGHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/testing.hs, interpreted )\r\n\r\n/tmp/testing.hs:11:10: error:ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160117 for x86_64-unknown-linux):\r\n fvProv falls into a hole {a13R}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\nLeaving GHCi.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/11532ghc: panic! occured2019-07-07T18:29:56Zcutsea110ghc: panic! occuredI'd like to try install by following:
```
$ cabal sandbox init
$ cabal install metadata
Resolving dependencies...
Notice: installing into a sandbox located at
/home/cutsea110/devel/haskell/sandbox/.cabal-sandbox
Configuring metadata-0.4...I'd like to try install by following:
```
$ cabal sandbox init
$ cabal install metadata
Resolving dependencies...
Notice: installing into a sandbox located at
/home/cutsea110/devel/haskell/sandbox/.cabal-sandbox
Configuring metadata-0.4.2.0...
Building metadata-0.4.2.0...
:
:
[1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox-304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot )
[1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox-304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
LocalReg's live-in to graph cpd3t {_sp8MJ::P64}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
metadata-0.4.2.0 failed during the building phase. The exception was:
ExitFailure 1
```
--
regards.
<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: panic! occured","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":"I'd like to try install by following:\r\n\r\n{{{\r\n$ cabal sandbox init\r\n$ cabal install metadata\r\nResolving dependencies...\r\nNotice: installing into a sandbox located at\r\n/home/cutsea110/devel/haskell/sandbox/.cabal-sandbox\r\nConfiguring metadata-0.4.2.0...\r\nBuilding metadata-0.4.2.0...\r\n:\r\n:\r\n\r\n[1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox-304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot )\r\n[1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox-304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-unknown-linux):\r\n LocalReg's live-in to graph cpd3t {_sp8MJ::P64}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Error: some packages failed to install:\r\nmetadata-0.4.2.0 failed during the building phase. The exception was:\r\nExitFailure 1\r\n\r\n}}}\r\n\r\n-- \r\n\r\nregards.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/11550ghc-HEAD -DDEBUG is broken (possiby by D1880)2019-07-07T18:29:52ZSergei Trofimovichghc-HEAD -DDEBUG is broken (possiby by D1880)Was found when tried to build with
> BuildFlavour = devel2
```
ghc-validate $ LANG=C make V=0
HC [stage 2] libraries/parallel/dist-install/build/Control/Seq.o
WARNING: file compiler/stgSyn/CoreToStg.hs, line 250
using False True
...Was found when tried to build with
> BuildFlavour = devel2
```
ghc-validate $ LANG=C make V=0
HC [stage 2] libraries/parallel/dist-install/build/Control/Seq.o
WARNING: file compiler/stgSyn/CoreToStg.hs, line 250
using False True
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160206 for x86_64-unknown-linux):
ASSERT failed!
CallStack (from HasCallStack):
assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:216:59 in ghc:CoreToStg
using
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
> https://travis-ci.org/ghc/ghc/builds
suggests
> changeset:4f9967aa3d1f7cfd539d0c173cafac0fe290e26f
might be at fault.
Reverting it on top of master fixes devel2 build.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | osa1, skvadrik |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-HEAD -DDEBUG is broken (possiby by D1880)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["osa1","skvadrik"],"type":"Bug","description":"Was found when tried to build with\r\n BuildFlavour = devel2\r\n\r\n{{{\r\nghc-validate $ LANG=C make V=0\r\n\r\n HC [stage 2] libraries/parallel/dist-install/build/Control/Seq.o\r\nWARNING: file compiler/stgSyn/CoreToStg.hs, line 250\r\n using False True\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160206 for x86_64-unknown-linux):\r\n ASSERT failed!\r\n CallStack (from HasCallStack):\r\n assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:216:59 in ghc:CoreToStg\r\n using\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n\r\n https://travis-ci.org/ghc/ghc/builds\r\nsuggests\r\n changeset:4f9967aa3d1f7cfd539d0c173cafac0fe290e26f\r\nmight be at fault.\r\n\r\nReverting it on top of master fixes devel2 build.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11554Self quantification in GADT data declarations2020-09-19T20:01:19ZRafbillSelf quantification in GADT data declarationsGHC hangs on this (it was panicking on the same code before : [https://github.com/goldfirere/ghc/issues/56](https://github.com/goldfirere/ghc/issues/56)(https://github.com/goldfirere/ghc/issues/56) :
```hs
{-# LANGUAGE GADTs, TypeInType...GHC hangs on this (it was panicking on the same code before : [https://github.com/goldfirere/ghc/issues/56](https://github.com/goldfirere/ghc/issues/56)(https://github.com/goldfirere/ghc/issues/56) :
```hs
{-# LANGUAGE GADTs, TypeInType #-}
import Data.Kind
data A :: Type where
B :: forall (a :: A). A
```
I guess the typechecker tries to infer the kind of A from the type of the constructors and hangs. Maybe recursive occurrences of a type as a kind in its constructors should only be allowed when its kind signature is specified and can be used to typecheck the constructors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Self quantification in GADT data declarations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC hangs on this (it was panicking on the same code before : [https://github.com/goldfirere/ghc/issues/56](https://github.com/goldfirere/ghc/issues/56) :\r\n{{{#!hs\r\n{-# LANGUAGE GADTs, TypeInType #-}\r\nimport Data.Kind\r\ndata A :: Type where\r\n B :: forall (a :: A). A\r\n}}}\r\n\r\nI guess the typechecker tries to infer the kind of A from the type of the constructors and hangs. Maybe recursive occurrences of a type as a kind in its constructors should only be allowed when its kind signature is specified and can be used to typecheck the constructors.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11560panic: isInjectiveTyCon sees a TcTyCon2019-07-07T18:29:48Zrwbartonpanic: isInjectiveTyCon sees a TcTyConI typed this into ghci and it panicked. Not sure whether the declaration is really valid anyways, but ghci shouldn't panic on it.
```
rwbarton@morphism:~/ghc-newest$ ./inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160201: htt...I typed this into ghci and it panicked. Not sure whether the declaration is really valid anyways, but ghci shouldn't panic on it.
```
rwbarton@morphism:~/ghc-newest$ ./inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160201: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XTypeFamilies -XTypeInType
Prelude> :m +Data.Kind
Prelude Data.Kind> type family T (l :: *) (k :: l) :: * where { T * Int = * }
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160201 for x86_64-unknown-linux):
isInjectiveTyCon sees a TcTyCon T
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.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":"panic: isInjectiveTyCon sees a TcTyCon","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I typed this into ghci and it panicked. Not sure whether the declaration is really valid anyways, but ghci shouldn't panic on it.\r\n{{{\r\nrwbarton@morphism:~/ghc-newest$ ./inplace/bin/ghc-stage2 --interactive\r\nGHCi, version 8.1.20160201: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XTypeFamilies -XTypeInType\r\nPrelude> :m +Data.Kind\r\nPrelude Data.Kind> type family T (l :: *) (k :: l) :: * where { T * Int = * }\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160201 for x86_64-unknown-linux):\r\n\tisInjectiveTyCon sees a TcTyCon T\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11580panic on incompatible options2019-07-07T18:29:44Zdougmpanic on incompatible optionsThis torture test causes ghc to panic for incompatible options Unsafe and Trustworthy
```
ghc `ghc --supported-languages | sed 's/^/-X/'`
```
The two options alone lead to a correct diagnostic.
So does deletion of either from the f...This torture test causes ghc to panic for incompatible options Unsafe and Trustworthy
```
ghc `ghc --supported-languages | sed 's/^/-X/'`
```
The two options alone lead to a correct diagnostic.
So does deletion of either from the full list.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic on incompatible options","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This torture test causes ghc to panic for incompatible options Unsafe and Trustworthy\r\n{{{\r\n ghc `ghc --supported-languages | sed 's/^/-X/'`\r\n}}}\r\nThe two options alone lead to a correct diagnostic.\r\nSo does deletion of either from the full list.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1kaihakaihahttps://gitlab.haskell.org/ghc/ghc/-/issues/11600Panic (ASSERT failed) in compiler/types/TyCoRep.hs:19392019-07-07T18:29:39ZHerbert Valerio Riedelhvr@gnu.orgPanic (ASSERT failed) in compiler/types/TyCoRep.hs:1939This happens when trying to update the `transformers` submodule to 0.5.2.0 (see `wip/transformers-0.5.2`-branch), then during `validate` the following panic occurs:
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -...This happens when trying to update the `transformers` submodule to 0.5.2.0 (see `wip/transformers-0.5.2`-branch), then during `validate` the following panic occurs:
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id haskeline-0.7.2.2 -package-id process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -dcore-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI.hs -o ghc/stage2/build/GHCi/UI.dyn_o
WARNING: file compiler/specialise/Specialise.hs, line 1173
Missed specialisation opportunity for $fMonadIOExceptT_$cliftIO
[] 2 [] 1 [ALWAYS]
WARNING: file compiler/specialise/Specialise.hs, line 1173
Missed specialisation opportunity for $w$c<*>
[] 2 [] 1 [0]
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.1.20160218 for x86_64-unknown-linux):
ASSERT failed!
file compiler/types/TyCoRep.hs line 1939
in_scope InScope {fromTarget_aiKD pprTT_aj4s pp_resume_aj4J
opts_ajdx flagList_ajdy $dMonad_anX0 $dOrd_areH $dEq_as40
$dRead_as5N $dEq_aswW $dMonadIO_at39 $dApplicative_atce $dShow_atnW
$dMonad_ats4 $dFunctor_atsk $dNFData_awOZ $dEq_azf8 $dFunctor_azfb
$dHasGhciState_azfd $dNFData_aAFw $trModule availableCommands
shortHelpText fullHelpText defPrompt defPrompt2 defaultGhciSettings
ghciWelcomeMsg ghciCommands word_break_chars specials spaces
flagWordBreakChars keepGoing keepGoing' keepGoingPaths
defShortHelpText defFullHelpText findEditor default_progname
default_prompt default_prompt2 interactiveUI
resetLastErrorLocations withGhcAppData runGHCiInput
checkFileAndDirPerms checkPerms incrementLineNo fileLoop mkPrompt
queryQueue installInteractivePrint runCommands runCommands'
runOneCommand checkInputForLayout enqueueCommands runStmt
afterRunStmt runSuccess runAllocs printTypeOfNames compareNames
printTypeOfName lookupCommand' getCurrentBreakSpan
getCurrentBreakModule noArgs withSandboxOnly help info
filterOutChildren pprInfo doWithArgs changeDirectory trySuccess
chooseEditFile defineMacro getGhciStepIO deferredLoad loadModule
loadModule_ reloadModule doLoadAndCollectInfo afterLoad
setContextAfterLoad setContextKeepingPackageModules
keepPackageImports runExceptGhcMonad exceptT parseSpanArg
showSrcSpan showRealSrcSpan kindOfType isSafeModule browseCmd
guessCurrentModule browseModule addModulesToContext
addModulesToContext_ remModulesFromContext setContext addII
restoreContextOnFailure checkAdd setGHCContextFromGHCiState
mkIIDecl iiModules iiModuleName preludeModuleName
implicitPreludeImport isPreludeImport iiSubsumes showOptions
showDynFlags setArgs setProg setEditor setStop setPrompt setPrompt2
setPrompt_ packageFlagsChanged newDynFlags isMinus isPlus setOpt
unsetOpt strToGHCiOpt showImports showModules getLoadedModules
showBindings showBkptTable showContext pprStopped showPackages
showPaths showLanguages showiLanguages showLanguages'
ghciCompleteWord completeGhciCommand completeIdentifier
completeModule listHomeModules completeSetOptions
completeHomeModuleOrFile wrapCompleter wrapIdentCompleter
completeExpression pprintCommand stepCmd leftmostLargestRealSrcSpan
doContinue bold breakSwitch breakByModuleLine breakSyntax
findBreakAndSet findBreakByCoord do_bold start_bold end_bold
listModuleLine listAround getTickArray discardTickArrays
discardActiveBreakPoints turnOffBreak getModBreak handler
showException ghciHandle tryBool lookupModule lookupModuleName
expandPath expandPathIO wantInterpretedModule
wantInterpretedModuleName wantNameFromInterpretedModule
$tc'GhciSettings $tcGhciSettings $tc'GotCommand $tc'BadCommand
$tc'NoLastCommand $tcMaybeCommand a_sKa7 a_sKa8 a_sKa9 a_sKaa
a_sKag a_sKah a_sKai a_sKaj a_sKdg a_sKrw a_sKvG a_sKvH a_sKvI
a_sKwn a_sKwo a_sKws a_sKwt a_sKxU a_sKxV a_sKy8 a_sKy9 a_sKyg
a_sKyh a_sKyk a_sKyl a_sKyV a_sKAe a_sKAk a_sKAl a_sKAm a_sKAn
a_sKAo a_sKAp a_sKAq a_sKAr a_sKAs a_sKAt a_sKAu a_sKD4 a_sKEx
a_sKEy a_sKEz a_sKEA a_sKEB a_sKEC a_sKF1 a_sKF2 a_sKFj a_sKFk
a_sKFm a_sKFn a_sKMd a_sKMe a_sKMf a_sKMg a_sKMh a_sKOX a_sKQx
a_sKQy a_sKTg a_sKWr a_sKWs a_sKWt a_sLrp a_sLrs a_sLrB a_sLs3
a_sLs5 a_sLsd a_sLsV a_sLtg a_sLtY a_sLv2 a_sLv7 a_sLvB a_sLvF
a_sLvP a_sLvT a_sLwI}
tenv [alhH :-> InputT GHCi, alhI :-> e_alhI]
tenvFVs [alhI :-> e_alhI]
cenv []
cenvFVs []
tys []
cos [forall (a17_aDzt :: <*>_N).
<String>_R
-> Sym (N:ExceptT[0] <e_alhI>_N <m_alhH>_R <a17_aDzt>_N)]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
ghc/ghc.mk:112: recipe for target 'ghc/stage2/build/GHCi/UI.dyn_o' failed
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| 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":"Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This happens when trying to update the `transformers` submodule to 0.5.2.0 (see `wip/transformers-0.5.2`-branch), then during `validate` the following panic occurs:\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id haskeline-0.7.2.2 -package-id process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -dcore-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI.hs -o ghc/stage2/build/GHCi/UI.dyn_o \r\nWARNING: file compiler/specialise/Specialise.hs, line 1173\r\n Missed specialisation opportunity for $fMonadIOExceptT_$cliftIO\r\n [] 2 [] 1 [ALWAYS]\r\nWARNING: file compiler/specialise/Specialise.hs, line 1173\r\n Missed specialisation opportunity for $w$c<*>\r\n [] 2 [] 1 [0]\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160218 for x86_64-unknown-linux):\r\n\tASSERT failed!\r\n file compiler/types/TyCoRep.hs line 1939\r\n in_scope InScope {fromTarget_aiKD pprTT_aj4s pp_resume_aj4J\r\n opts_ajdx flagList_ajdy $dMonad_anX0 $dOrd_areH $dEq_as40\r\n $dRead_as5N $dEq_aswW $dMonadIO_at39 $dApplicative_atce $dShow_atnW\r\n $dMonad_ats4 $dFunctor_atsk $dNFData_awOZ $dEq_azf8 $dFunctor_azfb\r\n $dHasGhciState_azfd $dNFData_aAFw $trModule availableCommands\r\n shortHelpText fullHelpText defPrompt defPrompt2 defaultGhciSettings\r\n ghciWelcomeMsg ghciCommands word_break_chars specials spaces\r\n flagWordBreakChars keepGoing keepGoing' keepGoingPaths\r\n defShortHelpText defFullHelpText findEditor default_progname\r\n default_prompt default_prompt2 interactiveUI\r\n resetLastErrorLocations withGhcAppData runGHCiInput\r\n checkFileAndDirPerms checkPerms incrementLineNo fileLoop mkPrompt\r\n queryQueue installInteractivePrint runCommands runCommands'\r\n runOneCommand checkInputForLayout enqueueCommands runStmt\r\n afterRunStmt runSuccess runAllocs printTypeOfNames compareNames\r\n printTypeOfName lookupCommand' getCurrentBreakSpan\r\n getCurrentBreakModule noArgs withSandboxOnly help info\r\n filterOutChildren pprInfo doWithArgs changeDirectory trySuccess\r\n chooseEditFile defineMacro getGhciStepIO deferredLoad loadModule\r\n loadModule_ reloadModule doLoadAndCollectInfo afterLoad\r\n setContextAfterLoad setContextKeepingPackageModules\r\n keepPackageImports runExceptGhcMonad exceptT parseSpanArg\r\n showSrcSpan showRealSrcSpan kindOfType isSafeModule browseCmd\r\n guessCurrentModule browseModule addModulesToContext\r\n addModulesToContext_ remModulesFromContext setContext addII\r\n restoreContextOnFailure checkAdd setGHCContextFromGHCiState\r\n mkIIDecl iiModules iiModuleName preludeModuleName\r\n implicitPreludeImport isPreludeImport iiSubsumes showOptions\r\n showDynFlags setArgs setProg setEditor setStop setPrompt setPrompt2\r\n setPrompt_ packageFlagsChanged newDynFlags isMinus isPlus setOpt\r\n unsetOpt strToGHCiOpt showImports showModules getLoadedModules\r\n showBindings showBkptTable showContext pprStopped showPackages\r\n showPaths showLanguages showiLanguages showLanguages'\r\n ghciCompleteWord completeGhciCommand completeIdentifier\r\n completeModule listHomeModules completeSetOptions\r\n completeHomeModuleOrFile wrapCompleter wrapIdentCompleter\r\n completeExpression pprintCommand stepCmd leftmostLargestRealSrcSpan\r\n doContinue bold breakSwitch breakByModuleLine breakSyntax\r\n findBreakAndSet findBreakByCoord do_bold start_bold end_bold\r\n listModuleLine listAround getTickArray discardTickArrays\r\n discardActiveBreakPoints turnOffBreak getModBreak handler\r\n showException ghciHandle tryBool lookupModule lookupModuleName\r\n expandPath expandPathIO wantInterpretedModule\r\n wantInterpretedModuleName wantNameFromInterpretedModule\r\n $tc'GhciSettings $tcGhciSettings $tc'GotCommand $tc'BadCommand\r\n $tc'NoLastCommand $tcMaybeCommand a_sKa7 a_sKa8 a_sKa9 a_sKaa\r\n a_sKag a_sKah a_sKai a_sKaj a_sKdg a_sKrw a_sKvG a_sKvH a_sKvI\r\n a_sKwn a_sKwo a_sKws a_sKwt a_sKxU a_sKxV a_sKy8 a_sKy9 a_sKyg\r\n a_sKyh a_sKyk a_sKyl a_sKyV a_sKAe a_sKAk a_sKAl a_sKAm a_sKAn\r\n a_sKAo a_sKAp a_sKAq a_sKAr a_sKAs a_sKAt a_sKAu a_sKD4 a_sKEx\r\n a_sKEy a_sKEz a_sKEA a_sKEB a_sKEC a_sKF1 a_sKF2 a_sKFj a_sKFk\r\n a_sKFm a_sKFn a_sKMd a_sKMe a_sKMf a_sKMg a_sKMh a_sKOX a_sKQx\r\n a_sKQy a_sKTg a_sKWr a_sKWs a_sKWt a_sLrp a_sLrs a_sLrB a_sLs3\r\n a_sLs5 a_sLsd a_sLsV a_sLtg a_sLtY a_sLv2 a_sLv7 a_sLvB a_sLvF\r\n a_sLvP a_sLvT a_sLwI}\r\n tenv [alhH :-> InputT GHCi, alhI :-> e_alhI]\r\n tenvFVs [alhI :-> e_alhI]\r\n cenv []\r\n cenvFVs []\r\n tys []\r\n cos [forall (a17_aDzt :: <*>_N).\r\n <String>_R\r\n -> Sym (N:ExceptT[0] <e_alhI>_N <m_alhH>_R <a17_aDzt>_N)]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nghc/ghc.mk:112: recipe for target 'ghc/stage2/build/GHCi/UI.dyn_o' failed\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11644Core lint error in result of Specialise for TEST=T3220 WAY=optasm2019-07-07T18:29:19ZThomas MiedemaCore lint error in result of Specialise for TEST=T3220 WAY=optasmThis is the code:
```hs
{-# LANGUAGE TypeFamilies, ScopedTypeVariables#-}
module T3220 where
class Foo m where
type Bar m :: *
action :: m -> Bar m -> m
right x m = action m (Right x)
right' :: (Either a b ~ Bar m, Foo m) =>...This is the code:
```hs
{-# LANGUAGE TypeFamilies, ScopedTypeVariables#-}
module T3220 where
class Foo m where
type Bar m :: *
action :: m -> Bar m -> m
right x m = action m (Right x)
right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m
right' x m = action m (Right x)
instance Foo Int where
type Bar Int = Either Int Int
action m a = either (*) (+) a m
instance Foo Float where
type Bar Float = Either Float Float
action m a = either (*) (+) a m
foo = print $ right (1::Int) (3 :: Int)
bar = print $ right (1::Float) (3 :: Float)
```
Invocation:
```
$ ghc-8.0.1 T3220.hs -O -dcore-lint
```
```
[1 of 1] Compiling T3220 ( T3220.hs, T3220.o )
*** Core Lint errors : in result of Specialise ***
<no location info>: warning:
In the expression: action
@ Float
$fFooFloat
m_ayb
((Right @ Float @ Float x_aya)
`cast` (Sub (Sym cobox_aUe) :: Either a_aU3 b_aU4 ~R# Bar m_aU1))
cobox_aUe :: Bar m_aU1 ~# Either a_aU3 b_aU4
[LclId[CoVarId], Str=DmdType] is out of scope
```
Interestingly, with HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037), it hits an assert from #11371.
```
=====> T3220(profasm) 12 of 21 [0, 11, 0]
cd ./indexed-types/should_compile && "/home/thomas/ghc-validate/inplace/test spaces/ghc-stage2" -c T3220.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -prof -static -auto-all > T3220.comp.stderr 2>&1
Compile failed (status 256) errors were:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160221 for x86_64-unknown-linux):
ASSERT failed!
CallStack (from HasCallStack):
assertPprPanic, called at compiler/types/TyCoRep.hs:1942:51 in ghc:TyCoRep
checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep
substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst
in_scope InScope {x_axS m_axT $caction_a1dp $caction_a1dR right
right' foo bar $tcFoo $tc'C:Foo $fFooFloat $fFooInt $trModule
a_s1fZ a_s1g0 a_s1g1 a_s1g2}
tenv [aTT :-> Float, aTV :-> Float, aTW :-> Float]
cenv []
tys []
cos [Sub (Sym cobox_aU6)]
needInScope [aU6 :-> cobox_aU6]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This is a regression from 7.10.3. Setting priority=highest.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11649LLVM code generator produces mal-formed LLVM blocks2020-01-07T04:30:58ZBen GamariLLVM code generator produces mal-formed LLVM blocksIt appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to comp...It appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to compile with,
```
Entry block to function must not have predecessors!
label %cjGw
/home/ben/ghc/roots/llvm-3.7/bin/opt: libraries/base/GHC/Generics.ll: error: input module is broken!
```
The problematic block in question appears to be,
```
define internal ghccc void @rhSw_info$def(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noal
ias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) align 4 nounwind prefix <{
i32, i32, i32}><{i32 65541, i32 0, i32 15}>
{
clpH:
br label %clpH
}
```
Which arose from this Cmm,
```
==================== Post control-flow optimisations ====================
2016-02-26 10:39:28.656744 UTC
[section ""data" . lvl_rhSw_closure" {
lvl_rhSw_closure:
const lvl_rhSw_info;
},
lvl_rhSw_entry() // []
{ info_tbl: [(clpH,
label: lvl_rhSw_info
rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]
stack_info: arg_space: 0 updfr_space: Nothing
}
{offset
clpH:
goto clpH; // CmmBranch
}
}]
```
Which arose from this input Cmm,
```
==================== Cmm produced by new codegen ====================
2016-02-26 10:39:28.611641 UTC
[section ""data" . lvl_rhSw_closure" {
lvl_rhSw_closure:
const lvl_rhSw_info;
},
lvl_rhSw_entry() // [R2]
{ info_tbl: [(clpD,
label: lvl_rhSw_info
rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]
stack_info: arg_space: 4 updfr_space: Just 4
}
{offset
clpD:
_shWa::P32 = R2; // CmmAssign
goto clpz; // CmmBranch
clpz:
if ((old + 0) - <highSp> < SpLim) goto clpE; else goto clpF; // CmmCondBranch
clpE:
R2 = _shWa::P32; // CmmAssign
R1 = lvl_rhSw_closure; // CmmAssign
call (stg_gc_fun)(R2, R1) args: 4, res: 0, upd: 4; // CmmCall
clpF:
goto clpy; // CmmBranch
clpy:
goto shWb; // CmmBranch
shWb:
goto clpH; // CmmBranch
clpH:
goto shWb; // CmmBranch
}
}]
```
Which arose from this STG,
```hs
lvl_rhSw
:: forall a_a99i.
GHC.Generics.U1 a_a99i -> GHC.Generics.U1 [a_a99i]
[GblId,
Arity=1,
Caf=NoCafRefs,
Str=DmdType <L,U>x,
Unf=OtherCon []] =
sat-only \r [eta_shWa]
let-no-escape {
some_v_shWb [Occ=LoopBreaker] :: GHC.Generics.U1 [a12_a99i]
[LclId, Str=DmdType b] =
NO_CCS[] \u [] some_v_shWb;
} in some_v_shWb;
```
Which arose from this Core (from `-ddump-simpl`),
```hs
lvl_rhSw :: forall a_a99i. U1 a_a99i -> U1 [a_a99i]
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,U>x]
lvl_rhSw =
\ (@ a12_a99i) _ [Occ=Dead] ->
letrec {
some_v_a99l [Occ=LoopBreaker] :: U1 [a12_a99i]
[LclId, Str=DmdType b]
some_v_a99l = some_v_a99l; } in
some_v_a99l
```
Which is apparently the body of the `some` implementation in the `Alternative` instance for `GHC.Generics.U1`.8.0.1erikderikdhttps://gitlab.haskell.org/ghc/ghc/-/issues/11664Core Lint failure when building warp-3.2.22019-07-07T18:29:11Zanton.dessiatovCore Lint failure when building warp-3.2.2When building warp-3.2.2 with `-dcore-lint` the module Network.Wai.Handler.Warp.HTTP2.Worker fails to compile with Core Lint errors.
Steps to reproduce (assuming that you have [Stack](http://haskellstack.org) installed):
1. Download [w...When building warp-3.2.2 with `-dcore-lint` the module Network.Wai.Handler.Warp.HTTP2.Worker fails to compile with Core Lint errors.
Steps to reproduce (assuming that you have [Stack](http://haskellstack.org) installed):
1. Download [warp-3.2.2.tar.gz](https://hackage.haskell.org/package/warp-3.2.2/warp-3.2.2.tar.gz) from Hackage, extract it, and cd to that directory.
1. Run `echo "resolver: lts-5.5" > stack.yaml` and then `stack build --ghc-options -dcore-lint`.
The text with exact error message is attached to this ticket.
<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":"Core Lint failure when building warp-3.2.2","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":"When building warp-3.2.2 with `-dcore-lint` the module Network.Wai.Handler.Warp.HTTP2.Worker fails to compile with Core Lint errors.\r\n\r\nSteps to reproduce (assuming that you have [http://haskellstack.org Stack] installed):\r\n 1. Download [https://hackage.haskell.org/package/warp-3.2.2/warp-3.2.2.tar.gz warp-3.2.2.tar.gz] from Hackage, extract it, and cd to that directory.\r\n 2. Run `echo \"resolver: lts-5.5\" > stack.yaml` and then `stack build --ghc-options -dcore-lint`.\r\n\r\nThe text with exact error message is attached to this ticket.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11665Recent master fails to build attoparsec-0.13.0.1 with core lint failure2019-07-07T18:29:11Zanton.dessiatovRecent master fails to build attoparsec-0.13.0.1 with core lint failureYou might also like to see #11664 for some history.
I have tried using current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 to build current `attoparsec-0.13.0.1` on Ubuntu Linux 15.10 x86_64. The build fails with Core Lint error
...You might also like to see #11664 for some history.
I have tried using current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 to build current `attoparsec-0.13.0.1` on Ubuntu Linux 15.10 x86_64. The build fails with Core Lint error
```
<no location info>: warning:
In the type ‘Buffer
-> Pos -> More -> a_aOwS -> IResult Text r_aOwT’
@ a_aOwS is out of scope
```
Attached comes full output of `cabal install attoparsec --with-ghc=<path-to-ghc> --verbose --ghc-options -dcore-lint`. The output is huge (57k lines) so I gzipped it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Recent master fails to build attoparsec-0.13.0.1 with core lint failure","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You might also like to see #11664 for some history.\r\n\r\nI have tried using current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 to build current `attoparsec-0.13.0.1` on Ubuntu Linux 15.10 x86_64. The build fails with Core Lint error \r\n\r\n{{{\r\n<no location info>: warning:\r\n In the type ‘Buffer\r\n -> Pos -> More -> a_aOwS -> IResult Text r_aOwT’\r\n @ a_aOwS is out of scope\r\n}}}\r\n\r\nAttached comes full output of `cabal install attoparsec --with-ghc=<path-to-ghc> --verbose --ghc-options -dcore-lint`. The output is huge (57k lines) so I gzipped it.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11678runhaskell (and ghc, ghci) fail to run if HOME is not set2019-07-07T18:29:08Zcrosserrunhaskell (and ghc, ghci) fail to run if HOME is not setSteps to reproduce:
```
$ env -i ghc
HOME: getAppUserDataDirectory: does not exist (no environment variable)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
This may be not a big deal for the compile...Steps to reproduce:
```
$ env -i ghc
HOME: getAppUserDataDirectory: does not exist (no environment variable)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
This may be not a big deal for the compiler and repl, but there are use cases to run `runhaskell` without HOME, e.g. I encountered this when running a cgi script under Apache. I think that the problem was introduced after 7.8.
<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":"runhaskell (and ghc, ghci) fail to run if HOME is not set","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":"Steps to reproduce:\r\n\r\n{{{\r\n$ env -i ghc\r\nHOME: getAppUserDataDirectory: does not exist (no environment variable)\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n}}}\r\n\r\nThis may be not a big deal for the compiler and repl, but there are use cases to run `runhaskell` without HOME, e.g. I encountered this when running a cgi script under Apache. I think that the problem was introduced after 7.8.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11681ghc panic with TypeError2019-07-07T18:29:06Zinakighc panic with TypeErrorWhen playing around with `TypeError` I got a ghc panic with the following code:
```hs
{-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators,
FlexibleInstances, UndecidableInstances #-}
import GHC.TypeLits
class C t where
insta...When playing around with `TypeError` I got a ghc panic with the following code:
```hs
{-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators,
FlexibleInstances, UndecidableInstances #-}
import GHC.TypeLits
class C t where
instance
(TypeError (Text "A" :<>: {- Text -} "B"))
=> C t where
main :: IO ()
main = return ()
```
Compiling this results in
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.0.20160204 for x86_64-unknown-linux):
fvProv falls into a hole {a1bh}
```
Commenting "in" the second `Text` removes the panic.
<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 panic with TypeError","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":"When playing around with `TypeError` I got a ghc panic with the following code:\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators,\r\n FlexibleInstances, UndecidableInstances #-}\r\n\r\nimport GHC.TypeLits\r\n\r\nclass C t where\r\n\r\ninstance\r\n (TypeError (Text \"A\" :<>: {- Text -} \"B\"))\r\n => C t where\r\n\r\nmain :: IO ()\r\nmain = return ()\r\n}}}\r\n\r\nCompiling this results in\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.0.20160204 for x86_64-unknown-linux):\r\n\tfvProv falls into a hole {a1bh}\r\n}}}\r\n\r\nCommenting \"in\" the second `Text` removes the panic.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11685undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadRes...2019-07-07T18:29:05Zmartinvlkundefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closureHi, when compiling a program I get this message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc4185_0/libghc_82.so: undefined symbol: Dat...Hi, when compiling a program I get this message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc4185_0/libghc_82.so: undefined symbol: DataziSafeStore_zdszdfApplicativeNoLoggingTzuzdszdfMonadResourceT_closure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The same program compiled fine before, not sure what might be causing it.. happy to provide more info if you tell me what will help.
Martinhttps://gitlab.haskell.org/ghc/ghc/-/issues/11694The function `lift'ghc: panic! (the 'impossible' happened)2019-07-07T18:29:04ZSventimirThe function `lift'ghc: panic! (the 'impossible' happened)The error message I got doesn't even make much sense (or at least I don't understand it). Here it is:
```
src/Splices.hs:22:18:
Couldn't match kind `* -> *' with `*'
Expected type: (a1 -> a1)
-> heist-0.14.1.1...The error message I got doesn't even make much sense (or at least I don't understand it). Here it is:
```
src/Splices.hs:22:18:
Couldn't match kind `* -> *' with `*'
Expected type: (a1 -> a1)
-> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text
Actual type: (a1 -> a1)
-> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text
Kind incompatibility when matching types:
a_t -> a_t :: * -> *
a1 -> a1 :: *
The function `lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-unknown-linux):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
As far as I understand it says that two things of the same type (a -\> a) have different kind...
And the offending function is really simple:
```hs
import Happstack.Server (path)
import Heist.Interpreted (textSplice)
insertFromPath :: Splice m
insertFromPath = lift path id >>= textSplice
```
I believe that `m` should evaluate to `ServerPartT IO` from Happstack.Server module. I append the whole source code.
<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":"The function `lift'ghc: panic! (the 'impossible' happened)","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":"The error message I got doesn't even make much sense (or at least I don't understand it). Here it is:\r\n\r\n{{{\r\nsrc/Splices.hs:22:18:\r\n Couldn't match kind `* -> *' with `*'\r\n Expected type: (a1 -> a1)\r\n -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text\r\n Actual type: (a1 -> a1)\r\n -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text\r\n Kind incompatibility when matching types:\r\n a_t -> a_t :: * -> *\r\n a1 -> a1 :: *\r\n The function `lift'ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.3 for x86_64-unknown-linux):\r\n\tkindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nAs far as I understand it says that two things of the same type (a -> a) have different kind...\r\n\r\nAnd the offending function is really simple:\r\n\r\n{{{#!hs\r\nimport Happstack.Server (path)\r\nimport Heist.Interpreted (textSplice)\r\n\r\n\r\ninsertFromPath :: Splice m\r\ninsertFromPath = lift path id >>= textSplice\r\n}}}\r\n\r\nI believe that `m` should evaluate to `ServerPartT IO` from Happstack.Server module. I append the whole source code.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11711Typechecker assertion failure2019-07-07T18:28:58ZBen GamariTypechecker assertion failureI've seen this program both fail with a typechecker assertion and Core lint violations with various GHC versions,
```hs
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeOperators #-}
{...I've seen this program both fail with a typechecker assertion and Core lint violations with various GHC versions,
```hs
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE TypeInType #-}
module Hi where
import Data.Kind (Type)
data (:~~:) a b where
HRefl :: a :~~: a
data TypeRep (a :: k) where
TrTyCon :: String -> TypeRep k -> TypeRep (a :: k)
TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1).
TypeRep (a :: k1 -> k2)
-> TypeRep (b :: k1)
-> TypeRep (a b)
class Typeable (a :: k) where
typeRep :: TypeRep a
data TypeRepX where
TypeRepX :: forall k (a :: k). TypeRep a -> TypeRepX
eqTypeRep :: TypeRep a -> TypeRep b -> Maybe (a :~~: b)
eqTypeRep = undefined
typeRepKind :: forall k (a :: k). TypeRep a -> TypeRep k
typeRepKind = undefined
funResultTy :: TypeRepX -> TypeRepX -> Maybe TypeRepX
funResultTy (TypeRepX f) (TypeRepX x)
| Just HRefl <- (typeRep :: TypeRep Type) `eqTypeRep` typeRepKind f
, TRFun arg res <- f
, Just HRefl <- arg `eqTypeRep` x
= Just (TypeRepX res)
| otherwise
= Nothing
trArrow :: TypeRep (->)
trArrow = undefined
pattern TRFun :: forall fun. ()
=> forall arg res. (fun ~ (arg -> res))
=> TypeRep arg
-> TypeRep res
-> TypeRep fun
pattern TRFun arg res <- TrApp (TrApp (eqTypeRep trArrow -> Just HRefl) arg) res
```
The most recent type checker error is,
```
$ ~/ghc/ghc-testing/inplace/bin/ghc-stage2 -dcore-lint ~/Hi.hs
[1 of 1] Compiling Hi ( /home/ben/Hi.hs, /home/ben/Hi.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160315 for x86_64-unknown-linux):
tcTyVarDetails cobox_a1Nm :: k_a1N4[ssk] ~# Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1-rc2 |
| 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":"Typechecker assertion failure","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've seen this program both fail with a typechecker assertion and Core lint violations with various GHC versions,\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE ViewPatterns #-}\r\n{-# LANGUAGE TypeInType #-}\r\n\r\nmodule Hi where\r\n\r\nimport Data.Kind (Type)\r\n\r\ndata (:~~:) a b where\r\n HRefl :: a :~~: a\r\n\r\ndata TypeRep (a :: k) where\r\n TrTyCon :: String -> TypeRep k -> TypeRep (a :: k)\r\n TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1).\r\n TypeRep (a :: k1 -> k2)\r\n -> TypeRep (b :: k1)\r\n -> TypeRep (a b)\r\n\r\nclass Typeable (a :: k) where\r\n typeRep :: TypeRep a\r\n\r\ndata TypeRepX where\r\n TypeRepX :: forall k (a :: k). TypeRep a -> TypeRepX\r\n\r\neqTypeRep :: TypeRep a -> TypeRep b -> Maybe (a :~~: b)\r\neqTypeRep = undefined\r\n\r\ntypeRepKind :: forall k (a :: k). TypeRep a -> TypeRep k\r\ntypeRepKind = undefined\r\n\r\nfunResultTy :: TypeRepX -> TypeRepX -> Maybe TypeRepX\r\nfunResultTy (TypeRepX f) (TypeRepX x)\r\n | Just HRefl <- (typeRep :: TypeRep Type) `eqTypeRep` typeRepKind f\r\n , TRFun arg res <- f\r\n , Just HRefl <- arg `eqTypeRep` x\r\n = Just (TypeRepX res)\r\n | otherwise\r\n = Nothing\r\n\r\ntrArrow :: TypeRep (->)\r\ntrArrow = undefined\r\n\r\npattern TRFun :: forall fun. ()\r\n => forall arg res. (fun ~ (arg -> res))\r\n => TypeRep arg\r\n -> TypeRep res\r\n -> TypeRep fun\r\npattern TRFun arg res <- TrApp (TrApp (eqTypeRep trArrow -> Just HRefl) arg) res\r\n}}}\r\n\r\nThe most recent type checker error is,\r\n{{{\r\n$ ~/ghc/ghc-testing/inplace/bin/ghc-stage2 -dcore-lint ~/Hi.hs\r\n[1 of 1] Compiling Hi ( /home/ben/Hi.hs, /home/ben/Hi.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160315 for x86_64-unknown-linux):\r\n tcTyVarDetails cobox_a1Nm :: k_a1N4[ssk] ~# Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11720pureMD5: Simplifier ticks exhausted2019-07-07T18:28:55ZPeter Trommlerptrommler@acm.orgpureMD5: Simplifier ticks exhaustedGHC panics with simplifier ticks exhausted on powerpc, powerpc64, and powerpc64le compiling pureMD5:
```
[ 43s] [1 of 1] Compiling Data.Digest.Pure.MD5 ( Data/Digest/Pure/MD5.hs, dist/build/Data/Digest/Pure/MD5.o )
[...]
[ 46s] ghc...GHC panics with simplifier ticks exhausted on powerpc, powerpc64, and powerpc64le compiling pureMD5:
```
[ 43s] [1 of 1] Compiling Data.Digest.Pure.MD5 ( Data/Digest/Pure/MD5.hs, dist/build/Data/Digest/Pure/MD5.o )
[...]
[ 46s] ghc: panic! (the 'impossible' happened)
[ 46s] (GHC version 8.0.0.20160204 for powerpc64le-unknown-linux):
[ 46s] Simplifier ticks exhausted
[ 46s] When trying UnfoldingDone $
[ 46s] To increase the limit, use -fsimpl-tick-factor=N (default 100)
[ 46s] If you need to do this, let GHC HQ know, and what factor you needed
[ 46s] To see detailed counts use -ddump-simpl-stats
[ 46s] Total ticks: 168807
```
pureMD5 compiles on i586 and x86_64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"pureMD5: Simplifier ticks exhausted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC panics with simplifier ticks exhausted on powerpc, powerpc64, and powerpc64le compiling pureMD5: \r\n{{{\r\n[ 43s] [1 of 1] Compiling Data.Digest.Pure.MD5 ( Data/Digest/Pure/MD5.hs, dist/build/Data/Digest/Pure/MD5.o ) \r\n[...]\r\n[ 46s] ghc: panic! (the 'impossible' happened)\r\n[ 46s] (GHC version 8.0.0.20160204 for powerpc64le-unknown-linux):\r\n[ 46s] \tSimplifier ticks exhausted\r\n[ 46s] When trying UnfoldingDone $\r\n[ 46s] To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n[ 46s] If you need to do this, let GHC HQ know, and what factor you needed\r\n[ 46s] To see detailed counts use -ddump-simpl-stats\r\n[ 46s] Total ticks: 168807\r\n}}}\r\n\r\npureMD5 compiles on i586 and x86_64.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11723TYPE 'UnboxedTupleRep is a lie2019-07-07T18:28:55ZRichard Eisenbergrae@richarde.devTYPE 'UnboxedTupleRep is a lieFrom \@RyanGlScott, [ticket:11471\#comment:117929](https://gitlab.haskell.org//ghc/ghc/issues/11471#note_117929):
I notice that there's a single constructor of `RuntimeRep` for unboxed
tuples (`UnboxedTupleRep`). Does this mean somethin...From \@RyanGlScott, [ticket:11471\#comment:117929](https://gitlab.haskell.org//ghc/ghc/issues/11471#note_117929):
I notice that there's a single constructor of `RuntimeRep` for unboxed
tuples (`UnboxedTupleRep`). Does this mean something like this should be
allowed?
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
module Example where
import Data.Typeable
import GHC.Exts
data Wat (a :: TYPE 'UnboxedTupleRep) = Wat a
```
Currently, that fails to compile due to a separate GHC panic:
```
$ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs
[1 of 1] Compiling Example ( Example.hs, Example.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.1.20160317 for x86_64-unknown-linux):
unboxed tuple PrimRep
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
But wouldn't this be dangerous anyway? After all, unboxed tuples are
supposed to represent arguments on the stack, so couldn't unboxed tuple
polymorphic potentially lead to the RTS miscalculating how much data to
read? Or am I misreading this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"TYPE 'UnboxedTupleRep is a lie","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From @RyanGlScott, comment:28:ticket:11471:\r\n\r\nI notice that there's a single constructor of `RuntimeRep` for unboxed\r\ntuples (`UnboxedTupleRep`). Does this mean something like this should be\r\nallowed?\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE KindSignatures #-}\r\nmodule Example where\r\n\r\nimport Data.Typeable\r\nimport GHC.Exts\r\n\r\ndata Wat (a :: TYPE 'UnboxedTupleRep) = Wat a\r\n}}}\r\n\r\nCurrently, that fails to compile due to a separate GHC panic:\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs\r\n[1 of 1] Compiling Example ( Example.hs, Example.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160317 for x86_64-unknown-linux):\r\n unboxed tuple PrimRep\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nBut wouldn't this be dangerous anyway? After all, unboxed tuples are\r\nsupposed to represent arguments on the stack, so couldn't unboxed tuple\r\npolymorphic potentially lead to the RTS miscalculating how much data to\r\nread? Or am I misreading this?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11724Must check for representation polymorphism in datatype declarations2019-07-07T18:28:54ZRichard Eisenbergrae@richarde.devMust check for representation polymorphism in datatype declarations```hs
data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a
```
panics. It should error instead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...```hs
data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a
```
panics. It should error instead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Must check for representation polymorphism in datatype declarations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\ndata Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a\r\n}}}\r\n\r\npanics. It should error instead.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/11748GHC runtime linker: fatal error: I found a duplicate definition for symbol2019-07-07T18:28:47ZjeieaGHC runtime linker: fatal error: I found a duplicate definition for symbolI found GHC panic when using both inline-c and local Win32 package.
I don't know whether it's related to #6107.
```
D:\ghc-bug-maybe>stack build
Win32a-2.3.1.0: build
Win32a-2.3.1.0: copy/register
ghc-bug-maybe-0.1.0.0: configure
ghc-b...I found GHC panic when using both inline-c and local Win32 package.
I don't know whether it's related to #6107.
```
D:\ghc-bug-maybe>stack build
Win32a-2.3.1.0: build
Win32a-2.3.1.0: copy/register
ghc-bug-maybe-0.1.0.0: configure
ghc-bug-maybe-0.1.0.0: build
Completed 2 action(s).
-- While building package ghc-bug-maybe-0.1.0.0 using:
C:\AppData\Roaming\stack\setup-exe-cache\x86_64-windows\setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\dist\2672c1f3 build lib:ghc-bug-maybe exe:DualternativeH-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: D:\ghc-bug-maybe\.stack-work\logs\ghc-bug-maybe-0.1.0.0.log
Configuring ghc-bug-maybe-0.1.0.0...
Preprocessing library ghc-bug-maybe-0.1.0.0...
[1 of 1] Compiling Lib ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
GHC runtime linker: fatal error: I found a duplicate definition for symbol
rgb
whilst processing object file
D:\ghc-bug-maybe\.stack-work\install\0464eb7a\lib\x86_64-windows-ghc-7.10.3\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-mingw32):
loadObj "D:\\ghc-bug-maybe\\.stack-work\\install\\0464eb7a\\lib\\x86_64-windows-ghc-7.10.3\\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC runtime linker: fatal error: I found a duplicate definition for symbol","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I found GHC panic when using both inline-c and local Win32 package.\r\n\r\nI don't know whether it's related to #6107.\r\n\r\n{{{\r\nD:\\ghc-bug-maybe>stack build\r\nWin32a-2.3.1.0: build\r\nWin32a-2.3.1.0: copy/register\r\nghc-bug-maybe-0.1.0.0: configure\r\nghc-bug-maybe-0.1.0.0: build\r\nCompleted 2 action(s).\r\n\r\n-- While building package ghc-bug-maybe-0.1.0.0 using:\r\n C:\\AppData\\Roaming\\stack\\setup-exe-cache\\x86_64-windows\\setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\\dist\\2672c1f3 build lib:ghc-bug-maybe exe:DualternativeH-exe --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n Logs have been written to: D:\\ghc-bug-maybe\\.stack-work\\logs\\ghc-bug-maybe-0.1.0.0.log\r\n\r\n Configuring ghc-bug-maybe-0.1.0.0...\r\n Preprocessing library ghc-bug-maybe-0.1.0.0...\r\n [1 of 1] Compiling Lib ( src\\Lib.hs, .stack-work\\dist\\2672c1f3\\build\\Lib.o )\r\n GHC runtime linker: fatal error: I found a duplicate definition for symbol\r\n rgb\r\n whilst processing object file\r\n D:\\ghc-bug-maybe\\.stack-work\\install\\0464eb7a\\lib\\x86_64-windows-ghc-7.10.3\\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o\r\n This could be caused by:\r\n * Loading two different object files which export the same symbol\r\n * Specifying the same object file twice on the GHCi command line\r\n * An incorrect `package.conf' entry, causing some object to be\r\n loaded twice.\r\n ghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-unknown-mingw32):\r\n loadObj \"D:\\\\ghc-bug-maybe\\\\.stack-work\\\\install\\\\0464eb7a\\\\lib\\\\x86_64-windows-ghc-7.10.3\\\\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\\\\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o\": failed\r\n\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11753Type hole(?) causes compiler failure2019-07-07T18:28:43ZAlexander KjeldaasType hole(?) causes compiler failureI tried to understand some Servant code, and added
```hs
bodyCheck :: _
```
To the following code
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE FlexibleInstances #-}
{...I tried to understand some Servant code, and added
```hs
bodyCheck :: _
```
To the following code
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeSynonymInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
module Servant.Files ( FilesTmp
, FilesMem
, MultiPartData
, MultiPartDataT
, Tmp
, Mem
) where
import Control.Monad.Trans.Resource
import Data.ByteString.Lazy (ByteString)
import Network.Wai.Parse
import Servant
import Servant.Server.Internal
-- Backends for file upload: in memory or in /tmp ?
data Mem
data Tmp
class KnownBackend b where
type Storage b :: *
withBackend :: Proxy b -> (BackEnd (Storage b) -> IO r) -> IO r
instance KnownBackend Mem where
type Storage Mem = ByteString
withBackend Proxy f = f lbsBackEnd
instance KnownBackend Tmp where
type Storage Tmp = FilePath
withBackend Proxy f = runResourceT . withInternalState $ \s ->
f (tempFileBackEnd s)
-- * Files combinator, to get all of the uploaded files
data Files b
type MultiPartData b = ([Param], [File (Storage b)])
type MultiPartDataT b = ((MultiPartData b -> IO (MultiPartData b)) -> IO (MultiPartData b))
type FilesMem = Files Mem
type FilesTmp = Files Tmp
instance (KnownBackend b,
HasServer sublayout config) => HasServer (Files b :> sublayout) config where
type ServerT (Files b :> sublayout) m =
MultiPartDataT b -> ServerT sublayout m
route Proxy config subserver = WithRequest $ \request ->
route (Proxy :: Proxy sublayout) config (addBodyCheck subserver (bodyCheck request))
where
bodyCheck :: _
bodyCheck request = return $ Route (\f ->
withBackend (Proxy :: Proxy b) $ \pb -> parseRequestBody pb request >>= f
)
```
Output:
```
> :load src/Servant/Test.hs
[1 of 1] Compiling Servant.Files ( src/Servant/Test.hs, interpreted )
src/Servant/Test.hs:59:59:
Couldn't match type ‘r’ with ‘([Param], [File (Storage b)])’
because type variable ‘b’ would escape its scope
This (rigid, skolem) type variable is bound by
the instance declaration
at src/Servant/Test.hs:(53,10)-(54,80)
Expected type: Delayed
(((([Param], [File (Storage b)]) -> IO r) -> IO r)
-> Server sublayout)
Actual type: Delayed (Server (Files b :> sublayout))
Relevant bindings include
bodyCheck :: Network.Wai.Internal.Request
-> m (RouteResult
((([Param], [File (Storage b)]) -> IO r) -> IO r))
(bound at src/Servant/Test.hs:62:7)
subserver :: Delayed (Server (Files b :> sublayout))
(bound at src/Servant/Test.hs:58:22)
route :: Proxy (Files b :> sublayout)
-> Context config
-> Delayed (Server (Files b :> sublayout))
-> Router
(bound at src/Servant/Test.hs:58:3)
In the first argument of ‘addBodyCheck’, namely ‘subserver’
In the third argument of ‘route’, namely
‘(addBodyCheck subserver (bodyCheck request))’
src/Servant/Test.hs:59:70:
Couldn't match type ‘m’ with ‘IO’
‘m’ is untouchable
inside the constraints (KnownBackend b, HasServer sublayout config)
bound by the instance declaration
at src/Servant/Test.hs:(53,10)-(54,80)ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
No skolem info: m_a5An[sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/11755Seed unsafeGlobalDynFlags with enough information to use ppr2019-07-07T18:28:41ZBen GamariSeed unsafeGlobalDynFlags with enough information to use pprAt the moment the pretty-printer isn't functional if used before `DynFlags` is initialized by `initGhcMonad`. In particular things like `pprPanic` aren't usable since `unsafeGlobalDynFlags` isn't yet initialized. This is quite annoying d...At the moment the pretty-printer isn't functional if used before `DynFlags` is initialized by `initGhcMonad`. In particular things like `pprPanic` aren't usable since `unsafeGlobalDynFlags` isn't yet initialized. This is quite annoying during development.
It seems like it should be possible to seed `unsafeGlobalDynFlags` with some minimal `DynFlags`, presumably with rather verbose output (as this is presumably what you want when debugging a compiler crash early in startup).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Seed unsafeGlobalDynFlags with enough information to use ppr","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"At the moment the pretty-printer isn't functional if used before `DynFlags` is initialized by `initGhcMonad`. In particular things like `pprPanic` aren't usable since `unsafeGlobalDynFlags` isn't yet initialized. This is quite annoying during development.\r\n\r\nIt seems like it should be possible to seed `unsafeGlobalDynFlags` with some minimal `DynFlags`, presumably with rather verbose output (as this is presumably what you want when debugging a compiler crash early in startup).","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11784panic "hscCmmFile: no_mod" with `-v2 and above2019-07-07T18:28:33Zerikdpanic "hscCmmFile: no_mod" with `-v2 and aboveInitailly found this on powerpc when debugging #11773, but it also happens on x86_64. The command line:
```
inplace/bin/ghc-stage1 -static -H64m -O0 -Wall -v2 -Iincludes \
-Iincludes/dist -Iincludes/dist-derivedconstants/header \
...Initailly found this on powerpc when debugging #11773, but it also happens on x86_64. The command line:
```
inplace/bin/ghc-stage1 -static -H64m -O0 -Wall -v2 -Iincludes \
-Iincludes/dist -Iincludes/dist-derivedconstants/header \
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \
-DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts \
-irts/dist/build -irts/dist/build/autogen -Irts/dist/build \
-Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances -c\
rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
```
panics with a message:
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.1.20160402 for powerpc-unknown-linux):
hscCmmFile: no_mod
```
The only thing that was added to the command line that is different from the normal build command is the `-v2`.
This is caused by the code (in compiler/main/HscMain.hs):
```
no_mod = panic "hscCmmFile: no_mod"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"panic \"hscCmmFile: no_mod\" with `-v2 and above","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Initailly found this on powerpc when debugging #11773, but it also happens on x86_64. The command line:\r\n\r\n{{{\r\ninplace/bin/ghc-stage1 -static -H64m -O0 -Wall -v2 -Iincludes \\\r\n -Iincludes/dist -Iincludes/dist-derivedconstants/header \\\r\n -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \\\r\n -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts \\\r\n -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \\\r\n -Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances -c\\\r\n rts/StgStartup.cmm -o rts/dist/build/StgStartup.o\r\n}}}\r\n\r\npanics with a message:\r\n\r\n{{{\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160402 for powerpc-unknown-linux):\r\n hscCmmFile: no_mod\r\n}}}\r\n\r\nThe only thing that was added to the command line that is different from the normal build command is the `-v2`.\r\n\r\nThis is caused by the code (in compiler/main/HscMain.hs):\r\n\r\n{{{\r\n no_mod = panic \"hscCmmFile: no_mod\"\r\n}}}\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/11824GHC error in desugarer lookup2019-07-07T18:28:23ZdarchonGHC error in desugarer lookupIn GHC8-rc3, I'm getting:
```
GHC error in desugarer lookup in CLaSH.Core.TyCon:
Can't find interface-file declaration for variable $tcType
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -dd...In GHC8-rc3, I'm getting:
```
GHC error in desugarer lookup in CLaSH.Core.TyCon:
Can't find interface-file declaration for variable $tcType
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.0.20160411 for x86_64-unknown-linux):
initDs IOEnv failure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
To reproduce (requires stack):
- git clone -b ghc8 https://github.com/clash-lang/clash-compiler.git
- cd clash-compiler
- git submodule update --init
- stack --stack-yaml=stack-ghc8.yaml build
The -ddump-if-trace of CLaSH.Core.TyCon can be found here: https://gist.github.com/christiaanb/1cd84e9941f6614321719e298cc12af0
I'm terribly sorry that the current instructions for reproducing the bug are to build my project and all its dependencies. I'm having a lot of trouble reducing the bug to a sensible/small test case, so any hints as to what might be the cause of this bug would be helpful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc3 |
| 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 error in desugarer lookup","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In GHC8-rc3, I'm getting:\r\n\r\n{{{\r\n GHC error in desugarer lookup in CLaSH.Core.TyCon:\r\n Can't find interface-file declaration for variable $tcType\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.0.20160411 for x86_64-unknown-linux):\r\n initDs IOEnv failure\r\n \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nTo reproduce (requires stack):\r\n\r\n* git clone -b ghc8 https://github.com/clash-lang/clash-compiler.git\r\n* cd clash-compiler\r\n* git submodule update --init\r\n* stack --stack-yaml=stack-ghc8.yaml build\r\n\r\nThe -ddump-if-trace of CLaSH.Core.TyCon can be found here: https://gist.github.com/christiaanb/1cd84e9941f6614321719e298cc12af0\r\n\r\nI'm terribly sorry that the current instructions for reproducing the bug are to build my project and all its dependencies. I'm having a lot of trouble reducing the bug to a sensible/small test case, so any hints as to what might be the cause of this bug would be helpful.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11973Simplifier ticks exhausted with complex list literal.2019-07-07T18:28:11ZLokathorSimplifier ticks exhausted with complex list literal.So I had a working version of a module that was too slow:
https://github.com/Lokathor/ludolib/blob/6e69f87762c88d7909ca259ffe69141ea4b707c0/src/Util/AutomataGen.hs\#L167
and then I tried to rearrange things so that the checking could sh...So I had a working version of a module that was too slow:
https://github.com/Lokathor/ludolib/blob/6e69f87762c88d7909ca259ffe69141ea4b707c0/src/Util/AutomataGen.hs\#L167
and then I tried to rearrange things so that the checking could short-circuit a bit and run faster. I came up with this:
https://gist.github.com/Lokathor/d1e4a8cd6268835a2403423fb180a71d\#file-automatagencrashesghc-hs-L172
Which loads and runs just fine in GHCi, but then when I go to compile it into a binary for benchmarking I got the following:
```
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone a_siVC
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 294802
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Setting the factor up to 1k caused it to crash out with the same problem. Setting the factor up to 10k caused GHC to just eat up nearly all of my RAM (11GB) and then stall out until I killed it a few minutes later.
I tried not using -O2 during compilation, but it had the same problem anyway. With some IRC help, it was suggested to add the `-fsimple-list-literals` flag, which makes things compile and run just fine (and with the speed gain that I'd hoped for).
So things work now, for some definition of "work", though I was advised to report this bad behavior anyway.
<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":"Simplifier ticks exhausted with complex list literal.","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":"So I had a working version of a module that was too slow: \r\nhttps://github.com/Lokathor/ludolib/blob/6e69f87762c88d7909ca259ffe69141ea4b707c0/src/Util/AutomataGen.hs#L167\r\n\r\nand then I tried to rearrange things so that the checking could short-circuit a bit and run faster. I came up with this:\r\nhttps://gist.github.com/Lokathor/d1e4a8cd6268835a2403423fb180a71d#file-automatagencrashesghc-hs-L172\r\n\r\nWhich loads and runs just fine in GHCi, but then when I go to compile it into a binary for benchmarking I got the following:\r\n{{{\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-unknown-mingw32):\r\n Simplifier ticks exhausted\r\n When trying UnfoldingDone a_siVC\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 294802\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nSetting the factor up to 1k caused it to crash out with the same problem. Setting the factor up to 10k caused GHC to just eat up nearly all of my RAM (11GB) and then stall out until I killed it a few minutes later.\r\n\r\nI tried not using -O2 during compilation, but it had the same problem anyway. With some IRC help, it was suggested to add the `-fsimple-list-literals` flag, which makes things compile and run just fine (and with the speed gain that I'd hoped for).\r\n\r\nSo things work now, for some definition of \"work\", though I was advised to report this bad behavior anyway.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12026Pattern match failure in RnNames.hs2019-07-07T18:27:56ZdaveanPattern match failure in RnNames.hsWhen compiling dimensional-1.0.1.1 after patching numtype-dk with the patch at https://github.com/bjornbm/numtype-dk/issues/12 GHC does the "impossible":
```
[ 3 of 16] Compiling Numeric.Units.Dimensional.Dimensions.TypeLevel ( src/Nume...When compiling dimensional-1.0.1.1 after patching numtype-dk with the patch at https://github.com/bjornbm/numtype-dk/issues/12 GHC does the "impossible":
```
[ 3 of 16] Compiling Numeric.Units.Dimensional.Dimensions.TypeLevel ( src/Numeric/Units/Dimensional/Dimensions/TypeLevel.hs, dist/dist-sandbox-68389a1a/build/Numeric/Units/Dimensional/Dimensions/TypeLevel.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.0.20160421 for x86_64-unknown-linux):
Pattern match failure in do expression at compiler/rename/RnNames.hs:902:12-50
```8.0.2Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/12055Typechecker panic instead of proper error2019-07-07T18:27:49ZBen GamariTypechecker panic instead of proper errorConsider this modification of the testcase from #12021,
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGU...Consider this modification of the testcase from #12021,
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE TypeInType #-}
import GHC.Base ( Constraint, Type )
import GHC.Exts ( type (~~) )
type Cat k = k -> k -> Type
class Category (p :: Cat k) where
type Ob p :: k -> Constraint
class (Category (Dom f), Category (Cod f)) => Functor (f :: j -> k) where
type Dom f :: Cat j
type Cod f :: Cat k
functor :: forall a b.
Iso Constraint (:-) (:-)
(Ob (Dom f) a) (Ob (Dom f) b)
(Ob (Cod f) (f a)) (Ob (Cod f) (f b))
class (Functor f , Dom f ~ p, Cod f ~ q) =>
Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) | f -> p q
instance (Functor f , Dom f ~ p, Cod f ~ q) =>
Fun (p :: Cat j) (q :: Cat k) (f :: j -> k)
data Nat (p :: Cat j) (q :: Cat k) (f :: j -> k) (g :: j -> k)
type Iso k (c :: Cat k) (d :: Cat k) s t a b =
forall p. (Cod p ~~ Nat d (->)) => p a b -> p s t
data (p :: Constraint) :- (q :: Constraint)
```
With GHC 8.0.1 it fails with a compiler panic,
```
$ ghc Hi.hs -fprint-explicit-kinds
[1 of 1] Compiling Main ( Hi.hs, Hi.o )
Hi.hs:21:1: error:
• Non type-variable argument
in the constraint: Category j (Dom k j f)
(Use FlexibleContexts to permit this)
• In the context: (Category j (Dom k j f), Category k (Cod k j f))
While checking the super-classes of class ‘Functor’
In the class declaration for ‘Functor’
Hi.hs:29:20: error:
• GHC internal error: ‘Dom’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a2yi :-> Type variable ‘j’ = j,
a2yj :-> Type variable ‘p’ = p, a2yk :-> Type variable ‘k’ = k,
a2yl :-> Type variable ‘q’ = q, a2ym :-> Type variable ‘f’ = f,
r2xT :-> ATcTyCon Fun]
• In the first argument of ‘~’, namely ‘Dom f’
In the class declaration for ‘Fun’
```
If one adds the appropriate extensions (`FunctionalDependencies`, `FlexibleInstances`, and `FlexibleContexts`) GHC complains that the program fails to satisfy the coverage condition,
```
Hi.hs:31:10: error:
• Illegal instance declaration for ‘Fun k j p q f’
The coverage condition fails in class ‘Fun’
for functional dependency: ‘f -> p q’
Reason: lhs type ‘f’ does not determine rhs types ‘p’, ‘q’
Un-determined variables: p, q
Using UndecidableInstances might help
• In the instance declaration for
‘Fun (p :: Cat j) (q :: Cat k) (f :: j -> k)’
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12066Symbol not found: _stg_ap_0_upd_info2019-07-07T18:27:47ZpikajudeSymbol not found: _stg_ap_0_upd_infoWhen compiling a project for which `double-conversion` is a dependency:
```
[ 1 of 12] Compiling Models.TH ( src/Models/TH.hs, dist/build/Models/TH.o )
<command line>: can't load .so/.DLL for: /nix/store/m8whp07czawywfis99bfqpjmf...When compiling a project for which `double-conversion` is a dependency:
```
[ 1 of 12] Compiling Models.TH ( src/Models/TH.hs, dist/build/Models/TH.o )
<command line>: can't load .so/.DLL for: /nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib (dlopen(/nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib, 5): Symbol not found: _stg_ap_0_upd_info
Referenced from: /nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib
Expected in: flat namespace
in /nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib)
```8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12072GHC panic on type wildcard in left-hand side of data family2019-07-07T18:27:46ZAndreas HerrmannGHC panic on type wildcard in left-hand side of data familyWhile playing around with data families I received the following output by ghc/ghci:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
rnHsTyKi HsWildcardTy
Please report this as a GHC...While playing around with data families I received the following output by ghc/ghci:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
rnHsTyKi HsWildcardTy
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I had accidentally left a wildcard `_` on the left-hand side of a data instance definition.
To reproduce enter the following code into a file and try to load that file into ghci, or try to compile it with ghc:
```hs
data family Bug x
data instance Bug _ = Bug
```
The expected behavior would be a (non-panic) error message of some sort.
<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 panic on type wildcard in left-hand side of data family","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":"While playing around with data families I received the following output by ghc/ghci:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-unknown-linux):\r\n rnHsTyKi HsWildcardTy\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI had accidentally left a wildcard `_` on the left-hand side of a data instance definition. \r\n\r\nTo reproduce enter the following code into a file and try to load that file into ghci, or try to compile it with ghc:\r\n\r\n{{{#!hs\r\ndata family Bug x\r\ndata instance Bug _ = Bug\r\n}}}\r\n\r\nThe expected behavior would be a (non-panic) error message of some sort.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12081TypeInType Compile-time Panic2020-09-19T19:52:25ZMichaelKTypeInType Compile-time PanicI've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code:
```hs
{-# LANGUAGE TypeInType #-}
data Nat = Z | S Nat
class C (n :: Nat) where
type T n :: Nat
f :: (a :: T n)
```
```
...I've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code:
```hs
{-# LANGUAGE TypeInType #-}
data Nat = Z | S Nat
class C (n :: Nat) where
type T n :: Nat
f :: (a :: T n)
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.0.20160421 for x86_64-apple-darwin):
isInjectiveTyCon sees a TcTyCon T
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc4 |
| 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":"TypeInType Compile-time Panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeInType #-}\r\n\r\ndata Nat = Z | S Nat\r\n\r\nclass C (n :: Nat) where\r\n type T n :: Nat\r\n f :: (a :: T n)\r\n}}}\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.0.20160421 for x86_64-apple-darwin):\r\n\tisInjectiveTyCon sees a TcTyCon T\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12083ghc-8.0.1-rc4: tyConRoles sees a TcTyCon2019-07-07T18:27:43ZSerge Kosyrevghc-8.0.1-rc4: tyConRoles sees a TcTyCon```hs
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UnicodeSyntax #-}
type Constrd a = Num a ⇒ a
data ADT a = ADT (Constrd a) ExistentiallyLost
data ExistentiallyLost = ∀ u. TC u ⇒ ExistentiallyLost u
class u ~ (ATF1 u, ATF2 u) ⇒ TC u w...```hs
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UnicodeSyntax #-}
type Constrd a = Num a ⇒ a
data ADT a = ADT (Constrd a) ExistentiallyLost
data ExistentiallyLost = ∀ u. TC u ⇒ ExistentiallyLost u
class u ~ (ATF1 u, ATF2 u) ⇒ TC u where
type ATF1 u ∷ *
type ATF2 u ∷ *
uie_handlers ∷ ADT Int
-- Loop:
-- - ADT depends on ExistentiallyLost (also the Constrd appendage)
-- - ExistentiallyLost depends on TC
-- - TC depends on ADT
```
--\>
```
[1 of 1] Compiling Main ( /home/deepfire/src/ghc-testcases/tyconroles-sees-a-tctycon-tyalias.hs, interpreted )
<- ghc: panic! (the 'impossible' happened)
(GHC version 8.0.0.20160421 for x86_64-unknown-linux):
tyConRoles sees a TcTyCon Constrd
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12104Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell in...2019-07-07T18:27:38ZantalszType families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole"If I create a type family – open or closed – with a case that evaluates to a `TypeError`, and define a top-level binding with this type, loading the file with `-fdefer-type-errors` enabled (or via `:load!`/`:reload!`) panics GHC with "op...If I create a type family – open or closed – with a case that evaluates to a `TypeError`, and define a top-level binding with this type, loading the file with `-fdefer-type-errors` enabled (or via `:load!`/`:reload!`) panics GHC with "opt_univ fell into a hole". (And if I used `:load!` or `:reload!`, `-fdefer-type-errors` doesn't get unset.)
A minimal example:
```hs
{-# LANGUAGE TypeFamilies, DataKinds, UndecidableInstances #-}
module T12104 where
import GHC.TypeLits
type family F a where
F a = TypeError (Text "error")
err :: F ()
err = ()
```
results in the panic
```
….hs:9:7: warning: [-Wdeferred-type-errors]
• error
• In the expression: ()
In an equation for ‘err’: err = ()
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-apple-darwin):
opt_univ fell into a hole {a4Va}
```
Adding more cases to the type family, or making it open, still cause the crash. This holds whether the error case is a final catch-all case, or something more like
```hs
type family F a where
F () = TypeError (Text "error")
F a = ()
```
Just using a type synonym for `F` doesn't cause a panic, however, and nor does giving `err` the type `TypeError (Text "error")` directly.8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12130ghc: panic! (the 'impossible' happened): find_tycon Block []2019-07-07T18:27:32Zjeieaghc: panic! (the 'impossible' happened): find_tycon Block []I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to `$(widgetFile ...)` yesod template haskell clause.
It was same on linux and windows, and when ...I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to `$(widgetFile ...)` yesod template haskell clause.
It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell).
```
~/yt> stack build
...
yt-0.0.0: configure
Configuring yt-0.0.0...
yt-0.0.0: build
Preprocessing library yt-0.0.0...
[1 of 9] Compiling Settings ( Settings.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o )
[2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o )
[3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o )
[4 of 9] Compiling Foundation ( Foundation.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o )
[5 of 9] Compiling Import ( Import.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o )
[6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o )
[7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Block
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Completed 179 action(s).
-- While building package yt-0.0.0 using:
/home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --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 | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! (the 'impossible' happened): find_tycon Block []","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":"I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to {{{$(widgetFile ...)}}} yesod template haskell clause.\r\n\r\nIt was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell).\r\n\r\n{{{\r\n~/yt> stack build\r\n...\r\nyt-0.0.0: configure\r\nConfiguring yt-0.0.0...\r\nyt-0.0.0: build\r\nPreprocessing library yt-0.0.0...\r\n[1 of 9] Compiling Settings ( Settings.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o )\r\n[2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o )\r\n[3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o )\r\n[4 of 9] Compiling Foundation ( Foundation.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o )\r\n[5 of 9] Compiling Import ( Import.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o )\r\n[6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o )\r\n[7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n find_tycon\r\n Block\r\n []\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nCompleted 179 action(s).\r\n\r\n-- While building package yt-0.0.0 using:\r\n /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/12144GHC panic when using DeriveAnyClass with functor-like class and datatype with...2019-07-07T18:27:29ZRyan ScottGHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant positionThe following code
```hs
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE KindSignatures #-}
module Example where
class C (a :: * -> *)
data T a = MkT (a -> Int) deriving C
```
fails to compile with the following GHC panic:
```
$ /opt/gh...The following code
```hs
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE KindSignatures #-}
module Example where
class C (a :: * -> *)
data T a = MkT (a -> Int) deriving C
```
fails to compile with the following GHC panic:
```
$ /opt/ghc/8.0.1/bin/ghc Example.hs
[1 of 1] Compiling Example ( Example.hs, Example.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
contravariant
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The culprit is that when `DeriveAnyClass` comes up with the constraints for typeclass instances whose argument is of kind `* -> *`, it calls [deepSubtypesContaining](http://git.haskell.org/ghc.git/blob/0676e68cf5fe8696f1f760fef0f35dba14db1104:/compiler/typecheck/TcGenDeriv.hs#l1665), which immediately bails out when it sees a type variable in a contravariant or "bad" position. I'm less sure of what the fix should be.
<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":"GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["Generics"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE KindSignatures #-}\r\nmodule Example where\r\n\r\nclass C (a :: * -> *)\r\ndata T a = MkT (a -> Int) deriving C\r\n}}}\r\n\r\nfails to compile with the following GHC panic:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Example.hs\r\n[1 of 1] Compiling Example ( Example.hs, Example.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tcontravariant\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe culprit is that when `DeriveAnyClass` comes up with the constraints for typeclass instances whose argument is of kind `* -> *`, it calls [http://git.haskell.org/ghc.git/blob/0676e68cf5fe8696f1f760fef0f35dba14db1104:/compiler/typecheck/TcGenDeriv.hs#l1665 deepSubtypesContaining], which immediately bails out when it sees a type variable in a contravariant or \"bad\" position. I'm less sure of what the fix should be.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12145GHC 8.0.1 compilier panic - find_tycon2019-07-07T18:27:28ZhighflyGHC 8.0.1 compilier panic - find_tycon```
angie-0.0.0: configure
Configuring angie-0.0.0...
angie-0.0.0: build
Preprocessing library angie-0.0.0...
[ 8 of 11] Compiling Handler.Home ( Handler/Home.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o )
gh...```
angie-0.0.0: configure
Configuring angie-0.0.0...
angie-0.0.0: build
Preprocessing library angie-0.0.0...
[ 8 of 11] Compiling Handler.Home ( Handler/Home.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Block
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building package angie-0.0.0 using:
/home/haiwei/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:angie exe:angie --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
```https://gitlab.haskell.org/ghc/ghc/-/issues/12212GHC 8.0.1 crash2019-07-07T18:27:08ZdibblegoGHC 8.0.1 crashAttempting to install the geodetics package results in a GHC 8.0.1 crash.
```
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1
% uname -a
Linux moron 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016...Attempting to install the geodetics package results in a GHC 8.0.1 crash.
```
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1
% uname -a
Linux moron 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux
% cabal install geodetics-0.0.4
...omitted
[2 of 9] Compiling Geodetics.Ellipsoids ( src/Geodetics/Ellipsoids.hs, dist/dist-sandbox-49e45c7e/build/Geodetics/Ellipsoids.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
Template variable unbound in rewrite rule
Variable: cobox_scSX
Rule "SPEC t @ a @ 'DQuantity @ 'DQuantity @ d @ d' @ 'DQuantity @ 'DQuantity @ d @ d' @ 'DQuantity @ 'DQuantity @ d @ d'"
Rule bndrs: [cobox_scSX, cobox_scSY, cobox_scSZ, cobox_scT0,
cobox_scT1, $dKnownVariant_scT2, $dKnownVariant_scT3,
$dKnownVariant_scT4, $dKnownVariant_scT5, $dKnownVariant_scT6,
$dKnownVariant_scT7, $dNum_scT8]
LHS args: [TYPE: a_ac0a, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, CO: <d_ac0b * d'_ac0c>_N,
CO: cobox_scSY, CO: <d_ac0b * d'_ac0c>_N, CO: cobox_scT0,
CO: cobox_scT1, $dKnownVariant_scT2, $dKnownVariant_scT3,
$dKnownVariant_scT4, $dKnownVariant_scT5, $dKnownVariant_scT6,
$dKnownVariant_scT7, $dNum_scT8]
Actual args: [TYPE: a_ac0a, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,
TYPE: d_ac0b, TYPE: d'_ac0c, CO: <d_ac0b * d'_ac0c>_N,
CO: D:R:*[1], CO: <d_ac0b * d'_ac0c>_N, CO: D:R:*[1], CO: D:R:*[1],
$fKnownVariantDQuantity, $fKnownVariantDQuantity,
$fKnownVariantDQuantity, $fKnownVariantDQuantity,
$fKnownVariantDQuantity, $fKnownVariantDQuantity, $dNum_acqm,
tx_aaQW, v_aaQZ]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
geodetics-0.0.4 failed during the building phase. The exception was:
ExitFailure 1
```
Similarity to #10602 and #9160 has been pointed out. I also tried:
```
% cabal --ghc-options="-O2" install geodetics-0.0.4
```
with no difference in the crash outcome.
<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":"GHC 8.0.1 crash","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":"Attempting to install the geodetics package results in a GHC 8.0.1 crash.\r\n\r\n{{{\r\n% ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.1\r\n% uname -a\r\nLinux moron 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux\r\n% cabal install geodetics-0.0.4\r\n...omitted\r\n[2 of 9] Compiling Geodetics.Ellipsoids ( src/Geodetics/Ellipsoids.hs, dist/dist-sandbox-49e45c7e/build/Geodetics/Ellipsoids.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n Template variable unbound in rewrite rule\r\n Variable: cobox_scSX\r\n Rule \"SPEC t @ a @ 'DQuantity @ 'DQuantity @ d @ d' @ 'DQuantity @ 'DQuantity @ d @ d' @ 'DQuantity @ 'DQuantity @ d @ d'\"\r\n Rule bndrs: [cobox_scSX, cobox_scSY, cobox_scSZ, cobox_scT0,\r\n cobox_scT1, $dKnownVariant_scT2, $dKnownVariant_scT3,\r\n $dKnownVariant_scT4, $dKnownVariant_scT5, $dKnownVariant_scT6,\r\n $dKnownVariant_scT7, $dNum_scT8]\r\n LHS args: [TYPE: a_ac0a, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, CO: <d_ac0b * d'_ac0c>_N,\r\n CO: cobox_scSY, CO: <d_ac0b * d'_ac0c>_N, CO: cobox_scT0,\r\n CO: cobox_scT1, $dKnownVariant_scT2, $dKnownVariant_scT3,\r\n $dKnownVariant_scT4, $dKnownVariant_scT5, $dKnownVariant_scT6,\r\n $dKnownVariant_scT7, $dNum_scT8]\r\n Actual args: [TYPE: a_ac0a, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, TYPE: 'DQuantity, TYPE: 'DQuantity,\r\n TYPE: d_ac0b, TYPE: d'_ac0c, CO: <d_ac0b * d'_ac0c>_N,\r\n CO: D:R:*[1], CO: <d_ac0b * d'_ac0c>_N, CO: D:R:*[1], CO: D:R:*[1],\r\n $fKnownVariantDQuantity, $fKnownVariantDQuantity,\r\n $fKnownVariantDQuantity, $fKnownVariantDQuantity,\r\n $fKnownVariantDQuantity, $fKnownVariantDQuantity, $dNum_acqm,\r\n tx_aaQW, v_aaQZ]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Error: some packages failed to install:\r\ngeodetics-0.0.4 failed during the building phase. The exception was:\r\nExitFailure 1\r\n}}}\r\n\r\nSimilarity to #10602 and #9160 has been pointed out. I also tried:\r\n\r\n{{{\r\n% cabal --ghc-options=\"-O2\" install geodetics-0.0.4\r\n}}}\r\n\r\nwith no difference in the crash outcome.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12216GHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.12019-07-07T18:27:07ZcgoGHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.1This just happened on macOS 10.11.5:
```
Configuring JuicyPixels-repa-0.7.1.0...
Building JuicyPixels-repa-0.7.1.0...
Preprocessing library JuicyPixels-repa-0.7.1.0...
[1 of 1] Compiling Codec.Picture.Repa ( Codec/Picture/Repa.hs, dist/...This just happened on macOS 10.11.5:
```
Configuring JuicyPixels-repa-0.7.1.0...
Building JuicyPixels-repa-0.7.1.0...
Preprocessing library JuicyPixels-repa-0.7.1.0...
[1 of 1] Compiling Codec.Picture.Repa ( Codec/Picture/Repa.hs, dist/dist-sandbox-94652cd7/build/Codec/Picture/Repa.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-apple-darwin):
filterImports/combine
(Array,
Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor},
Nothing)
(Array,
Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex},
Nothing)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
cabal: Leaving directory '/var/folders/lj/5d92khf937120qgs9xccbn400000gn/T/cabal-tmp-24887/JuicyPixels-repa-0.7.1.0'
Updating documentation indexhttps://gitlab.haskell.org/ghc/ghc/-/issues/12222ghc panic kindFunResult with template haskell 'isInstance'2019-07-07T18:27:06Zghornghc panic kindFunResult with template haskell 'isInstance'```hs
--TH.hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE TemplateHaskell #-}
module TH
( SomeClass
, doThStuff
) where
import Control.Monad ( void )
import Language.Haskell.TH
class SomeClass a where
doThStuff :: Na...```hs
--TH.hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE TemplateHaskell #-}
module TH
( SomeClass
, doThStuff
) where
import Control.Monad ( void )
import Language.Haskell.TH
class SomeClass a where
doThStuff :: Name -> Q [Dec]
doThStuff name = reify name >>= go
go :: Info -> Q [Dec]
go (TyConI (DataD [] _ _ [(NormalC _ [(_,typ)])] _)) = do
void (isInstance ''SomeClass [typ]) -- THIS LINE CRASHES GHC
return []
go _ = fail "wrong info"
```
```hs
-- Bug.hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug
( Bar(..)
) where
import TH
data Foo a = Foo a
instance SomeClass (Foo a)
data Bar f = Bar (Foo (f Int))
doThStuff ''Bar
```
I get this error:
```
$ runghc -ddump-splices Bug.hs
Bug.hs:1:1:
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
kindFunResult
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Code: doThStuff ''Bar
```
If I comment out either `instance SomeClass (Foo a)` or `void (isInstance ''SomeClass [typ])`, the crash does not occur.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic kindFunResult with template haskell 'isInstance'","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["kindFunResult"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n--TH.hs\r\n\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule TH\r\n ( SomeClass\r\n , doThStuff\r\n ) where\r\n\r\nimport Control.Monad ( void )\r\nimport Language.Haskell.TH\r\n\r\nclass SomeClass a where\r\n\r\ndoThStuff :: Name -> Q [Dec]\r\ndoThStuff name = reify name >>= go\r\n\r\ngo :: Info -> Q [Dec]\r\ngo (TyConI (DataD [] _ _ [(NormalC _ [(_,typ)])] _)) = do\r\n void (isInstance ''SomeClass [typ]) -- THIS LINE CRASHES GHC\r\n return []\r\ngo _ = fail \"wrong info\"\r\n}}}\r\n\r\n{{{#!hs\r\n-- Bug.hs\r\n\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule Bug\r\n ( Bar(..)\r\n ) where\r\n\r\nimport TH\r\n\r\ndata Foo a = Foo a\r\ninstance SomeClass (Foo a)\r\n\r\ndata Bar f = Bar (Foo (f Int))\r\ndoThStuff ''Bar\r\n}}}\r\n\r\nI get this error:\r\n{{{\r\n$ runghc -ddump-splices Bug.hs \r\n\r\nBug.hs:1:1:\r\n Exception when trying to run compile-time code:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-unknown-linux):\r\n\tkindFunResult\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n Code: doThStuff ''Bar\r\n}}}\r\n\r\nIf I comment out either `instance SomeClass (Foo a)` or `void (isInstance ''SomeClass [typ])`, the crash does not occur.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12274GHC panic: simplifier ticks exhausted2019-07-07T18:26:58ZmrkkrpGHC panic: simplifier ticks exhaustedWhile compiling a project, I ran into this:
```
Preprocessing library stache-0.1.0...
[1 of 6] Compiling Text.Mustache.Type ( Text/Mustache/Type.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Type.o ) [.stack-work/...While compiling a project, I ran into this:
```
Preprocessing library stache-0.1.0...
[1 of 6] Compiling Text.Mustache.Type ( Text/Mustache/Type.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Type.o ) [.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/cabal_macros.h changed]
[2 of 6] Compiling Text.Mustache.Parser ( Text/Mustache/Parser.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Parser.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying RuleFired Class op HEq_sc
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 189602
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The code is available here:
https://github.com/stackbuilders/stache
This only happens with GHC 8.0, with 7.10 it just takes forever (which should be a known issue, with 7.8 it's much faster), but nevertheless finishes.
With `-fsimpl-tick-factor=150` the build suceeded.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | CompileTimeCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic: simplifier ticks exhausted","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":"While compiling a project, I ran into this:\r\n\r\n{{{\r\nPreprocessing library stache-0.1.0...\r\n[1 of 6] Compiling Text.Mustache.Type ( Text/Mustache/Type.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Type.o ) [.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/cabal_macros.h changed]\r\n[2 of 6] Compiling Text.Mustache.Parser ( Text/Mustache/Parser.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Parser.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tSimplifier ticks exhausted\r\n When trying RuleFired Class op HEq_sc\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 189602\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe code is available here:\r\n\r\nhttps://github.com/stackbuilders/stache\r\n\r\nThis only happens with GHC 8.0, with 7.10 it just takes forever (which should be a known issue, with 7.8 it's much faster), but nevertheless finishes.\r\n\r\nWith `-fsimpl-tick-factor=150` the build suceeded.","type_of_failure":"CompileTimeCrash","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12383ghc: internal error: TSO object entered2019-07-07T18:26:51Zaufhebenghc: internal error: TSO object enteredI just ran into this build failure for the first time:
```
ghc: internal error: TSO object entered!
(GHC version 7.10.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm n...I just ran into this build failure for the first time:
```
ghc: internal error: TSO object entered!
(GHC version 7.10.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm not sure how to reproduce this bug or obtain more debugging information but this is how it happened: I was working with Yesod and trying to edit a .hamlet template file. When the file was saved Yesod tried to recompile the project and the build failed with that output.
<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: internal error: TSO object entered","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":"I just ran into this build failure for the first time:\r\n\r\n{{{\r\nghc: internal error: TSO object entered!\r\n (GHC version 7.10.3 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\nI'm not sure how to reproduce this bug or obtain more debugging information but this is how it happened: I was working with Yesod and trying to edit a .hamlet template file. When the file was saved Yesod tried to recompile the project and the build failed with that output.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->