GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:04:54Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3204Binary package of GHC 6.10.2 fails to install on debian etch (amd64)2019-07-07T19:04:54ZsolBinary package of GHC 6.10.2 fails to install on debian etch (amd64)Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: Fi...Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized
`strip --version` gives:
```
GNU strip 2.17 Debian GNU/Linux
```
`uname -a` gives:
```
Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"Binary package of GHC 6.10.2 fails to install on debian etch (amd64)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:\r\n\r\n/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized\r\n\r\n\r\n{{{strip --version}}} gives:\r\n{{{\r\nGNU strip 2.17 Debian GNU/Linux\r\n}}}\r\n{{{uname -a}}} gives:\r\n{{{\r\nLinux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3249Unable to install Ghc packages by MacPorts2019-07-07T19:04:44ZsoopoUnable to install Ghc packages by MacPortsI was asked to send the following error here.
I am not sure where the bug is.
```
sudo port install hs-cabal hs-Crypto hs-libcabal ...I was asked to send the following error here.
I am not sure where the bug is.
```
sudo port install hs-cabal hs-Crypto hs-libcabal ~
Password:
---> Fetching hs-HTTP
---> Attempting to fetch HTTP-3001.1.4.tar.gz from http://trd.no.distfiles.macports.org/hs-HTTP
---> Verifying checksum(s) for hs-HTTP
---> Extracting hs-HTTP
---> Configuring hs-HTTP
---> Building hs-HTTP
---> Staging hs-HTTP into destroot
---> Installing hs-HTTP @3001.1.4_0
---> Activating hs-HTTP @3001.1.4_0
---> Cleaning hs-HTTP
---> Fetching hs-libcabal
---> Attempting to fetch Cabal-1.6.0.1.tar.gz from http://trd.no.distfiles.macports.org/hs-libcabal
---> Verifying checksum(s) for hs-libcabal
---> Extracting hs-libcabal
---> Configuring hs-libcabal
---> Building hs-libcabal
---> Staging hs-libcabal into destroot
---> Installing hs-libcabal @1.6.0.1_0
---> Activating hs-libcabal @1.6.0.1_0
---> Cleaning hs-libcabal
---> Fetching hs-zlib
---> Attempting to fetch zlib-0.5.0.0.tar.gz from http://trd.no.distfiles.macports.org/hs-zlib
---> Verifying checksum(s) for hs-zlib
---> Extracting hs-zlib
---> Configuring hs-zlib
---> Building hs-zlib
---> Staging hs-zlib into destroot
---> Installing hs-zlib @0.5.0.0_0
---> Activating hs-zlib @0.5.0.0_0
---> Cleaning hs-zlib
---> Fetching hs-cabal
---> Attempting to fetch cabal-install-0.6.0.tar.gz from http://trd.no.distfiles.macports.org/hs-cabal
---> Verifying checksum(s) for hs-cabal
---> Extracting hs-cabal
---> Configuring hs-cabal
---> Building hs-cabal
---> Staging hs-cabal into destroot
---> Installing hs-cabal @0.6.0_0
---> Activating hs-cabal @0.6.0_0
---> Cleaning hs-cabal
---> Fetching hs-Crypto
---> Attempting to fetch Crypto-4.1.0.tar.gz from http://trd.no.distfiles.macports.org/hs-Crypto
---> Verifying checksum(s) for hs-Crypto
---> Extracting hs-Crypto
---> Configuring hs-Crypto
---> Building hs-Crypto
Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1
Command output: In the instance declaration for `Integral (LargeKey a b)'
Data/LargeWord.hs:137:9:
Warning: No explicit method nor default method for `toRational'
In the instance declaration for `Real (LargeKey a b)'
Data/LargeWord.hs:140:9:
Warning: No explicit method nor default method for `toEnum'
In the instance declaration for `Enum (LargeKey a b)'
Data/LargeWord.hs:140:9:
Warning: No explicit method nor default method for `fromEnum'
In the instance declaration for `Enum (LargeKey a b)'
[10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o )
[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )
Linking dist/build/SymmetricTest/SymmetricTest ...
Building executable: SHA1Test...
Creating dist/build/SHA1Test (and its parents)
Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents)
/opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all-packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Error: Status 1 encountered during processing.
[
```https://gitlab.haskell.org/ghc/ghc/-/issues/3268implement the Cabal ${pkgroot} spec extension2019-07-07T19:04:40Zduncanimplement the Cabal ${pkgroot} spec extensionSee the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are ...See the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).
The open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"implement the Cabal ${pkgroot} spec extension","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See the proposal for relative paths in installed package descriptions:\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2009-May/011772.html\r\n\r\nBasically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).\r\n\r\nThe open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://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/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/3818ghc-pkg prints warnings to stdout instead of stderr2019-07-07T19:02:00ZJoachim Breitnermail@joachim-breitner.deghc-pkg prints warnings to stdout instead of stderrThe warning
```
WARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache
use 'ghc-pkg recache' to fix.
```
is printed to stdout, which breaks scripts. It should be printed to stderr instead.
<details><summary>...The warning
```
WARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache
use 'ghc-pkg recache' to fix.
```
is printed to stdout, which breaks scripts. It should be printed to stderr instead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| 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":"ghc-pkg prints warnings to stdout instead of stderr","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The warning\r\n{{{\r\nWARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache\r\n use 'ghc-pkg recache' to fix.\r\n}}}\r\nis printed to stdout, which breaks scripts. It should be printed to stderr instead.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3930ghci does not consider library-dirs of dependent packages for dlopen()2019-07-07T19:01:27Zduncanghci does not consider library-dirs of dependent packages for dlopen()On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent pa...On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent packages.
This shows up with gtk2hs on OSX when the glib and gtk C libs are in a non-standard location (/opt/local/lib). The glib package registration file uses `library-dirs: /opt/local/lib` and the gtk package depend on the glib package. The gtk package requires the C lib libgthread-2.0.dynlib. This exists in `/opt/local/lib` however when loading the gtk package in ghci, it does not look in `/opt/local/lib`. It only does so if we modify the gtk registration file to specify `library-dirs: /opt/local/lib`.
This behaviour of not using the lib dirs of dependent packages is inconsistent with the static linking case. I suspect this bad behaviour is specific to OSX, because I think this has always worked in the gtk2hs windows installers.
<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":"ghci does not consider library-dirs of dependent packages for dlopen()","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":"On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent packages.\r\n\r\nThis shows up with gtk2hs on OSX when the glib and gtk C libs are in a non-standard location (/opt/local/lib). The glib package registration file uses `library-dirs: /opt/local/lib` and the gtk package depend on the glib package. The gtk package requires the C lib libgthread-2.0.dynlib. This exists in `/opt/local/lib` however when loading the gtk package in ghci, it does not look in `/opt/local/lib`. It only does so if we modify the gtk registration file to specify `library-dirs: /opt/local/lib`.\r\n\r\nThis behaviour of not using the lib dirs of dependent packages is inconsistent with the static linking case. I suspect this bad behaviour is specific to OSX, because I think this has always worked in the gtk2hs windows installers.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/3970ghc-pkg list segfaults in ghc-6.12.1.201003302019-07-07T19:01:18ZWolfram Kahlghc-pkg list segfaults in ghc-6.12.1.20100330ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
...ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
QuickCheck-2.1.0.3
array-0.3.0.0
base-3.0.3.2
base-4.2.0.1
bin-package-db-0.0.0.0
binary-0.5.0.2
bytestring-0.9.1.6
containers-0.3.0.0
directory-1.0.1.1
Segmentation fault
```
(Now, trying to install zlib, I also get:
```
./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
```
although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [Bug 559 in the Cabal trac](http://hackage.haskell.org/trac/hackage/ticket/599).)
Wolfram
<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":"ghc-pkg list segfaults in ghc-6.12.1.20100330","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":"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:\r\n\r\n{{{\r\n/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d\r\n Cabal-1.8.0.3\r\n QuickCheck-2.1.0.3\r\n array-0.3.0.0\r\n base-3.0.3.2\r\n base-4.2.0.1\r\n bin-package-db-0.0.0.0\r\n binary-0.5.0.2\r\n bytestring-0.9.1.6\r\n containers-0.3.0.0\r\n directory-1.0.1.1\r\n Segmentation fault\r\n}}}\r\n\r\n(Now, trying to install zlib, I also get:\r\n{{{\r\n ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p\r\nConfiguring zlib-0.5.2.0...\r\nSetup: failed to parse output of 'ghc-pkg dump'\r\n}}}\r\nalthough I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3971FFI callback segfaults on PPC2019-07-07T19:01:18ZWolfram KahlFFI callback segfaults on PPCghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
...ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
QuickCheck-2.1.0.3
array-0.3.0.0
base-3.0.3.2
base-4.2.0.1
bin-package-db-0.0.0.0
binary-0.5.0.2
bytestring-0.9.1.6
containers-0.3.0.0
directory-1.0.1.1
Segmentation fault
```
(Now, trying to install zlib, I also get:
```
./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
```
although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [Bug 559 in the Cabal trac](http://hackage.haskell.org/trac/hackage/ticket/599).)
Wolfram
<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":"ghc-pkg list segfaults in ghc-6.12.1.20100330","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":"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:\r\n\r\n{{{\r\n/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d\r\n Cabal-1.8.0.3\r\n QuickCheck-2.1.0.3\r\n array-0.3.0.0\r\n base-3.0.3.2\r\n base-4.2.0.1\r\n bin-package-db-0.0.0.0\r\n binary-0.5.0.2\r\n bytestring-0.9.1.6\r\n containers-0.3.0.0\r\n directory-1.0.1.1\r\n Segmentation fault\r\n}}}\r\n\r\n(Now, trying to install zlib, I also get:\r\n{{{\r\n ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p\r\nConfiguring zlib-0.5.2.0...\r\nSetup: failed to parse output of 'ghc-pkg dump'\r\n}}}\r\nalthough I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4072Local package DB doesn't take preference over global DB2019-07-07T19:00:49ZtibbeLocal package DB doesn't take preference over global DBI sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:
```
ghc -c Test.hs -package-conf dist/package.conf.inplace
```
This doesn't work
```
Test.hs:4:...I sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:
```
ghc -c Test.hs -package-conf dist/package.conf.inplace
```
This doesn't work
```
Test.hs:4:0:
Failed to load interface for `Data.Text.Lazy.Builder':
Use -v to see a list of the files searched for.
```
The global version of `text` gets picked instead of the local one (and in this case the global version lacks the `Data.Text.Lazy.Builder` module). I expect the package given on the command line to take preference.
Workaround: Bump the version number of the local package.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Local package DB doesn't take preference over global DB","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:\r\n\r\n{{{\r\nghc -c Test.hs -package-conf dist/package.conf.inplace\r\n}}}\r\n\r\nThis doesn't work\r\n\r\n{{{\r\nTest.hs:4:0:\r\n Failed to load interface for `Data.Text.Lazy.Builder':\r\n Use -v to see a list of the files searched for.\r\n}}}\r\n\r\nThe global version of `text` gets picked instead of the local one (and in this case the global version lacks the `Data.Text.Lazy.Builder` module). I expect the package given on the command line to take preference.\r\n\r\nWorkaround: Bump the version number of the local package.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4104ghc-pkg refuses to register packages if some include directories don't exist2019-07-07T19:00:32ZMaxime Henrion <mux@FreeBSD.org>ghc-pkg refuses to register packages if some include directories don't existWhen registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the direct...When registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the directories given by "pkg-config --cflags gtk+-2.0", which typically contains lots of redundant and possibly non-existent directories, depending on your operating system.
Maybe ghc-pkg should just warn instead?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| 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":"ghc-pkg refuses to register packages if some include directories don't exist","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the directories given by \"pkg-config --cflags gtk+-2.0\", which typically contains lots of redundant and possibly non-existent directories, depending on your operating system.\r\n\r\nMaybe ghc-pkg should just warn instead?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4158Non-ASCII author name breaks ghc-pkg recache2019-07-07T19:00:21ZAnders KaseorgNon-ASCII author name breaks ghc-pkg recache```
$ cabal install binary-shared
Resolving dependencies...
Configuring binary-shared-0.8...
Preprocessing library binary-shared-0.8...
Building binary-shared-0.8...
[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,
dist...```
$ cabal install binary-shared
Resolving dependencies...
Configuring binary-shared-0.8...
Preprocessing library binary-shared-0.8...
Building binary-shared-0.8...
[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,
dist/build/Data/Binary/Shared.o )
Registering binary-shared-0.8...
Installing library in /home/anders/.cabal/lib/binary-shared-0.8/ghc-6.12.1
Registering binary-shared-0.8...
$ ghc-pkg recache
ghc-pkg: /home/anders/.ghc/x86_64-linux-6.12.1/package.conf.d/binary-shared-0.8-00180db675f2ea73ce16a4820071cd80.conf:
hGetContents: invalid argument (invalid UTF-8 byte sequence)
```
The author’s name, Jürgen Nicklisch-Franken, is written in UTF-8 in binary-shared.cabal. It is translated to Haskell \\decimal-escaped Unicode syntax in package.conf.inplace, which is passed to ghc-pkg update. But the resulting .conf file contains the name in ISO-8859-1. This breaks ghc-pkg recache.
I’m using ghc6 6.12.1-13 on Ubuntu maverick amd64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| 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":"Non-ASCII author name breaks ghc-pkg recache","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cabal install binary-shared\r\nResolving dependencies...\r\nConfiguring binary-shared-0.8...\r\nPreprocessing library binary-shared-0.8...\r\nBuilding binary-shared-0.8...\r\n[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,\r\ndist/build/Data/Binary/Shared.o )\r\nRegistering binary-shared-0.8...\r\nInstalling library in /home/anders/.cabal/lib/binary-shared-0.8/ghc-6.12.1\r\nRegistering binary-shared-0.8...\r\n$ ghc-pkg recache\r\nghc-pkg: /home/anders/.ghc/x86_64-linux-6.12.1/package.conf.d/binary-shared-0.8-00180db675f2ea73ce16a4820071cd80.conf:\r\nhGetContents: invalid argument (invalid UTF-8 byte sequence)\r\n}}}\r\n\r\nThe author’s name, Jürgen Nicklisch-Franken, is written in UTF-8 in binary-shared.cabal. It is translated to Haskell \\decimal-escaped Unicode syntax in package.conf.inplace, which is passed to ghc-pkg update. But the resulting .conf file contains the name in ISO-8859-1. This breaks ghc-pkg recache.\r\n\r\nI’m using ghc6 6.12.1-13 on Ubuntu maverick amd64.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4260GHC Mac installer Perl path2019-07-07T18:59:48ZdonsGHC Mac installer Perl pathSee HP bug http://trac.haskell.org/haskell-platform/ticket/138
Perl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.
HP can patch and work around, but it would ...See HP bug http://trac.haskell.org/haskell-platform/ticket/138
Perl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.
HP can patch and work around, but it would be better to fix upstream.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC Mac installer Perl path","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See HP bug http://trac.haskell.org/haskell-platform/ticket/138 \r\n\r\nPerl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.\r\n\r\nHP can patch and work around, but it would be better to fix upstream.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4354OS X installer deletes old versions, breaks symlinks2019-07-07T18:59:22ZelaforgeOS X installer deletes old versions, breaks symlinksThe .pkg installer for ghc removes previous versions of ghc and leaves broken
stale symlinks in /usr/bin
The symlink issue can be fixed with a new create-links script, included. The
old script links through the Current symlink, which is...The .pkg installer for ghc removes previous versions of ghc and leaves broken
stale symlinks in /usr/bin
The symlink issue can be fixed with a new create-links script, included. The
old script links through the Current symlink, which is updated to point to
the latest version. So every new install breaks the symlinks for the old
one. The new script links through the version directory, so it doesn't get
broken when Current changes.
There are other binaries which are unversioned, like hsc2hs and haddock.
I guess this was a conscious decision so I didn't try to make versioned
symlinks to those, they just get overwritten with the last installed version.
I also changed create-links to put a version on /usr/share/doc/ghc. I left
the man pages unversioned because 'man ghc' should work.
The deletion problem is due to the fact that the OS X installer always wants
to delete an old version when installing a new one. It makes more sense for
a compiler to allow multiple concurrent versions. The way around this is to
append the version to the package name (the python installer does this).
Unfortunately, there are lots of places you can set the "bundle ID" and
as far as I can tell no documentation for it. So based on trial and error,
I appended the version to distrib/MacOS/Info.plist and the -i flag to
packagemaker. Both seem to be necessary. I use the PackageVersionInt, so
reinstalling a ghc with the same major and minor version but a different
patchelevel will overwrite it, as before, which seems reasonable.
This means the Uninstaller isn't so useful, since it's designed to only work
with a single installed version. I did a bit of work to extend it to remove
a certain version, but decided it's not really worth it. OS X programmers
don't generally have installers. The old uninstaller was also removing the
incorrect package receipt (it removes
org.haskell.glasgowHaskellCompiler.ghc.pkg.bom, which on my machine, is what
1. 12.1 used, but not anything newer).
I reckon the simplest thing is to just remove the uninstaller (and update the
doc in the installer to not mention it). If there are people who really like
it, I can finish off my fancy uninstall one version thing.
I left the uninstaller but can remove it in a separate patch if people agree.
I also changed occurrences of 'org.haskell.glasgowHaskellCompiler.ghc.pkg' to 'org.haskell.ghc.pkg'. It doesn't seem to have any effect, but older versions named the package glasgowHaskellCompiler.ghc and it seems messy and confusing to have multiple versions of the same identifier around.
I tested these changes on my machine, and they seem to work fine, but it would
be good to get a few more people to try it on their macs. After the changes,
installing the new .pkg should create
/Library/Receipts/boms/org.haskell.ghc.700.bom, and of course a Versions/700
and not overwrite any previous versions. GHC packages going forward should no
longer overwrite each other.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.1 |
| 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":"OS X installer deletes old versions, breaks symlinks","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The .pkg installer for ghc removes previous versions of ghc and leaves broken\r\nstale symlinks in /usr/bin\r\n\r\nThe symlink issue can be fixed with a new create-links script, included. The\r\nold script links through the Current symlink, which is updated to point to\r\nthe latest version. So every new install breaks the symlinks for the old\r\none. The new script links through the version directory, so it doesn't get\r\nbroken when Current changes.\r\n\r\nThere are other binaries which are unversioned, like hsc2hs and haddock.\r\nI guess this was a conscious decision so I didn't try to make versioned\r\nsymlinks to those, they just get overwritten with the last installed version.\r\n\r\nI also changed create-links to put a version on /usr/share/doc/ghc. I left\r\nthe man pages unversioned because 'man ghc' should work.\r\n\r\nThe deletion problem is due to the fact that the OS X installer always wants\r\nto delete an old version when installing a new one. It makes more sense for\r\na compiler to allow multiple concurrent versions. The way around this is to\r\nappend the version to the package name (the python installer does this).\r\nUnfortunately, there are lots of places you can set the \"bundle ID\" and\r\nas far as I can tell no documentation for it. So based on trial and error,\r\nI appended the version to distrib/MacOS/Info.plist and the -i flag to\r\npackagemaker. Both seem to be necessary. I use the PackageVersionInt, so\r\nreinstalling a ghc with the same major and minor version but a different\r\npatchelevel will overwrite it, as before, which seems reasonable.\r\n\r\nThis means the Uninstaller isn't so useful, since it's designed to only work\r\nwith a single installed version. I did a bit of work to extend it to remove\r\na certain version, but decided it's not really worth it. OS X programmers\r\ndon't generally have installers. The old uninstaller was also removing the\r\nincorrect package receipt (it removes\r\norg.haskell.glasgowHaskellCompiler.ghc.pkg.bom, which on my machine, is what\r\n6.12.1 used, but not anything newer).\r\n\r\nI reckon the simplest thing is to just remove the uninstaller (and update the\r\ndoc in the installer to not mention it). If there are people who really like\r\nit, I can finish off my fancy uninstall one version thing.\r\n\r\nI left the uninstaller but can remove it in a separate patch if people agree.\r\n\r\nI also changed occurrences of 'org.haskell.glasgowHaskellCompiler.ghc.pkg' to 'org.haskell.ghc.pkg'. It doesn't seem to have any effect, but older versions named the package glasgowHaskellCompiler.ghc and it seems messy and confusing to have multiple versions of the same identifier around.\r\n\r\nI tested these changes on my machine, and they seem to work fine, but it would \r\nbe good to get a few more people to try it on their macs. After the changes,\r\ninstalling the new .pkg should create \r\n/Library/Receipts/boms/org.haskell.ghc.700.bom, and of course a Versions/700\r\nand not overwrite any previous versions. GHC packages going forward should no\r\nlonger overwrite each other.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4843"include" directory missing in the ghc 7.0.1 windows installer2019-07-07T18:58:15Znsch"include" directory missing in the ghc 7.0.1 windows installerThe current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1\#windows is missing the "include" directory in its root directory.
For example this build fails because it cannot find **HsFFI.h**, which is located in `C:...The current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1\#windows is missing the "include" directory in its root directory.
For example this build fails because it cannot find **HsFFI.h**, which is located in `C:\Haskell\ghc-7.0.1\lib\include` and not in `C:\\Haskell\\ghc-7.0.1/include`, where GHC is looking for it:
```
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h
config.status: include/HsDirectoryConfig.h is unchanged
("C:\\Haskell\\ghc-7.0.1\\mingw\\bin\\gcc.exe",["C:\\Users\\Nils\\AppData\\Local\\Temp\\3048.c","-o","C:\\Users\\Nils\\AppData\\Local\\Temp\
\3048","-D__GLASGOW_HASKELL__=700","-Iinclude","-I.","-IC:\\Haskell\\ghc-7.0.1\\old-time-1.0.0.6\\include","-IC:\\Haskell\\ghc-7.0.1\\Win32-
2.2.0.1\\include","-IC:\\Haskell\\ghc-7.0.1\\bytestring-0.9.1.8\\include","-IC:\\Haskell\\ghc-7.0.1\\base-4.3.0.0\\include","-IC:\\Haskell\\
ghc-7.0.1/include","-IC:\\Haskell\\ghc-7.0.1/include","-LC:\\Haskell\\ghc-7.0.1\\old-time-1.0.0.6","-LC:\\Haskell\\ghc-7.0.1\\old-locale-1.0
.0.2","-LC:\\Haskell\\ghc-7.0.1\\filepath-1.2.0.0","-LC:\\Haskell\\ghc-7.0.1\\Win32-2.2.0.1","-LC:\\Haskell\\ghc-7.0.1\\bytestring-0.9.1.8",
"-LC:\\Haskell\\ghc-7.0.1\\base-4.3.0.0","-LC:\\Haskell\\ghc-7.0.1\\integer-gmp-0.2.0.2","-LC:\\Haskell\\ghc-7.0.1\\ghc-prim-0.2.0.0","-LC:\
\Haskell\\ghc-7.0.1","-LC:\\Haskell\\ghc-7.0.1"])
C:\Haskell\ghc-7.0.1\mingw\bin\gcc.exe returned ExitFailure 1 with error
message:
In file included from C:\Users\Nils\AppData\Local\Temp\3048.c:1:0:
include/HsDirectory.h:19:19: fatal error: HsFFI.h: No such file or directory
compilation terminated.
```
You have to pass `--extra-include-dirs=C:/Haskell/ghc-7.0.1/lib/include` to get it to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| 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":"\"include\" directory missing in the ghc 7.0.1 windows installer","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1#windows is missing the \"include\" directory in its root directory.\r\n\r\nFor example this build fails because it cannot find '''HsFFI.h''', which is located in `C:\\Haskell\\ghc-7.0.1\\lib\\include` and not in `C:\\\\Haskell\\\\ghc-7.0.1/include`, where GHC is looking for it:\r\n\r\n{{{\r\nconfigure: creating ./config.status\r\nconfig.status: creating include/HsDirectoryConfig.h\r\nconfig.status: include/HsDirectoryConfig.h is unchanged\r\n(\"C:\\\\Haskell\\\\ghc-7.0.1\\\\mingw\\\\bin\\\\gcc.exe\",[\"C:\\\\Users\\\\Nils\\\\AppData\\\\Local\\\\Temp\\\\3048.c\",\"-o\",\"C:\\\\Users\\\\Nils\\\\AppData\\\\Local\\\\Temp\\\r\n\\3048\",\"-D__GLASGOW_HASKELL__=700\",\"-Iinclude\",\"-I.\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\old-time-1.0.0.6\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\Win32-\r\n2.2.0.1\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\bytestring-0.9.1.8\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\base-4.3.0.0\\\\include\",\"-IC:\\\\Haskell\\\\\r\nghc-7.0.1/include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1/include\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\old-time-1.0.0.6\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\old-locale-1.0\r\n.0.2\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\filepath-1.2.0.0\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\Win32-2.2.0.1\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\bytestring-0.9.1.8\",\r\n\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\base-4.3.0.0\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\integer-gmp-0.2.0.2\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\ghc-prim-0.2.0.0\",\"-LC:\\\r\n\\Haskell\\\\ghc-7.0.1\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\"])\r\nC:\\Haskell\\ghc-7.0.1\\mingw\\bin\\gcc.exe returned ExitFailure 1 with error\r\nmessage:\r\nIn file included from C:\\Users\\Nils\\AppData\\Local\\Temp\\3048.c:1:0:\r\ninclude/HsDirectory.h:19:19: fatal error: HsFFI.h: No such file or directory\r\ncompilation terminated.\r\n}}}\r\n\r\nYou have to pass `--extra-include-dirs=C:/Haskell/ghc-7.0.1/lib/include` to get it to compile.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/5216Haskell Platform 2011.2.0.1 Setup2019-07-07T18:56:23ZguestHaskell Platform 2011.2.0.1 Setup"Could not write updated PATH to HKLM"
This message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago di..."Could not write updated PATH to HKLM"
This message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago did exactly the same)
After inserting the path by hand in the environment variables, ghc was found from the command prompt.
The fact that this message was given three times, and I just resolved one path, suggests that I am missing two other paths. Could you let me know which ones?
Thanks,
Stef Joosten
stef.joosten\@ou.nl
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | stef.joosten@ou.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haskell Platform 2011.2.0.1 Setup","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["\"windows","7\"","setup"],"differentials":[],"test_case":"","architecture":"","cc":["stef.joosten@ou.nl"],"type":"Bug","description":"\"Could not write updated PATH to HKLM\"\r\n\r\nThis message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago did exactly the same)\r\n\r\nAfter inserting the path by hand in the environment variables, ghc was found from the command prompt.\r\n\r\nThe fact that this message was given three times, and I just resolved one path, suggests that I am missing two other paths. Could you let me know which ones?\r\nThanks,\r\nStef Joosten\r\nstef.joosten@ou.nl","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5511-package should take priority over modules in the filesystem2019-07-07T18:54:57Zpeteg-package should take priority over modules in the filesystemImagine I have a GHC package called P. I build it using Cabal and a directory structure like so:
```
P/ -- project root, containing P.cabal etc.
P/Code/M.hs
P/Tests/T.hs
```
I build P and install it.
In P/ I want to say:
```
ghci -pa...Imagine I have a GHC package called P. I build it using Cabal and a directory structure like so:
```
P/ -- project root, containing P.cabal etc.
P/Code/M.hs
P/Tests/T.hs
```
I build P and install it.
In P/ I want to say:
```
ghci -package P Tests/T.hs
```
but ghci insists on loading Code/M.hs rather than using P - it seems to ignore the -package flag.
cheers
peter
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| 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":"-package should take priority over modules in the filesystem","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Imagine I have a GHC package called P. I build it using Cabal and a directory structure like so:\r\n\r\n{{{\r\nP/ -- project root, containing P.cabal etc.\r\nP/Code/M.hs\r\nP/Tests/T.hs\r\n}}}\r\n\r\nI build P and install it.\r\n\r\nIn P/ I want to say:\r\n\r\n{{{\r\nghci -package P Tests/T.hs\r\n}}}\r\n\r\nbut ghci insists on loading Code/M.hs rather than using P - it seems to ignore the -package flag.\r\n\r\ncheers\r\npeter","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5521Allow unknown fields in .cabal with X- at front2019-07-07T18:54:55Zzzo38Allow unknown fields in .cabal with X- at frontI have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.
<details><summary>Trac metadata</summary>
| Trac fi...I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow unknown fields in .cabal with X- at front","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5704Bug in the handling of wired-in packages (like template-haskell)2019-07-07T18:53:58ZSimon MarlowBug in the handling of wired-in packages (like template-haskell)If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` wit...If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:
```
Data/Aeson/TH.hs:181:1:
Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi
Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH
```
the bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:
```
wired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace
```
whereas we wanted to use `template-haskell-2.6.0.0`.
Not immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in the handling of wired-in packages (like template-haskell)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the \"wired-in\" package rather than the older one.\r\n\r\nThis happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:\r\n\r\n{{{\r\nData/Aeson/TH.hs:181:1:\r\n Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi\r\n Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH\r\n}}}\r\n\r\nthe bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:\r\n\r\n{{{\r\nwired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace\r\n}}}\r\n\r\nwhereas we wanted to use `template-haskell-2.6.0.0`.\r\n\r\nNot immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5709ghc-7.2 cannot find libraries in non-standard locations2019-07-07T18:53:56ZAndres Löhghc-7.2 cannot find libraries in non-standard locationsThe following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.
On NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:
```
$ ghc -package zli...The following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.
On NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:
```
$ ghc -package zlib -e "print ()"
()
$ ghc-pkg describe zlib | grep library-dirs -A 1
library-dirs: /nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4
/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
$ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
stat64("/nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4/libz.so", 0xb5e94490) = -1 ENOENT (No such file or directory)
stat64("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so", {st_mode=S_IFREG|0555, st_size=91092, ...}) = 0
open("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so", O_RDONLY) = 7
```
However, if I try exactly the same with ghc-7.2.1, I get:
```
$ ghc -package zlib -e "print ()"
<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)
$ ghc-pkg describe zlib | grep library-dirs -A 1
library-dirs: /nix/store/6zjd86g35dpxl5r6zrr67nnmf00qalkr-haskell-zlib-ghc7.2.1-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.2.1
/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
$ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
open("/nix/store/ri2nlzb1lsi0d1y7nb8dkhzhsnyd08k4-gmp-4.3.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/nmliqd429c0s4sdlbk0394zdfx86gvf9-ncurses-5.7/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
```
The directories listed by strace seem to be the ones used for building GHC itself. The directories in the package configuration file seem to be ignored.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| 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":"ghc-7.2 cannot find libraries in non-standard locations","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.\r\n\r\nOn NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:\r\n{{{\r\n$ ghc -package zlib -e \"print ()\"\r\n()\r\n$ ghc-pkg describe zlib | grep library-dirs -A 1\r\nlibrary-dirs: /nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4\r\n /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib\r\n$ strace ghc -package zlib -e \"print ()\" 2>&1 | grep libz.so\r\nstat64(\"/nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4/libz.so\", 0xb5e94490) = -1 ENOENT (No such file or directory)\r\nstat64(\"/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so\", {st_mode=S_IFREG|0555, st_size=91092, ...}) = 0\r\nopen(\"/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so\", O_RDONLY) = 7\r\n}}}\r\n\r\nHowever, if I try exactly the same with ghc-7.2.1, I get:\r\n{{{\r\n$ ghc -package zlib -e \"print ()\"\r\n<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)\r\n$ ghc-pkg describe zlib | grep library-dirs -A 1\r\nlibrary-dirs: /nix/store/6zjd86g35dpxl5r6zrr67nnmf00qalkr-haskell-zlib-ghc7.2.1-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.2.1\r\n /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib\r\n$ strace ghc -package zlib -e \"print ()\" 2>&1 | grep libz.so\r\nopen(\"/nix/store/ri2nlzb1lsi0d1y7nb8dkhzhsnyd08k4-gmp-4.3.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/nmliqd429c0s4sdlbk0394zdfx86gvf9-ncurses-5.7/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\n}}}\r\nThe directories listed by strace seem to be the ones used for building GHC itself. The directories in the package configuration file seem to be ignored.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5754Cabal cannot register a package in a directory with Unicode chars2019-07-07T18:53:44ZSimon MarlowCabal cannot register a package in a directory with Unicode charsWhile fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.
This appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4....While fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.
This appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4.
I'm not sure who's fault this is, but since it is GHC-version dependent it could well be ours.
```
c:\simonmar\scratch\áéóíúúíáλ>cabal register --inplace -v
c:\simonmar\ghc-validate\inplace\bin\ghc-stage2.exe --abi-hash -package-name par
allel-3.2.0.0 -hide-all-packages -fbuilding-cabal-package -i -idist\build -i. -i
dist\build\autogen -Idist\build\autogen -Idist\build -optP-include -optPdist\bui
ld\autogen\cabal_macros.h -odir dist\build -hidir dist\build -stubdir dist\build
-package-id array-0.3.0.3-inplace -package-id base-4.4.0.0-inplace -package-id
containers-0.4.2.0-inplace -package-id deepseq-1.2.0.1-inplace -O -feager-blackh
oling -Wall -XCPP -XBangPatterns Control.Seq Control.Parallel Control.Parallel.S
trategies
Registering parallel-3.2.0.0...
c:\simonmar\ghc-validate\inplace\bin\ghc-pkg.exe update - --global --user
cabal: fd:5: hGetContents: invalid argument (invalid UTF-8 byte sequence)
cabal: fd:5: invalid argument
```
I tried with cabal-install 0.8 and 0.10:
```
c:\simonmar\scratch\áéóíúúíáλ>cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library
c:\simonmar\scratch\áéóíúúíáλ>cabal +RTS --info
[("GHC RTS", "YES")
,("GHC version", "7.0.4")
,("RTS way", "rts_v")
,("Build platform", "i386-unknown-mingw32")
,("Build architecture", "i386")
,("Build OS", "mingw32")
,("Build vendor", "unknown")
,("Host platform", "i386-unknown-mingw32")
,("Host architecture", "i386")
,("Host OS", "mingw32")
,("Host vendor", "unknown")
,("Target platform", "i386-unknown-mingw32")
,("Target architecture", "i386")
,("Target OS", "mingw32")
,("Target vendor", "unknown")
,("Word size", "32")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
]
```
I haven't tried building cabal-install with 7.2 yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | duncan |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cabal cannot register a package in a directory with Unicode chars","status":"New","operating_system":"Unknown/Multiple","component":"Package system","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["duncan"],"type":"Bug","description":"While fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.\r\n\r\nThis appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4.\r\n\r\nI'm not sure who's fault this is, but since it is GHC-version dependent it could well be ours.\r\n\r\n{{{\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal register --inplace -v\r\nc:\\simonmar\\ghc-validate\\inplace\\bin\\ghc-stage2.exe --abi-hash -package-name par\r\nallel-3.2.0.0 -hide-all-packages -fbuilding-cabal-package -i -idist\\build -i. -i\r\ndist\\build\\autogen -Idist\\build\\autogen -Idist\\build -optP-include -optPdist\\bui\r\nld\\autogen\\cabal_macros.h -odir dist\\build -hidir dist\\build -stubdir dist\\build\r\n -package-id array-0.3.0.3-inplace -package-id base-4.4.0.0-inplace -package-id\r\ncontainers-0.4.2.0-inplace -package-id deepseq-1.2.0.1-inplace -O -feager-blackh\r\noling -Wall -XCPP -XBangPatterns Control.Seq Control.Parallel Control.Parallel.S\r\ntrategies\r\nRegistering parallel-3.2.0.0...\r\nc:\\simonmar\\ghc-validate\\inplace\\bin\\ghc-pkg.exe update - --global --user\r\ncabal: fd:5: hGetContents: invalid argument (invalid UTF-8 byte sequence)\r\ncabal: fd:5: invalid argument\r\n}}}\r\n\r\nI tried with cabal-install 0.8 and 0.10:\r\n\r\n{{{\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal --version\r\ncabal-install version 0.10.2\r\nusing version 1.10.2.0 of the Cabal library\r\n\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal +RTS --info\r\n [(\"GHC RTS\", \"YES\")\r\n ,(\"GHC version\", \"7.0.4\")\r\n ,(\"RTS way\", \"rts_v\")\r\n ,(\"Build platform\", \"i386-unknown-mingw32\")\r\n ,(\"Build architecture\", \"i386\")\r\n ,(\"Build OS\", \"mingw32\")\r\n ,(\"Build vendor\", \"unknown\")\r\n ,(\"Host platform\", \"i386-unknown-mingw32\")\r\n ,(\"Host architecture\", \"i386\")\r\n ,(\"Host OS\", \"mingw32\")\r\n ,(\"Host vendor\", \"unknown\")\r\n ,(\"Target platform\", \"i386-unknown-mingw32\")\r\n ,(\"Target architecture\", \"i386\")\r\n ,(\"Target OS\", \"mingw32\")\r\n ,(\"Target vendor\", \"unknown\")\r\n ,(\"Word size\", \"32\")\r\n ,(\"Compiler unregisterised\", \"NO\")\r\n ,(\"Tables next to code\", \"YES\")\r\n ]\r\n}}}\r\n\r\nI haven't tried building cabal-install with 7.2 yet.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5907Crashed loading package Safe2019-07-07T18:53:03ZguestCrashed loading package Safe```
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package safe-0.3.3 ... ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
load...```
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package safe-0.3.3 ... ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
loadObj "C:\\Documents and Settings\\\1042\1083\1072\1076\1099\1082\1072\\Application Data\\cabal\\safe-0.3.3\\ghc-7.0.3\\HSsafe-0.3.3.o": failed
```
Before that I installed package Safe using cabal.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/7324GHC 7.6.1 ships with a buggy Cabal2019-07-07T18:50:15Ztd123GHC 7.6.1 ships with a buggy CabalUsing ghc 7.6.1
$ rm -rf \~/.cabal \# To force a new default config being written
$ cabal update \# To write default config
Config file path source is default config file.
Config file /home/bardur/.cabal/config not found.
Writing defaul...Using ghc 7.6.1
$ rm -rf \~/.cabal \# To force a new default config being written
$ cabal update \# To write default config
Config file path source is default config file.
Config file /home/bardur/.cabal/config not found.
Writing default configuration to /home/bardur/.cabal/config
Downloading the latest package list from hackage.haskell.org
$ cabal install foo
cabal: Command.optionToFieldDescr: feature not implemented
related bug report: https://bugs.archlinux.org/task/31864
Although this particular bug doesn't seem to be severe since once you remove the incorrect jobs line in the .cabal/config file it starts working again, it is quite annoying.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| 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":"GHC 7.6.1 ships with a buggy Cabal","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using ghc 7.6.1\r\n\r\n$ rm -rf ~/.cabal # To force a new default config being written\r\n$ cabal update # To write default config\r\nConfig file path source is default config file.\r\nConfig file /home/bardur/.cabal/config not found.\r\nWriting default configuration to /home/bardur/.cabal/config\r\nDownloading the latest package list from hackage.haskell.org\r\n$ cabal install foo\r\ncabal: Command.optionToFieldDescr: feature not implemented\r\n\r\nrelated bug report: https://bugs.archlinux.org/task/31864\r\n\r\nAlthough this particular bug doesn't seem to be severe since once you remove the incorrect jobs line in the .cabal/config file it starts working again, it is quite annoying.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7531after manualy installing array-0.4.0.12019-07-07T18:49:20Zguestafter manualy installing array-0.4.0.1After manually installing array-0.4.0.1 installation manually of Cabal -1.16.0.3 print:
```
c:\download\archive\Cabal\1.16.0.3\Cabal-1.16.0.3>runghc Setup.hs install
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-...After manually installing array-0.4.0.1 installation manually of Cabal -1.16.0.3 print:
```
c:\download\archive\Cabal\1.16.0.3\Cabal-1.16.0.3>runghc Setup.hs install
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
interactiveUI:setBuffering2
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7990ghc-pkg warning shows the wrong command2019-07-07T18:47:09Zmcandreghc-pkg warning shows the wrong commandWhen ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global...When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global caches, "ghc-pkg --global recache" successfully clears the warning. For out of date user caches, "ghc-pkg --user recache" clears the warning.
In the future, could ghc-pkg display the command more specific to the problem?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"ghc-pkg warning shows the wrong command","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending \"ghc-pkg recache\". However, sometimes running this command does not fix the problem, because it targets the wrong cache.\r\n\r\nFor out of date global caches, \"ghc-pkg --global recache\" successfully clears the warning. For out of date user caches, \"ghc-pkg --user recache\" clears the warning.\r\n\r\nIn the future, could ghc-pkg display the command more specific to the problem?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8407Module re-exports at the package level2019-07-07T18:45:11ZJoachim Breitnermail@joachim-breitner.deModule re-exports at the package levelFor various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design s...For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design spec at ModuleReexports; this bug is to track the progress.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Module re-exports at the package level","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.\r\n\r\nI wrote up a design spec at ModuleReexports; this bug is to track the progress.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/8442Cabal-install internal error with any use2019-07-07T18:45:03ZsenkCabal-install internal error with any useAny attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used wa...Any attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.
```
cabal install hakyll
cabal-install: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.6.3 for x86_64_portbld_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"Cabal-install internal error with any use","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Any attempt to use cabal-install fails with an internal error.\r\n\r\nUsed FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.\r\n\r\n{{{\r\ncabal install hakyll\r\ncabal-install: internal error: evacuate(static): strange closure type -385875968\r\n (GHC version 7.6.3 for x86_64_portbld_freebsd)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/8591Concurrent executions of ghc-pkg can cause inconstant package.cache files2022-03-29T16:17:37ZjanmConcurrent executions of ghc-pkg can cause inconstant package.cache filesI am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in gh...I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.
In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated)
The FreeBSD ports system is used to drive the Haskell build system.
The process works single threaded and fails intermittently when done in parallel.
Building: devel/hs-data-default-instances-base
Building: devel/hs-data-default-instances-containers
Building: devel/hs-data-default-instances-old-locale
Built: devel/hs-dlist
Building: devel/hs-data-default-instances-dlist
Built: devel/hs-temporary
Built: jail-image-full
Installing: system-image__jail-image-full
Built: devel/hs-base64-bytestring
Built: archivers/hs-zlib
Building: security/hs-digest
Built: devel/hs-syb
Building: textproc/hs-hs-bibutils
Building: textproc/hs-pandoc-types
Built: devel/hs-utf8-string
Built: devel/hs-data-default-instances-old-locale
Built: devel/hs-data-default-instances-containers
Built: devel/hs-data-default-instances-base
Built: devel/hs-data-default-instances-dlist
Building: devel/hs-data-default
Built: devel/hs-random
Installed: system-image__lang/ghc
Installing: system-image__archivers/hs-zlib
Installing: system-image__devel/hs-utf8-string
Installing: system-image__devel/hs-syb
Installing: system-image__devel/hs-base64-bytestring
Installing: system-image__devel/hs-data-default-class
Installing: system-image__devel/hs-dlist
Installing: system-image__devel/hs-random
Installing: system-image__devel/hs-temporary
Installing: system-image__devel/hs-extensible-exceptions
Built: devel/hs-data-default FAILED
The error from the Haskell data-default build was:
setup: At least the following dependencies are missing:
data-default-instances-base -any
Looking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default-instances-base
Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.
To me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | FreeBSD |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Concurrent executions of ghc-pkg can cause inconstant package.cache files","status":"New","operating_system":"FreeBSD","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["ghc-pkg","race"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.\r\n\r\nI am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.\r\n\r\nIn my case, the following things happened: (\"Building\" indicates a start, \"Built\" indicates completion, \"Installing\" is setup in a separate chroot'd environment and is isolated)\r\n\r\nThe FreeBSD ports system is used to drive the Haskell build system.\r\n\r\nThe process works single threaded and fails intermittently when done in parallel.\r\n\r\nBuilding: devel/hs-data-default-instances-base\r\nBuilding: devel/hs-data-default-instances-containers\r\nBuilding: devel/hs-data-default-instances-old-locale\r\nBuilt: devel/hs-dlist \r\nBuilding: devel/hs-data-default-instances-dlist\r\nBuilt: devel/hs-temporary \r\nBuilt: jail-image-full \r\nInstalling: system-image__jail-image-full\r\nBuilt: devel/hs-base64-bytestring \r\nBuilt: archivers/hs-zlib \r\nBuilding: security/hs-digest\r\nBuilt: devel/hs-syb \r\nBuilding: textproc/hs-hs-bibutils\r\nBuilding: textproc/hs-pandoc-types\r\nBuilt: devel/hs-utf8-string \r\nBuilt: devel/hs-data-default-instances-old-locale \r\nBuilt: devel/hs-data-default-instances-containers \r\nBuilt: devel/hs-data-default-instances-base \r\nBuilt: devel/hs-data-default-instances-dlist \r\nBuilding: devel/hs-data-default\r\nBuilt: devel/hs-random \r\nInstalled: system-image__lang/ghc \r\nInstalling: system-image__archivers/hs-zlib\r\nInstalling: system-image__devel/hs-utf8-string\r\nInstalling: system-image__devel/hs-syb\r\nInstalling: system-image__devel/hs-base64-bytestring\r\nInstalling: system-image__devel/hs-data-default-class\r\nInstalling: system-image__devel/hs-dlist\r\nInstalling: system-image__devel/hs-random\r\nInstalling: system-image__devel/hs-temporary\r\nInstalling: system-image__devel/hs-extensible-exceptions\r\nBuilt: devel/hs-data-default FAILED\r\n\r\nThe error from the Haskell data-default build was:\r\n\r\nsetup: At least the following dependencies are missing:\r\ndata-default-instances-base -any\r\n\r\nLooking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running \"ghc-pkg list\" did not show data-default-instances-base\r\n\r\nRunning /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.\r\n\r\nTo me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/9009Confusing error message when loading package with TH2019-07-07T18:42:20ZJan Stolarekjan.stolarek@ed.ac.ukConfusing error message when loading package with THI got this error message when compiling a file that calls Template Haskell function from `singletons` package:
```
[1 of 1] Compiling Splices ( Splices.hs, Splices.o )
Loading package ghc-prim ... linking ... done.
Loading pack...I got this error message when compiling a file that calls Template Haskell function from `singletons` package:
```
[1 of 1] Compiling Splices ( Splices.hs, Splices.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-0.4.1 ... linking ... done.
Loading package th-desugar-1.4.0 ... linking ... done.
Loading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info)
```
After some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"Confusing error message when loading package with TH","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got this error message when compiling a file that calls Template Haskell function from `singletons` package:\r\n\r\n{{{\r\n[1 of 1] Compiling Splices ( Splices.hs, Splices.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package transformers-0.3.0.0 ... linking ... done.\r\nLoading package pretty-1.1.1.1 ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package mtl-2.1.2 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package syb-0.4.1 ... linking ... done.\r\nLoading package th-desugar-1.4.0 ... linking ... done.\r\nLoading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info)\r\n}}}\r\n\r\nAfter some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9060`cabal` linking error with GHC 7.8.22019-07-07T18:42:06Zpseudonom`cabal` linking error with GHC 7.8.2First reported on [GitHub](https://github.com/haskell/cabal/issues/1830).
Trying
```
rm -r .ghc .cabal
cabal update
cabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0
cabal install polyparse
```
with GHC 7.8.2 throws the f...First reported on [GitHub](https://github.com/haskell/cabal/issues/1830).
Trying
```
rm -r .ghc .cabal
cabal update
cabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0
cabal install polyparse
```
with GHC 7.8.2 throws the following error:
```
[18 of 18] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o )
src/Text/ParserCombinators/HuttonMeijer.hs:53:10: Warning:
‘Parser’ is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
src/Text/ParserCombinators/HuttonMeijer.hs:63:10: Warning:
‘Parser’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
Linking...
/usr/bin/ar -r dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a dist/build/Text/ParserCombinators/HuttonMeijer.o dist/build/Text/ParserCombinators/HuttonMeijerWallace.o dist/build/Text/ParserCombinators/Poly.o dist/build/Text/ParserCombinators/Poly/Base.o dist/build/Text/ParserCombinators/Poly/Result.o dist/build/Text/ParserCombinators/Poly/Parser.o dist/build/Text/ParserCombinators/Poly/Plain.o dist/build/Text/ParserCombinators/Poly/Lazy.o dist/build/Text/ParserCombinators/Poly/StateParser.o dist/build/Text/ParserCombinators/Poly/State.o dist/build/Text/ParserCombinators/Poly/StateLazy.o dist/build/Text/ParserCombinators/Poly/Lex.o dist/build/Text/Parse.o dist/build/Text/ParserCombinators/Poly/ByteString.o dist/build/Text/ParserCombinators/Poly/ByteStringChar.o dist/build/Text/Parse/ByteString.o dist/build/Text/ParserCombinators/Poly/Text.o dist/build/Text/ParserCombinators/Poly/StateText.o
/usr/bin/ar: creating dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a
/usr/bin/strip dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a --strip-unneeded
/usr/bin/ghc -shared -dynamic -package-name polyparse-1.9 -no-auto-link-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id text-1.1.1.1-dd6849c4a01e66d368eb3b161ca67182 dist/build/Text/ParserCombinators/HuttonMeijer.dyn_o dist/build/Text/ParserCombinators/HuttonMeijerWallace.dyn_o dist/build/Text/ParserCombinators/Poly.dyn_o dist/build/Text/ParserCombinators/Poly/Base.dyn_o dist/build/Text/ParserCombinators/Poly/Result.dyn_o dist/build/Text/ParserCombinators/Poly/Parser.dyn_o dist/build/Text/ParserCombinators/Poly/Plain.dyn_o dist/build/Text/ParserCombinators/Poly/Lazy.dyn_o dist/build/Text/ParserCombinators/Poly/StateParser.dyn_o dist/build/Text/ParserCombinators/Poly/State.dyn_o dist/build/Text/ParserCombinators/Poly/StateLazy.dyn_o dist/build/Text/ParserCombinators/Poly/Lex.dyn_o dist/build/Text/Parse.dyn_o dist/build/Text/ParserCombinators/Poly/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/ByteStringChar.dyn_o dist/build/Text/Parse/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/Text.dyn_o dist/build/Text/ParserCombinators/Poly/StateText.dyn_o -o dist/build/libHSpolyparse-1.9-ghc7.8.2.so
/usr/bin/ld: cannot find -lHStext-1.1.1.1-ghc7.8.2
collect2: error: ld returned 1 exit status
Failed to install polyparse-1.9
Updating world file...
cabal: Error: some packages failed to install:
polyparse-1.9 failed during the building phase. The exception was:
ExitFailure 1
```
It happens with other packages as well. `hashable`, for example. The `text` that `polyparse` fails on is installed as a transitive dependency of `cabal-install`:
```
...
[43 of 43] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o )
Building C Sources...
creating dist/build
/usr/bin/ghc -c -odir dist/build -Idist/build -Iinclude -optc-O2 -package-db dist/package.conf.inplace -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 cbits/cbits.c
Linking...
/usr/bin/ar -r dist/build/libHStext-1.1.1.1.a dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o
/usr/bin/ar: creating dist/build/libHStext-1.1.1.1.a
/usr/bin/ld -x -r -o dist/build/HStext-1.1.1.1.o dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o
In-place registering text-1.1.1.1...
/usr/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace
directory dist/doc/html/text does exist: False
creating /home/intrados/.cabal/share/doc/text-1.1.1.1
Installing LICENSE to /home/intrados/.cabal/share/doc/text-1.1.1.1/LICENSE
Installing library in /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder
Installing dist/build/Data/Text.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text.hi
Installing dist/build/Data/Text/Array.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Array.hi
Installing dist/build/Data/Text/Encoding.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding.hi
Installing dist/build/Data/Text/Encoding/Error.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding/Error.hi
Installing dist/build/Data/Text/Foreign.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Foreign.hi
Installing dist/build/Data/Text/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/IO.hi
Installing dist/build/Data/Text/Internal.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal.hi
Installing dist/build/Data/Text/Internal/Builder.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder.hi
Installing dist/build/Data/Text/Internal/Builder/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Functions.hi
Installing dist/build/Data/Text/Internal/Builder/Int/Digits.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int/Digits.hi
Installing dist/build/Data/Text/Internal/Builder/RealFloat/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat/Functions.hi
Installing dist/build/Data/Text/Internal/Encoding/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion.hi
Installing dist/build/Data/Text/Internal/Encoding/Fusion/Common.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion/Common.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf16.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf16.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf32.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf32.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf8.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf8.hi
Installing dist/build/Data/Text/Internal/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Functions.hi
Installing dist/build/Data/Text/Internal/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion.hi
Installing dist/build/Data/Text/Internal/Fusion/CaseMapping.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/CaseMapping.hi
Installing dist/build/Data/Text/Internal/Fusion/Common.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Common.hi
Installing dist/build/Data/Text/Internal/Fusion/Size.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Size.hi
Installing dist/build/Data/Text/Internal/Fusion/Types.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Types.hi
Installing dist/build/Data/Text/Internal/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/IO.hi
Installing dist/build/Data/Text/Internal/Lazy.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy.hi
Installing dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding/Fusion.hi
Installing dist/build/Data/Text/Internal/Lazy/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Fusion.hi
Installing dist/build/Data/Text/Internal/Lazy/Search.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Search.hi
Installing dist/build/Data/Text/Internal/Private.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Private.hi
Installing dist/build/Data/Text/Internal/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Read.hi
Installing dist/build/Data/Text/Internal/Search.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Search.hi
Installing dist/build/Data/Text/Internal/Unsafe.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe.hi
Installing dist/build/Data/Text/Internal/Unsafe/Char.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Char.hi
Installing dist/build/Data/Text/Internal/Unsafe/Shift.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Shift.hi
Installing dist/build/Data/Text/Lazy.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy.hi
Installing dist/build/Data/Text/Lazy/Builder.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder.hi
Installing dist/build/Data/Text/Lazy/Builder/Int.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/Int.hi
Installing dist/build/Data/Text/Lazy/Builder/RealFloat.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/RealFloat.hi
Installing dist/build/Data/Text/Lazy/Encoding.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Encoding.hi
Installing dist/build/Data/Text/Lazy/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/IO.hi
Installing dist/build/Data/Text/Lazy/Internal.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Internal.hi
Installing dist/build/Data/Text/Lazy/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Read.hi
Installing dist/build/Data/Text/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Read.hi
Installing dist/build/Data/Text/Unsafe.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Unsafe.hi
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
Installing dist/build/libHStext-1.1.1.1.a to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/libHStext-1.1.1.1.a
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
Installing dist/build/HStext-1.1.1.1.o to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/HStext-1.1.1.1.o
/usr/bin/ghc --abi-hash -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-DINTEGER_GMP -optP-DHAVE_DEEPSEQ -optP-include -optPdist/build/autogen/cabal_macros.h -package-name text-1.1.1.1 -hide-all-packages -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 -XHaskell98 Data.Text Data.Text.Array Data.Text.Encoding Data.Text.Encoding.Error Data.Text.Foreign Data.Text.IO Data.Text.Internal Data.Text.Internal.Builder Data.Text.Internal.Builder.Functions Data.Text.Internal.Builder.Int.Digits Data.Text.Internal.Builder.RealFloat.Functions Data.Text.Internal.Encoding.Fusion Data.Text.Internal.Encoding.Fusion.Common Data.Text.Internal.Encoding.Utf16 Data.Text.Internal.Encoding.Utf32 Data.Text.Internal.Encoding.Utf8 Data.Text.Internal.Functions Data.Text.Internal.Fusion Data.Text.Internal.Fusion.CaseMapping Data.Text.Internal.Fusion.Common Data.Text.Internal.Fusion.Size Data.Text.Internal.Fusion.Types Data.Text.Internal.IO Data.Text.Internal.Lazy Data.Text.Internal.Lazy.Encoding.Fusion Data.Text.Internal.Lazy.Fusion Data.Text.Internal.Lazy.Search Data.Text.Internal.Private Data.Text.Internal.Read Data.Text.Internal.Search Data.Text.Internal.Unsafe Data.Text.Internal.Unsafe.Char Data.Text.Internal.Unsafe.Shift Data.Text.Lazy Data.Text.Lazy.Builder Data.Text.Lazy.Builder.Int Data.Text.Lazy.Builder.RealFloat Data.Text.Lazy.Encoding Data.Text.Lazy.IO Data.Text.Lazy.Internal Data.Text.Lazy.Read Data.Text.Read Data.Text.Unsafe -Wall -fwarn-tabs -funbox-strict-fields -O2
Registering text-1.1.1.1...
/usr/bin/ghc-pkg update - --global --user
Installed text-1.1.1.1
```
The same procedure succeeds with a clean GHC 7.6.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"`cabal` linking error with GHC 7.8.2","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First reported on [https://github.com/haskell/cabal/issues/1830 GitHub].\r\n\r\nTrying\r\n\r\n{{{\r\nrm -r .ghc .cabal\r\ncabal update\r\ncabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0\r\ncabal install polyparse\r\n}}}\r\n\r\nwith GHC 7.8.2 throws the following error:\r\n\r\n{{{\r\n[18 of 18] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o )\r\n\r\nsrc/Text/ParserCombinators/HuttonMeijer.hs:53:10: Warning:\r\n ‘Parser’ is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.\r\n\r\nsrc/Text/ParserCombinators/HuttonMeijer.hs:63:10: Warning:\r\n ‘Parser’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.\r\nLinking...\r\n/usr/bin/ar -r dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a dist/build/Text/ParserCombinators/HuttonMeijer.o dist/build/Text/ParserCombinators/HuttonMeijerWallace.o dist/build/Text/ParserCombinators/Poly.o dist/build/Text/ParserCombinators/Poly/Base.o dist/build/Text/ParserCombinators/Poly/Result.o dist/build/Text/ParserCombinators/Poly/Parser.o dist/build/Text/ParserCombinators/Poly/Plain.o dist/build/Text/ParserCombinators/Poly/Lazy.o dist/build/Text/ParserCombinators/Poly/StateParser.o dist/build/Text/ParserCombinators/Poly/State.o dist/build/Text/ParserCombinators/Poly/StateLazy.o dist/build/Text/ParserCombinators/Poly/Lex.o dist/build/Text/Parse.o dist/build/Text/ParserCombinators/Poly/ByteString.o dist/build/Text/ParserCombinators/Poly/ByteStringChar.o dist/build/Text/Parse/ByteString.o dist/build/Text/ParserCombinators/Poly/Text.o dist/build/Text/ParserCombinators/Poly/StateText.o\r\n/usr/bin/ar: creating dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a\r\n/usr/bin/strip dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a --strip-unneeded\r\n/usr/bin/ghc -shared -dynamic -package-name polyparse-1.9 -no-auto-link-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id text-1.1.1.1-dd6849c4a01e66d368eb3b161ca67182 dist/build/Text/ParserCombinators/HuttonMeijer.dyn_o dist/build/Text/ParserCombinators/HuttonMeijerWallace.dyn_o dist/build/Text/ParserCombinators/Poly.dyn_o dist/build/Text/ParserCombinators/Poly/Base.dyn_o dist/build/Text/ParserCombinators/Poly/Result.dyn_o dist/build/Text/ParserCombinators/Poly/Parser.dyn_o dist/build/Text/ParserCombinators/Poly/Plain.dyn_o dist/build/Text/ParserCombinators/Poly/Lazy.dyn_o dist/build/Text/ParserCombinators/Poly/StateParser.dyn_o dist/build/Text/ParserCombinators/Poly/State.dyn_o dist/build/Text/ParserCombinators/Poly/StateLazy.dyn_o dist/build/Text/ParserCombinators/Poly/Lex.dyn_o dist/build/Text/Parse.dyn_o dist/build/Text/ParserCombinators/Poly/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/ByteStringChar.dyn_o dist/build/Text/Parse/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/Text.dyn_o dist/build/Text/ParserCombinators/Poly/StateText.dyn_o -o dist/build/libHSpolyparse-1.9-ghc7.8.2.so\r\n/usr/bin/ld: cannot find -lHStext-1.1.1.1-ghc7.8.2\r\ncollect2: error: ld returned 1 exit status\r\nFailed to install polyparse-1.9\r\nUpdating world file...\r\ncabal: Error: some packages failed to install:\r\npolyparse-1.9 failed during the building phase. The exception was:\r\nExitFailure 1\r\n}}}\r\n\r\nIt happens with other packages as well. {{{hashable}}}, for example. The {{{text}}} that {{{polyparse}}} fails on is installed as a transitive dependency of {{{cabal-install}}}:\r\n\r\n{{{\r\n...\r\n[43 of 43] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o )\r\nBuilding C Sources...\r\ncreating dist/build\r\n/usr/bin/ghc -c -odir dist/build -Idist/build -Iinclude -optc-O2 -package-db dist/package.conf.inplace -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 cbits/cbits.c\r\nLinking...\r\n/usr/bin/ar -r dist/build/libHStext-1.1.1.1.a dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o\r\n/usr/bin/ar: creating dist/build/libHStext-1.1.1.1.a\r\n/usr/bin/ld -x -r -o dist/build/HStext-1.1.1.1.o dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o\r\nIn-place registering text-1.1.1.1...\r\n/usr/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace\r\ndirectory dist/doc/html/text does exist: False\r\ncreating /home/intrados/.cabal/share/doc/text-1.1.1.1\r\nInstalling LICENSE to /home/intrados/.cabal/share/doc/text-1.1.1.1/LICENSE\r\nInstalling library in /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder\r\nInstalling dist/build/Data/Text.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text.hi\r\nInstalling dist/build/Data/Text/Array.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Array.hi\r\nInstalling dist/build/Data/Text/Encoding.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding.hi\r\nInstalling dist/build/Data/Text/Encoding/Error.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding/Error.hi\r\nInstalling dist/build/Data/Text/Foreign.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Foreign.hi\r\nInstalling dist/build/Data/Text/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/IO.hi\r\nInstalling dist/build/Data/Text/Internal.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal.hi\r\nInstalling dist/build/Data/Text/Internal/Builder.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/Int/Digits.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int/Digits.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/RealFloat/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Fusion/Common.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion/Common.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf16.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf16.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf32.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf32.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf8.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf8.hi\r\nInstalling dist/build/Data/Text/Internal/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/CaseMapping.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/CaseMapping.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Common.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Common.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Size.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Size.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Types.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Types.hi\r\nInstalling dist/build/Data/Text/Internal/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/IO.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Search.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Search.hi\r\nInstalling dist/build/Data/Text/Internal/Private.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Private.hi\r\nInstalling dist/build/Data/Text/Internal/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Read.hi\r\nInstalling dist/build/Data/Text/Internal/Search.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Search.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe/Char.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Char.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe/Shift.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Shift.hi\r\nInstalling dist/build/Data/Text/Lazy.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder/Int.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/Int.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder/RealFloat.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/RealFloat.hi\r\nInstalling dist/build/Data/Text/Lazy/Encoding.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Encoding.hi\r\nInstalling dist/build/Data/Text/Lazy/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/IO.hi\r\nInstalling dist/build/Data/Text/Lazy/Internal.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Internal.hi\r\nInstalling dist/build/Data/Text/Lazy/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Read.hi\r\nInstalling dist/build/Data/Text/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Read.hi\r\nInstalling dist/build/Data/Text/Unsafe.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Unsafe.hi\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\nInstalling dist/build/libHStext-1.1.1.1.a to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/libHStext-1.1.1.1.a\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\nInstalling dist/build/HStext-1.1.1.1.o to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/HStext-1.1.1.1.o\r\n/usr/bin/ghc --abi-hash -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-DINTEGER_GMP -optP-DHAVE_DEEPSEQ -optP-include -optPdist/build/autogen/cabal_macros.h -package-name text-1.1.1.1 -hide-all-packages -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 -XHaskell98 Data.Text Data.Text.Array Data.Text.Encoding Data.Text.Encoding.Error Data.Text.Foreign Data.Text.IO Data.Text.Internal Data.Text.Internal.Builder Data.Text.Internal.Builder.Functions Data.Text.Internal.Builder.Int.Digits Data.Text.Internal.Builder.RealFloat.Functions Data.Text.Internal.Encoding.Fusion Data.Text.Internal.Encoding.Fusion.Common Data.Text.Internal.Encoding.Utf16 Data.Text.Internal.Encoding.Utf32 Data.Text.Internal.Encoding.Utf8 Data.Text.Internal.Functions Data.Text.Internal.Fusion Data.Text.Internal.Fusion.CaseMapping Data.Text.Internal.Fusion.Common Data.Text.Internal.Fusion.Size Data.Text.Internal.Fusion.Types Data.Text.Internal.IO Data.Text.Internal.Lazy Data.Text.Internal.Lazy.Encoding.Fusion Data.Text.Internal.Lazy.Fusion Data.Text.Internal.Lazy.Search Data.Text.Internal.Private Data.Text.Internal.Read Data.Text.Internal.Search Data.Text.Internal.Unsafe Data.Text.Internal.Unsafe.Char Data.Text.Internal.Unsafe.Shift Data.Text.Lazy Data.Text.Lazy.Builder Data.Text.Lazy.Builder.Int Data.Text.Lazy.Builder.RealFloat Data.Text.Lazy.Encoding Data.Text.Lazy.IO Data.Text.Lazy.Internal Data.Text.Lazy.Read Data.Text.Read Data.Text.Unsafe -Wall -fwarn-tabs -funbox-strict-fields -O2\r\nRegistering text-1.1.1.1...\r\n/usr/bin/ghc-pkg update - --global --user\r\nInstalled text-1.1.1.1\r\n}}}\r\n\r\nThe same procedure succeeds with a clean GHC 7.6.3.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9265Create PackageKey to replace PackageId, including version dependency information2019-07-07T18:41:08ZEdward Z. YangCreate PackageKey to replace PackageId, including version dependency information[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately nev...[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately never got merged into HEAD.
This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows:
- We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`.
- We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist.
- We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice.
- In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work.
- We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion.7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9331Release Cabal 1.22 before GHC 7.10 release2019-07-07T18:40:51ZEdward Z. YangRelease Cabal 1.22 before GHC 7.10 releaseJust a tracking bug so we don't forget.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type ...Just a tracking bug so we don't forget.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Release Cabal 1.22 before GHC 7.10 release","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Just a tracking bug so we don't forget.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9375Support for module thinning/renaming on command line2019-07-07T18:40:40ZEdward Z. YangSupport for module thinning/renaming on command lineIn #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo wh...In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package "foo (A as B, C)"`.
This feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping.
Since this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated.
In the \*\*absence\*\* of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT.
- \*With\*\* the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for module thinning/renaming on command line","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.8.2","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package \"foo (A as B, C)\"`.\r\n\r\nThis feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping.\r\n\r\nSince this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated.\r\n\r\nIn the **absence** of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT.\r\n\r\n**With** the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.)","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9625ghc: panic using --enable-executable-dynamic2019-07-07T18:39:46ZCoreyOConnorghc: panic using --enable-executable-dynamic(from: https://github.com/haskell/cabal/issues/2039)
Using --enable-executable-dynamic leads to a ghc panic.
Reproduction steps:
```
1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tes...(from: https://github.com/haskell/cabal/issues/2039)
Using --enable-executable-dynamic leads to a ghc panic.
Reproduction steps:
```
1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tests --enable-executable-dynamic
3. cabal test
```
Expected results: Test executes and passes.
Actual results:
```
ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Don't understand library name verify-foo
```
Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail.
Removing "--enable-executable-dynamic" results in a pass regardless of test suite name.
Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu.https://gitlab.haskell.org/ghc/ghc/-/issues/9998GHC binary package seems to be corrupt2019-07-07T18:37:59Zmark_christiaensGHC binary package seems to be corruptInstalled https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2
Did ghc-pkg check
Got:
ghc-pkg check
There are problems in package haskell-src-exts-1.16.0.1:
> Warning: library-dirs: /home/developer/.caba...Installed https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2
Did ghc-pkg check
Got:
ghc-pkg check
There are problems in package haskell-src-exts-1.16.0.1:
> Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory
> Warning: haddock-interfaces: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html/haskell-src-exts.haddock doesn't exist or isn't a file
> Warning: haddock-html: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html doesn't exist or isn't a directory
> import-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory
> cannot find any of \["Language/Haskell/Exts.hi","Language/Haskell/Exts.p_hi","Language/Haskell/Exts.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Lexer.hi","Language/Haskell/Exts/Lexer.p_hi","Language/Haskell/Exts/Lexer.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Parser.hi","Language/Haskell/Exts/Parser.p_hi","Language/Haskell/Exts/Parser.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Pretty.hi","Language/Haskell/Exts/Pretty.p_hi","Language/Haskell/Exts/Pretty.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Syntax.hi","Language/Haskell/Exts/Syntax.p_hi","Language/Haskell/Exts/Syntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Extension.hi","Language/Haskell/Exts/Extension.p_hi","Language/Haskell/Exts/Extension.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Build.hi","Language/Haskell/Exts/Build.p_hi","Language/Haskell/Exts/Build.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Fixity.hi","Language/Haskell/Exts/Fixity.p_hi","Language/Haskell/Exts/Fixity.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Comments.hi","Language/Haskell/Exts/Comments.p_hi","Language/Haskell/Exts/Comments.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/SrcLoc.hi","Language/Haskell/Exts/SrcLoc.p_hi","Language/Haskell/Exts/SrcLoc.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated.hi","Language/Haskell/Exts/Annotated.p_hi","Language/Haskell/Exts/Annotated.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Syntax.hi","Language/Haskell/Exts/Annotated/Syntax.p_hi","Language/Haskell/Exts/Annotated/Syntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Fixity.hi","Language/Haskell/Exts/Annotated/Fixity.p_hi","Language/Haskell/Exts/Annotated/Fixity.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Build.hi","Language/Haskell/Exts/Annotated/Build.p_hi","Language/Haskell/Exts/Annotated/Build.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/ExactPrint.hi","Language/Haskell/Exts/Annotated/ExactPrint.p_hi","Language/Haskell/Exts/Annotated/ExactPrint.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Simplify.hi","Language/Haskell/Exts/Annotated/Simplify.p_hi","Language/Haskell/Exts/Annotated/Simplify.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ExtScheme.hi","Language/Haskell/Exts/ExtScheme.p_hi","Language/Haskell/Exts/ExtScheme.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseMonad.hi","Language/Haskell/Exts/ParseMonad.p_hi","Language/Haskell/Exts/ParseMonad.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseSyntax.hi","Language/Haskell/Exts/ParseSyntax.p_hi","Language/Haskell/Exts/ParseSyntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/InternalLexer.hi","Language/Haskell/Exts/InternalLexer.p_hi","Language/Haskell/Exts/InternalLexer.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseUtils.hi","Language/Haskell/Exts/ParseUtils.p_hi","Language/Haskell/Exts/ParseUtils.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/InternalParser.hi","Language/Haskell/Exts/InternalParser.p_hi","Language/Haskell/Exts/InternalParser.dyn_hi"\]
> cannot find any of \["libHShaskell-src-exts-1.16.0.1.a","libHShaskell-src-exts-1.16.0.1.p_a","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.so","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.dylib","HShaskell-src-exts-1.16.0.1-ghc7.8.4.dll"\] on library path
There are problems in package aeson-0.8.0.2:
> Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/aeson-0.8.0.2 doesn't exist or isn't a directory
1. ..
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.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":"GHC binary package seems to be corrupt","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Installed https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2\r\n\r\nDid ghc-pkg check\r\n\r\nGot: \r\n\r\nghc-pkg check\r\nThere are problems in package haskell-src-exts-1.16.0.1:\r\n Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory\r\n Warning: haddock-interfaces: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html/haskell-src-exts.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html doesn't exist or isn't a directory\r\n import-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory\r\n cannot find any of [\"Language/Haskell/Exts.hi\",\"Language/Haskell/Exts.p_hi\",\"Language/Haskell/Exts.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Lexer.hi\",\"Language/Haskell/Exts/Lexer.p_hi\",\"Language/Haskell/Exts/Lexer.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Parser.hi\",\"Language/Haskell/Exts/Parser.p_hi\",\"Language/Haskell/Exts/Parser.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Pretty.hi\",\"Language/Haskell/Exts/Pretty.p_hi\",\"Language/Haskell/Exts/Pretty.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Syntax.hi\",\"Language/Haskell/Exts/Syntax.p_hi\",\"Language/Haskell/Exts/Syntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Extension.hi\",\"Language/Haskell/Exts/Extension.p_hi\",\"Language/Haskell/Exts/Extension.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Build.hi\",\"Language/Haskell/Exts/Build.p_hi\",\"Language/Haskell/Exts/Build.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Fixity.hi\",\"Language/Haskell/Exts/Fixity.p_hi\",\"Language/Haskell/Exts/Fixity.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Comments.hi\",\"Language/Haskell/Exts/Comments.p_hi\",\"Language/Haskell/Exts/Comments.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/SrcLoc.hi\",\"Language/Haskell/Exts/SrcLoc.p_hi\",\"Language/Haskell/Exts/SrcLoc.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated.hi\",\"Language/Haskell/Exts/Annotated.p_hi\",\"Language/Haskell/Exts/Annotated.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Syntax.hi\",\"Language/Haskell/Exts/Annotated/Syntax.p_hi\",\"Language/Haskell/Exts/Annotated/Syntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Fixity.hi\",\"Language/Haskell/Exts/Annotated/Fixity.p_hi\",\"Language/Haskell/Exts/Annotated/Fixity.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Build.hi\",\"Language/Haskell/Exts/Annotated/Build.p_hi\",\"Language/Haskell/Exts/Annotated/Build.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/ExactPrint.hi\",\"Language/Haskell/Exts/Annotated/ExactPrint.p_hi\",\"Language/Haskell/Exts/Annotated/ExactPrint.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Simplify.hi\",\"Language/Haskell/Exts/Annotated/Simplify.p_hi\",\"Language/Haskell/Exts/Annotated/Simplify.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ExtScheme.hi\",\"Language/Haskell/Exts/ExtScheme.p_hi\",\"Language/Haskell/Exts/ExtScheme.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseMonad.hi\",\"Language/Haskell/Exts/ParseMonad.p_hi\",\"Language/Haskell/Exts/ParseMonad.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseSyntax.hi\",\"Language/Haskell/Exts/ParseSyntax.p_hi\",\"Language/Haskell/Exts/ParseSyntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/InternalLexer.hi\",\"Language/Haskell/Exts/InternalLexer.p_hi\",\"Language/Haskell/Exts/InternalLexer.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseUtils.hi\",\"Language/Haskell/Exts/ParseUtils.p_hi\",\"Language/Haskell/Exts/ParseUtils.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/InternalParser.hi\",\"Language/Haskell/Exts/InternalParser.p_hi\",\"Language/Haskell/Exts/InternalParser.dyn_hi\"]\r\n cannot find any of [\"libHShaskell-src-exts-1.16.0.1.a\",\"libHShaskell-src-exts-1.16.0.1.p_a\",\"libHShaskell-src-exts-1.16.0.1-ghc7.8.4.so\",\"libHShaskell-src-exts-1.16.0.1-ghc7.8.4.dylib\",\"HShaskell-src-exts-1.16.0.1-ghc7.8.4.dll\"] on library path\r\nThere are problems in package aeson-0.8.0.2:\r\n Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/aeson-0.8.0.2 doesn't exist or isn't a directory\r\n\r\n...\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://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/10479Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh2019-07-07T18:35:45ZEdward Z. YangMake GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4GhThe GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://git...The GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://github.com/haskell/cabal/issues/2638 since there are some Cabal changes, which necessitate updating to Cabal head.
Cabal maintainers have expressed interest in this being merged into 7.10. To do this, we first have to merge the Cabal change into the 7.10 branch of Cabal, and apply the differential to GHC 7.10. (We shouldn't be blocked by the Cabal HEAD changes as those are not on the 7.10 branch.) If 7.10 release managers agree to let this patch in I volunteer to coordinate the changes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| 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":"Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://github.com/haskell/cabal/issues/2638 since there are some Cabal changes, which necessitate updating to Cabal head.\r\n\r\nCabal maintainers have expressed interest in this being merged into 7.10. To do this, we first have to merge the Cabal change into the 7.10 branch of Cabal, and apply the differential to GHC 7.10. (We shouldn't be blocked by the Cabal HEAD changes as those are not on the 7.10 branch.) If 7.10 release managers agree to let this patch in I volunteer to coordinate the changes.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10550Drop truncated package name prefix from package keys2019-07-07T18:35:22ZEdward Z. YangDrop truncated package name prefix from package keysEarly on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like `ghcpr_8TmvWUcS1U1IKHT0levwg3` rather than just `8TmvWUcS1U1IKHT0levwg3`, which would leave a user w...Early on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like `ghcpr_8TmvWUcS1U1IKHT0levwg3` rather than just `8TmvWUcS1U1IKHT0levwg3`, which would leave a user with no idea what the key is.
I now think that this is more trouble than its worth:
1. We have fixed library \*paths\* so that the full package name, version, key is in the path, e.g. libraries are installed to `/home/ezyang/Dev/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3` instead of `/home/ezyang/Dev/ghc-7.10.1/usr/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3`. This means that the biggest case where users might care about package keys is no longer relevant; a user will always be able to get the real package key.
1. The other case where package keys show up is in symbol names. However, symbol names already contain \*modules names\*, so today we have `procezu0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` but `0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` seems just about as clear (in particular, five letters just doesn't seem like enough to adequately describe long package names.)
1. Now, the reason why we don't want to truncate the prefix name is because it makes it more difficult to reliably, deterministically generate a package key based on a few parameters about a package: namely, any algorithm needs to know that `take 5 (filter (/= '-') packageName)` and prefix that onto the key. Really, we only care about the hash, but for most equality tests the prefix matters too! So it would be much nicer if we didn't have to care about the hash as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| 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":"Drop truncated package name prefix from package keys","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Early on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like `ghcpr_8TmvWUcS1U1IKHT0levwg3` rather than just `8TmvWUcS1U1IKHT0levwg3`, which would leave a user with no idea what the key is.\r\n\r\nI now think that this is more trouble than its worth:\r\n\r\n1. We have fixed library *paths* so that the full package name, version, key is in the path, e.g. libraries are installed to `/home/ezyang/Dev/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3` instead of `/home/ezyang/Dev/ghc-7.10.1/usr/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3`. This means that the biggest case where users might care about package keys is no longer relevant; a user will always be able to get the real package key.\r\n\r\n2. The other case where package keys show up is in symbol names. However, symbol names already contain *modules names*, so today we have `procezu0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` but `0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` seems just about as clear (in particular, five letters just doesn't seem like enough to adequately describe long package names.)\r\n\r\n3. Now, the reason why we don't want to truncate the prefix name is because it makes it more difficult to reliably, deterministically generate a package key based on a few parameters about a package: namely, any algorithm needs to know that `take 5 (filter (/= '-') packageName)` and prefix that onto the key. Really, we only care about the hash, but for most equality tests the prefix matters too! So it would be much nicer if we didn't have to care about the hash as well.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10566Move "package key" generation to GHC2019-07-07T18:35:13ZEdward Z. YangMove "package key" generation to GHCCurrently in GHC 7.10, we have the following situation:
1. Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package.
1. This...Currently in GHC 7.10, we have the following situation:
1. Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package.
1. This package key is passed to GHC via `-this-package-key`
1. GHC handles the package key opaquely
Now, in recent Backpack implementation, we need GHC to be able to compute package keys. (The concrete case: you're type-checking an interface file of an indefinite package, where you want to instantiate it with some assignment of its holes: instantiating those holes you need to instantiate any package keys mentioned in the interface, in which case you really want to be able to compute the hash.) So I want to move package key generation to GHC.
The primary implication is this: does Cabal continue to generate package keys? If it doesn't, we should revert from `-this-package-key` back to `-package-name` from the previous version (but maybe renamed because this name was bad). GHC then computes a package key based on `-package-name` and the explicitly mentioned `-package` dependencies, and Cabal reads it out with something akin to `--abi-hash`. If it does, we need to ensure GHC and Cabal's package key algorithms stay synchronized. I personally lean towards the first option.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| 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":"Move \"package key\" generation to GHC","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently in GHC 7.10, we have the following situation:\r\n\r\n1. Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package.\r\n2. This package key is passed to GHC via `-this-package-key`\r\n3. GHC handles the package key opaquely\r\n\r\nNow, in recent Backpack implementation, we need GHC to be able to compute package keys. (The concrete case: you're type-checking an interface file of an indefinite package, where you want to instantiate it with some assignment of its holes: instantiating those holes you need to instantiate any package keys mentioned in the interface, in which case you really want to be able to compute the hash.) So I want to move package key generation to GHC.\r\n\r\nThe primary implication is this: does Cabal continue to generate package keys? If it doesn't, we should revert from `-this-package-key` back to `-package-name` from the previous version (but maybe renamed because this name was bad). GHC then computes a package key based on `-package-name` and the explicitly mentioned `-package` dependencies, and Cabal reads it out with something akin to `--abi-hash`. If it does, we need to ensure GHC and Cabal's package key algorithms stay synchronized. I personally lean towards the first option.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10666Distinguish between semantic module / identity module in TcGblEnv, ModIface a...2019-07-07T18:34:44ZEdward Z. YangDistinguish between semantic module / identity module in TcGblEnv, ModIface and ModGutsWhen we write a signature like
```
package p where
signature H where
data T
```
and compile it to an interface file, there are two ways we might say what the `Module` of this interface is:
1. The \*\*identity module\*\* uniquely...When we write a signature like
```
package p where
signature H where
data T
```
and compile it to an interface file, there are two ways we might say what the `Module` of this interface is:
1. The \*\*identity module\*\* uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`.
1. The \*\*semantic module\*\* tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module.
For normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules.
By in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.)
I tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures.
Here are some things we could do:
1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct.
1. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules.
Pretty delicate.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"When we write a signature like\r\n\r\n{{{\r\npackage p where\r\n signature H where\r\n data T\r\n}}}\r\n\r\nand compile it to an interface file, there are two ways we might say what the `Module` of this interface is:\r\n\r\n1. The **identity module** uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`.\r\n\r\n2. The **semantic module** tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module.\r\n\r\nFor normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules.\r\n\r\nBy in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.)\r\n\r\nI tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures.\r\n\r\nHere are some things we could do:\r\n\r\n1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct.\r\n\r\n2. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules.\r\n\r\nPretty delicate.","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10679Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces2019-07-07T18:34:41ZEdward Z. YangGeneralize hi-boot/hi for signatures, to manage intermediate merged interfaces## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include ...## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include a-sig
signature A
```
Compiling `p/A.hsig` produces an interface file which contains just
the definitions declared in `p`. However, someone including `p`
should see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`
(which was included.)
### Example 2: Merging two home signatures
```
unit p where
signature A
signature B where
import A
...
signature A where
import B
...
```
What should we do if a signature is specified multiple times in the same
unit? The compilation of each produces a distinct interface, and the
public interface we want to expose is the merge of the two. (And by the
way, what's the source file name of `A`, if we are not using the inline syntax?)
### Example 3: Merging a signature and a module
```
unit p where
signature A
module B where
import A
...
module A where
import B
...
```
`A` and `B` are mutually recursive, and we want to use a signature file to
break the gap. The signature produces an interface file, only to be
overwritten when we actually define the module proper.
But wait! We have a solution for this example already: the first interface
file for `A` is not saved to `A.hi`, but `A.hi-boot`...
## The proposal
I want to take the `A.hi-boot` versus `A.hi` distinction and
generalize it: we should be able to name intermediate interface
files A.1.hi, A.2.hi, ... and finally A.hi (which
is publically visible outside the unit.) This naming convention applies
to Haskell files too.
### User-visible consequences
Every signature file is numbered, and every import of a signature file
refers to a specific number. This number is unique among all other
modules in a unit which share the same name. For backwards
compatibility, some number/file name extensions are treated specially:
1. `.hs` files compile to `.hi` (implicitly numbered 0)
1. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)
1. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)
1. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)
- \*Flex point:\*\* We could give `.hsig` files their own file extension
for interface files; just would require some more work to distinguish
between `hs-boot` and `hsig` as well as record the numbering.
To import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`
being equivalent `{-# SOURCE 1 #-}`.)
Inline Backpack files can omit numbering, since we can figure it out
based on the ordering of declarations (numbering in REVERSE order
of occurrence). Example 2 can be numbered as follows:
```
signature {-# SOURCE 2 #-} A
signature {-# SOURCE 1 #-} B where
import {-# SOURCE 2 #-} A
...
signature {-# SOURCE 1 #-} A where
import {-# SOURCE 1 #-} B
...
```
### Internal consequences
In many places in the code today, we record a boolean indicating if
we depended on the boot interface `hi-boot` or the normal interface `hi`.
We now replace this marker with an integer which records the numbering.
The primary affected components are dependency recording in interfaces,
interface loading code in GHC, and the implementation of `--make`.
### Interaction with signature merging
Unlike `hs-boot` files, `hsig` files can be included from external
units, in which case the semantics are that all signatures in scope
are merged together. The key rule is that we \*\*generate an hi
file for each partial merge\*\*; this means that whenever we want
to typecheck a module, there is exactly one interface file per
module we import. Consider this example:
```
unit a-sig where
signature A
unit a-sig2 where
signature A
unit p where
include a-sig
module B
include a-sig2
module C
signature A
module D
```
When compiling this, we generate four interface files for `A`:
```
unit p where
include a-sig
-- Produces A.3.hi-boot (a-sig)
module B -- uses A.3.hi-boot
include a-sig2
-- Produces A.2.hi-boot (a-sig + a-sig2)
module C -- uses A.2.hi-boot
signature A
-- Produces A.hi-boot (everything)
module D -- uses A.hi-boot
-- At the end, A.hi-boot copied to A.hi to be publically visible
```
## Can we do anything simpler?
There are a few barriers to doing something simpler:
1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.
1. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:
```
unit q where
signature M
signature A where
f :: Int -> Int
...
unit p where
signature A where
data T
module M where
import A -- should get T but not f
...
include q -- fill in M
module S where
import A -- should get T and f
```
> This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)
1. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"== The problem ==\r\n\r\nIn some situations, we need to output multiple interface\r\nfiles for what is morally the same module name.\r\n\r\n=== Example 1: Merging external and home signatures ===\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit p where\r\n include a-sig\r\n signature A\r\n}}}\r\n\r\nCompiling `p/A.hsig` produces an interface file which contains just\r\nthe definitions declared in `p`. However, someone including `p`\r\nshould see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`\r\n(which was included.)\r\n\r\n=== Example 2: Merging two home signatures ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n signature B where\r\n import A\r\n ...\r\n signature A where\r\n import B\r\n ...\r\n}}}\r\n\r\nWhat should we do if a signature is specified multiple times in the same\r\nunit? The compilation of each produces a distinct interface, and the\r\npublic interface we want to expose is the merge of the two. (And by the\r\nway, what's the source file name of `A`, if we are not using the inline syntax?)\r\n\r\n=== Example 3: Merging a signature and a module ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n module B where\r\n import A\r\n ...\r\n module A where\r\n import B\r\n ...\r\n}}}\r\n\r\n`A` and `B` are mutually recursive, and we want to use a signature file to\r\nbreak the gap. The signature produces an interface file, only to be\r\noverwritten when we actually define the module proper.\r\n\r\nBut wait! We have a solution for this example already: the first interface\r\nfile for `A` is not saved to `A.hi`, but `A.hi-boot`...\r\n\r\n== The proposal ==\r\n\r\nI want to take the `A.hi-boot` versus `A.hi` distinction and\r\ngeneralize it: we should be able to name intermediate interface\r\nfiles A.1.hi, A.2.hi, ... and finally A.hi (which\r\nis publically visible outside the unit.) This naming convention applies\r\nto Haskell files too.\r\n\r\n=== User-visible consequences ===\r\n\r\nEvery signature file is numbered, and every import of a signature file\r\nrefers to a specific number. This number is unique among all other\r\nmodules in a unit which share the same name. For backwards\r\ncompatibility, some number/file name extensions are treated specially:\r\n\r\n1. `.hs` files compile to `.hi` (implicitly numbered 0)\r\n\r\n2. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n3. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n4. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)\r\n\r\n**Flex point:** We could give `.hsig` files their own file extension\r\nfor interface files; just would require some more work to distinguish\r\nbetween `hs-boot` and `hsig` as well as record the numbering.\r\n\r\nTo import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`\r\nbeing equivalent `{-# SOURCE 1 #-}`.)\r\n\r\nInline Backpack files can omit numbering, since we can figure it out\r\nbased on the ordering of declarations (numbering in REVERSE order\r\nof occurrence). Example 2 can be numbered as follows:\r\n\r\n{{{\r\n signature {-# SOURCE 2 #-} A\r\n signature {-# SOURCE 1 #-} B where\r\n import {-# SOURCE 2 #-} A\r\n ...\r\n signature {-# SOURCE 1 #-} A where\r\n import {-# SOURCE 1 #-} B\r\n ...\r\n}}}\r\n\r\n=== Internal consequences ===\r\n\r\nIn many places in the code today, we record a boolean indicating if\r\nwe depended on the boot interface `hi-boot` or the normal interface `hi`.\r\nWe now replace this marker with an integer which records the numbering.\r\nThe primary affected components are dependency recording in interfaces,\r\ninterface loading code in GHC, and the implementation of `--make`.\r\n\r\n=== Interaction with signature merging ===\r\n\r\nUnlike `hs-boot` files, `hsig` files can be included from external\r\nunits, in which case the semantics are that all signatures in scope\r\nare merged together. The key rule is that we **generate an hi\r\nfile for each partial merge**; this means that whenever we want\r\nto typecheck a module, there is exactly one interface file per\r\nmodule we import. Consider this example:\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit a-sig2 where\r\n signature A\r\nunit p where\r\n include a-sig\r\n module B\r\n include a-sig2\r\n module C\r\n signature A\r\n module D\r\n}}}\r\n\r\nWhen compiling this, we generate four interface files for `A`:\r\n\r\n{{{\r\nunit p where\r\n include a-sig\r\n -- Produces A.3.hi-boot (a-sig)\r\n module B -- uses A.3.hi-boot\r\n include a-sig2\r\n -- Produces A.2.hi-boot (a-sig + a-sig2)\r\n module C -- uses A.2.hi-boot\r\n signature A\r\n -- Produces A.hi-boot (everything)\r\n module D -- uses A.hi-boot\r\n -- At the end, A.hi-boot copied to A.hi to be publically visible\r\n}}}\r\n\r\n== Can we do anything simpler? ==\r\n\r\nThere are a few barriers to doing something simpler:\r\n\r\n1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.\r\n\r\n2. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:\r\n{{{\r\nunit q where\r\n signature M\r\n signature A where\r\n f :: Int -> Int\r\n ...\r\nunit p where\r\n signature A where\r\n data T\r\n module M where\r\n import A -- should get T but not f\r\n ...\r\n include q -- fill in M\r\n module S where\r\n import A -- should get T and f\r\n}}}\r\n This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)\r\n\r\n3. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10680Make Backpack order-independent (again)2019-07-07T18:34:41ZEdward Z. YangMake Backpack order-independent (again)When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B...When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B
module B where
...
```
this fails to type-check, GHC complaining that `B` is not in scope. I did this, in part because it's what the Backpack paper described, and because it was "simpler" to implement.
I think we should move back to an order-independent scheme, for the following reasons:
1. Haskell users are used to not needing pay particularly close attention to the ordering of their modules, and forcing people to linearize their module descriptions would be spectacularly disruptive with large amounts of modules. So un-ordered modules are "more natural for a traditional Haskell user.
1. Order-independence imposes some constraints on how expressive programs are (with order-dependent Backpack, you can do some pretty tricky things by ordering things certain ways); this could simplify some aspects of compiler implementation and make Backpack easier to explain.
1. A particular case of (2): it seems a lot simpler UX-wise to let a user assume that if you import a module `M` in a unit, it doesn't matter where you import it: you always get the same set of identifiers brought into scope. Thus, the incremental results of signatures should not be visible, c.f. #10679
The main idea is that only the surface-syntax is un-ordered: the internal representation of units is a DAG which we work out in an elaboration phase, not altogether unsimilar from what `GhcMake` computes. An important auxiliary idea is that `import A` where `A` is backed by some signatures depends on EVERY signature in scope.
Here are the details:
- \*The intermediate representation.\*\* We translate into an intermediate representation which consists of a directed graph of:
• Each source-level module, signature and include, and
• Each unfilled requirement (called a “signature merge” node).
The edges of the directed graph signify a “depends on” relation, and are defined as follows:
• An include p depends on include q if, for some module name m, p requires m and q provides m.
• An include p depends on a module m if p requires a module named m.
• A module/signature m depends on include p if m imports a module provided by p.
• A module/signature m depends on a module n if m imports n.
• A module/signature m depends on a signature merge n if m imports n.
• A module/signature m depends on a signature n if m {-\# SOURCE \#-} imports n.
• A signature merge m depends on a local signature m (if it exists).
• A signature merge m depends on a include p, if the (renamed) include requires m.
- \*Elaboration.\*\* Take a Backpack file, construct this graph, and topsort it into a DAG of SCCs. SCCs with a single node are compileable as before. SCCs with multiple nodes will have to be managed with some mutual recursion mechanism; see refinements for more thoughts on this.
- \*Refinements:\*\*
1. \*\*Can a signature depend on a (home) module?\*\* Imports of this kind require a retypecheck loop. Consider this situation:
```
unit p where
signature H where
data T
module M where
import H
data S = S T
unit q where
include p
module Q where
import M
signature H where
import Q
data T = T S
```
> Here, signature H in q depends on Q. When we typecheck `Q`, we bring `M.S` into the type environment with a `TyThing` that describes the constructor as accepting an abstract type `T`. However, when we subsequently typecheck the local signature `H`, we must refine all `TyThing`s of `T` with the true description (e.g. constructor information). So you'll need to retypecheck `Q` (and `M`) in order to make sure the `TyThing` is correct.
1. \*\*Can an include depend on a (home) module?\*\* If the module has no (transitive) dependency on signatures, this is fine. However, it's easy to have a circular dependency. Consider:
```
unit p where
signature A -- imports nothing
signature B -- imports nothing
module M
unit q where
include p
module B where
import A
...
```
> `B` depends on `p` for `p/A.hsig`; however, `p` depends on `B` because this module is filling a requirement. However, if we were to include the internal graph of `p` into `q`, the resulting graph would not have an cycles; so this is one possibility of how to untangle this situation. However, if there's still a cycle (e.g. `A` imports `B`), then you will need at least a retypecheck loop, and maybe `hs-boot` style compilation. We're not going to implement this for now.
1. \*\*Can we deal with include-include dependency cycles?\*\* Yes! Just use the Backpack paper's strategy for creating a recursive unit key and compile the two packages `hs-boot` style. But I'm not planning on implementing this yet.
1. \*\*Can we deal with signature-signature dependency cycles?\*\* Ordered Backpack would have supported this:
```
unit a-sig where
signature A where
data T
unit ab-sig where
include a-sig
signature B where
import A
data S = S T
signature A where
import B
data T = T S
```
> In our model, `ab-sig` has a cycle. However, I believe any such cycle can be broken by creating sufficiently many units:
```
unit a-sig where
signature B where
data T
signature A where
data S = S T
unit b-sig where
signature A where
data S
signature B where
data T = T S
unit ab-sig where
include a-sig
include b-sig
```
> In principle, GHC could automatically break import cycles by replacing an import with an import of a reduced signature that simply has abstract type definitions. See #10681. (I'm not sure this is possible for all language features.) This technique would also work for normal modules, assuming that every function is explicitly annotated with a type.Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10714After implementing new installed package ID (hash of sdist), get rid of packa...2019-07-07T18:34:26ZEdward Z. YangAfter implementing new installed package ID (hash of sdist), get rid of package keysGHC tracking bug for https://github.com/haskell/cabal/issues/2745
Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should r...GHC tracking bug for https://github.com/haskell/cabal/issues/2745
Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should rename this.)
Internally, if we can assume that `PackageKey == InstalledPackageId`, we can do away with the `InstalledPackageId` map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs\`) and GHC's guts (which record package keys).
Blocked on Cabal not actually using ABI hashes to identify packages.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| 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":"After implementing new installed package ID (hash of sdist), get rid of package keys","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC tracking bug for https://github.com/haskell/cabal/issues/2745\r\n\r\nExternally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should rename this.)\r\n\r\nInternally, if we can assume that `PackageKey == InstalledPackageId`, we can do away with the `InstalledPackageId` map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs`) and GHC's guts (which record package keys). \r\n\r\nBlocked on Cabal not actually using ABI hashes to identify packages.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10723Make declarations in signatures "weakly bound" until they are used2019-07-07T18:34:19ZEdward Z. YangMake declarations in signatures "weakly bound" until they are usedSuppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the sign...Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API.
Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change.
Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible.
What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used!
How can we achieve this?
1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.)
1. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package.
So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use.
(PS: another moral here, is that `include`s are bad UNLESS you are including a signature package! Because an include for a concrete module is a dependency you can't override...)Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10798Signatures with only types should not be included in unit keys2019-07-07T18:33:50ZEdward Z. YangSignatures with only types should not be included in unit keysSuppose we want to modularize the dependence on `p` in this program:
```
unit p where
module A where
data T = T
mkT = T
unit q where
include p
module B where
import A
bar = mkT
```
The obvious signature to write f...Suppose we want to modularize the dependence on `p` in this program:
```
unit p where
module A where
data T = T
mkT = T
unit q where
include p
module B where
import A
bar = mkT
```
The obvious signature to write for `A` is:
```
signature A where
data T
mkT :: T
```
But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here.
But suppose we change our signature to be:
```
signature A.Types where
data T
signature A where
import A.Types
mkT :: T
```
This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question.
Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated.
So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Signatures with only types should not be included in unit keys","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Suppose we want to modularize the dependence on `p` in this program:\r\n\r\n{{{\r\nunit p where\r\n module A where\r\n data T = T\r\n mkT = T\r\nunit q where\r\n include p\r\n module B where\r\n import A\r\n bar = mkT\r\n}}}\r\n\r\nThe obvious signature to write for `A` is:\r\n\r\n{{{\r\nsignature A where\r\n data T\r\n mkT :: T\r\n}}}\r\n\r\nBut this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here.\r\n\r\nBut suppose we change our signature to be:\r\n\r\n{{{\r\nsignature A.Types where\r\n data T\r\nsignature A where\r\n import A.Types\r\n mkT :: T\r\n}}}\r\n\r\nThis is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question.\r\n\r\nNow there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated.\r\n\r\nSo, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.)","type_of_failure":"OtherFailure","blocking":[]} -->⊥Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/11025Per-database shadowing2019-07-07T18:32:34ZEdward Z. YangPer-database shadowingIn `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were ...In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique.
However, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them:
1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC.
1. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs.
1. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this.
So I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases:
```
pkg.conf.1
foo-0.1-XXX
bar-0.2-YYY (depends on foo-0.1-XXX)
pkg.conf.2
foo-0.1-XXX
baz-0.3-ZZZ (depends on foo-0.1-XXX)
```
If we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.)
It also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider:
```
pkg.conf.1
foo-0.1-XXX (abi is AAA)
pkg.conf.2
foo-0.1-XXX (abi is BBB)
pkg.conf.3
bar-0.1-YYY (depends on foo-0.1-XXX)
```
Which is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Per-database shadowing","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique.\r\n\r\nHowever, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them:\r\n\r\n1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC.\r\n\r\n2. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs.\r\n\r\n3. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this.\r\n\r\nSo I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases:\r\n\r\n{{{\r\npkg.conf.1\r\n foo-0.1-XXX\r\n bar-0.2-YYY (depends on foo-0.1-XXX)\r\npkg.conf.2\r\n foo-0.1-XXX\r\n baz-0.3-ZZZ (depends on foo-0.1-XXX)\r\n}}}\r\n\r\nIf we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.)\r\n\r\nIt also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider:\r\n\r\n{{{\r\npkg.conf.1\r\n foo-0.1-XXX (abi is AAA)\r\npkg.conf.2\r\n foo-0.1-XXX (abi is BBB)\r\npkg.conf.3\r\n bar-0.1-YYY (depends on foo-0.1-XXX)\r\n}}}\r\n\r\nWhich is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/11455GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"2019-07-07T18:30:21ZLemmingGHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160...When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Downloading
http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Resolving dependencies...
Configuring enummapset-0.5.2.1...
Building enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )
...
[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )
[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )
In-place registering enummapset-0.5.2.1...
Running Haddock for enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
...
Registering enummapset-0.5.2.1...
Installed enummapset-0.5.2.1
Configuring set-cover-0.0.8...
Building set-cover-0.0.8...
Preprocessing library set-cover-0.0.8...
[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )
[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )
src/Math/SetCover/Queue.hs:3:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap
src/Math/SetCover/Queue.hs:4:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet
Failed to install set-cover-0.0.8
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"GHC-8.0.0.20160109 runs into \"Bad interface file: ... Something is amiss\"","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:\r\n{{{\r\n$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nDownloading\r\nhttp://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nResolving dependencies...\r\nConfiguring enummapset-0.5.2.1...\r\nBuilding enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )\r\n...\r\n[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )\r\n[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )\r\nIn-place registering enummapset-0.5.2.1...\r\nRunning Haddock for enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n...\r\nRegistering enummapset-0.5.2.1...\r\nInstalled enummapset-0.5.2.1\r\nConfiguring set-cover-0.0.8...\r\nBuilding set-cover-0.0.8...\r\nPreprocessing library set-cover-0.0.8...\r\n[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )\r\n[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )\r\n\r\nsrc/Math/SetCover/Queue.hs:3:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap\r\n\r\nsrc/Math/SetCover/Queue.hs:4:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet\r\nFailed to install set-cover-0.0.8\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11504Can't install haskell-platform in OpenBSD2019-07-07T18:30:09ZAchifaifaCan't install haskell-platform in OpenBSDI'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|librar...I'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|library Xdamage.3.1 not found
| not found anywhere
|library Xext.12.0 not found
| not found anywhere
|library Xfixes.5.1 not found
| not found anywhere
|library Xi.11.1 not found
| not found anywhere
|library Xrandr.6.1 not found
| not found anywhere
|library Xrender.5.0 not found
| not found anywhere
|library Xxf86vm.5.0 not found
| not found anywhere
|library drm.3.1 not found
| not found anywhere
|library xcb.2.4 not found
| not found anywhere
Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0
Can't install haskell-platform-2012.4.0.0p0: can't resolve hs-GLUT-2.1.2.1p11 `
I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source.
I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue.https://gitlab.haskell.org/ghc/ghc/-/issues/11558Using Cabal 1.22 against GHC 8.0 results in unhelpful errors2019-07-07T18:29:49ZBen GamariUsing Cabal 1.22 against GHC 8.0 results in unhelpful errorsGHC 8.0 will require Cabal \>1.22 due to a variety of interface changes (see #10714, [D1780](https://phabricator.haskell.org/D1780), https://mail.haskell.org/pipermail/ghc-devs/2016-January/010978.html). Unfortunately things currently bl...GHC 8.0 will require Cabal \>1.22 due to a variety of interface changes (see #10714, [D1780](https://phabricator.haskell.org/D1780), https://mail.haskell.org/pipermail/ghc-devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about bad interface files for dependencies. For instance,
```
Text/Parsec/Prim.hs:85:1: error:
Bad interface file: /root/.cabal/lib/x86_64-linux-ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi
Something is amiss; requested module mtl-2.2.1@mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class
```
# For users seeing this error
The solution here is to install `Cabal` 1.23 or later and a `cabal-install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. Finally, you need to clear your package database.
This can be done with,
```
$ git clone git://github.com/haskell/cabal
$ cd cabal
$ cabal update
$ cabal install Cabal/ cabal-install/
$ rm -R $HOME/.ghc/*-8.0.0*
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11587Place shared objects in LIBDIR2020-12-20T18:22:52ZBen GamariPlace shared objects in LIBDIRIf one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program...If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g.,
```
$ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open
...
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
```
The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness.
Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/lib$PKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/11696Windows Install Makes Unnecessary/Incorrect PATH Changes2019-07-07T18:29:03ZAlexAndrewsWindows Install Makes Unnecessary/Incorrect PATH ChangesI installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents a...I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents and Settings\\\<username\>\\Application Data\\cabal\\bin
System environment variable PATH:
> C:\\Program Files\\Haskell\\bin
If these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.3 |
| 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":"Windows Install Makes Unnecessary/Incorrect PATH Changes","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["environment","install","path","variable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:\r\n\r\nUser environment variable PATH:\r\n\r\n C:\\Documents and Settings\\<username>\\Application Data\\cabal\\bin\r\n\r\nSystem environment variable PATH:\r\n\r\n C:\\Program Files\\Haskell\\bin\r\n\r\nIf these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12154GHC 8.0.1 x64 Windows installer doesn't honor custom install location2019-07-07T18:27:26ZscsGHC 8.0.1 x64 Windows installer doesn't honor custom install locationThe GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Hask...The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.
Potential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).
Workaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"GHC 8.0.1 x64 Windows installer doesn't honor custom install location","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.\r\n\r\nPotential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).\r\n\r\nWorkaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12196ghc-pkg should drop trailing path separator when computing package database root2019-07-07T18:27:12ZBen Gamarighc-pkg should drop trailing path separator when computing package database rootReported on `ghc-devs@`,
Nicolas Dudebout \<nicolas.dudebout\@gmail.com\> writes,
> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path cont...Reported on `ghc-devs@`,
Nicolas Dudebout \<nicolas.dudebout\@gmail.com\> writes,
> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path contains a trailing slash.
>
> Default behavior:
>
> ```
> $ ghc-pkg describe base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
> ```
>
> Correct behavior (no trailing slash):
>
> ```
> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base
> | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
>
> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
> ```
>
> Incorrect behavior (with trailing slash):
>
> ```
> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
>
> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
> ```
>
> When this bug happens, `ghc-pkg` check complains about missing files for
> packages using `${pkgroot}`.
>
> This bug happens because `${pkgroot}` is computed using `takeDirectory`. It
> should instead use `(takeDirectory . dropTrailingPathSeparator)`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nicolas.dudebout@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg should drop trailing path separator when computing package database root","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nicolas.dudebout@gmail.com"],"type":"Bug","description":"Reported on `ghc-devs@`,\r\n\r\n\r\nNicolas Dudebout <nicolas.dudebout@gmail.com> writes,\r\n\r\n> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path contains a trailing slash.\r\n> \r\n> Default behavior:\r\n> {{{\r\n> $ ghc-pkg describe base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> }}}\r\n> \r\n> Correct behavior (no trailing slash):\r\n> {{{\r\n> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base\r\n> | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> \r\n> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> }}}\r\n> \r\n> Incorrect behavior (with trailing slash):\r\n> {{{\r\n> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n> \r\n> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n> }}}\r\n> \r\n> When this bug happens, `ghc-pkg` check complains about missing files for\r\n> packages using `${pkgroot}`.\r\n> \r\n> This bug happens because `${pkgroot}` is computed using `takeDirectory`. It\r\n> should instead use `(takeDirectory . dropTrailingPathSeparator)`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12485-package-db flags now need to be sorted by dependency order2019-07-07T18:26:24Zniteria-package-db flags now need to be sorted by dependency orderAfter 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive ...After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive dependencies:
a-1-XXX
(use -v for more information)
```
See attached file for a repro.
It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-package-db flags now need to be sorted by dependency order","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:\r\n{{{\r\n<command line>: cannot satisfy -package-id b-1-XXX:\r\n b-1-XXX is unusable due to missing or recursive dependencies:\r\n a-1-XXX\r\n (use -v for more information)\r\n}}}\r\n\r\nSee attached file for a repro.\r\n\r\nIt's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.3https://gitlab.haskell.org/ghc/ghc/-/issues/12673bkpcabal01 testcase fails with spurious output on stderr on Darwin2019-07-07T18:25:37ZBen Gamaribkpcabal01 testcase fails with spurious output on stderr on DarwinThe `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,
```
=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1
Ac...The `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,
```
=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1
Actual stderr output differs from expected:
--- /dev/null 2016-10-08 22:51:23.000000000 +0300
+++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300
@@ -0,0 +1,4 @@
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
*** unexpected failure for bkpcabal01(normal)
```
It seems that the problem is that `ar` produces a warning when producing an archive file containing an object file with no symbols,
```
bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01
...
("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"])
ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a
a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o
a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o
/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
```
In general it would be best if we could avoid linking these empty object files to avoid these spurious warnings.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bkpcabal01 testcase fails with spurious output on stderr on Darwin","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"The `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,\r\n\r\n{{{\r\n=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]\r\ncd \"./backpack/cabal/bkpcabal01/bkpcabal01.run\" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1 \r\nActual stderr output differs from expected:\r\n--- /dev/null\t2016-10-08 22:51:23.000000000 +0300\r\n+++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised\t2016-10-08 22:51:23.000000000 +0300\r\n@@ -0,0 +1,4 @@\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n*** unexpected failure for bkpcabal01(normal)\r\n}}}\r\n\r\nIt seems that the problem is that `ar` produces a warning when producing an archive file containing an object file with no symbols,\r\n{{{\r\nbkpcabal01 bgamari$ make SETUP=\"./Setup -v3\" bkpcabal01\r\n...\r\n(\"/usr/bin/ar\",[\"-r\",\"-s\",\"-v\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o\"])\r\nar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a\r\na - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o\r\na - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o\r\n/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n}}}\r\n\r\nIn general it would be best if we could avoid linking these empty object files to avoid these spurious warnings.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13354Package database locking patch broke ghc-pkg with non-existent database2019-07-07T18:22:18ZBen GamariPackage database locking patch broke ghc-pkg with non-existent databaseIt seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration fi...It seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf
("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","--user","-v2"])
/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error
message:
ghc-pkg: Couldn't open database
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:
does not exist (No such file or directory)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"Package database locking patch broke ghc-pkg with non-existent database","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,\r\n{{{\r\nCreating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf\r\n(\"/opt/exp/ghc/roots/master/bin/ghc-pkg\",[\"update\",\"-\",\"--global\",\"--user\",\"-v2\"])\r\n/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error\r\nmessage:\r\nghc-pkg: Couldn't open database\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:\r\ndoes not exist (No such file or directory)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14017"make install" with non-standard umask causes bad permission on package.cache2022-02-11T00:19:09Zdjf"make install" with non-standard umask causes bad permission on package.cacheUsing Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in t...Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)
```
$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
```
It results in this message when trying to use ghc or ghci:
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)
```
(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc3 |
| 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":"\"make install\" with non-standard umask causes bad permission on package.cache","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.\r\n\r\nIf your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)\r\n\r\n{{{\r\n$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n}}}\r\n\r\nIt results in this message when trying to use ghc or ghci:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)\r\n}}}\r\n\r\n(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16318Explicitly passing -package-env causes "Loaded package environment from .ghc....2020-08-10T14:07:24ZRyan ScottExplicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3...```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Hello
```
This is a regression from GHC 8.4.4:
```
$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.4.4
Hello
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explicitly passing -package-env causes \"Loaded package environment from .ghc.environment\" message to be printed twice","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"{{{\r\n$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nHello\r\n}}}\r\n\r\nThis is a regression from GHC 8.4.4:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.4.4\r\nHello\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/16751Cabal-3.0.0.0 breaks cabal012019-06-07T14:33:21ZBen GamariCabal-3.0.0.0 breaks cabal01When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16879Hide "Loading package environment" message2019-08-25T01:30:04ZGuillaume BouchardHide "Loading package environment" message# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskel...# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskell, were the output is spammed by this message for each compiler step. See https://github.com/tweag/rules_haskell/issues/969
Example:
```
[nix-shell:~]$ touch .ghc.environment.x86_64-linux-8.6.3
[nix-shell:~]$ ghc
Loaded package environment from /home/guillaume/.ghc.environment.x86_64-linux-8.6.3
ghc: no input files
Usage: For basic information, try the `--help' option.
```
The `Loaded package environment from ...` is annoying.
# Proposal
Apparenly that's a log message with `SevInfo`. I did not found anyway to filter theses log messages. I tried `-v0`, or `-ddump-to-file` without success. `-ddump-json` changes the format of the output, but this stays in stderr.
I'll be happy to know another option to disable that or to have an option to disable log message based on severity.8.10.1Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/17191Split configure script2024-02-09T21:09:44ZJohn EricsonSplit configure script## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersio...## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersionMunged@`, `@LlvmVersion@`, etc. are still needed project-wide.
What I propose then is we strip down the root `configure.ac` to just substitute those platform-agnostic variables with no dynamic checks, and push the vast majority of the configure checks into package-specific configure scripts rts, inter-gmp, and base. The `settings` file does depend on a number of configure checks, but it can be either an extra file installed by the `rts`, which makes sense is it basically is saying how to produce Haskell which works with a given RTS, or get it's own configure script. As usual, the `m4` directory means we an share as much logic as we like between these scripts.
This has a number of benefits:
0. Running top-level configure should only make changes that are "safe for sdist". E.g. we can put all the versions in the cabal files and then sdist each cabal package. C.f. !5965.
1. Prevents regressions with multi-target: Compiler doesn't know about the target platform by construction, so it cannot be biased towards one or another.
2. Slightly more parallelism: we can immediately start building the compiler.
3. Better incremental builds: Changing configure results will no longer invalidate the stage 0 compiler build via `ghcautoconf.h`. More broadly each package only sees the options it cares about, so smaller incremental benefits for the other libs.
5. One step closer to `cabal build ghc` for a stage 0 compiler. Running the meta-configure is trivial preprocessor step that also could be done in `./boot` instead of autoconf as follow up work. Then the only thing blocking the cabal-built compilers is code gen executables `genprimmops`. But we have `build-tool-depends` already to hack something up, and longer term I hope https://github.com/ghc-proposals/ghc-proposals/pull/243 means it can all become TH.
I'll try to avoid controversy by *not* including getting rid of autoconf in the above list :). My view is this split delivers most of the benefit of that, and right now `configure.ac` is too big and monolithic to assess how much we depend on autoconf and where. With this change any renewed talk on purging autoconf will be a better evidence-based discussion.
## Things that get configured today
Good to keep in mind.
- `ghcautoconf.h`, from `AC_DEFINE`, via `mk/config.h`
- `settings` files per stage, originally directly via type level configure, now indirectly via make/hadrian
- Build system config files, from `AC_SUBST`:
- `hadrian/cfg/system.config`
- `mk/config.mk`
## Roadmap
### Prep Make build system
It turns out there was a few things to do with the make build system to make it better cope with the RTS having a configure script, and generally anticipate the goals here.
- [x] !6816
- [x] !6821
- [x] !6817
- [x] !6819
- [x] !6869
- [x] !6864
- [x] !6908
- [x] !6833 Make: Do not generate ghc.* headers in stage
- [x] !6966
- [x] !6977
- [x] !6978
- [x] !6989
### Prep Hadrian changes
- [x] !6953 Hadrian: bring up to date with latest make improvements
- [x] !6978
### Prep Autoconf changes
- [x] !6828 modularize platform detection.
- [x] !6836 Separate some `AC_SUBST` / `AC_DEFINE`
- [x] !6927 Factor out unregisterised and tables next to code m4 macros
- [x] !6931 Factor out more m4 macros
- [x] !6964
### Other prep
- [x] !6216 Move `/includes` to `/rts/include`, sort per package better
- [x] !6839 Avoid GHC_STAGE and other include bits
- [x] !6791 / !6920 Compiler is target agnostic!
- [x] !6963 Generate ghcversion.h with the top-level configure
- [x] !6987
- [x] !7100
- [x] !9627 Remove hack for building RTS that gets in the way of `build-type: Simple`.
### Intro RTS Configure script
A beachhead!
- [x] !6822 (optional intermediate step) do blank RTS configure script before moving anything over.
- [x] !9760 Bump Cabal so configure script can detect cabal flags.
- [x] !9756 Move extern symbols logic
### Headers generated RTS side.
Hadrian can still tell RTS what the configuration is (the RTS configure script wont't yet decide for itself), but `ghcautoconf.h` and `ghcplatform.h` are made in the RTS configure script. `mk/config.h` can be deleted.
### Rest of RTS-oriented configure logic.
The RTS is able to figure out its configuration without relying on correctly-set manual Cabal flags.
Perhaps the RTS will contain some settings info that Hadrian reads (c.f. #22686) i.e. it could be a source of truth.
1. [x] !11311
2. [x] !11319
3. [x] !11317
4. [x] !11318
4. [x] !11322
5. [x] !6803
### Slim down Cabal Flags for RTS
With the logic from before moved into the RTS configure script, there is often no need to make decision from the outside --- just let the RTS configure script make its own private choice.
We can do that and get rid of a bunch of Hadrian logic.
- [x] !9269 / `wip/rts-configure-scrap-cabal-flags`
### Get rid of rest of configure script
See
- #24008
- #23966
### `genapply` shouldn't take RTS headers at compile time
If the RTS is built standalone, there it will be annoying to *build* genapply at *RTS configure* time. We should do something different -- like make genapply take the info at runtime so we can use a prebuilt genapply.
### Create configure script for settings file.
Many decisions however need to effect both RTS and settings file. At a minimum, we can share `m4` logic between projects, but we may also want to make (part of) the settings file during the RTS build.
Some settings effectively indicate choices where the RTS and GHC must agree, so deciding twice and hoping the system-snooping is deterministic is sketch. Other settings like what tools to use are naturally independent.
Note it is precisely second sort that the bindist will configure today.
### Possible prepare stage-wide configure more like status-quo-ante for hadrian/make
While it's important than components can be configured separately to untangle our current mess, hadrian/make might continue to want to make some settings across projects. Concretely, *something* need to fill in their settings input files, `hadrian/cfg/system.config`, and `mk/config.mk`.
We can have our cake and eat it too by keeping enough logic in `m4` files to create a "stage-wide" configure script.
(Remember, per https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap bootstrapping is an infinite tree to explore, not a single chain, let alone a finite 3 stage chain! So stage-wide config files vs one master config files makes much more sense as input to Hadrian/Make.)
Additionally, we should enhance the autoconf macros to ensure every decision solved by the "outer" configure is not re-decided by the per-package configures. That means adding enough configure flags so the decisions can be "told" by make/hadrian to RTS/base/unix/whatever.
This last step might sound like it is undermining the whole project: what's the point of moving all the logic to per-package configure scripts if we are just going to centrally configure the decisions anyways?! Remember, only make/hadrian parameters that are either inspected/eliminated by the outer build system or "aliased" to multiple packages need be in the outer configure. The vast majority of stuff is just needed by on package (usually the RTS), or was `AC_DEFINED` and already bypasses the output build system going straight from autoconf to the headers. All such things need never be configured from the stage-wide configure script, and should purely be per-stage.
Also, downstream packaging like Haskell.nix or Nixpkgs will probably stop using Make/Hadrian, and thus bypass any stage-wide configuring, but will use the per-package configures. In general "whole compilers" should be thought of as mini-distros and not single packages, and thus our Make/Hadrian are more like package managers / multiple monorepo build systems (like the original BSD monorepo).
CC @angerman @alp @bgamari @hvr @nomeata @snowleopard @hsyl20 @nrnrnrhttps://gitlab.haskell.org/ghc/ghc/-/issues/17467Hadrian does not track package.conf.d/package.cache2022-08-06T18:35:03ZAlp MestanogullariHadrian does not track package.conf.d/package.cacheWhile @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing re...While @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing results in:
```
ghc: there is no package.cache in _build/stage0/lib/package.conf.d even though package database is not empty
```
It's probably safe to assume that Hadrian does not track the package db cache in any way (not even using `traceWrite` or anything like that). It'd be nice to teach Hadrian enough about those caches for it to be able to regenerate them when needed.9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/17468Hadrian uses wrong stage's ghc-pkg, writing incompatible package.cache2020-08-17T15:17:35ZNiklas Hambüchenmail@nh2.meHadrian uses wrong stage's ghc-pkg, writing incompatible package.cacheI tried to add a field to `InstalledPackageInfo`.
This gave me the error:
```
_build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)
```
Full output: https://g...I tried to add a field to `InstalledPackageInfo`.
This gave me the error:
```
_build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)
```
Full output: https://gist.github.com/nh2/94dc2f98b38798ed4a4e65844dd3ac9a
Doing `_build/stage0/lib/package.conf.d/{package.cache,rts.conf}` (also deleting a `.conf` file to work around #17467) and re-running `./hadrian/build.stack.sh -j --flavour=quickest --verbose` reveals the problem ([full output](https://gist.github.com/nh2/94dc2f98b38798ed4a4e65844dd3ac9a#file-problem-revealed-txt)):
```
ghc-pkg: cannot find package rts
| Run GhcPkg Copy Stage0: rts => _build/stage0/lib/package.conf.d/rts.conf
/raid/stack/programs/x86_64-linux/ghc-8.6.5/bin/ghc-pkg --expand-pkgroot --no-user-package-db describe rts
/raid/stack/programs/x86_64-linux/ghc-8.6.5/bin/ghc-pkg --global-package-db _build/stage0/lib/package.conf.d register -v0 -
```
As identified by @bgamari, it's using the global (stage0) `ghc-pkg register` to write the `package.conf`, which then of course cannot be deserialised by my modified `ghc-pkg` that expectes one field more.
> **nh2**: so you're saying it should use `_build/stage0/bin/ghc-pkg` instead?
>
> **bgamari**: rightMake removalAlp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18070GHC 8.10's API can load interfaces with the wrong package identifier when loo...2020-08-13T22:22:56ZquasicomputationalGHC 8.10's API can load interfaces with the wrong package identifier when looking for pluginsOriginally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). R...Originally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). Run with `./run-test.sh`.
On my machine, I get an error that looks like this:
```
test-doctest: Bad interface file: [..]/dist-newstyle/build/x86_64-linux/ghc-8.10.1/dummy-plugin-0.1.0.0/build/DummyDefs.hi
Something is amiss; requested module dummy-plugin-0.1.0.0:DummyDefs differs from name found in the interface file ghc-compact-0.1.0.0:DummyDefs (if these names look the same, try again with -dppr-debug)
```
Where does that `ghc-compact` come from? I have no idea. Even more puzzlingly, if I turn up GHC's verbosity, that turns into `process`!
[`test-doctest.hs`](https://github.com/quasicomputational/test-doctest/blob/master/test-doctest.hs) is the (now misleadingly-named) code driving GHC, and as far as I can tell it's not doing anything exotic or bizarre.
[`Haddock.Interface`](https://github.com/haskell/haddock/blob/8c6532636e6bd572455dfcf0b0d6e05f7033d110/haddock-api/src/Haddock/Interface.hs) is the roughly corresponding code in Haddock, which seems to mostly do the same thing - and yet Haddock works and doctest doesn't. I have no idea what the difference is, except that it might be something to do with order-sensitivity in how modules are loaded.
The error doesn't happen on GHC 8.8. I couldn't find anything in the release notes warning me about any changes here, so this is a regression.https://gitlab.haskell.org/ghc/ghc/-/issues/19286ghc and ghci don't read the default package environment file on Windows2021-12-09T20:47:10Zdanidiazghc and ghci don't read the default package environment file on Windows## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arc...## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arch-os-version/environments/default` package environment file if it exists and no specific options have been given to the contrary.
This works correctly on Linux, but the file is not being found on Windows.
On my machine, the default package environment is located at `C:\Users\myuser\.ghc\x86_64-mingw32-8.10.3\environments\default`.
## Steps to reproduce
Create a package environment file in the default location. The simplest way is to install a library with [`cabal install --lib`](https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-install):
`cabal install --lib sop-core`
Then, in an empty folder, start `ghci`, then try to `import Data.SOP.NP`.
Also create a `Main.hs` which imports `Data.SOP.NP` and try to compile with `ghc`.
## Expected behavior
Neither `ghci` nor `ghc` should complain about not finding the module.
`ghci` should show a `Loaded package environment from...` message when starting up.
## Environment
* GHC version used: 8.10.3
* Operating System: Windows 10https://gitlab.haskell.org/ghc/ghc/-/issues/19330Improve `ModOrigin: hidden module redefined` crash report2021-02-23T19:54:21ZSergei TrofimovichImprove `ModOrigin: hidden module redefined` crash report## Summary
Sometimes packages clash in module namespace in unobvious ways. GHC has a hard time loading those and it's very hard to figure out what module actually breaks things.
## Steps to reproduce
I don't know precise set of instal...## Summary
Sometimes packages clash in module namespace in unobvious ways. GHC has a hard time loading those and it's very hard to figure out what module actually breaks things.
## Steps to reproduce
I don't know precise set of installed packages needed to trigger the failure, but it looks like that:
```
./setup haddock --hyperlink-source
Preprocessing library for haskell-lsp-types-0.22.0.0..
Running Haddock on library for haskell-lsp-types-0.22.0.0..
Warning: --source-* options are ignored when --hyperlinked-source is enabled.
Haddock coverage:
33% ( 1 / 3) in 'Language.Haskell.LSP.Types.Constants'
Missing documentation for:
Module header
customModifier (src/Language/Haskell/LSP/Types/Constants.hs:13)
src/Language/Haskell/LSP/Types/MarkupContent.hs:15:1: warning: [-Wunused-imports]
The import of ‘Data.Monoid’ is redundant
except perhaps to import instances from ‘Data.Monoid’
To import instances alone, use: import Data.Monoid()
|
15 | import Data.Monoid ((<>))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'Hover' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'ParameterInfo' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'CompletionItem' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'plaintext' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'markdown' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'typescript' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
src/Language/Haskell/LSP/Types/Uri.hs:27:1: warning: [-Wunused-imports]
The import of ‘isPrefixOf’ from module ‘Data.List’ is redundant
|
27 | import Data.List (isPrefixOf, stripPrefix)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'comment' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'region' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: '_range' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Location.hs:95:7
* at src/Language/Haskell/LSP/Types/Symbol.hs:220:7
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Symbol.hs:220:7
0% ( 0 / 2) in 'Language.Haskell.LSP.Types.Utils'
Missing documentation for:
Module header
rdrop (src/Language/Haskell/LSP/Types/Utils.hs:5)
Warning: '_title' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Window.hs:145:7
* at src/Language/Haskell/LSP/Types/Window.hs:264:4
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Window.hs:264:4
Warning: '_percentage' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Window.hs:367:5
* at src/Language/Haskell/LSP/Types/Window.hs:282:5
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Window.hs:282:5
src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:9:1: warning: [-Wunused-imports]
The import of ‘Data.Monoid’ is redundant
except perhaps to import instances from ‘Data.Monoid’
To import instances alone, use: import Data.Monoid()
|
9 | import Data.Monoid ((<>))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'falsy' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'insertText' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'newText' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'textEdit' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'triggerCharacters' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'falsy' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: '_command' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Command.hs:41:7
* at src/Language/Haskell/LSP/Types/CodeAction.hs:275:7
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/CodeAction.hs:275:7
Warning: 'WorkspaceEdit' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'File' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'Array' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'SignatureInformation' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'true' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'startCharacter' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'endCharacter' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
0% ( 0 /200) in 'Language.Haskell.LSP.Types.Lens'
Missing documentation for:
Module header
HasDocumentChanges (src/Language/Haskell/LSP/Types/Lens.hs:28)
HasDynamicRegistration (src/Language/Haskell/LSP/Types/Lens.hs:29)
HasValueSet (src/Language/Haskell/LSP/Types/Lens.hs:31)
HasSymbolKind (src/Language/Haskell/LSP/Types/Lens.hs:32)
HasApplyEdit (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasConfiguration (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidChangeConfiguration (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidChangeWatchedFiles (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasExecuteCommand (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasSymbol (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasWorkspaceEdit (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasWorkspaceFolders (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidSave (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasWillSave (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasWillSaveWaitUntil (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasCommitCharactersSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasDeprecatedSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasDocumentationFormat (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasPreselectSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasSnippetSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasTagSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasCompletionItem (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasCompletionItemKind (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasContextSupport (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasContentFormat (src/Language/Haskell/LSP/Types/Lens.hs:40)
HasSignatureInformation (src/Language/Haskell/LSP/Types/Lens.hs:42)
HasHierarchicalDocumentSymbolSupport (src/Language/Haskell/LSP/Types/Lens.hs:46)
HasCodeActionKind (src/Language/Haskell/LSP/Types/Lens.hs:54)
HasCodeActionLiteralSupport (src/Language/Haskell/LSP/Types/Lens.hs:55)
HasPrepareSupport (src/Language/Haskell/LSP/Types/Lens.hs:59)
HasRelatedInformation (src/Language/Haskell/LSP/Types/Lens.hs:60)
HasCodeAction (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasCodeLens (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasColorProvider (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasCompletion (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDefinition (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentHighlight (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentLink (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentSymbol (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasFoldingRange (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasHover (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasImplementation (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasOnTypeFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasPublishDiagnostics (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasRangeFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasReferences (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasRename (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasSignatureHelp (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasSynchronization (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasTypeDefinition (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasExperimental (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasTextDocument (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasWindow (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasWorkspace (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasCapabilities (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasInitializationOptions (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasProcessId (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRootPath (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRootUri (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasTrace (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRetry (src/Language/Haskell/LSP/Types/Lens.hs:68)
HasAllCommitCharacters (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasResolveProvider (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasTriggerCharacters (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasRetriggerCharacters (src/Language/Haskell/LSP/Types/Lens.hs:70)
HasFirstTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:72)
HasMoreTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:72)
HasCommands (src/Language/Haskell/LSP/Types/Lens.hs:74)
HasIncludeText (src/Language/Haskell/LSP/Types/Lens.hs:75)
HasChange (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasOpenClose (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasSave (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasChangeNotifications (src/Language/Haskell/LSP/Types/Lens.hs:77)
HasSupported (src/Language/Haskell/LSP/Types/Lens.hs:77)
HasCodeActionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasCodeLensProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasCompletionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDefinitionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentHighlightProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentLinkProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentOnTypeFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentRangeFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentSymbolProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasExecuteCommandProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasFoldingRangeProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasHoverProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasImplementationProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasReferencesProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasRenameProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasSignatureHelpProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasTextDocumentSync (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasTypeDefinitionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasWorkspaceSymbolProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasId (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasMethod (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasRegisterOptions (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasRegistrations (src/Language/Haskell/LSP/Types/Lens.hs:82)
HasWatchers (src/Language/Haskell/LSP/Types/Lens.hs:83)
HasGlobPattern (src/Language/Haskell/LSP/Types/Lens.hs:84)
HasKind (src/Language/Haskell/LSP/Types/Lens.hs:84)
HasWatchChange (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasWatchCreate (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasWatchDelete (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasDocumentSelector (src/Language/Haskell/LSP/Types/Lens.hs:86)
HasUnregistrations (src/Language/Haskell/LSP/Types/Lens.hs:88)
HasSettings (src/Language/Haskell/LSP/Types/Lens.hs:89)
HasScopeUri (src/Language/Haskell/LSP/Types/Lens.hs:90)
HasSection (src/Language/Haskell/LSP/Types/Lens.hs:90)
HasItems (src/Language/Haskell/LSP/Types/Lens.hs:91)
HasRange (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasRangeLength (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasText (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasContentChanges (src/Language/Haskell/LSP/Types/Lens.hs:94)
HasSyncKind (src/Language/Haskell/LSP/Types/Lens.hs:95)
HasReason (src/Language/Haskell/LSP/Types/Lens.hs:96)
HasUri (src/Language/Haskell/LSP/Types/Lens.hs:99)
HasXtype (src/Language/Haskell/LSP/Types/Lens.hs:99)
HasChanges (src/Language/Haskell/LSP/Types/Lens.hs:100)
HasDiagnostics (src/Language/Haskell/LSP/Types/Lens.hs:101)
HasLanguage (src/Language/Haskell/LSP/Types/Lens.hs:102)
HasValue (src/Language/Haskell/LSP/Types/Lens.hs:102)
HasContents (src/Language/Haskell/LSP/Types/Lens.hs:103)
HasDocumentation (src/Language/Haskell/LSP/Types/Lens.hs:104)
HasLabel (src/Language/Haskell/LSP/Types/Lens.hs:104)
HasParameters (src/Language/Haskell/LSP/Types/Lens.hs:105)
HasActiveParameter (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasActiveSignature (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasSignatures (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasIncludeDeclaration (src/Language/Haskell/LSP/Types/Lens.hs:108)
HasContext (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasPosition (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasWorkDoneToken (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasQuery (src/Language/Haskell/LSP/Types/Lens.hs:111)
HasCommand (src/Language/Haskell/LSP/Types/Lens.hs:113)
HasXdata (src/Language/Haskell/LSP/Types/Lens.hs:113)
HasTarget (src/Language/Haskell/LSP/Types/Lens.hs:116)
HasInsertSpaces (src/Language/Haskell/LSP/Types/Lens.hs:117)
HasTabSize (src/Language/Haskell/LSP/Types/Lens.hs:117)
HasOptions (src/Language/Haskell/LSP/Types/Lens.hs:118)
HasCh (src/Language/Haskell/LSP/Types/Lens.hs:120)
HasNewName (src/Language/Haskell/LSP/Types/Lens.hs:121)
HasArguments (src/Language/Haskell/LSP/Types/Lens.hs:122)
HasEdit (src/Language/Haskell/LSP/Types/Lens.hs:124)
HasApplied (src/Language/Haskell/LSP/Types/Lens.hs:125)
HasParams (src/Language/Haskell/LSP/Types/Lens.hs:127)
HasCharacter (src/Language/Haskell/LSP/Types/Lens.hs:132)
HasLine (src/Language/Haskell/LSP/Types/Lens.hs:132)
HasEnd (src/Language/Haskell/LSP/Types/Lens.hs:133)
HasStart (src/Language/Haskell/LSP/Types/Lens.hs:133)
HasAdditionalTextEdits (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasCommitCharacters (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasDeprecated (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasDetail (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasFilterText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasInsertText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasInsertTextFormat (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasPreselect (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasSortText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTags (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTextEdit (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:138)
HasTriggerKind (src/Language/Haskell/LSP/Types/Lens.hs:138)
HasIsIncomplete (src/Language/Haskell/LSP/Types/Lens.hs:139)
HasTitle (src/Language/Haskell/LSP/Types/Lens.hs:146)
HasPattern (src/Language/Haskell/LSP/Types/Lens.hs:149)
HasScheme (src/Language/Haskell/LSP/Types/Lens.hs:149)
HasNewText (src/Language/Haskell/LSP/Types/Lens.hs:152)
HasVersion (src/Language/Haskell/LSP/Types/Lens.hs:153)
HasEdits (src/Language/Haskell/LSP/Types/Lens.hs:154)
HasName (src/Language/Haskell/LSP/Types/Lens.hs:158)
HasAdded (src/Language/Haskell/LSP/Types/Lens.hs:159)
HasRemoved (src/Language/Haskell/LSP/Types/Lens.hs:159)
HasEvent (src/Language/Haskell/LSP/Types/Lens.hs:160)
HasJsonrpc (src/Language/Haskell/LSP/Types/Lens.hs:163)
HasCode (src/Language/Haskell/LSP/Types/Lens.hs:164)
HasMessage (src/Language/Haskell/LSP/Types/Lens.hs:164)
HasResult (src/Language/Haskell/LSP/Types/Lens.hs:165)
HasLanguageId (src/Language/Haskell/LSP/Types/Lens.hs:170)
HasSeverity (src/Language/Haskell/LSP/Types/Lens.hs:178)
HasSource (src/Language/Haskell/LSP/Types/Lens.hs:178)
HasLocation (src/Language/Haskell/LSP/Types/Lens.hs:179)
HasChildren (src/Language/Haskell/LSP/Types/Lens.hs:183)
HasSelectionRange (src/Language/Haskell/LSP/Types/Lens.hs:183)
HasContainerName (src/Language/Haskell/LSP/Types/Lens.hs:184)
HasAlpha (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasBlue (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasGreen (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasRed (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasColor (src/Language/Haskell/LSP/Types/Lens.hs:188)
HasEndCharacter (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasEndLine (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasStartCharacter (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasStartLine (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasActions (src/Language/Haskell/LSP/Types/Lens.hs:200)
HasToken (src/Language/Haskell/LSP/Types/Lens.hs:202)
HasCancellable (src/Language/Haskell/LSP/Types/Lens.hs:203)
HasPercentage (src/Language/Haskell/LSP/Types/Lens.hs:203)
12% ( 35 /277) in 'Language.Haskell.LSP.Types'
Missing documentation for:
Module header
Trace (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:97)
InitializeParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:113)
InitializeError (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:151)
TextDocumentSyncKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:184)
CompletionOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:230)
SignatureHelpOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:265)
CodeLensOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:294)
CodeActionOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:317)
DocumentOnTypeFormattingOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:341)
DocumentLinkOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:365)
RenameOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:389)
ExecuteCommandOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:415)
SaveOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:437)
TextDocumentSyncOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:475)
GotoOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:644)
ColorOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:659)
FoldingRangeOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:674)
WorkspaceFolderChangeNotifications (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:689)
WorkspaceFolderOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:695)
WorkspaceOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:711)
InitializeResponseCapabilitiesInner (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:722)
InitializeResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:799)
InitializeRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:801)
InitializedParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:849)
InitializedNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:861)
ShutdownRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:887)
ShutdownResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:888)
ExitNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:914)
TelemetryNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:932)
CustomClientNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:934)
CustomServerNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:935)
CustomClientRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:937)
CustomServerRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:938)
CustomResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:940)
Registration (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:987)
RegistrationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1002)
RegisterCapabilityResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1012)
TextDocumentRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1029)
Unregistration (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1074)
UnregistrationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1086)
UnregisterCapabilityRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1093)
UnregisterCapabilityResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1095)
DidChangeWatchedFilesRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1148)
FileSystemWatcher (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1153)
WatchKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1159)
DidChangeConfigurationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1209)
DidChangeConfigurationNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1218)
ConfigurationItem (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1269)
ConfigurationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1277)
ConfigurationRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1284)
ConfigurationResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1285)
DidOpenTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1313)
DidOpenTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1320)
TextDocumentContentChangeEvent (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1372)
DidChangeTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1383)
DidChangeTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1391)
TextDocumentChangeRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1410)
TextDocumentSaveReason (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1473)
WillSaveTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1492)
WillSaveTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1500)
WillSaveWaitUntilTextDocumentRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1529)
WillSaveWaitUntilTextDocumentResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1530)
DidSaveTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1551)
DidSaveTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1558)
DidCloseTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1588)
DidCloseTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1596)
FileChangeType (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1652)
FileEvent (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1671)
DidChangeWatchedFilesParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1679)
DidChangeWatchedFilesNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1687)
PublishDiagnosticsParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1716)
PublishDiagnosticsNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1725)
ParameterInformation (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1818)
SignatureInformation (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1828)
SignatureHelp (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1837)
SignatureHelpRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1846)
SignatureHelpResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1847)
SignatureHelpRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1864)
LocationResponseParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1900)
DefinitionRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1911)
DefinitionResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1912)
TypeDefinitionRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1933)
TypeDefinitionResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1934)
ImplementationRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1956)
ImplementationResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1957)
ReferenceContext (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1997)
ReferenceParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2005)
ReferencesRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2016)
ReferencesResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2017)
DocumentHighlightKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2091)
DocumentHighlight (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2107)
DocumentHighlightRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2115)
DocumentHighlightsResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2116)
WorkspaceSymbolParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2149)
WorkspaceSymbolRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2157)
WorkspaceSymbolsResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2158)
CodeLensParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2214)
CodeLens (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2225)
CodeLensRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2235)
CodeLensResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2236)
CodeLensRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2250)
CodeLensResolveRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2281)
CodeLensResolveResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2282)
DocumentLinkParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2337)
DocumentLink (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2345)
DocumentLinkRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2353)
DocumentLinkResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2354)
DocumentLinkResolveRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2377)
DocumentLinkResolveResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2378)
FormattingOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2436)
DocumentFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2445)
DocumentFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2454)
DocumentFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2455)
DocumentRangeFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2496)
DocumentRangeFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2506)
DocumentRangeFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2507)
DocumentOnTypeFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2565)
DocumentOnTypeFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2575)
DocumentOnTypeFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2576)
DocumentOnTypeFormattingRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2578)
RenameParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2628)
RenameRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2641)
RenameResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2642)
RangeWithPlaceholder (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2672)
RangeOrRangeWithPlaceholder (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2681)
PrepareRenameRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2686)
PrepareRenameResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2687)
ExecuteCommandParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2740)
ExecuteCommandRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2749)
ExecuteCommandResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2750)
ExecuteCommandRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2752)
ApplyWorkspaceEditParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2795)
ApplyWorkspaceEditResponseBody (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2802)
ApplyWorkspaceEditResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2811)
TraceParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2817)
TraceNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2825)
CodeActionKind (src/Language/Haskell/LSP/Types/CodeAction.hs:214)
CodeActionContext (src/Language/Haskell/LSP/Types/CodeAction.hs:245)
CodeActionParams (src/Language/Haskell/LSP/Types/CodeAction.hs:254)
CodeAction (src/Language/Haskell/LSP/Types/CodeAction.hs:264)
CAResult (src/Language/Haskell/LSP/Types/CodeAction.hs:282)
CodeActionRequest (src/Language/Haskell/LSP/Types/CodeAction.hs:293)
CodeActionResponse (src/Language/Haskell/LSP/Types/CodeAction.hs:294)
ColorInformation (src/Language/Haskell/LSP/Types/Color.hs:92)
DocumentColorParams (src/Language/Haskell/LSP/Types/Color.hs:100)
DocumentColorRequest (src/Language/Haskell/LSP/Types/Color.hs:108)
DocumentColorResponse (src/Language/Haskell/LSP/Types/Color.hs:110)
ColorPresentationParams (src/Language/Haskell/LSP/Types/Color.hs:169)
ColorPresentation (src/Language/Haskell/LSP/Types/Color.hs:183)
ColorPresentationRequest (src/Language/Haskell/LSP/Types/Color.hs:201)
ColorPresentationResponse (src/Language/Haskell/LSP/Types/Color.hs:203)
Command (src/Language/Haskell/LSP/Types/Command.hs:38)
CompletionItemKind (src/Language/Haskell/LSP/Types/Completion.hs:23)
CompletionItemTag (src/Language/Haskell/LSP/Types/Completion.hs:105)
InsertTextFormat (src/Language/Haskell/LSP/Types/Completion.hs:305)
CompletionDoc (src/Language/Haskell/LSP/Types/Completion.hs:327)
CompletionItem (src/Language/Haskell/LSP/Types/Completion.hs:338)
CompletionListType (src/Language/Haskell/LSP/Types/Completion.hs:396)
CompletionResponseResult (src/Language/Haskell/LSP/Types/Completion.hs:404)
CompletionContext (src/Language/Haskell/LSP/Types/Completion.hs:437)
CompletionParams (src/Language/Haskell/LSP/Types/Completion.hs:448)
CompletionResponse (src/Language/Haskell/LSP/Types/Completion.hs:461)
CompletionRequest (src/Language/Haskell/LSP/Types/Completion.hs:462)
CompletionRegistrationOptions (src/Language/Haskell/LSP/Types/Completion.hs:484)
CompletionItemResolveRequest (src/Language/Haskell/LSP/Types/Completion.hs:513)
CompletionItemResolveResponse (src/Language/Haskell/LSP/Types/Completion.hs:514)
DiagnosticSeverity (src/Language/Haskell/LSP/Types/Diagnostic.hs:40)
DiagnosticTag (src/Language/Haskell/LSP/Types/Diagnostic.hs:81)
DiagnosticRelatedInformation (src/Language/Haskell/LSP/Types/Diagnostic.hs:124)
NumberOrString (src/Language/Haskell/LSP/Types/Diagnostic.hs:186)
DiagnosticSource (src/Language/Haskell/LSP/Types/Diagnostic.hs:195)
Diagnostic (src/Language/Haskell/LSP/Types/Diagnostic.hs:196)
DocumentFilter (src/Language/Haskell/LSP/Types/DocumentFilter.hs:41)
DocumentSelector (src/Language/Haskell/LSP/Types/DocumentFilter.hs:55)
FoldingRangeParams (src/Language/Haskell/LSP/Types/FoldingRange.hs:14)
FoldingRangeRequest (src/Language/Haskell/LSP/Types/FoldingRange.hs:71)
FoldingRangeResponse (src/Language/Haskell/LSP/Types/FoldingRange.hs:72)
LanguageString (src/Language/Haskell/LSP/Types/Hover.hs:43)
MarkedString (src/Language/Haskell/LSP/Types/Hover.hs:52)
HoverContents (src/Language/Haskell/LSP/Types/Hover.hs:106)
toMarkupContent (src/Language/Haskell/LSP/Types/Hover.hs:136)
Hover (src/Language/Haskell/LSP/Types/Hover.hs:142)
HoverRequest (src/Language/Haskell/LSP/Types/Hover.hs:150)
HoverResponse (src/Language/Haskell/LSP/Types/Hover.hs:151)
Position (src/Language/Haskell/LSP/Types/Location.hs:41)
Range (src/Language/Haskell/LSP/Types/Location.hs:71)
Location (src/Language/Haskell/LSP/Types/Location.hs:92)
ClientMethod (src/Language/Haskell/LSP/Types/Message.hs:72)
ServerMethod (src/Language/Haskell/LSP/Types/Message.hs:214)
RequestMessage (src/Language/Haskell/LSP/Types/Message.hs:279)
ErrorCode (src/Language/Haskell/LSP/Types/Message.hs:327)
ResponseError (src/Language/Haskell/LSP/Types/Message.hs:392)
ResponseMessage (src/Language/Haskell/LSP/Types/Message.hs:425)
ErrorResponse (src/Language/Haskell/LSP/Types/Message.hs:456)
BareResponseMessage (src/Language/Haskell/LSP/Types/Message.hs:460)
NotificationMessage (src/Language/Haskell/LSP/Types/Message.hs:474)
CancelParams (src/Language/Haskell/LSP/Types/Message.hs:511)
CancelNotification (src/Language/Haskell/LSP/Types/Message.hs:518)
CancelNotificationServer (src/Language/Haskell/LSP/Types/Message.hs:519)
DocumentSymbolParams (src/Language/Haskell/LSP/Types/Symbol.hs:103)
SymbolKind (src/Language/Haskell/LSP/Types/Symbol.hs:113)
DSResult (src/Language/Haskell/LSP/Types/Symbol.hs:260)
DocumentSymbolRequest (src/Language/Haskell/LSP/Types/Symbol.hs:272)
DocumentSymbolsResponse (src/Language/Haskell/LSP/Types/Symbol.hs:273)
TextDocumentIdentifier (src/Language/Haskell/LSP/Types/TextDocument.hs:28)
TextDocumentItem (src/Language/Haskell/LSP/Types/TextDocument.hs:66)
TextDocumentPositionParams (src/Language/Haskell/LSP/Types/TextDocument.hs:98)
Uri (src/Language/Haskell/LSP/Types/Uri.hs:41)
uriToFilePath (src/Language/Haskell/LSP/Types/Uri.hs:92)
filePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:120)
NormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:48)
toNormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:75)
fromNormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:81)
toNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:181)
fromNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:188)
normalizedFilePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:191)
uriToNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:194)
platformAwareUriToFilePath (src/Language/Haskell/LSP/Types/Uri.hs:96)
platformAwareFilePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:124)
MessageType (src/Language/Haskell/LSP/Types/Window.hs:63)
ShowMessageParams (src/Language/Haskell/LSP/Types/Window.hs:85)
ShowMessageNotification (src/Language/Haskell/LSP/Types/Window.hs:93)
MessageActionItem (src/Language/Haskell/LSP/Types/Window.hs:143)
ShowMessageRequestParams (src/Language/Haskell/LSP/Types/Window.hs:151)
ShowMessageRequest (src/Language/Haskell/LSP/Types/Window.hs:160)
ShowMessageResponse (src/Language/Haskell/LSP/Types/Window.hs:161)
LogMessageParams (src/Language/Haskell/LSP/Types/Window.hs:192)
LogMessageNotification (src/Language/Haskell/LSP/Types/Window.hs:201)
WorkDoneProgressCreateParams (src/Language/Haskell/LSP/Types/Window.hs:475)
WorkDoneProgressCreateRequest (src/Language/Haskell/LSP/Types/Window.hs:482)
TextEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:42)
TextDocumentVersion (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:69)
VersionedTextDocumentIdentifier (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:71)
TextDocumentEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:106)
WorkspaceEditMap (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:144)
WorkspaceEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:146)
WorkspaceFolder (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:52)
WorkspaceFoldersRequest (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:62)
WorkspaceFoldersResponse (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:63)
DidChangeWorkspaceFoldersParams (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:120)
DidChangeWorkspaceFoldersNotification (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:128)
haddock: panic! (the 'impossible' happened)
(GHC version 8.10.3:
ModOrigin: hidden module redefined
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
I'd like error message to hint at module name, say
```
haddock: panic! (the 'impossible' happened)
(GHC version 8.10.3:
ModOrigin: hidden module <$MODNAME> redefined
```
## Environment
* GHC version used: 8.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/19370ghc: panic!: expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Pac...2021-06-04T11:08:27ZJens Petersenghc: panic!: expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Packages## Summary
ghc-8.10 is crashing when compiling/linking(?) a medium-sized executable for me.
With both ghc-8.10.3 and ghc-8.10.4 on Fedora 33 x86_64:
```
[41 of 42] Compiling Paths_fbrnch
[42 of 42] Compiling Main [Distribution.Fedora.B...## Summary
ghc-8.10 is crashing when compiling/linking(?) a medium-sized executable for me.
With both ghc-8.10.3 and ghc-8.10.4 on Fedora 33 x86_64:
```
[41 of 42] Compiling Paths_fbrnch
[42 of 42] Compiling Main [Distribution.Fedora.Branch changed]
ghc: panic! (the 'impossible' happened)
(GHC version 8.10.3:
expectJust getPackageDetails
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:57:27 in ghc:Maybes
expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Packages
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
I originally mentioned this in #18284 but this backtrace looks of different origin so I am reporting here now separately.
## Steps to reproduce
`stack --resolver lts-17 build fbrnch`
## Expected behavior
Compile the program without panicking (like 8.8.4 does successfully).
Not having to re-run the build to get it to complete.
I don't feel confident with updating Fedora to 8.10 with this issue existing,
though admittedly this is not a Fedora ghc build.
## Environment
* GHC version used: 8.10.4
Optional:
* Operating System: Fedora 33
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/19650ghci readily resets package state2021-12-14T15:49:44ZNeil Mitchellghci readily resets package state## Summary
Using GHC 9.0.1 and Cabal 3.4.0.0, a lot of "changes" will cause GHC to forget which modules were loaded in ghci. With GHC 8.10 it was a lot more robust. The frequent loss of loaded modules means tools like `ghcid` are a lot ...## Summary
Using GHC 9.0.1 and Cabal 3.4.0.0, a lot of "changes" will cause GHC to forget which modules were loaded in ghci. With GHC 8.10 it was a lot more robust. The frequent loss of loaded modules means tools like `ghcid` are a lot less useful.
## Steps to reproduce
```
$ cabal init
$ cabal repl
```
Now create an empty file `Foo.hs`, and a file `.ghci` with the contents:
```
:load Foo.hs
:set -DMAGIC
```
Using GHC 8.10.3, running `cabal exec ghci` leaves me with a GHCi session with `Foo.hs` loaded. However, with GHC 9.0.1:
```
C:\Neil\temp\ghci-bug>cabal exec ghci
Warning: The package list for 'hackage.haskell.org' is 22 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, one module loaded.
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
package flags have changed, resetting and loading new packages...
Loaded GHCi configuration from C:\Neil\temp\ghci-bug\.ghci
ghci> :show modules
ghci>
```
So something about the environment changed, so it threw away all my loaded modules. In practice, a lot of things seem to make the environment change - turning on/off exceptions on breakpoints does it too. This makes `ghci` a whole lot less useful.
Using `ghci` alone it doesn't seem to reset the modules. However, in practice, using `ghci` alone is now very difficult as it no longer allows global installs. There are also magic environment files which are hard to avoid, so alas, this bug report is in the intersection - but given keeping Cabal constant and changing GHC causes the bug, reporting for GHC 9.0.1.
## Expected behavior
Don't throw away the loaded modules so freely.
## Environment
* GHC version used: GHC 9.0.1
* Operating System: Windows
* System Architecture: x86_649.0.2Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/20253Hadrian binary distributions ship `settings`2023-04-04T08:09:40ZBen GamariHadrian binary distributions ship `settings`The binary distributions produced by Hadrian do not make any attempt to generate the `settings` file from the information about the host deduced by the bindist `configure` script. This is wrong. In particular, this was noticed on an olde...The binary distributions produced by Hadrian do not make any attempt to generate the `settings` file from the information about the host deduced by the bindist `configure` script. This is wrong. In particular, this was noticed on an older Darwin machine where the build environment's `cc` supported `-no-pie` but the installation host did not. Consequently, the installed compiler attempted to use `-no-pie` and was broken.9.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20806Document -package-env correctly2021-12-14T08:43:20ZRichard Eisenbergrae@richarde.devDocument -package-env correctlyFor a few GHCs now, I'm used to seeing a note as GHCi launches that it has loaded my default package environment file, in `~/.ghc/arch-version/environments/default`. Today, when working in GHC 9.2.1, I was surprised that some package was...For a few GHCs now, I'm used to seeing a note as GHCi launches that it has loaded my default package environment file, in `~/.ghc/arch-version/environments/default`. Today, when working in GHC 9.2.1, I was surprised that some package wasn't available, and so I looked for this line and was surprised not to find it.
Yet the [documentation](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) still says that it loads this default.
I think the documentation should be updated, and a release note added.https://gitlab.haskell.org/ghc/ghc/-/issues/21307ghc reports package-id in unused imports warning instead the package name+ver...2022-04-01T17:27:30ZJavier Neira ghc reports package-id in unused imports warning instead the package name+version+id## Summary
From https://github.com/haskell/cabal/issues/7209#issuecomment-1080118466
ghc reports bad package name in unused imports warning when the package-id name segment does not match the package name
## Steps to reproduce
* `caba...## Summary
From https://github.com/haskell/cabal/issues/7209#issuecomment-1080118466
ghc reports bad package name in unused imports warning when the package-id name segment does not match the package name
## Steps to reproduce
* `cabal build -v3` a project with any dependency containing vowels and `ghc-options: -Wunused-packages -Werror=unused-packages`
* check the ghc call made by cabal pass the package id removing vowels from the package name
* for the `ieee` package it would be like `-package-id -0.7-c9bfa6bf`
* check the v2 store package db has the complete package name for such package id:
```
# ghc-pkg --package-db ~/.cabal/store/ghc-9.2.2/package.db describe ieee | head -n 5
name: ieee
version: 0.7
visibility: public
id: -0.7-c9bfa6bf
key: -0.7-c9bfa6bf
```
* and check the unused package warning uses the package-id instead the full package name plus version:
```
<no location info>: warning: [-Wunused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- -0.7-c9bfa6bf
```
* the behaviour is not reproduced in windows, where package names are also shortened by cabal in the package id, see https://github.com/haskell/cabal/issues/7209#issuecomment-1080327599
* from the ghc call made by cabal we derive the bug is in the ghc side
## Expected behavior
* the error message should use the full package name + package version from package-db
```
<no location info>: warning: [-Wunused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- ieee-0.7
```
## Environment
* GHC version used: 8.10.7, 9.2.2
Optional:
* Operating System: macos
* System Architecture: anyñ9.4.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21931v3.8.1.0 checkout of cabal supports GHC 9.4 and is ready for assimilation int...2022-08-31T22:27:23ZMikolaj Konarskiv3.8.1.0 checkout of cabal supports GHC 9.4 and is ready for assimilation into GHC (or if it's not, we'd love your feedback)The tag is https://github.com/haskell/cabal/tree/Cabal-v3.8.1.0.
Contact point is Mikolaj Konarski, but feel free to also open tickets in the cabal repo.
The actual cabal release is planned in a week or two, after some more of (yours, ...The tag is https://github.com/haskell/cabal/tree/Cabal-v3.8.1.0.
Contact point is Mikolaj Konarski, but feel free to also open tickets in the cabal repo.
The actual cabal release is planned in a week or two, after some more of (yours, among others) feedback. Either exactly the tag is going to be released or, if changes are needed, a new tag, e.g., 3.8.2.0. Current hackage candidates are at https://hackage.haskell.org/package/Cabal-3.8.1.0/candidate https://hackage.haskell.org/package/Cabal-syntax-3.8.1.0/candidate https://hackage.haskell.org/package/cabal-install-3.8.1.0/candidate https://hackage.haskell.org/package/cabal-install-solver-3.8.1.0/candidate9.4.1Douglas Wilsondouglas@well-typed.comDouglas Wilsondouglas@well-typed.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22333GHC 9.4.2/Cabal 3.8.1.0: `PackageImports` with `reexported-modules`, problem2022-12-15T18:48:30ZMike PilgremGHC 9.4.2/Cabal 3.8.1.0: `PackageImports` with `reexported-modules`, problem## Summary
I have reported the same [issue](https://github.com/haskell/cabal/issues/8548) in the repository of Cabal (the library) and it has been suggested there that it may be a bug in GHC 9.4.2. The problem has been reproduced with S...## Summary
I have reported the same [issue](https://github.com/haskell/cabal/issues/8548) in the repository of Cabal (the library) and it has been suggested there that it may be a bug in GHC 9.4.2. The problem has been reproduced with Stack and Cabal (the tool). The problem is most easily described by the steps to produce it, below.
## Steps to reproduce
I have a library in package `my-package-B` which exposes module `LibB`. I have a library in package `my-package-A` which `build-depends` on `my-package-B` and has `reexported-modules` `LibB`.
Finally, I have an executable in package `my-package-C` which `build-depends` on `my-package-A` (only), and has `Main.hs`:
~~~haskell
{-# LANGUAGE PackageImports #-}
module Main (main) where
import "my-package-A" LibB (someFuncB)
main :: IO ()
main = print someFuncB
~~~
With `stack --resolver ghc-9.2.4 build`, it all builds as expected.
However, with `stack --resolver ghc-9.4.2 build`, and all else equal, the build fails with Cabal message:
~~~text
my-package-C> app\Main.hs:6:1: error:
my-package-C> Could not find module ‘LibB’
my-package-C> Perhaps you meant
my-package-C> LibB (from my-package-A-0.1.0.0, reexporting LibB)
my-package-C> LibA (from my-package-A-0.1.0.0)
my-package-C> |
my-package-C> 6 | import "my-package-A" LibB (someFuncB)
my-package-C> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~~~
I can't make sense of the error message. I've requested `LibB` be imported from package `my-package-A` and I'm told it can't be found but perhaps I mean `LibB` reexported by `my-package-A`?
However, if I change (only) `Main.hs` to (no package-qualified import):
~~~haskell
module Main (main) where
import LibB (someFuncB)
main :: IO ()
main = print someFuncB
~~~
`stack --resolver ghc-9.4.2 build` now works! That is why I think it is a bug.
## Environment
* GHC 9.4.2
* Windows 11
* x86_649.4.4Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23131ghc type mismatch due to different package versions2023-10-28T08:03:10ZFrancesco Occhipintighc type mismatch due to different package versions## Summary
We stumbled upon the following:
```
• Couldn't match type ‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
with ‘ByteString’
NB: ‘ByteString’
is defined in ‘Data.ByteString...## Summary
We stumbled upon the following:
```
• Couldn't match type ‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
with ‘ByteString’
NB: ‘ByteString’
is defined in ‘Data.ByteString.Internal.Type’
in package ‘bytestring-0.11.4.0’
‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
is defined in ‘Data.ByteString.Internal’
in package ‘bytestring-0.10.8.2’
Expected type: Field -> Parser Day
Actual type: ByteString -> Parser Day
• In the expression: parseDate
In an equation for ‘parseField’: parseField = parseDate
In the instance declaration for ‘FromField Day’
```
This seems to be due to `cassava` relying on `bytestring` 0.10, while the type in scope and related functions come from an installed `bytestring` 0.11.
Unfortunately, the `PackageImports` syntax does not allow to specify a package version.
We could try to select the desired package by using the compiler's options, but `-hide-all-packages` won't help because it prevents some locally installed packages to access their dependencies. `-hide-package bytestring-0.11.4.2`, on the other hand, fails with the surprising error:
```
<command line>: cannot satisfy -hide-package bytestring-0.11.4.2
(use -v for more information)
```
Since we just want to hide a package, we would expect no errors even if the package was not visible. Anyway this is just some temporary puzzlement, as it turns out that we wrote the version wrong, so the error is arguably helpful.
Once the right version is specified, the compiler starts and mostly works, although it seems to still fail at some stage, between Renamer and Upsweep, with the same problem:
```
Ambiguous module name ‘Data.ByteString.Lazy’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
```
The compiler version is 8.6.5. Before updating i would be interested to know whether this has been fixed in a later version. Furthermore, since this use case touched a diverse array of limitations, i thought it might be worth issuing anyway.
Here the complete error including some contextual lines:
```
*** Parser [Lumaposta]:
!!! Parser [Lumaposta]: finished in 2.81 milliseconds, allocated 4.923 megabytes
*** Renamer/typechecker [Lumaposta]:
!!! Renamer/typechecker [Lumaposta]: finished in 25.23 milliseconds, allocated 12.681 megabytes
lumaposta.hs:9:1: error:
Ambiguous module name ‘Data.ByteString’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
9 | import Data.ByteString (ByteString)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:16:1: error:
Ambiguous module name ‘Data.ByteString’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
16 | import qualified Data.ByteString as ByteString
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:17:1: error:
Ambiguous module name ‘Data.ByteString.Lazy’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
17 | import qualified Data.ByteString.Lazy as Lazy
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:18:1: error:
Ambiguous module name ‘Data.ByteString.Char8’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
18 | import qualified Data.ByteString.Char8 as Char8
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Upsweep partially successful.
*** Deleting temp files:
Deleting:
link(batch): upsweep (partially) failed OR
Main.main not exported; not linking.
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
```
## Environment
* GHC version used: 8.6.5Matthew PickeringMatthew Pickering