GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:03:13Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3590panic (the impossible happened) when compiling with -O22019-07-07T19:03:13Zyairchupanic (the impossible happened) when compiling with -O2when compiling the attached program with -O2 I get the following error:
```
[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-apple-darwin):
Coercio...when compiling the attached program with -O2 I get the following error:
```
[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-apple-darwin):
Coercion.splitCoercionKindOf
ghc-prim:GHC.Prim.left{(w) tc 34B}
(ghc-prim:GHC.Prim.trans{(w) tc 34y}
(List-0.3:Data.List.Class.ItemM{tc r28}
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk]))
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]
List-0.3:Control.Monad.ListT.:CoF:R5ItemM{tc r29} List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D}
a{tv ayS} [sk])
c{tv ayR} [sk]))
<pred>List-0.3:Data.List.Class.ItemM{tc r28}
(List-0.3:Control.Monad.ListT.ListT{tc r34}
(ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))
~
ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
When compiling without -O2, it works.
I am using TypeFamilies (for the List class)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"panic (the impossible happened) when compiling with -O2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"when compiling the attached program with -O2 I get the following error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( crashTest.hs, crashTest.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-apple-darwin):\r\n\tCoercion.splitCoercionKindOf\r\n ghc-prim:GHC.Prim.left{(w) tc 34B}\r\n (ghc-prim:GHC.Prim.trans{(w) tc 34y}\r\n (List-0.3:Data.List.Class.ItemM{tc r28}\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk]))\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]\r\n List-0.3:Control.Monad.ListT.:CoF:R5ItemM{tc r29} List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D}\r\n a{tv ayS} [sk])\r\n c{tv ayR} [sk]))\r\n <pred>List-0.3:Data.List.Class.ItemM{tc r28}\r\n (List-0.3:Control.Monad.ListT.ListT{tc r34}\r\n (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]))\r\n ~\r\n ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nWhen compiling without -O2, it works.\r\nI am using TypeFamilies (for the List class)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3591A working program reports <<loop>> when compiled with -O2021-04-07T16:37:52ZGhost UserA working program reports <<loop>> when compiled with -OIf the attached module Trampoline.hs is compiled with no optimizations it works:
```
$ ghc --make Trampoline.hs
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
...
((5,2),(1,...If the attached module Trampoline.hs is compiled with no optimizations it works:
```
$ ghc --make Trampoline.hs
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
...
((5,2),(1,2,6))
$
```
With optimizations on, it hangs:
```
$ ghc --make Trampoline.hs -O
[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )
Linking Trampoline ...
$ ./Trampoline
bounce start
bounce end
liftOut
inject suspend
Trampoline: <<loop>>
```
That doesn't seem right. Oh, GHCi runs it with no problem as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"A working program reports <<loop>> when compiled with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the attached module Trampoline.hs is compiled with no optimizations it works:\r\n\r\n{{{\r\n$ ghc --make Trampoline.hs \r\n[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )\r\nLinking Trampoline ...\r\n$ ./Trampoline \r\n...\r\n((5,2),(1,2,6))\r\n$ \r\n}}}\r\n\r\nWith optimizations on, it hangs:\r\n\r\n{{{\r\n$ ghc --make Trampoline.hs -O\r\n[1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o )\r\nLinking Trampoline ...\r\n$ ./Trampoline \r\nbounce start\r\nbounce end\r\nliftOut\r\ninject suspend\r\nTrampoline: <<loop>>\r\n}}}\r\n\r\nThat doesn't seem right. Oh, GHCi runs it with no problem as well.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3592Eta-contraction gives a rather bogus type error message2019-07-07T19:03:12ZguestEta-contraction gives a rather bogus type error messageConsider the following program:
```
module Main where
type T a = Show a => a
f :: T a -> String
f = show
```
Compiling this with GHC 6.10.3 and -fglasgow-exts gives:
```
[1 of 1] Compiling Main ( Test.hs, interpreted )
g...Consider the following program:
```
module Main where
type T a = Show a => a
f :: T a -> String
f = show
```
Compiling this with GHC 6.10.3 and -fglasgow-exts gives:
```
[1 of 1] Compiling Main ( Test.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
TcTyFuns.flattenType: unexpected PredType
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thomas@cs.ru.nl |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! on overloaded type synonym","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":["thomas@cs.ru.nl"],"type":"Bug","description":"Consider the following program:\r\n\r\n{{{\r\nmodule Main where\r\n\r\ntype T a = Show a => a\r\n\r\nf :: T a -> String\r\nf = show\r\n}}}\r\n\r\nCompiling this with GHC 6.10.3 and -fglasgow-exts gives:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( Test.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-apple-darwin):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3593Where has readline gone?2019-07-07T19:03:12ZspiveyWhere has readline gone?In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I ...In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Where has readline gone?","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3594ppc stage1 panic for --enable-shared2019-07-07T19:03:12ZJens Petersenppc stage1 panic for --enable-sharedNot sure if this is expected but ghc-6.12 panics on ppc
when it starts to build shared libraries:
```
/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a
"inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -...Not sure if this is expected but ghc-6.12 panics on ppc
when it starts to build shared libraries:
```
/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a
"inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.12.0.20091010 for powerpc-unknown-linux):
getRegisterReg-memory PicBaseReg
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o] Error 1
make: *** [all] Error 2
```
so reporting it here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ppc stage1 panic for --enable-shared","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not sure if this is expected but ghc-6.12 panics on ppc\r\nwhen it starts to build shared libraries:\r\n\r\n{{{\r\n/usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaskeline-0.6.2.1.a\r\n\"inplace/bin/ghc-stage1\" -fPIC -dynamic -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/ghc-prim/./GHC/Generics.hs -o libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 6.12.0.20091010 for powerpc-unknown-linux):\r\n getRegisterReg-memory PicBaseReg\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o] Error 1\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nso reporting it here.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3595The forefathers of Haskell ...2019-07-07T19:03:12ZJohnDThe forefathers of Haskell ...17 October 2009
I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes a...17 October 2009
I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem.
Haskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-)
At one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he.
Unix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it.
What exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sited and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats.
If you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The forefathers of Haskell ...","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"17 October 2009\r\n\r\nI am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem.\r\n\r\nHaskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-)\r\n\r\nAt one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he.\r\n\r\nUnix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it.\r\n\r\nWhat exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sited and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats.\r\n\r\nIf you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3596getOptions'.parseLanguage(1) went past eof token2019-07-07T19:03:11ZPaczesiowagetOptions'.parseLanguage(1) went past eof tokenthis (19char) "code" crashes ghc-6.10.4:
```
{-#LANGUAGE CPP
#-}
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-linux):
> getOptions'.parseLanguage(1) went past eof token
<details><summary>Trac me...this (19char) "code" crashes ghc-6.10.4:
```
{-#LANGUAGE CPP
#-}
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-linux):
> getOptions'.parseLanguage(1) went past eof token
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getOptions'.parseLanguage(1) went past eof token","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"this (19char) \"code\" crashes ghc-6.10.4:\r\n{{{\r\n{-#LANGUAGE CPP\r\n#-}\r\n}}}\r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-linux):\r\n getOptions'.parseLanguage(1) went past eof token\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3597trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf2019-07-07T19:03:11Zzookotrying to build ghc 6.10.4 from src tarball: haddock: Can't find package.confFolks:
Trying to build from the ghc-6.10.4 source tarball on Ubuntu Hardy i686, the "make" step ends with:
```
Preprocessing library terminfo-0.3.1...
Running Haddock for terminfo-0.3.1...
Warning: The documentation for the following p...Folks:
Trying to build from the ghc-6.10.4 source tarball on Ubuntu Hardy i686, the "make" step ends with:
```
Preprocessing library terminfo-0.3.1...
Running Haddock for terminfo-0.3.1...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: rts-1.0
Documentation created: dist/doc/html/terminfo/index.html
if ifBuildable/ifBuildable /home/zooko/playground/ghc/ghc-6.10.4/packages haskeline; then \
cd haskeline && /home/zooko/playground/ghc/ghc-6.10.4/libraries/cabal-bin /usr/bin/ghc /home/zooko/playground/ghc/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 haddock --html-location='../$pkg' \
--with-haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/bin/haddock; \
fi
./Setup haddock --html-location=../$pkg --with-haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/bin/haddock
Preprocessing library haskeline-0.6.1.5...
Running Haddock for haskeline-0.6.1.5...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: rts-1.0
Warning: System.Console.Haskeline.History: could not find link destinations for:
System.Console.Haskeline.Monads.MonadState
Warning: System.Console.Haskeline.MonadException: could not find link destinations for:
System.Console.Haskeline.Backend.Terminfo.Draw System.Console.Haskeline.Backend.DumbTerm.DumbTerm GHC.IOBase.IOError GHC.IOBase.ioe_handle GHC.IOBase.ioe_type GHC.IOBase.ioe_location GHC.IOBase.ioe_description GHC.IOBase.ioe_filename
Warning: System.Console.Haskeline: could not find link destinations for:
System.Console.Haskeline.Monads.MonadState System.Console.Haskeline.Monads.MonadReader System.Console.Haskeline.Term.RunTerm
Documentation created: dist/doc/html/haskeline/index.html
sh gen_contents_index --inplace
haddock: Can't find package.conf as /home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/share/./inplace-datadir/package.conf
make[2]: *** [doc] Error 1
make[2]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4/libraries'
make[1]: *** [stage2] Error 2
make[1]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4'
make: *** [bootstrap2] Error 2
real 43m43.936s
user 36m2.463s
sys 7m22.284s
```
Googling for this error message shows me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538157
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Folks:\r\n\r\nTrying to build from the ghc-6.10.4 source tarball on Ubuntu Hardy i686, the \"make\" step ends with:\r\n\r\n{{{\r\nPreprocessing library terminfo-0.3.1...\r\nRunning Haddock for terminfo-0.3.1...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: rts-1.0\r\nDocumentation created: dist/doc/html/terminfo/index.html\r\nif ifBuildable/ifBuildable /home/zooko/playground/ghc/ghc-6.10.4/packages haskeline; then \\\r\n cd haskeline && /home/zooko/playground/ghc/ghc-6.10.4/libraries/cabal-bin /usr/bin/ghc /home/zooko/playground/ghc/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 haddock --html-location='../$pkg' \\\r\n --with-haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/bin/haddock; \\\r\n fi\r\n./Setup haddock --html-location=../$pkg --with-haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/bin/haddock\r\nPreprocessing library haskeline-0.6.1.5...\r\nRunning Haddock for haskeline-0.6.1.5...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: rts-1.0\r\nWarning: System.Console.Haskeline.History: could not find link destinations for:\r\n System.Console.Haskeline.Monads.MonadState\r\nWarning: System.Console.Haskeline.MonadException: could not find link destinations for:\r\n System.Console.Haskeline.Backend.Terminfo.Draw System.Console.Haskeline.Backend.DumbTerm.DumbTerm GHC.IOBase.IOError GHC.IOBase.ioe_handle GHC.IOBase.ioe_type GHC.IOBase.ioe_location GHC.IOBase.ioe_description GHC.IOBase.ioe_filename\r\nWarning: System.Console.Haskeline: could not find link destinations for:\r\n System.Console.Haskeline.Monads.MonadState System.Console.Haskeline.Monads.MonadReader System.Console.Haskeline.Term.RunTerm\r\nDocumentation created: dist/doc/html/haskeline/index.html\r\nsh gen_contents_index --inplace\r\nhaddock: Can't find package.conf as /home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/share/./inplace-datadir/package.conf\r\nmake[2]: *** [doc] Error 1\r\nmake[2]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4/libraries'\r\nmake[1]: *** [stage2] Error 2\r\nmake[1]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4'\r\nmake: *** [bootstrap2] Error 2\r\n\r\nreal 43m43.936s\r\nuser 36m2.463s\r\nsys 7m22.284s\r\n}}}\r\n\r\nGoogling for this error message shows me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538157","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3598ghc-stage2 binary name confusing for users2019-07-07T19:03:11ZJens Petersenghc-stage2 binary name confusing for usersghc-6.12.0.20091010 create a binary called
$libdir/ghc-6.12.0.20091010/ghc-stage2 and then causing
the program name ghc-stage2 to appear in compiler output
and help etc which is confusing for users and a regression
compared to 6.10.x IMH...ghc-6.12.0.20091010 create a binary called
$libdir/ghc-6.12.0.20091010/ghc-stage2 and then causing
the program name ghc-stage2 to appear in compiler output
and help etc which is confusing for users and a regression
compared to 6.10.x IMHO.
eg
```
$ ghc
ghc-stage2: no input files
Usage: For basic information, try the `--help' option.
```
```
$ ghc --help
Usage:
ghc-stage2 [command-line-options-and-input-files]
To compile and link a complete Haskell program, run the compiler like
so:
ghc-stage2 --make Main
:
Alternatively, ghc-stage2 can be used to compile files individually. Each
input file is guided through (some of the) possible phases of a
compilation:
:
Given the above, here are some TYPICAL invocations of ghc-stage2:
# compile a Haskell module to a .o file, optimising:
% ghc-stage2 -c -O Foo.hs
# link three .o files into an executable called "test":
% ghc-stage2 -o test Foo.o Bar.o Baz.o
# compile a Haskell module to C (a .hc file), using a bigger heap:
% ghc-stage2 -C -H16m Foo.hs
# compile Haskell-produced C (.hc) to assembly language:
% ghc-stage2 -S Foo.hc
```
etc
I think either the output text should be changed
or ghc-stage2 renamed to ghc.6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3599haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css2019-07-07T19:03:10ZJens Petersenhaddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.cssI build rc1 with docs living in /usr/share/doc/ghc/html
but haddock seems to assume $libdir/ghc-$version/html:
```
$ runghc Setup haddock
Running Haddock for zlib-0.5.0.0...
Preprocessing library zlib-0.5.0.0...
Warning: The documentati...I build rc1 with docs living in /usr/share/doc/ghc/html
but haddock seems to assume $libdir/ghc-$version/html:
```
$ runghc Setup haddock
Running Haddock for zlib-0.5.0.0...
Preprocessing library zlib-0.5.0.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: internal Haddock or GHC error: /usr/lib64/ghc-6.12.0.20091010/html/haddock.css: openFile: does not exist (No such file or directory)
$ rpm -ql ghc-doc | grep html/haddock.css
/usr/share/doc/ghc/html/html/haddock.css
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I build rc1 with docs living in /usr/share/doc/ghc/html\r\nbut haddock seems to assume $libdir/ghc-$version/html:\r\n\r\n{{{\r\n$ runghc Setup haddock\r\nRunning Haddock for zlib-0.5.0.0...\r\nPreprocessing library zlib-0.5.0.0...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: ffi-1.0, rts-1.0\r\nhaddock: internal Haddock or GHC error: /usr/lib64/ghc-6.12.0.20091010/html/haddock.css: openFile: does not exist (No such file or directory)\r\n$ rpm -ql ghc-doc | grep html/haddock.css\r\n/usr/share/doc/ghc/html/html/haddock.css\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3600Template Haskell mis-coverting empty list to empty string2021-11-02T09:27:33ZSimon Peyton JonesTemplate Haskell mis-coverting empty list to empty stringAntoine Latter aslatter\@gmail.com writes: the program Demo.hs compiles on 6.10, but not on 6.12rc1. The output --ddump-splices for 6.10:
```
Demo.hs:1:0:
Demo.hs:1:0: Splicing declarations
test
======>
Demo.hs:6:2...Antoine Latter aslatter\@gmail.com writes: the program Demo.hs compiles on 6.10, but not on 6.12rc1. The output --ddump-splices for 6.10:
```
Demo.hs:1:0:
Demo.hs:1:0: Splicing declarations
test
======>
Demo.hs:6:2-5
myFunction[aLQ] = Demo2.testFun []
Ok, modules loaded: Demo2, Main.
```
In 6.12rc1:
```
Demo.hs:1:0:
Demo.hs:1:0: Splicing declarations
test
======>
Demo.hs:6:2-5
myFunction[aNX] = testFun ""
Demo.hs:6:2:
Couldn't match expected type `[Char]' against inferred type `Char'
Expected type: [String]
Inferred type: [Char]
In the first argument of `testFun', namely `""'
In the expression: testFun ""
Failed, modules loaded: Demo2.
```
The code is short:
```
---------- Demo.hs ---------------
{-# LANGUAGE TemplateHaskell #-}
module Demo where
import Demo2
$(test)
---------- Demo2.hs ---------------
{-# LANGUAGE TemplateHaskell #-}
module Demo2 where
import Language.Haskell.TH
test :: Q [Dec]
test = do
let args = [] :: [String]
body = [| testFun args |]
decNm <- newName "myFunction"
(:[]) `fmap` funD decNm [clause [] (normalB body) []]
testFun :: [String] -> String
testFun _ = "hello"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.4 |
| 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":"Template Haskell mis-coverting empty list to empty string","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Antoine Latter aslatter@gmail.com writes: the program Demo.hs compiles on 6.10, but not on 6.12rc1. The output --ddump-splices for 6.10:\r\n{{{\r\nDemo.hs:1:0:\r\n Demo.hs:1:0: Splicing declarations\r\n test\r\n ======>\r\n Demo.hs:6:2-5\r\n myFunction[aLQ] = Demo2.testFun []\r\nOk, modules loaded: Demo2, Main.\r\n}}}\r\nIn 6.12rc1:\r\n{{{\r\nDemo.hs:1:0:\r\n Demo.hs:1:0: Splicing declarations\r\n test\r\n ======>\r\n Demo.hs:6:2-5\r\n myFunction[aNX] = testFun \"\"\r\n\r\nDemo.hs:6:2:\r\n Couldn't match expected type `[Char]' against inferred type `Char'\r\n Expected type: [String]\r\n Inferred type: [Char]\r\n In the first argument of `testFun', namely `\"\"'\r\n In the expression: testFun \"\"\r\nFailed, modules loaded: Demo2.\r\n}}}\r\nThe code is short:\r\n{{{\r\n---------- Demo.hs ---------------\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Demo where\r\nimport Demo2\r\n$(test)\r\n\r\n---------- Demo2.hs ---------------\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Demo2 where\r\n\r\nimport Language.Haskell.TH\r\n\r\ntest :: Q [Dec]\r\ntest = do\r\n let args = [] :: [String]\r\n body = [| testFun args |]\r\n decNm <- newName \"myFunction\"\r\n (:[]) `fmap` funD decNm [clause [] (normalB body) []]\r\n\r\ntestFun :: [String] -> String\r\ntestFun _ = \"hello\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/314#line pragmas not respected inside nested comments2019-07-07T19:18:30Znobody#line pragmas not respected inside nested comments```
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper...```
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
<jlouis@mongers.org>
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * "string"
main = putStrLn $ show c
----
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * "string"
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx "filename"
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen <jlouis@mongers.org>
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/3602cabal-install bootstrap script emits error message with no detail2019-07-07T19:03:10Zzookocabal-install bootstrap script emits error message with no detailI am trying to install cabal-install, and it ended with:
```
Sorry, something went wrong.
```
It would have been helpful if it had instead said
```
Sorry, the 'cabal' executable was not successfully installed into '/usr/local/stow/gh...I am trying to install cabal-install, and it ended with:
```
Sorry, something went wrong.
```
It would have been helpful if it had instead said
```
Sorry, the 'cabal' executable was not successfully installed into '/usr/local/stow/ghc-6.10.4-from-srctarball/bin/'.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cabal-install bootstrap script emits error message with no detail","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to install cabal-install, and it ended with:\r\n\r\n{{{\r\nSorry, something went wrong.\r\n}}}\r\n\r\nIt would have been helpful if it had instead said\r\n\r\n{{{\r\nSorry, the 'cabal' executable was not successfully installed into '/usr/local/stow/ghc-6.10.4-from-srctarball/bin/'.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3603cabal-install bootstrap script respects PREFIX inconsistently, fails2019-07-07T19:03:09Zzookocabal-install bootstrap script respects PREFIX inconsistently, failsThe bootstrap.sh script that comes with cabal-install is documented as respecting a PREFIX environment variable, but if you pass one it will ignore it during the installation of the executable:
```
./Setup configure --user "--prefix=$...The bootstrap.sh script that comes with cabal-install is documented as respecting a PREFIX environment variable, but if you pass one it will ignore it during the installation of the executable:
```
./Setup configure --user "--prefix=${HOME}/.cabal" \
--with-compiler=${GHC} --with-hc-pkg=${GHC_PKG} \
${EXTRA_CONFIGURE_OPTS} ${VERBOSE} \
|| die "Configuring the ${PKG} package failed"
```
But then respect it during the post-install self-test:
```
CABAL_BIN="$PREFIX/bin"
if [ -x "$CABAL_BIN/cabal" ]
then
```
1. ..
```
else
echo "Sorry, something went wrong."
fi
```
Which means that it always emits the "Sorry, something went wrong." message and not the success message when PREFIX was specified. Also that it installed into the wrong directory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"cabal-install bootstrap script respects PREFIX inconsistently, fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The bootstrap.sh script that comes with cabal-install is documented as respecting a PREFIX environment variable, but if you pass one it will ignore it during the installation of the executable:\r\n\r\n{{{\r\n ./Setup configure --user \"--prefix=${HOME}/.cabal\" \\\r\n --with-compiler=${GHC} --with-hc-pkg=${GHC_PKG} \\\r\n ${EXTRA_CONFIGURE_OPTS} ${VERBOSE} \\\r\n || die \"Configuring the ${PKG} package failed\"\r\n}}}\r\n\r\nBut then respect it during the post-install self-test:\r\n\r\n{{{\r\nCABAL_BIN=\"$PREFIX/bin\"\r\nif [ -x \"$CABAL_BIN/cabal\" ]\r\nthen\r\n}}}\r\n...\r\n{{{\r\nelse\r\n echo \"Sorry, something went wrong.\"\r\nfi\r\n}}}\r\n\r\nWhich means that it always emits the \"Sorry, something went wrong.\" message and not the success message when PREFIX was specified. Also that it installed into the wrong directory.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3604Use of template-haskell is broken with shared libraries2019-07-07T19:03:09ZguestUse of template-haskell is broken with shared librariesConsider the following program:
TH.hs:
```
{-# LANGUAGE TemplateHaskell #-}
module TH where
import Language.Haskell.TH
spliceMe = [| (\xs -> tail xs ++ init xs) |]
```
Library.hs
```
{-# LANGUAGE TemplateHaskell #-}
module Library ...Consider the following program:
TH.hs:
```
{-# LANGUAGE TemplateHaskell #-}
module TH where
import Language.Haskell.TH
spliceMe = [| (\xs -> tail xs ++ init xs) |]
```
Library.hs
```
{-# LANGUAGE TemplateHaskell #-}
module Library where
import TH
main = print ($(spliceMe) [1, 2])
```
Build it like so:
```
ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/a
utogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e
12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC
```
And observe the wonderful error:
```
Creating dist/build (and its parents)
Creating dist/build/autogen (and its parents)
Preprocessing library foo-0.2.3...
Building foo-0.2.3...
Building library...
Creating dist/build (and its parents)
/home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library
/home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC
[2 of 2] Compiling Library ( Library.hs, dist/build/Library.dyn_o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
ghc-stage2: dist/build/TH.dyn_o: unknown symbol `__stginit_base_Prelude_dyn'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use of template-haskell is broken with shared libraries","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","ndmitchell@gmail.com"],"type":"Bug","description":"Consider the following program:\r\n\r\nTH.hs:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule TH where\r\n\r\nimport Language.Haskell.TH\r\n\r\nspliceMe = [| (\\xs -> tail xs ++ init xs) |]\r\n}}}\r\n\r\nLibrary.hs\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Library where\r\n\r\nimport TH\r\n\r\nmain = print ($(spliceMe) [1, 2])\r\n}}}\r\n\r\nBuild it like so:\r\n\r\n{{{\r\nghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/a\r\nutogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e\r\n12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC\r\n}}}\r\n\r\nAnd observe the wonderful error:\r\n\r\n{{{\r\nCreating dist/build (and its parents)\r\nCreating dist/build/autogen (and its parents)\r\nPreprocessing library foo-0.2.3...\r\nBuilding foo-0.2.3...\r\nBuilding library...\r\nCreating dist/build (and its parents)\r\n/home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library\r\n/home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template-haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC\r\n[2 of 2] Compiling Library ( Library.hs, dist/build/Library.dyn_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.3.0.0 ... linking ... done.\r\nLoading package containers-0.3.0.0 ... linking ... done.\r\nLoading package pretty-1.0.1.1 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nghc-stage2: dist/build/TH.dyn_o: unknown symbol `__stginit_base_Prelude_dyn'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3605Dll's freeze with -threaded2019-07-07T19:03:09ZNeil MitchellDll's freeze with -threadedAttached are two source files (one .c, one .hs), which are compiled (using mk.sh) into DsoHsDemo.dll. When this library is loaded, using the following C snippet:
```
int main(int argc, char* argv[])
{
printf("Started LoadLibrary\n")...Attached are two source files (one .c, one .hs), which are compiled (using mk.sh) into DsoHsDemo.dll. When this library is loaded, using the following C snippet:
```
int main(int argc, char* argv[])
{
printf("Started LoadLibrary\n");
LoadLibrary("DsoHsDemo.dll");
printf("Finished LoadLibrary\n");
}
```
The program freezes:
```
$ ./mk.sh && ./CSnippet
The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091010
Creating library file: DsoHsDemo.dll.a
Started LoadLibrary
pre hs_init
<program freezes>
```
The freeze only occurs when the dll is linked with -threaded, and happens within either startupHaskell, or (if you call hs_init/hs_add_root instead) within hs_add_root. This happens with GHC 6.10.4 and 6.12rc1 on Windows XP.
This bug appears to make it impossible to successfully build a DLL for multithreaded use.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Dll's freeze with -threaded","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Attached are two source files (one .c, one .hs), which are compiled (using mk.sh) into DsoHsDemo.dll. When this library is loaded, using the following C snippet:\r\n\r\n{{{\r\nint main(int argc, char* argv[])\r\n{\r\n printf(\"Started LoadLibrary\\n\");\r\n LoadLibrary(\"DsoHsDemo.dll\");\r\n printf(\"Finished LoadLibrary\\n\");\r\n}\r\n}}}\r\n\r\nThe program freezes:\r\n\r\n{{{\r\n$ ./mk.sh && ./CSnippet\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.0.20091010\r\nCreating library file: DsoHsDemo.dll.a\r\nStarted LoadLibrary\r\npre hs_init\r\n<program freezes>\r\n}}}\r\n\r\nThe freeze only occurs when the dll is linked with -threaded, and happens within either startupHaskell, or (if you call hs_init/hs_add_root instead) within hs_add_root. This happens with GHC 6.10.4 and 6.12rc1 on Windows XP.\r\n\r\nThis bug appears to make it impossible to successfully build a DLL for multithreaded use.","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3607index variable for array traversal worker function is not unboxed2019-07-07T19:03:09Zblarsenindex variable for array traversal worker function is not unboxedSee also [http://hackage.haskell.org/trac/ghc/ticket/3606](http://hackage.haskell.org/trac/ghc/ticket/3606).
In an attempt to write a better comparison function for unboxed arrays, I wrote the following code:
```
{-# LANGUAGE BangPatte...See also [http://hackage.haskell.org/trac/ghc/ticket/3606](http://hackage.haskell.org/trac/ghc/ticket/3606).
In an attempt to write a better comparison function for unboxed arrays, I wrote the following code:
```
{-# LANGUAGE BangPatterns #-}
{-# OPTIONS -Wall #-}
module BadArrayCmp where
import Data.Array.Base
import Data.Array.Unboxed
cmpArrays :: (IArray a1 e, IArray a2 e, Ix i, Ord e)
=> a1 i e
-> a2 i e
-> Ordering
cmpArrays a1 a2 = case compare (bounds a1) (bounds a2) of
LT -> LT
EQ -> go 0
GT -> GT
where
iMaxPlusOne :: Int
iMaxPlusOne = numElements a1
go :: Int -> Ordering
go !i = if i == iMaxPlusOne
then EQ
else case compare (unsafeAt a1 i) (unsafeAt a2 i) of
LT -> LT
EQ -> go (i+1)
GT -> GT
{-# INLINE cmpArrays #-}
```
I have attached this code as a test case.
Examining the core generated by ghc 6.10.4 using -O2 on Ubuntu 9.04 x86_64, the code generated for 'go' uses a boxed Int for the index variable.
Because of this boxed int (and perhaps other problems in the generated code, I'm not sure), in a particular application of mine, \~60% of the total time is used and %80% of the total allocation is done in 'cmpArrays'. (These percentages obtained via profiling.)
I imagine that 'go' _could_ be compiled so that the only potential allocation done is for the Ordering value at the end. Using a boxed index variable instead of something kept in a register really kills performance!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"index variable for array traversal worker function is not unboxed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["Ord","array,","unboxed"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See also [http://hackage.haskell.org/trac/ghc/ticket/3606].\r\n\r\nIn an attempt to write a better comparison function for unboxed arrays, I wrote the following code:\r\n\r\n\r\n{{{\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# OPTIONS -Wall #-}\r\n\r\nmodule BadArrayCmp where\r\n\r\nimport Data.Array.Base\r\nimport Data.Array.Unboxed\r\n\r\n\r\ncmpArrays :: (IArray a1 e, IArray a2 e, Ix i, Ord e)\r\n => a1 i e\r\n -> a2 i e\r\n -> Ordering\r\ncmpArrays a1 a2 = case compare (bounds a1) (bounds a2) of\r\n LT -> LT\r\n EQ -> go 0\r\n GT -> GT\r\n where\r\n iMaxPlusOne :: Int\r\n iMaxPlusOne = numElements a1\r\n \r\n go :: Int -> Ordering\r\n go !i = if i == iMaxPlusOne\r\n then EQ\r\n else case compare (unsafeAt a1 i) (unsafeAt a2 i) of\r\n LT -> LT\r\n EQ -> go (i+1)\r\n GT -> GT\r\n{-# INLINE cmpArrays #-}\r\n}}}\r\n\r\nI have attached this code as a test case.\r\n\r\nExamining the core generated by ghc 6.10.4 using -O2 on Ubuntu 9.04 x86_64, the code generated for 'go' uses a boxed Int for the index variable.\r\n\r\nBecause of this boxed int (and perhaps other problems in the generated code, I'm not sure), in a particular application of mine, ~60% of the total time is used and %80% of the total allocation is done in 'cmpArrays'. (These percentages obtained via profiling.)\r\n\r\nI imagine that 'go' _could_ be compiled so that the only potential allocation done is for the Ordering value at the end. Using a boxed index variable instead of something kept in a register really kills performance!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3608Build the ghc-bin package in the standard way2019-07-07T19:03:08ZIan Lynagh <igloo@earth.li>Build the ghc-bin package in the standard wayIn `ghc/ghc.mk` we have
```
# ToDo
ghc_USES_CABAL = NO
```
which I think is responsible for these (non-fatal) errors during the build:
```
"inplace/bin/mkdependC" -f ghc/stage1/build/.depend.tmp -- -Wall -Werror -- ghc/h...In `ghc/ghc.mk` we have
```
# ToDo
ghc_USES_CABAL = NO
```
which I think is responsible for these (non-fatal) errors during the build:
```
"inplace/bin/mkdependC" -f ghc/stage1/build/.depend.tmp -- -Wall -Werror -- ghc/hschooks.c
ghc/hschooks.c:7:17: error: Rts.h: No such file or directory
ghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory
ghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory
ghc/hschooks.c:7:17: error: Rts.h: No such file or directory
ghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory
ghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory
```
We should build ghc-bin in the standard way, without `ghc_USES_CABAL = NO`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Build the ghc-bin package in the standard way","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"In `ghc/ghc.mk` we have\r\n{{{\r\n# ToDo\r\nghc_USES_CABAL = NO\r\n}}}\r\nwhich I think is responsible for these (non-fatal) errors during the build:\r\n{{{\r\n\"inplace/bin/mkdependC\" -f ghc/stage1/build/.depend.tmp -- -Wall -Werror -- ghc/hschooks.c\r\nghc/hschooks.c:7:17: error: Rts.h: No such file or directory\r\nghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory\r\nghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory\r\nghc/hschooks.c:7:17: error: Rts.h: No such file or directory\r\nghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory\r\nghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory\r\n}}}\r\n\r\nWe should build ghc-bin in the standard way, without `ghc_USES_CABAL = NO`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3609ar.exe: Bad file number2019-07-07T19:03:08ZSimon Peyton Jonesar.exe: Bad file numberJohn Earle writes:
- Hardware. Operating System: 32-Bit Edition of Windows Vista with Service Pack 2 applied. CPU: Intel Pentium 4
- Software. MinGW 5.1.6 which is the current stable release. MinGW 5.1.6 does not install the latest vers...John Earle writes:
- Hardware. Operating System: 32-Bit Edition of Windows Vista with Service Pack 2 applied. CPU: Intel Pentium 4
- Software. MinGW 5.1.6 which is the current stable release. MinGW 5.1.6 does not install the latest version of gcc, however. It installs gcc 3.4.5.
- MSYS 1.0.11 which is the current version of MSYS. It installs GNU Make 3.81 among other things. The version of MSYS available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows is 1.0.10.
- msysDTK-1.0.1 which is the current stable release and is the same version available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.
- Preexisting version of GHC is 6.10.4 which is the current stable release of GHC which was used to build GHC 6.10.4 from source.
- Those additional Haskell tools that were needed were downloaded from http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.
- !ActiveState Python 2.6.3.7 (current is 3.1.1.2, but is not appropriate).
A build script along with a build procedure was prepared. These results do not reflect what was needed to reach this point. Many hours of work were required to achieve these results. These results were not the results that were achieved initially. The directions provided for how to build GHC from source proved insufficient. A workaround which was not described is needed.
The build script runs make, the fast test suite, and make install. The documentation is not built. In order for the test suite to complete Windows Firewall had to be turned off which was something that was also not specified in the directions. Where the test suite needed to be unpacked to or should be named was furthermore not specified. These issues among others make the build process very expensive. Once you have all your ducks in the row, it is easier going, but that is how it usually is in life.
Before proceeding remove the xargs shell script from the path. The xargs shell script is the workaround described above.
Wait 1 hour and 1 minute.
```
make -C libraries all
make[2]: Entering directory `/Z/dev/ghc-6.10.4/src/libraries/ghc-prim'
(echo dist/build/cbits/longlong.o `find dist/build -name "*_stub.o" -print`; find dist/build/GHC/Bool_split dist/build/GHC/Generics_split dist/build/GHC/Ordering_split dist/build/GHC/PrimopWrappers_split dist/build/GHC/IntWord32_split dist/build/GHC/IntWord64_split dist/build/GHC/Tuple_split dist/build/GHC/Types_split dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/MinGW/bin/ar.exe q dist/build/libHSghc-prim-0.1.0.0.a
xargs: c:/MinGW/bin/ar.exe: Bad file number
make[2]: *** [dist/build/libHSghc-prim-0.1.0.0.a] Error 126
```
In prior attempts I did not receive this error so early. Notice that the version of ar is c:/MinGW/bin/ar.exe. In http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows c:/MinGW/bin/ occurs in the path before the preexisting instance of GHC just as is the case here. On a previous attempts I have gotten "xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Argument list too long" and "xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Bad file number". The path to ar appeared hard coded which is confusing.
I moved the xargs shell script so that it appeared front most in the path once more and resumed the build process from where it left off.
Wait 3 hours and 5 minutes. The build process completed successfully.
At 2 hours and 42 minutes later after the build process was resumed an empty null file is created in the "Z:\\dev" parent directory which an immediate child of the root directory. Regardless of how deeply nested the project directory is, it always appears in the dev directory.
If all goes well the build process has consistently taken 4 hours and 6 minutes.
The day before the build was completed with the workaround applied prior to carrying out the procedure. Today, when the workaround was applied only once an error was encountered and this resulted in additional unexpected test suite failure, namely: conc049(normal). These were yesterdays results:
```
OVERALL SUMMARY for test run started at The current date is: 2009.10.22
Enter the new date: (yy-mm-dd)
2403 total tests, which gave rise to
12815 test cases, of which
0 caused framework failures
10766 were skipped
1955 expected passes
76 expected failures
1 unexpected passes
17 unexpected failures
Unexpected passes:
system001(normal)
Unexpected failures:
2816(ghci)
DoParamM(normal)
cabal01(normal)
drvfail006(normal)
drvfail008(normal)
getPermissions001(normal,normal)
ghci028(ghci)
mod133(normal)
net001(normal)
signals004(normal)
tc183(normal)
tc217(normal)
tc220(normal)
tc223(normal)
tc232(normal)
tcfail126(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ar.exe: Bad file number","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"John Earle writes:\r\n\r\n * Hardware. Operating System: 32-Bit Edition of Windows Vista with Service Pack 2 applied. CPU: Intel Pentium 4\r\n \r\n * Software. MinGW 5.1.6 which is the current stable release. MinGW 5.1.6 does not install the latest version of gcc, however. It installs gcc 3.4.5.\r\n \r\n * MSYS 1.0.11 which is the current version of MSYS. It installs GNU Make 3.81 among other things. The version of MSYS available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows is 1.0.10.\r\n \r\n * msysDTK-1.0.1 which is the current stable release and is the same version available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.\r\n\r\n * Preexisting version of GHC is 6.10.4 which is the current stable release of GHC which was used to build GHC 6.10.4 from source.\r\n \r\n * Those additional Haskell tools that were needed were downloaded from http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.\r\n \r\n * !ActiveState Python 2.6.3.7 (current is 3.1.1.2, but is not appropriate).\r\n \r\nA build script along with a build procedure was prepared. These results do not reflect what was needed to reach this point. Many hours of work were required to achieve these results. These results were not the results that were achieved initially. The directions provided for how to build GHC from source proved insufficient. A workaround which was not described is needed.\r\n \r\nThe build script runs make, the fast test suite, and make install. The documentation is not built. In order for the test suite to complete Windows Firewall had to be turned off which was something that was also not specified in the directions. Where the test suite needed to be unpacked to or should be named was furthermore not specified. These issues among others make the build process very expensive. Once you have all your ducks in the row, it is easier going, but that is how it usually is in life.\r\n \r\nBefore proceeding remove the xargs shell script from the path. The xargs shell script is the workaround described above.\r\n\r\nWait 1 hour and 1 minute.\r\n{{{\r\nmake -C libraries all\r\n \r\nmake[2]: Entering directory `/Z/dev/ghc-6.10.4/src/libraries/ghc-prim'\r\n \r\n(echo dist/build/cbits/longlong.o `find dist/build -name \"*_stub.o\" -print`; find dist/build/GHC/Bool_split dist/build/GHC/Generics_split dist/build/GHC/Ordering_split dist/build/GHC/PrimopWrappers_split dist/build/GHC/IntWord32_split dist/build/GHC/IntWord64_split dist/build/GHC/Tuple_split dist/build/GHC/Types_split dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/MinGW/bin/ar.exe q dist/build/libHSghc-prim-0.1.0.0.a\r\nxargs: c:/MinGW/bin/ar.exe: Bad file number\r\nmake[2]: *** [dist/build/libHSghc-prim-0.1.0.0.a] Error 126\r\n}}}\r\nIn prior attempts I did not receive this error so early. Notice that the version of ar is c:/MinGW/bin/ar.exe. In http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows c:/MinGW/bin/ occurs in the path before the preexisting instance of GHC just as is the case here. On a previous attempts I have gotten \"xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Argument list too long\" and \"xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Bad file number\". The path to ar appeared hard coded which is confusing.\r\n \r\nI moved the xargs shell script so that it appeared front most in the path once more and resumed the build process from where it left off. \r\n \r\nWait 3 hours and 5 minutes. The build process completed successfully. \r\n \r\nAt 2 hours and 42 minutes later after the build process was resumed an empty null file is created in the \"Z:\\dev\" parent directory which an immediate child of the root directory. Regardless of how deeply nested the project directory is, it always appears in the dev directory.\r\n \r\nIf all goes well the build process has consistently taken 4 hours and 6 minutes.\r\n \r\nThe day before the build was completed with the workaround applied prior to carrying out the procedure. Today, when the workaround was applied only once an error was encountered and this resulted in additional unexpected test suite failure, namely: conc049(normal). These were yesterdays results:\r\n{{{\r\nOVERALL SUMMARY for test run started at The current date is: 2009.10.22 \r\nEnter the new date: (yy-mm-dd) \r\n 2403 total tests, which gave rise to\r\n 12815 test cases, of which\r\n 0 caused framework failures\r\n 10766 were skipped\r\n \r\n 1955 expected passes\r\n 76 expected failures\r\n 1 unexpected passes\r\n 17 unexpected failures\r\n \r\nUnexpected passes:\r\n system001(normal)\r\n \r\nUnexpected failures:\r\n 2816(ghci)\r\n DoParamM(normal)\r\n cabal01(normal)\r\n drvfail006(normal)\r\n drvfail008(normal)\r\n getPermissions001(normal,normal)\r\n ghci028(ghci)\r\n mod133(normal)\r\n net001(normal)\r\n signals004(normal)\r\n tc183(normal)\r\n tc217(normal)\r\n tc220(normal)\r\n tc223(normal)\r\n tc232(normal)\r\n tcfail126(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3610Installer has hard-coded path /usr/bin/strip2019-07-07T19:03:08ZYitzGaleInstaller has hard-coded path /usr/bin/stripOn some systems, strip may not be located in /usr/bin.
And even if it is, that might not be the version of strip
we need to use, e.g., in a virtual hosting environment.
See, for example,
[this blog post](http://substack.net/posts/ea85c2...On some systems, strip may not be located in /usr/bin.
And even if it is, that might not be the version of strip
we need to use, e.g., in a virtual hosting environment.
See, for example,
[this blog post](http://substack.net/posts/ea85c2/Happstack-on-Dreamhost-Notes)
about installing GHC on Dreamhost.
It seems that GHC ought to locate strip using $PATH,
or some other mechanism that can be configured.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Installer has hard-coded path /usr/bin/strip","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On some systems, strip may not be located in /usr/bin.\r\nAnd even if it is, that might not be the version of strip\r\nwe need to use, e.g., in a virtual hosting environment.\r\n\r\nSee, for example,\r\n[http://substack.net/posts/ea85c2/Happstack-on-Dreamhost-Notes this blog post]\r\nabout installing GHC on Dreamhost.\r\n\r\nIt seems that GHC ought to locate strip using $PATH,\r\nor some other mechanism that can be configured.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3611X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala2019-07-07T19:03:08ZneuroserveX11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koalatoens\@wintermute:\~/src/X11-xft-0.3$ runhaskell Setup.lhs build
Preprocessing library X11-xft-0.3...
Building X11-xft-0.3...
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for ...toens\@wintermute:\~/src/X11-xft-0.3$ runhaskell Setup.lhs build
Preprocessing library X11-xft-0.3...
Building X11-xft-0.3...
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-linux):
> Prelude.chr: bad argument
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
I don't know really much about haskell. I just wanted to compile X11 and X11-xft for xmonad-0.9.
I'm ready to answer any questions about this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"toens@wintermute:~/src/X11-xft-0.3$ runhaskell Setup.lhs build\r\nPreprocessing library X11-xft-0.3...\r\nBuilding X11-xft-0.3...\r\nBinary: Int64 truncated to fit in 32 bit Int\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-linux):\r\n Prelude.chr: bad argument\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nI don't know really much about haskell. I just wanted to compile X11 and X11-xft for xmonad-0.9.\r\nI'm ready to answer any questions about this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3612Installing the binary tarball requires build tools (binutils, gcc, etc.)2019-07-07T19:03:08ZmatthijsInstalling the binary tarball requires build tools (binutils, gcc, etc.)When installing the binary tarball (e.g., http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2), you need to run `./configure && make install`. However, configure does the full build-time set of checks, complain...When installing the binary tarball (e.g., http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2), you need to run `./configure && make install`. However, configure does the full build-time set of checks, complaining about the lack of binutils, gcc, and whatnot.
I'm trying to build a small system which doesn't have any build tools, and I'd rather not install them just for satisfying configure :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Installing the binary tarball requires build tools (binutils, gcc, etc.)","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When installing the binary tarball (e.g., http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2), you need to run {{{./configure && make install}}}. However, configure does the full build-time set of checks, complaining about the lack of binutils, gcc, and whatnot.\r\n\r\nI'm trying to build a small system which doesn't have any build tools, and I'd rather not install them just for satisfying configure :-)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3613Better error messages for do-notation2019-07-07T19:03:07ZSimon Peyton JonesBetter error messages for do-notationC Rodrigues \[red5_2\@hotmail.com\] writes: In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe ().
```
> import Control.Monad
>
> foo :: Maybe ()
> foo = retur...C Rodrigues \[red5_2\@hotmail.com\] writes: In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe ().
```
> import Control.Monad
>
> foo :: Maybe ()
> foo = return ()
>
> bar :: IO ()
> bar = return ()
>
> fun1 = let fooThen m = foo>> m
> in fooThen (bar>> undefined)
>
> fun2 = let fooThen m = foo>> m
> in fooThen (do {bar; undefined})
```
With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped.
* fun1 produces the error message:
{{{
Couldn't match expected type `Maybe a' against inferred type `IO ()'
In the first argument of `(\>\>=)', namely `bar'
}}}
* fun2 produces the error message:
{{{
Couldn't match expected type `IO ()' against inferred type \`Maybe ()'
In a stmt of a 'do' expression: bar
}}}
It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO ().
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | red5_2@hotmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Better error messages for do-notation","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["red5_2@hotmail.com"],"type":"Bug","description":"C Rodrigues [red5_2@hotmail.com] writes: In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe ().\r\n{{{\r\n> import Control.Monad\r\n>\r\n> foo :: Maybe ()\r\n> foo = return ()\r\n>\r\n> bar :: IO ()\r\n> bar = return ()\r\n>\r\n> fun1 = let fooThen m = foo>> m\r\n> in fooThen (bar>> undefined)\r\n>\r\n> fun2 = let fooThen m = foo>> m\r\n> in fooThen (do {bar; undefined})\r\n}}}\r\nWith ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped.\r\n * fun1 produces the error message:\r\n{{{\r\nCouldn't match expected type `Maybe a' against inferred type `IO ()'\r\nIn the first argument of `(>>=)', namely `bar'\r\n}}}\r\n * fun2 produces the error message:\r\n{{{\r\nCouldn't match expected type `IO ()' against inferred type `Maybe ()'\r\nIn a stmt of a 'do' expression: bar\r\n}}}\r\nIt's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO ().\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3614Cabal file parser can't handle colon in description2019-07-07T19:03:07ZdsfCabal file parser can't handle colon in descriptionThe description field of the cabal file in the haskell-mtl package currently in debian sid contains an url with a colon, which leads to this error:
```
ghc-pkg: 13: unrecognised field or section: "(<http://web.cecs.pdx.edu/~mpj/pubs/s...The description field of the cabal file in the haskell-mtl package currently in debian sid contains an url with a colon, which leads to this error:
```
ghc-pkg: 13: unrecognised field or section: "(<http://web.cecs.pdx.edu/~mpj/pubs/springschool.html>),"
```
This comes from `Cabal.Distribution.ParseUtils`.6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3615GHCi doesn't allow the use of imported data contructors2021-07-15T19:56:21ZGhost UserGHCi doesn't allow the use of imported data contructorsThere are two modules in this simplified scenario. The main module is Main.hs and contains the following three lines of code.
```
module Main where
import Imp (D(..))
main = print D1
```
Module Imp contains a single data type definitio...There are two modules in this simplified scenario. The main module is Main.hs and contains the following three lines of code.
```
module Main where
import Imp (D(..))
main = print D1
```
Module Imp contains a single data type definition:
```
module Imp where
data D = D1 | D2 deriving Show
```
Now, when I compile Main everything works. GHCi doesn't complain when it loads the main module either, but it doesn't allow me to construct D on its command line. This makes no sense to me.
```
$ ghc --make Main.hs
[1 of 2] Compiling Imp ( Imp.hs, Imp.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
D1
$ ghci Main.hs
GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main, Imp.
Prelude Main> D1
<interactive>:1:0: Not in scope: data constructor `D1'
Prelude Main>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"GHCi doesn't allow the use of imported data contructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are two modules in this simplified scenario. The main module is Main.hs and contains the following three lines of code.\r\n\r\n{{{\r\nmodule Main where\r\nimport Imp (D(..))\r\nmain = print D1\r\n}}}\r\n\r\nModule Imp contains a single data type definition:\r\n\r\n{{{\r\nmodule Imp where\r\ndata D = D1 | D2 deriving Show\r\n}}}\r\n\r\nNow, when I compile Main everything works. GHCi doesn't complain when it loads the main module either, but it doesn't allow me to construct D on its command line. This makes no sense to me.\r\n\r\n{{{\r\n$ ghc --make Main.hs \r\n[1 of 2] Compiling Imp ( Imp.hs, Imp.o )\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main \r\nD1\r\n$ ghci Main.hs\r\nGHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nOk, modules loaded: Main, Imp.\r\nPrelude Main> D1\r\n\r\n<interactive>:1:0: Not in scope: data constructor `D1'\r\nPrelude Main> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3616ghci crash from :l2019-07-07T19:03:07Zeflisterghci crash from :li got the following from trying to :l this file
```
Prelude> :l tmp.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC ...i got the following from trying to :l this file
```
Prelude> :l tmp.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/3617There is no -debug runtime in 6.12 RC12019-07-07T19:03:07ZguestThere is no -debug runtime in 6.12 RC1```
$ cat Hello.hs
module Main where
main = print "Hello world"
```
```
$ ghc -debug --make Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o )
Linking Hello ...
/usr/bin/ld: cannot find -lHSrts_debug
collect2: ld return...```
$ cat Hello.hs
module Main where
main = print "Hello world"
```
```
$ ghc -debug --make Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o )
Linking Hello ...
/usr/bin/ld: cannot find -lHSrts_debug
collect2: ld returned 1 exit status
```
Interestingly there is a debug runtime .so, but no .a. This seems like an oversight.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"There is no -debug runtime in 6.12 RC1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","ndmitchell@gmail.com"],"type":"Bug","description":"{{{\r\n$ cat Hello.hs\r\nmodule Main where\r\n\r\nmain = print \"Hello world\"\r\n}}}\r\n\r\n{{{\r\n$ ghc -debug --make Hello.hs\r\n[1 of 1] Compiling Main ( Hello.hs, Hello.o )\r\nLinking Hello ...\r\n/usr/bin/ld: cannot find -lHSrts_debug\r\ncollect2: ld returned 1 exit status\r\n}}}\r\n\r\nInterestingly there is a debug runtime .so, but no .a. This seems like an oversight.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3618memory-leak detector in +RTS -DS fails to track allocations in constructors2019-07-07T19:03:06Zguestmemory-leak detector in +RTS -DS fails to track allocations in constructors```
$ cat Hello.hs
module Main where
main = print "Hello world"
```
```
$ ghc -debug -dynamic --make Hello.hs && ./Hello +RTS -DS
Linking Hello ...
"Hello world"
Warning: Freeing non-allocated memory at 0x1ff87850
Warning: Freeing non...```
$ cat Hello.hs
module Main where
main = print "Hello world"
```
```
$ ghc -debug -dynamic --make Hello.hs && ./Hello +RTS -DS
Linking Hello ...
"Hello world"
Warning: Freeing non-allocated memory at 0x1ff87850
Warning: Freeing non-allocated memory at 0x1ff85820
Warning: Freeing non-allocated memory at 0x1ff85010
Warning: Freeing non-allocated memory at 0x1ff89860
Warning: Freeing non-allocated memory at 0x1ff8b860
Warning: 192 bytes at 0x1ff9b920 still allocated at shutdown
Warning: 2048 bytes at 0x1ff8ef50 still allocated at shutdown
Warning: 48 bytes at 0x1ff8eef0 still allocated at shutdown
Warning: 2048 bytes at 0x1ff8e6c0 still allocated at shutdown
Warning: 48 bytes at 0x1ff8e660 still allocated at shutdown
Warning: 2048 bytes at 0x1ff8de30 still allocated at shutdown
Warning: 48 bytes at 0x1ff8ddd0 still allocated at shutdown
Warning: 4100 bytes at 0x1ff8cca0 still allocated at shutdown
Warning: 16 bytes at 0x1ff8c980 still allocated at shutdown
Warning: 16 bytes at 0x1ff8c940 still allocated at shutdown
Warning: 4 bytes at 0x1ff8c880 still allocated at shutdown
Warning: 5 bytes at 0x1ff8c840 still allocated at shutdown
Warning: 8 bytes at 0x1ff8c800 still allocated at shutdown
Warning: 32 bytes at 0x1ff8c7b0 still allocated at shutdown
```
Note the freeing of non-allocated memory. This is because "base" contains a foreign export of forkOS_entry. Foreign exports are desugared to uses of __attribute__((constructor)) which call getStablePtr (in this case initializing stginit_export_base_ControlziConcurrent_zdfforkOSzuentryzua1bd). On our system this initializer is being run when libHSbase-4.2.0.0-ghc6.12.0.20091010.so gets loaded, which is before the runtime is actually initialized.
This leads to a call to allocHashTable (from initStablePtrTable) which allocates memory. This allocation is recorded in the allocs linked list but when the runtime is initialized initAllocator gets called which overwrites that entry. Hence when we come to free that hash table we free a pointer which is not in the allocs list and get the warning.
I don't get this message with static linking on 6.10 - I can't check 6.12 because there is no static debug runtime for 6.12 RC1 by default. This makes me suspect that this is a peculiarity of shared object initialization, and the call to getStablePtr will happen more lazily with static linking (probably on the first reference to a function in base), such that it comes after RTS initialization is complete.
I observed this behaviour when trying to use -DS to isolate a segfault in Haskell code in a very large program using -dynamic and Haskell shared libraries. I'm not sure if this problem is actually causing my segfault, but it certainly feels like it has the potential to do so, especially as I tend to get my segfaults from Evac.c, which could be affected by the stable ptr table.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getStablePtr is called too early with dynamic libraries","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","ndmitchell@gmail.com"],"type":"Bug","description":"{{{\r\n$ cat Hello.hs\r\nmodule Main where\r\n\r\nmain = print \"Hello world\"\r\n}}}\r\n\r\n{{{\r\n$ ghc -debug -dynamic --make Hello.hs && ./Hello +RTS -DS\r\nLinking Hello ...\r\n\"Hello world\"\r\nWarning: Freeing non-allocated memory at 0x1ff87850\r\nWarning: Freeing non-allocated memory at 0x1ff85820\r\nWarning: Freeing non-allocated memory at 0x1ff85010\r\nWarning: Freeing non-allocated memory at 0x1ff89860\r\nWarning: Freeing non-allocated memory at 0x1ff8b860\r\nWarning: 192 bytes at 0x1ff9b920 still allocated at shutdown\r\nWarning: 2048 bytes at 0x1ff8ef50 still allocated at shutdown\r\nWarning: 48 bytes at 0x1ff8eef0 still allocated at shutdown\r\nWarning: 2048 bytes at 0x1ff8e6c0 still allocated at shutdown\r\nWarning: 48 bytes at 0x1ff8e660 still allocated at shutdown\r\nWarning: 2048 bytes at 0x1ff8de30 still allocated at shutdown\r\nWarning: 48 bytes at 0x1ff8ddd0 still allocated at shutdown\r\nWarning: 4100 bytes at 0x1ff8cca0 still allocated at shutdown\r\nWarning: 16 bytes at 0x1ff8c980 still allocated at shutdown\r\nWarning: 16 bytes at 0x1ff8c940 still allocated at shutdown\r\nWarning: 4 bytes at 0x1ff8c880 still allocated at shutdown\r\nWarning: 5 bytes at 0x1ff8c840 still allocated at shutdown\r\nWarning: 8 bytes at 0x1ff8c800 still allocated at shutdown\r\nWarning: 32 bytes at 0x1ff8c7b0 still allocated at shutdown\r\n}}}\r\n\r\nNote the freeing of non-allocated memory. This is because \"base\" contains a foreign export of forkOS_entry. Foreign exports are desugared to uses of __attribute__((constructor)) which call getStablePtr (in this case initializing stginit_export_base_ControlziConcurrent_zdfforkOSzuentryzua1bd). On our system this initializer is being run when libHSbase-4.2.0.0-ghc6.12.0.20091010.so gets loaded, which is before the runtime is actually initialized.\r\n\r\nThis leads to a call to allocHashTable (from initStablePtrTable) which allocates memory. This allocation is recorded in the allocs linked list but when the runtime is initialized initAllocator gets called which overwrites that entry. Hence when we come to free that hash table we free a pointer which is not in the allocs list and get the warning.\r\n\r\nI don't get this message with static linking on 6.10 - I can't check 6.12 because there is no static debug runtime for 6.12 RC1 by default. This makes me suspect that this is a peculiarity of shared object initialization, and the call to getStablePtr will happen more lazily with static linking (probably on the first reference to a function in base), such that it comes after RTS initialization is complete.\r\n\r\nI observed this behaviour when trying to use -DS to isolate a segfault in Haskell code in a very large program using -dynamic and Haskell shared libraries. I'm not sure if this problem is actually causing my segfault, but it certainly feels like it has the potential to do so, especially as I tend to get my segfaults from Evac.c, which could be affected by the stable ptr table.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3620The seeds generated by split are not independent2019-07-07T19:03:06ZGhost UserThe seeds generated by split are not independentSuppose we split a seed into two like this:
```
split' :: StdGen -> (StdGen, StdGen)
split' g = (g12, g21)
where (_, g12) = split g1
(g21, _) = split g2
(g1, g2) = split g
```
Since g1 and g2 are independent, g12 and ...Suppose we split a seed into two like this:
```
split' :: StdGen -> (StdGen, StdGen)
split' g = (g12, g21)
where (_, g12) = split g1
(g21, _) = split g2
(g1, g2) = split g
```
Since g1 and g2 are independent, g12 and g21 ought to be too. But they're not! If we use both of g12 and g21 to generate a random number in the range \[0..10\], then the two numbers ought to be equal 1/11 of the time. In fact, they're never equal.
Here is a test program that ought to return True 1/11 of the time but
actually always returns False:
```
sample :: StdGen -> (Int, Int)
sample g = (fst (randomR (0, 10) g1),
fst (randomR (0, 10) g2))
where (g1, g2) = split' g
test :: StdGen -> Bool
test g = fst (sample g) == snd (sample g)
```
I attached a program that prints the distribution of values from
`test` for other ranges than \[0..10\]. The distribution is
always quite bad no matter what the range is.
The upshot of all this is that the following QuickCheck (version 2)
property always passes, even though it's false:
```
import Test.QuickCheck
import Text.Show.Functions
newtype Eleven = Eleven Int deriving Eq
instance Arbitrary Eleven where
arbitrary = fmap Eleven (choose (0, 10))
prop :: (Int -> Eleven) -> Bool
prop f = f 5 /= f 6
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The seeds generated by split are not independent","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Suppose we split a seed into two like this:\r\n{{{\r\nsplit' :: StdGen -> (StdGen, StdGen)\r\nsplit' g = (g12, g21)\r\n where (_, g12) = split g1\r\n (g21, _) = split g2\r\n (g1, g2) = split g\r\n}}}\r\nSince g1 and g2 are independent, g12 and g21 ought to be too. But they're not! If we use both of g12 and g21 to generate a random number in the range [0..10], then the two numbers ought to be equal 1/11 of the time. In fact, they're never equal.\r\nHere is a test program that ought to return True 1/11 of the time but\r\nactually always returns False:\r\n{{{\r\nsample :: StdGen -> (Int, Int)\r\nsample g = (fst (randomR (0, 10) g1),\r\n fst (randomR (0, 10) g2))\r\n where (g1, g2) = split' g\r\ntest :: StdGen -> Bool\r\ntest g = fst (sample g) == snd (sample g)\r\n}}}\r\n\r\nI attached a program that prints the distribution of values from\r\n{{{test}}} for other ranges than [0..10]. The distribution is\r\nalways quite bad no matter what the range is.\r\n\r\nThe upshot of all this is that the following QuickCheck (version 2)\r\nproperty always passes, even though it's false:\r\n{{{\r\nimport Test.QuickCheck\r\nimport Text.Show.Functions\r\n\r\nnewtype Eleven = Eleven Int deriving Eq\r\n\r\ninstance Arbitrary Eleven where\r\n arbitrary = fmap Eleven (choose (0, 10))\r\n\r\nprop :: (Int -> Eleven) -> Bool\r\nprop f = f 5 /= f 6\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/3621"No match in record selector Var.tcTyVarDetails" with incorrect multi-paramet...2019-07-07T19:03:06ZPeter Berry"No match in record selector Var.tcTyVarDetails" with incorrect multi-parameter newtype derivation```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Control.Monad.State
newtype WrappedState s a = WS { runWS :: State s a }
deriving (Monad, MonadState state)
```
Note that the 'deriving' for `MonadState` has the wrong variable ...```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Control.Monad.State
newtype WrappedState s a = WS { runWS :: State s a }
deriving (Monad, MonadState state)
```
Note that the 'deriving' for `MonadState` has the wrong variable name. It should be rejected with something like "not in scope: type variable 'state'" but instead this happens:
```
[pwb@rhuidean tmp]$ ghc bug.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for x86_64-unknown-linux):
No match in record selector Var.tcTyVarDetails
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"\"No match in record selector Var.tcTyVarDetails\" with incorrect multi-parameter newtype derivation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\nimport Control.Monad.State\r\nnewtype WrappedState s a = WS { runWS :: State s a }\r\n deriving (Monad, MonadState state)\r\n}}}\r\nNote that the 'deriving' for {{{MonadState}}} has the wrong variable name. It should be rejected with something like \"not in scope: type variable 'state'\" but instead this happens:\r\n{{{\r\n[pwb@rhuidean tmp]$ ghc bug.hs \r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for x86_64-unknown-linux):\r\n\tNo match in record selector Var.tcTyVarDetails\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3622ghci ignores LANGUAGE TemplateHaskell pragma2019-07-07T19:03:05Ziampure@gmail.comghci ignores LANGUAGE TemplateHaskell pragmaSave the following in Foo.hs
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH.Syntax
```
`$ ghci Foo.hs`
Paste runQ \[\| (\\x y -\> compare x y == EQ) \|\] in ghci and press enter
Instead of getting a useful result, I ...Save the following in Foo.hs
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH.Syntax
```
`$ ghci Foo.hs`
Paste runQ \[\| (\\x y -\> compare x y == EQ) \|\] in ghci and press enter
Instead of getting a useful result, I get an error.
If I explicitly load TH on the command line, it does work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghci ignores LANGUAGE TemplateHaskell pragma","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Save the following in Foo.hs\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nimport Language.Haskell.TH.Syntax\r\n}}}\r\n\r\n{{{$ ghci Foo.hs}}}\r\n\r\nPaste runQ [| (\\x y -> compare x y == EQ) |] in ghci and press enter\r\n\r\nInstead of getting a useful result, I get an error. \r\n\r\nIf I explicitly load TH on the command line, it does work. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3623Host's C info ending up in .hc files while cross-bootstrapping2019-07-07T19:03:05ZksfHost's C info ending up in .hc files while cross-bootstrappinghsc2hs does not seem to have access to the target's info, or at least not enough of it, at least in the posix package. I was able to hack around a differently-layout struct stat by hand which fixes obvious symptoms, and I'm strongly susp...hsc2hs does not seem to have access to the target's info, or at least not enough of it, at least in the posix package. I was able to hack around a differently-layout struct stat by hand which fixes obvious symptoms, and I'm strongly suspecting this also to be the cause of other strange behaviour that renders the compiled stage2 useless (it can't locate its builtin packages)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Host's C info ending up in .hc files while cross-bootstrapping","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"hsc2hs does not seem to have access to the target's info, or at least not enough of it, at least in the posix package. I was able to hack around a differently-layout struct stat by hand which fixes obvious symptoms, and I'm strongly suspecting this also to be the cause of other strange behaviour that renders the compiled stage2 useless (it can't locate its builtin packages)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3624Parse fails when foreign import declarations contain path information (like t...2019-07-07T19:03:05ZtwadleighParse fails when foreign import declarations contain path information (like those generated by c2hs).An import declaration like:
```
foreign import ccall safe "path/to/test.h test" test :: IO ()
```
fails with:
```
test.hs:7:26: Malformed entity string
```
I've marked this as a major issue because it ought to affect, for instance, a...An import declaration like:
```
foreign import ccall safe "path/to/test.h test" test :: IO ()
```
fails with:
```
test.hs:7:26: Malformed entity string
```
I've marked this as a major issue because it ought to affect, for instance, any library that depends on c2hs (which generates bindings of this kind).
I'm not sure if this is a GHC regression or actually an improvement in fidelity to the FFI spec (although I didn't see anything in the spec that would preclude qualifying the header name with path info).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parse fails when foreign import declarations contain path information (like those generated by c2hs).","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":["FFI,","c2hs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"An import declaration like:\r\n\r\n{{{\r\nforeign import ccall safe \"path/to/test.h test\" test :: IO ()\r\n}}}\r\n\r\nfails with:\r\n\r\n{{{\r\ntest.hs:7:26: Malformed entity string\r\n}}}\r\n\r\nI've marked this as a major issue because it ought to affect, for instance, any library that depends on c2hs (which generates bindings of this kind).\r\n\r\nI'm not sure if this is a GHC regression or actually an improvement in fidelity to the FFI spec (although I didn't see anything in the spec that would preclude qualifying the header name with path info).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3625GHCI doesn't work with dtrace on OS X2019-07-07T19:03:05Zrl@cse.unsw.edu.auGHCI doesn't work with dtrace on OS XOn OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:
```
provider haskell {
probe dem...On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:
```
provider haskell {
probe demo__trace(char*);
};
```
and this C file:
```
void demo_trace( char *s )
{
HASKELL_DEMO_TRACE(s);
}
```
When we compile it, we get:
```
newbie:dtrace-demo rl$ nm demo-trace.o
U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace
```
When linked as a dynamic library, the undefined symbols disappear:
```
newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o
newbie:dtrace-demo rl$ nm demo-trace.dylib
00000000 t __mh_dylib_header
000008b0 T _demo_trace
```
But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:
```
unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'
```
Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.
The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCI doesn't work with dtrace on OS X","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:\r\n\r\n{{{\r\nprovider haskell {\r\n probe demo__trace(char*);\r\n};\r\n}}}\r\n\r\nand this C file:\r\n\r\n{{{\r\nvoid demo_trace( char *s )\r\n{\r\n HASKELL_DEMO_TRACE(s);\r\n}\r\n}}}\r\n\r\nWhen we compile it, we get:\r\n\r\n{{{\r\nnewbie:dtrace-demo rl$ nm demo-trace.o\r\n U ___dtrace_probe$haskell$demo__trace$v1$63686172202a\r\n U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0\r\n U ___dtrace_typedefs$haskell$v1\r\n00000000 T _demo_trace\r\n}}}\r\n\r\nWhen linked as a dynamic library, the undefined symbols disappear:\r\n\r\n{{{\r\nnewbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o \r\nnewbie:dtrace-demo rl$ nm demo-trace.dylib \r\n00000000 t __mh_dylib_header\r\n000008b0 T _demo_trace\r\n}}}\r\n\r\nBut GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:\r\n\r\n{{{\r\nunknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'\r\nLoading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'\r\n}}}\r\n\r\nUnless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.\r\n\r\nThe problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3626Template Haskell silently boxes tuples2019-07-07T19:03:05Zrl@cse.unsw.edu.auTemplate Haskell silently boxes tuplesHere is a small program:
```
{-# LANGUAGE TemplateHaskell, UnboxedTuples #-}
module T where
$(id [d| f g x = case g x of (# _, _ #) -> x |])
```
Output of `ghci -ddump-splices`:
```
f g[aR4] x[aR5] = case g[aR4] x[aR5] of { (_, _) ...Here is a small program:
```
{-# LANGUAGE TemplateHaskell, UnboxedTuples #-}
module T where
$(id [d| f g x = case g x of (# _, _ #) -> x |])
```
Output of `ghci -ddump-splices`:
```
f g[aR4] x[aR5] = case g[aR4] x[aR5] of { (_, _) -> x[aR5] }
```
Note how the tuple has been silently converted to a boxed one. TH shouldn't accept this program since it can't deal with unboxed tuples.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.4 |
| 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":"Template Haskell silently boxes tuples","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a small program:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell, UnboxedTuples #-}\r\nmodule T where\r\n\r\n$(id [d| f g x = case g x of (# _, _ #) -> x |])\r\n}}}\r\n\r\nOutput of `ghci -ddump-splices`:\r\n\r\n{{{\r\n f g[aR4] x[aR5] = case g[aR4] x[aR5] of { (_, _) -> x[aR5] }\r\n}}}\r\n\r\nNote how the tuple has been silently converted to a boxed one. TH shouldn't accept this program since it can't deal with unboxed tuples.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3627Profiling loses eta-expansion opportunities unnecessarily2019-07-07T19:03:04ZSimon Peyton JonesProfiling loses eta-expansion opportunities unnecessarilyIf I have
```
f = scc "f"
let x = scc "g" y in
\z -> ...
```
then we don't see that f has arity 1. Because `SimplUtils.mkLam` only does eta expansion if there is at least one value lambda.
I'm making a ticket for this so that...If I have
```
f = scc "f"
let x = scc "g" y in
\z -> ...
```
then we don't see that f has arity 1. Because `SimplUtils.mkLam` only does eta expansion if there is at least one value lambda.
I'm making a ticket for this so that we don't forget it, but it's not very high priority.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Profiling loses eta-expansion opportunities unnecessarily","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"_|_","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I have\r\n{{{\r\nf = scc \"f\" \r\n let x = scc \"g\" y in\r\n \\z -> ...\r\n}}}\r\nthen we don't see that f has arity 1. Because `SimplUtils.mkLam` only does eta expansion if there is at least one value lambda.\r\n\r\nI'm making a ticket for this so that we don't forget it, but it's not very high priority.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3629Code compiled WITHOUT profiling many times slower than compiled WITH profilin...2022-11-24T23:09:44ZgchrupalaCode compiled WITHOUT profiling many times slower than compiled WITH profiling onI have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).
I reproduced it with GHC 6.10, 6.12 and 6.13.
The source is attache...I have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).
I reproduced it with GHC 6.10, 6.12 and 6.13.
The source is attached.
I compiled and ran like this:
```
ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp
time ./runST > /dev/null
real 5m9.670s
user 5m7.627s
sys 0m0.468s
ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp -prof -auto-all
real 0m39.544s
user 0m39.050s
sys 0m0.148s
```
In the meantime, is there is a workaround other than compiling with profiling options on? I would prefer to modify the source rather than ask users to install profiling libraries and mess with compiler options.
Best,
--
Grzegorz Chrupala
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"Code compiled WITHOUT profiling many times slower than compiled WITH profiling on","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).\r\n\r\nI reproduced it with GHC 6.10, 6.12 and 6.13.\r\n\r\nThe source is attached.\r\n\r\nI compiled and ran like this:\r\n\r\n{{{\r\nghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp\r\ntime ./runST > /dev/null\r\nreal\t5m9.670s\r\nuser\t5m7.627s\r\nsys\t0m0.468s\r\n\r\nghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp -prof -auto-all\r\nreal\t0m39.544s\r\nuser\t0m39.050s\r\nsys\t0m0.148s\r\n}}}\r\n\r\nIn the meantime, is there is a workaround other than compiling with profiling options on? I would prefer to modify the source rather than ask users to install profiling libraries and mess with compiler options.\r\n\r\nBest,\r\n\r\n--\r\nGrzegorz Chrupala\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3630Suggested algorithm to control upper bound of space "leaks"2019-07-07T19:03:03Zshelbymoore3Suggested algorithm to control upper bound of space "leaks"An idea for an algorithm to mitigate space "leaks".
Limited research (thus far) reveals that space "leaks" due to laziness are
desireable function of the matrix of design choices and may be better
automatically controlled in runtime (re...An idea for an algorithm to mitigate space "leaks".
Limited research (thus far) reveals that space "leaks" due to laziness are
desireable function of the matrix of design choices and may be better
automatically controlled in runtime (read both links to fully understand):
http://www.haskell.org/pipermail/haskell-cafe/2009-October/068382.html \[\[BR\]\]
http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Proposes to fix to this bug (in theory):
http://hackage.haskell.org/trac/ghc/ticket/917
May you can cross-link from the bug, so people can read my links above to get a deeper understanding of why space "leaks" are really a feature, not a bug. And others can think about my idea at links above for a deterministic runtime upper bound solution (that proposes to be orthogonal to profiling and static optimization).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Suggested algorithm to control upper bound of space \"leaks\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"An idea for an algorithm to mitigate space \"leaks\".\r\n\r\nLimited research (thus far) reveals that space \"leaks\" due to laziness are\r\ndesireable function of the matrix of design choices and may be better\r\nautomatically controlled in runtime (read both links to fully understand):\r\n\r\nhttp://www.haskell.org/pipermail/haskell-cafe/2009-October/068382.html [[BR]]\r\nhttp://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html\r\n\r\nProposes to fix to this bug (in theory):\r\n\r\nhttp://hackage.haskell.org/trac/ghc/ticket/917\r\n\r\nMay you can cross-link from the bug, so people can read my links above to get a deeper understanding of why space \"leaks\" are really a feature, not a bug. And others can think about my idea at links above for a deterministic runtime upper bound solution (that proposes to be orthogonal to profiling and static optimization).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3631Overload the Prelude iterate to support list input2019-07-07T19:03:03Zshelbymoore3Overload the Prelude iterate to support list inputHad to overload the Prelude function iterate to support list input. The overload could be global (should be added to Prelude), no need to wrap in where. My example fibonacci sequence usage follows.
```
fibs = 0 : 1 : zipWith (+) fib...Had to overload the Prelude function iterate to support list input. The overload could be global (should be added to Prelude), no need to wrap in where. My example fibonacci sequence usage follows.
```
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
Make forward iteration explicit, and remove self referential space "leak" above due direct recursion on fibs.
```
fibs = iterate (\x -> last x + last init x) [ 0 : 1 ] where
iterate :: ([a] -> [a]) -> [a] -> [a]
iterate f x = iterate f (x : (f x))
-- iterate f x == [x, f x, f (f x), ...]
```
> Or verbosely:
```
fibs = iterate (\x -> fib -1 + fib -2 where fib i = | i==-1=last x | i==-2=last init x) [ 0 : 1 ]
-- negative indices in local function fib offset from end of list
```
P.S. Note I not using HUGS nor GHC, this is just in my head. The above are my unique solutions, didn't lift them from www. I am just learning FP and Haskell for first time in my head past few days. So this might be rubbish.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Overload the Prelude iterate to support list input","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Had to overload the Prelude function iterate to support list input. The overload could be global (should be added to Prelude), no need to wrap in where. My example fibonacci sequence usage follows.\r\n\r\n\r\n{{{\r\n fibs = 0 : 1 : zipWith (+) fibs (tail fibs)\r\n}}}\r\n\r\n\r\nMake forward iteration explicit, and remove self referential space \"leak\" above due direct recursion on fibs.\r\n\r\n\r\n{{{\r\n fibs = iterate (\\x -> last x + last init x) [ 0 : 1 ] where\r\n \titerate :: ([a] -> [a]) -> [a] -> [a]\r\n \titerate f x = iterate f (x : (f x))\r\n \t-- iterate f x == [x, f x, f (f x), ...]\r\n}}}\r\n\r\n\r\n Or verbosely:\r\n\r\n\r\n{{{\r\n fibs = iterate (\\x -> fib -1 + fib -2 where fib i = | i==-1=last x | i==-2=last init x) [ 0 : 1 ]\r\n \t-- negative indices in local function fib offset from end of list\r\n}}}\r\n\r\n\r\n\r\nP.S. Note I not using HUGS nor GHC, this is just in my head. The above are my unique solutions, didn't lift them from www. I am just learning FP and Haskell for first time in my head past few days. So this might be rubbish.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3632lift restrictions on records with existential fields, especially in the prese...2022-05-26T07:42:13Zeflisterlift restrictions on records with existential fields, especially in the presence of class constraintsthe attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.
her...the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.
here is the record definition; the dur field is existential, but constrained to be in class NoteDur.
```
data Note = forall x . NoteDur x => Note {
midiNum :: Int -- 0-255
, vel :: Int -- 0-255
, chan :: Int -- 0-15
, measure :: Integral a => a
, beat :: Int
, subdiv :: RealFrac a => a -- % of beat
, dur :: x
}
```
here is a walk through of places in the code where the current restrictions are unnecessary and intrusive:
1. lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case.
1. Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type:
```
fieldName :: (SomeClass x) => Record -> x
```
> line 142 shows a case where this would be very nice to have.
1. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit)
1. lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints.
1. lines 124-127 show how it would be nice to have existential classes
1. lastly, allow curried updater functions: `(rec {field = }) 5` instead of `(\x -> (rec {field = x})) 5`8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3633Heap size suggestion of > 2145 MB gets ignored2019-07-07T19:03:02Zchevalier@alum.wellesley.eduHeap size suggestion of > 2145 MB gets ignoredHello,
If I run a GHC-compiled program with:
`+RTS -H2150M -RTS`
or any value greater than 2150 MB, the heap size suggestion apparently gets ignored.
If there is a limit on how big the heap size suggestion can be, at least I should g...Hello,
If I run a GHC-compiled program with:
`+RTS -H2150M -RTS`
or any value greater than 2150 MB, the heap size suggestion apparently gets ignored.
If there is a limit on how big the heap size suggestion can be, at least I should get an error message. My machine has 4 GB of RAM and I'm eager to use it :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Heap size suggestion of > 2145 MB gets ignored","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nIf I run a GHC-compiled program with:\r\n\r\n{{{+RTS -H2150M -RTS}}}\r\n\r\nor any value greater than 2150 MB, the heap size suggestion apparently gets ignored.\r\n\r\nIf there is a limit on how big the heap size suggestion can be, at least I should get an error message. My machine has 4 GB of RAM and I'm eager to use it :-)","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3634Add traceM, traceShowM and withTrace2019-07-07T19:03:02ZMartijnVanSteenbergenAdd traceM, traceShowM and withTraceOn haskell-libraries we have [discussed](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019) the addition of the following three functions to module Debug.Trace:
```
withTrace :: Show a => String -> a -> a
withTrace msg x =...On haskell-libraries we have [discussed](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019) the addition of the following three functions to module Debug.Trace:
```
withTrace :: Show a => String -> a -> a
withTrace msg x = trace (msg ++ show x) x
traceM :: Monad m => String -> m ()
traceM msg = trace msg (return ())
traceShowM :: (Show a, Monad m) => a -> m ()
traceShowM = traceM . show
```
The current documentation for that module is a little terse so we have also added an example to clarify the use of trace.
The following people have participated in the discussion and all expressed interest, agreement or concerns (but always with constructive comments) in or over the new functions: Philip Hölzenspies, pepe, Lennart Augustsson, Felipe Lessa, Evan !LaForge, Joachim Breitner, Twan van Laarhoven, Ben Franksen, Ian Lynagh, Sean Leather. Please see the thread for more detail.
I have attached a diff that can be applied to the module. Could one of the GHC developers check it and apply it?
Thanks,
Martijn.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add traceM, traceShowM and withTrace","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On haskell-libraries we have [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019 discussed] the addition of the following three functions to module Debug.Trace:\r\n\r\n{{{\r\nwithTrace :: Show a => String -> a -> a\r\nwithTrace msg x = trace (msg ++ show x) x\r\n\r\ntraceM :: Monad m => String -> m ()\r\ntraceM msg = trace msg (return ())\r\n\r\ntraceShowM :: (Show a, Monad m) => a -> m ()\r\ntraceShowM = traceM . show\r\n}}}\r\n\r\nThe current documentation for that module is a little terse so we have also added an example to clarify the use of trace.\r\n\r\nThe following people have participated in the discussion and all expressed interest, agreement or concerns (but always with constructive comments) in or over the new functions: Philip Hölzenspies, pepe, Lennart Augustsson, Felipe Lessa, Evan !LaForge, Joachim Breitner, Twan van Laarhoven, Ben Franksen, Ian Lynagh, Sean Leather. Please see the thread for more detail.\r\n\r\nI have attached a diff that can be applied to the module. Could one of the GHC developers check it and apply it?\r\n\r\nThanks,\r\n\r\nMartijn.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3635base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows2019-07-07T19:03:02Zguestbase-3-compat with 6.12 won't load in GHCi, Template Haskell on Windowsbase3-compat/GHC/Handle.hs needs:
```
#ifndef mingw32_HOST_OS
..
#endif
```
Wrapped around its export for and definition of unlockFile. This is because unlockFile is a RTS symbol that is only compiled on non-Windows OSes. This \#ifdef ...base3-compat/GHC/Handle.hs needs:
```
#ifndef mingw32_HOST_OS
..
#endif
```
Wrapped around its export for and definition of unlockFile. This is because unlockFile is a RTS symbol that is only compiled on non-Windows OSes. This \#ifdef exists in base4, it looks like it was just omitted from base3.
The result of this bug is that any package using base 3 doesn’t work with template-haskell or GHCi:
```
$ ghci -package base-3.0.3.2
WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular)
doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead
GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... : unable to load package `base-3.0.3.2'
: C:\ghc\GHC-61~2.200\lib\base-3.0.3.2\HSbase-3.0.3.2.o: unknown symbol `_unlockFile'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","ndmitchell@gmail.com"],"type":"Bug","description":"base3-compat/GHC/Handle.hs needs:\r\n\r\n{{{\r\n#ifndef mingw32_HOST_OS\r\n..\r\n#endif\r\n}}}\r\n\r\nWrapped around its export for and definition of unlockFile. This is because unlockFile is a RTS symbol that is only compiled on non-Windows OSes. This #ifdef exists in base4, it looks like it was just omitted from base3.\r\n\r\nThe result of this bug is that any package using base 3 doesn’t work with template-haskell or GHCi:\r\n\r\n{{{\r\n$ ghci -package base-3.0.3.2\r\nWARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular)\r\n doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead\r\nGHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package syb-0.1.0.2 ... linking ... done.\r\nLoading package base-3.0.3.2 ... linking ... : unable to load package `base-3.0.3.2'\r\n: C:\\ghc\\GHC-61~2.200\\lib\\base-3.0.3.2\\HSbase-3.0.3.2.o: unknown symbol `_unlockFile'\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3636ghc --make sends progress output to stderr2019-07-07T19:03:01Zabghc --make sends progress output to stderrThis is a relatively minor problem, but it is really annoying. Running `ghc --make` generates progress output on the standard error stream rather than the usual standard out. For example, lines such as the following appear on stderr:
``...This is a relatively minor problem, but it is really annoying. Running `ghc --make` generates progress output on the standard error stream rather than the usual standard out. For example, lines such as the following appear on stderr:
```
[ 1 of 13] Compiling Poly ( tools/mackerel/Poly.hs, Poly.o )
[ 2 of 13] Compiling Space ( tools/mackerel/Space.hs, Space.o )
```
Could you please consider changing this so that progress output goes to stdout and only actual errors go to stderr? Without this, it is much harder to quieten the output from ghc but still see actual errors, and various build system tools incorrectly identify the progress output as error messages.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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 --make sends progress output to stderr","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a relatively minor problem, but it is really annoying. Running {{{ghc --make}}} generates progress output on the standard error stream rather than the usual standard out. For example, lines such as the following appear on stderr:\r\n\r\n{{{\r\n[ 1 of 13] Compiling Poly ( tools/mackerel/Poly.hs, Poly.o )\r\n[ 2 of 13] Compiling Space ( tools/mackerel/Space.hs, Space.o )\r\n}}}\r\n\r\nCould you please consider changing this so that progress output goes to stdout and only actual errors go to stderr? Without this, it is much harder to quieten the output from ghc but still see actual errors, and various build system tools incorrectly identify the progress output as error messages.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3637./configure doesn't understand Gentoo's build/host/target2019-07-07T19:03:01Zkolmodin@dtek.chalmers.se./configure doesn't understand Gentoo's build/host/targetApparently there are several styles in how to write your build/host/target variables.
In Gentoo they look like this for my amd64 `x86_64-pc-linux-gnu` which doesn't play well with the current build system.
Default `./configure` executi...Apparently there are several styles in how to write your build/host/target variables.
In Gentoo they look like this for my amd64 `x86_64-pc-linux-gnu` which doesn't play well with the current build system.
Default `./configure` execution in Gentoo ebuilds will pass the following flags:
```
./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man \
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc \
--localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu
```
Which results in:
```
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... given 6.12.0.20091010
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.10.4
Target platform inferred as: x86_64-unknown-linux
Unknown vendor linux
```
So we sed it like this:
```
build=`echo "$build" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
host=`echo "$host" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
target=`echo "$target" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
```
but of course we would prefer not to have to handle this specially.
That is, the `vendor` is `pc` and the `OS` is `linux-gnu`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"./configure doesn't understand Gentoo's build/host/target","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Apparently there are several styles in how to write your build/host/target variables.\r\n\r\nIn Gentoo they look like this for my amd64 {{{x86_64-pc-linux-gnu}}} which doesn't play well with the current build system.\r\n\r\nDefault {{{./configure}}} execution in Gentoo ebuilds will pass the following flags:\r\n{{{\r\n./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man \\\r\n --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc \\\r\n --localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu\r\n}}}\r\n\r\nWhich results in:\r\n\r\n{{{\r\nchecking for gfind... no\r\nchecking for find... /usr/bin/find\r\nchecking for sort... /usr/bin/sort\r\nchecking for GHC version date... given 6.12.0.20091010\r\nchecking for ghc... /usr/bin/ghc\r\nchecking version of ghc... 6.10.4\r\nTarget platform inferred as: x86_64-unknown-linux\r\nUnknown vendor linux\r\n}}}\r\n\r\nSo we sed it like this:\r\n{{{\r\nbuild=`echo \"$build\" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`\r\nhost=`echo \"$host\" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`\r\ntarget=`echo \"$target\" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`\r\n}}}\r\nbut of course we would prefer not to have to handle this specially.\r\n\r\nThat is, the {{{vendor}}} is {{{pc}}} and the {{{OS}}} is {{{linux-gnu}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3638Redundant signature required with RULES and GADTs2019-07-07T19:03:01Zrl@cse.unsw.edu.auRedundant signature required with RULES and GADTsHere is a small program:
```
data T a where TInt :: T Int
foo :: T Int -> Int
foo TInt = 0
{-# RULES "foo" forall x. foo x = case x of { TInt -> 0 } #-}
```
GHC complains:
```
GADT pattern match with non-rigid result type `t'
...Here is a small program:
```
data T a where TInt :: T Int
foo :: T Int -> Int
foo TInt = 0
{-# RULES "foo" forall x. foo x = case x of { TInt -> 0 } #-}
```
GHC complains:
```
GADT pattern match with non-rigid result type `t'
Solution: add a type signature for the entire case expression
In a case alternative: TInt -> 0
In the expression: case x of { TInt -> 0 }
When checking the transformation rule "foo"
```
And indeed, changing the rule to
```
{-# RULES "foo" forall x. foo x = case x of { TInt -> 0 } :: Int #-}
```
works. The signature is redundant, though, because the type of the case is determined by the type of the rule head.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.13 |
| 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":"Redundant signature required with RULES and GADTs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a small program:\r\n\r\n{{{\r\ndata T a where TInt :: T Int\r\n\r\nfoo :: T Int -> Int\r\nfoo TInt = 0\r\n\r\n{-# RULES \"foo\" forall x. foo x = case x of { TInt -> 0 } #-}\r\n}}}\r\n\r\nGHC complains:\r\n\r\n{{{\r\n GADT pattern match with non-rigid result type `t'\r\n Solution: add a type signature for the entire case expression\r\n In a case alternative: TInt -> 0\r\n In the expression: case x of { TInt -> 0 }\r\n When checking the transformation rule \"foo\"\r\n}}}\r\n\r\nAnd indeed, changing the rule to\r\n\r\n{{{\r\n{-# RULES \"foo\" forall x. foo x = case x of { TInt -> 0 } :: Int #-}\r\n}}}\r\n\r\nworks. The signature is redundant, though, because the type of the case is determined by the type of the rule head.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3639GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or d...2019-07-07T19:03:01ZspookylukeyGHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory"I am attempting to build GHC 6.10.1 on a CentOS 4.5 machine.
At the 'make install' stage, I get this error:
```
/home/build/build/ghc-6.10.1/libraries/cabal-bin /home/build/local/bin/ghc /home/build/build/ghc-6.10.1/libraries/bootstrap...I am attempting to build GHC 6.10.1 on a CentOS 4.5 machine.
At the 'make install' stage, I get this error:
```
/home/build/build/ghc-6.10.1/libraries/cabal-bin /home/build/local/bin/ghc /home/build/build/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O --ghc-option=-H32m --ghc-option=-O
Preprocessing executables for ghc-bin-6.10.1...
Building ghc-bin-6.10.1...
In file included from Main.hs:13:0:
/home/build/local/lib/ghc-6.10.4/ghc-6.10.4/include/HsVersions.h:23:0:
../includes/ghcautoconf.h: No such file or directory
make[2]: *** [build.stage.1] Error 1
make[1]: *** [build.stage.1] Error 2
make: *** [stage1] Error 1
```
This was also reported here http://www.haskell.org/pipermail/glasgow-haskell-bugs/2008-November/015981.html but with no follow up.
I am building using GHC 6.10.4 (which I cannot use for other purposes because of bug #3179). I have to compile from source because of #2211
I already have GHC 6.8.3 built, so I will uninstall 6.10.4 to try to build 6.10.1 with 6.8.3 instead, and report back here if I have success.
Otherwise, as GHC 6.10.1 is apparently the only version of GHC that I can use (library dependencies rule out 6.8.\*), I would really appreciate help on fixing this or a workaround!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 6.10.1 fails to build with \"../includes/ghcautoconf.h: No such file or directory\"","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am attempting to build GHC 6.10.1 on a CentOS 4.5 machine.\r\n\r\nAt the 'make install' stage, I get this error:\r\n\r\n{{{\r\n/home/build/build/ghc-6.10.1/libraries/cabal-bin /home/build/local/bin/ghc /home/build/build/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O --ghc-option=-H32m --ghc-option=-O\r\nPreprocessing executables for ghc-bin-6.10.1...\r\nBuilding ghc-bin-6.10.1...\r\n\r\nIn file included from Main.hs:13:0:\r\n\r\n/home/build/local/lib/ghc-6.10.4/ghc-6.10.4/include/HsVersions.h:23:0:\r\n ../includes/ghcautoconf.h: No such file or directory\r\nmake[2]: *** [build.stage.1] Error 1\r\nmake[1]: *** [build.stage.1] Error 2\r\nmake: *** [stage1] Error 1\r\n}}}\r\n\r\nThis was also reported here http://www.haskell.org/pipermail/glasgow-haskell-bugs/2008-November/015981.html but with no follow up.\r\n\r\nI am building using GHC 6.10.4 (which I cannot use for other purposes because of bug #3179). I have to compile from source because of #2211\r\n\r\nI already have GHC 6.8.3 built, so I will uninstall 6.10.4 to try to build 6.10.1 with 6.8.3 instead, and report back here if I have success.\r\n\r\nOtherwise, as GHC 6.10.1 is apparently the only version of GHC that I can use (library dependencies rule out 6.8.*), I would really appreciate help on fixing this or a workaround!\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3640NamedFieldPuns broken in where clauses2019-07-07T19:03:00ZcjsNamedFieldPuns broken in where clausesThe attached file compiles fine under GHC 6.10. However, under 6.12, it produces the error
```
BadPun.hs:8:17:
Conflicting definitions for `pun-right-hand-side'
In the binding group for: pun-right-hand-side, pun-right-hand-side,...The attached file compiles fine under GHC 6.10. However, under 6.12, it produces the error
```
BadPun.hs:8:17:
Conflicting definitions for `pun-right-hand-side'
In the binding group for: pun-right-hand-side, pun-right-hand-side,
pun-right-hand-side
```
Note that this affects the named field puns only in the where clause of `badPun`; `goodPun`, which uses them in the LHS of a top-level definition, does not have this problem.
A possibly interesting additional note is that if you change `Record{f1,f2,`... to `Record{f1=f1,f2,`..., you'll find that you get this error message instead:
```
BadPun.hs:8:23:
Conflicting definitions for `pun-right-hand-side'
In the binding group for: f1, pun-right-hand-side,
pun-right-hand-side
```
Changing `f2` to `f2=f2` as well makes the error go away, presumably because there's now only one `pun-right-hand-side` defined.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"NamedFieldPuns broken in where clauses","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":["NamedFieldPuns"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached file compiles fine under GHC 6.10. However, under 6.12, it produces the error\r\n\r\n{{{\r\nBadPun.hs:8:17:\r\n Conflicting definitions for `pun-right-hand-side'\r\n In the binding group for: pun-right-hand-side, pun-right-hand-side,\r\n pun-right-hand-side\r\n}}}\r\n\r\nNote that this affects the named field puns only in the where clause of {{{badPun}}}; {{{goodPun}}}, which uses them in the LHS of a top-level definition, does not have this problem.\r\n\r\nA possibly interesting additional note is that if you change {{{Record{f1,f2,}}}... to {{{Record{f1=f1,f2,}}}..., you'll find that you get this error message instead:\r\n\r\n{{{\r\nBadPun.hs:8:23:\r\n Conflicting definitions for `pun-right-hand-side'\r\n In the binding group for: f1, pun-right-hand-side,\r\n pun-right-hand-side\r\n}}}\r\nChanging {{{f2}}} to {{{f2=f2}}} as well makes the error go away, presumably because there's now only one {{{pun-right-hand-side}}} defined.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3641^L Does Not Work Anymore in Interactive Mode for 6.10.x?2019-07-07T19:03:00ZAviator^L Does Not Work Anymore in Interactive Mode for 6.10.x?I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if so...I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if someone has posted a similar bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"^L Does Not Work Anymore in Interactive Mode for 6.10.x?","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.\r\n\r\nI don't know if someone has posted a similar bug.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchjudahjudahhttps://gitlab.haskell.org/ghc/ghc/-/issues/3642GHC does not build using the Haskell Platform on Windows2019-07-07T19:03:00ZSimon MarlowGHC does not build using the Haskell Platform on WindowsWe still have issues with paths containing spaces in the build system. I have fixed some of them, but there are more (that are not easy to fix). The current bug I ran into is in `rules/distdir-way-opts.mk` where we make the HSC2HS_OPTS b...We still have issues with paths containing spaces in the build system. I have fixed some of them, but there are more (that are not easy to fix). The current bug I ran into is in `rules/distdir-way-opts.mk` where we make the HSC2HS_OPTS by prepending --cflag/--lflag to the beginning of CC_OPTS and LD_OPTS respectively, that doesn't know where the word breaks in CC_OPTS/LD_OPTS are supposed to be.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC does not build using the Haskell Platform on Windows","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.12.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We still have issues with paths containing spaces in the build system. I have fixed some of them, but there are more (that are not easy to fix). The current bug I ran into is in `rules/distdir-way-opts.mk` where we make the HSC2HS_OPTS by prepending --cflag/--lflag to the beginning of CC_OPTS and LD_OPTS respectively, that doesn't know where the word breaks in CC_OPTS/LD_OPTS are supposed to be.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3643building heliumeditor2019-07-07T19:02:59Zcyberpuffbuilding heliumeditor:\~/share/heliumEditor$ cabal configure
Resolving dependencies...
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
> (GHC version 6.10.4 for i386-unknown-linux):
Prelude.chr: bad argument
Please re...:\~/share/heliumEditor$ cabal configure
Resolving dependencies...
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
> (GHC version 6.10.4 for i386-unknown-linux):
Prelude.chr: bad argument
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
The system is i386 Xubuntu 9.10, installed from the alternate CD running as a VirtualBox VM guest under XP SP3.
It don't happen if I do: cabal configure -fgui
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"building heliumeditor","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":":~/share/heliumEditor$ cabal configure\r\nResolving dependencies...\r\nBinary: Int64 truncated to fit in 32 bit Int\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-linux):\r\n\tPrelude.chr: bad argument\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThe system is i386 Xubuntu 9.10, installed from the alternate CD running as a VirtualBox VM guest under XP SP3.\r\n\r\nIt don't happen if I do: cabal configure -fgui","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3644./configure fails while gcc version checking2019-07-07T19:02:59Ztolysz./configure fails while gcc version checking1. /configure exits with an error 1
but commenting out lines 4115 - 4138 solves this problem i.e.
```
>gcc --version
gcc (Debian 4.3.4-6) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for...1. /configure exits with an error 1
but commenting out lines 4115 - 4138 solves this problem i.e.
```
>gcc --version
gcc (Debian 4.3.4-6) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
```
>gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --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.3.4 (Debian 4.3.4-6)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"./configure fails while gcc version checking","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"./configure exits with an error 1\r\nbut commenting out lines 4115 - 4138 solves this problem i.e. \r\n\r\n{{{\r\n>gcc --version\r\ngcc (Debian 4.3.4-6) 4.3.4\r\nCopyright (C) 2008 Free Software Foundation, Inc.\r\nThis is free software; see the source for copying conditions. There is NO\r\nwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\r\n}}}\r\n\r\n{{{\r\n>gcc -v\r\nUsing built-in specs.\r\nTarget: x86_64-linux-gnu\r\nConfigured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --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.3.4 (Debian 4.3.4-6) \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3646Enforce requirement that our repos contains a subset of upstream's patches2019-07-07T19:02:59ZIan Lynagh <igloo@earth.li>Enforce requirement that our repos contains a subset of upstream's patchesSimon Marlow wrote this prehook script:
{{{
\#!/bin/sh -e
\# checkupstream.sh
\# Only allow applying of patches that are also in this upstream repository:
UPSTREAM=$1
\# echo DARCS_PATCHES_XML = $DARCS_PATCHES_XML
\# Take $DARCS_PATC...Simon Marlow wrote this prehook script:
{{{
\#!/bin/sh -e
\# checkupstream.sh
\# Only allow applying of patches that are also in this upstream repository:
UPSTREAM=$1
\# echo DARCS_PATCHES_XML = $DARCS_PATCHES_XML
\# Take $DARCS_PATCHES_XML and turn it into a list of patch hashes
\# suitable for looping over.
hashes=`echo $DARCS_PATCHES_XML | sed 's|</patch>|</patch>\n|g' | sed -n
'/hash/p' | sed "s|^.*hash='\([^']*\)'.*$|\1|"`
\# echo hashes: $hashes
\# For each patch, try pulling the patch from the upstream repo. If
\# the patch is not upstream, then fail.
for p in $hashes; do
if darcs pull --match="hash $p" $UPSTREAM --xml --dry-run \| grep "$p"
> /dev/null; then
echo "Patch $p is upstream; ok"
else
echo "Patch $p is not upstream!"
> exit 1
> fi
done
exit 0
}}}
although this is not ideal, as what we really want is to abort the entire `darcs-all push`, not just the push to that repo. e.g. if you haven't pushed to the upstream Cabal repo yet, then you shouldn't push the accompanying patches to the ghc repo.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Enforce requirement that our repos contains a subset of upstream's patches","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Simon Marlow wrote this prehook script:\r\n{{{\r\n#!/bin/sh -e\r\n\r\n# checkupstream.sh\r\n\r\n# Only allow applying of patches that are also in this upstream repository:\r\nUPSTREAM=$1\r\n\r\n# echo DARCS_PATCHES_XML = $DARCS_PATCHES_XML\r\n\r\n# Take $DARCS_PATCHES_XML and turn it into a list of patch hashes\r\n# suitable for looping over.\r\nhashes=`echo $DARCS_PATCHES_XML | sed 's|</patch>|</patch>\\n|g' | sed -n\r\n'/hash/p' | sed \"s|^.*hash='\\([^']*\\)'.*$|\\1|\"`\r\n\r\n# echo hashes: $hashes\r\n\r\n# For each patch, try pulling the patch from the upstream repo. If\r\n# the patch is not upstream, then fail.\r\nfor p in $hashes; do\r\nif darcs pull --match=\"hash $p\" $UPSTREAM --xml --dry-run | grep \"$p\"\r\n>/dev/null; then\r\n echo \"Patch $p is upstream; ok\"\r\n else\r\n echo \"Patch $p is not upstream!\"\r\n exit 1\r\n fi\r\ndone\r\n\r\nexit 0\r\n}}}\r\nalthough this is not ideal, as what we really want is to abort the entire `darcs-all push`, not just the push to that repo. e.g. if you haven't pushed to the upstream Cabal repo yet, then you shouldn't push the accompanying patches to the ghc repo.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3647unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/exten...2019-07-07T19:02:59Zeflisterunify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensionsit's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-\#LANGUAGE ...\#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accept...it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-\#LANGUAGE ...\#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accepted in the pragma list. even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable). also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into \*either\* one's language pragma or command line -X extension args. see http://hackage.haskell.org/trac/ghc/ticket/3616\##3647.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erik.flister@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["error","extensions","language","message","pragma","warning"],"differentials":[],"test_case":"","architecture":"","cc":["erik.flister@gmail.com"],"type":"FeatureRequest","description":"it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-#LANGUAGE ...#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accepted in the pragma list. even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable). also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args. see http://hackage.haskell.org/trac/ghc/ticket/3616#comment:8.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/3648Release a new containers version2019-07-07T19:02:58ZIan Lynagh <igloo@earth.li>Release a new containers versionTo include:
```
Wed Oct 28 03:55:32 PDT 2009 Ross Paterson <ross@soi.city.ac.uk>
* doc bugfix: correct description of index argument
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...To include:
```
Wed Oct 28 03:55:32 PDT 2009 Ross Paterson <ross@soi.city.ac.uk>
* doc bugfix: correct description of index argument
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Release a new containers version","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"To include:\r\n{{{\r\nWed Oct 28 03:55:32 PDT 2009 Ross Paterson <ross@soi.city.ac.uk>\r\n * doc bugfix: correct description of index argument\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3649inconsistent exception between unix/windows for running non-existant program2019-07-07T19:02:58Zduncaninconsistent exception between unix/windows for running non-existant program```
handle (print . isDoesNotExistError) $ do
(_,_,_,hnd) <- createProcess (proc "foobar" [])
print =<< waitForProcess hnd
```
On Windows this prints `True` since it throws a "does not exists" kind of IOException. On Unix instead th...```
handle (print . isDoesNotExistError) $ do
(_,_,_,hnd) <- createProcess (proc "foobar" [])
print =<< waitForProcess hnd
```
On Windows this prints `True` since it throws a "does not exists" kind of IOException. On Unix instead the createProcess call succeeds and then waiting on the process claims it terminated with an exit code of 127.
It is annoying that we need two different error handling mechanisms in this case. For example Cabal wants to know when it tries to run a program that cannot be found (eg when it tries to run sh.exe on Windows).
It would be better if the behaviour was consistent. The behaviour on Windows seems to be the more sensible one. We should be able to make the Unix behaviour the same since the exceve call does indeed return an error code when loading the new executable image fails.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"inconsistent exception between unix/windows for running non-existant program","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nhandle (print . isDoesNotExistError) $ do\r\n (_,_,_,hnd) <- createProcess (proc \"foobar\" [])\r\n print =<< waitForProcess hnd\r\n}}}\r\n\r\nOn Windows this prints `True` since it throws a \"does not exists\" kind of IOException. On Unix instead the createProcess call succeeds and then waiting on the process claims it terminated with an exit code of 127.\r\n\r\nIt is annoying that we need two different error handling mechanisms in this case. For example Cabal wants to know when it tries to run a program that cannot be found (eg when it tries to run sh.exe on Windows).\r\n\r\nIt would be better if the behaviour was consistent. The behaviour on Windows seems to be the more sensible one. We should be able to make the Unix behaviour the same since the exceve call does indeed return an error code when loading the new executable image fails.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Michael Snoymanmichael@snoyman.comMichael Snoymanmichael@snoyman.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3650Add a Natural number type to the pre-defined basic types.2019-07-07T19:02:58ZJohnDAdd a Natural number type to the pre-defined basic types.See
[http://hackage.haskell.org/trac/haskell-prime/wiki/Natural](http://hackage.haskell.org/trac/haskell-prime/wiki/Natural)
concerning "Add a Natural number type to the pre-defined basic types." I will add a link from that page to thi...See
[http://hackage.haskell.org/trac/haskell-prime/wiki/Natural](http://hackage.haskell.org/trac/haskell-prime/wiki/Natural)
concerning "Add a Natural number type to the pre-defined basic types." I will add a link from that page to this one. That was the Haskell prime wiki which is my understanding concerns discussions concerning the Haskell language in general. It seems conceivable that GHC may be uniquely positioned to address this problem. Haskell was designed to explorer a problem that is of academic interest. Why else is the language lazy and statically typed? It's all about purity. To provide a synopsis it dates back to the discovery that untyped lambda calculus is a model of computation and not that of logic.
At first blush one might conclude that there is good reason why there is no natural number type. Natural numbers are problematic. For example, you can add them, but you cannot in general subtract them. In the general case subtraction yields an integer type, not a natural number type. This problem could be solved through duck typing, but that isn't what Haskell or ML is about. With duck typing you can compare two values at runtime to ensure that the result yields a natural number thus upholding the type system. Though duck typing is useful it is naturally off the table.
A natural number type could be included in the language, but such an addition without the benefit of duck typing might be looked upon as ad hoc.
You get the nat type for abbreviated natural number in proof assistants. Some proof assistants are built using the Haskell language in fact. It is my impression that ML has been around longer than Haskell; consequently, most proof assistants are built on ML and not Haskell. I recall that GHC has moved from System F to a subset of dependent types and can therefore handle some problems involving dependent types. Nat seems to me to potentially be such a problem. Dependent types and proof assistants are like bread and butter. You prove by semi-automated methods at compile time that one number is necessarily not less than another and thereby prove that the difference at runtime cannot be negative.
A natural number is an integer that depends on a number, a lower bound, namely zero. As such it seems likely that natural numbers are a dependent type. I am not sufficiently familiar with GHC at the present time to assess whether or not if the natural number dependent type can be resolved automatically by GHC. It is, however, something I have wondered about and may be something worth considering.
With the inclusion of a natural number type if it proves feasible suggests that interval types may also be possible. The Ada language has an interval type in that array bounds are made explicit. The point is there are special cases where such types can be resolved at compile time.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | |
| 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":"Add a Natural number type to the pre-defined basic types.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See\r\n\r\n[http://hackage.haskell.org/trac/haskell-prime/wiki/Natural]\r\n\r\nconcerning \"Add a Natural number type to the pre-defined basic types.\" I will add a link from that page to this one. That was the Haskell prime wiki which is my understanding concerns discussions concerning the Haskell language in general. It seems conceivable that GHC may be uniquely positioned to address this problem. Haskell was designed to explorer a problem that is of academic interest. Why else is the language lazy and statically typed? It's all about purity. To provide a synopsis it dates back to the discovery that untyped lambda calculus is a model of computation and not that of logic.\r\n\r\nAt first blush one might conclude that there is good reason why there is no natural number type. Natural numbers are problematic. For example, you can add them, but you cannot in general subtract them. In the general case subtraction yields an integer type, not a natural number type. This problem could be solved through duck typing, but that isn't what Haskell or ML is about. With duck typing you can compare two values at runtime to ensure that the result yields a natural number thus upholding the type system. Though duck typing is useful it is naturally off the table.\r\n\r\nA natural number type could be included in the language, but such an addition without the benefit of duck typing might be looked upon as ad hoc.\r\n\r\nYou get the nat type for abbreviated natural number in proof assistants. Some proof assistants are built using the Haskell language in fact. It is my impression that ML has been around longer than Haskell; consequently, most proof assistants are built on ML and not Haskell. I recall that GHC has moved from System F to a subset of dependent types and can therefore handle some problems involving dependent types. Nat seems to me to potentially be such a problem. Dependent types and proof assistants are like bread and butter. You prove by semi-automated methods at compile time that one number is necessarily not less than another and thereby prove that the difference at runtime cannot be negative.\r\n\r\nA natural number is an integer that depends on a number, a lower bound, namely zero. As such it seems likely that natural numbers are a dependent type. I am not sufficiently familiar with GHC at the present time to assess whether or not if the natural number dependent type can be resolved automatically by GHC. It is, however, something I have wondered about and may be something worth considering.\r\n\r\nWith the inclusion of a natural number type if it proves feasible suggests that interval types may also be possible. The Ada language has an interval type in that array bounds are made explicit. The point is there are special cases where such types can be resolved at compile time.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3651GADT type checking too liberal2019-07-07T19:02:58ZMartijnVanSteenbergenGADT type checking too liberalI would expect the following three functions to fail:
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
module Unsafe where
data Z a where
U :: Z ()
B :: Z Bool
unsafe1 :: Z a -> Z a -> a
unsafe1 B U = ()
unsafe2 :: a ~ b...I would expect the following three functions to fail:
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
module Unsafe where
data Z a where
U :: Z ()
B :: Z Bool
unsafe1 :: Z a -> Z a -> a
unsafe1 B U = ()
unsafe2 :: a ~ b => Z b -> Z a -> a
unsafe2 B U = ()
unsafe3 :: a ~ b => Z a -> Z b -> a
unsafe3 B U = True
```
But they are all accepted. In unsafe1 it seems pattern matching on the second argument discards any information learned from pattern matching on the first, while in the other two functions it seems the equality constraints are not checked at all.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| 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":"GADT type checking too liberal","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I would expect the following three functions to fail:\r\n\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nmodule Unsafe where\r\n\r\ndata Z a where\r\n U :: Z ()\r\n B :: Z Bool\r\n\r\nunsafe1 :: Z a -> Z a -> a\r\nunsafe1 B U = ()\r\n\r\nunsafe2 :: a ~ b => Z b -> Z a -> a\r\nunsafe2 B U = ()\r\n\r\nunsafe3 :: a ~ b => Z a -> Z b -> a\r\nunsafe3 B U = True\r\n}}}\r\n\r\nBut they are all accepted. In unsafe1 it seems pattern matching on the second argument discards any information learned from pattern matching on the first, while in the other two functions it seems the equality constraints are not checked at all.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3652Gettting error while running configure2019-07-07T19:02:57ZcheramGettting error while running configureHI,
While i run the configure i am getting the following error.
Please suggest me how to overcome.
```
x86_32/bin:/arm/tools/arm/lyra-pkg/2.01/common:/arm/tools/arm/depot-build/2.01/common/bin:/arm/tools/arm/depot-build/2.01/rhe4-x86_...HI,
While i run the configure i am getting the following error.
Please suggest me how to overcome.
```
x86_32/bin:/arm/tools/arm/lyra-pkg/2.01/common:/arm/tools/arm/depot-build/2.01/common/bin:/arm/tools/arm/depot-build/2.01/rhe4-x86_32/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Which we'll further canonicalise into: i386-unknown-linux
checking for path to top of build tree... pwd: timer_create: Invalid argument
configure: error: cannot determine current directory
tmk: child process exited abnormally
tmk: tmk: exiting.
tmk: exiting.
while executing
"error "${::__OutputPrefix} exiting.""
invoked from within
"if $::__DbgLevel {
```
Thanks,
Chetanhttps://gitlab.haskell.org/ghc/ghc/-/issues/3653"Missing header file: HsDirectory.h" with old kernel/glibc2019-07-07T19:02:57Zroland"Missing header file: HsDirectory.h" with old kernel/glibcConfiguring ghc-6.12.1rc1 on a machine with linux kernel 2.6.9 and glibc 2.3.4 gives:
```
$ ./configure
[...]
Configuring directory-1.0.1.0...
[...]
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h...Configuring ghc-6.12.1rc1 on a machine with linux kernel 2.6.9 and glibc 2.3.4 gives:
```
$ ./configure
[...]
Configuring directory-1.0.1.0...
[...]
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h
ghc-cabal: Missing dependency on a foreign library:
* Missing header file: HsDirectory.h
[...]
```
The file `HsDirectory.h` is actually there, but it fails to compile.
```
$ cd libraries/directory
$ runhaskell Setup configure -v3
[...]
include/HsDirectory.h:58: error: syntax error before "__hscore_S_IRUSR"
include/HsDirectory.h:59: error: syntax error before "__hscore_S_IWUSR"
include/HsDirectory.h:60: error: syntax error before "__hscore_S_IXUSR"
include/HsDirectory.h:61: error: syntax error before "__hscore_S_IFDIR"
[...]
```
The problem can be fixed by adding `#include <sys/types.h>` at the beginning of `HsDirectory.h`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Missing header file: HsDirectory.h\" with old kernel/glibc","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Configuring ghc-6.12.1rc1 on a machine with linux kernel 2.6.9 and glibc 2.3.4 gives:\r\n{{{\r\n$ ./configure\r\n[...]\r\nConfiguring directory-1.0.1.0...\r\n[...]\r\nconfigure: creating ./config.status\r\nconfig.status: creating include/HsDirectoryConfig.h\r\nghc-cabal: Missing dependency on a foreign library:\r\n* Missing header file: HsDirectory.h\r\n[...]\r\n}}}\r\nThe file {{{HsDirectory.h}}} is actually there, but it fails to compile.\r\n{{{\r\n$ cd libraries/directory\r\n$ runhaskell Setup configure -v3\r\n[...]\r\ninclude/HsDirectory.h:58: error: syntax error before \"__hscore_S_IRUSR\"\r\ninclude/HsDirectory.h:59: error: syntax error before \"__hscore_S_IWUSR\"\r\ninclude/HsDirectory.h:60: error: syntax error before \"__hscore_S_IXUSR\"\r\ninclude/HsDirectory.h:61: error: syntax error before \"__hscore_S_IFDIR\"\r\n[...]\r\n}}}\r\nThe problem can be fixed by adding {{{#include <sys/types.h>}}} at the beginning of {{{HsDirectory.h}}}.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3654Mach-O GHCi linker lacks support for a range of relocation entries2020-07-06T18:44:07ZManuel M T ChakravartyMach-O GHCi linker lacks support for a range of relocation entriesThe Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries. It used to silently ignore many of them. The following patch makes it barf() when it encounters an unsupported entry:
```
Wed Nov 11 13:0...The Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries. It used to silently ignore many of them. The following patch makes it barf() when it encounters an unsupported entry:
```
Wed Nov 11 13:07:12 EST 2009 Manuel M T Chakravarty <chak@cse.unsw.edu.au>
* Barf on unhandled Mach-O relocations in the ghci linker
- It might be worthwhile to MERGE this to 6.12, BUT somebody should validate
it on PPC/Mac OS X first.
```
Moreover, at least one entry type —i.e., `GENERIC_RELOC_LOCAL_SECTDIFF`— is not correctly implemented.
This is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed. In that case, changes in `ld` suddenly created a so far unsupported entry type. This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS.
Instead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with `dlopen()` and leave the implementation of dynamic linking to the OS vendor. This has a number of advantages:
- The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs.
- Dynamically loaded code can use dtrace probes (and other features requiring linker trickery).
- Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked).
- Potential performance advantage due to optimisations in the OS' dynamic linker.
The main obstacle with using dynamic libraries and `dlopen()` appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries. Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use `dlopen()` for loading packages.
More details are in the following thread on `cvs-ghc@haskell.org`:
> [http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html](http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html)
> [http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html](http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Mach-O GHCi linker lacks support for a range of relocation entries","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries. It used to silently ignore many of them. The following patch makes it barf() when it encounters an unsupported entry:\r\n{{{\r\nWed Nov 11 13:07:12 EST 2009 Manuel M T Chakravarty <chak@cse.unsw.edu.au>\r\n * Barf on unhandled Mach-O relocations in the ghci linker\r\n \r\n - It might be worthwhile to MERGE this to 6.12, BUT somebody should validate\r\n it on PPC/Mac OS X first.\r\n}}}\r\nMoreover, at least one entry type —i.e., `GENERIC_RELOC_LOCAL_SECTDIFF`— is not correctly implemented.\r\n\r\nThis is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed. In that case, changes in `ld` suddenly created a so far unsupported entry type. This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS.\r\n\r\nInstead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with `dlopen()` and leave the implementation of dynamic linking to the OS vendor. This has a number of advantages:\r\n * The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs.\r\n * Dynamically loaded code can use dtrace probes (and other features requiring linker trickery).\r\n * Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked).\r\n * Potential performance advantage due to optimisations in the OS' dynamic linker.\r\n\r\nThe main obstacle with using dynamic libraries and `dlopen()` appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries. Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use `dlopen()` for loading packages.\r\n\r\nMore details are in the following thread on `cvs-ghc@haskell.org`:\r\n [http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html]\r\n [http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html]\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3655Performance regression relative to 6.102019-07-07T19:02:56ZSimon MarlowPerformance regression relative to 6.10The attached program runs more slowly when compiled with 6.12 compared to 6.10. The current HEAD is also worse than 6.10, but not as bad as 6.12.
The results are below, on x86-64/Linux, first with -O:
```
time all...The attached program runs more slowly when compiled with 6.12 compared to 6.10. The current HEAD is also worse than 6.10, but not as bad as 6.12.
The results are below, on x86-64/Linux, first with -O:
```
time allocation
6.10.2 9.6s 6.5GB
6.12.20091011 11.0s 7.5GB
6.13.20091111 10.2s 6.2GB
```
Interestingly, `-O2` makes things even worse with 6.12, but makes things slightly better with both 6.10 and 6.13:
```
time allocation
6.10.2 9.5s 6.5GB
6.12.20091011 11.8s 7.5GB
6.13.20091111 10.1s 6.2GB
```
It may be that there is some degradation due to the new IO library, since the program generates a fair amount of output. That may account for some of the difference between 6.10.2 and 6.12/6.13, but it doesn't account for the difference between 6.12 and 6.13, which are both using the new IO library.
The program is in one module, compile with no special options. To run it:
```
./pHlcm mushroom.dat 100 >/dev/null +RTS -s
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Performance regression relative to 6.10","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program runs more slowly when compiled with 6.12 compared to 6.10. The current HEAD is also worse than 6.10, but not as bad as 6.12.\r\n\r\nThe results are below, on x86-64/Linux, first with -O:\r\n\r\n{{{\r\n time allocation\r\n6.10.2 9.6s 6.5GB\r\n6.12.20091011 11.0s 7.5GB\r\n6.13.20091111 10.2s 6.2GB\r\n}}}\r\n\r\nInterestingly, `-O2` makes things even worse with 6.12, but makes things slightly better with both 6.10 and 6.13:\r\n\r\n{{{\r\n time allocation\r\n6.10.2 9.5s 6.5GB\r\n6.12.20091011 11.8s 7.5GB\r\n6.13.20091111 10.1s 6.2GB\r\n}}}\r\n\r\nIt may be that there is some degradation due to the new IO library, since the program generates a fair amount of output. That may account for some of the difference between 6.10.2 and 6.12/6.13, but it doesn't account for the difference between 6.12 and 6.13, which are both using the new IO library.\r\n\r\nThe program is in one module, compile with no special options. To run it:\r\n\r\n{{{\r\n./pHlcm mushroom.dat 100 >/dev/null +RTS -s\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3656ghci leaves /tmp/ghc* directory if killed by signal2019-07-07T19:02:56Zvvvghci leaves /tmp/ghc* directory if killed by signalI was wondering where do numerous /tmp/ghc${PID}_0 directories come
from. And noticed that they are not removed when I kill (close)
'\*haskell\*' Emacs buffer instead of typing ':q' in ghci prompt...
I've investigated this problem down ...I was wondering where do numerous /tmp/ghc${PID}_0 directories come
from. And noticed that they are not removed when I kill (close)
'\*haskell\*' Emacs buffer instead of typing ':q' in ghci prompt...
I've investigated this problem down to ghci: when ghci has an .hs file
`:load`-ed and is killed with SIGHUP or SIGTERM signal, it leaves
/tmp/ghc${PID}_0 directory.
```
$ ls -d /tmp/ghc*
ls: cannot access /tmp/ghc*: No such file or directory
$ ghci *.hs &
[1] 26384
$ GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( proxy-POC.hs, interpreted )
Ok, modules loaded: Main.
*Main>
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
[1]+ Stopped ghci *.hs
$ kill -HUP %%
[1]+ Stopped ghci *.hs
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
[1]+ Hangup ghci *.hs
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
$ pgrep ghc
$ ps 26384
PID TTY STAT TIME COMMAND
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | valery.vv@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci leaves /tmp/ghc* directory if killed by signal","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["valery.vv@gmail.com"],"type":"Bug","description":"I was wondering where do numerous /tmp/ghc${PID}_0 directories come\r\nfrom. And noticed that they are not removed when I kill (close)\r\n'*haskell*' Emacs buffer instead of typing ':q' in ghci prompt...\r\n\r\nI've investigated this problem down to ghci: when ghci has an .hs file\r\n`:load`-ed and is killed with SIGHUP or SIGTERM signal, it leaves\r\n/tmp/ghc${PID}_0 directory.\r\n\r\n{{{\r\n$ ls -d /tmp/ghc*\r\nls: cannot access /tmp/ghc*: No such file or directory\r\n$ ghci *.hs &\r\n[1] 26384\r\n$ GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( proxy-POC.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> \r\n$ ls -d /tmp/ghc*\r\n/tmp/ghc26384_0\r\n\r\n[1]+ Stopped ghci *.hs\r\n$ kill -HUP %%\r\n\r\n[1]+ Stopped ghci *.hs\r\n$ ls -d /tmp/ghc*\r\n/tmp/ghc26384_0\r\n[1]+ Hangup ghci *.hs\r\n$ ls -d /tmp/ghc*\r\n/tmp/ghc26384_0\r\n$ pgrep ghc\r\n$ ps 26384\r\n PID TTY STAT TIME COMMAND\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3657ffi-1.0 causes panic in 6.12.200910102019-07-07T19:02:56Ztobsanffi-1.0 causes panic in 6.12.20091010After upgrading GHC to 6.12, any Haskell file I try to compile yields this result:\[\[BR\]\]
```
tobsan@magrathea ~/programming/HQmpd/src $ ghci Test.hs
GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help
Loading pac...After upgrading GHC to 6.12, any Haskell file I try to compile yields this result:\[\[BR\]\]
```
tobsan@magrathea ~/programming/HQmpd/src $ ghci Test.hs
GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
ghc-stage2: This ELF file contains no symtab
Loading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened)
(GHC version 6.12.0.20091010 for x86_64-unknown-linux):
loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```
tobsan@magrathea ~/programming/HQmpd/src $ cat Test.hs
module Test where
hej = print "Hej"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"fff-1.0 causes panic in 6.12.20091010","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After upgrading GHC to 6.12, any Haskell file I try to compile yields this result:[[BR]]\r\n\r\n{{{\r\ntobsan@magrathea ~/programming/HQmpd/src $ ghci Test.hs\r\nGHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nghc-stage2: This ELF file contains no symtab\r\nLoading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 6.12.0.20091010 for x86_64-unknown-linux):\r\n\tloadObj: failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n{{{\r\ntobsan@magrathea ~/programming/HQmpd/src $ cat Test.hs \r\nmodule Test where\r\n\r\nhej = print \"Hej\"\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3658Dynamically link GHCi (and use system linker) on platforms that support it2022-06-06T18:41:01ZSimon MarlowDynamically link GHCi (and use system linker) on platforms that support itIn 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress).
## Advantages
- The GHCi binary is smalle...In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress).
## Advantages
- The GHCi binary is smaller
- some packages don't need to be loaded on startup: lower memory use
- GHCi startup might be quicker (or it might not)
- some hacks due to having two copies of the base package are not
necessary (see `rts/Globals.c`)
- We might save some space in the distributions.
- It takes us a step closer to not needing the RTS linker at all
- It takes us a step closer to using dynamic linking by default, which
is where we want to go ultimately
## Potential Issues
- Do we run into any problems with GHCi and the user program sharing the same
stdin/stdout/stderr handles? Do we need to virtualise these explicitly in the
GHCi front end?
- We cannot revert CAFs in packages that are shared by GHC and the user program.
There are some old non-working hacks related to reverting CAFs when GHCi is
dynamically linked (see `KeepCAFsForGHCi`) that
need to be cleaned out. CAFs can only be reverted in code loaded by the RTS
linker. We need to think about whether this is a necessary feature or not:
we have never supported CAF reverting for interpreted code anyway. One
reason to have it was so that you can recover after saying `getContents` at
the GHCi prompt, but we can provide other ways to work around that. However, if
we eliminated HEAP_ALLOCED (#8199), as a side effect of this implementation,
this might be doable, as we no longer have to reach our fingers into the
data section of dynamically linked in libraries to revert a CAF; all of the CAFs
are copied to dynamic memory space first. (The current implementation doesn't
work for that, however!)
- There will be installation/binary-dist issues to resolve; currently we don't
install any dynamically-linked binaries.
## Open questions
- Whether we continue to use the same binary for GHC and GHCi is an open question:
it would be possible to provide a separate statically-linked GHC binary if
performance of the dynamically-linked version was an issue.
- We might as well dynamically-link Haddock, and the other tools that come
with GHC too.7.10.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/3659two-dimensional PArrays in data parallel code2019-07-07T19:02:54Zamstwo-dimensional PArrays in data parallel codeHi -- Is it possible to create two-dimensional PArrays? It seems like an expression like
```
fromList [fromList [1]]
```
would do it (where fromList is from Data.Array.Parallel.Prelude), but a type class constraint seems not to be m...Hi -- Is it possible to create two-dimensional PArrays? It seems like an expression like
```
fromList [fromList [1]]
```
would do it (where fromList is from Data.Array.Parallel.Prelude), but a type class constraint seems not to be matched here:
```
No instance for (Elt (PArray Int))
arising from a use of `fromList' at Main.hs:8:16-42
Possible fix: add an instance declaration for (Elt (PArray Int))
```
(Details below.) Are there any other ways?
Thanks -- Adam Shaw
```
$ cat Main.hs
import Data.Array.Parallel.PArray as P
main :: IO ()
main
= do
let v2D = P.fromList [P.fromList [1::Int]]
print v2D
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.13.20090929
$ ghc -fdph-seq Main.hs
Main.hs:6:16:
No instance for (Elt (PArray Int))
arising from a use of `fromList' at Main.hs:6:16-47
Possible fix: add an instance declaration for (Elt (PArray Int))
In the expression: fromList [fromList [1 :: Int]]
In the definition of `v2D': v2D = fromList [fromList [1 :: Int]]
In the expression:
do { let v2D = fromList ...;
print v2D }
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"two-dimensional PArrays in data parallel code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Hi -- Is it possible to create two-dimensional PArrays? It seems like an expression like\r\n\r\n{{{\r\n fromList [fromList [1]]\r\n}}}\r\n\r\nwould do it (where fromList is from Data.Array.Parallel.Prelude), but a type class constraint seems not to be matched here:\r\n{{{\r\n No instance for (Elt (PArray Int))\r\n arising from a use of `fromList' at Main.hs:8:16-42\r\n Possible fix: add an instance declaration for (Elt (PArray Int))\r\n}}}\r\n(Details below.) Are there any other ways?\r\n\r\nThanks -- Adam Shaw\r\n\r\n{{{\r\n$ cat Main.hs\r\nimport Data.Array.Parallel.PArray as P\r\n\r\nmain :: IO ()\r\nmain\r\n = do\r\n let v2D = P.fromList [P.fromList [1::Int]]\r\n print v2D\r\n\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.13.20090929\r\n\r\n$ ghc -fdph-seq Main.hs\r\n\r\nMain.hs:6:16:\r\n No instance for (Elt (PArray Int))\r\n arising from a use of `fromList' at Main.hs:6:16-47\r\n Possible fix: add an instance declaration for (Elt (PArray Int))\r\n In the expression: fromList [fromList [1 :: Int]]\r\n In the definition of `v2D': v2D = fromList [fromList [1 :: Int]]\r\n In the expression:\r\n do { let v2D = fromList ...;\r\n print v2D }\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->rl@cse.unsw.edu.aurl@cse.unsw.edu.auhttps://gitlab.haskell.org/ghc/ghc/-/issues/3660"Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad Transformers2019-07-07T19:02:54Zjfredett"Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad TransformersSummary:
When trying to build a monad stack which involves a state transformer with a constrained state, the newtype which constrains said state (below, it is the `Filter` newtype) cannot seem to derive something within the list of thin...Summary:
When trying to build a monad stack which involves a state transformer with a constrained state, the newtype which constrains said state (below, it is the `Filter` newtype) cannot seem to derive something within the list of things it's intended to derive. After some testing I found that changing the `MonadState Bool` part of the `deriving` clause to `MonadState t` (in line with the actual state parameter) made everything work. The Type of `Email` doesn't matter, I've tested to this effect (replacing `Email` with `data Email = Email` and not importing the real version, it still compiles fine in the fixed case, and does not compile in the broken case).
I have not tested on GHC 6.12 yet, I'm still trying to install it. All other system information at the bottom.
By the looks of it, this is a case of GHC not noticing I'm doing something silly, and not reporting something along the lines of the "This isn't polymorphic enough" error.
Broken Code:
```
type Context = ReaderT Email
type Match t = StateT t IO
type ContextMatch t a = Context (Match t) a
newtype FilterState t => Filter t a = Filter (ContextMatch t a)
deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO)
class FilterState t where
data FState t
deliver :: FState t -> IO ()
```
Error:
```
[1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/HackMail/Email/ParseEmail.hs, interpreted )
[2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/Email/Email.hs, interpreted )
[3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/Filter/Filter.hs, interpreted )
*** Exception: No match in record selector Var.tcTyVarDetails
```
Fixed Code:
```
type Context = ReaderT Email
type Match t = StateT t IO
type ContextMatch t a = Context (Match t) a
-- changed `Bool` to `t`.
newtype FilterState t => Filter t a = Filter (ContextMatch t a)
deriving (Functor, Monad, MonadReader Email, MonadState t, MonadIO)
class FilterState t where
data FState t
deliver :: FState t -> IO ()
```
System Info:
```
[jfredett@Erdos]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
[jfredett@Erdos]$ uname -a
Linux Erdos 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST 2009 i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux
```
(Possibly) Related Tickets include: 3621, 3422 and 2714
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"\"Var.tcTyVarDetails\" exception w/ Assoc. Datatypes and Monad Transformers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["Associated","Datatypes","Monad","Transformers,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Summary:\r\n\r\nWhen trying to build a monad stack which involves a state transformer with a constrained state, the newtype which constrains said state (below, it is the `Filter` newtype) cannot seem to derive something within the list of things it's intended to derive. After some testing I found that changing the `MonadState Bool` part of the `deriving` clause to `MonadState t` (in line with the actual state parameter) made everything work. The Type of `Email` doesn't matter, I've tested to this effect (replacing `Email` with `data Email = Email` and not importing the real version, it still compiles fine in the fixed case, and does not compile in the broken case). \r\n\r\nI have not tested on GHC 6.12 yet, I'm still trying to install it. All other system information at the bottom.\r\n\r\nBy the looks of it, this is a case of GHC not noticing I'm doing something silly, and not reporting something along the lines of the \"This isn't polymorphic enough\" error. \r\n\r\n\r\n\r\nBroken Code:\r\n{{{\r\ntype Context = ReaderT Email\r\ntype Match t = StateT t IO\r\ntype ContextMatch t a = Context (Match t) a\r\n\r\nnewtype FilterState t => Filter t a = Filter (ContextMatch t a)\r\n deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO)\r\n\r\nclass FilterState t where\r\n data FState t\r\n deliver :: FState t -> IO ()\r\n\r\n}}}\r\n\r\nError:\r\n{{{\r\n[1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/HackMail/Email/ParseEmail.hs, interpreted )\r\n[2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/Email/Email.hs, interpreted )\r\n[3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/Filter/Filter.hs, interpreted )\r\n*** Exception: No match in record selector Var.tcTyVarDetails\r\n}}}\r\n\r\nFixed Code:\r\n{{{ \r\ntype Context = ReaderT Email\r\ntype Match t = StateT t IO\r\ntype ContextMatch t a = Context (Match t) a\r\n\r\n-- changed `Bool` to `t`.\r\nnewtype FilterState t => Filter t a = Filter (ContextMatch t a)\r\n deriving (Functor, Monad, MonadReader Email, MonadState t, MonadIO)\r\n\r\nclass FilterState t where\r\n data FState t\r\n deliver :: FState t -> IO ()\r\n}}}\r\nSystem Info:\r\n{{{\r\n[jfredett@Erdos]$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.4\r\n[jfredett@Erdos]$ uname -a\r\nLinux Erdos 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST 2009 i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux\r\n}}}\r\n\r\n(Possibly) Related Tickets include: 3621, 3422 and 2714","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3661Profiling GHC HEAD broken under OSX.2019-07-07T19:02:54ZpejoProfiling GHC HEAD broken under OSX.If I pull latest HEAD, with the following contents in build.mk:
```
BuildFlavour = prof
```
and then build under OSX it errors out with:
```
"inplace/bin/ghc-stage1" -prof -H32m -O -package-name ghc-6.13.20091112 -hide-all-package...If I pull latest HEAD, with the following contents in build.mk:
```
BuildFlavour = prof
```
and then build under OSX it errors out with:
```
"inplace/bin/ghc-stage1" -prof -H32m -O -package-name ghc-6.13.20091112 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.8.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package template-haskell-2.4.0.0 -package unix-2.4.0.0 -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c compiler/main/Finder.lhs -o compiler/stage2/build/Finder.p_o
Undefined symbols:
"_CCCS", referenced from:
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [utils/runghc/dist/build/tmp/runghc] Error 1
make[1]: *** Waiting for unfinished jobs....
Undefined symbols:
"_CCCS", referenced from:
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
Undefined symbols:
"_CCCS", referenced from:
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [utils/hpc/dist/build/tmp/hpc] Error 1
Undefined symbols:
"_CCCS", referenced from:
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
_integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [utils/ghc-pkg/dist-install/build/tmp/ghc-pkg] Error 1
make: *** [all] Error 2
```
This does not happen to me with the build.mk without profiling from the developers wiki.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"Profiling GHC HEAD broken under OSX.","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I pull latest HEAD, with the following contents in build.mk:\r\n{{{\r\nBuildFlavour = prof\r\n}}}\r\nand then build under OSX it errors out with:\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -prof -H32m -O -package-name ghc-6.13.20091112 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.8.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package template-haskell-2.4.0.0 -package unix-2.4.0.0 -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c compiler/main/Finder.lhs -o compiler/stage2/build/Finder.p_o\r\nUndefined symbols:\r\n \"_CCCS\", referenced from:\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\nld: symbol(s) not found\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [utils/runghc/dist/build/tmp/runghc] Error 1\r\nmake[1]: *** Waiting for unfinished jobs....\r\nUndefined symbols:\r\n \"_CCCS\", referenced from:\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\nld: symbol(s) not found\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1\r\nUndefined symbols:\r\n \"_CCCS\", referenced from:\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\nld: symbol(s) not found\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [utils/hpc/dist/build/tmp/hpc] Error 1\r\nUndefined symbols:\r\n \"_CCCS\", referenced from:\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\n _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp-wrappers.o)\r\nld: symbol(s) not found\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [utils/ghc-pkg/dist-install/build/tmp/ghc-pkg] Error 1\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nThis does not happen to me with the build.mk without profiling from the developers wiki.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3662Don't know how to install documentation2019-07-07T19:02:54ZbosDon't know how to install documentationFollowing the changes to the build system that got merged in earlier this year, it's no longer obvious (or documented, as far as I can tell) how to either build or install documentation.
The procedure that used to work for 6.10 was `mak...Following the changes to the build system that got merged in earlier this year, it's no longer obvious (or documented, as far as I can tell) how to either build or install documentation.
The procedure that used to work for 6.10 was `make install-docs`, but the `Makefile`s in the `docs` and `docs/man` directories have bit-rotted, and the `install-docs` target has vanished from the top-level `Makefile` too.
If I knew how to build the documentation, I'd send in a patch, as I think it's important that this be fixed before 6.12.1 goes final, so that platform packagers like myself can figure out how to easily build and install the documentation. Unfortunately, I'm not even sure what needs fixing in the new build world.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Don't know how to install documentation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Following the changes to the build system that got merged in earlier this year, it's no longer obvious (or documented, as far as I can tell) how to either build or install documentation.\r\n\r\nThe procedure that used to work for 6.10 was {{{make install-docs}}}, but the {{{Makefile}}}s in the {{{docs}}} and {{{docs/man}}} directories have bit-rotted, and the {{{install-docs}}} target has vanished from the top-level {{{Makefile}}} too.\r\n\r\nIf I knew how to build the documentation, I'd send in a patch, as I think it's important that this be fixed before 6.12.1 goes final, so that platform packagers like myself can figure out how to easily build and install the documentation. Unfortunately, I'm not even sure what needs fixing in the new build world.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3663Unreg build fails when haddocking dph-seq2019-07-07T19:02:53ZSimon MarlowUnreg build fails when haddocking dph-seqThe unregisterised HEAD build is failing thus:
```
"inplace/bin/ghc-cabal" haddock dist-install libraries/dph/dph-seq --with-haddock=/64playpen/buildbot/x86_64-linux-head-unreg/build/inplace/bin/haddock --with-ghc=/64playpen/buildbot/x8...The unregisterised HEAD build is failing thus:
```
"inplace/bin/ghc-cabal" haddock dist-install libraries/dph/dph-seq --with-haddock=/64playpen/buildbot/x86_64-linux-head-unreg/build/inplace/bin/haddock --with-ghc=/64playpen/buildbot/x86_64-linux-head-unreg/build/inplace/bin/ghc-stage2 --hyperlink-source
Running Haddock for dph-seq-0.4.0...
Preprocessing library dph-seq-0.4.0...
Running hscolour for dph-seq-0.4.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: panic! (the 'impossible' happened)
(GHC version 6.13.20091112 for x86_64-unknown-linux):
This compiler was built without a native code generator
Use -fvia-C instead
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Presumably because dph-seq needs to do some dynamic compilation for its annotations, so Haddock tells it to use -fasm, but there's no native code generator.
Not clear whether this is a Haddock problem or something we need to fix in the GHC API (probably both).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"Unreg build fails when haddocking dph-seq","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The unregisterised HEAD build is failing thus:\r\n\r\n{{{\r\n\"inplace/bin/ghc-cabal\" haddock dist-install libraries/dph/dph-seq --with-haddock=/64playpen/buildbot/x86_64-linux-head-unreg/build/inplace/bin/haddock --with-ghc=/64playpen/buildbot/x86_64-linux-head-unreg/build/inplace/bin/ghc-stage2 --hyperlink-source \r\nRunning Haddock for dph-seq-0.4.0...\r\nPreprocessing library dph-seq-0.4.0...\r\nRunning hscolour for dph-seq-0.4.0...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: ffi-1.0, rts-1.0\r\nhaddock: panic! (the 'impossible' happened)\r\n (GHC version 6.13.20091112 for x86_64-unknown-linux):\r\n\tThis compiler was built without a native code generator\r\n Use -fvia-C instead\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nPresumably because dph-seq needs to do some dynamic compilation for its annotations, so Haddock tells it to use -fasm, but there's no native code generator.\r\n\r\nNot clear whether this is a Haddock problem or something we need to fix in the GHC API (probably both).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3664Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate)2019-07-07T19:02:53ZSergei TrofimovichGhc eats tremendous heaps of RAM in -prof build (highlighting-kate)Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious...Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("Project version","6.12.0.20091010")
,("Booter version","6.10.4")
,("Stage","2")
,("Have interpreter","YES")
,("Object splitting","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("Win32 DLLs","")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/usr/lib64/ghc-6.12.0.20091010")
```
```
* Using cabal-1.8.0.
[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )
Linking setup ...
Configuring highlighting-kate-0.2.5...
Flags chosen: executable=True, splitbase=True
Dependency base >=3 && <5: using base-4.2.0.0
Dependency containers -any: using containers-0.3.0.0
Dependency filepath -any: using filepath-1.1.0.3
Dependency parsec <3: using parsec-2.1.0.1
Dependency pcre-light -any: using pcre-light-0.3.1
Dependency xhtml -any: using xhtml-3000.2.0.1
Using Cabal-1.8.0 compiled by ghc-6.12
Using compiler: ghc-6.12.0.20091010
```
1. ..
```
/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010
Preprocessing library highlighting-kate-0.2.5...
Preprocessing executables for highlighting-kate-0.2.5...
Building highlighting-kate-0.2.5...
```
1. ..
```
[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )
Ctrl+C
VIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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 eats tremendous heaps of RAM in -prof build (highlighting-kate)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tried to build '''highlighting-kate-0.2.5''' from hackage with ghc-6.12rc1\r\nand could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I\r\nstopped it as machine swapped horribly.\r\n\r\n{{{\r\n$ ghc --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"Project version\",\"6.12.0.20091010\")\r\n ,(\"Booter version\",\"6.10.4\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting\",\"YES\")\r\n ,(\"Have native code generator\",\"YES\")\r\n ,(\"Support SMP\",\"YES\")\r\n ,(\"Unregisterised\",\"NO\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"Win32 DLLs\",\"\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn\")\r\n ,(\"Leading underscore\",\"NO\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/usr/lib64/ghc-6.12.0.20091010\")\r\n}}}\r\n\r\n{{{\r\n * Using cabal-1.8.0.\r\n[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )\r\nLinking setup ...\r\nConfiguring highlighting-kate-0.2.5...\r\nFlags chosen: executable=True, splitbase=True\r\nDependency base >=3 && <5: using base-4.2.0.0\r\nDependency containers -any: using containers-0.3.0.0\r\nDependency filepath -any: using filepath-1.1.0.3\r\nDependency parsec <3: using parsec-2.1.0.1\r\nDependency pcre-light -any: using pcre-light-0.3.1\r\nDependency xhtml -any: using xhtml-3000.2.0.1\r\nUsing Cabal-1.8.0 compiled by ghc-6.12\r\nUsing compiler: ghc-6.12.0.20091010\r\n}}}\r\n...\r\n{{{\r\n/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010\r\nPreprocessing library highlighting-kate-0.2.5...\r\nPreprocessing executables for highlighting-kate-0.2.5...\r\nBuilding highlighting-kate-0.2.5...\r\n}}}\r\n...\r\n{{{\r\n[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )\r\n \r\nCtrl+C\r\nVIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3665Add whole-package deprecation warnings2019-07-07T19:02:53ZduncanAdd whole-package deprecation warningsWith GHC-6.12 if you use base 3 you get:
```
Warning: Module `Prelude' is deprecated:
[You are using an old version of base. Future
GHC versions will not support this version, so you need to
update your code to use ...With GHC-6.12 if you use base 3 you get:
```
Warning: Module `Prelude' is deprecated:
[You are using an old version of base. Future
GHC versions will not support this version, so you need to
update your code to use the new base version.]
```
This is initially a somewhat confusing warning. We're not really deprecating the Prelude!
It would be much nicer if it told us:
```
Warning: Package `base-3.0.3.2' is deprecated:
[You are using an old version of base. Future
GHC versions will not support this version, so you need to
update your code to use the new base version.]
```
The message itself could be formatted more nicely too. Patch attached for that.
Note the current spurious list syntax in the deprecation message. I've re-opened #3303 about that.
As for the syntax for package deprecations, how about just
```
module Foo {-# DEPRECATED package "the message" #-} (..) where
```
For the behaviour, how about making them behave just like module-deprecation messages in that one attaches them to a module header and they are only triggered if you import that module. The only change would be in how the message is reported; instead of saying the module is deprecated it'd give the package (including the full version).
I know this is a feature request, which usually we'd want to put off for the next major version, but since this one is all about helping maintainers and users of 6.12.1 and .2, I hope that we consider looking at it for an early 6.12 release.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add whole-package deprecation warnings","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"With GHC-6.12 if you use base 3 you get:\r\n\r\n{{{\r\n Warning: Module `Prelude' is deprecated:\r\n [You are using an old version of base. Future\r\nGHC versions will not support this version, so you need to\r\nupdate your code to use the new base version.]\r\n}}}\r\n\r\nThis is initially a somewhat confusing warning. We're not really deprecating the Prelude!\r\n\r\nIt would be much nicer if it told us:\r\n\r\n{{{\r\n Warning: Package `base-3.0.3.2' is deprecated:\r\n [You are using an old version of base. Future\r\nGHC versions will not support this version, so you need to\r\nupdate your code to use the new base version.]\r\n}}}\r\n\r\nThe message itself could be formatted more nicely too. Patch attached for that.\r\n\r\nNote the current spurious list syntax in the deprecation message. I've re-opened #3303 about that.\r\n\r\nAs for the syntax for package deprecations, how about just\r\n{{{\r\nmodule Foo {-# DEPRECATED package \"the message\" #-} (..) where\r\n}}}\r\n\r\nFor the behaviour, how about making them behave just like module-deprecation messages in that one attaches them to a module header and they are only triggered if you import that module. The only change would be in how the message is reported; instead of saying the module is deprecated it'd give the package (including the full version).\r\n\r\nI know this is a feature request, which usually we'd want to put off for the next major version, but since this one is all about helping maintainers and users of 6.12.1 and .2, I hope that we consider looking at it for an early 6.12 release.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3666Binary: Int64 truncated to fit in 32 bit Int2019-07-07T19:02:52ZguestBinary: Int64 truncated to fit in 32 bit IntI'm a complete Haskell noob, but code that I wrote and loaded and ran in GHCI fine didn't compile with ghc --make:
```
$ ghc --make test.hs
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
(GHC vers...I'm a complete Haskell noob, but code that I wrote and loaded and ran in GHCI fine didn't compile with ghc --make:
```
$ ghc --make test.hs
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-linux):
Prelude.chr: bad argument
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Binary: Int64 truncated to fit in 32 bit Int","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm a complete Haskell noob, but code that I wrote and loaded and ran in GHCI fine didn't compile with ghc --make:\r\n\r\n{{{\r\n$ ghc --make test.hs\r\nBinary: Int64 truncated to fit in 32 bit Int\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-linux):\r\n\tPrelude.chr: bad argument\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/3667Overly specific type inference.2019-07-07T19:02:52ZSean Erle JohnsonOverly specific type inference.The inferred type for perms in the following code is too specific:
```
import Data.List
main = print $ perms 4 [1..4]
test = perms 4 ['1'..'4']
perms = combBase delete
combBase :: (a -> [a] -> [a]) -> Int -> [a] -> [[a]]
combBase ...The inferred type for perms in the following code is too specific:
```
import Data.List
main = print $ perms 4 [1..4]
test = perms 4 ['1'..'4']
perms = combBase delete
combBase :: (a -> [a] -> [a]) -> Int -> [a] -> [[a]]
combBase next = worker
where worker 0 _ = [[]]
worker _ [] = [[]]
worker l xs = concatMap (\x -> map (x:) (worker (l-1) (next x xs))) xs
```
Compiling with ghc (with the --make switch) yields:
```
TypeInferenceBug.hs:3:24:
No instance for (Num Char)
arising from the literal `1' at TypeInferenceBug.hs:3:24
Possible fix: add an instance declaration for (Num Char)
In the expression: 1
In the second argument of `perms', namely `[1 .. 4]'
In the second argument of `($)', namely `perms 4 ([1 .. 4])'
```
Typing ":t perms" into ghci gives the following signature (after the main function is commented out):
```
perms :: Int -> [Char] -> [[Char]]
```
Compiling occurs without complaint when perms is given the explicit (and more general) type signature and ghci reports the correct type signature:
```
perms :: Eq a => Int -> [a] -> [[a]]
perms = combBase delete
```
The type is correctly inferred for combBase regardless of if it has an explicit type signature or not.
I tested this on Windows but not on Linux yet, though I suspect that this problem is architecture-independent.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Overly specific type inference.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The inferred type for perms in the following code is too specific:\r\n\r\n{{{\r\nimport Data.List\r\n\r\nmain = print $ perms 4 [1..4]\r\n\r\ntest = perms 4 ['1'..'4']\r\n\r\nperms = combBase delete \r\n\r\ncombBase :: (a -> [a] -> [a]) -> Int -> [a] -> [[a]]\r\ncombBase next = worker\r\n where worker 0 _ = [[]]\r\n worker _ [] = [[]]\r\n worker l xs = concatMap (\\x -> map (x:) (worker (l-1) (next x xs))) xs\r\n}}}\r\n\r\nCompiling with ghc (with the --make switch) yields:\r\n\r\n{{{\r\nTypeInferenceBug.hs:3:24:\r\n No instance for (Num Char)\r\n arising from the literal `1' at TypeInferenceBug.hs:3:24\r\n Possible fix: add an instance declaration for (Num Char)\r\n In the expression: 1\r\n In the second argument of `perms', namely `[1 .. 4]'\r\n In the second argument of `($)', namely `perms 4 ([1 .. 4])'\r\n}}}\r\n\r\nTyping \":t perms\" into ghci gives the following signature (after the main function is commented out):\r\n\r\n{{{\r\nperms :: Int -> [Char] -> [[Char]]\r\n}}}\r\n\r\nCompiling occurs without complaint when perms is given the explicit (and more general) type signature and ghci reports the correct type signature:\r\n\r\n{{{\r\nperms :: Eq a => Int -> [a] -> [[a]]\r\nperms = combBase delete \r\n}}}\r\n\r\nThe type is correctly inferred for combBase regardless of if it has an explicit type signature or not. \r\n\r\nI tested this on Windows but not on Linux yet, though I suspect that this problem is architecture-independent.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3668PIE-enabled hardened gcc might broke GHC.2023-05-08T13:54:25ZsecludedsagePIE-enabled hardened gcc might broke GHC.```
emerge --info:
Portage 2.1.7.4 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r0, 2.6.31-11-generic i686)
=================================================================
System uname: Linux-2.6.31-11-generic-i686-Genuine...```
emerge --info:
Portage 2.1.7.4 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r0, 2.6.31-11-generic i686)
=================================================================
System uname: Linux-2.6.31-11-generic-i686-Genuine_Intel-R-_CPU_T2050_@_1.60GHz-with-gentoo-2.0.1
Timestamp of tree: Sat, 14 Nov 2009 05:45:01 +0000
app-shells/bash: 4.0_p35
dev-lang/python: 2.6.4, 3.1.1-r1
sys-apps/baselayout: 2.0.1
sys-apps/openrc: 0.5.2-r1
sys-apps/sandbox: 2.2
sys-devel/autoconf: 2.63-r1
sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11
sys-devel/binutils: 2.20
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.6a
virtual/os-headers: 2.6.30-r1
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="*"
MAKEOPTS="-j3"
```
While I am building yi-editor, I get:
```
Building yi-0.6.1...
[ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs,
dist/build/System/FriendlyPath.o )
[ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs,
dist/build/Shim/ProjectContent.o )
[ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs,
dist/build/Parser/Incremental.o )
[ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o
)
[ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs,
dist/build/Data/DelayList.o )
[ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o
)
[ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs,
dist/build/Data/Prototype.o )
[ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs,
dist/build/HConf/Utils.o )
[ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs,
dist/build/HConf/Paths.o )
[ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs,
dist/build/Paths_yi.o )
[ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o )
[ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs,
dist/build/Yi/Char/Unicode.o )
[ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot,
dist/build/Yi/UI/Common.o-boot )
[ 14 of 119] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o
)
[ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o )
[ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs,
dist/build/Yi/Keymap/Completion.o )
[ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot,
dist/build/Yi/Editor.o-boot )
[ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o )
[ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs,
dist/build/Yi/Prelude.o )
[ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs,
dist/build/Yi/Dynamic.o )
[ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o )
[ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs,
dist/build/Yi/Interact.o )
[ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot,
dist/build/Yi/Keymap.o-boot )
[ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o )
[ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs,
dist/build/Yi/Style/Library.o )
[ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs,
dist/build/Yi/Interpreter.o )
[ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs,
dist/build/Shim/Utils.o )
[ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs,
dist/build/Shim/CabalInfo.o )
[ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot,
dist/build/Yi/Buffer/Misc.o-boot )
[ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs,
dist/build/Yi/Buffer/Basic.o )
ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol
`_GLOBAL_OFFSET_TABLE_'
Loading package ghc-prim ... linking ... ghc: unable to load package `ghc-prim'
```
mk/build.mk:
```
# Gentoo changes
docdir = /usr/share/doc/ghc-6.10.4
htmldir = /usr/share/doc/ghc-6.10.4
SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl-nopie -optc-fno-PIE -opta-Wa,--noexecstack
SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack
XMLDocWays=
HADDOCK_DOCS=NO
SRC_HC_OPTS+=-w
```https://gitlab.haskell.org/ghc/ghc/-/issues/3669haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: inval...2019-07-07T19:02:51ZIan Lynagh <igloo@earth.li>haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument)This change to `gen_contents_index`:
```
VERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*[ \t]//'`
```
looks like it has caused this problem for SPJ on MSYS:
```
cd libraries && sh gen_contents_index --inplace
haddock: in...This change to `gen_contents_index`:
```
VERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*[ \t]//'`
```
looks like it has caused this problem for SPJ on MSYS:
```
cd libraries && sh gen_contents_index --inplace
haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument)
make[1]: *** [libraries/index.html] Error 1
make: *** [all] Error 2
sh-3.1$
```
Presumably the problem is that the sed didn't remove what it was meant to, presumably because the '\\t' didn't end up matching the tab character in the file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This change to `gen_contents_index`:\r\n{{{\r\nVERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*[ \\t]//'`\r\n}}}\r\nlooks like it has caused this problem for SPJ on MSYS:\r\n{{{\r\ncd libraries && sh gen_contents_index --inplace\r\nhaddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument)\r\nmake[1]: *** [libraries/index.html] Error 1\r\nmake: *** [all] Error 2\r\nsh-3.1$\r\n}}}\r\nPresumably the problem is that the sed didn't remove what it was meant to, presumably because the '\\t' didn't end up matching the tab character in the file.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3670Allow RULES for higher-ranked terms2019-07-07T19:02:51Zrl@cse.unsw.edu.auAllow RULES for higher-ranked termsHere is a small code sample:
```
foo :: (forall m. m a -> m b) -> m a -> m b
foo f = f
bar :: (forall m. m a -> m a) -> m a -> m a
bar f = f
```
I'd like to specialise `foo` to `bar` whenever possible but there seems to be no way of d...Here is a small code sample:
```
foo :: (forall m. m a -> m b) -> m a -> m b
foo f = f
bar :: (forall m. m a -> m a) -> m a -> m a
bar f = f
```
I'd like to specialise `foo` to `bar` whenever possible but there seems to be no way of doing so. This doesn't work:
```
{-# RULES "foo/bar" foo = bar #-}
```
GHC complains:
```
Cannot match a monotype with `(forall (m1 :: * -> *). m1 a -> m1 b)
-> m a
-> m b'
```
Adding a signature to the rhs of the rule doesn't help. GHC doesn't accept signatures in the lhs. The following works, of course, but it's not as general:
```
{-# RULES "foo/bar" forall (f :: (forall m. m a -> m a)). foo f = bar f #-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.13 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow RULES for higher-ranked terms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Here is a small code sample:\r\n\r\n{{{\r\nfoo :: (forall m. m a -> m b) -> m a -> m b\r\nfoo f = f\r\n\r\nbar :: (forall m. m a -> m a) -> m a -> m a\r\nbar f = f\r\n}}}\r\n\r\nI'd like to specialise `foo` to `bar` whenever possible but there seems to be no way of doing so. This doesn't work:\r\n\r\n{{{\r\n{-# RULES \"foo/bar\" foo = bar #-}\r\n}}}\r\n\r\nGHC complains:\r\n\r\n{{{\r\n Cannot match a monotype with `(forall (m1 :: * -> *). m1 a -> m1 b)\r\n -> m a\r\n -> m b'\r\n}}}\r\n\r\nAdding a signature to the rhs of the rule doesn't help. GHC doesn't accept signatures in the lhs. The following works, of course, but it's not as general:\r\n\r\n{{{\r\n{-# RULES \"foo/bar\" forall (f :: (forall m. m a -> m a)). foo f = bar f #-}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3671Add partitioning functions to Data.List2019-07-07T19:02:51ZholzenspAdd partitioning functions to Data.ListThe functions `take` and `span` have recursive equivalents `takeRec` and `spanRec` that apply the same function to the remainder, i.e.
```
takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs
spanRec p xs = let (hs,ts) = span ...The functions `take` and `span` have recursive equivalents `takeRec` and `spanRec` that apply the same function to the remainder, i.e.
```
takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs
spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p xs
```
and the more generic version of `take`:
```
genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i xs
```
These functions, to me, are in the same league as `partition` and `group`, can be added with little chance of nameclashes on functions with a different meaning and are not named compositions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add partitioning functions to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":["Data.List"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The functions `take` and `span` have recursive equivalents `takeRec` and `spanRec` that apply the same function to the remainder, i.e.\r\n{{{\r\ntakeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs\r\nspanRec p xs = let (hs,ts) = span p xs in hs : spanRec p xs\r\n}}}\r\nand the more generic version of `take`:\r\n{{{\r\ngenericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i xs\r\n}}}\r\nThese functions, to me, are in the same league as `partition` and `group`, can be added with little chance of nameclashes on functions with a different meaning and are not named compositions.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3672Let Linker.c know about stg_arg_bitmaps2019-07-07T19:02:51ZBertram FelgenhauerLet Linker.c know about stg_arg_bitmapsstg_args_bitmaps is useful to make sense of AP and PAP closures on the heap, i.e. for heap inspecting code. So it would be nice if code other than the RTS that uses it worked in ghci.
<details><summary>Trac metadata</summary>
| Trac fi...stg_args_bitmaps is useful to make sense of AP and PAP closures on the heap, i.e. for heap inspecting code. So it would be nice if code other than the RTS that uses it worked in ghci.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.13 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Let Linker.c know about stg_arg_bitmaps","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"stg_args_bitmaps is useful to make sense of AP and PAP closures on the heap, i.e. for heap inspecting code. So it would be nice if code other than the RTS that uses it worked in ghci.","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3673ghc-6.12.0 does not include ghc-tarballs/ for libffi?2019-07-07T19:02:51ZJens Petersenghc-6.12.0 does not include ghc-tarballs/ for libffi?When I try to build latest ghc-6.12.0 nightly snapshots I get:
```
cp rts/sm/Scav.c rts/dist/build/sm/Scav_thr.c
"rm" -f -r libffi/build
cd libffi && /bin/gtar -zxf ../ghc-tarballs/libffi/libffi*.tar.gz
done.
"inplace/bin/mkdirhier" bo...When I try to build latest ghc-6.12.0 nightly snapshots I get:
```
cp rts/sm/Scav.c rts/dist/build/sm/Scav_thr.c
"rm" -f -r libffi/build
cd libffi && /bin/gtar -zxf ../ghc-tarballs/libffi/libffi*.tar.gz
done.
"inplace/bin/mkdirhier" bootstrapping
"inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp/
/bin/gtar: ../ghc-tarballs/libffi/libffi*.tar.gz: Cannot open: No such file or directory
/bin/gtar: Error is not recoverable: exiting now
/bin/gtar: Child returned status 2
/bin/gtar: Exiting with failure status due to previous errors
make[2]: *** [libffi/stamp.ffi.configure-shared] Error 2
```
A workaround seems to be:
mkdir ghc-tarballs ; ln -s ../libffi/tarball ghc-tarballs/libffi
I see there is http://darcs.haskell.org/ghc-tarballs/
but not in the ghc tarball. Is there supposed to be
another tarball for that or better still can system libffi
be used?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"ghc-6.12.0 does not include ghc-tarballs/ for libffi?","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to build latest ghc-6.12.0 nightly snapshots I get:\r\n\r\n{{{\r\ncp rts/sm/Scav.c rts/dist/build/sm/Scav_thr.c\r\n\"rm\" -f -r libffi/build\r\ncd libffi && /bin/gtar -zxf ../ghc-tarballs/libffi/libffi*.tar.gz\r\ndone.\r\n\"inplace/bin/mkdirhier\" bootstrapping\r\n\"inplace/bin/mkdirhier\" utils/ghc-cabal/dist/build/tmp/\r\n/bin/gtar: ../ghc-tarballs/libffi/libffi*.tar.gz: Cannot open: No such file or directory\r\n/bin/gtar: Error is not recoverable: exiting now\r\n/bin/gtar: Child returned status 2\r\n/bin/gtar: Exiting with failure status due to previous errors\r\nmake[2]: *** [libffi/stamp.ffi.configure-shared] Error 2\r\n}}}\r\n\r\nA workaround seems to be:\r\nmkdir ghc-tarballs ; ln -s ../libffi/tarball ghc-tarballs/libffi\r\n\r\nI see there is http://darcs.haskell.org/ghc-tarballs/\r\nbut not in the ghc tarball. Is there supposed to be\r\nanother tarball for that or better still can system libffi\r\nbe used?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3674Recognise language pragmas generated by custom pre-processors (run with -F)2019-07-07T19:02:50ZdorchardRecognise language pragmas generated by custom pre-processors (run with -F)A custom pre-processor might desugar terms into terms of a particular language extension, requiring a new language pragma.
Currently, any language pragmas generated by a pre-processor will be ignored once the pre-processed file is picked...A custom pre-processor might desugar terms into terms of a particular language extension, requiring a new language pragma.
Currently, any language pragmas generated by a pre-processor will be ignored once the pre-processed file is picked up by GHC again.
As a contrived example, consider foo.hs:
```
{-# OPTIONS -F -pgmF ./preprocess.sh #-}
data Foo a where MkFoo :: Foo a
```
where preprocess.sh:
{{{
\#!/bin/sh
( echo "{-\# LANGUAGE GADTs \#-}"; cat $2; ) \> $3
}}}
Currently we get this behaviour:
```
bash-3.2$ ghc foo.hs
/tmp/ghc7191_0/ghc7191_0.hspp:4:0:
Illegal generalised algebraic data declaration for `Foo'
(Use -XGADTs to allow GADTs)
In the data type declaration for `Foo'
bash-3.2$ ghc foo.hs -E
bash-3.2$ cat foo.hspp
{-# LANGUAGE GADTs #-}
{-# OPTIONS -F -pgmF ./preprocess.sh #-}
data Foo a where MkFoo :: Foo abash-3.2$
```
It would be nice if GHC noticed the new pragmas, particularly language pragmas, although perhaps not all pragmas should be picked up (maybe not new OPTION pragmas).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recognise language pragmas generated by custom pre-processors (run with -F)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dorchard"},"version":"","keywords":["customer","pre-processor"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"A custom pre-processor might desugar terms into terms of a particular language extension, requiring a new language pragma.\r\nCurrently, any language pragmas generated by a pre-processor will be ignored once the pre-processed file is picked up by GHC again. \r\n\r\nAs a contrived example, consider foo.hs:\r\n\r\n{{{\r\n{-# OPTIONS -F -pgmF ./preprocess.sh #-}\r\n\r\ndata Foo a where MkFoo :: Foo a\r\n}}}\r\n\r\nwhere preprocess.sh:\r\n\r\n{{{\r\n#!/bin/sh\r\n( echo \"{-# LANGUAGE GADTs #-}\"; cat $2; ) > $3\r\n}}}\r\n\r\nCurrently we get this behaviour:\r\n\r\n{{{\r\nbash-3.2$ ghc foo.hs\r\n\r\n/tmp/ghc7191_0/ghc7191_0.hspp:4:0:\r\n Illegal generalised algebraic data declaration for `Foo'\r\n (Use -XGADTs to allow GADTs)\r\n In the data type declaration for `Foo'\r\n\r\nbash-3.2$ ghc foo.hs -E\r\nbash-3.2$ cat foo.hspp\r\n{-# LANGUAGE GADTs #-}\r\n{-# OPTIONS -F -pgmF ./preprocess.sh #-}\r\n\r\ndata Foo a where MkFoo :: Foo abash-3.2$ \r\n}}}\r\n\r\nIt would be nice if GHC noticed the new pragmas, particularly language pragmas, although perhaps not all pragmas should be picked up (maybe not new OPTION pragmas).\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3675load fails with Literate target contents2019-07-07T19:02:50ZJeanPhilippeMoresmauload fails with Literate target contentsI am loading a target with actual contents (targetContents=Just (contents, time)). The contents are literate Haskell. I get compilation errors instead of the "preprocessing needed, interactive check disabled" error I should get. It works...I am loading a target with actual contents (targetContents=Just (contents, time)). The contents are literate Haskell. I get compilation errors instead of the "preprocessing needed, interactive check disabled" error I should get. It works if I manually set the Phase to Unlit `HsSrcFile`, but the doc says it should guess it's literate from the file extension. I'm using 6.10.4 in Windows.
`GHC.hs` line 2240:
```
Nothing <- mb_phase, Unlit _ <- startPhase src_fn = True
```
(src_fn is the file name, endings in .lhs in my case)
`DriverPhase.hs` line 146:
```
startPhase "lhs" = Unlit HsSrcFile
```
Somewhere in there we forgot to move from "/drive/dir/foo.lhs" to "lhs". We need something like tail $ takeExtension $ src_fn, and handling gracefully the case where there is no extension.
I can try to actually code the patch, but I've never tried to build GHC on my machine....7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/3677Optimizer creates stack overflow on filtered CAF2019-07-07T19:02:50ZjpetOptimizer creates stack overflow on filtered CAFThe following code creates a stack overflow at -O1 or -O2, when running with a moderately small stack (+RTS -K94k):
```
import Data.Bits
hmm :: [Integer]
hmm = filter (\n -> (n .&. (n-1))==0) [1..]
main = mapM_ print hmm
```
The lambda...The following code creates a stack overflow at -O1 or -O2, when running with a moderately small stack (+RTS -K94k):
```
import Data.Bits
hmm :: [Integer]
hmm = filter (\n -> (n .&. (n-1))==0) [1..]
main = mapM_ print hmm
```
The lambda just picks out powers of two, so that filter will skip increasingly long subsequences. It's the filter causing the overflow.
Changing hmm to \[Int\], or to be let-bound, or compiling with -O0 makes the overflow go away. Using a 95k stack also makes the overflow go away. (Below 95k, stack usage is linear with the length of the filtered-out subsequence; then it seems to cap out.)6.12.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3678rejig the build system so that dummy-ghc isn't used2019-07-07T19:02:49Zpejorejig the build system so that dummy-ghc isn't usedBuild.mk:
```
# My build settings for hacking on stage 2
SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O0 -DDEBUG -Wall -fexpose-all-unfoldings
GhcLibHcOpts = -O -fasm -XGenerics
GhcLibWa...Build.mk:
```
# My build settings for hacking on stage 2
SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O0 -DDEBUG -Wall -fexpose-all-unfoldings
GhcLibHcOpts = -O -fasm -XGenerics
GhcLibWays = v
SplitObjs = NO
GhcBootLibs = YES
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
```
The build error:
```
"inplace/bin/ghc-cabal" configure --with-ghc="/Volumes/OSXSSD/ghc/ghc.full-unfoldings/inplace/bin/dummy-ghc" --with-ghc-pkg="/Volumes/OSXSSD/ghc/ghc.full-unfoldings/inplace/bin/ghc-pkg" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --flags=stage2 --flags=ncg --flags=ghci --ghc-option=-DGHCI_TABLES_NEXT_TO_CODE --ghc-option=-DSTAGE=2 --ghc-options='-O0 -DDEBUG -Wall -fexpose-all-unfoldings' --configure-option=CFLAGS=" -m32 " --configure-option=LDFLAGS=" " -- stage2 compiler
Configuring ghc-6.13.20091119...
Warning: 'include-dirs: ../libffi/build/include' is a relative path outside of
the source tree. This will not work when generating a tarball with 'sdist'.
Warning: 'include-dirs: ../libraries/base/cbits' is a relative path outside of
the source tree. This will not work when generating a tarball with 'sdist'.
Warning: 'include-dirs: ../libraries/base/include' is a relative path outside
of the source tree. This will not work when generating a tarball with 'sdist'.
Warning: 'hs-source-dirs: cprAnalysis' directory does not exist.
ghc: unrecognised flags: -fexpose-all-unfoldings
Usage: For basic information, try the `--help' option.
make[1]: *** [compiler/stage2/package-data.mk] Error 1
make: *** [all] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Build.mk:\r\n{{{\r\n# My build settings for hacking on stage 2\r\nSRC_HC_OPTS = -H32m -O -fasm -Rghc-timing\r\nGhcStage1HcOpts = -O -fasm\r\nGhcStage2HcOpts = -O0 -DDEBUG -Wall -fexpose-all-unfoldings\r\nGhcLibHcOpts = -O -fasm -XGenerics\r\nGhcLibWays = v\r\nSplitObjs = NO\r\nGhcBootLibs = YES\r\nHADDOCK_DOCS = NO\r\nBUILD_DOCBOOK_HTML = NO\r\nBUILD_DOCBOOK_PS = NO\r\nBUILD_DOCBOOK_PDF = NO\r\n}}}\r\n\r\nThe build error:\r\n{{{\r\n\"inplace/bin/ghc-cabal\" configure --with-ghc=\"/Volumes/OSXSSD/ghc/ghc.full-unfoldings/inplace/bin/dummy-ghc\" --with-ghc-pkg=\"/Volumes/OSXSSD/ghc/ghc.full-unfoldings/inplace/bin/ghc-pkg\" --with-gcc=\"/usr/bin/gcc\" --configure-option=--with-cc=\"/usr/bin/gcc\" --flags=stage2 --flags=ncg --flags=ghci --ghc-option=-DGHCI_TABLES_NEXT_TO_CODE --ghc-option=-DSTAGE=2 --ghc-options='-O0 -DDEBUG -Wall -fexpose-all-unfoldings' --configure-option=CFLAGS=\" -m32 \" --configure-option=LDFLAGS=\" \" -- stage2 compiler\r\nConfiguring ghc-6.13.20091119...\r\nWarning: 'include-dirs: ../libffi/build/include' is a relative path outside of\r\nthe source tree. This will not work when generating a tarball with 'sdist'.\r\nWarning: 'include-dirs: ../libraries/base/cbits' is a relative path outside of\r\nthe source tree. This will not work when generating a tarball with 'sdist'.\r\nWarning: 'include-dirs: ../libraries/base/include' is a relative path outside\r\nof the source tree. This will not work when generating a tarball with 'sdist'.\r\nWarning: 'hs-source-dirs: cprAnalysis' directory does not exist.\r\nghc: unrecognised flags: -fexpose-all-unfoldings\r\nUsage: For basic information, try the `--help' option.\r\nmake[1]: *** [compiler/stage2/package-data.mk] Error 1\r\nmake: *** [all] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3679./configure --enable-shared does not work for ghc-6.102019-07-07T19:02:49Zelkner./configure --enable-shared does not work for ghc-6.10```
SunOS q 5.11 snv_126 i86pc i386 i86pc
./configure --prefix=/opt \
--disable-static \
--disable-rpath \
--enable-shared \
--with-ghc=$ROOT4BUILD/opt/bin/ghc \
--with-gmp-includes=/usr/inclu...```
SunOS q 5.11 snv_126 i86pc i386 i86pc
./configure --prefix=/opt \
--disable-static \
--disable-rpath \
--enable-shared \
--with-ghc=$ROOT4BUILD/opt/bin/ghc \
--with-gmp-includes=/usr/include/gmp \
--with-gmp-libraries=/usr/lib/${ARCH_DIR}
gmake all | tee $MAKELOG
...
/export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -I/usr/include/gmp -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -hisuf dyn_hi -hcsuf dyn_hc -osuf dyn_o -fPIC -dynamic -c Apply.cmm -o Apply.dyn_o
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-solaris2):
howToAccessLabel: PIC not defined for this platform
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
gmake[2]: *** [Apply.dyn_o] Error 1
gmake[1]: *** [all] Error 1
gmake[1]: Leaving directory `/export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/rts'
gmake: *** [stage1] Error 2
Skipping package make
432.09u 41.84s 9:58.28 79.2%
```https://gitlab.haskell.org/ghc/ghc/-/issues/3680Improve docs for 'length'2019-07-07T19:02:49Zdaniel.is.fischerImprove docs for 'length'The haddock docs for 'length' and 'genericLength' give no indication of their complexity. This leads to many inadvertent uses of 'length', causing poor performance.
To reduce the number of those cases, I suggest inserting the complexity...The haddock docs for 'length' and 'genericLength' give no indication of their complexity. This leads to many inadvertent uses of 'length', causing poor performance.
To reduce the number of those cases, I suggest inserting the complexity (/O(n)/) into the haddock docs, perhaps even a warning to the effect of "use only if you really want to know the length".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improve docs for 'length'","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The haddock docs for 'length' and 'genericLength' give no indication of their complexity. This leads to many inadvertent uses of 'length', causing poor performance.\r\n\r\nTo reduce the number of those cases, I suggest inserting the complexity (/O(n)/) into the haddock docs, perhaps even a warning to the effect of \"use only if you really want to know the length\".","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3681hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C comp...2019-07-07T19:02:49Znwnhsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to usehsc2hs wrapper script ignores default flags to build 32bit binary when specified C-compiler to use even if it was gcc.
This become a problem when building packages with Cabal. As usual, Cabal passes --cc=/path/to/gcc to hsc2hs. So defau...hsc2hs wrapper script ignores default flags to build 32bit binary when specified C-compiler to use even if it was gcc.
This become a problem when building packages with Cabal. As usual, Cabal passes --cc=/path/to/gcc to hsc2hs. So default flags are ignored, built packages are broken.
I edited script to fix this problem. I think it's ugly fix, but it works.
{{{
\#!/bin/sh
exedir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121"
exeprog="hsc2hs"
executablename="$exedir/$exeprog"
datadir="/Library/Frameworks/GHC.framework/Versions/612/usr/share"
bindir="/Library/Frameworks/GHC.framework/Versions/612/usr/bin"
topdir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121"
HSC2HS_EXTRA="--cflag=-m32 --lflag=-m32"
\#!/bin/sh
tflag="--template=$topdir/template-hsc.h"
Iflag="-I$topdir/include/"
for arg do
case "$arg" in
- gcc) break;;
-c\*) HSC2HS_EXTRA=;;
--cc=\*) HSC2HS_EXTRA=;;
-t\*) tflag=;;
--template=\*) tflag=;;
--) break;;
> esac
done
exec "$executablename" "$tflag" $HSC2HS_EXTRA ${1+"$@"} "$Iflag"
}}}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs wrapper script ignores default flags","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"hsc2hs wrapper script ignores default flags to build 32bit binary when specified C-compiler to use even if it was gcc.\r\n\r\nThis become a problem when building packages with Cabal. As usual, Cabal passes --cc=/path/to/gcc to hsc2hs. So default flags are ignored, built packages are broken.\r\n\r\nI edited script to fix this problem. I think it's ugly fix, but it works.\r\n\r\n{{{\r\n#!/bin/sh\r\nexedir=\"/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121\"\r\nexeprog=\"hsc2hs\"\r\nexecutablename=\"$exedir/$exeprog\"\r\ndatadir=\"/Library/Frameworks/GHC.framework/Versions/612/usr/share\"\r\nbindir=\"/Library/Frameworks/GHC.framework/Versions/612/usr/bin\"\r\ntopdir=\"/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121\"\r\nHSC2HS_EXTRA=\"--cflag=-m32 --lflag=-m32\"\r\n#!/bin/sh\r\n\r\ntflag=\"--template=$topdir/template-hsc.h\"\r\nIflag=\"-I$topdir/include/\"\r\n\r\nfor arg do\r\n case \"$arg\" in\r\n *gcc) break;;\r\n -c*) HSC2HS_EXTRA=;;\r\n --cc=*) HSC2HS_EXTRA=;;\r\n -t*) tflag=;;\r\n --template=*) tflag=;;\r\n --) break;;\r\n esac\r\ndone\r\n\r\nexec \"$executablename\" \"$tflag\" $HSC2HS_EXTRA ${1+\"$@\"} \"$Iflag\"\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/3682shared libraries not installed executable2019-07-07T19:02:48ZJens Petersenshared libraries not installed executableWhen ghc-6.12.0 is built with --enable-shared,
libHS\*.so shared library object files are installed
with permission -rw-r--r-- (644) not -rwxr-xr-x (755)
as they should be. (This is true for 6.12.0.20091118
and I assume also for rc2.)
<...When ghc-6.12.0 is built with --enable-shared,
libHS\*.so shared library object files are installed
with permission -rw-r--r-- (644) not -rwxr-xr-x (755)
as they should be. (This is true for 6.12.0.20091118
and I assume also for rc2.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shared libraries not installed executable","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When ghc-6.12.0 is built with --enable-shared,\r\nlibHS*.so shared library object files are installed\r\nwith permission -rw-r--r-- (644) not -rwxr-xr-x (755)\r\nas they should be. (This is true for 6.12.0.20091118\r\nand I assume also for rc2.)","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3683could not build ghc-6.12.0.20091121 under solaris2019-07-07T19:02:48ZChristian Maedercould not build ghc-6.12.0.20091121 under solarisafter unpacking `ghc-6.12.0.20091121-src.tar.bz2` and doing "./configure" and "gmake" I get many lines with:
```
/bin/sh: syntax error at line 1: `;' unexpected
```
probably because /bin/sh is not bash under solaris. (I've no idea what...after unpacking `ghc-6.12.0.20091121-src.tar.bz2` and doing "./configure" and "gmake" I get many lines with:
```
/bin/sh: syntax error at line 1: `;' unexpected
```
probably because /bin/sh is not bash under solaris. (I've no idea what calls /bin/sh)
Finally building fails with:
```
compiler/nativeGen/AsmCodeGen.lhs:19:1:
lexical error at character 'i'
gmake[1]: *** [compiler/stage2/build/.depend-v-p] Error 1
gmake[1]: *** Deleting file `compiler/stage2/build/.depend-v-p'
gmake: *** [all] Error 2
```
(thats the 'i' of an '\#include', probably because unlit wasn't build)
My log file is 1MB long (so I'm not sure if I can attach it here)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"could not build ghc-6.12.0.20091121 under solaris","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"after unpacking `ghc-6.12.0.20091121-src.tar.bz2` and doing \"./configure\" and \"gmake\" I get many lines with:\r\n\r\n{{{\r\n/bin/sh: syntax error at line 1: `;' unexpected\r\n}}}\r\n\r\nprobably because /bin/sh is not bash under solaris. (I've no idea what calls /bin/sh)\r\n\r\nFinally building fails with:\r\n\r\n{{{\r\ncompiler/nativeGen/AsmCodeGen.lhs:19:1:\r\n lexical error at character 'i'\r\ngmake[1]: *** [compiler/stage2/build/.depend-v-p] Error 1\r\ngmake[1]: *** Deleting file `compiler/stage2/build/.depend-v-p'\r\ngmake: *** [all] Error 2\r\n}}}\r\n\r\n(thats the 'i' of an '#include', probably because unlit wasn't build)\r\n\r\nMy log file is 1MB long (so I'm not sure if I can attach it here) ","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3684Missing ghc-pkg options in --help2019-07-07T19:02:48Zkolmodin@dtek.chalmers.seMissing ghc-pkg options in --help`ghc-pkg` does not in `--help` say it can do `recache`.
Any other missing commands?
Could also use some trivial line-edits for the commands `dot` and `find-module`.
<details><summary>Trac metadata</summary>
| Trac field |...`ghc-pkg` does not in `--help` say it can do `recache`.
Any other missing commands?
Could also use some trivial line-edits for the commands `dot` and `find-module`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing ghc-pkg options in --help","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{ghc-pkg}}} does not in {{{--help}}} say it can do {{{recache}}}.\r\n\r\nAny other missing commands?\r\n\r\nCould also use some trivial line-edits for the commands {{{dot}}} and {{{find-module}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3685"double free or corruption" error when running Setup.hs with other GHC in PATH2019-07-07T19:02:48Zajd"double free or corruption" error when running Setup.hs with other GHC in PATHInside network-2.2.1.5 source directory:
```
$ /home/alex/usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121
$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6...Inside network-2.2.1.5 source directory:
```
$ /home/alex/usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121
$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
$ echo $PATH
/home/alex/.cabal/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core
$ /home/alex/usr/bin/ghc --make Setup.hs
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Setup.hs:3:0:
Warning: In the use of `defaultUserHooks'
(imported from Distribution.Simple):
Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2
compatibility in which case you must stick with defaultUserHooks"
Linking Setup ...
$ ./Setup configure
Warning: defaultUserHooks in Setup script is deprecated.
Configuring network-2.2.1.5...
Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)
*** glibc detected *** ./Setup: double free or corruption (!prev): 0x08e21050 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6b6c1)[0xb76166c1]
/lib/libc.so.6(+0x6cf18)[0xb7617f18]
/lib/libc.so.6(cfree+0x6d)[0xb761af8d]
/lib/libc.so.6(+0x1829c)[0xb75c329c]
/lib/libc.so.6(iconv_close+0x1c)[0xb75c27ec]
./Setup[0x821f6b9]
======= Memory map: ========
08048000-082be000 r-xp 00000000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup
082be000-082ed000 rwxp 00275000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup
082ed000-082f0000 rwxp 00000000 00:00 0
08dbf000-08e4a000 rwxp 00000000 00:00 0 [heap]
b6f00000-b6f21000 rwxp 00000000 00:00 0
b6f21000-b7000000 ---p 00000000 00:00 0
b70c8000-b70e5000 r-xp 00000000 08:03 385336 /usr/lib/libgcc_s.so.1
b70e5000-b70e6000 rwxp 0001c000 08:03 385336 /usr/lib/libgcc_s.so.1
b7100000-b7300000 rwxp 00000000 00:00 0
b7391000-b7591000 r-xp 00000000 08:03 396531 /usr/lib/locale/locale-archive
b7591000-b7592000 rwxp 00000000 00:00 0
b7592000-b75a7000 r-xp 00000000 08:03 262160 /lib/libpthread-2.11.so
b75a7000-b75a8000 r-xp 00014000 08:03 262160 /lib/libpthread-2.11.so
b75a8000-b75a9000 rwxp 00015000 08:03 262160 /lib/libpthread-2.11.so
b75a9000-b75ab000 rwxp 00000000 00:00 0
b75ab000-b76eb000 r-xp 00000000 08:03 262169 /lib/libc-2.11.so
b76eb000-b76ed000 r-xp 00140000 08:03 262169 /lib/libc-2.11.so
b76ed000-b76ee000 rwxp 00142000 08:03 262169 /lib/libc-2.11.so
b76ee000-b76f1000 rwxp 00000000 00:00 0
b76f1000-b7715000 r-xp 00000000 08:03 262184 /lib/libm-2.11.so
b7715000-b7716000 r-xp 00023000 08:03 262184 /lib/libm-2.11.so
b7716000-b7717000 rwxp 00024000 08:03 262184 /lib/libm-2.11.so
b7717000-b7718000 rwxp 00000000 00:00 0
b7718000-b7762000 r-xp 00000000 08:03 388239 /usr/lib/libgmp.so.3.5.0
b7762000-b7765000 rwxp 00049000 08:03 388239 /usr/lib/libgmp.so.3.5.0
b7765000-b7767000 r-xp 00000000 08:03 262188 /lib/libdl-2.11.so
b7767000-b7768000 r-xp 00001000 08:03 262188 /lib/libdl-2.11.so
b7768000-b7769000 rwxp 00002000 08:03 262188 /lib/libdl-2.11.so
b7769000-b776b000 r-xp 00000000 08:03 262274 /lib/libutil-2.11.so
b776b000-b776c000 r-xp 00001000 08:03 262274 /lib/libutil-2.11.so
b776c000-b776d000 rwxp 00002000 08:03 262274 /lib/libutil-2.11.so
b776d000-b7774000 r-xp 00000000 08:03 262277 /lib/librt-2.11.so
b7774000-b7775000 r-xp 00006000 08:03 262277 /lib/librt-2.11.so
b7775000-b7776000 rwxp 00007000 08:03 262277 /lib/librt-2.11.so
b778c000-b778e000 r-xp 00000000 08:03 184559 /usr/lib/gconv/UTF-32.so
b778e000-b778f000 r-xp 00001000 08:03 184559 /usr/lib/gconv/UTF-32.so
b778f000-b7790000 rwxp 00002000 08:03 184559 /usr/lib/gconv/UTF-32.so
b7790000-b7791000 rwxp 00000000 00:00 0
b7791000-b7792000 r-xp 00000000 00:00 0 [vdso]
b7792000-b77ae000 r-xp 00000000 08:03 262276 /lib/ld-2.11.so
b77ae000-b77af000 r-xp 0001b000 08:03 262276 /lib/ld-2.11.so
b77af000-b77b0000 rwxp 0001c000 08:03 262276 /lib/ld-2.11.so
bffe2000-bfff7000 rwxp 00000000 00:00 0 [stack]
Aborted
```
Basically, a Setup script compiled with a different GHC than the one that Setup is using fails with a memory error.
See attached file for `/usr/bin/ghc-pkg dump` output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.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":"\"double free or corruption\" error when running Setup.hs with other GHC in PATH","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Inside network-2.2.1.5 source directory:\r\n\r\n{{{\r\n$ /home/alex/usr/bin/ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121\r\n$ /usr/bin/ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.4\r\n$ echo $PATH\r\n/home/alex/.cabal/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core\r\n$ /home/alex/usr/bin/ghc --make Setup.hs \r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\n\r\nSetup.hs:3:0:\r\n Warning: In the use of `defaultUserHooks'\r\n (imported from Distribution.Simple):\r\n Deprecated: \"Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2\r\n compatibility in which case you must stick with defaultUserHooks\"\r\nLinking Setup ...\r\n$ ./Setup configure\r\nWarning: defaultUserHooks in Setup script is deprecated.\r\nConfiguring network-2.2.1.5...\r\nSetup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)\r\n*** glibc detected *** ./Setup: double free or corruption (!prev): 0x08e21050 ***\r\n======= Backtrace: =========\r\n/lib/libc.so.6(+0x6b6c1)[0xb76166c1]\r\n/lib/libc.so.6(+0x6cf18)[0xb7617f18]\r\n/lib/libc.so.6(cfree+0x6d)[0xb761af8d]\r\n/lib/libc.so.6(+0x1829c)[0xb75c329c]\r\n/lib/libc.so.6(iconv_close+0x1c)[0xb75c27ec]\r\n./Setup[0x821f6b9]\r\n======= Memory map: ========\r\n08048000-082be000 r-xp 00000000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup\r\n082be000-082ed000 rwxp 00275000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup\r\n082ed000-082f0000 rwxp 00000000 00:00 0 \r\n08dbf000-08e4a000 rwxp 00000000 00:00 0 [heap]\r\nb6f00000-b6f21000 rwxp 00000000 00:00 0 \r\nb6f21000-b7000000 ---p 00000000 00:00 0 \r\nb70c8000-b70e5000 r-xp 00000000 08:03 385336 /usr/lib/libgcc_s.so.1\r\nb70e5000-b70e6000 rwxp 0001c000 08:03 385336 /usr/lib/libgcc_s.so.1\r\nb7100000-b7300000 rwxp 00000000 00:00 0 \r\nb7391000-b7591000 r-xp 00000000 08:03 396531 /usr/lib/locale/locale-archive\r\nb7591000-b7592000 rwxp 00000000 00:00 0 \r\nb7592000-b75a7000 r-xp 00000000 08:03 262160 /lib/libpthread-2.11.so\r\nb75a7000-b75a8000 r-xp 00014000 08:03 262160 /lib/libpthread-2.11.so\r\nb75a8000-b75a9000 rwxp 00015000 08:03 262160 /lib/libpthread-2.11.so\r\nb75a9000-b75ab000 rwxp 00000000 00:00 0 \r\nb75ab000-b76eb000 r-xp 00000000 08:03 262169 /lib/libc-2.11.so\r\nb76eb000-b76ed000 r-xp 00140000 08:03 262169 /lib/libc-2.11.so\r\nb76ed000-b76ee000 rwxp 00142000 08:03 262169 /lib/libc-2.11.so\r\nb76ee000-b76f1000 rwxp 00000000 00:00 0 \r\nb76f1000-b7715000 r-xp 00000000 08:03 262184 /lib/libm-2.11.so\r\nb7715000-b7716000 r-xp 00023000 08:03 262184 /lib/libm-2.11.so\r\nb7716000-b7717000 rwxp 00024000 08:03 262184 /lib/libm-2.11.so\r\nb7717000-b7718000 rwxp 00000000 00:00 0 \r\nb7718000-b7762000 r-xp 00000000 08:03 388239 /usr/lib/libgmp.so.3.5.0\r\nb7762000-b7765000 rwxp 00049000 08:03 388239 /usr/lib/libgmp.so.3.5.0\r\nb7765000-b7767000 r-xp 00000000 08:03 262188 /lib/libdl-2.11.so\r\nb7767000-b7768000 r-xp 00001000 08:03 262188 /lib/libdl-2.11.so\r\nb7768000-b7769000 rwxp 00002000 08:03 262188 /lib/libdl-2.11.so\r\nb7769000-b776b000 r-xp 00000000 08:03 262274 /lib/libutil-2.11.so\r\nb776b000-b776c000 r-xp 00001000 08:03 262274 /lib/libutil-2.11.so\r\nb776c000-b776d000 rwxp 00002000 08:03 262274 /lib/libutil-2.11.so\r\nb776d000-b7774000 r-xp 00000000 08:03 262277 /lib/librt-2.11.so\r\nb7774000-b7775000 r-xp 00006000 08:03 262277 /lib/librt-2.11.so\r\nb7775000-b7776000 rwxp 00007000 08:03 262277 /lib/librt-2.11.so\r\nb778c000-b778e000 r-xp 00000000 08:03 184559 /usr/lib/gconv/UTF-32.so\r\nb778e000-b778f000 r-xp 00001000 08:03 184559 /usr/lib/gconv/UTF-32.so\r\nb778f000-b7790000 rwxp 00002000 08:03 184559 /usr/lib/gconv/UTF-32.so\r\nb7790000-b7791000 rwxp 00000000 00:00 0 \r\nb7791000-b7792000 r-xp 00000000 00:00 0 [vdso]\r\nb7792000-b77ae000 r-xp 00000000 08:03 262276 /lib/ld-2.11.so\r\nb77ae000-b77af000 r-xp 0001b000 08:03 262276 /lib/ld-2.11.so\r\nb77af000-b77b0000 rwxp 0001c000 08:03 262276 /lib/ld-2.11.so\r\nbffe2000-bfff7000 rwxp 00000000 00:00 0 [stack]\r\nAborted\r\n}}}\r\n\r\nBasically, a Setup script compiled with a different GHC than the one that Setup is using fails with a memory error.\r\n\r\nSee attached file for {{{/usr/bin/ghc-pkg dump}}} output.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3686please remove huge ghc-tarballs/2019-07-07T19:02:48ZJens Petersenplease remove huge ghc-tarballs/Just prior to ghc-6.12 RC2 the ghc tarball sizes ballooned:
```
-rw-r--r-- 7821334 2009-11-17 12:27 ghc-6.12.0.20091116-src.tar.bz2
-rw-r--r-- 7822080 2009-11-18 18:37 ghc-6.12.0.20091117-src.tar.bz2
-rw-r--r-- 25473470 2009-11-...Just prior to ghc-6.12 RC2 the ghc tarball sizes ballooned:
```
-rw-r--r-- 7821334 2009-11-17 12:27 ghc-6.12.0.20091116-src.tar.bz2
-rw-r--r-- 7822080 2009-11-18 18:37 ghc-6.12.0.20091117-src.tar.bz2
-rw-r--r-- 25473470 2009-11-19 10:30 ghc-6.12.0.20091118-src.tar.bz2
-rw-r--r-- 22538103 2009-11-23 14:14 ghc-6.12.0.20091121-src.tar.bz2
```
This is largely due to the addition of `ghc-tarballs/` and particularly `mingw/`.
Can't `mingw/` and `perl/` go into a separate extra tarball for people who should want to build on Windows if the ghc project really needs to ship them? This addition really bloats the src distribution in a big way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"please remove huge ghc-tarballs/","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just prior to ghc-6.12 RC2 the ghc tarball sizes ballooned:\r\n\r\n{{{\r\n -rw-r--r-- 7821334 2009-11-17 12:27 ghc-6.12.0.20091116-src.tar.bz2\r\n -rw-r--r-- 7822080 2009-11-18 18:37 ghc-6.12.0.20091117-src.tar.bz2\r\n -rw-r--r-- 25473470 2009-11-19 10:30 ghc-6.12.0.20091118-src.tar.bz2\r\n -rw-r--r-- 22538103 2009-11-23 14:14 ghc-6.12.0.20091121-src.tar.bz2\r\n}}}\r\n\r\nThis is largely due to the addition of {{{ghc-tarballs/}}} and particularly {{{mingw/}}}.\r\nCan't {{{mingw/}}} and {{{perl/}}} go into a separate extra tarball for people who should want to build on Windows if the ghc project really needs to ship them? This addition really bloats the src distribution in a big way.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3687Merge _stub.o files back in to the .o file2019-07-07T19:02:47ZNeil MitchellMerge _stub.o files back in to the .o fileGHC sometimes generates _stub.o files. When it does, ghci doesn't work with compiled files (it forgets to include the _stub.o in the files to link against), and it complicates many building rules (including those inside GHC's makefile).
...GHC sometimes generates _stub.o files. When it does, ghci doesn't work with compiled files (it forgets to include the _stub.o in the files to link against), and it complicates many building rules (including those inside GHC's makefile).
It would be far better if the _stub.o files were merged back in with the original. This is actually reasonably easy:
```
b <- doesFileExist stub
when b $ do
let tmp = res <.> "tmp.o"
mv obj tmp
exec ["ld","-r","-o",obj,tmp,stub]
rm stub
rm tmp
```
While being mainly a feature request, this enhancement also fixes a bug with GHCi loading files with _stub's, so includes a bug fix for free.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Merge _stub.o files back in to the .o file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC sometimes generates _stub.o files. When it does, ghci doesn't work with compiled files (it forgets to include the _stub.o in the files to link against), and it complicates many building rules (including those inside GHC's makefile).\r\n\r\nIt would be far better if the _stub.o files were merged back in with the original. This is actually reasonably easy:\r\n\r\n{{{\r\nb <- doesFileExist stub\r\nwhen b $ do\r\n let tmp = res <.> \"tmp.o\"\r\n mv obj tmp\r\n exec [\"ld\",\"-r\",\"-o\",obj,tmp,stub]\r\n rm stub\r\n rm tmp\r\n}}}\r\n\r\nWhile being mainly a feature request, this enhancement also fixes a bug with GHCi loading files with _stub's, so includes a bug fix for free.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3688getOptions'.parseLanguage(2) went past eof token2019-07-07T19:02:47ZguestgetOptions'.parseLanguage(2) went past eof tokenPrelude\> :l counter.hs
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32):
> getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
T...Prelude\> :l counter.hs
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32):
> getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
The language pragma just contains: {-\# LANGUAGE -fglasgow-exts \#-}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getOptions'.parseLanguage(2) went past eof token","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["language","pragma"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Prelude> :l counter.hs\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-mingw32):\r\n getOptions'.parseLanguage(2) went past eof token\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n\r\nThe language pragma just contains: {-# LANGUAGE -fglasgow-exts #-}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3689GHCi bug on too long input lines2019-07-07T19:02:47Zharry666tGHCi bug on too long input linesThis is probably a very strange thing to do, but when you put a really, really, really long line (mine was about 59000 characters long) in a file and try to load the module in ghci, you get an error message:
ghc-6.8.2: panic! (the 'impo...This is probably a very strange thing to do, but when you put a really, really, really long line (mine was about 59000 characters long) in a file and try to load the module in ghci, you get an error message:
ghc-6.8.2: panic! (the 'impossible' happened)
> (GHC version 6.8.2 for i386-unknown-linux):
linkBCO: \>= 64k insns in BCO
The same thing happens when you paste a really long line in the terminal in an interactive GHCi shell.
The bug seems to only affect ghci; the module compiles without problems with ghc.
I'm using the GHC version from Debian Squeeze.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi bug on too long input lines","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is probably a very strange thing to do, but when you put a really, really, really long line (mine was about 59000 characters long) in a file and try to load the module in ghci, you get an error message:\r\n\r\nghc-6.8.2: panic! (the 'impossible' happened)\r\n (GHC version 6.8.2 for i386-unknown-linux):\r\n\tlinkBCO: >= 64k insns in BCO\r\n\r\nThe same thing happens when you paste a really long line in the terminal in an interactive GHCi shell.\r\n\r\nThe bug seems to only affect ghci; the module compiles without problems with ghc.\r\n\r\nI'm using the GHC version from Debian Squeeze.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3690GHC panics on a crazy type signature2019-07-07T19:02:46ZBorisGHC panics on a crazy type signature```
x :: [Enum a => (forall a. Num a => a)]
x = []
```
I have NO idea what that would mean or whatever it makes sense at all, but it fails with:
```
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32)...```
x :: [Enum a => (forall a. Num a => a)]
x = []
```
I have NO idea what that would mean or whatever it makes sense at all, but it fails with:
```
: panic! (the 'impossible' happened)
(GHC version 6.10.4 for i386-unknown-mingw32):
TcTyFuns.flattenType: unexpected PredType
```
And it said I should report it. :)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| 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 panics on a crazy type signature","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nx :: [Enum a => (forall a. Num a => a)]\r\nx = []\r\n}}}\r\n\r\nI have NO idea what that would mean or whatever it makes sense at all, but it fails with:\r\n\r\n{{{\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for i386-unknown-mingw32):\r\n TcTyFuns.flattenType: unexpected PredType\r\n}}}\r\n\r\nAnd it said I should report it. :)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3691Error message doesn't mention necessary extension in warning2019-07-07T19:02:46ZarsenmError message doesn't mention necessary extension in warningIn this example(Taken from [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap](http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap)) with the exception of removing -fglasgow-exts), GHC gives the wrong error message and fails to m...In this example(Taken from [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap](http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap)) with the exception of removing -fglasgow-exts), GHC gives the wrong error message and fails to mention the missing necessary extension (which turns out to be ScopedTypeVariables).
If you take the example, and remove -fglasgow-exts and try to only use the minimum required language extensions,
```
{-# LANGUAGE EmptyDataDecls,
MultiParamTypeClasses,
FunctionalDependencies,
OverlappingInstances,
FlexibleInstances,
UndecidableInstances #-}
```
GHC fails with the error
```
wiki.hs:30:12:
Could not deduce (Print' flag a)
from the context (Print a, ShowPred a flag1, Print' flag1 a)
arising from a use of `print'' at wiki.hs:30:12-35
Possible fix:
add (Print' flag a) to the context of the instance declaration
In the expression: print' (undefined :: flag)
In the definition of `print': print = print' (undefined :: flag)
In the instance declaration for `Print a'
Failed, modules loaded: none.
```
However, it compiles fine if ScopedTypeVariables is added to the list of extensions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Error message doesn't mention necessary extension in warning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In this example(Taken from [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap]) with the exception of removing -fglasgow-exts), GHC gives the wrong error message and fails to mention the missing necessary extension (which turns out to be ScopedTypeVariables).\r\n\r\nIf you take the example, and remove -fglasgow-exts and try to only use the minimum required language extensions,\r\n\r\n{{{\r\n{-# LANGUAGE EmptyDataDecls,\r\n MultiParamTypeClasses,\r\n FunctionalDependencies,\r\n OverlappingInstances,\r\n FlexibleInstances,\r\n UndecidableInstances #-}\r\n}}}\r\n\r\nGHC fails with the error\r\n\r\n{{{\r\nwiki.hs:30:12:\r\n Could not deduce (Print' flag a)\r\n from the context (Print a, ShowPred a flag1, Print' flag1 a)\r\n arising from a use of `print'' at wiki.hs:30:12-35\r\n Possible fix:\r\n add (Print' flag a) to the context of the instance declaration\r\n In the expression: print' (undefined :: flag)\r\n In the definition of `print': print = print' (undefined :: flag)\r\n In the instance declaration for `Print a'\r\nFailed, modules loaded: none.\r\n\r\n}}}\r\n\r\nHowever, it compiles fine if ScopedTypeVariables is added to the list of extensions. \r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3692Bogus type error message in type with constraints after the arrow2019-07-07T19:02:46ZcdfhBogus type error message in type with constraints after the arrowHello,
I've found a bug, however it may be a duplicate of one of these: #2846, #3272, #3592, #3125, #3102 (roughly in order of duplicate-likelihoodness).
Here's the code:
```
type Foo a b = () -> (Bar a => a)
class Bar a where {}
fo...Hello,
I've found a bug, however it may be a duplicate of one of these: #2846, #3272, #3592, #3125, #3102 (roughly in order of duplicate-likelihoodness).
Here's the code:
```
type Foo a b = () -> (Bar a => a)
class Bar a where {}
foo :: Foo a b
foo = id (undefined :: Foo a b)
```
And the result of compilation:
```
$ ghc -fglasgow-exts --make Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm running Gentoo Linux, with dev-lang/ghc-6.10.4 (not dev-haskell/haskell-platform)
```
Linux geneva 2.6.29-gentoo-r5 #1 SMP Sun Jul 12 03:16:58 BST 2009 x86_64 Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz GenuineIntel GNU/Linux
```
I'm afraid I've not tested this against HEAD, since I couldn't get it to build.
Note that `foo = undefined :: Foo a b` does not cause GHC to panic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"TcTyFuns.flattenType: unexpected PredType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["PredType","TcTyFuns","panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nI've found a bug, however it may be a duplicate of one of these: #2846, #3272, #3592, #3125, #3102 (roughly in order of duplicate-likelihoodness).\r\n\r\nHere's the code:\r\n\r\n{{{\r\ntype Foo a b = () -> (Bar a => a)\r\n\r\nclass Bar a where {}\r\n\r\nfoo :: Foo a b\r\nfoo = id (undefined :: Foo a b)\r\n}}}\r\n\r\nAnd the result of compilation:\r\n\r\n{{{\r\n$ ghc -fglasgow-exts --make Bug.hs\r\n\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.4 for x86_64-unknown-linux):\r\n TcTyFuns.flattenType: unexpected PredType\r\n \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI'm running Gentoo Linux, with dev-lang/ghc-6.10.4 (not dev-haskell/haskell-platform)\r\n\r\n{{{\r\nLinux geneva 2.6.29-gentoo-r5 #1 SMP Sun Jul 12 03:16:58 BST 2009 x86_64 Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz GenuineIntel GNU/Linux\r\n}}}\r\n\r\nI'm afraid I've not tested this against HEAD, since I couldn't get it to build.\r\n\r\nNote that `foo = undefined :: Foo a b` does not cause GHC to panic.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3693Show stack traces2019-07-07T19:02:45ZjpetShow stack tracesDebugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful.
(Entered after spe...Debugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful.
(Entered after spending two days trying to determine the cause of a stack overflow, before discovering it was a GHC bug \[3677\], which would have been apparent immediately if I could have only seen a callstack.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show stack traces","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Debugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful.\r\n\r\n(Entered after spending two days trying to determine the cause of a stack overflow, before discovering it was a GHC bug [3677], which would have been apparent immediately if I could have only seen a callstack.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1TarraschTarraschhttps://gitlab.haskell.org/ghc/ghc/-/issues/3694Image link in User's Guide is broken2019-07-07T19:02:45ZjliImage link in User's Guide is brokenIn section 5.1.1 "Inserting cost centres by hand" of the user's guide, there's an image of a heap profile, but the image doesn't exist.
section 5.1.1: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html\#id514538
imag...In section 5.1.1 "Inserting cost centres by hand" of the user's guide, there's an image of a heap profile, but the image doesn't exist.
section 5.1.1: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html\#id514538
image link: http://www.haskell.org/ghc/docs/latest/html/users_guide/prof_scc
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.4 |
| 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":"Image link in User's Guide is broken","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In section 5.1.1 \"Inserting cost centres by hand\" of the user's guide, there's an image of a heap profile, but the image doesn't exist.\r\n\r\nsection 5.1.1: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#id514538\r\nimage link: http://www.haskell.org/ghc/docs/latest/html/users_guide/prof_scc","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>