GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:42:39Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8951genSym uses atomic_inc but doesn't link arm_atomic_spin_lock2019-07-07T18:42:39ZcjwatsongenSym uses atomic_inc but doesn't link arm_atomic_spin_lockOn Debian armel, a snapshot of GHC 7.8 from 20140228 fails to build as follows:
> https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564
```
"inplace/bin/ghc-stage2" -o utils/haddock/dist/buil...On Debian armel, a snapshot of GHC 7.8 from 20140228 fails to build as follows:
> https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564
```
"inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc-mlong-calls -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140228 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o
/«PKGBUILDDIR»/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym':
genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock'
genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock'
collect2: error: ld returned 1 exit status
make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1
```
Our armel architecture satisfies "arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6)", so cas() in includes/stg/SMP.h will (uniquely among architectures) not be entirely inline: it calls arm_atomic_spin_lock and arm_atomic_spin_unlock, which are in libHSrts. 7.8 introduces compiler/cbits/genSym.c which uses atomic_inc. How should the linkage requirements be satisfied here?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"genSym uses atomic_inc but doesn't link arm_atomic_spin_lock","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On Debian armel, a snapshot of GHC 7.8 from 20140228 fails to build as follows:\r\n\r\n https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140228-1&stamp=1394495564\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage2\" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc-mlong-calls -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140228 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o \r\n/«PKGBUILDDIR»/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym':\r\ngenSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock'\r\ngenSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock'\r\ncollect2: error: ld returned 1 exit status\r\nmake[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1\r\n}}}\r\n\r\nOur armel architecture satisfies \"arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6)\", so cas() in includes/stg/SMP.h will (uniquely among architectures) not be entirely inline: it calls arm_atomic_spin_lock and arm_atomic_spin_unlock, which are in libHSrts. 7.8 introduces compiler/cbits/genSym.c which uses atomic_inc. How should the linkage requirements be satisfied here?","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/88527.8.1 uses a lot of memory when compiling attoparsec programs using <|>2019-07-07T18:43:05Zjoelteon7.8.1 uses a lot of memory when compiling attoparsec programs using <|>To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec.
With this test program:
```haskell
{-# LANGUAGE OverloadedStrings #-}
import Contro...To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec.
With this test program:
```haskell
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Data.Attoparsec.Text
import Data.Text (Text)
parser :: Parser Text
parser = string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
<|> string "a" <|> string "a"
main :: IO ()
main = parseTest parser "a"
```
and using GHC 7.8.1.rc2:
Compiling using `-O2`, GHC tops out at \~1GB of RAM and takes 25s.
Using `-O0`, GHC takes 0.47s and uses \<150MB of RAM.
Compare this with GHC 7.6.3:
Compiling using `-O2`, GHC uses \<150MB and takes 3.7s. Memory usage is similar with `-O0` although compile time goes down to 0.36s.
An extreme version of this bug can be found in the `thyme` package here: https://github.com/liyang/thyme/blob/master/src/Data/Thyme/Format.hs\#L589-L693. Compiling that module with an unfixed attoparsec makes GHC use all available memory and stall out, forcing kill -9. Replacing the function body with `undefined` makes the package compile as expected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"7.8.1 uses a lot of memory when compiling attoparsec programs using <|>","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec.\r\n\r\nWith this test program:\r\n\r\n{{{#!haskell\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nimport Control.Applicative\r\nimport Data.Attoparsec.Text\r\nimport Data.Text (Text)\r\n\r\nparser :: Parser Text\r\nparser = string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n <|> string \"a\" <|> string \"a\"\r\n\r\nmain :: IO ()\r\nmain = parseTest parser \"a\"\r\n}}}\r\n\r\nand using GHC 7.8.1.rc2:\r\n\r\nCompiling using `-O2`, GHC tops out at ~1GB of RAM and takes 25s.\r\n\r\nUsing `-O0`, GHC takes 0.47s and uses <150MB of RAM.\r\n\r\nCompare this with GHC 7.6.3:\r\n\r\nCompiling using `-O2`, GHC uses <150MB and takes 3.7s. Memory usage is similar with `-O0` although compile time goes down to 0.36s.\r\n\r\nAn extreme version of this bug can be found in the `thyme` package here: https://github.com/liyang/thyme/blob/master/src/Data/Thyme/Format.hs#L589-L693. Compiling that module with an unfixed attoparsec makes GHC use all available memory and stall out, forcing kill -9. Replacing the function body with `undefined` makes the package compile as expected.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/8849Unregisterised compiler: arithmetic failure2019-07-07T18:43:07ZPeter Trommlerptrommler@acm.orgUnregisterised compiler: arithmetic failureCompiling the following with RC2 on powerpc 64 downloaded from haskell.org:
```
main = putStr $ show (-1.0000000001 :: Double)
```
Setting `-O` yields:
```
0.0
```
Without optimization the correct result is displayed.
I prepared an ...Compiling the following with RC2 on powerpc 64 downloaded from haskell.org:
```
main = putStr $ show (-1.0000000001 :: Double)
```
Setting `-O` yields:
```
0.0
```
Without optimization the correct result is displayed.
I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unregisterised compiler: arithmetic failure","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling the following with RC2 on powerpc 64 downloaded from haskell.org:\r\n{{{\r\nmain = putStr $ show (-1.0000000001 :: Double)\r\n}}}\r\nSetting {{{-O}}} yields:\r\n{{{\r\n0.0\r\n}}}\r\nWithout optimization the correct result is displayed.\r\n\r\nI prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/8825ghc can't determine gcc version on ru_RU locale2019-07-07T18:43:13ZSergei Trofimovichghc can't determine gcc version on ru_RU localeCurrent ghc spits warnings time to time:
```
<no location info>:
Warning: Couldn't figure out linker information!
Make sure you're using GNU gcc, or clang
```
It's because my default locale is **LANG=ru_RU.UTF-8** \[1\...Current ghc spits warnings time to time:
```
<no location info>:
Warning: Couldn't figure out linker information!
Make sure you're using GNU gcc, or clang
```
It's because my default locale is **LANG=ru_RU.UTF-8** \[1\]
```
...
gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
```
versus **LANG=C**
```
...
gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
```
\[1\]:
```
$ gcc -v
Используются внутренние спецификации.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Целевая архитектура: x86_64-pc-linux-gnu
Параметры конфигурации: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
Модель многопоточности: posix
gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
```
\[2\]:
While LANG=C output:
```
$ LANG=C gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
Thread model: posix
gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| 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 can't determine gcc version on ru_RU locale","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Current ghc spits warnings time to time:\r\n\r\n{{{\r\n<no location info>:\r\n Warning: Couldn't figure out linker information!\r\n Make sure you're using GNU gcc, or clang\r\n}}}\r\n\r\nIt's because my default locale is '''LANG=ru_RU.UTF-8''' [1]\r\n{{{\r\n...\r\ngcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)\r\n}}}\r\nversus '''LANG=C'''\r\n{{{\r\n...\r\ngcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)\r\n}}}\r\n\r\n[1]:\r\n{{{\r\n$ gcc -v\r\nИспользуются внутренние спецификации.\r\nCOLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc\r\nCOLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper\r\nЦелевая архитектура: x86_64-pc-linux-gnu\r\nПараметры конфигурации: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog\r\nМодель многопоточности: posix\r\ngcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)\r\n}}}\r\n\r\n[2]:\r\nWhile LANG=C output:\r\n\r\n{{{\r\n$ LANG=C gcc -v\r\nUsing built-in specs.\r\nCOLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc\r\nCOLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper\r\nTarget: x86_64-pc-linux-gnu\r\nConfigured with: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog\r\nThread model: posix\r\ngcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/881964bit Testsuite failures in unregisterised 7.8 RCs2019-07-07T18:43:18ZPeter Trommlerptrommler@acm.org64bit Testsuite failures in unregisterised 7.8 RCsWith the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64:
```
Unexpected failures:
../../libraries/base/tests fixed [bad stdout] ...With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64:
```
Unexpected failures:
../../libraries/base/tests fixed [bad stdout] (normal)
../../libraries/base/tests/Numeric num010 [bad stdout] (normal)
../../libraries/process/tests process007 [bad exit code] (normal)
codeGen/should_compile T7574 [stderr mismatch] (normal)
codeGen/should_gen_asm memcpy [asm mismatch] (normal)
codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal)
codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal)
codeGen/should_run T2838 [bad stdout] (normal)
lib/integer integerBits [bad stdout] (normal)
lib/integer integerConversions [bad stdout] (normal)
numeric/should_run T8726 [bad exit code] (normal)
numeric/should_run arith002 [bad stdout] (normal)
numeric/should_run arith003 [bad stdout] (normal)
numeric/should_run arith004 [bad stdout] (normal)
numeric/should_run arith005 [bad stdout] (normal)
numeric/should_run arith011 [bad stdout] (normal)
numeric/should_run arith012 [bad stdout] (normal)
numeric/should_run arith014 [bad stdout] (normal)
parser/should_run readRun002 [bad stdout] (normal)
perf/compiler T1969 [stat too good] (normal)
perf/compiler T3064 [stat too good] (normal)
perf/compiler T783 [stat too good] (normal)
perf/should_run T3736 [bad stderr] (normal)
rts T5423 [bad stderr] (normal)
rts T7815 [bad exit code] (threaded1)
safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite failures in 7.8 RC1","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64:\r\n{{{\r\nUnexpected failures:\r\n ../../libraries/base/tests fixed [bad stdout] (normal)\r\n ../../libraries/base/tests/Numeric num010 [bad stdout] (normal)\r\n ../../libraries/process/tests process007 [bad exit code] (normal)\r\n codeGen/should_compile T7574 [stderr mismatch] (normal)\r\n codeGen/should_gen_asm memcpy [asm mismatch] (normal)\r\n codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal)\r\n codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal)\r\n codeGen/should_run T2838 [bad stdout] (normal)\r\n lib/integer integerBits [bad stdout] (normal)\r\n lib/integer integerConversions [bad stdout] (normal)\r\n numeric/should_run T8726 [bad exit code] (normal)\r\n numeric/should_run arith002 [bad stdout] (normal)\r\n numeric/should_run arith003 [bad stdout] (normal)\r\n numeric/should_run arith004 [bad stdout] (normal)\r\n numeric/should_run arith005 [bad stdout] (normal)\r\n numeric/should_run arith011 [bad stdout] (normal)\r\n numeric/should_run arith012 [bad stdout] (normal)\r\n numeric/should_run arith014 [bad stdout] (normal)\r\n parser/should_run readRun002 [bad stdout] (normal)\r\n perf/compiler T1969 [stat too good] (normal)\r\n perf/compiler T3064 [stat too good] (normal)\r\n perf/compiler T783 [stat too good] (normal)\r\n perf/should_run T3736 [bad stderr] (normal)\r\n rts T5423 [bad stderr] (normal)\r\n rts T7815 [bad exit code] (threaded1)\r\n safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/7898SpecConstr explodes when compiling module BSP of frag-1.1.22022-04-25T19:06:30ZTinctoriusSpecConstr explodes when compiling module BSP of frag-1.1.2GHC will get stuck when trying to compile [Frag](http://www.haskell.org/haskellwiki/Frag). Steps to reproduce:
1. Get Frag 1.1.2 from the Darcs repository (`darcs get http://code.haskell.org/frag`), or from snowmantw's !GitHub fork (`gi...GHC will get stuck when trying to compile [Frag](http://www.haskell.org/haskellwiki/Frag). Steps to reproduce:
1. Get Frag 1.1.2 from the Darcs repository (`darcs get http://code.haskell.org/frag`), or from snowmantw's !GitHub fork (`git clone https://github.com/snowmantw/Frag.git`).
1. Fix the code so it'll actually compile:
`
diff --git a/src/Textures.hs b/src/Textures.hs
index 7383fd8..b5516a5 100644
--- a/src/Textures.hs
+++ b/src/Textures.hs
@@ -10,6 +10,7 @@ import Graphics.UI.GLUT
import TGA (readTga)
import Data.Word (Word8)
import Foreign.Marshal.Alloc (free)
+import Control.Exception (catch, SomeException)
-- read a list of images and returns a list of textures
@@ -32,7 +33,8 @@ getAndCreateTexture fileName = do
-- read the image data
readImageC :: String -> IO (Maybe (Size, PixelData Word8))
-readImageC path = catch (readTga path) (\_ -> do print ("missing texture: "++path)
+readImageC path = catch (readTga path) (\e -> do print (e :: SomeException)
+ print ("missing texture: "++path)
return Nothing)
`
1. `cabal configure`
1. `cabal build`
GHC will get stuck on the module `BSP` and consume memory until it crashes. According to [this ticket on the GitHub fork mentioned earlier](https://github.com/snowmantw/Frag/issues/1), this problem only occurs with `-O2`.
When I split the reading part of the module (`readBSP` and all functions it depends on), it crashed on that part. Will investigate further.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Compiler diverges when compiling module BSP of frag-1.1.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC will get stuck when trying to compile [http://www.haskell.org/haskellwiki/Frag Frag]. Steps to reproduce:\r\n\r\n 1. Get Frag 1.1.2 from the Darcs repository (`darcs get http://code.haskell.org/frag`), or from snowmantw's !GitHub fork (`git clone https://github.com/snowmantw/Frag.git`).\r\n 1. Fix the code so it'll actually compile:\r\n {{{\r\ndiff --git a/src/Textures.hs b/src/Textures.hs\r\nindex 7383fd8..b5516a5 100644\r\n--- a/src/Textures.hs\r\n+++ b/src/Textures.hs\r\n@@ -10,6 +10,7 @@ import Graphics.UI.GLUT\r\n import TGA (readTga)\r\n import Data.Word (Word8)\r\n import Foreign.Marshal.Alloc (free)\r\n+import Control.Exception (catch, SomeException)\r\n \r\n \r\n -- read a list of images and returns a list of textures\r\n@@ -32,7 +33,8 @@ getAndCreateTexture fileName = do\r\n \r\n -- read the image data\r\n readImageC :: String -> IO (Maybe (Size, PixelData Word8))\r\n-readImageC path = catch (readTga path) (\\_ -> do print (\"missing texture: \"++path)\r\n+readImageC path = catch (readTga path) (\\e -> do print (e :: SomeException)\r\n+ print (\"missing texture: \"++path)\r\n return Nothing)\r\n \r\n }}}\r\n 1. `cabal configure`\r\n 1. `cabal build`\r\n\r\nGHC will get stuck on the module `BSP` and consume memory until it crashes. According to [https://github.com/snowmantw/Frag/issues/1 this ticket on the GitHub fork mentioned earlier], this problem only occurs with `-O2`.\r\n\r\nWhen I split the reading part of the module (`readBSP` and all functions it depends on), it crashed on that part. Will investigate further.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/7143ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version2019-07-07T18:51:08Zcetinsertghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM versionI have downloaded:
ghc: ghc-7.6.0.20120810-x86_64-windows.exe
mingw64: http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w64-bin-x86_64-20120807.7z
llvm64: http://www.drangon.org/mingw/mirror.php?num=2&fname=llvm-3.1-w64-bin-x...I have downloaded:
ghc: ghc-7.6.0.20120810-x86_64-windows.exe
mingw64: http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w64-bin-x86_64-20120807.7z
llvm64: http://www.drangon.org/mingw/mirror.php?num=2&fname=llvm-3.1-w64-bin-x86_64-20120610.7z
my path contains:
```
/c/ghc/ghc-7.6.0.20120810/bin:/c/Users/Cetin/AppData/Roaming/cabal/bin:/c/llvm/bin:/c/mw64/bin
```
When I run:
```
ghc -fllvm --make Main.hs
```
I get:
```
[1 of 1] Compiling Main ( Main.hs, Main.o )
<no location info>:
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM
```
Attached is the output from:
```
ghc -v3 -fllvm --make Main.hs
```
for all Main.hs - it mentions:
```
*** LlVM CodeGen:
Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)
<no location info>:
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM
*** LLVM Optimiser:
"" "C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll" "-o" "C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc" "-mem2reg" "--enable-tbaa=true"
Failed: "" "C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll" "-o" "C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc" "-mem2reg" "--enable-tb
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLC version","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1-rc1","keywords":["llvm"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I have downloaded:\r\n\r\nghc: ghc-7.6.0.20120810-x86_64-windows.exe\r\n\r\nmingw64: http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w64-bin-x86_64-20120807.7z \r\n\r\nllvm64: http://www.drangon.org/mingw/mirror.php?num=2&fname=llvm-3.1-w64-bin-x86_64-20120610.7z\r\n\r\nmy path contains:\r\n\r\n{{{\r\n/c/ghc/ghc-7.6.0.20120810/bin:/c/Users/Cetin/AppData/Roaming/cabal/bin:/c/llvm/bin:/c/mw64/bin\r\n}}}\r\n\r\n\r\nWhen I run:\r\n\r\n{{{\r\nghc -fllvm --make Main.hs\r\n}}}\r\n\r\nI get:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( Main.hs, Main.o )\r\n\r\n<no location info>:\r\n Warning: Couldn't figure out LLVM version!\r\n Make sure you have installed LLVM\r\n}}}\r\n\r\nAttached is the output from:\r\n\r\n{{{\r\nghc -v3 -fllvm --make Main.hs\r\n}}}\r\n\r\nfor all Main.hs - it mentions:\r\n\r\n{{{\r\n*** LlVM CodeGen:\r\nError (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)\r\n\r\n<no location info>:\r\n Warning: Couldn't figure out LLVM version!\r\n Make sure you have installed LLVM\r\n*** LLVM Optimiser:\r\n\"\" \"C:\\Users\\Cetin\\AppData\\Local\\Temp\\ghc6036_0\\ghc6036_0.ll\" \"-o\" \"C:\\Users\\Cetin\\AppData\\Local\\Temp\\ghc6036_0\\ghc6036_0.bc\" \"-mem2reg\" \"--enable-tbaa=true\"\r\n\r\n\r\nFailed: \"\" \"C:\\Users\\Cetin\\AppData\\Local\\Temp\\ghc6036_0\\ghc6036_0.ll\" \"-o\" \"C:\\Users\\Cetin\\AppData\\Local\\Temp\\ghc6036_0\\ghc6036_0.bc\" \"-mem2reg\" \"--enable-tb\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4FanaelFanaelhttps://gitlab.haskell.org/ghc/ghc/-/issues/7068Extensive Memory usage (regression)2019-07-07T18:51:33ZwaldheinzExtensive Memory usage (regression)The "bling raytracer" project \[1\] can not be compiled with recent GHC versions (personally tested 7.4.1 on Linux / OS X / Windows, that 7.4.2 fails in the same way was reported on IRC).
The problem is that when compiling the "Transfor...The "bling raytracer" project \[1\] can not be compiled with recent GHC versions (personally tested 7.4.1 on Linux / OS X / Windows, that 7.4.2 fails in the same way was reported on IRC).
The problem is that when compiling the "Transform.hs" source file \[2\] GHC allocates more RAM than any of my machines can bear (8+ GB).
This does not happen with 7.0.x versions of GHC. Also, reducing the optimization level from O2 to O1 makes the problem go away. To reproduce this bug I'd recommend
> hg clone -r eb0f7f91bde6 https://code.google.com/p/bling-raytracer/
> cabal build
There was no consensus on IRC if this is really a GHC bug or I should simply tinker with the GHC options / source file until it works. But since the code in question does not use any obscure extensions (in fact, no extensions at all) and could be compiled with many GHC versions from 6.4 onward, I thought you might want to hear about it.
\[1\] http://code.google.com/p/bling-raytracer/
\[2\] http://code.google.com/p/bling-raytracer/source/browse/src/Graphics/Bling/Transform.hs?r=9499d979762ddcbc1ff31aea053dfcf3d4590a08
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"Extensive Memory usage (regression)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The \"bling raytracer\" project [1] can not be compiled with recent GHC versions (personally tested 7.4.1 on Linux / OS X / Windows, that 7.4.2 fails in the same way was reported on IRC).\r\n\r\nThe problem is that when compiling the \"Transform.hs\" source file [2] GHC allocates more RAM than any of my machines can bear (8+ GB).\r\n\r\nThis does not happen with 7.0.x versions of GHC. Also, reducing the optimization level from O2 to O1 makes the problem go away. To reproduce this bug I'd recommend\r\n\r\n> hg clone -r eb0f7f91bde6 https://code.google.com/p/bling-raytracer/\r\n> cabal build\r\n\r\nThere was no consensus on IRC if this is really a GHC bug or I should simply tinker with the GHC options / source file until it works. But since the code in question does not use any obscure extensions (in fact, no extensions at all) and could be compiled with many GHC versions from 6.4 onward, I thought you might want to hear about it.\r\n\r\n[1] http://code.google.com/p/bling-raytracer/\r\n[2] http://code.google.com/p/bling-raytracer/source/browse/src/Graphics/Bling/Transform.hs?r=9499d979762ddcbc1ff31aea053dfcf3d4590a08\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/10176Invalid core generated with GHC 7.10 RC32019-07-07T18:37:13ZNeil MitchellInvalid core generated with GHC 7.10 RC3Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:
```
## BUILD oracle --quiet *str-int
TESTS FAILED
shake-test: Expected an exception but s...Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:
```
## BUILD oracle --quiet *str-int
TESTS FAILED
shake-test: Expected an exception but succeeded
```
Discussion about this issue can be found on the mailing list: http://osdir.com/ml/general/2015-03/msg25847.html
GHC generates the Core:
```
case (\_ -> error "here") of {}
```
This is invalid GHC Core. I intend to track down a minimal example shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Invalid core generated with GHC 7.10 RC3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:\r\n\r\n{{{\r\n## BUILD oracle --quiet *str-int\r\nTESTS FAILED\r\nshake-test: Expected an exception but succeeded\r\n}}}\r\n\r\nDiscussion about this issue can be found on the mailing list: http://osdir.com/ml/general/2015-03/msg25847.html\r\n\r\nGHC generates the Core:\r\n\r\n{{{\r\ncase (\\_ -> error \"here\") of {}\r\n}}}\r\n\r\nThis is invalid GHC Core. I intend to track down a minimal example shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/10165Win32 broken with GHC 7.10 RC32019-07-07T18:37:16ZNeil MitchellWin32 broken with GHC 7.10 RC3Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:
```
C:\Neil>ghci
GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Win32...Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:
```
C:\Neil>ghci
GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Win32
Prelude System.Win32> wRITE_DAC
<interactive>: C:\ghc\ghc-7.10.0.20150316\lib\Win32_6dnIMpnCmqmCdDB983aKnr\HSWin
32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW'
ghc.exe: unable to load package `Win32-2.3.1.0'
```
This seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Win32 broken with GHC 7.10 RC3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:\r\n\r\n{{{\r\nC:\\Neil>ghci\r\nGHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help\r\nPrelude> import System.Win32\r\nPrelude System.Win32> wRITE_DAC\r\n<interactive>: C:\\ghc\\ghc-7.10.0.20150316\\lib\\Win32_6dnIMpnCmqmCdDB983aKnr\\HSWin\r\n32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW'\r\nghc.exe: unable to load package `Win32-2.3.1.0'\r\n}}}\r\n\r\nThis seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10164Cleanup test framework string formatting2019-07-07T18:37:16ZThomas MiedemaCleanup test framework string formattingThis is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versio...This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cleanup test framework string formatting","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10142Documentation for Ix is contradictory around minimal definition2019-07-07T18:37:21ZRichard Eisenbergrae@richarde.devDocumentation for Ix is contradictory around minimal definitionThe Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires...The Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for Ix is contradictory around minimal definition","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/10128Data.List.transpose needs more docs2019-07-07T18:37:23ZJoachim Breitnermail@joachim-breitner.deData.List.transpose needs more docsas mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose func...as mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose function transposes the rows and columns of its argument. For example,
>
> ```
> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]
> ```
>
> If some of the rows are shorter than the following rows, their elements are skipped:
>
> ```
> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]
> ```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.transpose needs more docs","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"as mentioned by Doug McIlroy on haskell-prime.\r\n\r\nMy preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:\r\n\r\n> The transpose function transposes the rows and columns of its argument. For example,\r\n> \r\n> {{{\r\n> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]\r\n> }}}\r\n> \r\n> If some of the rows are shorter than the following rows, their elements are skipped:\r\n> \r\n> {{{\r\n> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]\r\n> }}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10115Unable to run cabal haddock --hoogle on GHC 7.102019-07-07T18:37:26ZMichael Snoymanmichael@snoyman.comUnable to run cabal haddock --hoogle on GHC 7.10At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, ...At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it:
https://github.com/haskell/haddock/issues/361
https://github.com/haskell/cabal/issues/2297
I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to run cabal haddock --hoogle on GHC 7.10","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:\r\n\r\nI'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it:\r\n\r\nhttps://github.com/haskell/haddock/issues/361\r\nhttps://github.com/haskell/cabal/issues/2297\r\n\r\nI really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10113Re-export (<$>) and (<$) from Prelude2019-07-07T18:37:27ZHerbert Valerio Riedelhvr@gnu.orgRe-export (<$>) and (<$) from PreludeSee http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field ...See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10099cabal install broken with ghc 7.10.1-rc22019-07-07T18:37:30ZPeter Trommlerptrommler@acm.orgcabal install broken with ghc 7.10.1-rc2Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primi...Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primitive-0.5.4.0...
cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf
```
This is my package database:
```
peter@montebre:~> ghc-pkg list
/usr/lib64/ghc-7.10.0.20150123/package.conf.d
Cabal-1.22.1.0
HTTP-4000.2.19
array-0.5.0.1
base-4.8.0.0
bin-package-db-0.0.0.0
binary-0.7.3.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.0.0
directory-1.2.2.0
filepath-1.3.1.0
ghc-7.10.0.20150123
ghc-prim-0.3.1.0
haskeline-0.7.2.0
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
mtl-2.2.1
network-2.4.2.3
old-locale-1.0.0.7
old-time-1.1.0.3
parsec-3.1.8
pretty-1.1.2.0
process-1.2.2.0
random-1.0.1.1
rts-1.0
stm-2.4.2
syb-0.4.4
template-haskell-2.10.0.0
terminfo-0.4.0.1
text-1.2.0.4
th-desugar-1.5
th-lift-0.7
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
zlib-0.5.4.2
```
I updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.
I am setting this to highest as this issue would be very annoying for everyone.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cabal install broken with ghc 7.10.1-rc2","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2\r\nconsistently gives this error message (`primitive` is just an example):\r\n{{{\r\npeter@montebre:~> cabal install primitive\r\nResolving dependencies...\r\nConfiguring primitive-0.5.4.0...\r\ncabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf\r\n}}}\r\n\r\nThis is my package database:\r\n{{{\r\npeter@montebre:~> ghc-pkg list\r\n/usr/lib64/ghc-7.10.0.20150123/package.conf.d\r\n Cabal-1.22.1.0\r\n HTTP-4000.2.19\r\n array-0.5.0.1\r\n base-4.8.0.0\r\n bin-package-db-0.0.0.0\r\n binary-0.7.3.0\r\n bytestring-0.10.6.0\r\n containers-0.5.6.2\r\n deepseq-1.4.0.0\r\n directory-1.2.2.0\r\n filepath-1.3.1.0\r\n ghc-7.10.0.20150123\r\n ghc-prim-0.3.1.0\r\n haskeline-0.7.2.0\r\n hoopl-3.10.0.2\r\n hpc-0.6.0.2\r\n integer-gmp-1.0.0.0\r\n mtl-2.2.1\r\n network-2.4.2.3\r\n old-locale-1.0.0.7\r\n old-time-1.1.0.3\r\n parsec-3.1.8\r\n pretty-1.1.2.0\r\n process-1.2.2.0\r\n random-1.0.1.1\r\n rts-1.0\r\n stm-2.4.2\r\n syb-0.4.4\r\n template-haskell-2.10.0.0\r\n terminfo-0.4.0.1\r\n text-1.2.0.4\r\n th-desugar-1.5\r\n th-lift-0.7\r\n time-1.5.0.1\r\n transformers-0.4.2.0\r\n unix-2.7.1.0\r\n xhtml-3000.2.1\r\n zlib-0.5.4.2\r\n}}}\r\nI updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.\r\n\r\nI am setting this to highest as this issue would be very annoying for everyone.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10096Top-level ./configure should accept and propagate --with-curses-{includes,lib...2019-07-07T18:37:33ZPHOTop-level ./configure should accept and propagate --with-curses-{includes,libraries} to librariesIf curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:
```
libraries/terminfo_CONFIGURE_OPTS += \
--configure-option=--with-curses-includes=/somewhere/include \
...If curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:
```
libraries/terminfo_CONFIGURE_OPTS += \
--configure-option=--with-curses-includes=/somewhere/include \
--configure-option=--with-curses-libraries=/somewhere/lib
```
This is because the top-level `configure` does not accept nor propagate `--with-curses-{includes,libraries}` to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner.
I will soon submit a patch for this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Top-level ./configure should accept and propagate --with-curses-{includes,libraries} to libraries","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"If curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:\r\n{{{\r\nlibraries/terminfo_CONFIGURE_OPTS += \\\r\n --configure-option=--with-curses-includes=/somewhere/include \\\r\n --configure-option=--with-curses-libraries=/somewhere/lib\r\n}}}\r\n\r\nThis is because the top-level `configure` does not accept nor propagate `--with-curses-{includes,libraries}` to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner.\r\n\r\nI will soon submit a patch for this.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10091Add configurable verbosity level to hpc executable2019-07-07T18:37:35ZYurasAdd configurable verbosity level to hpc executableRight now `hpc markup` writes a notice for each module and for each index file:
```
Writing: Module.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
```
That is a bit a...Right now `hpc markup` writes a notice for each module and for each index file:
```
Writing: Module.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
```
That is a bit annoying when you have e.g. 100 modules.
I propose to add `--verbosity` flag with possible values `0`, `1` and `2` (default `1`) and suppress the notice for verbosity level `0`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add configurable verbosity level to hpc executable","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Right now `hpc markup` writes a notice for each module and for each index file:\r\n\r\n{{{\r\nWriting: Module.hs.html\r\nWriting: hpc_index.html\r\nWriting: hpc_index_fun.html\r\nWriting: hpc_index_alt.html\r\nWriting: hpc_index_exp.html\r\n}}}\r\n\r\nThat is a bit annoying when you have e.g. 100 modules.\r\n\r\nI propose to add `--verbosity` flag with possible values `0`, `1` and `2` (default `1`) and suppress the notice for verbosity level `0`","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1YurasYurashttps://gitlab.haskell.org/ghc/ghc/-/issues/10088Broken link in Data.Ix documentation2019-07-07T18:37:36ZDavid FeuerBroken link in Data.Ix documentationThe Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index....The Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index.
This link is dead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken link in Data.Ix documentation","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Data.Ix` includes the following line:\r\n\r\n For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html#prelude-index.\r\n\r\nThis link is dead.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10078tcPluginStop of a type checker plugin is not called if an error occurs2019-07-07T18:37:39ZjbrackertcPluginStop of a type checker plugin is not called if an error occursWhen a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChec...When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.
### Test plugin
`MyPlugin.hs`:
```hs
module MyPlugin
( plugin ) where
import Plugins
import TcRnTypes
import TcPluginM
plugin :: Plugin
plugin = defaultPlugin
{ tcPlugin = \clos -> Just $ TcPlugin
{ tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init"
, tcPluginSolve = \_ _ _ _ -> do
tcPluginIO $ putStrLn ">>> Plugin Solve"
return $ TcPluginOk [] []
, tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop"
}
}
```
### Minimal example (with type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return 1
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Solve
Main.hs:6:10:
Could not deduce (Num ()) arising from the literal ‘1’
from the context: Monad m
bound by the type signature for: main :: Monad m => m ()
at Main.hs:4:9-25
In the first argument of ‘return’, namely ‘1’
In a stmt of a 'do' block: return 1
In the expression: do { return 1 }
```
Which means `tcPluginStop` was _not_ called.
### Minimal example (without type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return ()
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Stop
Linking Main ...
```
Which means `tcPluginStop` _was_ called.
### Possible solution
As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
to
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
case eitherRes of
Left e -> failM
Right res -> return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
.
I have tried this. It compiles and my minimal example delivers the correct result.
Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.
<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 | adamgundry |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tcPluginStop of a type checker plugin is not called if an error occurs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["adamgundry"],"type":"Bug","description":"When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.\r\n\r\nI am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.\r\n\r\n=== Test plugin\r\n\r\n`MyPlugin.hs`:\r\n{{{#!hs\r\nmodule MyPlugin\r\n ( plugin ) where\r\n\r\nimport Plugins\r\nimport TcRnTypes\r\nimport TcPluginM\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin \r\n { tcPlugin = \\clos -> Just $ TcPlugin \r\n { tcPluginInit = tcPluginIO $ putStrLn \">>> Plugin Init\"\r\n , tcPluginSolve = \\_ _ _ _ -> do\r\n tcPluginIO $ putStrLn \">>> Plugin Solve\"\r\n return $ TcPluginOk [] []\r\n , tcPluginStop = \\_ -> tcPluginIO $ putStrLn \">>> Plugin Stop\"\r\n }\r\n }\r\n}}}\r\n\r\n=== Minimal example (with type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return 1\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n\r\nMain.hs:6:10:\r\n Could not deduce (Num ()) arising from the literal ‘1’\r\n from the context: Monad m\r\n bound by the type signature for: main :: Monad m => m ()\r\n at Main.hs:4:9-25\r\n In the first argument of ‘return’, namely ‘1’\r\n In a stmt of a 'do' block: return 1\r\n In the expression: do { return 1 }\r\n}}}\r\nWhich means `tcPluginStop` was _not_ called.\r\n\r\n=== Minimal example (without type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return ()\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Stop\r\nLinking Main ...\r\n}}}\r\nWhich means `tcPluginStop` _was_ called.\r\n\r\n=== Possible solution\r\n\r\nAs far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n res <- updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\nto\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n eitherRes <- tryM $ do updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n case eitherRes of\r\n Left e -> failM\r\n Right res -> return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\n.\r\n\r\nI have tried this. It compiles and my minimal example delivers the correct result.\r\n\r\nAre there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1jbrackerjbracker