GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:51:00Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7172GHCi :issafe command doesn't work2019-07-07T18:51:00ZdtereiGHCi :issafe command doesn't workIn HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.
I will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.
<deta...In HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.
I will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1-rc1 |
| 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":"GHCi :issafe command doesn't work","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"7.6.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.\r\n\r\nI will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7215miscompilation due to broken interface hash2019-07-07T18:50:50Ztakano-akiomiscompilation due to broken interface hashThe following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)
```
rm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o
ghc=ghc
echo 'module MyBool wher...The following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)
```
rm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o
ghc=ghc
echo 'module MyBool where data MyBool = MyFalse | MyTrue deriving Show' > MyBool.hs
echo 'module Foo where import MyBool; foo = MyFalse' > Foo.hs
echo 'import Foo; main = print foo' > main.hs
$ghc -c -O2 MyBool.hs
$ghc -c -O2 Foo.hs
$ghc -O2 main.hs
./main
echo 'module Foo where import MyBool; foo = MyTrue' > Foo.hs
$ghc -c -O2 Foo.hs
$ghc -O2 main.hs
./main
```
The issue seems to be that the second version of Foo.hs gets the same interface hash as the old one. This stops GHC from updating Foo.hi, which contains an outdated unfolding.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"miscompilation due to broken interface hash","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)\r\n\r\n{{{\r\nrm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o\r\n\r\nghc=ghc\r\necho 'module MyBool where data MyBool = MyFalse | MyTrue deriving Show' > MyBool.hs\r\necho 'module Foo where import MyBool; foo = MyFalse' > Foo.hs\r\necho 'import Foo; main = print foo' > main.hs\r\n$ghc -c -O2 MyBool.hs\r\n$ghc -c -O2 Foo.hs\r\n$ghc -O2 main.hs\r\n./main\r\necho 'module Foo where import MyBool; foo = MyTrue' > Foo.hs\r\n$ghc -c -O2 Foo.hs\r\n$ghc -O2 main.hs\r\n./main\r\n}}}\r\n\r\nThe issue seems to be that the second version of Foo.hs gets the same interface hash as the old one. This stops GHC from updating Foo.hi, which contains an outdated unfolding.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7270Incorrect optimization with Data.ByteString.append2019-07-07T18:50:34ZocheronIncorrect optimization with Data.ByteString.appendThe following program does not give the same result with -O2 and without:
```
import qualified Data.ByteString as B
main = let a = B.singleton 65 in print (func a a)
func y z = B.append r s
where
r = B.map (succ) x
s = B.map...The following program does not give the same result with -O2 and without:
```
import qualified Data.ByteString as B
main = let a = B.singleton 65 in print (func a a)
func y z = B.append r s
where
r = B.map (succ) x
s = B.map (succ . succ) x
x = B.append y z
```
Result observed with GHC 7.6.1 (bytestring-0.10.0.0):
```
$ ghc --make test -fforce-recomp && ./test
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
"BBCC"
$ ghc --make test -fforce-recomp -O2 && ./test
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
"CCCC"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.6.1 |
| 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":"Incorrect optimization with Data.ByteString.append","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program does not give the same result with -O2 and without:\r\n{{{\r\nimport qualified Data.ByteString as B\r\n\r\nmain = let a = B.singleton 65 in print (func a a)\r\n\r\nfunc y z = B.append r s\r\n where\r\n r = B.map (succ) x\r\n s = B.map (succ . succ) x\r\n x = B.append y z\r\n}}}\r\n\r\nResult observed with GHC 7.6.1 (bytestring-0.10.0.0):\r\n{{{\r\n$ ghc --make test -fforce-recomp && ./test\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n\"BBCC\"\r\n$ ghc --make test -fforce-recomp -O2 && ./test\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n\"CCCC\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/7325threadDelay mistreats minBound and maxBound in some configurations2019-07-07T18:50:14ZjoeyadamsthreadDelay mistreats minBound and maxBound in some configurationsthreadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([as seen in the async package](http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async....threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([as seen in the async package](http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently)):
```
forever (threadDelay maxBound)
```
On Linux (Ubuntu 10.04 64-bit) without -threaded, `threadDelay maxBound` returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:
```
import Control.Concurrent
import Control.Monad
main = forM_ [6244222868950683224..] $ \i -> do
print i
threadDelay i
```
threadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:
```
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
```
The bug usually appears, but if I run it like this:
```
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs
./threadDelay-maxBound
```
The bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.
On Windows without -threaded, `threadDelay maxBound` seems to work, but `threadDelay minBound` blocks rather than returning immediately.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay mistreats minBound and maxBound in some configurations","status":"New","operating_system":"Unknown/Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently as seen in the async package]):\r\n\r\n{{{\r\nforever (threadDelay maxBound)\r\n}}}\r\n\r\nOn Linux (Ubuntu 10.04 64-bit) without -threaded, {{{threadDelay maxBound}}} returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Monad\r\n\r\nmain = forM_ [6244222868950683224..] $ \\i -> do\r\n print i\r\n threadDelay i\r\n}}}\r\n\r\nthreadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:\r\n\r\n{{{\r\nghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound\r\n}}}\r\n\r\nThe bug usually appears, but if I run it like this:\r\n\r\n{{{\r\nghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs\r\n./threadDelay-maxBound\r\n}}}\r\n\r\nThe bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.\r\n\r\nOn Windows without -threaded, {{{threadDelay maxBound}}} seems to work, but {{{threadDelay minBound}}} blocks rather than returning immediately.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/7342Memory violation bug in System.Posix.Env.putEnv2019-07-07T18:50:10ZSimon Hengelsol@typeful.netMemory violation bug in System.Posix.Env.putEnv`putEnv` frees the marshaled string after calling `c_putenv`. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.
See [SUSv2](http://pubs.opengroup.org/onlinepubs/007908799/xsh/pu...`putEnv` frees the marshaled string after calling `c_putenv`. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.
See [SUSv2](http://pubs.opengroup.org/onlinepubs/007908799/xsh/putenv.html):
> 1. .. the string pointed to by string shall become part of the
>
> environment ...
The issue is reproducible with the following QC property:
```
import Test.QuickCheck
import Test.QuickCheck.Property
import System.Posix.Env
import Data.IORef
import qualified Data.Map as Map
import Control.Applicative
isValidKey :: String -> Bool
isValidKey k = '\NUL' `notElem` k && '=' `notElem` k && (not . null) k
isValidValue :: String -> Bool
isValidValue v = '\NUL' `notElem` v && (not . null) v
main :: IO ()
main = do
env' <- getEnvironment >>= newIORef . Map.fromList
quickCheck $ \k v -> isValidKey k ==> isValidValue v ==> morallyDubiousIOProperty $ do
putEnv (k ++ "=" ++ v)
modifyIORef env' (Map.insert k v)
(==) <$> readIORef env' <*> (Map.fromList <$> getEnvironment)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in System.Posix.Env.putEnv","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{putEnv}}} frees the marshaled string after calling {{{c_putenv}}}. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.\r\n\r\nSee [http://pubs.opengroup.org/onlinepubs/007908799/xsh/putenv.html SUSv2]:\r\n\r\n> ... the string pointed to by string shall become part of the\r\n> environment ...\r\n\r\nThe issue is reproducible with the following QC property:\r\n\r\n{{{\r\nimport Test.QuickCheck\r\nimport Test.QuickCheck.Property\r\nimport System.Posix.Env\r\nimport Data.IORef\r\nimport qualified Data.Map as Map\r\nimport Control.Applicative\r\n\r\nisValidKey :: String -> Bool\r\nisValidKey k = '\\NUL' `notElem` k && '=' `notElem` k && (not . null) k\r\n\r\nisValidValue :: String -> Bool\r\nisValidValue v = '\\NUL' `notElem` v && (not . null) v\r\n\r\nmain :: IO ()\r\nmain = do\r\n env' <- getEnvironment >>= newIORef . Map.fromList\r\n quickCheck $ \\k v -> isValidKey k ==> isValidValue v ==> morallyDubiousIOProperty $ do\r\n putEnv (k ++ \"=\" ++ v)\r\n modifyIORef env' (Map.insert k v)\r\n (==) <$> readIORef env' <*> (Map.fromList <$> getEnvironment)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://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/7399Test Posix004 fails in test-suite2019-07-07T18:49:54ZpaulhTest Posix004 fails in test-suiteAfter a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected f...After a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected failure for posix004(normal)
```7.8.1Edward Z. YangEdward Z. Yanghttps://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/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/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/7491getNumCapabilities uses n_capabilities instead of enabled_capabilities2019-07-07T18:49:31ZYurasgetNumCapabilities uses n_capabilities instead of enabled_capabilitiessetNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<details><summary>Trac metadata</summary>
| Trac field |...setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<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 | shumovichy@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getNumCapabilities uses n_capabilities instead of enabled_capabilities","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["shumovichy@gmail.com"],"type":"Bug","description":"setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7493STM and TVar report incorrect results2019-07-07T18:49:30ZparcsSTM and TVar report incorrect resultsOn Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.ST...On Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
import Control.Applicative
main = do
q <- newTQueueIO
atomically $ writeTQueue q True
atomically $ writeTQueue q False
forever $ do
xs <- atomically $ many $ readTQueue q
print xs
threadDelay 500000
```
I'd expect the output of the script to be:
```
[True,False]
[]
[]
...
```
However, that is not the case: the actual output of the script is:
```
[True,False]
[True,False]
[True,False]
...
```
If 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:
```
[True]
[]
[]
...
```
Which is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.
Is this considered a bug, or undocumented behavior of TQueue?
----
Bas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:
```
$ cat stmTest.hs
import Control.Concurrent.STM
main = do
x <- atomically $ do
t <- newTVar 1
writeTVar t 2
((readTVar t >> retry) `orElse` return ()) `orElse` return ()
readTVar t
print x
$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest
[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )
Linking stmTest ...
1
```
The program prints 1 when it should print 2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | v.dijk.bas@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM and TVar report incorrect results","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["v.dijk.bas@gmail.com"],"type":"Bug","description":"On Haskell Cafe, I posted:\r\n\r\nI'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Control.Applicative\r\n\r\nmain = do\r\n q <- newTQueueIO\r\n atomically $ writeTQueue q True\r\n atomically $ writeTQueue q False\r\n forever $ do\r\n xs <- atomically $ many $ readTQueue q\r\n print xs\r\n threadDelay 500000\r\n}}}\r\n\r\nI'd expect the output of the script to be:\r\n{{{\r\n[True,False]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nHowever, that is not the case: the actual output of the script is:\r\n{{{\r\n[True,False]\r\n[True,False]\r\n[True,False]\r\n...\r\n}}}\r\n\r\nIf 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:\r\n{{{\r\n[True]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nWhich is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.\r\n\r\nIs this considered a bug, or undocumented behavior of TQueue?\r\n\r\n----\r\n\r\nBas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:\r\n\r\n{{{\r\n$ cat stmTest.hs\r\nimport Control.Concurrent.STM\r\nmain = do\r\n x <- atomically $ do\r\n t <- newTVar 1\r\n writeTVar t 2\r\n ((readTVar t >> retry) `orElse` return ()) `orElse` return ()\r\n readTVar t\r\n print x\r\n\r\n$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest\r\n[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )\r\nLinking stmTest ...\r\n1\r\n}}}\r\n\r\nThe program prints 1 when it should print 2.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://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/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/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/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/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/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/7646resource busy (file is locked) with multi-threaded file ops2019-07-07T18:48:51ZStefanWehrresource busy (file is locked) with multi-threaded file opsThe sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use \*strict IO\*.
When compiled witho...The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use \*strict IO\*.
When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.
But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.
Tested under Mac OSX 10.8.2 and Linux.
Tested with both GHC 7.6.1 and 7.6.2.
I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| 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":"resource busy (file is locked) with multi-threaded file ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*.\r\n\r\nWhen compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.\r\n\r\nBut with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.\r\n\r\nTested under Mac OSX 10.8.2 and Linux.\r\nTested with both GHC 7.6.1 and 7.6.2.\r\n\r\nI could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.3Simon MarlowSimon Marlowhttps://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":[]} -->