GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:17:54Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/454hPutBuf doesn't respect LineBuffering2019-07-07T19:17:54ZSimon MarlowhPutBuf doesn't respect LineBuffering```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newA...```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newArray)
> import System.IO (hSetBinaryMode, hPutBuf, stdout,
hSetBuffering,
> BufferMode(..))
>
> main = do hSetBinaryMode stdout True
> hSetBuffering stdout LineBuffering
> p <- newArray (map castCharToCChar "foo\n")
> hPutBuf stdout p 4
> system "sleep 5"
> putStr "bar\n"
> --------------------------------------------------
>
> compiled by GHC then it waits 5 seconds and then
prints foo and bar
> together.
>
> With hugs, foo is printed and then 5 seconds later
bar is printed, as
> I would expect.
True, the implementation doesn't respect LineBuffering
(though it does
respect the other buffering modes, I believe). That's
a bug.
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/592signal handlers should be able to access siginfo_t information2019-07-07T19:17:44ZSimon Marlowsignal handlers should be able to access siginfo_t informationCurrently a Haskell signal handler doesn't get much information at all. There ought to be a way to access all the information that the C signal handler gets (siginfo_t).
There might be some implementation trickiness: we have to stash aw...Currently a Haskell signal handler doesn't get much information at all. There ought to be a way to access all the information that the C signal handler gets (siginfo_t).
There might be some implementation trickiness: we have to stash away the siginfo_t somewhere in the signal handler, and we have to do that without using malloc().
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers should be able to access siginfo_t information","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently a Haskell signal handler doesn't get much information at all. There ought to be a way to access all the information that the C signal handler gets (siginfo_t).\r\n\r\nThere might be some implementation trickiness: we have to stash away the siginfo_t somewhere in the signal handler, and we have to do that without using malloc().","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/711shutdownHaskell() does not return allocated memory on Unix2019-07-07T19:17:19Zlennart.augustsson@credit-suisse.comshutdownHaskell() does not return allocated memory on UnixCalling shutdownHaskell() doesn't actually return the memory allocated.
This can be very bad when loading and unloading DLLs many times.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...Calling shutdownHaskell() doesn't actually return the memory allocated.
This can be very bad when loading and unloading DLLs many times.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"shutdownHaskell() does not return allocated memory","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Calling shutdownHaskell() doesn't actually return the memory allocated.\r\nThis can be very bad when loading and unloading DLLs many times.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/789BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO2019-07-07T19:16:54ZSimon Peyton JonesBCOs can only have 64k instructions: linkBCO: >= 64k insns in BCOFredrick Eaton (frederik\@a5.repetae.net) said:
Here I'm reading a very large matrix from a file and turning it into a
template Haskell expression. Probably not the most efficient thing to
do, but the error message could be clearer...
...Fredrick Eaton (frederik\@a5.repetae.net) said:
Here I'm reading a very large matrix from a file and turning it into a
template Haskell expression. Probably not the most efficient thing to
do, but the error message could be clearer...
```
*Main> let y = $(qFast (\f -> runIO $ readMatrixFile "data.txt" (runQ.f)));
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
linkBCO: >= 64k insns in BCO
```
Indeed, the error message is unhelpful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"BCOs can only have 64k instructions","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Fredrick Eaton (frederik@a5.repetae.net) said:\r\n\r\nHere I'm reading a very large matrix from a file and turning it into a\r\ntemplate Haskell expression. Probably not the most efficient thing to\r\ndo, but the error message could be clearer...\r\n{{{\r\n*Main> let y = $(qFast (\\f -> runIO $ readMatrixFile \"data.txt\" (runQ.f)));\r\nghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):\r\n linkBCO: >= 64k insns in BCO\r\n\r\n}}}\r\nIndeed, the error message is unhelpful.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/912Build system is missing various dependencies2019-07-07T19:16:20ZSimon MarlowBuild system is missing various dependenciesThe build system is missing dependencies, which means that if you change something and recompile, you don't always get a working build. The most common problem is to issue a `darcs-all pull` followed by `make`, which may well result in a...The build system is missing dependencies, which means that if you change something and recompile, you don't always get a working build. The most common problem is to issue a `darcs-all pull` followed by `make`, which may well result in a broken build depending on what changes were pulled.
I'm creating this ticket to keep track of the dependencies that we know are missing, so that maybe one day they could be fixed.
- re-configuring with a new `--prefix` will not cause the various tools
and scripts that depend on prefix to be rebuilt.
- package dependencies are not mirrored in the build system: rebuilding base
doesn't cause all the other packages to be rebuilt, for example.
The following are probably not feasible/desirable to fix:
- stage 2 doesn't have a dependency on the packages.
- the packages don't have a dependency on the .hi file format
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Build system is missing various dependencies","status":"New","operating_system":"Multiple","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"The build system is missing dependencies, which means that if you change something and recompile, you don't always get a working build. The most common problem is to issue a {{{darcs-all pull}}} followed by {{{make}}}, which may well result in a broken build depending on what changes were pulled.\r\n\r\nI'm creating this ticket to keep track of the dependencies that we know are missing, so that maybe one day they could be fixed.\r\n\r\n * re-configuring with a new {{{--prefix}}} will not cause the various tools\r\n and scripts that depend on prefix to be rebuilt.\r\n\r\n * package dependencies are not mirrored in the build system: rebuilding base\r\n doesn't cause all the other packages to be rebuilt, for example.\r\n\r\nThe following are probably not feasible/desirable to fix:\r\n\r\n * stage 2 doesn't have a dependency on the packages.\r\n\r\n * the packages don't have a dependency on the .hi file format","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1074-fwarn-unused-imports complains about wrong import2019-07-07T19:15:23Zguest-fwarn-unused-imports complains about wrong importIf a symbol is accessible through multiple imports, ghc seems to complain about the first one, even if that's the one it's actually accessed through.
```
$ cat Test.hs
module Test where
import qualified Control.Monad (ap)
import qualif...If a symbol is accessible through multiple imports, ghc seems to complain about the first one, even if that's the one it's actually accessed through.
```
$ cat Test.hs
module Test where
import qualified Control.Monad (ap)
import qualified Control.Monad.Reader
foo :: IO ()
foo = return id `Control.Monad.ap` return ()
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6
$ ghc -c Test.hs -Werror -fwarn-unused-imports
Test.hs:3:0:
Warning: Module `Control.Monad' is imported, but nothing from it is used,
except perhaps instances visible in `Control.Monad'
To suppress this warning, use: import Control.Monad()
$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | powerpc |
</details>
<!-- {"blocked_by":[],"summary":"-fwarn-unused-imports complains about wrong import","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"powerpc","cc":[""],"type":"Bug","description":"If a symbol is accessible through multiple imports, ghc seems to complain about the first one, even if that's the one it's actually accessed through.\r\n\r\n{{{\r\n$ cat Test.hs\r\nmodule Test where\r\n\r\nimport qualified Control.Monad (ap)\r\nimport qualified Control.Monad.Reader\r\n\r\nfoo :: IO ()\r\nfoo = return id `Control.Monad.ap` return ()\r\n\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.6\r\n\r\n$ ghc -c Test.hs -Werror -fwarn-unused-imports\r\n\r\nTest.hs:3:0:\r\n Warning: Module `Control.Monad' is imported, but nothing from it is used,\r\n except perhaps instances visible in `Control.Monad'\r\n To suppress this warning, use: import Control.Monad()\r\n\r\n$\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1136High memory use when compiling many let bindings.2019-07-07T19:15:07ZIan Lynagh <igloo@earth.li>High memory use when compiling many let bindings.Two programs that generate modules with lots of let bindings that GHC struggles to compile. With the first,
```
ghc -c J.hs
```
uses \>100M of memory which seems a little high. For the second,
```
ghc -c J2.hs
```
got past 700M befor...Two programs that generate modules with lots of let bindings that GHC struggles to compile. With the first,
```
ghc -c J.hs
```
uses \>100M of memory which seems a little high. For the second,
```
ghc -c J2.hs
```
got past 700M before I killed it, with both 6.6 and HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| 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":"High memory use when compiling many let bindings.","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Two programs that generate modules with lots of let bindings that GHC struggles to compile. With the first,\r\n\r\n{{{\r\nghc -c J.hs\r\n}}}\r\n\r\nuses >100M of memory which seems a little high. For the second,\r\n\r\n{{{\r\nghc -c J2.hs\r\n}}}\r\n\r\ngot past 700M before I killed it, with both 6.6 and HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1185can't do I/O in the child of forkProcess with -threaded2019-07-07T19:14:49ZSimon Marlowcan't do I/O in the child of forkProcess with -threaded`forkProcess` kills all threads, as advertised. Unfortunately this includes the I/O manager thread, so trying to do I/O in the child of `forkProcess` leads to deadlock. It might be possible to fix this, but we'd need to add a way to rest...`forkProcess` kills all threads, as advertised. Unfortunately this includes the I/O manager thread, so trying to do I/O in the child of `forkProcess` leads to deadlock. It might be possible to fix this, but we'd need to add a way to restart the I/O manager thread.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"can't do I/O in the child of forkProcess with -threaded","status":"New","operating_system":"Unknown","component":"Runtime System","related":[],"milestone":"_|_","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"`forkProcess` kills all threads, as advertised. Unfortunately this includes the I/O manager thread, so trying to do I/O in the child of `forkProcess` leads to deadlock. It might be possible to fix this, but we'd need to add a way to restart the I/O manager thread.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1324threadDelay can't handle long times2019-07-07T19:14:06ZguestthreadDelay can't handle long timesWith (Control.Concurrent.threadDelay :: Int -\> IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to im...With (Control.Concurrent.threadDelay :: Int -\> IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to implement longer delays, but I ask whether this is the interface we want to have.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay can't handle long times","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With (Control.Concurrent.threadDelay :: Int -> IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to implement longer delays, but I ask whether this is the interface we want to have.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1346bootstrap from HC files2021-02-24T11:23:38ZSimon Marlowbootstrap from HC filesThere's some work to do on 6.8 to ensure that we can still bootstrap from HC files. This will be slightly harder due to the new Cabal-based build system for libraries, and the solution will probably involve 'setup makefile' somewhere. Al...There's some work to do on 6.8 to ensure that we can still bootstrap from HC files. This will be slightly harder due to the new Cabal-based build system for libraries, and the solution will probably involve 'setup makefile' somewhere. Also we'll need to update the building guide to include the new instructions, whatever they may be.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"bootstrap from HC files","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"There's some work to do on 6.8 to ensure that we can still bootstrap from HC files. This will be slightly harder due to the new Cabal-based build system for libraries, and the solution will probably involve 'setup makefile' somewhere. Also we'll need to update the building guide to include the new instructions, whatever they may be.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1502GHC should integrate better with mingw2019-07-07T19:13:10ZeivuokkoGHC should integrate better with mingwWhen developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used
- strip
- nm
- reimp
- dlltool
- pexport
- windres
Also, when installing libraries/headers for mingw/msys and a...When developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used
- strip
- nm
- reimp
- dlltool
- pexport
- windres
Also, when installing libraries/headers for mingw/msys and are going to use them with GHC, the only way to get them linked is to copy them to GHC installation as well. So, I'd really like if I could tell GHC via flag or preferably via configuration file. But GHC would probably need to organize the includes and archives differently than it does now.
Configuring via files would also allow Cabal to make use of these tools without much extra fiddling.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| 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 should integrate better with mingw","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["windows"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"When developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used\r\n * strip\r\n * nm\r\n * reimp\r\n * dlltool\r\n * pexport\r\n * windres\r\n\r\nAlso, when installing libraries/headers for mingw/msys and are going to use them with GHC, the only way to get them linked is to copy them to GHC installation as well. So, I'd really like if I could tell GHC via flag or preferably via configuration file. But GHC would probably need to organize the includes and archives differently than it does now.\r\n\r\nConfiguring via files would also allow Cabal to make use of these tools without much extra fiddling.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1548printf bugs2019-07-07T19:12:58Zl.mai@web.deprintf bugsI think the following are bugs in printf:
```
Prelude Text.Printf> printf "%.*f" 2 (1/3) :: String
"*** Exception: Printf.printf: bad formatting char *
(expected: "0.33")
Prelude Text.Printf> printf "%.3s" "foobar" :: String
"foobar"
(...I think the following are bugs in printf:
```
Prelude Text.Printf> printf "%.*f" 2 (1/3) :: String
"*** Exception: Printf.printf: bad formatting char *
(expected: "0.33")
Prelude Text.Printf> printf "%.3s" "foobar" :: String
"foobar"
(expected: "foo")
```
This one may not be a bug but it's incompatible with C printf:
```
Prelude Text.Printf> printf "%10.5d" 4 :: String
" 4"
(expected: " 00004")
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"printf bugs","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I think the following are bugs in printf:\r\n\r\n{{{\r\nPrelude Text.Printf> printf \"%.*f\" 2 (1/3) :: String\r\n\"*** Exception: Printf.printf: bad formatting char *\r\n(expected: \"0.33\")\r\n\r\nPrelude Text.Printf> printf \"%.3s\" \"foobar\" :: String\r\n\"foobar\"\r\n(expected: \"foo\")\r\n}}}\r\n\r\nThis one may not be a bug but it's incompatible with C printf:\r\n\r\n{{{\r\nPrelude Text.Printf> printf \"%10.5d\" 4 :: String\r\n\" 4\"\r\n(expected: \" 00004\")\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1645{-# SPECIALIZE #-} doesn't2019-07-07T19:12:26Zguest{-# SPECIALIZE #-} doesn'tI would expect doing
```
{-# SPECIALIZE f :: T #-}
f :: U
f = ...
```
to create a specialized version of f that is the same as if I had written
```
f :: T
f = ...
```
But this is not the case. In the attached example the qsort functi...I would expect doing
```
{-# SPECIALIZE f :: T #-}
f :: U
f = ...
```
to create a specialized version of f that is the same as if I had written
```
f :: T
f = ...
```
But this is not the case. In the attached example the qsort function is SPECIALIZEd, and the specialized version is called QS.qsort1 in the core dump. The qsort1 function contains all kinds of dictionary manipulation that is not there when using the special type as a type signature.
This pretty much defeats the purpose of SPECIALIZE.
To test, unzip, untar, read Main.hs on how to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"{-# SPECIALIZE #-} doesn't","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"I would expect doing\r\n{{{\r\n{-# SPECIALIZE f :: T #-}\r\nf :: U\r\nf = ...\r\n}}}\r\nto create a specialized version of f that is the same as if I had written\r\n{{{\r\nf :: T\r\nf = ...\r\n}}}\r\n\r\nBut this is not the case. In the attached example the qsort function is SPECIALIZEd, and the specialized version is called QS.qsort1 in the core dump. The qsort1 function contains all kinds of dictionary manipulation that is not there when using the special type as a type signature.\r\n\r\nThis pretty much defeats the purpose of SPECIALIZE.\r\n\r\nTo test, unzip, untar, read Main.hs on how to compile.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1647Using -fdicts-strict flag causes Core Lint error2019-07-07T19:12:25Zchevalier@alum.wellesley.eduUsing -fdicts-strict flag causes Core Lint errorIt appears that passing in the `-fdicts-strict` flag results in a Core Lint error for any program:
```
$ ghc -fdicts-strict -dcore-lint hello.hs
```
```
*** Core Lint Errors: in result of Desugar ***
{-# LINE 3 "hello.hs #-}:
[RHS ...It appears that passing in the `-fdicts-strict` flag results in a Core Lint error for any program:
```
$ ghc -fdicts-strict -dcore-lint hello.hs
```
```
*** Core Lint Errors: in result of Desugar ***
{-# LINE 3 "hello.hs #-}:
[RHS of $dMonad_a6a :: GHC.Base.Monad GHC.IOBase.IO]
Recursive or top-level binder has strict demand info: $dMonad_a6a
Binder's demand info: T
```
The flag is documented only minimally, so I'm not sure whether it's something that still gets used a lot. Thus I'm not sure whether it would be worth it to fix it or just remove the flag. This is only in HEAD.6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1817Should be possible to specify pragmas with mixed case2019-07-07T19:11:36ZIan Lynagh <igloo@earth.li>Should be possible to specify pragmas with mixed caseReported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-October/013313.html
```
The manual says:
"Pragmas all take the form {-# word ... #-} where word indicates the
type of pragma, and is followed optionally by inf...Reported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-October/013313.html
```
The manual says:
"Pragmas all take the form {-# word ... #-} where word indicates the
type of pragma, and is followed optionally by information specific to
that type of pragma. Case is ignored in word."
However, when I use "Language CPP" instead of "LANGUAGE CPP" in the
pragma, the pragma is ignored. Is this a documentation bug?
```
Either the documentation or code should be fixed. In the thread linked to above some people spoke up in favour of supporting what the manual claims, so ideally it should be the code that is fixed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Should be possible to specify pragmas with mixed case","status":"New","operating_system":"Unknown","component":"Compiler (Parser)","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Reported here: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-October/013313.html\r\n\r\n{{{\r\nThe manual says:\r\n\r\n\"Pragmas all take the form {-# word ... #-} where word indicates the \r\ntype of pragma, and is followed optionally by information specific to\r\nthat type of pragma. Case is ignored in word.\"\r\n\r\nHowever, when I use \"Language CPP\" instead of \"LANGUAGE CPP\" in the\r\npragma, the pragma is ignored. Is this a documentation bug?\r\n}}}\r\n\r\nEither the documentation or code should be fixed. In the thread linked to above some people spoke up in favour of supporting what the manual claims, so ideally it should be the code that is fixed.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1squadettesquadettehttps://gitlab.haskell.org/ghc/ghc/-/issues/1876Complete shared library support2019-07-07T19:11:19ZSimon MarlowComplete shared library supportThis ticket is a placeholder for the shared libraries work, which is mostly working but needs to be completed (binary distributions, issues with `-rpath` etc.).
<details><summary>Trac metadata</summary>
| Trac field | Value...This ticket is a placeholder for the shared libraries work, which is mostly working but needs to be completed (binary distributions, issues with `-rpath` etc.).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Task |
| 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":"Complete shared library support","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"This ticket is a placeholder for the shared libraries work, which is mostly working but needs to be completed (binary distributions, issues with `-rpath` etc.).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/1895Allow aliases in GHCi module imports2019-07-07T19:11:10ZtibbeAllow aliases in GHCi module importsIt would be convenient if it was possible to import a package in GHCi under another name.
```
:m +Data.ByteString.Lazy.Char8 as B
```
This is especially useful with modules like `Data.ByteString` which names collide with `Prelude`.
<d...It would be convenient if it was possible to import a package in GHCi under another name.
```
:m +Data.ByteString.Lazy.Char8 as B
```
This is especially useful with modules like `Data.ByteString` which names collide with `Prelude`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Allow aliases in GHCi module imports","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"FeatureRequest","description":"It would be convenient if it was possible to import a package in GHCi under another name.\r\n\r\n{{{\r\n:m +Data.ByteString.Lazy.Char8 as B\r\n}}}\r\n\r\nThis is especially useful with modules like {{{Data.ByteString}}} which names collide with {{{Prelude}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1911-w doesn't turn off nullModuleExport2019-07-07T19:11:05ZAndreaRossato-w doesn't turn off nullModuleExportHello!
Starting from 6.8.1 ghc reports a warning when a module that does not export anything is exported. The warning is generated in compiler/rename/RnName.lhs by exports_from_avail.
I'm not familiar enough with ghc to go any further....Hello!
Starting from 6.8.1 ghc reports a warning when a module that does not export anything is exported. The warning is generated in compiler/rename/RnName.lhs by exports_from_avail.
I'm not familiar enough with ghc to go any further.
Thanks.
Andrea
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"-w doesn't turn off nullModuleExport","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"Hello!\r\n\r\nStarting from 6.8.1 ghc reports a warning when a module that does not export anything is exported. The warning is generated in compiler/rename/RnName.lhs by exports_from_avail.\r\n\r\nI'm not familiar enough with ghc to go any further.\r\n\r\nThanks.\r\nAndrea","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1AndreaRossatoAndreaRossatohttps://gitlab.haskell.org/ghc/ghc/-/issues/1924Rewrite the handling of values we get from ./configure2019-07-07T19:11:01ZIan Lynagh <igloo@earth.li>Rewrite the handling of values we get from ./configureThe handling of values we get from configure needs to be rewritten to follow the normal conventions, and we should check that everything gets sane values (in particular, I'm not sure if mandir does currently). This was discussed in these...The handling of values we get from configure needs to be rewritten to follow the normal conventions, and we should check that everything gets sane values (in particular, I'm not sure if mandir does currently). This was discussed in these messages and their replies:
http://www.haskell.org/pipermail/cvs-ghc/2007-September/038407.html
http://www.haskell.org/pipermail/cvs-ghc/2007-September/038418.html
We should also only do this in a single file which is shared between normal builds and bindists, rather than doing it in both `mk/config.mk.in` and `distrib/Makefile-bin-vars.in`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Rewrite the handling of values we get from ./configure","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The handling of values we get from configure needs to be rewritten to follow the normal conventions, and we should check that everything gets sane values (in particular, I'm not sure if mandir does currently). This was discussed in these messages and their replies:\r\nhttp://www.haskell.org/pipermail/cvs-ghc/2007-September/038407.html\r\nhttp://www.haskell.org/pipermail/cvs-ghc/2007-September/038418.html\r\n\r\nWe should also only do this in a single file which is shared between normal builds and bindists, rather than doing it in both `mk/config.mk.in` and `distrib/Makefile-bin-vars.in`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1962make binary-dist creates nested directories under solaris2019-07-07T19:10:52ZChristian Maedermake binary-dist creates nested directories under solaris```
cat Makefile >> /home/maeder/haskell/pc-solaris/ghc-6.8.1
.20071206/ghc-6.8.1.20071206/compiler/Makefile
/home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/install-sh -c -m 644 packa
ge.conf.in /home/mae...```
cat Makefile >> /home/maeder/haskell/pc-solaris/ghc-6.8.1
.20071206/ghc-6.8.1.20071206/compiler/Makefile
/home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/install-sh -c -m 644 packa
ge.conf.in /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.2007
1206/compiler/
set -e; for d in stage2/*/; do ../utils/mkdirhier/mkdirhier /home/maeder/haskell
/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/compiler/$d; done
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin
mkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp
iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin
/NOTES
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make binary-dist creates nested directories under solaris","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\ncat Makefile >> /home/maeder/haskell/pc-solaris/ghc-6.8.1\r\n.20071206/ghc-6.8.1.20071206/compiler/Makefile\r\n/home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/install-sh -c -m 644 packa\r\nge.conf.in /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.2007\r\n1206/compiler/\r\nset -e; for d in stage2/*/; do ../utils/mkdirhier/mkdirhier /home/maeder/haskell\r\n/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/compiler/$d; done\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin\r\nmkdir /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp\r\niler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin\r\n/NOTES\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1