GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:47:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7934usleep hangs, no threads2019-07-07T18:47:23Zgelisamusleep hangs, no threadsimport System.Posix.Unistd
main = flip mapM_ \[0..\] $ \\i -\> do
usleep 100000
> print i
###
The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to pr...import System.Posix.Unistd
main = flip mapM_ \[0..\] $ \\i -\> do
usleep 100000
> print i
###
The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print).
The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any.
The problem also occurs with nanosleep, but not with threadDelay.
#1156 sounds related, but this time the problem also occurs without -threaded.
###
workaround: use threadDelay.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"usleep hangs, no threads","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"import System.Posix.Unistd\r\nmain = flip mapM_ [0..] $ \\i -> do\r\n usleep 100000\r\n print i\r\n\r\n===\r\n\r\nThe above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print).\r\n\r\nThe documentation for usleep warns about bad interactions with threads, but the above program doesn't use any.\r\n\r\nThe problem also occurs with nanosleep, but not with threadDelay.\r\n\r\n#1156 sounds related, but this time the problem also occurs without -threaded.\r\n\r\n===\r\n\r\nworkaround: use threadDelay.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7910ConstraintKinds and reifyInstances2019-07-07T18:47:32ZtrevorConstraintKinds and reifyInstancesreifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):
```
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH...reifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):
```
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
class C a
instance C Int
type D a = C a
main = print $(
do isCInst <- isInstance ''C [ConT ''Int]
isDInst <- isInstance ''D [ConT ''Int]
lift (isCInst,isDInst))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"ConstraintKinds and reifyInstances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["ConstraintKinds,","TemplateHaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"reifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):\r\n\r\n\r\n{{{\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nimport Language.Haskell.TH\r\nimport Language.Haskell.TH.Syntax\r\n\r\nclass C a\r\ninstance C Int\r\n\r\ntype D a = C a\r\n\r\nmain = print $(\r\n do isCInst <- isInstance ''C [ConT ''Int]\r\n isDInst <- isInstance ''D [ConT ''Int]\r\n lift (isCInst,isDInst))\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7899Strange behavior of -ddump-minimal-imports2019-07-07T18:47:37ZdsfStrange behavior of -ddump-minimal-importsThe following two line module:
```
import System.Exit
main = undefined >>= undefined
```
when compiled with `ghc -c -ddump-minimal-imports Test.hs` produces the following in Main.imports:
```
import System.Exit ( (>>=), undefined )
``...The following two line module:
```
import System.Exit
main = undefined >>= undefined
```
when compiled with `ghc -c -ddump-minimal-imports Test.hs` produces the following in Main.imports:
```
import System.Exit ( (>>=), undefined )
```
Those symbols are not exported by System.Exit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Strange behavior of -ddump-minimal-imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following two line module:\r\n\r\n{{{\r\nimport System.Exit\r\nmain = undefined >>= undefined\r\n}}}\r\n\r\nwhen compiled with {{{ghc -c -ddump-minimal-imports Test.hs}}} produces the following in Main.imports:\r\n{{{\r\nimport System.Exit ( (>>=), undefined )\r\n}}}\r\nThose symbols are not exported by System.Exit.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7877hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X2019-07-07T18:47:43ZnfrisbyhSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X```
$ make TESTS="hSetBuffering002 hSetBuffering004"
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)
../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] ...```
$ make TESTS="hSetBuffering002 hSetBuffering004"
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)
../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci)
```
For 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)`
For 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin.
I'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ make TESTS=\"hSetBuffering002 hSetBuffering004\"\r\n# ... snip ...\r\nUnexpected failures:\r\n ../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)\r\n ../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci)\r\n}}}\r\n\r\nFor 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)`\r\n\r\nFor 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin.\r\n\r\nI'm on OS X 10.7.5\r\n\r\n{{{\r\nghc : ade1ae97ed52c493ec415c1601dace39b64071dd\r\ntestsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b\r\nbase : b3387abfbc94b69e977c232386acad4dde7597e8\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7876hClose002 for ghci hangs on Mac OS X2019-07-07T18:47:43ZnfrisbyhClose002 for ghci hangs on Mac OS XI'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
hClose002 fails with these three ways:
```
$ make TESTS=hCl...I'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
hClose002 fails with these three ways:
```
$ make TESTS=hClose002
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hClose002 [bad exit code] (ghci,threaded1,threaded2)
```
The test opens a file in !WriteMode, closes it "without telling the IO library", then hCloses it twice. Then it does that again in !ReadMode. Thus there are four hClose calls in total. It is the third one that hangs.https://gitlab.haskell.org/ghc/ghc/-/issues/7866floor (0/0) :: Int is different with -O0 and -O12019-07-07T18:47:45ZAlex Langfloor (0/0) :: Int is different with -O0 and -O1This program:
```
main = print (floor (0/0) :: Int)
```
prints a different result with -O0:
```
0
```
and -O1:
```
-9223372036854775808
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----...This program:
```
main = print (floor (0/0) :: Int)
```
prints a different result with -O0:
```
0
```
and -O1:
```
-9223372036854775808
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"floor (0/0) :: Int is different with -O0 and -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n{{{\r\nmain = print (floor (0/0) :: Int)\r\n}}}\r\n\r\nprints a different result with -O0:\r\n{{{\r\n0\r\n}}}\r\nand -O1:\r\n{{{\r\n-9223372036854775808\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7853UTF encodings do not detect overlong forms2019-07-07T18:47:48ZbatterseapowerUTF encodings do not detect overlong formsOverlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do ...Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!
This problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"UTF encodings do not detect overlong forms","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!\r\n\r\nThis problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7839After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: faile...2019-07-07T18:47:52ZthorkilnaurAfter forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)"Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
...Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
$ cat T7715O.hs
import Control.Monad
import Control.Concurrent
import System.IO
import System.Environment
main' c d2 = do
replicateM_ c $ forkIO $ do
putStrLn "Hello, world!"
threadDelay d2
mainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)
main :: IO ()
main
= do
hSetBuffering stdout NoBuffering
hSetBuffering stderr NoBuffering
args <- getArgs
mainArgsInterpret args
$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts
[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )
Linking T7715O ...
$ ./T7715O 25 10000000
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
HeT7715O: <stdout>: hPutChar: failed (Operation not supported)
T7715O: <stdout>: hPutChar: failed (Operation not supported)
$
```
This doesn't happen on
```
$ uname -a
Linux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"After forkIO'ing on Intel Mac, putStrLn (presumably) reports \"hPutChar: failed (Operation not supported)\"","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Investigating #7715 on the tn23 builder, which is\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ \r\n}}}\r\nI ran into:\r\n{{{\r\n$ cat T7715O.hs \r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport System.IO\r\nimport System.Environment\r\n\r\nmain' c d2 = do\r\n replicateM_ c $ forkIO $ do\r\n putStrLn \"Hello, world!\"\r\n threadDelay d2\r\n\r\nmainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)\r\n\r\nmain :: IO ()\r\nmain\r\n = do\r\n hSetBuffering stdout NoBuffering\r\n hSetBuffering stderr NoBuffering\r\n args <- getArgs\r\n mainArgsInterpret args\r\n$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts \r\n[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )\r\nLinking T7715O ...\r\n$ ./T7715O 25 10000000 \r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHeT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\nT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\n$\r\n}}}\r\nThis doesn't happen on\r\n{{{\r\n$ uname -a\r\nLinux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux\r\n$ \r\n}}}\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7716ZonedTime read instance failing to parse what show returns2019-07-07T18:48:26Zmercer92ZonedTime read instance failing to parse what show returnsTest case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Ti...Test case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Time"
*** Exception: Prelude.read: no parse
```
Reportedly this works with (some) other timezones, so be sure to also test it with mine (show time =\> "2013-02-24 14:51:56.453125 Central European Standard Time").
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Zonetime read instance failing to parse what show returns","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["ZoneTime","read","show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case:\r\n{{{\r\nimport Data.Time\r\n\r\nmain = do\r\n time <- getZonedTime\r\n let string = show time\r\n print string\r\n print $ (read string :: ZonedTime)\r\n}}}\r\n\r\nThis gives me:\r\n\r\n\r\n{{{\r\n*Main> main\r\n\"2013-02-24 14:51:56.453125 Central European Standard Time\"\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nReportedly this works with (some) other timezones, so be sure to also test it with mine (show time => \"2013-02-24 14:51:56.453125 Central European Standard Time\").","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7613readSigned consumes too much input2019-07-07T18:48:59ZliyangreadSigned consumes too much input```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0...```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0.1"
[(0,".1")]
```
I think the bug is due to the use of `lex` in `readSigned`, which consumes the entire "0.1" string, such that readDec no longer gives a clean parse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"readSigned consumes too much input","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> reads \"0.1\" :: [(Int, String)]\r\n[]\r\n}}}\r\n\r\nI would have expected {{{[(0, \".1\")]}}}. The Report specifies that {{{reads}}} for {{{Int}}} ought to essentially be {{{readSigned readDec}}}, and indeed {{{readDec}}} gives the expected result:\r\n{{{\r\n> readDec \"0.1\"\r\n[(0,\".1\")]\r\n}}}\r\n\r\nI think the bug is due to the use of {{{lex}}} in {{{readSigned}}}, which consumes the entire \"0.1\" string, such that readDec no longer gives a clean parse.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7599timeout does not behave as expected2019-07-07T18:49:03Ziquetimeout does not behave as expectedIn trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positi...In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.
Below is a minimal test-case that I ran in ghci.
Import System.Timeout
Import Network
timeout (-1) $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns: Just {handle: \<socket: 9\>}
timeout 1000000 $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns Nothing
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"timeout does not behave as expected","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":["System.Timeout","base-4.6","timeout"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.\r\n\r\nWhen connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.\r\n\r\nBelow is a minimal test-case that I ran in ghci.\r\n\r\nImport System.Timeout\r\n\r\nImport Network\r\n\r\ntimeout (-1) $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns: Just {handle: <socket: 9>}\r\n\r\ntimeout 1000000 $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns Nothing","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7589LLVM 3.2 Support2019-07-07T18:49:06ZdtereiLLVM 3.2 SupportLLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started...LLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1515 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
5 unexpected failures
Unexpected failures:
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where the failures marked with '\*' are unique to the LLVM backend.
With LLVM 3.2 we get the following:
```
OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1512 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
8 unexpected failures
Unexpected failures:
** codeGen/should_compile 1916 [exit code non-0] (optllvm)
** codeGen/should_run cgrun028 [exit code non-0] (optllvm)
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
** numeric/should_run numrun012 [exit code non-0] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where failures marked with '\*' are unique to the LLVM backend and failures marked with '\*\*' are unique to LLVM 3.2 relative to 3.1.
I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -\> 3.2. I'll create a separate ticket for that.
**NOTE**: These test suite results were all generated on **Mac OS X 10.8**.dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7583IO reordering2019-07-07T18:49:08ZHeimdellIO reorderingI have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes...I have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes "\> " just after receiving input.
```
maelstrom@ubuntu:~/vault$ ./test
WHAT
> WHAT
```
That is not the behavior I expect.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| 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":"IO reordering","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["IO,","evaluation","invalid","order"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a simple test program:\r\n\r\n{{{\r\nmain = do putStr \"> \"\r\n line <- getLine\r\n putStrLn line\r\n}}}\r\n\r\nIn ghci, it writes \"> \" before receiving input:\r\n\r\n{{{\r\nPrelude Main> main\r\n> WHAT\r\nWHAT\r\n}}}\r\n\r\nBut being compiled by ghc it writes \"> \" just after receiving input.\r\n\r\n{{{\r\nmaelstrom@ubuntu:~/vault$ ./test \r\nWHAT\r\n> WHAT\r\n}}}\r\n\r\nThat is not the behavior I expect.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7537[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.52019-07-07T18:49:19ZPHO[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch]...I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch](https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9) to fix this:
```
git fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.\r\n\r\nHere is my [https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9 patch] to fix this:\r\n{{{\r\ngit fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7528Non terminating thunk resolution blocks world, even in the case of forkOS2019-07-07T18:49:20ZtimthelionNon terminating thunk resolution blocks world, even in the case of forkOSPlease see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(o...Please see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(or at least I don't).
> neverEnds = do
> let (a::String) = a
> putStrLn a
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Non terminating thunk resolution blocks world, even in the case of forkOS","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["Concurrent","forkOS","thunk"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Please see:\r\nhttp://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479\r\n\r\n>{-# LANGUAGE ScopedTypeVariables #-}\r\n>import Control.Concurrent\r\n\r\n>main = do\r\n> putStrLn \"Hello\"\r\n> forkOS neverEnds\r\n> putStrLn \"Bye bye\" --We never get here(or at least I don't).\r\n\r\n>neverEnds = do\r\n> let (a::String) = a\r\n> putStrLn a","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7483Broken Read instance for Data.Fixed ("no parse" in legitimate cases).2019-07-07T18:49:32ZnavaatiBroken Read instance for Data.Fixed ("no parse" in legitimate cases).`read "Just 12.30" :: Maybe Centi` throws "\*\*\* Exception: Prelude.read: no parse", as do `read " 12.30" :: Centi`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------...`read "Just 12.30" :: Maybe Centi` throws "\*\*\* Exception: Prelude.read: no parse", as do `read " 12.30" :: Centi`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | leo.gillot@navaati.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken Read instance for Data.Fixed (\"no parse\" in legitimate cases).","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["leo.gillot@navaati.net"],"type":"Bug","description":"{{{read \"Just 12.30\" :: Maybe Centi}}} throws \"*** Exception: Prelude.read: no parse\", as do {{{read \" 12.30\" :: Centi}}}.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7468incorect waiting for packets on UDP connections.2019-07-07T18:49:37ZETincorect waiting for packets on UDP connections.Preconditions:
Have an UDP server.
Transform the socket into a handle.
call hWaitForInput.
When it returns True.
call recv to read the datagram.
Expected result:
it will wait for a package with the hWaitForInput.
when the package arrive...Preconditions:
Have an UDP server.
Transform the socket into a handle.
call hWaitForInput.
When it returns True.
call recv to read the datagram.
Expected result:
it will wait for a package with the hWaitForInput.
when the package arrives (withing the timeout).
it will read it in the buffer.
(this is how it works in HUGS).
Actual result:
hWaitForInput consumes the package (I think).
recv will block until the next package arrives.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"incorect waiting for packets on UDP connections.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["UDP","loss.","packet"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Preconditions:\r\nHave an UDP server.\r\nTransform the socket into a handle.\r\ncall hWaitForInput.\r\nWhen it returns True.\r\ncall recv to read the datagram.\r\n\r\nExpected result:\r\nit will wait for a package with the hWaitForInput.\r\nwhen the package arrives (withing the timeout).\r\nit will read it in the buffer.\r\n(this is how it works in HUGS).\r\n\r\nActual result:\r\nhWaitForInput consumes the package (I think).\r\nrecv will block until the next package arrives.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7421Data.List.insert / insertBy do not match the documentation2019-07-07T18:49:48ZBart MasseyData.List.insert / insertBy do not match the documentationIn Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says "The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or e...In Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says "The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or equal to the next element." However:
> insert 1 \[2,3,4,2,3,4\]
\[1,2,3,4,2,3,4\]
One could correct the code to match the documentation. However, any maximally productive version is likely quite a bit less efficient than the current code, and the documented behavior doesn't seem terribly useful.
Instead, I suggest patching the documentation in the obvious way: "The insert function takes an element and a list and inserts the element into the list at the first position where it is less than or equal to the next element."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.insert / insertBy do not match the documentation","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says \"The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or equal to the next element.\" However:\r\n\r\n> insert 1 [2,3,4,2,3,4]\r\n[1,2,3,4,2,3,4]\r\n\r\nOne could correct the code to match the documentation. However, any maximally productive version is likely quite a bit less efficient than the current code, and the documented behavior doesn't seem terribly useful.\r\n\r\nInstead, I suggest patching the documentation in the obvious way: \"The insert function takes an element and a list and inserts the element into the list at the first position where it is less than or equal to the next element.\"","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/7365rem function in ghci changes result when using the Int type2019-07-07T18:50:05Zleonardorem function in ghci changes result when using the Int typeI define this function
```
congruent_modulo_n a b n = (rem a n) == (rem b n)
```
If the signature is:
```
congruent_modulo_n :: Integer->Integer->Integer->Bool
```
Then when I try this function in the ghci everything works perfect.
I...I define this function
```
congruent_modulo_n a b n = (rem a n) == (rem b n)
```
If the signature is:
```
congruent_modulo_n :: Integer->Integer->Integer->Bool
```
Then when I try this function in the ghci everything works perfect.
If I use this signature:
```
congruent_modulo_n :: Int->Int->Int->Bool
```
Then for the following input I get False:
```
congruent_modulo_n (3^(113-1)) 1 113
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"rem function in ghci changes result when using the Int type","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I define this function\r\n\r\n{{{\r\ncongruent_modulo_n a b n = (rem a n) == (rem b n)\r\n}}}\r\n\r\nIf the signature is:\r\n\r\n{{{\r\ncongruent_modulo_n :: Integer->Integer->Integer->Bool\r\n}}}\r\n\r\nThen when I try this function in the ghci everything works perfect.\r\nIf I use this signature:\r\n\r\n{{{\r\ncongruent_modulo_n :: Int->Int->Int->Bool\r\n}}}\r\nThen for the following input I get False:\r\n\r\n{{{\r\ncongruent_modulo_n (3^(113-1)) 1 113\r\n}}}\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7364`foo !f = id . f` becomes non-strict with -O22020-02-26T21:26:36Zshachaf`foo !f = id . f` becomes non-strict with -O2The following program:
```
foo :: (a -> b) -> a -> b
foo !f = id . f
main :: IO ()
main = print (foo undefined `seq` "ok")
```
Crashes with `Prelude.undefined` when compiled without `-O2`, but prints `"ok"` with it. As far as I can te...The following program:
```
foo :: (a -> b) -> a -> b
foo !f = id . f
main :: IO ()
main = print (foo undefined `seq` "ok")
```
Crashes with `Prelude.undefined` when compiled without `-O2`, but prints `"ok"` with it. As far as I can tell the optimizer shouldn't be allowed to do that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| 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":"`foo !f = id . f` becomes non-strict with -O2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program:\r\n\r\n{{{\r\nfoo :: (a -> b) -> a -> b\r\nfoo !f = id . f\r\n\r\nmain :: IO ()\r\nmain = print (foo undefined `seq` \"ok\")\r\n}}}\r\n\r\nCrashes with `Prelude.undefined` when compiled without `-O2`, but prints `\"ok\"` with it. As far as I can tell the optimizer shouldn't be allowed to do that.","type_of_failure":"OtherFailure","blocking":[]} -->