GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:08:53Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2379ghc-6.9.20080614: panic! (the 'impossible' happened)2019-07-07T19:08:53Zmegaczghc-6.9.20080614: panic! (the 'impossible' happened)```
[ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( Data/Array/Parallel/Base/Rebox.hs, dist/build/Data/Array/Parallel/Base/Rebox.o )
ghc-6.9.20080614: panic! (the 'impossible' happened)
(GHC version 6.9.20080614 for i386-apple-da...```
[ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( Data/Array/Parallel/Base/Rebox.hs, dist/build/Data/Array/Parallel/Base/Rebox.o )
ghc-6.9.20080614: panic! (the 'impossible' happened)
(GHC version 6.9.20080614 for i386-apple-darwin):
initC: srt_lbl
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 85934552 bytes, 26 GCs, 2419370/5914624 avg/max bytes residency (3 samples), 11M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (1.05 elapsed), 0.08 GC (0.09 elapsed) :ghc>>
```6.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/2201"ghc-pkg --user describe '*'" fails with empty user db2019-07-07T19:09:44Zduncan"ghc-pkg --user describe '*'" fails with empty user dbWith ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user sp...With ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet).
So what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD.
I'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like "`ghc-pkg: cannot find package matching *`" because that will upset Cabal's parser.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"\"ghc-pkg --user describe '*'\" fails with empty user db","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With ghc 6.9 and later Cabal uses the new \"`ghc-pkg describe '*'`\" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet).\r\n\r\nSo what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD.\r\n\r\nI'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like \"{{{ghc-pkg: cannot find package matching *}}}\" because that will upset Cabal's parser.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/1198Windows: hWaitForInput returns False for file handles, and doesn't work prope...2019-07-07T19:14:44ZIan Lynagh <igloo@earth.li>Windows: hWaitForInput returns False for file handles, and doesn't work properly for consolesOn Windows, readwrite002 is failing with
```
readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument)
```
The error is being generated by
```
rc = PeekNamedPipe( hFile, NULL, 0, NULL, &avail, NULL );
``...On Windows, readwrite002 is failing with
```
readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument)
```
The error is being generated by
```
rc = PeekNamedPipe( hFile, NULL, 0, NULL, &avail, NULL );
```
in the `inputReady` function in `cbits/inputReady.c`, during a call to `hReady`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | readwrite002 |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.6.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"readwrite002","architecture":"Unknown","cc":[""],"type":"Bug","description":"On Windows, readwrite002 is failing with\r\n{{{\r\nreadwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument)\r\n}}}\r\nThe error is being generated by\r\n{{{\r\nrc = PeekNamedPipe( hFile, NULL, 0, NULL, &avail, NULL );\r\n}}}\r\nin the `inputReady` function in `cbits/inputReady.c`, during a call to `hReady`.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.1Simon MarlowSimon Marlow