GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:55:44Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5365Finalizer running prematurely in ghci2019-07-07T18:55:44ZEdward KmettFinalizer running prematurely in ghciI have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci.
I've distilled the problem to the following test case.
```
Prelude ...I have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci.
I've distilled the problem to the following test case.
```
Prelude System.Mem.Weak GHC.IO> let x = let y = "foo" in (unsafePerformIO $ addFinalizer y (putStrLn "deleted")) `seq` y
Prelude System.Mem.Weak GHC.IO> x
"foo"
deleted
Prelude System.Mem.Weak GHC.IO> x
"foo"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"Finalizer running prematurely in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["finalizers"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci. \r\n\r\nI've distilled the problem to the following test case.\r\n\r\n{{{\r\nPrelude System.Mem.Weak GHC.IO> let x = let y = \"foo\" in (unsafePerformIO $ addFinalizer y (putStrLn \"deleted\")) `seq` y\r\nPrelude System.Mem.Weak GHC.IO> x\r\n\"foo\"\r\ndeleted\r\nPrelude System.Mem.Weak GHC.IO> x\r\n\"foo\"\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5363optimized profiled version of a program incorectly compiles $!2019-07-07T18:55:44Zphercekoptimized profiled version of a program incorectly compiles $!Here is a test program (file name prgSrc.hs):
```
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i <- [1..5000000] ]
let l3 = map (\l -> listArray (1,length l) l) l2 :: [UArray Int Int]
p...Here is a test program (file name prgSrc.hs):
```
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i <- [1..5000000] ]
let l3 = map (\l -> listArray (1,length l) l) l2 :: [UArray Int Int]
print $ accumulate l3 0
accumulate [] rv = rv
accumulate (h:t) rv =
let nextRv = (rv + sum (elems h)) in
accumulate t $! nextRv
```
I used ghc 7.0.3-2 on archlinux, 64 bit version.
I created it only to check how much memory short unboxed arrays consume.
Thanks to the "$!" call at the last line of the "accumulate" function there should not be any stack overflow.
When I compile with these options:\[\[BR\]\]
*ghc --make prgSrc.hs\[\[BR\]\]
ghc -O2 --make prgSrc.hs\[\[BR\]\]
ghc -prof -auto-all -caf-all --make prgSrc.hs\[\[BR\]\]*
then there is no problem.
But when I compile with these options:\[\[BR\]\]
*ghc -O2 -prof -auto-all -caf-all --make prgSrc.hs\[\[BR\]\]*
then the program runs out of stack.
This indicates that there is a bug while compiling "$!" in an optimized profiling version of this program.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"optimized profiled version of a program incorectly compiles $!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["optimization","profiling","stricness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a test program (file name prgSrc.hs):\r\n\r\n{{{\r\nimport Data.Array.Unboxed\r\n\r\nmain = do\r\n let l1 = [1..10] :: [Int]\r\n let l2 = [ map (i+) l1 | i <- [1..5000000] ]\r\n let l3 = map (\\l -> listArray (1,length l) l) l2 :: [UArray Int Int]\r\n print $ accumulate l3 0\r\n\r\naccumulate [] rv = rv\r\naccumulate (h:t) rv =\r\n let nextRv = (rv + sum (elems h)) in\r\n accumulate t $! nextRv\r\n}}}\r\n\r\nI used ghc 7.0.3-2 on archlinux, 64 bit version.\r\nI created it only to check how much memory short unboxed arrays consume.\r\nThanks to the \"$!\" call at the last line of the \"accumulate\" function there should not be any stack overflow.\r\n\r\nWhen I compile with these options:[[BR]]\r\n''ghc --make prgSrc.hs[[BR]]\r\nghc -O2 --make prgSrc.hs[[BR]]\r\nghc -prof -auto-all -caf-all --make prgSrc.hs[[BR]]''\r\nthen there is no problem.\r\n\r\nBut when I compile with these options:[[BR]]\r\n''ghc -O2 -prof -auto-all -caf-all --make prgSrc.hs[[BR]]''\r\nthen the program runs out of stack.\r\n\r\nThis indicates that there is a bug while compiling \"$!\" in an optimized profiling version of this program.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5280System.Random commits (rand `mod` base) error.2019-07-07T18:56:05ZrrnewtonSystem.Random commits (rand `mod` base) error.You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and bas...You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and base being `10`.
In the function `System.Random.randomIvalInteger` you can see the same thing happening.
The only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.
This strategy appears to be used by GMP's mpz_urandomm function:
> http://gmplib.org/manual/Integer-Random-Numbers.html\#Integer-Random-Numbers
The file `urandomm.c` has the code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Random commits (rand `mod` base) error.","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rrnewton"},"version":"7.0.3","keywords":["base","mod","random"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You have probably at some point come across the C code \"{{{rand() % base}}}\"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine {{{rand()}}} producing numbers in say `[0,15)` and base being `10`.\r\n\r\nIn the function `System.Random.randomIvalInteger` you can see the same thing happening. \r\n\r\nThe only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.\r\n\r\nThis strategy appears to be used by GMP's mpz_urandomm function:\r\n\r\n http://gmplib.org/manual/Integer-Random-Numbers.html#Integer-Random-Numbers\r\n\r\nThe file `urandomm.c` has the code.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1rrnewtonrrnewtonhttps://gitlab.haskell.org/ghc/ghc/-/issues/5279numericEnumFromThen breaks standard behaviour in presence of ⊥2019-07-07T18:56:05ZehirdnumericEnumFromThen breaks standard behaviour in presence of ⊥Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:
```
numericEnumFromThen n m = iterate (+(m-n)) n
```
but GHC has:
```
numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFr...Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:
```
numericEnumFromThen n m = iterate (+(m-n)) n
```
but GHC has:
```
numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n))
```
The standard evaluation of `numericEnumFromThen 0.0 undefined` is equivalent to `0.0 : repeat undefined`, but GHC evaluates it as `undefined`:
```
> Prelude> [0.0, undefined..]
*** Exception: Prelude.undefined
```
So unfortunately, this optimisation changes semantics in violation of the Report.
`numericEnumFrom` also suffers from this issue; the evaluation of `numericEnumFrom undefined` should be equivalent to `repeat undefined`, but GHC evaluates it as `undefined`. This is a more minor issue, however. :)
(Tested with 7.0.3 and whatever version lambdabot uses on freenode.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"numericEnumFromThen breaks standard behaviour in presence of ⊥","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:\r\n\r\n{{{\r\nnumericEnumFromThen n m = iterate (+(m-n)) n\r\n}}}\r\n\r\nbut GHC has:\r\n\r\n{{{\r\nnumericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n))\r\n}}}\r\n\r\nThe standard evaluation of `numericEnumFromThen 0.0 undefined` is equivalent to `0.0 : repeat undefined`, but GHC evaluates it as `undefined`:\r\n\r\n{{{\r\n> Prelude> [0.0, undefined..]\r\n*** Exception: Prelude.undefined\r\n}}}\r\n\r\nSo unfortunately, this optimisation changes semantics in violation of the Report.\r\n\r\n`numericEnumFrom` also suffers from this issue; the evaluation of `numericEnumFrom undefined` should be equivalent to `repeat undefined`, but GHC evaluates it as `undefined`. This is a more minor issue, however. :)\r\n\r\n(Tested with 7.0.3 and whatever version lambdabot uses on freenode.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5278System.Random.randomIvalInteger makes invalid assumptions about RandomGen2019-07-07T18:56:05ZrrnewtonSystem.Random.randomIvalInteger makes invalid assumptions about RandomGenThe existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`.
For example, the following `RandomGen` produces only zeros and ones, but should be ...The existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`.
For example, the following `RandomGen` produces only zeros and ones, but should be legitimate:
```
import System.Random
data BinRNG = BinRNG StdGen
instance RandomGen BinRNG where
next (BinRNG g) = (x `mod` 2, BinRNG g')
where (x,g') = next g
split (BinRNG g) = (BinRNG g1, BinRNG g2)
where (g1,g2) = split g
genRange _ = (0,1)
ls :: [Int]
ls = randoms (BinRNG$ mkStdGen 38388)
main = print $ take 20 ls
```
But `System.Random.randomIvalInteger` makes invalid assumptions about the amount of randomness produced by `next`. (Specifically, assuming that it creates the same amount as `StdGen`.) Thus, the above program will create an output with only a couple of unique ints (rather than 2\^64).
For example:
```
[4611734781337924537,4611734781337924537,-9223323645458902796,
-9223323645458902797,4611734783485408099,4611734783485408098,
-9223323645458902796,-9223323647606386357,4611734781337924538,
-9223323645458902796,-9223323645458902797,
-9223323647606386357,4611734783485408098,4611734783485408098,
-9223323647606386357,4611734781337924538,4611734781337924537,
-9223323645458902796,4611734783485408099,4611734781337924538]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Random.randomIvalInteger makes invalid assumptions about RandomGen","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rrnewton"},"version":"7.0.3","keywords":["assumption","incorrect"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`. \r\n\r\nFor example, the following `RandomGen` produces only zeros and ones, but should be legitimate:\r\n\r\n{{{\r\nimport System.Random\r\n\r\ndata BinRNG = BinRNG StdGen\r\ninstance RandomGen BinRNG where \r\n next (BinRNG g) = (x `mod` 2, BinRNG g')\r\n where (x,g') = next g\r\n split (BinRNG g) = (BinRNG g1, BinRNG g2)\r\n where (g1,g2) = split g\r\n genRange _ = (0,1)\r\n\r\nls :: [Int]\r\nls = randoms (BinRNG$ mkStdGen 38388)\r\n\r\nmain = print $ take 20 ls\r\n}}}\r\n\r\nBut `System.Random.randomIvalInteger` makes invalid assumptions about the amount of randomness produced by `next`. (Specifically, assuming that it creates the same amount as `StdGen`.) Thus, the above program will create an output with only a couple of unique ints (rather than 2^64). \r\n\r\nFor example:\r\n\r\n{{{\r\n[4611734781337924537,4611734781337924537,-9223323645458902796,\r\n-9223323645458902797,4611734783485408099,4611734783485408098,\r\n-9223323645458902796,-9223323647606386357,4611734781337924538,\r\n-9223323645458902796,-9223323645458902797,\r\n-9223323647606386357,4611734783485408098,4611734783485408098,\r\n-9223323647606386357,4611734781337924538,4611734781337924537,\r\n-9223323645458902796,4611734783485408099,4611734781337924538]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/5257Calling fail on a UTF-8 encoded string (in file) causes garbage to be printed2019-07-07T18:56:10Zanthony.de.almeida.lopesCalling fail on a UTF-8 encoded string (in file) causes garbage to be printedFor example,
```
guerrilla@delta:/tmp/foo$ cat Test.hs
module Main where
main :: IO ()
main =
do
putStrLn "μ"
fail "μ"
guerrilla@delta:/tmp/foo$ ./Test
μ
Test: user error (�)
guerrilla@delta:/tmp/foo$ ./Test 2>&1 ...For example,
```
guerrilla@delta:/tmp/foo$ cat Test.hs
module Main where
main :: IO ()
main =
do
putStrLn "μ"
fail "μ"
guerrilla@delta:/tmp/foo$ ./Test
μ
Test: user error (�)
guerrilla@delta:/tmp/foo$ ./Test 2>&1 | xxd
0000000: cebc 0a54 6573 743a 2075 7365 7220 6572 ...Test: user er
0000010: 726f 7220 28bc 290a ror (.).
```
Using either encodeString or writing it in escaped hexidecimal does work.7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5212waitForProcess: does not exist (No child processes)2019-07-07T18:56:24ZChris DonewaitForProcess: does not exist (No child processes)I have this error when launching a program on our REHL prod machine.
```
waitForProcess: does not exist (No child processes)
```
This is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubu...I have this error when launching a program on our REHL prod machine.
```
waitForProcess: does not exist (No child processes)
```
This is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubuntu machine. If I re-implement `readProcess` with the same source but remove `waitForProcess` line, I do get standard output. Launching the program is successful.
The problem stems from `waitForProcess` expecting a process and somehow there isn't one. I didn't think this would be a problem, because `waitForProcess` itself doesn't throw such an exception, and it \*does\* handle the process having ended (of course), which is trivial to confirm locally:
```
λ> (inh,outh,_,pid) <- createProcess (proc "date" [])
Tue May 24 11:19:59 CEST 2011
λ> waitForProcess pid
ExitSuccess
λ>
```
So perhaps it's in `withProcessHandle`, which I don't have access to in the Haddock docs. I don't really know what would cause this error. Ideas?
We're using GHC 6.12.3 (I know, not recent). I'd provide a test-case but I can't even reproduce it on my own machine. I don't have direct shell access to the prod machine. The test-case would essentially be "use readProcess", anyway.
I can assign this to me and I'll see if the problem persists when we upgrade to GHC7. FWIW if you want to reproduce the exact case I tried, here it is:
```
readProcess "pdfinfo" ["--help"] ""
```
```
$ pdfinfo -v
pdfinfo version 3.00
Copyright 1996-2004 Glyph & Cog, LLC
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"waitForProcess: does not exist (No child processes)","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chrisdone"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have this error when launching a program on our REHL prod machine.\r\n\r\n{{{\r\nwaitForProcess: does not exist (No child processes)\r\n}}}\r\n\r\nThis is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubuntu machine. If I re-implement `readProcess` with the same source but remove `waitForProcess` line, I do get standard output. Launching the program is successful.\r\n\r\nThe problem stems from `waitForProcess` expecting a process and somehow there isn't one. I didn't think this would be a problem, because `waitForProcess` itself doesn't throw such an exception, and it *does* handle the process having ended (of course), which is trivial to confirm locally:\r\n\r\n{{{\r\nλ> (inh,outh,_,pid) <- createProcess (proc \"date\" [])\r\nTue May 24 11:19:59 CEST 2011\r\nλ> waitForProcess pid\r\nExitSuccess\r\nλ>\r\n}}}\r\n\r\nSo perhaps it's in `withProcessHandle`, which I don't have access to in the Haddock docs. I don't really know what would cause this error. Ideas?\r\n\r\nWe're using GHC 6.12.3 (I know, not recent). I'd provide a test-case but I can't even reproduce it on my own machine. I don't have direct shell access to the prod machine. The test-case would essentially be \"use readProcess\", anyway.\r\n\r\nI can assign this to me and I'll see if the problem persists when we upgrade to GHC7. FWIW if you want to reproduce the exact case I tried, here it is:\r\n\r\n{{{\r\nreadProcess \"pdfinfo\" [\"--help\"] \"\"\r\n}}}\r\n\r\n{{{\r\n$ pdfinfo -v\r\npdfinfo version 3.00\r\nCopyright 1996-2004 Glyph & Cog, LLC\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5166Wrong calculation with Int642019-07-07T18:56:37ZmalphunctionWrong calculation with Int64Let's multiply 1524503639859200000 on 13:
```
$ ghci
Prelude> import Data.Int
Prelude Data.Int> 1524503639859200000 * 13
19818547318169600000 -- that's OK!
Prelude Data.Int> (1524503639859200000::Int64)*(13::Int64)
1371803244460048384 -...Let's multiply 1524503639859200000 on 13:
```
$ ghci
Prelude> import Data.Int
Prelude Data.Int> 1524503639859200000 * 13
19818547318169600000 -- that's OK!
Prelude Data.Int> (1524503639859200000::Int64)*(13::Int64)
1371803244460048384 -- FAIL!!!!!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| 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":"Wrong calculation with Int64","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Let's multiply 1524503639859200000 on 13:\r\n\r\n{{{\r\n$ ghci\r\nPrelude> import Data.Int\r\nPrelude Data.Int> 1524503639859200000 * 13\r\n19818547318169600000 -- that's OK!\r\nPrelude Data.Int> (1524503639859200000::Int64)*(13::Int64)\r\n1371803244460048384 -- FAIL!!!!!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5129"evaluate" optimized away2023-12-15T20:11:41Zdons"evaluate" optimized awayReported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exc...Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.
```
import Control.Exception
import Test.HUnit
throwIfNegative :: Int -> String
throwIfNegative n | n < 0 = error "negative"
| otherwise = "no worries"
{-# NOINLINE throwIfNegative #-}
case_negative =
handleJust errorCalls (const $ return ()) $ do
evaluate $ throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
main = runTestTT $ TestCase case_negative
```
Looking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.
Using seq instead of evaluate is happy enough:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
throwIfNegative (-1) `seq` assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
or a bang pattern:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
let !x = throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
Possibly related to #2273
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"\"evaluate\" optimized away","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["evaluate","seq,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit\r\n\r\nWith optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.\r\n\r\n{{{\r\nimport Control.Exception\r\nimport Test.HUnit\r\n\r\nthrowIfNegative :: Int -> String\r\nthrowIfNegative n | n < 0 = error \"negative\"\r\n | otherwise = \"no worries\"\r\n{-# NOINLINE throwIfNegative #-}\r\n\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n evaluate $ throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n\r\nmain = runTestTT $ TestCase case_negative\r\n}}}\r\n\r\nLooking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.\r\n\r\nUsing seq instead of evaluate is happy enough:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n throwIfNegative (-1) `seq` assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nor a bang pattern:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n let !x = throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nPossibly related to #2273","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5118Numeric.floatToDigits fails for large floatRange2019-07-07T18:56:50ZClaudiusMaximusNumeric.floatToDigits fails for large floatRangeI tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):
```
data HugeFloat = HugeFloat Integer Int
```
Mainly as an exercise to see how much slower it would be, but ...I tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):
```
data HugeFloat = HugeFloat Integer Int
```
Mainly as an exercise to see how much slower it would be, but got failures trying to print the values (ghci would consume all available memory and be rather unresponsive w.r.t. ctrl-C input).
Changing this line in my RealFloat instance from:
```
floatRange _ = (minBound, maxBound) -- fails
```
to:
```
floatRange _ = (minBound `div` 2, maxBound `div` 2) -- works
```
made the non-termination failures seemingly disappear.
With attached code, ghci fails if I type:
```
> 771 :: F1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | claudiusmaximus@goto10.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Numeric.floatToDigits fails for large floatRange","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["claudiusmaximus@goto10.org"],"type":"Bug","description":"I tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):\r\n{{{\r\ndata HugeFloat = HugeFloat Integer Int\r\n}}}\r\nMainly as an exercise to see how much slower it would be, but got failures trying to print the values (ghci would consume all available memory and be rather unresponsive w.r.t. ctrl-C input).\r\n\r\nChanging this line in my RealFloat instance from:\r\n{{{\r\n floatRange _ = (minBound, maxBound) -- fails\r\n}}}\r\nto:\r\n{{{\r\n floatRange _ = (minBound `div` 2, maxBound `div` 2) -- works\r\n}}}\r\nmade the non-termination failures seemingly disappear.\r\n\r\nWith attached code, ghci fails if I type:\r\n{{{\r\n > 771 :: F1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5114-with-rtsopts, ghc_rts_opts not honoured2019-07-07T18:56:50Zguest-with-rtsopts, ghc_rts_opts not honouredusing -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with "Most RTS options are disabled. Link with -rtsopts to enable them." I don't have the environment variable GHCRTS.
```
$ echo 'main = print (fol...using -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with "Most RTS options are disabled. Link with -rtsopts to enable them." I don't have the environment variable GHCRTS.
```
$ echo 'main = print (foldl1 (+) [1..100000])' > main.hs
$ ghc --make -with-rtsopts='-K1m' main.hs
$ ./main
main: Most RTS options are disabled. Link with -rtsopts to enable them.
```
```
$ rm main main.hi main.o
$ echo 'char *ghc_rts_opts = "-K1m";' > ro.c
$ ghc --make main.hs ro.c
$ ./main
main: Most RTS options are disabled. Link with -rtsopts to enable them.
```
I obtained ghc from the generic binary tarball for linux x86 32-bit.
This is present in both 7.0.2 and 7.0.3. I don't know about 7.0.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | trebla@vex.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-with-rtsopts, ghc_rts_opts not honoured","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["trebla@vex.net"],"type":"Bug","description":"using -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with \"Most RTS options are disabled. Link with -rtsopts to enable them.\" I don't have the environment variable GHCRTS.\r\n\r\n{{{\r\n$ echo 'main = print (foldl1 (+) [1..100000])' > main.hs\r\n$ ghc --make -with-rtsopts='-K1m' main.hs\r\n$ ./main\r\nmain: Most RTS options are disabled. Link with -rtsopts to enable them.\r\n}}}\r\n\r\n{{{\r\n$ rm main main.hi main.o\r\n$ echo 'char *ghc_rts_opts = \"-K1m\";' > ro.c\r\n$ ghc --make main.hs ro.c\r\n$ ./main\r\nmain: Most RTS options are disabled. Link with -rtsopts to enable them.\r\n}}}\r\n\r\nI obtained ghc from the generic binary tarball for linux x86 32-bit.\r\n\r\nThis is present in both 7.0.2 and 7.0.3. I don't know about 7.0.1.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5088TextEncoding iconv instances are shared between threads2019-07-07T18:56:57ZbatterseapowerTextEncoding iconv instances are shared between threadsThe icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.
However, we currently don't take any measures to prevent t...The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.
However, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding in future -- even if those uses occur on different threads!
This could lead to arbitrarily strange heisenbugs depending on the iconv implementation.
Either we should:
1. Make it clear that the user should recreate a TextEncoding anew for every use site
1. (Better), elaborate the TextEncoding interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"TextEncoding iconv instances are shared between threads","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.\r\n\r\nHowever, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding in future -- even if those uses occur on different threads!\r\n\r\nThis could lead to arbitrarily strange heisenbugs depending on the iconv implementation.\r\n\r\nEither we should:\r\n\r\n 1. Make it clear that the user should recreate a TextEncoding anew for every use site\r\n\r\n 2. (Better), elaborate the TextEncoding interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5048Wrong SrcSpan on AbsBinds2019-07-07T18:57:11ZJPMoresmauWrong SrcSpan on AbsBindsI have the following code:
```
{-# LANGUAGE RankNTypes #-}
module Folder1.ForAll where
import Data.Char
fun :: t -> [Char] -> [Char]
fun _=reverse . map toUpper
```
And the `TypecheckedSource` gives me something like (using the
`gh...I have the following code:
```
{-# LANGUAGE RankNTypes #-}
module Folder1.ForAll where
import Data.Char
fun :: t -> [Char] -> [Char]
fun _=reverse . map toUpper
```
And the `TypecheckedSource` gives me something like (using the
`ghc-syb-utils` package to dump it:)
```
{Bag(Located (HsBind Var)):
[
(L {src\Folder1\ForAll.hs:8:1-29}
(AbsBinds
[{Var: t}]
[]
[
((,,,)
[{Var: t}] {Var: Folder1.ForAll.fun} {Var: fun}
(SpecPrags
[]))]
({abstract:TcEvBinds}) {Bag(Located (HsBind Var)):
[
(L {src\Folder1\ForAll.hs:9:1-27}
(FunBind
(L {src\Folder1\ForAll.hs:9:1-3} {Var: fun})
(False)
(MatchGroup
```
The issue here is that the `AbsBinds` has a `SrcSpan` that only covers the type signature, and not the rest of the code, hence (I think) we never go down the contents, and Scion cannot resolve anything when a user asks it to.
If the type signature is not present, the problem doesn't occur: the
`AbsBinds` location covers all the source code.
If the type signature is present but without any type variable, there is no `AbsBinds` and no problem (the `FunBind` covers all the code).7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4956threadDelay behavior 64-bit mac os x2019-07-07T18:57:37ZperikovthreadDelay behavior 64-bit mac os xthreadDelay 1000000
```
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
```
to reproduce:
fire up ghci
```
import Control.Concurrent
threadDela...threadDelay 1000000
```
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
```
to reproduce:
fire up ghci
```
import Control.Concurrent
threadDelay 1000000
```7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4911GHC 7 does not process Handle correctly2019-07-07T18:57:57Zkazu-yamamotoGHC 7 does not process Handle correctlyCompile the following code:
```
module Main where
import qualified Data.ByteString.Lazy.Char8 as L
main :: IO ()
main = do
getLine >>= putStrLn
L.getContents >>= L.putStr
```
Let's call this binary "foo". If you compile this ...Compile the following code:
```
module Main where
import qualified Data.ByteString.Lazy.Char8 as L
main :: IO ()
main = do
getLine >>= putStrLn
L.getContents >>= L.putStr
```
Let's call this binary "foo". If you compile this with GHC 6.12.3, the following command work well. That is, the entire of "any-file" is displayed.
```
% foo < any-file
```
However, if you compile this with GHC 7.0.1 or later, the command displays only the first line of "any-file".
This can be re-produced on Linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7 does not process Handle correctly","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compile the following code:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport qualified Data.ByteString.Lazy.Char8 as L\r\n\r\nmain :: IO ()\r\nmain = do\r\n getLine >>= putStrLn\r\n L.getContents >>= L.putStr\r\n}}}\r\n\r\nLet's call this binary \"foo\". If you compile this with GHC 6.12.3, the following command work well. That is, the entire of \"any-file\" is displayed.\r\n\r\n{{{\r\n% foo < any-file\r\n}}}\r\n\r\nHowever, if you compile this with GHC 7.0.1 or later, the command displays only the first line of \"any-file\".\r\n\r\nThis can be re-produced on Linux.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4884registerPackage fails with multiple command line --package-conf= flags2019-07-07T18:58:04Zr6registerPackage fails with multiple command line --package-conf= flagsin registerPackage the database to operate on is filtered, whereas the databases to validate are \*truncated\*. The trucation can be seen in the code:
> let truncated_stack = dropWhile ((/= to_modify).location) db_stack
> -- truncate ...in registerPackage the database to operate on is filtered, whereas the databases to validate are \*truncated\*. The trucation can be seen in the code:
> let truncated_stack = dropWhile ((/= to_modify).location) db_stack
> -- truncate the stack for validation, because we don't allow
> -- packages lower in the stack to refer to those higher up.
> validatePackageConfig pkg truncated_stack auto_ghci_libs update force
notice the use of dropWhile instead of filter. The problem is that if I want to update a package with a command with multiple --package-conf= parameters, then these parameters get ignored during validation and if the package being installed depends on the packages in these databases, the installation will fail (unless --force is used). For example if you run the command
> ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf
then the command will fail with the error ""something" doesn't exist (use --force to override)" if newPkg.conf depends on something in on of myPkgs.
In fact, with the above command, the truncated_stack consists of only two packages: \[the-user-pkg,the-global-pkg\].
I think the fix is to use a filter instead of dropWhile, but maybe there is some purpose behind using dropWhile. In any case a bug does exist because the above ghc-pkg command should succeed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"registerPackage fails with multiple command line --package-conf= flags","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"in registerPackage the database to operate on is filtered, whereas the databases to validate are *truncated*. The trucation can be seen in the code:\r\n\r\n let truncated_stack = dropWhile ((/= to_modify).location) db_stack\r\n -- truncate the stack for validation, because we don't allow\r\n -- packages lower in the stack to refer to those higher up.\r\n validatePackageConfig pkg truncated_stack auto_ghci_libs update force\r\n\r\nnotice the use of dropWhile instead of filter. The problem is that if I want to update a package with a command with multiple --package-conf= parameters, then these parameters get ignored during validation and if the package being installed depends on the packages in these databases, the installation will fail (unless --force is used). For example if you run the command\r\n\r\n ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf\r\n\r\nthen the command will fail with the error \"\"something\" doesn't exist (use --force to override)\" if newPkg.conf depends on something in on of myPkgs.\r\n\r\nIn fact, with the above command, the truncated_stack consists of only two packages: [the-user-pkg,the-global-pkg].\r\n\r\nI think the fix is to use a filter instead of dropWhile, but maybe there is some purpose behind using dropWhile. In any case a bug does exist because the above ghc-pkg command should succeed.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4855Debug.Trace.trace mangles Unicode strings2019-07-07T18:58:11ZAnders KaseorgDebug.Trace.trace mangles Unicode strings```
Prelude Debug.Trace> trace "Σὲ γνωρίζω ἀπὸ τὴν κόψη" ()
�r ����w��
()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version |...```
Prelude Debug.Trace> trace "Σὲ γνωρίζω ἀπὸ τὴν κόψη" ()
�r ����w��
()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"Debug.Trace.trace mangles Unicode strings","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nPrelude Debug.Trace> trace \"Σὲ γνωρίζω ἀπὸ τὴν κόψη\" ()\r\n�r ����w�� \r\n()\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4844createDirectoryIfMissing fails to create directory if compiled2019-07-07T18:58:15ZNeil MitchellcreateDirectoryIfMissing fails to create directory if compiledI'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.
Given the ...I'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.
Given the code:
```
module Main where
import System.Directory
main = do
print 1
createDirectoryIfMissing True "hello"
print 2
createDirectoryIfMissing True "hello"
```
I can use `runhaskell`:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.1.20101215
$ runhaskell Main
1
2
$ ghc --make Main
$ main
Main.exe: CreateDirectory "hello": invalid argument (Cannot create a file when that file already exists.)
```
I would expect the `runhaskell` behaviour both times. I have tried this with GHC 6.12.3, where I'm sure I used to rely on this behaviour, and it's broken there too. Is my system going crazy?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"createDirectoryIfMissing fails to create directory if compiled","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.\r\n\r\nGiven the code:\r\n\r\n{{{\r\nmodule Main where\r\nimport System.Directory\r\nmain = do\r\n print 1\r\n createDirectoryIfMissing True \"hello\"\r\n print 2\r\n createDirectoryIfMissing True \"hello\"\r\n}}}\r\n\r\nI can use {{{runhaskell}}}:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.1.20101215\r\n$ runhaskell Main\r\n1\r\n2\r\n$ ghc --make Main\r\n$ main\r\nMain.exe: CreateDirectory \"hello\": invalid argument (Cannot create a file when that file already exists.)\r\n}}}\r\n\r\nI would expect the {{{runhaskell}}} behaviour both times. I have tried this with GHC 6.12.3, where I'm sure I used to rely on this behaviour, and it's broken there too. Is my system going crazy?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4809MonoLocalBinds and type classes cause infinite loop2019-07-07T18:58:27ZJeremyShawMonoLocalBinds and type classes cause infinite loopThe following program gets stuck in a loop and prints no output when run:
```
{-# LANGUAGE MonoLocalBinds #-}
module Main where
import IdentityT (IdentityT(..), XML, runIdentityT)
import XMLGenerator (XMLGenT(..), XMLGen(genElement), C...The following program gets stuck in a loop and prints no output when run:
```
{-# LANGUAGE MonoLocalBinds #-}
module Main where
import IdentityT (IdentityT(..), XML, runIdentityT)
import XMLGenerator (XMLGenT(..), XMLGen(genElement), Child, EmbedAsChild(..), unXMLGenT)
import System.IO (BufferMode(..), hSetBuffering, stdout)
page :: XMLGenT (IdentityT IO) XML
page = genElement (Nothing, "ul") [] [ asChild (asChild "foo")]
where
-- item :: XMLGenT (IdentityT IO) [Child (IdentityT IO)]
item = (asChild $ asChild (return "bar" :: XMLGenT (IdentityT IO) String))
main :: IO ()
main =
do hSetBuffering stdout LineBuffering
r <- runIdentityT (unXMLGenT page)
print r
```
I believe this is due to a compiler bug. There are five things you can do to make it run successfully (i.e., not loop) -- none of which ought to have an effect. Doing any one of the five works though.
Note that 'item' in the 'page' where clause is not actually used anywhere, but three of the five things involve changes to that clause.
1. remove the 'where' clause in 'page' entirely. After all it is not needed.
1. uncomment the type signature for 'item'
1. remove one of the calls to 'asChild' in item.
1. remove one of the calls to 'asChild' in page.
1. remove the MonoLocalBinds pragma.
I considered the possibility that the loop might be cause by asChild calls forming a loop depending on how the types are inferred. However, each call to asChild does a putStrLn. Since there is no output when the loop occurs, I believe that the execution is not even getting that far.
Doing --dump-ds, does show the loop. But I could figure out anything useful from seeing the loop in the desugared code.
The looping seems to occur whether compiled or using GHCi and at all optimization levels.
This bug prevents HSP, and therefore Happstack and SeeReason from moving to GHC 7.
I have attached 3 files. The above file, IdentityT.hs and XMLGenerator.hs. The latter two come from HSP/Happstack, but have been stripped down to the bare essentials.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"MonoLocalBinds and type classes cause infinite loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program gets stuck in a loop and prints no output when run:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE MonoLocalBinds #-}\r\nmodule Main where\r\n\r\nimport IdentityT (IdentityT(..), XML, runIdentityT)\r\nimport XMLGenerator (XMLGenT(..), XMLGen(genElement), Child, EmbedAsChild(..), unXMLGenT)\r\nimport System.IO (BufferMode(..), hSetBuffering, stdout)\r\n\r\npage :: XMLGenT (IdentityT IO) XML\r\npage = genElement (Nothing, \"ul\") [] [ asChild (asChild \"foo\")]\r\n where\r\n-- item :: XMLGenT (IdentityT IO) [Child (IdentityT IO)] \r\n item = (asChild $ asChild (return \"bar\" :: XMLGenT (IdentityT IO) String))\r\n\r\nmain :: IO ()\r\nmain =\r\n do hSetBuffering stdout LineBuffering\r\n r <- runIdentityT (unXMLGenT page)\r\n print r\r\n}}}\r\n\r\nI believe this is due to a compiler bug. There are five things you can do to make it run successfully (i.e., not loop) -- none of which ought to have an effect. Doing any one of the five works though.\r\n\r\nNote that 'item' in the 'page' where clause is not actually used anywhere, but three of the five things involve changes to that clause.\r\n\r\n1. remove the 'where' clause in 'page' entirely. After all it is not needed.\r\n\r\n2. uncomment the type signature for 'item'\r\n\r\n3. remove one of the calls to 'asChild' in item.\r\n\r\n4. remove one of the calls to 'asChild' in page. \r\n\r\n5. remove the MonoLocalBinds pragma.\r\n\r\nI considered the possibility that the loop might be cause by asChild calls forming a loop depending on how the types are inferred. However, each call to asChild does a putStrLn. Since there is no output when the loop occurs, I believe that the execution is not even getting that far. \r\n\r\nDoing --dump-ds, does show the loop. But I could figure out anything useful from seeing the loop in the desugared code.\r\n\r\nThe looping seems to occur whether compiled or using GHCi and at all optimization levels.\r\n\r\nThis bug prevents HSP, and therefore Happstack and SeeReason from moving to GHC 7.\r\n\r\nI have attached 3 files. The above file, IdentityT.hs and XMLGenerator.hs. The latter two come from HSP/Happstack, but have been stripped down to the bare essentials.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4807Data instance for Data.Map is incomplete2019-07-07T18:58:27ZsclvData instance for Data.Map is incompleteThere's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.
Observe:
```
Prelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Dat...There's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.
Observe:
```
Prelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))
Just (Just (fromList []))
Prelude Data.Data Data.Generics Data.Map> dataCast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))
Nothing
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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 instance for Data.Map is incomplete","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.\r\n\r\nObserve: \r\n\r\n{{{\r\nPrelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))\r\nJust (Just (fromList []))\r\nPrelude Data.Data Data.Generics Data.Map> dataCast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))\r\nNothing\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->