GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:15:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14818Provide highestOneBit function in Data.Bits module2019-07-07T18:15:27ZkostmoProvide highestOneBit function in Data.Bits moduleThis function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/do...This function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int)), there is a gap in the Haskell library, even though the Haskell docs [describe a method to calculate logBase2 via the \`countLeadingZeros\` function](https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros).
From the Java documentation:
> The implementations of the "bit twiddling" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| 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":"Provide highestOneBit function in Data.Bits module","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This function yields the [https://stackoverflow.com/a/17379704/105137 largest power of 2 less than or equal to the given number].\r\n\r\n\r\nRelative to the Java standard library, which [https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int) provides this function], there is a gap in the Haskell library, even though the Haskell docs [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros describe a method to calculate logBase2 via the `countLeadingZeros` function].\r\n\r\nFrom the Java documentation:\r\n\r\n> The implementations of the \"bit twiddling\" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10176Invalid core generated with GHC 7.10 RC32019-07-07T18:37:13ZNeil MitchellInvalid core generated with GHC 7.10 RC3Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:
```
## BUILD oracle --quiet *str-int
TESTS FAILED
shake-test: Expected an exception but s...Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:
```
## BUILD oracle --quiet *str-int
TESTS FAILED
shake-test: Expected an exception but succeeded
```
Discussion about this issue can be found on the mailing list: http://osdir.com/ml/general/2015-03/msg25847.html
GHC generates the Core:
```
case (\_ -> error "here") of {}
```
This is invalid GHC Core. I intend to track down a minimal example shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Invalid core generated with GHC 7.10 RC3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Using the Shake repo (https://github.com/ndmitchell/shake.git) at commit d7fa04 and GHC 7.10 RC3 or GHC HEAD, if I {{cabal test}} I get the error:\r\n\r\n{{{\r\n## BUILD oracle --quiet *str-int\r\nTESTS FAILED\r\nshake-test: Expected an exception but succeeded\r\n}}}\r\n\r\nDiscussion about this issue can be found on the mailing list: http://osdir.com/ml/general/2015-03/msg25847.html\r\n\r\nGHC generates the Core:\r\n\r\n{{{\r\ncase (\\_ -> error \"here\") of {}\r\n}}}\r\n\r\nThis is invalid GHC Core. I intend to track down a minimal example shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/10165Win32 broken with GHC 7.10 RC32019-07-07T18:37:16ZNeil MitchellWin32 broken with GHC 7.10 RC3Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:
```
C:\Neil>ghci
GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Win32...Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:
```
C:\Neil>ghci
GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Win32
Prelude System.Win32> wRITE_DAC
<interactive>: C:\ghc\ghc-7.10.0.20150316\lib\Win32_6dnIMpnCmqmCdDB983aKnr\HSWin
32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW'
ghc.exe: unable to load package `Win32-2.3.1.0'
```
This seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Win32 broken with GHC 7.10 RC3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem:\r\n\r\n{{{\r\nC:\\Neil>ghci\r\nGHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help\r\nPrelude> import System.Win32\r\nPrelude System.Win32> wRITE_DAC\r\n<interactive>: C:\\ghc\\ghc-7.10.0.20150316\\lib\\Win32_6dnIMpnCmqmCdDB983aKnr\\HSWin\r\n32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW'\r\nghc.exe: unable to load package `Win32-2.3.1.0'\r\n}}}\r\n\r\nThis seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10164Cleanup test framework string formatting2019-07-07T18:37:16ZThomas MiedemaCleanup test framework string formattingThis is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versio...This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cleanup test framework string formatting","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10142Documentation for Ix is contradictory around minimal definition2019-07-07T18:37:21ZRichard Eisenbergrae@richarde.devDocumentation for Ix is contradictory around minimal definitionThe Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires...The Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for Ix is contradictory around minimal definition","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/10128Data.List.transpose needs more docs2019-07-07T18:37:23ZJoachim Breitnermail@joachim-breitner.deData.List.transpose needs more docsas mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose func...as mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose function transposes the rows and columns of its argument. For example,
>
> ```
> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]
> ```
>
> If some of the rows are shorter than the following rows, their elements are skipped:
>
> ```
> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]
> ```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.transpose needs more docs","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"as mentioned by Doug McIlroy on haskell-prime.\r\n\r\nMy preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:\r\n\r\n> The transpose function transposes the rows and columns of its argument. For example,\r\n> \r\n> {{{\r\n> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]\r\n> }}}\r\n> \r\n> If some of the rows are shorter than the following rows, their elements are skipped:\r\n> \r\n> {{{\r\n> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]\r\n> }}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10115Unable to run cabal haddock --hoogle on GHC 7.102019-07-07T18:37:26ZMichael Snoymanmichael@snoyman.comUnable to run cabal haddock --hoogle on GHC 7.10At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, ...At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it:
https://github.com/haskell/haddock/issues/361
https://github.com/haskell/cabal/issues/2297
I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to run cabal haddock --hoogle on GHC 7.10","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:\r\n\r\nI'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it:\r\n\r\nhttps://github.com/haskell/haddock/issues/361\r\nhttps://github.com/haskell/cabal/issues/2297\r\n\r\nI really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10113Re-export (<$>) and (<$) from Prelude2019-07-07T18:37:27ZHerbert Valerio Riedelhvr@gnu.orgRe-export (<$>) and (<$) from PreludeSee http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field ...See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10099cabal install broken with ghc 7.10.1-rc22019-07-07T18:37:30ZPeter Trommlerptrommler@acm.orgcabal install broken with ghc 7.10.1-rc2Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primi...Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primitive-0.5.4.0...
cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf
```
This is my package database:
```
peter@montebre:~> ghc-pkg list
/usr/lib64/ghc-7.10.0.20150123/package.conf.d
Cabal-1.22.1.0
HTTP-4000.2.19
array-0.5.0.1
base-4.8.0.0
bin-package-db-0.0.0.0
binary-0.7.3.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.0.0
directory-1.2.2.0
filepath-1.3.1.0
ghc-7.10.0.20150123
ghc-prim-0.3.1.0
haskeline-0.7.2.0
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
mtl-2.2.1
network-2.4.2.3
old-locale-1.0.0.7
old-time-1.1.0.3
parsec-3.1.8
pretty-1.1.2.0
process-1.2.2.0
random-1.0.1.1
rts-1.0
stm-2.4.2
syb-0.4.4
template-haskell-2.10.0.0
terminfo-0.4.0.1
text-1.2.0.4
th-desugar-1.5
th-lift-0.7
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
zlib-0.5.4.2
```
I updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.
I am setting this to highest as this issue would be very annoying for everyone.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cabal install broken with ghc 7.10.1-rc2","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2\r\nconsistently gives this error message (`primitive` is just an example):\r\n{{{\r\npeter@montebre:~> cabal install primitive\r\nResolving dependencies...\r\nConfiguring primitive-0.5.4.0...\r\ncabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf\r\n}}}\r\n\r\nThis is my package database:\r\n{{{\r\npeter@montebre:~> ghc-pkg list\r\n/usr/lib64/ghc-7.10.0.20150123/package.conf.d\r\n Cabal-1.22.1.0\r\n HTTP-4000.2.19\r\n array-0.5.0.1\r\n base-4.8.0.0\r\n bin-package-db-0.0.0.0\r\n binary-0.7.3.0\r\n bytestring-0.10.6.0\r\n containers-0.5.6.2\r\n deepseq-1.4.0.0\r\n directory-1.2.2.0\r\n filepath-1.3.1.0\r\n ghc-7.10.0.20150123\r\n ghc-prim-0.3.1.0\r\n haskeline-0.7.2.0\r\n hoopl-3.10.0.2\r\n hpc-0.6.0.2\r\n integer-gmp-1.0.0.0\r\n mtl-2.2.1\r\n network-2.4.2.3\r\n old-locale-1.0.0.7\r\n old-time-1.1.0.3\r\n parsec-3.1.8\r\n pretty-1.1.2.0\r\n process-1.2.2.0\r\n random-1.0.1.1\r\n rts-1.0\r\n stm-2.4.2\r\n syb-0.4.4\r\n template-haskell-2.10.0.0\r\n terminfo-0.4.0.1\r\n text-1.2.0.4\r\n th-desugar-1.5\r\n th-lift-0.7\r\n time-1.5.0.1\r\n transformers-0.4.2.0\r\n unix-2.7.1.0\r\n xhtml-3000.2.1\r\n zlib-0.5.4.2\r\n}}}\r\nI updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.\r\n\r\nI am setting this to highest as this issue would be very annoying for everyone.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10096Top-level ./configure should accept and propagate --with-curses-{includes,lib...2019-07-07T18:37:33ZPHOTop-level ./configure should accept and propagate --with-curses-{includes,libraries} to librariesIf curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:
```
libraries/terminfo_CONFIGURE_OPTS += \
--configure-option=--with-curses-includes=/somewhere/include \
...If curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:
```
libraries/terminfo_CONFIGURE_OPTS += \
--configure-option=--with-curses-includes=/somewhere/include \
--configure-option=--with-curses-libraries=/somewhere/lib
```
This is because the top-level `configure` does not accept nor propagate `--with-curses-{includes,libraries}` to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner.
I will soon submit a patch for this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Top-level ./configure should accept and propagate --with-curses-{includes,libraries} to libraries","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"If curses is installed into some non-standard path, we currently have to say something like the following in `mk/build.mk`:\r\n{{{\r\nlibraries/terminfo_CONFIGURE_OPTS += \\\r\n --configure-option=--with-curses-includes=/somewhere/include \\\r\n --configure-option=--with-curses-libraries=/somewhere/lib\r\n}}}\r\n\r\nThis is because the top-level `configure` does not accept nor propagate `--with-curses-{includes,libraries}` to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner.\r\n\r\nI will soon submit a patch for this.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10091Add configurable verbosity level to hpc executable2019-07-07T18:37:35ZYurasAdd configurable verbosity level to hpc executableRight now `hpc markup` writes a notice for each module and for each index file:
```
Writing: Module.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
```
That is a bit a...Right now `hpc markup` writes a notice for each module and for each index file:
```
Writing: Module.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
```
That is a bit annoying when you have e.g. 100 modules.
I propose to add `--verbosity` flag with possible values `0`, `1` and `2` (default `1`) and suppress the notice for verbosity level `0`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add configurable verbosity level to hpc executable","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Right now `hpc markup` writes a notice for each module and for each index file:\r\n\r\n{{{\r\nWriting: Module.hs.html\r\nWriting: hpc_index.html\r\nWriting: hpc_index_fun.html\r\nWriting: hpc_index_alt.html\r\nWriting: hpc_index_exp.html\r\n}}}\r\n\r\nThat is a bit annoying when you have e.g. 100 modules.\r\n\r\nI propose to add `--verbosity` flag with possible values `0`, `1` and `2` (default `1`) and suppress the notice for verbosity level `0`","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1YurasYurashttps://gitlab.haskell.org/ghc/ghc/-/issues/10088Broken link in Data.Ix documentation2019-07-07T18:37:36ZDavid FeuerBroken link in Data.Ix documentationThe Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index....The Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index.
This link is dead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken link in Data.Ix documentation","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Data.Ix` includes the following line:\r\n\r\n For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html#prelude-index.\r\n\r\nThis link is dead.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10078tcPluginStop of a type checker plugin is not called if an error occurs2019-07-07T18:37:39ZjbrackertcPluginStop of a type checker plugin is not called if an error occursWhen a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChec...When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.
### Test plugin
`MyPlugin.hs`:
```hs
module MyPlugin
( plugin ) where
import Plugins
import TcRnTypes
import TcPluginM
plugin :: Plugin
plugin = defaultPlugin
{ tcPlugin = \clos -> Just $ TcPlugin
{ tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init"
, tcPluginSolve = \_ _ _ _ -> do
tcPluginIO $ putStrLn ">>> Plugin Solve"
return $ TcPluginOk [] []
, tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop"
}
}
```
### Minimal example (with type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return 1
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Solve
Main.hs:6:10:
Could not deduce (Num ()) arising from the literal ‘1’
from the context: Monad m
bound by the type signature for: main :: Monad m => m ()
at Main.hs:4:9-25
In the first argument of ‘return’, namely ‘1’
In a stmt of a 'do' block: return 1
In the expression: do { return 1 }
```
Which means `tcPluginStop` was _not_ called.
### Minimal example (without type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return ()
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Stop
Linking Main ...
```
Which means `tcPluginStop` _was_ called.
### Possible solution
As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
to
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
case eitherRes of
Left e -> failM
Right res -> return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
.
I have tried this. It compiles and my minimal example delivers the correct result.
Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | adamgundry |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tcPluginStop of a type checker plugin is not called if an error occurs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["adamgundry"],"type":"Bug","description":"When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.\r\n\r\nI am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.\r\n\r\n=== Test plugin\r\n\r\n`MyPlugin.hs`:\r\n{{{#!hs\r\nmodule MyPlugin\r\n ( plugin ) where\r\n\r\nimport Plugins\r\nimport TcRnTypes\r\nimport TcPluginM\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin \r\n { tcPlugin = \\clos -> Just $ TcPlugin \r\n { tcPluginInit = tcPluginIO $ putStrLn \">>> Plugin Init\"\r\n , tcPluginSolve = \\_ _ _ _ -> do\r\n tcPluginIO $ putStrLn \">>> Plugin Solve\"\r\n return $ TcPluginOk [] []\r\n , tcPluginStop = \\_ -> tcPluginIO $ putStrLn \">>> Plugin Stop\"\r\n }\r\n }\r\n}}}\r\n\r\n=== Minimal example (with type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return 1\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n\r\nMain.hs:6:10:\r\n Could not deduce (Num ()) arising from the literal ‘1’\r\n from the context: Monad m\r\n bound by the type signature for: main :: Monad m => m ()\r\n at Main.hs:4:9-25\r\n In the first argument of ‘return’, namely ‘1’\r\n In a stmt of a 'do' block: return 1\r\n In the expression: do { return 1 }\r\n}}}\r\nWhich means `tcPluginStop` was _not_ called.\r\n\r\n=== Minimal example (without type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return ()\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Stop\r\nLinking Main ...\r\n}}}\r\nWhich means `tcPluginStop` _was_ called.\r\n\r\n=== Possible solution\r\n\r\nAs far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n res <- updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\nto\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n eitherRes <- tryM $ do updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n case eitherRes of\r\n Left e -> failM\r\n Right res -> return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\n.\r\n\r\nI have tried this. It compiles and my minimal example delivers the correct result.\r\n\r\nAre there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1jbrackerjbrackerhttps://gitlab.haskell.org/ghc/ghc/-/issues/10072Panic: generalised wildcards in RULES2019-07-07T18:37:40ZthomaswPanic: generalised wildcards in RULESGeneralised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.
Minimal example:
```hs
module WildcardInRuleBndrSig where
{-# RULES
"map/empty" forall (f :: a -> _). map f [] = []
#-}
```
Output:
...Generalised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.
Minimal example:
```hs
module WildcardInRuleBndrSig where
{-# RULES
"map/empty" forall (f :: a -> _). map f [] = []
#-}
```
Output:
```
WildcardInRuleBndrSig.hs:3:31:ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.11.20150209 for x86_64-unknown-linux):
No skolem info: w__alY[sk]
```
When a wildcard is generalised over, the error message reporting the inferred type gives some extra info about the type variables occurring in the inferred type. This extra information is retrieved by looking up the skolem information (`getSkolemInfo`) for the type variables in the enclosing implications (`cec_encl`). The problem is that there are no enclosing implications in this case, hence the panic.
Note that with the flags `-XPartialTypeSignatures` and `-fno-warn-partial-type-signatures` enabled, there is no panic, as no error/warning message is constructed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic: generalised wildcards in RULES","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thomasw"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Generalised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.\r\n\r\nMinimal example:\r\n{{{#!hs\r\nmodule WildcardInRuleBndrSig where\r\n{-# RULES\r\n\"map/empty\" forall (f :: a -> _). map f [] = []\r\n #-}\r\n}}}\r\n\r\nOutput:\r\n{{{\r\nWildcardInRuleBndrSig.hs:3:31:ghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150209 for x86_64-unknown-linux):\r\n\tNo skolem info: w__alY[sk]\r\n}}}\r\n\r\n\r\nWhen a wildcard is generalised over, the error message reporting the inferred type gives some extra info about the type variables occurring in the inferred type. This extra information is retrieved by looking up the skolem information (`getSkolemInfo`) for the type variables in the enclosing implications (`cec_encl`). The problem is that there are no enclosing implications in this case, hence the panic.\r\n\r\nNote that with the flags `-XPartialTypeSignatures` and `-fno-warn-partial-type-signatures` enabled, there is no panic, as no error/warning message is constructed.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thomaswthomaswhttps://gitlab.haskell.org/ghc/ghc/-/issues/10058Panic: Loading temp shared object failed2019-07-07T18:37:45ZRichard Eisenbergrae@richarde.devPanic: Loading temp shared object failedI ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way.
To reproduce:
```
> git cl...I ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way.
To reproduce:
```
> git clone http://github.com/goldfirere/singletons.git
> cd singletons
> git checkout ghc-loading-panic-test-case
> cabal update
> cabal install --only-dependencies
> cabal configure
> cabal build
> cat dist/build/autogen/cabal_macros.h
# copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h
> cd tests/compile-and-dump
> ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs
```
You will see something like
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.0.20150123 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info
Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib
Expected in: flat namespace
in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output [here](https://travis-ci.org/goldfirere/singletons/jobs/49103793).
Why am I doing such a crazy thing? It's part of the `singletons` test suite, where it's important to test the output of a run of ghc with `-ddump-splices`. Getting the test cases to compile against the built-but-not-yet-installed `singletons` object files should work with `-this-package-key`. I'm sure there's a better way to structure a testsuite, but this general technique works (with `-package-name` instead of `-this-package-key`) with 7.8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Panic: Loading temp shared object failed","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way.\r\n\r\nTo reproduce:\r\n\r\n{{{\r\n> git clone http://github.com/goldfirere/singletons.git\r\n> cd singletons\r\n> git checkout ghc-loading-panic-test-case\r\n> cabal update\r\n> cabal install --only-dependencies\r\n> cabal configure\r\n> cabal build\r\n> cat dist/build/autogen/cabal_macros.h\r\n# copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h\r\n> cd tests/compile-and-dump\r\n> ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs\r\n}}}\r\n\r\nYou will see something like\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.0.20150123 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info\r\n Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib\r\n Expected in: flat namespace\r\n in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output [https://travis-ci.org/goldfirere/singletons/jobs/49103793 here].\r\n\r\nWhy am I doing such a crazy thing? It's part of the `singletons` test suite, where it's important to test the output of a run of ghc with `-ddump-splices`. Getting the test cases to compile against the built-but-not-yet-installed `singletons` object files should work with `-this-package-key`. I'm sure there's a better way to structure a testsuite, but this general technique works (with `-package-name` instead of `-this-package-key`) with 7.8.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10051panic - the 'impossible' happened2019-07-07T18:37:47Zjpw1991panic - the 'impossible' happenedHi there,
I'm new to Haskell and I'm loving it so far. I finished a learning project in Haskell and it works fine on Linux. I'm bringing it over to Windows and I got the following error while running it:
C:\\Repositories\\HaskellPong\>...Hi there,
I'm new to Haskell and I'm loving it so far. I finished a learning project in Haskell and it works fine on Linux. I'm bringing it over to Windows and I got the following error while running it:
C:\\Repositories\\HaskellPong\>ghci Main.hs -LC:\\SDL\\lib -lSDL2
GHCi, version 7.8.3: 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 object (static archive) C:\\SDL\\lib\\libSDL2.a ... ghc.exe: Unknown PEi386
section name \`.rdata$.refptr.DUMMYAUD_bootstrap' (while processing: C:\\SDL\\lib\\
libSDL2.a)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-mingw32):
> loadArchive "C:\\\\SDL\\\\lib\\\\libSDL2.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
The repository is public, so you can go and get it from here: https://jwoodss\@bitbucket.org/jwoodss/haskellpong.git
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic - the 'impossible' happened","status":"New","operating_system":"Unknown/Multiple","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Hi there,\r\n\r\nI'm new to Haskell and I'm loving it so far. I finished a learning project in Haskell and it works fine on Linux. I'm bringing it over to Windows and I got the following error while running it:\r\n\r\nC:\\Repositories\\HaskellPong>ghci Main.hs -LC:\\SDL\\lib -lSDL2\r\nGHCi, version 7.8.3: 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 object (static archive) C:\\SDL\\lib\\libSDL2.a ... ghc.exe: Unknown PEi386\r\n section name `.rdata$.refptr.DUMMYAUD_bootstrap' (while processing: C:\\SDL\\lib\\\r\nlibSDL2.a)\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-unknown-mingw32):\r\n loadArchive \"C:\\\\SDL\\\\lib\\\\libSDL2.a\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThe repository is public, so you can go and get it from here: https://jwoodss@bitbucket.org/jwoodss/haskellpong.git","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10050template haskell Ppr missing parentheses for SigT2019-07-07T18:37:48Zaavogttemplate haskell Ppr missing parentheses for SigT```hs
ppr (SigE (VarE (mkName "a")) (SigT (VarT (mkName "x")) (VarT (mkName "k"))))
```
prints as "a :: x :: k". Ghc can't parse that, so I think it should be printed as "a :: (x :: k)"
<details><summary>Trac metadata</summary>
| Trac...```hs
ppr (SigE (VarE (mkName "a")) (SigT (VarT (mkName "x")) (VarT (mkName "k"))))
```
prints as "a :: x :: k". Ghc can't parse that, so I think it should be printed as "a :: (x :: k)"
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"template haskell Ppr missing parentheses for SigT","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nppr (SigE (VarE (mkName \"a\")) (SigT (VarT (mkName \"x\")) (VarT (mkName \"k\"))))\r\n}}}\r\nprints as \"a :: x :: k\". Ghc can't parse that, so I think it should be printed as \"a :: (x :: k)\"","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10043runtime fails in threaded way on SPARC (bus error -> unaligned access to data)2019-07-07T18:37:49Zkgardasruntime fails in threaded way on SPARC (bus error -> unaligned access to data)Hello,
it looks like runtime has changed between 7.8 and 7.10 in a way it no longer works well on SPARC. Tested on SPARC/Solaris 2.11. Both compilers compiled as their are w/o any changes so both unregisterised. On 7.8 testblockalloc run...Hello,
it looks like runtime has changed between 7.8 and 7.10 in a way it no longer works well on SPARC. Tested on SPARC/Solaris 2.11. Both compilers compiled as their are w/o any changes so both unregisterised. On 7.8 testblockalloc runs well, on 7.10.1-rc2 it fails in threaded way with "Bus error"
```
karel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ ./testblockalloc +RTS -I0
Bus Error (core dumped)
```
When run in debugger it points to assignment of 0 to tso-\>alloc_limit:
```
karel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ gdb ./testblockalloc
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11"...
set ar(gdb) set args +RTS -I0
(gdb) r
Starting program: /home/karel/src/ghc-7.10.0.20150123/testsuite/tests/rts/testblockalloc +RTS -I0
warning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
Program received signal SIGSEGV, Segmentation fault.
0x006b62d4 in createThread (cap=0x821ec0, size=256) at rts/Threads.c:113
113 tso->alloc_limit = 0;
(gdb)
```
usually bus error is generated by unaligned access to data. I'll have a look at it, but any idea is of course highly appreciated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runtime fails in threaded way on SPARC (bus error -> unaligned access to data)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\nit looks like runtime has changed between 7.8 and 7.10 in a way it no longer works well on SPARC. Tested on SPARC/Solaris 2.11. Both compilers compiled as their are w/o any changes so both unregisterised. On 7.8 testblockalloc runs well, on 7.10.1-rc2 it fails in threaded way with \"Bus error\"\r\n{{{\r\nkarel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ ./testblockalloc +RTS -I0\r\nBus Error (core dumped)\r\n}}}\r\n\r\nWhen run in debugger it points to assignment of 0 to tso->alloc_limit:\r\n{{{\r\nkarel@niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ gdb ./testblockalloc\r\nGNU gdb 6.8\r\nCopyright (C) 2008 Free Software Foundation, Inc.\r\nLicense GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\r\nThis is free software: you are free to change and redistribute it.\r\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\r\nand \"show warranty\" for details.\r\nThis GDB was configured as \"sparc-sun-solaris2.11\"...\r\nset ar(gdb) set args +RTS -I0\r\n(gdb) r\r\nStarting program: /home/karel/src/ghc-7.10.0.20150123/testsuite/tests/rts/testblockalloc +RTS -I0\r\nwarning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074\r\nwarning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000074\r\nwarning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n0x006b62d4 in createThread (cap=0x821ec0, size=256) at rts/Threads.c:113\r\n113 tso->alloc_limit = 0;\r\n(gdb) \r\n}}}\r\n\r\nusually bus error is generated by unaligned access to data. I'll have a look at it, but any idea is of course highly appreciated.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1kgardaskgardashttps://gitlab.haskell.org/ghc/ghc/-/issues/10038Missing information about some libraries in the GHC 7.10.1 RC2 release notes2019-07-07T18:37:50ZAndrés Sicard-RamírezMissing information about some libraries in the GHC 7.10.1 RC2 release notesGHC 7.10.1.RC2 is shipped with the following libraries: haskeline-0.7.2.0, pretty-1.1.2.0, terminfo-0.4.0.1, transformers-0.4.2.0 and xhtml-3000.2.1.
In Section 1.5.3 of https://downloads.haskell.org/\~ghc/7.10.1-rc2/docs/users_guide.pd...GHC 7.10.1.RC2 is shipped with the following libraries: haskeline-0.7.2.0, pretty-1.1.2.0, terminfo-0.4.0.1, transformers-0.4.2.0 and xhtml-3000.2.1.
In Section 1.5.3 of https://downloads.haskell.org/\~ghc/7.10.1-rc2/docs/users_guide.pdf there isn't information about these libraries.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.10.1-rc2 |
| 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":"Missing information about some libraries in the GHC 7.10.1 RC2 release notes","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 7.10.1.RC2 is shipped with the following libraries: haskeline-0.7.2.0, pretty-1.1.2.0, terminfo-0.4.0.1, transformers-0.4.2.0 and xhtml-3000.2.1.\r\n\r\nIn Section 1.5.3 of https://downloads.haskell.org/~ghc/7.10.1-rc2/docs/users_guide.pdf there isn't information about these libraries.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10036Update Cabal before final 7.10 release2019-07-07T18:37:50ZEdward Z. YangUpdate Cabal before final 7.10 releaseIt will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC.
https://github.com/haskell/cabal/pull/2391
<details><summary>Trac metadata</...It will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC.
https://github.com/haskell/cabal/pull/2391
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Update Cabal before final 7.10 release","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC.\r\n\r\nhttps://github.com/haskell/cabal/pull/2391","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1