GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:05:20Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3111Can't find DPH2019-07-07T19:05:20Zcolin-adamsCan't find DPHI added the following to the top of my module:
```
{-# LANGUAGE PArr, ParallelListComp #-}
{-# OPTIONS -fvectorise #-}
```
But when building I got:
```
GHC error in desugarer lookup in main:Board:
Failed to load interface for `Data....I added the following to the top of my module:
```
{-# LANGUAGE PArr, ParallelListComp #-}
{-# OPTIONS -fvectorise #-}
```
But when building I got:
```
GHC error in desugarer lookup in main:Board:
Failed to load interface for `Data.Array.Parallel.Lifted.PArray':
no package matching `dph-par' was found
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20090317 for x86_64-unknown-linux):
initDs IOEnv failure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I hadn't done anything in particular to try to install DPH, so this is probably a user error, but as the panic occurred, i felt duty-bound to report the bug as requested.6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3112GHCI Crashes on self referential local variable2019-07-07T19:05:20ZdvsGHCI Crashes on self referential local variable```
f :: Int -> Int
f x =
let p = x*x
in
let p = p*x
in p
```
Causes a segfault of GHCI on Windows XP Service Pack 2, and unbounded memory consumption on Linux. There is no output when the crash occurs, after inv...```
f :: Int -> Int
f x =
let p = x*x
in
let p = p*x
in p
```
Causes a segfault of GHCI on Windows XP Service Pack 2, and unbounded memory consumption on Linux. There is no output when the crash occurs, after invoking the function (for example f 7) it just immediately drops back to a command prompt in Windows. I would expect some sort of error message to be printed, perhaps \<loop\>, and then return gracefully to the GHCI prompt.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"GHCI Crashes on self referential local variable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nf :: Int -> Int\r\nf x = \r\n let p = x*x\r\n in \r\n let p = p*x\r\n in p\r\n}}}\r\n\r\nCauses a segfault of GHCI on Windows XP Service Pack 2, and unbounded memory consumption on Linux. There is no output when the crash occurs, after invoking the function (for example f 7) it just immediately drops back to a command prompt in Windows. I would expect some sort of error message to be printed, perhaps <loop>, and then return gracefully to the GHCI prompt. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3113-fdisambiguate-record-fields does not exist anymore2019-07-07T19:05:19Ziampure@gmail.com-fdisambiguate-record-fields does not exist anymoreghc: unrecognised flags: -fdisambiguate-record-fields and Haskell 98 regards all four as ambiguous, but with the -fdisambiguate-record-fields flag, GHC will accept the former two. =\> universe exploded.
It seems that either the document...ghc: unrecognised flags: -fdisambiguate-record-fields and Haskell 98 regards all four as ambiguous, but with the -fdisambiguate-record-fields flag, GHC will accept the former two. =\> universe exploded.
It seems that either the documentation is wrong or the implementation is wrong.
-XDisambiguateRecordFields is the new option. The documentation and man page should just be updated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fdisambiguate-record-fields does not exist anymore","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc: unrecognised flags: -fdisambiguate-record-fields and Haskell 98 regards all four as ambiguous, but with the -fdisambiguate-record-fields flag, GHC will accept the former two. => universe exploded. \r\n It seems that either the documentation is wrong or the implementation is wrong. \r\n -XDisambiguateRecordFields is the new option. The documentation and man page should just be updated.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3114"ghc -shared --make" gives panic2019-07-07T19:05:19ZMark_Spezzano"ghc -shared --make" gives panicI was just experimenting with the compiler options and for some reason I decided to stick -shared in there (it's not needed for compilation: ghc --make Teapot.hs does the trick). I got this error message:
```
C:\Users\Mark\workspace2\Op...I was just experimenting with the compiler options and for some reason I decided to stick -shared in there (it's not needed for compilation: ghc --make Teapot.hs does the trick). I got this error message:
```
C:\Users\Mark\workspace2\OpenGLPractice\src>ghc -shared --make Teapot.hs
[1 of 1] Compiling Main ( Teapot.hs, Teapot.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
link: GHC not built to link this way: LinkDynLib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3115mark ghc.cabal so that unsuspecting newbies don't try to edit it2019-07-07T19:05:19Znr@eecs.harvard.edumark ghc.cabal so that unsuspecting newbies don't try to edit itPlease change the configure/build system so that (a) ghc.cabal is not writable and (b) it contains a comment at the top saying that people wishing to add source files to the compiler should extend file ghc.cabal.in and re-run ../configur...Please change the configure/build system so that (a) ghc.cabal is not writable and (b) it contains a comment at the top saying that people wishing to add source files to the compiler should extend file ghc.cabal.in and re-run ../configure; they should *not* edit ghc.cabal directly.
I know of two people who have fallen into this pit; let's not have any more.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mark ghc.cabal so that unsuspecting newbies don't try to edit it","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Please change the configure/build system so that (a) ghc.cabal is not writable and (b) it contains a comment at the top saying that people wishing to add source files to the compiler should extend file ghc.cabal.in and re-run ../configure; they should ''not'' edit ghc.cabal directly.\r\n\r\nI know of two people who have fallen into this pit; let's not have any more.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3116missed opportunity for call-pattern specialisation2019-07-07T19:05:19Zduncanmissed opportunity for call-pattern specialisationWith strict `ByteString` an a simple tail recursive iteration pattern we get perfect code.
First the definitions:
```
data ByteString
= BS {-# UNPACK #-} !(ForeignPtr Word8) -- payload
{-# UNPACK #-} !Int ...With strict `ByteString` an a simple tail recursive iteration pattern we get perfect code.
First the definitions:
```
data ByteString
= BS {-# UNPACK #-} !(ForeignPtr Word8) -- payload
{-# UNPACK #-} !Int -- offset
{-# UNPACK #-} !Int -- length
null :: ByteString -> Bool
null (BS _ _ l) = l <= 0
tail :: ByteString -> ByteString
tail (BS p s l)
| l <= 0 = error "ByteString.tail: empty ByteString"
| otherwise = BS p (s+1) (l-1)
```
Now a trivial iteration pattern:
```
length :: ByteString -> Int
length = go 0
where
go !n bs | null bs = n
| otherwise = go (n+1) (tail bs)
```
Perfect core code (edited for clarity):
```
go :: Int# -> Addr# -> ForeignPtrContents
-> Int# -> Int# -> Int#
go = \n p fpc o l ->
case l <=# 0 of
False -> go (n +# 1) p fpc (o +# 1) (l -# 1)
True -> n
length :: ByteString -> GHC.Base.Int
length = \bs ->
case bs of
BS p fpc 0 l ->
case go 0 p fpc 0 l of
n -> I# n
```
This worked because strict `ByteString` is a single constructor data type which allows it to be unpacked into separate parameters in the recursive call.
Now, lets try the same with lazy `ByteStrings`:
```
data ByteString
= Empty
| Chunk {-# UNPACK #-} !StrictBS.ByteString ByteString
```
This of course has two constructors. It's built for call-pattern specialisation.
Now the ops:
```
null :: ByteString -> Bool
null Empty = True
null _ = False
tail :: ByteString -> ByteString
tail Empty = error "empty tail"
tail (Chunk (S.BS fp s 1) cs) = cs
tail (Chunk (S.BS fp s l) cs) = Chunk (S.BS fp (s+1) (l-1)) cs
```
We can use the exact same code for tail, but now for the lazy `ByteString` type:
```
length :: ByteString -> Int
length = go 0
where
go !n bs | null bs = n
| otherwise = go (n+1) (tail bs)
```
But, oh noes!! The optimisation does not work:
```
go :: Int# -> ByteString -> Int#
go = \n bs ->
case bs of
Empty -> n
Chunk p fpc o l bs' ->
go (n +# 1)
(case l of
1 -> bs'
_ -> Chunk p fpc (o +# 1) (l -# 1) bs')
length :: ByteString -> Int
length = \bs ->
case go 0 bs of
n -> I# n
```
However this is not because call pattern specialisation didn't do what we wanted. We know this for several reasons. One, if we remove the case
```
tail (Chunk (S.BS fp s 1) cs) = cs
```
then call pattern specialisation works and the code ends up as a perfect loop. Of course we need that case for correctness.
Also, if we change the definition of lazy `ByteString` to be a single constructor and represent the end by an empty chunk then we still get essentially the same code.
Also, if we use `uncons` instead of `null` and `tail` then we effectively perform by hand the missing optimisation transformation and get perfect code (and call-pattern specialisation happens exactly as expected).
```
length :: ByteString -> Int
length = go 0
where
go !n bs = case uncons bs of
Nothing -> n
Just (_, bs') -> go (n+1) bs'
uncons :: ByteString -> Maybe (Word8, ByteString)
uncons Empty = Nothing
uncons (Chunk c cs)
| StrictBS.length c == 1
= Just (S.unsafeHead c, cs)
| otherwise
= Just (S.unsafeHead c, Chunk (S.unsafeTail c) cs)
```
This version with `uncons` gives us perfect code:
```
go_chunk :: ByteString -> Int# -> Int#
-> ForeignPtrContents -> Addr# -> Int# -> Int#
go_chunk = \bs' l o fpc p n ->
case l of
1 -> go (n +# 1) bs'
_ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1)
go :: Int# -> ByteString -> Int#
go = \n bs ->
case bs of
Empty -> n
Chunk p fpc o l bs' ->
case l of
1 -> go (n +# 1) bs'
_ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1)
length :: ByteString -> Int
length = \bs ->
case go 0 bs of
n -> I# n
```
and we can see the specialisation rule that ghc invented for us:
```
forall bs l o fpc p n.
go n (Chunk p fpc o l bs)
= go_chunk bs l o fpc p n
```
Aside: looks like there's an extra/missing reverse in there somewhere.
The problem with the `head` / `tail` version is that the following transformation is never performed and so the opportunity for call pattern specialisation (or even simple worker/wrapper unpacking) is never exposed:
```
go (n+1)
(case l of
1 -> bs'
_ -> Chunk p fpc (o+1) (l-1) bs')
=
case l of
1 -> go (n+1) bs'
_ -> go (n+1) (Chunk p fpc (o+1) (l-1) bs')
```
which is the fragment inside the inlined definition of the go worker function:
```
go !n bs = case bs of
Empty -> n
Chunk p fpc o l bs' ->
go (n+1)
(case l of
1 -> bs'
_ -> Chunk p fpc (o+1) (l-1) bs')
```
So `go` is tail recursive and strict in both arguments. This situation will arise whenever we have something like
```
go (tail xs)
```
and `tail` involves a case analysis. Since `go` is just a function call there is no problem in duplicating it into the two branches of `tail`. The fact that it enables the call-pattern specialisation makes this a huge win.
This will happen with lazy `ByteString`s or any other chunked representation using trees. We really need the per-chunk inner loop to be good with just a single test in the fast path to see if we're at the end of the chunk. When we get to the end of the chunk we can move into the slow path and do more cunning things with chunks and trees and lazyness. But the overall speed of these kinds of operations is determined by the quality of the inner loop. If that inner loop has to allocate a fresh constructor each time round then we lose.
In principle, if we can optimise perfectly then there is no reason for strict `ByteString` to have faster code than lazy `ByteString`, because their inner loops should look exactly the same.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"missed optimisation opportunity with lazy ByteStrings","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With strict `ByteString` an a simple tail recursive iteration pattern we get perfect code.\r\n\r\nFirst the definitions:\r\n\r\n{{{\r\ndata ByteString\r\n = BS {-# UNPACK #-} !(ForeignPtr Word8) -- payload\r\n {-# UNPACK #-} !Int -- offset\r\n {-# UNPACK #-} !Int -- length\r\n\r\nnull :: ByteString -> Bool\r\nnull (BS _ _ l) = l <= 0\r\n\r\ntail :: ByteString -> ByteString\r\ntail (BS p s l)\r\n | l <= 0 = error \"ByteString.tail: empty ByteString\"\r\n | otherwise = BS p (s+1) (l-1)\r\n}}}\r\n\r\nNow a trivial iteration pattern:\r\n\r\n{{{\r\nlength :: ByteString -> Int\r\nlength = go 0\r\n where\r\n go !n bs | null bs = n\r\n | otherwise = go (n+1) (tail bs)\r\n}}}\r\n\r\nPerfect core code (edited for clarity):\r\n\r\n{{{\r\ngo :: Int# -> Addr# -> ForeignPtrContents\r\n -> Int# -> Int# -> Int#\r\ngo = \\n p fpc o l ->\r\n case l <=# 0 of\r\n False -> go (n +# 1) p fpc (o +# 1) (l -# 1)\r\n True -> n\r\n\r\nlength :: ByteString -> GHC.Base.Int\r\nlength = \\bs ->\r\n case bs of\r\n BS p fpc 0 l ->\r\n case go 0 p fpc 0 l of\r\n n -> I# n\r\n}}}\r\n\r\nThis worked because strict `ByteString` is a single constructor data type which allows it to be unpacked into separate parameters in the recursive call.\r\n\r\nNow, lets try the same with lazy `ByteStrings`:\r\n\r\n{{{\r\ndata ByteString\r\n = Empty\r\n | Chunk {-# UNPACK #-} !StrictBS.ByteString ByteString\r\n}}}\r\n\r\nThis of course has two constructors. It's built for call-pattern specialisation.\r\n\r\nNow the ops:\r\n\r\n{{{\r\nnull :: ByteString -> Bool\r\nnull Empty = True\r\nnull _ = False\r\n\r\ntail :: ByteString -> ByteString\r\ntail Empty = error \"empty tail\"\r\ntail (Chunk (S.BS fp s 1) cs) = cs\r\ntail (Chunk (S.BS fp s l) cs) = Chunk (S.BS fp (s+1) (l-1)) cs\r\n}}}\r\n\r\nWe can use the exact same code for tail, but now for the lazy `ByteString` type:\r\n\r\n{{{\r\nlength :: ByteString -> Int\r\nlength = go 0\r\n where\r\n go !n bs | null bs = n\r\n | otherwise = go (n+1) (tail bs)\r\n}}}\r\n\r\nBut, oh noes!! The optimisation does not work:\r\n\r\n{{{\r\ngo :: Int# -> ByteString -> Int#\r\ngo = \\n bs ->\r\n case bs of\r\n Empty -> n\r\n Chunk p fpc o l bs' ->\r\n go (n +# 1)\r\n (case l of\r\n 1 -> bs'\r\n _ -> Chunk p fpc (o +# 1) (l -# 1) bs')\r\n\r\nlength :: ByteString -> Int\r\nlength = \\bs ->\r\n case go 0 bs of\r\n n -> I# n\r\n}}}\r\n\r\nHowever this is not because call pattern specialisation didn't do what we wanted. We know this for several reasons. One, if we remove the case\r\n{{{\r\ntail (Chunk (S.BS fp s 1) cs) = cs\r\n}}}\r\nthen call pattern specialisation works and the code ends up as a perfect loop. Of course we need that case for correctness.\r\n\r\nAlso, if we change the definition of lazy `ByteString` to be a single constructor and represent the end by an empty chunk then we still get essentially the same code.\r\n\r\nAlso, if we use `uncons` instead of `null` and `tail` then we effectively perform by hand the missing optimisation transformation and get perfect code (and call-pattern specialisation happens exactly as expected).\r\n\r\n{{{\r\nlength :: ByteString -> Int\r\nlength = go 0\r\n where\r\n go !n bs = case uncons bs of\r\n Nothing -> n\r\n Just (_, bs') -> go (n+1) bs'\r\n\r\nuncons :: ByteString -> Maybe (Word8, ByteString)\r\nuncons Empty = Nothing\r\nuncons (Chunk c cs)\r\n | StrictBS.length c == 1\r\n = Just (S.unsafeHead c, cs)\r\n\r\n | otherwise\r\n = Just (S.unsafeHead c, Chunk (S.unsafeTail c) cs)\r\n}}}\r\n\r\nThis version with `uncons` gives us perfect code:\r\n\r\n{{{\r\ngo_chunk :: ByteString -> Int# -> Int#\r\n -> ForeignPtrContents -> Addr# -> Int# -> Int#\r\ngo_chunk = \\bs' l o fpc p n ->\r\n case l of\r\n 1 -> go (n +# 1) bs'\r\n _ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1)\r\n\r\ngo :: Int# -> ByteString -> Int#\r\ngo = \\n bs ->\r\n case bs of\r\n Empty -> n\r\n Chunk p fpc o l bs' ->\r\n case l of\r\n 1 -> go (n +# 1) bs'\r\n _ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1)\r\n\r\nlength :: ByteString -> Int\r\nlength = \\bs ->\r\n case go 0 bs of\r\n n -> I# n\r\n}}}\r\n\r\nand we can see the specialisation rule that ghc invented for us:\r\n\r\n{{{\r\nforall bs l o fpc p n.\r\n go n (Chunk p fpc o l bs)\r\n = go_chunk bs l o fpc p n\r\n}}}\r\n\r\nAside: looks like there's an extra/missing reverse in there somewhere.\r\n\r\nThe problem with the `head` / `tail` version is that the following transformation is never performed and so the opportunity for call pattern specialisation (or even simple worker/wrapper unpacking) is never exposed:\r\n\r\n{{{\r\n go (n+1)\r\n (case l of\r\n 1 -> bs'\r\n _ -> Chunk p fpc (o+1) (l-1) bs')\r\n=\r\n case l of\r\n 1 -> go (n+1) bs'\r\n _ -> go (n+1) (Chunk p fpc (o+1) (l-1) bs')\r\n}}}\r\n\r\nwhich is the fragment inside the inlined definition of the go worker function:\r\n\r\n{{{\r\ngo !n bs = case bs of\r\n Empty -> n\r\n Chunk p fpc o l bs' ->\r\n go (n+1)\r\n (case l of\r\n 1 -> bs'\r\n _ -> Chunk p fpc (o+1) (l-1) bs')\r\n}}}\r\n\r\nSo `go` is tail recursive and strict in both arguments. This situation will arise whenever we have something like\r\n\r\n{{{\r\ngo (tail xs)\r\n}}}\r\n\r\nand `tail` involves a case analysis. Since `go` is just a function call there is no problem in duplicating it into the two branches of `tail`. The fact that it enables the call-pattern specialisation makes this a huge win.\r\n\r\nThis will happen with lazy `ByteString`s or any other chunked representation using trees. We really need the per-chunk inner loop to be good with just a single test in the fast path to see if we're at the end of the chunk. When we get to the end of the chunk we can move into the slow path and do more cunning things with chunks and trees and lazyness. But the overall speed of these kinds of operations is determined by the quality of the inner loop. If that inner loop has to allocate a fresh constructor each time round then we lose.\r\n\r\nIn principle, if we can optimise perfectly then there is no reason for strict `ByteString` to have faster code than lazy `ByteString`, because their inner loops should look exactly the same.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3117via C compilation of module importing log1p from <math.h> fails.2023-01-30T15:43:00ZBertram Felgenhauervia C compilation of module importing log1p from <math.h> fails.This module fails to compile:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# OPTIONS_GHC -fvia-C #-}
foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double
main = print (log1p 1)
```
With errors like these:
```
/tmp...This module fails to compile:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# OPTIONS_GHC -fvia-C #-}
foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double
main = print (log1p 1)
```
With errors like these:
```
/tmp/ghc25313_0/ghc25313_0.hc: In function 'svD_entry':
/tmp/ghc25313_0/ghc25313_0.hc:66:0:
error: 'log1p' redeclared as different kind of symbol
/usr/include/bits/mathcalls.h:132:0:
error: previous declaration of 'log1p' was here
```
This is affecting the `logfloat` package on hackage.
The reason is that `ghc` doesn't generate proper prototypes for foreign imports, but that's probably ok as long as no conflicting prototypes are defined for the same function.
To accomplish this, `ghc` treats functions from `math.h` specially, but a number of these functions like `log1p` are not recognized. See `compiler/cmm/CLabel.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"via C compilation of module importing log1p from <math.h> fails.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module fails to compile:\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# OPTIONS_GHC -fvia-C #-}\r\n\r\nforeign import ccall unsafe \"math.h log1p\" log1p :: Double -> Double\r\n\r\nmain = print (log1p 1)\r\n}}}\r\nWith errors like these:\r\n{{{\r\n/tmp/ghc25313_0/ghc25313_0.hc: In function 'svD_entry':\r\n\r\n/tmp/ghc25313_0/ghc25313_0.hc:66:0:\r\n error: 'log1p' redeclared as different kind of symbol\r\n\r\n/usr/include/bits/mathcalls.h:132:0:\r\n error: previous declaration of 'log1p' was here\r\n}}}\r\nThis is affecting the {{{logfloat}}} package on hackage.\r\n\r\nThe reason is that {{{ghc}}} doesn't generate proper prototypes for foreign imports, but that's probably ok as long as no conflicting prototypes are defined for the same function.\r\n\r\nTo accomplish this, {{{ghc}}} treats functions from {{{math.h}}} specially, but a number of these functions like {{{log1p}}} are not recognized. See {{{compiler/cmm/CLabel.hs}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3118ghc: panic! (the 'impossible' happened): Missing alternative2019-07-07T19:05:17Zcalvinsghc: panic! (the 'impossible' happened): Missing alternativeWhen I include the -auto-all option (in addition to -prof) on the entry for Main in my Cabal file, I get the ghc panic message below. Full compile output attached.
```
[10 of 10] Compiling Main ( Rdf4hParseMain.hs, dist/buil...When I include the -auto-all option (in addition to -prof) on the entry for Main in my Cabal file, I get the ghc panic message below. Full compile output attached.
```
[10 of 10] Compiling Main ( Rdf4hParseMain.hs, dist/build/rdf4h/rdf4h-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
Missing alternative
main:Main.OutputFormat{d r16LZ}
(main:Main.Help{d r16M9}, [], lvl_s17ar{v} [lid])
(main:Main.Debug{d r16M7}, [], lvl_s17as{v} [lid])
(main:Main.Version{d r16M5}, [], lvl_s17at{v} [lid])
```
To reproduce the bug, check out a tagged version of the code using:
darcs get -t 'ghc bug report' http://protempore.net/rdf4h
And then edit the cabal file by adding "-prof -auto-all" to the library and main entries, and you should see what I see above if it's reproducible. It compiles fine if the options are only added to the library block, and it compiles fine if '-prof' but not '-auto-all' is added to the executable block, but fails when '-prof' and '-auto-all' are both added to the executable block.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc: panic! (the 'impossible' happened): Missing alternative","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I include the -auto-all option (in addition to -prof) on the entry for Main in my Cabal file, I get the ghc panic message below. Full compile output attached.\r\n\r\n\r\n{{{\r\n[10 of 10] Compiling Main ( Rdf4hParseMain.hs, dist/build/rdf4h/rdf4h-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for x86_64-unknown-linux):\r\n\tMissing alternative\r\n main:Main.OutputFormat{d r16LZ}\r\n (main:Main.Help{d r16M9}, [], lvl_s17ar{v} [lid])\r\n (main:Main.Debug{d r16M7}, [], lvl_s17as{v} [lid])\r\n (main:Main.Version{d r16M5}, [], lvl_s17at{v} [lid])\r\n\r\n}}}\r\n\r\nTo reproduce the bug, check out a tagged version of the code using:\r\n\r\ndarcs get -t 'ghc bug report' http://protempore.net/rdf4h\r\n\r\nAnd then edit the cabal file by adding \"-prof -auto-all\" to the library and main entries, and you should see what I see above if it's reproducible. It compiles fine if the options are only added to the library block, and it compiles fine if '-prof' but not '-auto-all' is added to the executable block, but fails when '-prof' and '-auto-all' are both added to the executable block.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3119Make ghc-6.10 use a non-executable stack (by bumping libffi)2019-07-07T19:05:17Zkolmodin@dtek.chalmers.seMake ghc-6.10 use a non-executable stack (by bumping libffi)Attached patch:
```
Mon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>
* Replace libffi 3.0.4 with libffi 3.0.8
Use the latest version of libffi, which compiles with a non-executable
stack. libffi 3.0.4 was the s...Attached patch:
```
Mon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>
* Replace libffi 3.0.4 with libffi 3.0.8
Use the latest version of libffi, which compiles with a non-executable
stack. libffi 3.0.4 was the single piece of ghc using the executable stack,
forcing the whole toolchain to use executable stacks (including all
executables it compiled).
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make ghc-6.10 use a non-executable stack (by bumping libffi)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Attached patch:\r\n\r\n{{{\r\nMon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>\r\n * Replace libffi 3.0.4 with libffi 3.0.8\r\n Use the latest version of libffi, which compiles with a non-executable\r\n stack. libffi 3.0.4 was the single piece of ghc using the executable stack,\r\n forcing the whole toolchain to use executable stacks (including all\r\n executables it compiled).\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3120openFile003 fails on i386/solaris2019-07-07T19:05:17ZkgardasopenFile003 fails on i386/solarisIt seems that openFile003 fails on i386/solaris platform. The reason seems to be a difference between expected and provided output. It also seems that the difference is expected as sparc/solaris2 provided stdout file makes test run fine ...It seems that openFile003 fails on i386/solaris platform. The reason seems to be a difference between expected and provided output. It also seems that the difference is expected as sparc/solaris2 provided stdout file makes test run fine on this platform and it looks logical. Provided darcs patch fixes this issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"openFile003 fails on i386/solaris","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"kgardas"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"It seems that openFile003 fails on i386/solaris platform. The reason seems to be a difference between expected and provided output. It also seems that the difference is expected as sparc/solaris2 provided stdout file makes test run fine on this platform and it looks logical. Provided darcs patch fixes this issue.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3121readline package does not respect Cabal --extra-{include,lib}-dirs flags2019-07-07T19:05:17Zduncanreadline package does not respect Cabal --extra-{include,lib}-dirs flagsThe readline package still uses a `./configure` script. It has flags to set extra library and include dirs to search. These are needed by OSX users.
The `./configure` script takes the flags:
```
--with-readline-includes=
--with-readlin...The readline package still uses a `./configure` script. It has flags to set extra library and include dirs to search. These are needed by OSX users.
The `./configure` script takes the flags:
```
--with-readline-includes=
--with-readline-libraries=
```
However when an end user installs the package via Cabal, (either `runghc Setup` or `cabal`) they use the Cabal flags:
```
--extra-include-dirs=
--extra-lib-dirs=
```
The problem is that the two sets of flags are not connected at all. If the configure script needs to know these directories then the Setup.hs for the package should pass them through. Users are not expected to know the per-package configure flags, especially when we already have suitable generic flags for the same purpose.
The end result is that OSX users cannot install readline. Eg, today someone complained:
```
hm, I have installed libreadline from mac ports and I have
told cabal to look for it in --extra-include-dirs
--extra-lib-dirs I also have installed the GNU.framework for
mac but it still fails...any suggestions?
```
This problem actually applies to most bindings packages that use configure scripts. See also [this Cabal ticket](http://hackage.haskell.org/trac/hackage/ticket/458) about similar mismatches with configure scripts.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"readline package does not respect Cabal --extra-{include,lib}-dirs flags","status":"New","operating_system":"Unknown/Multiple","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The readline package still uses a `./configure` script. It has flags to set extra library and include dirs to search. These are needed by OSX users.\r\n\r\nThe `./configure` script takes the flags:\r\n{{{\r\n--with-readline-includes=\r\n--with-readline-libraries=\r\n}}}\r\n\r\nHowever when an end user installs the package via Cabal, (either `runghc Setup` or `cabal`) they use the Cabal flags:\r\n\r\n{{{\r\n--extra-include-dirs=\r\n--extra-lib-dirs=\r\n}}}\r\n\r\nThe problem is that the two sets of flags are not connected at all. If the configure script needs to know these directories then the Setup.hs for the package should pass them through. Users are not expected to know the per-package configure flags, especially when we already have suitable generic flags for the same purpose.\r\n\r\nThe end result is that OSX users cannot install readline. Eg, today someone complained:\r\n\r\n{{{\r\nhm, I have installed libreadline from mac ports and I have\r\ntold cabal to look for it in --extra-include-dirs\r\n--extra-lib-dirs I also have installed the GNU.framework for\r\nmac but it still fails...any suggestions?\r\n}}}\r\n\r\nThis problem actually applies to most bindings packages that use configure scripts. See also [http://hackage.haskell.org/trac/hackage/ticket/458 this Cabal ticket] about similar mismatches with configure scripts.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3122Enhance --info2019-07-07T19:05:16ZIan Lynagh <igloo@earth.li>Enhance --infoWe should:
- Add things like C compiler, assembler, linker, libdir into the `--info` output
- Generalise `--print-libdir` such that `--print-foo` prints the foo field from the `--info` output.
<details><summary>Trac metadata</summary>
...We should:
- Add things like C compiler, assembler, linker, libdir into the `--info` output
- Generalise `--print-libdir` such that `--print-foo` prints the foo field from the `--info` output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Enhance --info","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We should:\r\n * Add things like C compiler, assembler, linker, libdir into the `--info` output\r\n * Generalise `--print-libdir` such that `--print-foo` prints the foo field from the `--info` output.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/3123make INLINE work for recursive definitions (generalized loop peeling/loop unr...2019-07-07T19:05:16Zclaus.reinke@talk21.commake INLINE work for recursive definitions (generalized loop peeling/loop unrolling)Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is curren...Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner.
Unfolding Recursions
Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand-unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents.
More details, examples, and an informal spec: wiki:OldInlining8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3124warning -F: directory name (/Users/me/Library/Frameworks) does not exist2019-07-07T19:05:16Z7studwarning -F: directory name (/Users/me/Library/Frameworks) does not existmac osx 10.4.11(intel),
ghc 6.8.2 installed from ghc-6.8.2-i386-apple-darwin.tar.bz2
When I try to compile programs, I get this warning:
```
$ ghc -o simple Main.hs PutJSON.hs SimpleJSON.hs
compilation IS NOT required
/usr/libexec/gcc/...mac osx 10.4.11(intel),
ghc 6.8.2 installed from ghc-6.8.2-i386-apple-darwin.tar.bz2
When I try to compile programs, I get this warning:
```
$ ghc -o simple Main.hs PutJSON.hs SimpleJSON.hs
compilation IS NOT required
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -F: directory name (/Users/autie/Library/Frameworks) does not exist
```
This is how I installed ghc:
1) I downloaded GMP.framework and GNUreadline.framework, which my mac automatically unzipped and placed on my desktop. I then dragged the resulting two folders into /Library/Frameworks as per the instructions at:
http://www.haskell.org/ghc/download_ghc_682.html\#macosxintel
2) I downloaded ghc-6.8.2-i386-apple-darwin.tar.bz2
3) I unzipped an untared into /Users/me/my_tar_extractions
4) I cd'ed into the newly created ghc-6.8.2 folder.
5) I read the INSTALL document in the ghc-6.8.2 folder.
6) I ran the command:
```
$ ./configure
```
7) Then I ran the command:
```
$ sudo make install
```
8) At the end of the install output, I got a message that said:
```
-------------
Installation of ghc-6.8.2 was successful.
To use, add /usr/local/bin to your PATH.
Warning: this binary distribution does NOT contain documentation!
--------------
```
9) I appended /usr/local/bin onto the PATH in \~/.bash_profile.
This is what INSTALL from step 5 says:
```
This is the INSTALL instructions for a binary distribution of GHC. For
more details on what on earth this package is up to, please consult
the README and ANNOUNCE.
This distribution can be installed in a location of your choosing.
To set the ball rolling, run the configure script (as usual, run the
script with --help to see what options it supports). eg. to set up
the package for installing in directory <my-dir>, use
./configure --prefix=<my-dir>
The default installation directory is /usr/local.
The configure script will figure out what platform you're running on,
and a couple of other interesting pieces of trivia, which it will then
fill in the Makefile.in template to give you a real Makefile. If
you're of a paranoid persuasion, you might want to take a look at this
Makefile to see if the information is correct.
Now run:
make install
(`make show-install-setup' prints the details of where the different
pieces of the bundle are heading when -- possibly helpful).
For more information, full GHC documentation is available from the
main GHC site:
http://www.haskell.org/ghc
Bug reports/suggestions for improvement to the installation
procedure/setup (as well as other GHC related troubles you're
experiencing, of course), gratefully received. Bug reporting
instructions are here:
http://www.haskell.org/ghc/reportabug
Enjoy,
-- The GHC Team.
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3125TcTyFuns.flattenType: unexpected PredType2019-07-07T19:05:16ZguestTcTyFuns.flattenType: unexpected PredType```
type family Garbage y
type instance Garbage y = [Num y => y]
```
yields
```
*Main> undefined :: Garbage Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpect...```
type family Garbage y
type instance Garbage y = [Num y => y]
```
yields
```
*Main> undefined :: Garbage Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
While its perfectly reasonable to die out on garbage like this, a less apocalyptic error message might be nice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TcTyFuns.flattenType: unexpected PredType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett@gmail.com"],"type":"Bug","description":"{{{\r\ntype family Garbage y\r\ntype instance Garbage y = [Num y => y]\r\n}}}\r\n\r\nyields\r\n\r\n{{{\r\n*Main> undefined :: Garbage Int\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for x86_64-unknown-linux):\r\n TcTyFuns.flattenType: unexpected PredType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nWhile its perfectly reasonable to die out on garbage like this, a less apocalyptic error message might be nice.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3126GHC needs to be more careful about pattern match order2019-07-07T19:05:15Zclaus.reinke@talk21.comGHC needs to be more careful about pattern match orderThe [language report](http://haskell.org/onlinereport/exps.html#sect3.17.2) specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences a...The [language report](http://haskell.org/onlinereport/exps.html#sect3.17.2) specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences are not observable and certain [rules](http://haskell.org/onlinereport/exps.html#sect3.17.3) remain valid. One such rule is:
```
case e of {p1->e1;p2->e2} =
case e of {p1->e1;_->case e of {p2->e2;_->error "No match"}}
```
GHC invalidates this rule:
```
newtype N = N Int deriving (Show,Eq)
instance Num N where
fromInteger 0 = error "0"
fromInteger 1 = N 0
fromInteger _ = N 1
f x = case x of
1 -> False
0 -> True
g x = case x of
1 -> False
_ -> case x of
0 -> True
_ -> error "No match"
main = do
print $ g (N 0)
print $ f (N 0)
-- ghc
$ ghc -w -e main PMOrderSpec.hs
False
<interactive>: 0
-- hugs
Main> main
False
False
```
The same effect can be achieved via `Data.String.IsString` (see attached test case).
See also:
- [compilation of pattern matching?](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-March/016949.html)
- [Wrongpat-matchorderforrecords](https://gitlab.haskell.org//ghc/ghc/issues/246)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"GHC needs to be more careful about pattern match order","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [http://haskell.org/onlinereport/exps.html#sect3.17.2 language report] specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences are not observable and certain [http://haskell.org/onlinereport/exps.html#sect3.17.3 rules] remain valid. One such rule is:\r\n{{{\r\n case e of {p1->e1;p2->e2} = \r\n case e of {p1->e1;_->case e of {p2->e2;_->error \"No match\"}}\r\n}}}\r\nGHC invalidates this rule:\r\n{{{\r\n newtype N = N Int deriving (Show,Eq)\r\n \r\n instance Num N where\r\n fromInteger 0 = error \"0\"\r\n fromInteger 1 = N 0\r\n fromInteger _ = N 1\r\n \r\n f x = case x of\r\n 1 -> False\r\n 0 -> True\r\n \r\n g x = case x of\r\n 1 -> False\r\n _ -> case x of\r\n 0 -> True\r\n _ -> error \"No match\"\r\n \r\n main = do\r\n print $ g (N 0)\r\n print $ f (N 0)\r\n\r\n -- ghc\r\n $ ghc -w -e main PMOrderSpec.hs\r\n False\r\n <interactive>: 0\r\n\r\n -- hugs\r\n Main> main\r\n False\r\n False\r\n}}}\r\nThe same effect can be achieved via `Data.String.IsString` (see attached test case).\r\n\r\nSee also: \r\n\r\n - [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-March/016949.html compilation of pattern matching?]\r\n - [ticket:246 Wrong pat-match order for records]","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3127need help to edit the Haskell script in Winhugs and documentation.2019-07-07T19:05:14Zrjhelpdeskneed help to edit the Haskell script in Winhugs and documentation.Both sections relate to the case study: Index for a document of text.
SECTION A:
Given the attached Haskell code which produces an index of words, make the following alterations by modifying existing functions and including new functio...Both sections relate to the case study: Index for a document of text.
SECTION A:
Given the attached Haskell code which produces an index of words, make the following alterations by modifying existing functions and including new functions where necessary – parts 1) to 5):
1) Where a word occurs N times on the same line, ensure that the line number occurs n times in the index entry for that word.
2) Allow words to be hyphenated and treat a hyphenated word as a single word. However, for those words which are split over two lines, treat a split word as a single word without the hyphen.
3) Treat a capitalised word (one or more capitals) as being different from the word in all lower case (but they should still be sorted alphabetically) – unless it is at the start of a sentence with only the initial letter capitalised. A sentence is terminated by a ‘.’, ‘?’ or ‘!’.
4) Make the output more readable in the form of an index table in columns with appropriate spacing and without brackets.
5) Include a user-friendly menu, so that the user can choose input/output file names or default files, and choose to rerun or exit.
Parts 1) to 5) may be developed in any order.
SECTION B:
6) For your version of function, makeIndex (only), show how an alternative ordering of the composed functions would provide a more efficient execution of makeIndex. Justify your answer.
7) For the parts 1) to 5) above that you have attempted, discuss the use you have made of a) higher-order functions, b) list comprehension, c) monadic input/output, d) functional composition, and/or e) partial parameterisation (or Curried functions). Include an evaluation of how useful your use of these concepts has been.
import Prelude
type Doc = String
type Line = String
type Word = String
makeIndex :: Doc -\> \[ (\[Int\], Word) \]
makeIndex
= shorten . -- \[(\[Int\], Word)\] -\> \[(\[Int\], Word)\]
> amalgamate .-- \[(\[Int\], Word)\] -\> \[(\[Int\], Word)\]
> makeLists . -- \[(Int, Word)\] -\> \[(\[Int\], Word)\]
> sortLs . -- \[(Int, Word)\] -\> \[(Int, Word)\]
allNumWords .-- \[(Int, Line)\] -\> \[(Int, Word)\]
numLines . -- \[Line\] -\> \[(Int, Line)\]
splitUp -- Doc -\> \[Line\]
splitUp :: Doc -\> \[Line\]
splitUp \[\] = \[\]
splitUp text
= takeWhile (/='\\n') text : -- first line
(splitUp . -- splitup other lines
dropWhile (==’\\n’) . -- delete 1st newline(s)
> dropWhile (/='\\n')) text -- other lines
numLines :: \[Line\] -\> \[(Int, Line)\]
numLines lines -- list of pairs of
= zip \[1 .. length lines\] lines -- line no. & line
-- for each line
-- a) split into words
-- b) attach line no. to each word
splitWords :: Line -\> \[Word\] -- a)
splitWords \[\] = \[\]
splitWords line
= takeWhile isLetter line : -- first word in line
(splitWords . -- split other words
dropWhile (not.isLetter) . -- delete separators
dropWhile isLetter) line -- other words
> where
> isLetter ch
= (‘a’\<=ch) && (ch\<=’z’)
> \|\| (‘A’\<=ch) && (ch\<=’Z’)
numWords :: (Int, Line) -\> \[(Int, Word)\] -- b)
numWords (number, line)
= map addLineNum ( splitWords line) -- all line pairs
> where
> addLineNum word = (number, word) -- a pair
allNumWords :: \[(Int, Line)\] -\> \[(Int, Word)\]
allNumWords = concat . map numWords -- doc pairs
sortLs :: \[(Int, Word)\] -\> \[(Int, Word)\]
sortLs \[ \] = \[ \]
sortLs (a:x)
= sortLs \[b \| b \<- x, compare b a\] -- sort 1st half
++ \[a\] ++ -- 1st in middle
sortLs \[b \| b \<- x, compare a b\] -- sort 2nd half
where
compare (n1, w1) (n2, w2)
> = (w1 \< w2) -- 1st word less
\|\| (w1 == w2 && n1 \< n2) -- check no.
makeLists :: \[(Int, Word)\] -\> \[(\[Int\], Word)\]
makeLists
= map mk -- all pairs
> where mk (num, word) = (\[num\], word)
-- list of single no.
amalgamate :: \[(\[Int\], Word)\] -\> \[(\[Int\], Word)\]
amalgamate \[ \] = \[ \]
amalgamate \[a\] = \[a\]
amalgamate ((n1, w1) : (n2, w2) : rest)-- pairs of pairs
\| w1 /= w2 = (n1, w1) : amalgamate ((n2, w2) : rest)
\| otherwise = amalgamate ((n1 ++ n2, w1) : rest)
-- if words are same grow list of numbers
shorten :: \[(\[Int\], Word)\] -\> \[(\[Int\], Word)\]
shorten
= filter long -- keep pairs \>4
> where
long (num, word) = length word \> 4 -- check word \>4
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"need help to edit the Haskell script in Winhugs and documentation.","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"\r\nBoth sections relate to the case study:\tIndex for a document of text.\r\n\r\nSECTION A: \r\n\r\nGiven the attached Haskell code which produces an index of words, make the following alterations by modifying existing functions and including new functions where necessary – parts 1) to 5):\r\n\r\n1)\tWhere a word occurs N times on the same line, ensure that the line number occurs n times in the index entry for that word.\t\r\n\r\n2)\tAllow words to be hyphenated and treat a hyphenated word as a single word. However, for those words which are split over two lines, treat a split word as a single word without the hyphen.\t\t\r\n\r\n3)\tTreat a capitalised word (one or more capitals) as being different from the word in all lower case (but they should still be sorted alphabetically) – unless it is at the start of a sentence with only the initial letter capitalised. A sentence is terminated by a ‘.’, ‘?’ or ‘!’.\t\r\n\r\n4)\tMake the output more readable in the form of an index table in columns with appropriate spacing and without brackets.\t\r\n\r\n5)\tInclude a user-friendly menu, so that the user can choose input/output file names or default files, and choose to rerun or exit.\t\r\n\r\nParts 1) to 5) may be developed in any order. \r\n\r\n\r\nSECTION B:\r\n\r\n6)\tFor your version of function, makeIndex (only), show how an alternative ordering of the composed functions would provide a more efficient execution of makeIndex. Justify your answer.\t\r\n\r\n7)\tFor the parts 1) to 5) above that you have attempted, discuss the use you have made of a) higher-order functions, b) list comprehension, c) monadic input/output, d) functional composition, and/or e) partial parameterisation (or Curried functions). Include an evaluation of how useful your use of these concepts has been.\t\t\t \r\n\r\n\t\t\t\t\t\t\t\t\t\t\r\n \r\nimport Prelude\r\n\r\ntype Doc\t= String\r\ntype Line\t= String\r\ntype Word\t= String\t\r\n\r\nmakeIndex :: Doc -> [ ([Int], Word) ]\r\n\r\nmakeIndex\r\n = \tshorten .\t--\t[([Int], Word)]\t-> [([Int], Word)]\r\n \tamalgamate .--\t[([Int], Word)]\t-> [([Int], Word)]\r\n \tmakeLists .\t--\t[(Int, Word)]\t-> [([Int], Word)]\r\n \tsortLs .\t--\t[(Int, Word)]\t-> [(Int, Word)]\r\n \tallNumWords .--\t[(Int, Line)]\t-> [(Int, Word)]\r\n \tnumLines .\t--\t[Line]\t\t-> [(Int, Line)]\r\n \tsplitUp \t--\tDoc\t\t\t-> [Line]\r\n\r\nsplitUp :: Doc -> [Line]\r\n\r\nsplitUp [] = []\r\nsplitUp text\r\n = takeWhile (/='\\n') text :\t--\tfirst line\r\n (splitUp . \t\t\t--\tsplitup other lines\r\n dropWhile (==’\\n’) . \t--\tdelete 1st newline(s)\r\n dropWhile (/='\\n')) text\t--\tother lines\r\n\r\nnumLines :: [Line] -> [(Int, Line)]\r\n\r\nnumLines lines\t\t\t\t--\tlist of pairs of \r\n = zip [1 .. length lines] lines\t--\tline no. & line\r\n\r\n--\tfor each line\r\n--\ta)\tsplit into words\r\n--\tb)\tattach line no. to each word\r\n\r\nsplitWords :: Line -> [Word]\t\t--\ta)\r\n\r\nsplitWords [] = []\r\nsplitWords line \r\n = takeWhile isLetter line :\t\t--\tfirst word in line\r\n\t(splitWords . \t\t\t--\tsplit other words\r\n\t dropWhile (not.isLetter) . \t--\tdelete separators\r\n\t dropWhile isLetter) line\t--\tother words\r\n where\r\n isLetter ch\r\n \t= (‘a’<=ch) && (ch<=’z’)\r\n \t || (‘A’<=ch) && (ch<=’Z’)\r\n\r\nnumWords :: (Int, Line) -> [(Int, Word)]\t--\tb)\r\n\r\nnumWords (number, line)\r\n = map addLineNum ( splitWords line)\t--\tall line pairs\r\n where\r\n addLineNum word = (number, word)\t\t--\ta pair\r\n\r\nallNumWords :: [(Int, Line)] -> [(Int, Word)]\r\n\r\nallNumWords = concat . map numWords\t\t-- doc pairs\t\r\n\r\nsortLs :: [(Int, Word)] -> [(Int, Word)]\r\n\r\nsortLs [ ] = [ ]\r\nsortLs (a:x)\r\n = sortLs [b | b <- x, compare b a]\t--\tsort 1st half\r\n ++ [a] ++\t\t\t\t--\t1st in middle\r\n sortLs [b | b <- x, compare a b]\t--\tsort 2nd half\r\n where\r\n compare (n1, w1) (n2, w2)\r\n = (w1 < w2) \t\t\t\t--\t1st word less\r\n\t || (w1 == w2 && n1 < n2)\t--\tcheck no.\t\r\n\r\nmakeLists :: [(Int, Word)] -> [([Int], Word)]\r\n\r\nmakeLists \r\n = map mk\t\t\t\t\t-- all pairs\r\n where mk (num, word) = ([num], word)\r\n\t\t\t\t\t\t-- list of single no.\r\n\r\namalgamate :: [([Int], Word)] -> [([Int], Word)]\r\n\r\namalgamate [ ] = [ ]\r\namalgamate [a] = [a]\r\namalgamate ((n1, w1) : (n2, w2) : rest)-- pairs of pairs\r\n | w1 /= w2\t\t= (n1, w1) : amalgamate ((n2, w2) : rest)\r\n | otherwise \t= amalgamate ((n1 ++ n2, w1) : rest)\r\n\t--\tif words are same grow list of numbers\r\n\r\nshorten :: [([Int], Word)] -> [([Int], Word)]\r\n\r\nshorten\r\n = filter long\t\t \t\t\t-- \tkeep pairs >4\r\n where\r\n\tlong (num, word) = length word > 4 --\tcheck word >4\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3128hClose leaves file descriptor open if it fails2019-07-07T19:05:14ZBaughnhClose leaves file descriptor open if it failsIn libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD.
If flushing the write buffer fails, for example if this is a network socket that has been closed by the...In libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD.
If flushing the write buffer fails, for example if this is a network socket that has been closed by the remote host, hClose throws an exception inside flushWriteBufferOnly and the socket is not closed. As a result, the program leaks sockets.
The solution is to always close the FD (that is, call hClose_handle_) regardless of errors, but I am not confident of writing correct exception-handling code without the usual abstractions available.
Also, inside hClose_handle_, an error is thrown if c_close ever returns -1. It may be practically impossible for this to be caused by EINTR, but is it theoretically impossible?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"hClose leaves file descriptor open if it fails","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD.\r\n\r\nIf flushing the write buffer fails, for example if this is a network socket that has been closed by the remote host, hClose throws an exception inside flushWriteBufferOnly and the socket is not closed. As a result, the program leaks sockets.\r\n\r\nThe solution is to always close the FD (that is, call hClose_handle_) regardless of errors, but I am not confident of writing correct exception-handling code without the usual abstractions available.\r\n\r\n\r\nAlso, inside hClose_handle_, an error is thrown if c_close ever returns -1. It may be practically impossible for this to be caused by EINTR, but is it theoretically impossible?","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3129Crypto-4.1.0 compilation failure2019-07-07T19:05:14ZguestCrypto-4.1.0 compilation failureGHC panic:
```
[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/b...GHC panic:
```
[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
Crypto-4.1.0 failed during the building phase. The exception was:
exit: ExitFailure 1
hS3-0.4 depends on Crypto-4.1.0 which failed to install.
```
--------------
Software:
```
System Version: Mac OS X 10.5.6 (9G55)
Kernel Version: Darwin 9.6.0
```
Hardware:
```
Model Name: MacBook
Model Identifier: MacBook2,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.16 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 4 GB
Bus Speed: 667 MHz
Boot ROM Version: MB21.00A5.B07
SMC Version: 1.17f0
Sudden Motion Sensor:
State: Enabled
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Crypto-4.1.0 compilation failure","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["Crypto-4.1.0"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC panic:\r\n\r\n{{{\r\n[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )\r\nLinking dist/build/SymmetricTest/SymmetricTest ...\r\n[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )\r\n[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )\r\n[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )\r\n[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tRegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Error: some packages failed to install:\r\nCrypto-4.1.0 failed during the building phase. The exception was:\r\nexit: ExitFailure 1\r\nhS3-0.4 depends on Crypto-4.1.0 which failed to install.\r\n}}}\r\n--------------\r\nSoftware:\r\n{{{\r\n System Version:\tMac OS X 10.5.6 (9G55)\r\n Kernel Version:\tDarwin 9.6.0\r\n}}}\r\nHardware:\r\n{{{\r\n Model Name:\tMacBook\r\n Model Identifier:\tMacBook2,1\r\n Processor Name:\tIntel Core 2 Duo\r\n Processor Speed:\t2.16 GHz\r\n Number Of Processors:\t1\r\n Total Number Of Cores:\t2\r\n L2 Cache:\t4 MB\r\n Memory:\t4 GB\r\n Bus Speed:\t667 MHz\r\n Boot ROM Version:\tMB21.00A5.B07\r\n SMC Version:\t1.17f0\r\n Sudden Motion Sensor:\r\n State:\tEnabled\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3130copyFile and findExecutable don't work correctly if filename has national sym...2019-07-07T19:05:13Zshelarcy@capella.freemail.ne.jpcopyFile and findExecutable don't work correctly if filename has national symbolscopyFile works doesn't work if first argument's filename has national symbols.
```
import System.Directory
main = do
copyFile "test.txt" "テスト.txt" -- works
print "copyFile works if second argument has national path."
copyF...copyFile works doesn't work if first argument's filename has national symbols.
```
import System.Directory
main = do
copyFile "test.txt" "テスト.txt" -- works
print "copyFile works if second argument has national path."
copyFile "テスト.txt" "test2.txt" -- doesn't work
print "copyFile doesn't work if second argument has national path."
copyFile "テスト.txt" "テスト2.txt" -- doesn't work
print "copyFile doesn't work if first argument has national path."
```
```
C:\home>runghc.exe Test.hs
"copyFile works if second argument has national path."
Test.hs: ニケネ.txt: copyFile: does not exist (No such file or directory)
```
System.Win32.copyFile doesn't cause this problem.
```
import System.Win32
main = do
copyFile "test.txt" "テスト.txt" False -- works
print "copyFile works if second argument has national path."
copyFile "テスト.txt" "test2.txt" False -- doesn't work
print "copyFile doesn't work if second argument has national path."
copyFile "テスト.txt" "テスト2.txt" False -- doesn't work
print "copyFile doesn't work if first argument has national path."
```
```
C:\home>runghc.exe Test.hs
"copyFile works if second argument has national path."
"copyFile doesn't work if second argument has national path."
"copyFile doesn't work if first argument has national path."
```
And findExecutable return Nothing if executable file name has national symbols.
```
import System.Directory -- hiding (getDirectoryContents)
main = findExecutable "テスト" >>= print
```
```
C:\home>runghc.exe Test.hs
Nothing
```
So, I made patch for these two problems.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.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":"copyFile and findExecutable don't work correctly if filename has national symbols","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"copyFile works doesn't work if first argument's filename has national symbols.\r\n\r\n{{{\r\nimport System.Directory\r\n\r\nmain = do\r\n copyFile \"test.txt\" \"テスト.txt\" -- works\r\n print \"copyFile works if second argument has national path.\"\r\n\r\n copyFile \"テスト.txt\" \"test2.txt\" -- doesn't work\r\n print \"copyFile doesn't work if second argument has national path.\"\r\n\r\n copyFile \"テスト.txt\" \"テスト2.txt\" -- doesn't work\r\n print \"copyFile doesn't work if first argument has national path.\"\r\n}}}\r\n\r\n{{{\r\nC:\\home>runghc.exe Test.hs\r\n\"copyFile works if second argument has national path.\"\r\nTest.hs: ニケネ.txt: copyFile: does not exist (No such file or directory)\r\n}}}\r\n\r\nSystem.Win32.copyFile doesn't cause this problem.\r\n\r\n{{{\r\nimport System.Win32\r\n\r\nmain = do\r\n copyFile \"test.txt\" \"テスト.txt\" False -- works\r\n print \"copyFile works if second argument has national path.\"\r\n\r\n copyFile \"テスト.txt\" \"test2.txt\" False -- doesn't work\r\n print \"copyFile doesn't work if second argument has national path.\"\r\n\r\n copyFile \"テスト.txt\" \"テスト2.txt\" False -- doesn't work\r\n print \"copyFile doesn't work if first argument has national path.\"\r\n}}}\r\n\r\n{{{\r\nC:\\home>runghc.exe Test.hs\r\n\"copyFile works if second argument has national path.\"\r\n\"copyFile doesn't work if second argument has national path.\"\r\n\"copyFile doesn't work if first argument has national path.\"\r\n}}}\r\n\r\nAnd findExecutable return Nothing if executable file name has national symbols.\r\n\r\n{{{\r\nimport System.Directory -- hiding (getDirectoryContents)\r\n\r\nmain = findExecutable \"テスト\" >>= print\r\n}}}\r\n\r\n{{{\r\nC:\\home>runghc.exe Test.hs\r\nNothing\r\n}}}\r\n\r\nSo, I made patch for these two problems.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2https://gitlab.haskell.org/ghc/ghc/-/issues/3131GHC stops after a single 'defined but not used' warning2019-07-07T19:05:13Znr@eecs.harvard.eduGHC stops after a single 'defined but not used' warningUsing `-Wall -Werror`, GHC stops after finding a single "defined but not used" warning:
```
cmm/ZDF3.hs:795:10: Warning: Defined but not used: `rew_CO'
```
I'm sweeping away old code and would much prefer that GHC find *all* the define...Using `-Wall -Werror`, GHC stops after finding a single "defined but not used" warning:
```
cmm/ZDF3.hs:795:10: Warning: Defined but not used: `rew_CO'
```
I'm sweeping away old code and would much prefer that GHC find *all* the defined-but-not-used identifiers on a single run. The transitive closure would be ideal, but I would settle for just all the ones that are defined but not used.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"GHC stops after a single 'defined but not used' warning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using {{{-Wall -Werror}}}, GHC stops after finding a single \"defined but not used\" warning:\r\n{{{\r\ncmm/ZDF3.hs:795:10: Warning: Defined but not used: `rew_CO'\r\n}}}\r\nI'm sweeping away old code and would much prefer that GHC find ''all'' the defined-but-not-used identifiers on a single run. The transitive closure would be ideal, but I would settle for just all the ones that are defined but not used.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3132cgCase of PrimAlts needs care in new codegen2019-07-21T19:53:10ZBertram FelgenhauercgCase of PrimAlts needs care in new codegenThe following code,
```
module Spring where
import Data.Array.Unboxed
type Arr = UArray Int Double
data Spring = Spring !Double !Int !Arr deriving Show
step :: Double -> Spring -> Spring
step h (Spring k sz y) = let
f arr = listA...The following code,
```
module Spring where
import Data.Array.Unboxed
type Arr = UArray Int Double
data Spring = Spring !Double !Int !Arr deriving Show
step :: Double -> Spring -> Spring
step h (Spring k sz y) = let
f arr = listArray (0, 2*sz-1) (velocity ++ accel)
where
velocity = [arr ! i | i <- [sz .. 2*sz-1]]
k' = k * fromIntegral sz^2
accel = [0] ++ [k' * (arr!(i-1) - 2 * arr!i + arr!(i+1))
| i <- [1 .. sz-2]]
++ [k' * (arr!(sz-2) - arr!(sz-1))]
(.*) :: Double -> Arr -> Arr
a .* b = listArray (0, 2*sz-1) $ map (a*) (elems b)
(<+>) :: Arr -> Arr -> Arr
a <+> b = listArray (0, 2*sz-1) $ zipWith (+) (elems a) (elems b)
-- order 4 Runge-Kutta
k1 = h .* f y
k2 = h .* f (y <+> (0.5 .* k1))
k3 = h .* f (y <+> (0.5 .* k2))
k4 = h .* f (y <+> k3)
y' = y <+> ((1/6) .* (k1 <+> (2 .* (k2 <+> k3)) <+> k4))
in
Spring k sz y'
```
doesn't compile with optimization in ghc-6.11:
```
# ghc -O -c Bug.hs
/tmp/ghc12296_0/ghc12296_0.s: Assembler messages:
/tmp/ghc12296_0/ghc12296_0.s:2355:0:
Error: bad register name `%st(-8)'
/tmp/ghc12296_0/ghc12296_0.s:2384:0:
Error: bad register name `%st(-8)'
/tmp/ghc12296_0/ghc12296_0.s:2563:0:
Error: bad register name `%st(-8)'
/tmp/ghc12296_0/ghc12296_0.s:2602:0:
Error: bad register name `%st(-8)'
/tmp/ghc12296_0/ghc12296_0.s:3006:0:
Error: bad register name `%fake0'
/tmp/ghc12296_0/ghc12296_0.s:3023:0:
Error: bad register name `%fake0'
```
It's odd, first it tries to assign a closure pointer to an FPU register:
```
movl $r1sa_closure,%fake0
```
and later it uses register 0 (%eax) as an operand to an FPU operation:
```
# gsubl %fake1,%eax,%fake1
#GSUB-xxxcase1
ffree %st(7) ; fld %st(-8) ; fsubrp %st(0),%st(2)
```
Using `-fregs-graph` didn't help.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86 code generator generates bad FPU register names","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code,\r\n\r\n{{{\r\nmodule Spring where\r\n\r\nimport Data.Array.Unboxed\r\n\r\ntype Arr = UArray Int Double\r\ndata Spring = Spring !Double !Int !Arr deriving Show\r\n\r\nstep :: Double -> Spring -> Spring\r\nstep h (Spring k sz y) = let\r\n f arr = listArray (0, 2*sz-1) (velocity ++ accel)\r\n where\r\n velocity = [arr ! i | i <- [sz .. 2*sz-1]]\r\n k' = k * fromIntegral sz^2\r\n accel = [0] ++ [k' * (arr!(i-1) - 2 * arr!i + arr!(i+1))\r\n | i <- [1 .. sz-2]]\r\n ++ [k' * (arr!(sz-2) - arr!(sz-1))]\r\n (.*) :: Double -> Arr -> Arr\r\n a .* b = listArray (0, 2*sz-1) $ map (a*) (elems b)\r\n (<+>) :: Arr -> Arr -> Arr\r\n a <+> b = listArray (0, 2*sz-1) $ zipWith (+) (elems a) (elems b)\r\n -- order 4 Runge-Kutta\r\n k1 = h .* f y\r\n k2 = h .* f (y <+> (0.5 .* k1))\r\n k3 = h .* f (y <+> (0.5 .* k2))\r\n k4 = h .* f (y <+> k3)\r\n y' = y <+> ((1/6) .* (k1 <+> (2 .* (k2 <+> k3)) <+> k4))\r\n in\r\n Spring k sz y'\r\n}}}\r\n\r\ndoesn't compile with optimization in ghc-6.11:\r\n\r\n{{{\r\n# ghc -O -c Bug.hs\r\n/tmp/ghc12296_0/ghc12296_0.s: Assembler messages:\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:2355:0:\r\n Error: bad register name `%st(-8)'\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:2384:0:\r\n Error: bad register name `%st(-8)'\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:2563:0:\r\n Error: bad register name `%st(-8)'\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:2602:0:\r\n Error: bad register name `%st(-8)'\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:3006:0:\r\n Error: bad register name `%fake0'\r\n\r\n/tmp/ghc12296_0/ghc12296_0.s:3023:0:\r\n Error: bad register name `%fake0'\r\n}}}\r\n\r\nIt's odd, first it tries to assign a closure pointer to an FPU register:\r\n{{{\r\n movl $r1sa_closure,%fake0\r\n}}}\r\nand later it uses register 0 (%eax) as an operand to an FPU operation:\r\n{{{\r\n# gsubl %fake1,%eax,%fake1\r\n #GSUB-xxxcase1\r\n ffree %st(7) ; fld %st(-8) ; fsubrp %st(0),%st(2)\r\n}}}\r\nUsing {{{-fregs-graph}}} didn't help.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3133Biographical profiling segfaults2019-07-07T19:05:13ZbasvandijkBiographical profiling segfaultsWhen I try to make a biographical profile of my program I get a segmentation fault:
```
$ ghc --make <prog>.hs -prof -auto-all
$ ./<prog> +RTS -hb
Segmentation fault
```
Note that I don't get a segmentation fault when I run the program...When I try to make a biographical profile of my program I get a segmentation fault:
```
$ ghc --make <prog>.hs -prof -auto-all
$ ./<prog> +RTS -hb
Segmentation fault
```
Note that I don't get a segmentation fault when I run the program without -hb or generate other memory usage profiles.
Also note that the program itself probably doesn't matter: I tried two different programs and got a segmentation fault each time. For what it's worth, here are they:
```
module Main where
import System.Environment (getArgs)
main :: IO ()
main = print . sum . enumFromTo (0::Int) . read . head =<< getArgs
```
```
module Main where
import Prelude hiding (foldl)
import System.Environment (getArgs)
foldl :: (b -> a -> b) -> b -> [a] -> b
foldl f z [] = z
foldl f z (x:xs) = let z' = f z x
in foldl f z' xs
sum2 :: [Int] -> Int
sum2 = foldl (+) 0
main :: IO()
main = print
. sum2
. enumFromTo 1
. read
. head =<< getArgs
```
Info:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ uname -a
Linux bassbox 2.6.27-gentoo-r8 #4 PREEMPT Mon Mar 23 10:33:24 CET 2009 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Biographical profiling segfaults","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to make a biographical profile of my program I get a segmentation fault:\r\n\r\n{{{\r\n$ ghc --make <prog>.hs -prof -auto-all\r\n$ ./<prog> +RTS -hb\r\nSegmentation fault\r\n}}}\r\n\r\nNote that I don't get a segmentation fault when I run the program without -hb or generate other memory usage profiles.\r\n\r\nAlso note that the program itself probably doesn't matter: I tried two different programs and got a segmentation fault each time. For what it's worth, here are they:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Environment (getArgs)\r\n\r\nmain :: IO ()\r\nmain = print . sum . enumFromTo (0::Int) . read . head =<< getArgs\r\n}}}\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Prelude hiding (foldl)\r\nimport System.Environment (getArgs)\r\n\r\nfoldl :: (b -> a -> b) -> b -> [a] -> b\r\nfoldl f z [] = z\r\nfoldl f z (x:xs) = let z' = f z x\r\n in foldl f z' xs\r\n\r\nsum2 :: [Int] -> Int\r\nsum2 = foldl (+) 0\r\n\r\nmain :: IO()\r\nmain = print\r\n . sum2\r\n . enumFromTo 1\r\n . read\r\n . head =<< getArgs\r\n}}}\r\n\r\nInfo:\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n\r\n$ uname -a\r\nLinux bassbox 2.6.27-gentoo-r8 #4 PREEMPT Mon Mar 23 10:33:24 CET 2009 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3134encodeFloat . decodeFloat2020-05-05T19:26:59ZrolandencodeFloat . decodeFloat> (0.0/0.0)
NaN
> (uncurry encodeFloat . decodeFloat) (0.0/0.0)
-Infinity
It seems reasonable to expect NaN here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------...> (0.0/0.0)
NaN
> (uncurry encodeFloat . decodeFloat) (0.0/0.0)
-Infinity
It seems reasonable to expect NaN here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"encodeFloat . decodeFloat","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"> (0.0/0.0)\r\nNaN\r\n\r\n> (uncurry encodeFloat . decodeFloat) (0.0/0.0)\r\n-Infinity\r\n\r\nIt seems reasonable to expect NaN here.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3135ext-core docs missing from web site2019-07-07T19:05:12Zchevalier@alum.wellesley.eduext-core docs missing from web siteHello,
The .pdf doc for External Core seems to be missing from haskell.org. The link at:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html
points to:
http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf
but ...Hello,
The .pdf doc for External Core seems to be missing from haskell.org. The link at:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html
points to:
http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf
but the latter URL is broken.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ext-core docs missing from web site","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nThe .pdf doc for External Core seems to be missing from haskell.org. The link at:\r\nhttp://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html\r\npoints to:\r\nhttp://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf\r\nbut the latter URL is broken.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3136monad syntax extension2019-07-07T19:05:12Zneodymionmonad syntax extensionallow this:
print (readInt \[\<getLine\>\] + readInt \[\<getLine\>\])
(or some other kind of funky brackets)
to translate into
getLine\>\>=\\x-\>getLine\>\>=\\y-\>print (readInt x + readInt y)
<details><summary>Trac metadata</summary...allow this:
print (readInt \[\<getLine\>\] + readInt \[\<getLine\>\])
(or some other kind of funky brackets)
to translate into
getLine\>\>=\\x-\>getLine\>\>=\\y-\>print (readInt x + readInt y)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"monad syntax extension","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"allow this:\r\n\r\nprint (readInt [<getLine>] + readInt [<getLine>])\r\n\r\n(or some other kind of funky brackets)\r\nto translate into\r\n\r\ngetLine>>=\\x->getLine>>=\\y->print (readInt x + readInt y)\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3137ghc 6.10.2 fails to compile on Mac OS X Leopard2019-07-07T19:05:12Zmvanier@cs.caltech.edughc 6.10.2 fails to compile on Mac OS X LeopardCompiling GHC 6.10.2 on Mac OS X Leopard fails, apparently because of a library problem involving filepath (Cabal expects version 1.1.0.2, process and directory expect version 1.1.0.1). I'm attaching the output of make.
<details><summar...Compiling GHC 6.10.2 on Mac OS X Leopard fails, apparently because of a library problem involving filepath (Cabal expects version 1.1.0.2, process and directory expect version 1.1.0.1). I'm attaching the output of make.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc 6.10.2 fails to compile on Mac OS X Leopard","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling GHC 6.10.2 on Mac OS X Leopard fails, apparently because of a library problem involving filepath (Cabal expects version 1.1.0.2, process and directory expect version 1.1.0.1). I'm attaching the output of make.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3138Returning a known constructor: GHC generates terrible code for cmonad2022-03-07T08:31:02ZSimon Peyton JonesReturning a known constructor: GHC generates terrible code for cmonadLennart reports that GHC generates very poor code for his cmonad package.
If you want to look at a simple example, look at the Inf.hs example
included in package `cmonad-0.1.1`.
It's very simple, and ghc generates fantastically bad code ...Lennart reports that GHC generates very poor code for his cmonad package.
If you want to look at a simple example, look at the Inf.hs example
included in package `cmonad-0.1.1`.
It's very simple, and ghc generates fantastically bad code for it.
It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc seems to
ignore the INLINE directives and use dictionaries left and right.
When I looked at it a year ago or so, it was a return of one
constructor in a sum. That is, a function always returns the same constructor, so the case
analysis of the return value is not needed; it should be returned as
an unboxed tuple instead
Another unrelated problem, I think, is that ghc needs to promote
in-memory variables to registers when possible.
Perhaps the new code generator has such a transformation?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Returning a known constructor: GHC generates terrible code for cmonad","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Lennart reports that GHC generates very poor code for his cmonad package. \r\nIf you want to look at a simple example, look at the Inf.hs example\r\nincluded in package `cmonad-0.1.1`.\r\nIt's very simple, and ghc generates fantastically bad code for it.\r\n\r\nIt would be great if you could nail down why it's so amazingly unoptimal.\r\nEven with everything inlined and no overloading left, ghc seems to\r\nignore the INLINE directives and use dictionaries left and right.\r\nWhen I looked at it a year ago or so, it was a return of one\r\nconstructor in a sum. That is, a function always returns the same constructor, so the case\r\nanalysis of the return value is not needed; it should be returned as\r\nan unboxed tuple instead\r\n\r\nAnother unrelated problem, I think, is that ghc needs to promote\r\nin-memory variables to registers when possible.\r\nPerhaps the new code generator has such a transformation?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3139automate "cabal check" in ghc release process2019-07-07T19:05:11Zduncanautomate "cabal check" in ghc release processCurrently the release manager must run `cabal check` manually on each package to check for problems that might cause the packages to be rejected when uploaded to Hackage. This should be automated.
Ideally we would use a dedicated progra...Currently the release manager must run `cabal check` manually on each package to check for problems that might cause the packages to be rejected when uploaded to Hackage. This should be automated.
Ideally we would use a dedicated program to do the check because the `cabal` command line utility uses a stable version of the Cabal library but the latest version of the Cabal library often has additional QA checks.
This was the case for the ghc-6.10.2 release. Hackage rejected the upload of `containers-0.2.0.1` with the message:
```
Unfortunately the language extensions 'DeriveDataTypeable', 'MagicHash'
break the parser in earlier Cabal versions so you need to specify
'cabal-version: >= 1.2.3'. Alternatively if you require compatability
with earlier Cabal versions then you may be able to use an equivalent
compiler-specific flag.
```
This happened because this QA check is only implemented in Cabal-1.7.x, not in the stable version that the `cabal` tool currently uses.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"automate \"cabal check\" in ghc release process","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently the release manager must run `cabal check` manually on each package to check for problems that might cause the packages to be rejected when uploaded to Hackage. This should be automated.\r\n\r\nIdeally we would use a dedicated program to do the check because the `cabal` command line utility uses a stable version of the Cabal library but the latest version of the Cabal library often has additional QA checks.\r\n\r\nThis was the case for the ghc-6.10.2 release. Hackage rejected the upload of `containers-0.2.0.1` with the message:\r\n{{{\r\nUnfortunately the language extensions 'DeriveDataTypeable', 'MagicHash'\r\nbreak the parser in earlier Cabal versions so you need to specify\r\n'cabal-version: >= 1.2.3'. Alternatively if you require compatability\r\nwith earlier Cabal versions then you may be able to use an equivalent\r\ncompiler-specific flag.\r\n}}}\r\nThis happened because this QA check is only implemented in Cabal-1.7.x, not in the stable version that the `cabal` tool currently uses.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3140(Windows?) GHCi doesn't load hierachical modules2019-07-07T19:05:11ZOrphi(Windows?) GHCi doesn't load hierachical modulesOn Windows, if you double-click a `*.hs` file, GHCi starts up and loads the corresponding module. Usually this works fine, however... it seems to trip over on hierachical module names. Specifically:
- Create file `Foo\Bar.hs` containing...On Windows, if you double-click a `*.hs` file, GHCi starts up and loads the corresponding module. Usually this works fine, however... it seems to trip over on hierachical module names. Specifically:
- Create file `Foo\Bar.hs` containing a module `Foo.Bar` that imports `Foo.Baz`.
- Create file `Foo\Baz.hs` containing a module `Foo.Baz`.
- Double-click on `Foo\Bar.hs`; GHCi whines that it can't find `Foo.Baz` in the search path.
This happens regardless of whether either of the modules is compiled or not. An easy work-around is to invoke GHCi from the command prompt with the CWD below the `Foo` folder. But it's kind of tedious to have to do that.
Note that if `Foo.Bar` doesn't import anything (or only modules from packages) then it works just fine. GHCi just doesn't seem to be able to find source files in the current folder if they have hierachical names.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3141directory-1.0.0.3 needs base == 4.* in .cabal file.2019-07-07T19:05:11Zguestdirectory-1.0.0.3 needs base == 4.* in .cabal file.directory-1.0.0.3 imports Control.Exception.Base that is only exported since base-4.\* so "cabal install directory" fails.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -------------------...directory-1.0.0.3 imports Control.Exception.Base that is only exported since base-4.\* so "cabal install directory" fails.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.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":"directory-1.0.0.3 needs base == 4.* in .cabal file.","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"directory-1.0.0.3 imports Control.Exception.Base that is only exported since base-4.* so \"cabal install directory\" fails.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3142unix-2.3.2.0 needs base >= 4.1 in .cabal file2019-07-07T19:05:10Zguestunix-2.3.2.0 needs base >= 4.1 in .cabal fileFrom the hackage log\[1\] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (\>= 4.1) in build-depends.
\[1\]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10
<details><s...From the hackage log\[1\] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (\>= 4.1) in build-depends.
\[1\]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| 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":"unix-2.3.2.0 needs base >= 4.x in .cabal file","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From the hackage log[1] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (>= 4.1) in build-depends.\r\n\r\n[1]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3143Network.Socket.connect: support for sockets w/ bound local endpoints2019-07-07T19:05:10ZsofNetwork.Socket.connect: support for sockets w/ bound local endpointsJust in case this isn't taken care of by the ongoing rewrite of 'network',
but there's an age-old limitation in the implementation of
Network.Socket.connect -- it balks at being given a socket where the
local endpoint (port,iface) has al...Just in case this isn't taken care of by the ongoing rewrite of 'network',
but there's an age-old limitation in the implementation of
Network.Socket.connect -- it balks at being given a socket where the
local endpoint (port,iface) has already been bound.
i.e., it socket status test ought to be
> not (currentStatus `elem` \[NotConnected,Bound\])
The workaround of manually resetting SocketStatus always leaves me
feeling icky.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Network.Socket.connect: support for sockets w/ bound local endpoints","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just in case this isn't taken care of by the ongoing rewrite of 'network',\r\nbut there's an age-old limitation in the implementation of\r\nNetwork.Socket.connect -- it balks at being given a socket where the\r\nlocal endpoint (port,iface) has already been bound. \r\n\r\ni.e., it socket status test ought to be\r\n not (currentStatus `elem` [NotConnected,Bound]) \r\n\r\nThe workaround of manually resetting SocketStatus always leaves me\r\nfeeling icky.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->tibbetibbehttps://gitlab.haskell.org/ghc/ghc/-/issues/3144ghc panic2019-07-07T19:05:10Zfunmlerghc panicghci fails with
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
> interactiveUI:setBuffering2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -------------...ghci fails with
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
> interactiveUI:setBuffering2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghci fails with\r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for i386-unknown-linux):\r\n interactiveUI:setBuffering2\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3145ImpredicativeTypes vs. LiberalTypeSynonyms2019-07-07T19:05:10ZMartijnVanSteenbergenImpredicativeTypes vs. LiberalTypeSynonymsConsider the following module:
```
{-# LANGUAGE Rank2Types #-}
module RunMud where
import Control.Monad.State
type Mud = StateT MudState IO
data MudState = MudState { mRunMud :: RunMud }
type RunMud = forall a. Mud a -> IO a
...Consider the following module:
```
{-# LANGUAGE Rank2Types #-}
module RunMud where
import Control.Monad.State
type Mud = StateT MudState IO
data MudState = MudState { mRunMud :: RunMud }
type RunMud = forall a. Mud a -> IO a
getRunMud :: Mud RunMud
getRunMud = do
s <- get
return (mRunMud s)
```
GHC suggests:
```
Illegal polymorphic or qualified type: RunMud
Perhaps you intended to use -XImpredicativeTypes
```
When I add a language pragma for ImpredicativeTypes, GHC stills comes up with the same error message.
Two questions:
1) Can GHC please not suggest enabling extensions that are already enabled? It's very confusing.
2) Can GHC in this specific case suggest LiberalTypeSynonyms? That's the third extension that needed to be on for this example to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ImpredicativeTypes vs. LiberalTypeSynonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following module:\r\n\r\n{{{\r\n{-# LANGUAGE Rank2Types #-}\r\n\r\nmodule RunMud where\r\n\r\nimport Control.Monad.State\r\n\r\ntype Mud = StateT MudState IO\r\ndata MudState = MudState { mRunMud :: RunMud }\r\ntype RunMud = forall a. Mud a -> IO a\r\n\r\ngetRunMud :: Mud RunMud\r\ngetRunMud = do\r\n s <- get\r\n return (mRunMud s)\r\n}}}\r\n\r\nGHC suggests:\r\n\r\n{{{\r\nIllegal polymorphic or qualified type: RunMud\r\nPerhaps you intended to use -XImpredicativeTypes\r\n}}}\r\n\r\nWhen I add a language pragma for ImpredicativeTypes, GHC stills comes up with the same error message.\r\n\r\nTwo questions:\r\n\r\n1) Can GHC please not suggest enabling extensions that are already enabled? It's very confusing.\r\n\r\n2) Can GHC in this specific case suggest LiberalTypeSynonyms? That's the third extension that needed to be on for this example to compile.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3146Testsuite for 6.10.2 fails if ghc is not already installed.2019-07-07T19:05:09Zgwright@antiope.comTestsuite for 6.10.2 fails if ghc is not already installed.The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.
Attached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to ...The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.
Attached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to fix this. The patches force the use of the newly built hsc2hs. (The changes handle hsc2hs in the same way ghc-pkg is handled.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite for 6.10.2 fails if ghc is not already installed.","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.\r\n\r\nAttached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to fix this. The patches force the use of the newly built hsc2hs. (The changes handle hsc2hs in the same way ghc-pkg is handled.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3147Testsuite for 6.10.2 fails if ghc is not already installed.2019-07-07T19:05:09Zgwright@antiope.comTestsuite for 6.10.2 fails if ghc is not already installed.The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.
Attached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to ...The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.
Attached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to fix this. The patches force the use of the newly built hsc2hs. (The changes handle hsc2hs in the same way ghc-pkg is handled.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite for 6.10.2 fails if ghc is not already installed.","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The testsuite for ghc 6.10.2 fails if ghc is not already installed, because building at least one of the utilities requires hsc2hs.\r\n\r\nAttached are patches to the testsuite-6.10.2/mk/boilerplate.mk and testsuite-6.10.2/timeout/Makefile to fix this. The patches force the use of the newly built hsc2hs. (The changes handle hsc2hs in the same way ghc-pkg is handled.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3148build failure of GHC 6.10.2 release on arm-unknown-linux platform2019-07-07T19:05:09Zkgardasbuild failure of GHC 6.10.2 release on arm-unknown-linux platformHello,
I've attempted to build GHC 6.10.2 release on arm-unknown-linux platform, but build fails with:
```
/home/user/src/ghc-6.10.2/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-na...Hello,
I've attempted to build GHC 6.10.2 release on arm-unknown-linux platform, but build fails with:
```
/home/user/src/ghc-6.10.2/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o
/tmp/ghc16399_0/ghc16399_0.hc: In function ‘stg_ap_0_fast’:
/tmp/ghc16399_0/ghc16399_0.hc:15:0:
warning: implicit declaration of function ‘JMP_’
ghc-asm: don't know how to mangle assembly language for: arm-unknown-linux
make[1]: *** [Apply.o] Error 1
make[1]: Leaving directory `/home/user/src/ghc-6.10.2/rts'
make: *** [stage1] Error 2
```
to perform the build I've done common:
```
./configure --prefix=/tmp/ghc-6.10.2-bin
make
```
The linux is Debian 4.0 running on simulated armv5tel (Qemu):
```
debian-arm:~# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 589.82
Features : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Cache type : write-through
Cache clean : not required
Cache lockdown : not supported
Cache format : Harvard
I size : 4096
I assoc : 4
I line length : 32
I sets : 32
D size : 65536
D assoc : 4
D line length : 32
D sets : 512
Hardware : ARM-Versatile PB
Revision : 0000
Serial : 0000000000000000
debian-arm:~#
```
I'm using Debian provided GHC, which is version 6.6:
```
debian-arm:~# ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6
debian-arm:~# ghc-pkg -l
/usr/lib/ghc-6.6/package.conf:
Cabal-1.1.6, base-2.0, (ghc-6.6), haskell98-1.0, parsec-2.0,
readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71,
rts-1.0, stm-2.0, template-haskell-2.0, unix-1.0
debian-arm:~#
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"build failure of GHC 6.10.2 release on arm-unknown-linux platform","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\nI've attempted to build GHC 6.10.2 release on arm-unknown-linux platform, but build fails with:\r\n{{{\r\n/home/user/src/ghc-6.10.2/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o\r\n/tmp/ghc16399_0/ghc16399_0.hc: In function ‘stg_ap_0_fast’:\r\n\r\n/tmp/ghc16399_0/ghc16399_0.hc:15:0:\r\n warning: implicit declaration of function ‘JMP_’\r\nghc-asm: don't know how to mangle assembly language for: arm-unknown-linux\r\nmake[1]: *** [Apply.o] Error 1\r\nmake[1]: Leaving directory `/home/user/src/ghc-6.10.2/rts'\r\nmake: *** [stage1] Error 2\r\n}}}\r\n\r\nto perform the build I've done common:\r\n{{{\r\n./configure --prefix=/tmp/ghc-6.10.2-bin\r\nmake\r\n}}}\r\n\r\nThe linux is Debian 4.0 running on simulated armv5tel (Qemu):\r\n{{{\r\ndebian-arm:~# cat /proc/cpuinfo \r\nProcessor : ARM926EJ-S rev 5 (v5l)\r\nBogoMIPS : 589.82\r\nFeatures : swp half fastmult edsp java \r\nCPU implementer : 0x41\r\nCPU architecture: 5TEJ\r\nCPU variant : 0x0\r\nCPU part : 0x926\r\nCPU revision : 5\r\nCache type : write-through\r\nCache clean : not required\r\nCache lockdown : not supported\r\nCache format : Harvard\r\nI size : 4096\r\nI assoc : 4\r\nI line length : 32\r\nI sets : 32\r\nD size : 65536\r\nD assoc : 4\r\nD line length : 32\r\nD sets : 512\r\n\r\nHardware : ARM-Versatile PB\r\nRevision : 0000\r\nSerial : 0000000000000000\r\ndebian-arm:~# \r\n}}}\r\n\r\nI'm using Debian provided GHC, which is version 6.6:\r\n{{{\r\ndebian-arm:~# ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.6\r\ndebian-arm:~# ghc-pkg -l\r\n/usr/lib/ghc-6.6/package.conf:\r\n Cabal-1.1.6, base-2.0, (ghc-6.6), haskell98-1.0, parsec-2.0,\r\n readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71,\r\n rts-1.0, stm-2.0, template-haskell-2.0, unix-1.0\r\ndebian-arm:~# \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3149Data.HashTable is slow2019-07-07T19:05:08ZdonsData.HashTable is slowData.HashTable is slow. Implement something non-naive, and move it out of base. It's a bit embarassing. See e.g.
```
import Prelude hiding (lookup)
import Data.HashTable (hashInt, fromList, lookup)
n :: Int
n = 10000000
l :: [Int]
l =...Data.HashTable is slow. Implement something non-naive, and move it out of base. It's a bit embarassing. See e.g.
```
import Prelude hiding (lookup)
import Data.HashTable (hashInt, fromList, lookup)
n :: Int
n = 10000000
l :: [Int]
l = [1..n]
stream :: [(Int, Int)]
stream = zip l l
main = do
m <- fromList hashInt stream
v <- lookup m 100
print v
```
Maybe just port the OCaml standard hashtable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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.HashTable is slow","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Data.HashTable is slow. Implement something non-naive, and move it out of base. It's a bit embarassing. See e.g.\r\n \r\n{{{\r\nimport Prelude hiding (lookup)\r\nimport Data.HashTable (hashInt, fromList, lookup)\r\n\r\nn :: Int\r\nn = 10000000\r\n\r\nl :: [Int]\r\nl = [1..n]\r\n\r\nstream :: [(Int, Int)]\r\nstream = zip l l\r\n\r\nmain = do\r\n m <- fromList hashInt stream\r\n v <- lookup m 100\r\n print v\r\n\r\n}}}\r\n\r\nMaybe just port the OCaml standard hashtable?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3150Overlapping data instances can segfault2019-07-07T19:05:08ZguestOverlapping data instances can segfaultWhen exploring data families for some fast unboxed tuple representation, we came across the following scenario.
```
class Foo a where
data Bar a :: *
instance Foo a where
data Bar a = PBar a
instance Foo () where
data Bar ...When exploring data families for some fast unboxed tuple representation, we came across the following scenario.
```
class Foo a where
data Bar a :: *
instance Foo a where
data Bar a = PBar a
instance Foo () where
data Bar () = PUnit
```
```
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, modules loaded: Main.
*Main> case PUnit of PBar x -> x
Segmentation fault
```
It appears the compiler is allowing the refinement of a into () because they overlap, when it shouldn't.
This is less academic than this example, because it affects doing similar operations to automatically unbox tuples of primitives when possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Overlapping data instances can segfault","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett@gmail.com"],"type":"Bug","description":"When exploring data families for some fast unboxed tuple representation, we came across the following scenario.\r\n\r\n{{{\r\nclass Foo a where\r\n data Bar a :: *\r\n\r\ninstance Foo a where\r\n data Bar a = PBar a\r\n\r\ninstance Foo () where\r\n data Bar () = PUnit\r\n}}}\r\n\r\n{{{\r\n\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( Foo.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> case PUnit of PBar x -> x\r\nSegmentation fault\r\n}}}\r\n\r\nIt appears the compiler is allowing the refinement of a into () because they overlap, when it shouldn't.\r\n\r\nThis is less academic than this example, because it affects doing similar operations to automatically unbox tuples of primitives when possible.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3151Hello World does not compile (missing Prelude?)2019-07-07T19:05:08Zfft1976Hello World does not compile (missing Prelude?)Note: This is actually 6.10.2 (the Ticket Properties does not give this choice)
```
$ cat hello.hs
main = do
putStrLn "Hello, World"
$ which ghc
/home/t/local/bin/ghc
$ ghc --version
The Glorious Glasgow Haskell Compilation System, ...Note: This is actually 6.10.2 (the Ticket Properties does not give this choice)
```
$ cat hello.hs
main = do
putStrLn "Hello, World"
$ which ghc
/home/t/local/bin/ghc
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.2
$ ghc --make hello
[1 of 1] Compiling Main ( hello.hs, hello.o )
hello.hs:1:0:
Failed to load interface for `Prelude':
Use -v to see a list of the files searched for.
```
Ubuntu 8.04 GHC 6.8.2 works though:
```
$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
$ /usr/bin/ghc --make hello
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
$ ./hello
Hello, World
```
```
$ ghc -v --make hello
```
Prints lots of stuff, including:
```
hello.hs:1:0:
Failed to load interface for `Prelude':
locations searched:
Prelude.hs
Prelude.lhs
```
Indeed, Prelude seems to be missing:
```
$ cd ~/local/lib/ghc-6.10.2/
$ find . -name \*elude\*
```
I can also confirm another bug report (the reason is likely the same):
```
$ ghci
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
interactiveUI:setBuffering2
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Hello World does not compile (missing Prelude?)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Note: This is actually 6.10.2 (the Ticket Properties does not give this choice)\r\n\r\n{{{\r\n$ cat hello.hs \r\nmain = do\r\n putStrLn \"Hello, World\"\r\n\r\n$ which ghc\r\n/home/t/local/bin/ghc\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.2\r\n$ ghc --make hello\r\n[1 of 1] Compiling Main ( hello.hs, hello.o )\r\n\r\nhello.hs:1:0:\r\n Failed to load interface for `Prelude':\r\n Use -v to see a list of the files searched for.\r\n}}}\r\n\r\nUbuntu 8.04 GHC 6.8.2 works though:\r\n\r\n{{{\r\n$ /usr/bin/ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.8.2\r\n$ /usr/bin/ghc --make hello\r\n[1 of 1] Compiling Main ( hello.hs, hello.o )\r\nLinking hello ...\r\n$ ./hello \r\nHello, World\r\n}}}\r\n\r\n\r\n{{{\r\n$ ghc -v --make hello\r\n}}}\r\nPrints lots of stuff, including:\r\n{{{\r\nhello.hs:1:0:\r\n Failed to load interface for `Prelude':\r\n locations searched:\r\n Prelude.hs\r\n Prelude.lhs\r\n}}}\r\n\r\nIndeed, Prelude seems to be missing:\r\n\r\n{{{\r\n$ cd ~/local/lib/ghc-6.10.2/\r\n$ find . -name \\*elude\\*\r\n}}}\r\n\r\nI can also confirm another bug report (the reason is likely the same):\r\n{{{\r\n$ ghci\r\nGHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for i386-unknown-linux):\r\n\tinteractiveUI:setBuffering2\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3152Documentation for getProcessExitCode contains nonsense2019-07-07T19:05:08ZYitzGaleDocumentation for getProcessExitCode contains nonsenseThe documentation for the function `getProcessExitCode` contains the following
nonsense sentence:
> Subsequent calls to `getProcessExitStatus` always return `Just ExitSuccess`, regardless of what the original exit code was.
If "getProc...The documentation for the function `getProcessExitCode` contains the following
nonsense sentence:
> Subsequent calls to `getProcessExitStatus` always return `Just ExitSuccess`, regardless of what the original exit code was.
If "getProcessExitStatus" is changed to "getProcessExitCode", the sentence is
no longer nonsense - it is false.
Apparently, this entire sentence should just be deleted.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for getProcessExitCode contains nonsense","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["documentation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The documentation for the function {{{getProcessExitCode}}} contains the following\r\nnonsense sentence:\r\n\r\n Subsequent calls to {{{getProcessExitStatus}}} always return {{{Just ExitSuccess}}}, regardless of what the original exit code was.\r\n\r\nIf \"getProcessExitStatus\" is changed to \"getProcessExitCode\", the sentence is\r\nno longer nonsense - it is false.\r\n\r\nApparently, this entire sentence should just be deleted.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3153Panic on syntactically wrong LANGUAGE pragma2019-07-07T19:05:07Zb_jonasPanic on syntactically wrong LANGUAGE pragmaI'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic.
I'm using ghc-6.10.2 compiled from vanilla sources (with extralibs...I'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic.
I'm using ghc-6.10.2 compiled from vanilla sources (with extralibs and a few options in build.mk) on an amd64 debian etch linux system.
Below you can see a transscript of the compilation including the panic message, and the source code.
```
[am]king ~/a/tmp$ runghc Bug
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for x86_64-unknown-linux):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
1[am]king ~/a/tmp$ cat Bug.hs
{-# LANGUAGE - #-}
main = return ();
[am]king ~/a/tmp$ cat -A Bug.hs
{-# LANGUAGE - #-}$
main = return ();$
[am]king ~/a/tmp$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.3/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.3.3 (GCC)
[am]king ~/a/tmp$ runghc -v -dcore-lint Bug
Glasgow Haskell Compiler, Version 6.10.2, for Haskell 98, stage 2 booted by GHC version 6.10.1
Using package config file: /usr/local/ghc/lib/ghc-6.10.2/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -ignore-dot-ghci -static
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *Bug.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for x86_64-unknown-linux):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
1[am]king ~/a/tmp$
```
(I found this bug when I tried to start a program with `{-# LANGUAGE -XPatternGuards #-}`.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Panic on syntactically wrong LANGUAGE pragma","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic. \r\n\r\nI'm using ghc-6.10.2 compiled from vanilla sources (with extralibs and a few options in build.mk) on an amd64 debian etch linux system. \r\n\r\nBelow you can see a transscript of the compilation including the panic message, and the source code. \r\n\r\n{{{\r\n[am]king ~/a/tmp$ runghc Bug\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for x86_64-unknown-linux):\r\n\tgetOptions'.parseLanguage(2) went past eof token\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n1[am]king ~/a/tmp$ cat Bug.hs\r\n{-# LANGUAGE - #-}\r\nmain = return ();\r\n[am]king ~/a/tmp$ cat -A Bug.hs\r\n{-# LANGUAGE - #-}$\r\nmain = return ();$\r\n[am]king ~/a/tmp$ gcc -v\r\nUsing built-in specs.\r\nTarget: x86_64-unknown-linux-gnu\r\nConfigured with: ../gcc-4.3.3/configure --enable-languages=c,c++\r\nThread model: posix\r\ngcc version 4.3.3 (GCC) \r\n[am]king ~/a/tmp$ runghc -v -dcore-lint Bug\r\nGlasgow Haskell Compiler, Version 6.10.2, for Haskell 98, stage 2 booted by GHC version 6.10.1\r\nUsing package config file: /usr/local/ghc/lib/ghc-6.10.2/./package.conf\r\nhiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.1\r\nwired-in package base mapped to base-4.1.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.1\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.1\r\nwired-in package dph-seq mapped to dph-seq-0.3\r\nwired-in package dph-par mapped to dph-par-0.3\r\nHsc static flags: -ignore-dot-ghci -static\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n*** Chasing dependencies:\r\nChasing modules from: \r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Chasing dependencies:\r\nChasing modules from: *Bug.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for x86_64-unknown-linux):\r\n\tgetOptions'.parseLanguage(2) went past eof token\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: \r\n1[am]king ~/a/tmp$ \r\n}}}\r\n\r\n(I found this bug when I tried to start a program with `{-# LANGUAGE -XPatternGuards #-}`.)","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3154Type families bug with data family instances2019-07-07T19:05:07ZtrevorType families bug with data family instancesThis data family definition led to the ability to define a generic cast:
```
{-# LANGUAGE TypeFamilies #-}
data family T a b t
data instance T a b t = L a
data instance T a b () = R b
cast :: a -> b
cast x = let L i = R x in i
get :...This data family definition led to the ability to define a generic cast:
```
{-# LANGUAGE TypeFamilies #-}
data family T a b t
data instance T a b t = L a
data instance T a b () = R b
cast :: a -> b
cast x = let L i = R x in i
get :: IO Char
get = cast ()
```
This bug was observed in ghc version 6.10.1, 6.10.1.20090326 and 6.10.2.
```
% ghci test.hs
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> get
'\4312564'
*Main> get
<interactive>: internal error: stg_ap_v_ret
(GHC version 6.10.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
zsh: abort ghci test.hs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type families bug with data family instances","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["families","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This data family definition led to the ability to define a generic cast:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ndata family T a b t\r\ndata instance T a b t = L a\r\ndata instance T a b () = R b\r\n\r\ncast :: a -> b\r\ncast x = let L i = R x in i\r\n\r\nget :: IO Char\r\nget = cast ()\r\n}}}\r\n\r\nThis bug was observed in ghc version 6.10.1, 6.10.1.20090326 and 6.10.2.\r\n\r\n{{{\r\n% ghci test.hs\r\nGHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( test.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> get\r\n'\\4312564'\r\n*Main> get\r\n<interactive>: internal error: stg_ap_v_ret\r\n (GHC version 6.10.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nzsh: abort ghci test.hs\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3155TypeOperators/Rank2Types clash2019-07-07T19:05:07ZMartijnVanSteenbergenTypeOperators/Rank2Types clashConsider the following piece of code:
```
{-# LANGUAGE GADTs #-}
data Any s where
Any :: s ix -> ix -> Any s
data AnyR s r where
AnyR :: s ix -> r ix -> AnyR s r
unR :: (forall ix. r ix -> ix) -> AnyR s r -> Any s
unR f (AnyR ix ...Consider the following piece of code:
```
{-# LANGUAGE GADTs #-}
data Any s where
Any :: s ix -> ix -> Any s
data AnyR s r where
AnyR :: s ix -> r ix -> AnyR s r
unR :: (forall ix. r ix -> ix) -> AnyR s r -> Any s
unR f (AnyR ix rix) = Any ix (f rix)
```
GHC reports:
```
Illegal operator `.' in type `forall ix . (r ix -> ix)'
Perhaps you intended to use -XRankNTypes or similar flag
to enable explicit-forall syntax: forall <tvs>. <type>
```
Enabling TypeOperators causes the error to change to:
```
Occurs check: cannot construct the infinite type: ix = r ix
In the pattern: AnyR ix rix
In the definition of `unR': unR f (AnyR ix rix) = Any ix (f rix)
```
Which is very confusing, as the solution (still) is to turn on Rank2Types.
Could it be made so that the error message stays the same when TypeOperators is turned on?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"TypeOperators/Rank2Types clash","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following piece of code:\r\n\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\n\r\ndata Any s where\r\n Any :: s ix -> ix -> Any s\r\n\r\ndata AnyR s r where\r\n AnyR :: s ix -> r ix -> AnyR s r\r\n\r\nunR :: (forall ix. r ix -> ix) -> AnyR s r -> Any s\r\nunR f (AnyR ix rix) = Any ix (f rix)\r\n}}}\r\n\r\nGHC reports:\r\n\r\n{{{\r\n Illegal operator `.' in type `forall ix . (r ix -> ix)'\r\n Perhaps you intended to use -XRankNTypes or similar flag\r\n to enable explicit-forall syntax: forall <tvs>. <type>\r\n}}}\r\n\r\nEnabling TypeOperators causes the error to change to:\r\n\r\n{{{\r\n Occurs check: cannot construct the infinite type: ix = r ix\r\n In the pattern: AnyR ix rix\r\n In the definition of `unR': unR f (AnyR ix rix) = Any ix (f rix)\r\n}}}\r\n\r\nWhich is very confusing, as the solution (still) is to turn on Rank2Types.\r\n\r\nCould it be made so that the error message stays the same when TypeOperators is turned on?\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3156Error on +RTS kHugeNumber2019-07-07T19:05:07ZzachkError on +RTS kHugeNumberIt is in either 6.10.2 or 6.10.1 I forget which
```
./p 1 -> works
./p 2 -> works
./p 3 -> error
./p 4 -> error
```
p is a shell script
I am passing a huge number in for stack size, ghc did say report it, so I am.
ghc -O3 --make poly...It is in either 6.10.2 or 6.10.1 I forget which
```
./p 1 -> works
./p 2 -> works
./p 3 -> error
./p 4 -> error
```
p is a shell script
I am passing a huge number in for stack size, ghc did say report it, so I am.
ghc -O3 --make poly
FILES ARE ATTACHED::6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3157ghci segmentation fault when computation is interrupted2019-07-07T19:05:07Zfft1976ghci segmentation fault when computation is interruptedThis is using Ubuntu 8.04. Both source-compiled and binary (libedit2) show this behavior.
```
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... link...This is using Ubuntu 8.04. Both source-compiled and binary (libedit2) show this behavior.
```
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> let a = a
Prelude> a
```
Then I press Ctrl-C
```
Segmentation fault
$
```
Potentially relevant:
```
$ dpkg -l | grep libedit
ii libedit-dev 2.9.cvs.20050518-4 BSD editline and history libraries (developm
ii libedit2 2.9.cvs.20050518-4 BSD editline and history libraries
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci segmentation fault when computation is interrupted","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["ghci"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is using Ubuntu 8.04. Both source-compiled and binary (libedit2) show this behavior.\r\n{{{\r\nGHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nPrelude> let a = a\r\nPrelude> a\r\n\r\n}}}\r\nThen I press Ctrl-C\r\n{{{\r\nSegmentation fault\r\n$ \r\n}}}\r\n\r\nPotentially relevant:\r\n{{{\r\n$ dpkg -l | grep libedit\r\nii libedit-dev 2.9.cvs.20050518-4 BSD editline and history libraries (developm\r\nii libedit2 2.9.cvs.20050518-4 BSD editline and history libraries\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3158Linker error (libffi.so.5) in 6.10.2 x86-Linux binary distribution2019-07-07T19:05:06ZguestLinker error (libffi.so.5) in 6.10.2 x86-Linux binary distributionHello,
I am running Debian Linux with the following uname(1):\[\[BR\]\]
Linux 2.6.18-6-686-bigmem #1 SMP Mon Aug 18 09:58:16 UTC 2008 i686 GNU/Linux
\[\[BR\]\]
I downloaded the tarball "http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-i...Hello,
I am running Debian Linux with the following uname(1):\[\[BR\]\]
Linux 2.6.18-6-686-bigmem #1 SMP Mon Aug 18 09:58:16 UTC 2008 i686 GNU/Linux
\[\[BR\]\]
I downloaded the tarball "http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-i386-unknown-linux-libedit2.tar.bz2".
After doing "configure" and "make install", I got the following output:\[\[BR\]\]
\<snip\> Begin log \</snip\>\[\[BR\]\]
\[\[BR\]\]
=======================================================================\[\[BR\]\]
Installation of ghc-6.10.2 was successful.\[\[BR\]\]
To use, add /h/uhs/pkg/ghc-6.10.2/bin to your PATH.\[\[BR\]\]
For documentation, see /h/uhs/pkg/ghc-6.10.2/share/doc/ghc/index.html\[\[BR\]\]
=======================================================================\[\[BR\]\]
haddock-2.4.2: dependency Cabal-1.6.0.3 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency array-0.2.0.0 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency base-4.1.0.0 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency containers-0.2.0.1 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency directory-1.0.0.3 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency filepath-1.1.0.2 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency ghc-6.10.2 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency haskell98-1.0.1.0 doesn't exist (ignoring)\[\[BR\]\]
haddock-2.4.2: dependency pretty-1.0.1.0 doesn't exist (ignoring)\[\[BR\]\]
rts-1.0: include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory (ignoring)\[\[BR\]\]
ifBuildable/ifBuildable: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory\[\[BR\]\]
\[... Many identical lines ...\]\[\[BR\]\]
ifBuildable/ifBuildable: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory\[\[BR\]\]
ghc-6.10.2: dependency Cabal-1.6.0.3 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency array-0.2.0.0 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency base-4.1.0.0 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency bytestring-0.9.1.4 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency containers-0.2.0.1 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency directory-1.0.0.3 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency editline-0.2.1.0 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency filepath-1.1.0.2 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency haskell98-1.0.1.0 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency hpc-0.5.0.3 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency old-time-1.0.0.2 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency process-1.0.1.1 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency template-haskell-2.3.0.1 doesn't exist (ignoring)\[\[BR\]\]
ghc-6.10.2: dependency unix-2.3.2.0 doesn't exist (ignoring)\[\[BR\]\]
\[\[BR\]\]
\<snip\> End log \</snip\>\[\[BR\]\]
\[\[BR\]\]
I tried to start ghci and got:\[\[BR\]\]
\<snip\> Begin log \</snip\>\[\[BR\]\]
\[\[BR\]\]
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help\[\[BR\]\]
ghc: panic! (the 'impossible' happened)\[\[BR\]\]
(GHC version 6.10.2 for i386-unknown-linux):\[\[BR\]\]
> interactiveUI:setBuffering2\[\[BR\]\]
\[\[BR\]\]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\[\[BR\]\]
\[\[BR\]\]
\<snip\> End log \</snip\>\[\[BR\]\]
\[\[BR\]\]
The same process (download, configure, make, run) worked fine for the 6.10.1 x86-Linux binary distribution.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linker error (libffi.so.5) in 6.10.2 x86-Linux binary distribution","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\nI am running Debian Linux with the following uname(1):[[BR]]\r\nLinux 2.6.18-6-686-bigmem #1 SMP Mon Aug 18 09:58:16 UTC 2008 i686 GNU/Linux\r\n[[BR]]\r\nI downloaded the tarball \"http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-i386-unknown-linux-libedit2.tar.bz2\".\r\nAfter doing \"configure\" and \"make install\", I got the following output:[[BR]]\r\n<snip> Begin log </snip>[[BR]]\r\n[[BR]]\r\n=======================================================================[[BR]]\r\nInstallation of ghc-6.10.2 was successful.[[BR]]\r\nTo use, add /h/uhs/pkg/ghc-6.10.2/bin to your PATH.[[BR]]\r\nFor documentation, see /h/uhs/pkg/ghc-6.10.2/share/doc/ghc/index.html[[BR]]\r\n=======================================================================[[BR]]\r\nhaddock-2.4.2: dependency Cabal-1.6.0.3 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency array-0.2.0.0 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency base-4.1.0.0 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency containers-0.2.0.1 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency directory-1.0.0.3 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency filepath-1.1.0.2 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency ghc-6.10.2 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency haskell98-1.0.1.0 doesn't exist (ignoring)[[BR]]\r\nhaddock-2.4.2: dependency pretty-1.0.1.0 doesn't exist (ignoring)[[BR]]\r\nrts-1.0: include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory (ignoring)[[BR]]\r\nifBuildable/ifBuildable: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory[[BR]]\r\n[... Many identical lines ...][[BR]]\r\nifBuildable/ifBuildable: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory[[BR]]\r\nghc-6.10.2: dependency Cabal-1.6.0.3 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency array-0.2.0.0 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency base-4.1.0.0 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency bytestring-0.9.1.4 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency containers-0.2.0.1 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency directory-1.0.0.3 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency editline-0.2.1.0 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency filepath-1.1.0.2 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency haskell98-1.0.1.0 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency hpc-0.5.0.3 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency old-time-1.0.0.2 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency process-1.0.1.1 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency template-haskell-2.3.0.1 doesn't exist (ignoring)[[BR]]\r\nghc-6.10.2: dependency unix-2.3.2.0 doesn't exist (ignoring)[[BR]]\r\n[[BR]]\r\n<snip> End log </snip>[[BR]]\r\n[[BR]]\r\nI tried to start ghci and got:[[BR]]\r\n<snip> Begin log </snip>[[BR]]\r\n[[BR]]\r\nGHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help[[BR]]\r\nghc: panic! (the 'impossible' happened)[[BR]]\r\n (GHC version 6.10.2 for i386-unknown-linux):[[BR]]\r\n interactiveUI:setBuffering2[[BR]]\r\n[[BR]]\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug[[BR]]\r\n[[BR]]\r\n<snip> End log </snip>[[BR]]\r\n[[BR]]\r\nThe same process (download, configure, make, run) worked fine for the 6.10.1 x86-Linux binary distribution.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3159QSem fails with negative quantities2019-07-07T19:05:06ZNeil MitchellQSem fails with negative quantitiesThe following program should always give 100 (I think). It doesn't:
```
import Data.IORef
import Control.Concurrent
main = do
sem <- newQSem (-99)
r <- newIORef 0
let incRef = atomicModifyIORef r (\a -> (a+1,a))
sequence_ $...The following program should always give 100 (I think). It doesn't:
```
import Data.IORef
import Control.Concurrent
main = do
sem <- newQSem (-99)
r <- newIORef 0
let incRef = atomicModifyIORef r (\a -> (a+1,a))
sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem
waitQSem sem
v <- readIORef r
print v
```
With a 2 processor machine on Windows, using GHC 6.8.3 and 6.10.2 and +RTS -N3 I usually get 100, but occasionally get answers such as 49, 82, 95. With +RTS -N2 it almost always works.
From reading the implementation of QSem, it doesn't seem that negative
availability was considered. A quick look suggests a better implementation might be:
```
-- Invariant: avail >= 1 ==> null blocked
waitQSem :: QSem -> IO ()
waitQSem (QSem sem) = do
(avail,blocked) <- takeMVar sem -- gain ex. access
if avail > 0 then
putMVar sem (avail-1,[])
else do
block <- newEmptyMVar
putMVar sem (avail, blocked++[block]) -- changed line
takeMVar block
signalQSem :: QSem -> IO ()
signalQSem (QSem sem) = do
(avail,blocked) <- takeMVar sem
-- changed below
if null blocked || avail < 0 then
putMVar sem (avail+1,blocked)
else
putMVar sem (avail, tail blocked)
putMVar (head blocked) ()
```
Writing parallel code is hard, so I could have easily got this wrong.
I haven't looked at QSemN, which may need similar fixes (or may
already deal with this)
Marking as severity major because it can cause incorrect parallel behaviour.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"QSem fails with negative quantities","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program should always give 100 (I think). It doesn't:\r\n\r\n{{{\r\nimport Data.IORef\r\nimport Control.Concurrent\r\n\r\nmain = do\r\n sem <- newQSem (-99)\r\n r <- newIORef 0\r\n let incRef = atomicModifyIORef r (\\a -> (a+1,a))\r\n sequence_ $ replicate 100 $ forkIO $ incRef >> signalQSem sem\r\n waitQSem sem\r\n v <- readIORef r\r\n print v\r\n}}}\r\n\r\nWith a 2 processor machine on Windows, using GHC 6.8.3 and 6.10.2 and +RTS -N3 I usually get 100, but occasionally get answers such as 49, 82, 95. With +RTS -N2 it almost always works.\r\n\r\nFrom reading the implementation of QSem, it doesn't seem that negative\r\navailability was considered. A quick look suggests a better implementation might be:\r\n\r\n{{{\r\n-- Invariant: avail >= 1 ==> null blocked\r\n\r\nwaitQSem :: QSem -> IO ()\r\nwaitQSem (QSem sem) = do\r\n (avail,blocked) <- takeMVar sem -- gain ex. access\r\n if avail > 0 then\r\n putMVar sem (avail-1,[])\r\n else do\r\n block <- newEmptyMVar\r\n putMVar sem (avail, blocked++[block]) -- changed line\r\n takeMVar block\r\n\r\nsignalQSem :: QSem -> IO ()\r\nsignalQSem (QSem sem) = do\r\n (avail,blocked) <- takeMVar sem\r\n -- changed below\r\n if null blocked || avail < 0 then\r\n putMVar sem (avail+1,blocked)\r\n else\r\n putMVar sem (avail, tail blocked)\r\n putMVar (head blocked) ()\r\n}}}\r\n\r\nWriting parallel code is hard, so I could have easily got this wrong.\r\nI haven't looked at QSemN, which may need similar fixes (or may\r\nalready deal with this)\r\n\r\nMarking as severity major because it can cause incorrect parallel behaviour.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3160No exception safety in Control.Concurrent.QSem QSemN and SampleVar2019-07-07T19:05:05ZChrisKuklewiczNo exception safety in Control.Concurrent.QSem QSemN and SampleVarLooking at the code for QSem, QSemN, and SampleVar shows they all use a "takeMVar" then "putMVar" programming idiom.
None of these are exception safe. An unlucky killThread will leave the MVar empty and cause the rest of the program to ...Looking at the code for QSem, QSemN, and SampleVar shows they all use a "takeMVar" then "putMVar" programming idiom.
None of these are exception safe. An unlucky killThread will leave the MVar empty and cause the rest of the program to malfunction.
The solution is to rewrite them using withMVar and modifyMVar(_) to prevent the MVar from being left empty in the event of an exception.
Note: QSem also needs the bugfix in #3159
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"No exception safety in Control.Concurrent.QSem QSemN and SampleVar","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Looking at the code for QSem, QSemN, and SampleVar shows they all use a \"takeMVar\" then \"putMVar\" programming idiom.\r\n\r\nNone of these are exception safe. An unlucky killThread will leave the MVar empty and cause the rest of the program to malfunction.\r\n\r\nThe solution is to rewrite them using withMVar and modifyMVar(_) to prevent the MVar from being left empty in the event of an exception.\r\n\r\nNote: QSem also needs the bugfix in #3159","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3161non-blocking read operations in Chan, Sem, QSem, SampleVar2019-07-07T19:05:04ZChrisKuklewicznon-blocking read operations in Chan, Sem, QSem, SampleVarThe non-blocking "tryTakeMVar" makes MVars useful in solving more problems.
The lack of a non-blocking wait/read/take in QSem(N)/Chan/SampleVar means that some problems have to be solved by re-implementing these modules.
This "feature ...The non-blocking "tryTakeMVar" makes MVars useful in solving more problems.
The lack of a non-blocking wait/read/take in QSem(N)/Chan/SampleVar means that some problems have to be solved by re-implementing these modules.
This "feature request" is for such an operation to be added to these modules.
Hmm...I may have a crack at this myself. (see also #3159 and #3160)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"non-blocking read operations in Chan, Sem, QSem, SampleVar","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The non-blocking \"tryTakeMVar\" makes MVars useful in solving more problems.\r\n\r\nThe lack of a non-blocking wait/read/take in QSem(N)/Chan/SampleVar means that some problems have to be solved by re-implementing these modules.\r\n\r\nThis \"feature request\" is for such an operation to be added to these modules.\r\n\r\nHmm...I may have a crack at this myself. (see also #3159 and #3160)","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3162Windows users can't compile time package2019-07-07T19:05:04ZNeil MitchellWindows users can't compile time packageThe time library got unbundled from GHC 6.10.2. Windows users who don't have Cygwin installed can't build the time library from Hackage. The end result is that an important and widely used library doesn't work with GHC 6.10.2. For many W...The time library got unbundled from GHC 6.10.2. Windows users who don't have Cygwin installed can't build the time library from Hackage. The end result is that an important and widely used library doesn't work with GHC 6.10.2. For many Windows users this will be a severe regression.
```
C:\Neil\hoogle>cabal install time --global
Resolving dependencies...
[1 of 1] Compiling Main ( C:\Users\Neil\AppData\Local\Temp\time-1.1.
2.32884\time-1.1.2.3\Setup.hs, C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884
\time-1.1.2.3\dist\setup\Main.o )
Linking C:\Users\Neil\AppData\Local\Temp\time-1.1.2.32884\time-1.1.2.3\dist\setu
p\setup.exe ...
Configuring time-1.1.2.3...
setup.exe: sh: runGenProcess: does not exist (No such file or directory)
cabal: Error: some packages failed to install:
time-1.1.2.3 failed during the configure step. The exception was:
exit: ExitFailure 1
C:\Neil\hoogle>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.2
```
There are two solutions: 1) Fix the time package so it doesn't depend on `sh`; 2) Bundle time with GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ashley@semantic.org, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Windows users can't compile time package","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ashley@semantic.org","ndmitchell@gmail.com"],"type":"Bug","description":"The time library got unbundled from GHC 6.10.2. Windows users who don't have Cygwin installed can't build the time library from Hackage. The end result is that an important and widely used library doesn't work with GHC 6.10.2. For many Windows users this will be a severe regression.\r\n\r\n{{{\r\nC:\\Neil\\hoogle>cabal install time --global\r\nResolving dependencies...\r\n[1 of 1] Compiling Main ( C:\\Users\\Neil\\AppData\\Local\\Temp\\time-1.1.\r\n2.32884\\time-1.1.2.3\\Setup.hs, C:\\Users\\Neil\\AppData\\Local\\Temp\\time-1.1.2.32884\r\n\\time-1.1.2.3\\dist\\setup\\Main.o )\r\nLinking C:\\Users\\Neil\\AppData\\Local\\Temp\\time-1.1.2.32884\\time-1.1.2.3\\dist\\setu\r\np\\setup.exe ...\r\nConfiguring time-1.1.2.3...\r\nsetup.exe: sh: runGenProcess: does not exist (No such file or directory)\r\ncabal: Error: some packages failed to install:\r\ntime-1.1.2.3 failed during the configure step. The exception was:\r\nexit: ExitFailure 1\r\n\r\nC:\\Neil\\hoogle>ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.2\r\n}}}\r\n\r\nThere are two solutions: 1) Fix the time package so it doesn't depend on {{{sh}}}; 2) Bundle time with GHC.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3163GADTs should not allow polymorphism in return type2019-07-07T19:05:04ZScott TurnerGADTs should not allow polymorphism in return type```
{-# LANGUAGE GADTs, RankNTypes, ImpredicativeTypes #-}
module Report (eval) where
data Taker a where
Unreached :: Taker (forall s. s)
eval :: a -> Taker a -> (forall t. t)
eval x c = case c of
Unreached -> x
```
I wanted t...```
{-# LANGUAGE GADTs, RankNTypes, ImpredicativeTypes #-}
module Report (eval) where
data Taker a where
Unreached :: Taker (forall s. s)
eval :: a -> Taker a -> (forall t. t)
eval x c = case c of
Unreached -> x
```
I wanted the quantified types to match and the code to get past the type-checker, as it would if the forall type annotations were replaced with any ordinary type. However, ghc reported:
```
Couldn't match expected type `t'
against inferred type `forall s. s'
`t' is a rigid type variable bound by
the type signature for `eval' at ghc_report.hs:7:32
In the expression: x
In a case alternative: Unreached -> x
In the expression: case c of { Unreached -> x }
```
I was unable to get around this problem by adding type annotations. However, I did get around it by using a similar type
```
data Z = Z (forall t.t)
```
instead of the bare forall type.
----
```
(yawl:~/programs/cat_type) scott% ghc -v -dcore-lint ghc_report.hs
Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.10.1
Using package config file: /usr/lib/ghc-6.10.1/./package.conf
hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0
hiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2
hiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2
hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1
hiding package parsec-2.1.0.1 to avoid conflict with later version parsec-3.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.0.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.0
wired-in package template-haskell mapped to template-haskell-2.3.0.0
wired-in package dph-seq[""] not found.
wired-in package dph-par[""] not found.
Hsc static flags: -static
Created temporary directory: /tmp/ghc26608_0
*** Checking old interface for main:Report:
*** Parser:
*** Renamer/typechecker:
ghc_report.hs:9:17:
Couldn't match expected type `t'
against inferred type `forall s. s'
`t' is a rigid type variable bound by
the type signature for `eval' at ghc_report.hs:7:32
In the expression: x
In a case alternative: Unreached -> x
In the expression: case c of { Unreached -> x }
*** Deleting temp files:
Deleting: /tmp/ghc26608_0/ghc26608_0.s
Warning: deleting non-existent /tmp/ghc26608_0/ghc26608_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc26608_0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"quantified types fail to match in GADT case","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE GADTs, RankNTypes, ImpredicativeTypes #-}\r\n\r\nmodule Report (eval) where\r\n\r\ndata Taker a where\r\n Unreached :: Taker (forall s. s)\r\neval :: a -> Taker a -> (forall t. t)\r\neval x c = case c of\r\n Unreached -> x\r\n}}}\r\nI wanted the quantified types to match and the code to get past the type-checker, as it would if the forall type annotations were replaced with any ordinary type. However, ghc reported:\r\n{{{\r\n Couldn't match expected type `t'\r\n against inferred type `forall s. s'\r\n `t' is a rigid type variable bound by\r\n the type signature for `eval' at ghc_report.hs:7:32\r\n In the expression: x\r\n In a case alternative: Unreached -> x\r\n In the expression: case c of { Unreached -> x }\r\n}}}\r\nI was unable to get around this problem by adding type annotations. However, I did get around it by using a similar type\r\n\r\n{{{\r\ndata Z = Z (forall t.t)\r\n}}}\r\ninstead of the bare forall type.\r\n\r\n----\r\n\r\n{{{\r\n(yawl:~/programs/cat_type) scott% ghc -v -dcore-lint ghc_report.hs\r\nGlasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.10.1\r\nUsing package config file: /usr/lib/ghc-6.10.1/./package.conf\r\nhiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0\r\nhiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2\r\nhiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2\r\nhiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1\r\nhiding package parsec-2.1.0.1 to avoid conflict with later version parsec-3.0.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.0\r\nwired-in package base mapped to base-4.0.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.0\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.0\r\nwired-in package dph-seq[\"\"] not found.\r\nwired-in package dph-par[\"\"] not found.\r\nHsc static flags: -static\r\nCreated temporary directory: /tmp/ghc26608_0\r\n*** Checking old interface for main:Report:\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n\r\nghc_report.hs:9:17:\r\n Couldn't match expected type `t'\r\n against inferred type `forall s. s'\r\n `t' is a rigid type variable bound by\r\n the type signature for `eval' at ghc_report.hs:7:32\r\n In the expression: x\r\n In a case alternative: Unreached -> x\r\n In the expression: case c of { Unreached -> x }\r\n*** Deleting temp files:\r\nDeleting: /tmp/ghc26608_0/ghc26608_0.s\r\nWarning: deleting non-existent /tmp/ghc26608_0/ghc26608_0.s\r\n*** Deleting temp dirs:\r\nDeleting: /tmp/ghc26608_0\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3164ghc: panic! (the 'impossible' happened) while building pandoc on a macbook2019-07-07T19:05:04ZSimon Michaelghc: panic! (the 'impossible' happened) while building pandoc on a macbook```
~/src/pandoc$ ghci -isrc src/pandoc.hs
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
...
Loading package digest-0.0.0.5 ... linking ... done.
Loading package zip-archive-0.1.1.3 ... linking ... done.
[ 8 of 29] Compi...```
~/src/pandoc$ ghci -isrc src/pandoc.hs
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
...
Loading package digest-0.0.0.5 ... linking ... done.
Loading package zip-archive-0.1.1.3 ... linking ... done.
[ 8 of 29] Compiling Text.Pandoc.LaTeXMathML ( src/Text/Pandoc/LaTeXMathML.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-apple-darwin):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```https://gitlab.haskell.org/ghc/ghc/-/issues/3165:history throws "Irrefutable pattern failed" exception2019-07-07T19:05:03Zgreenrd:history throws "Irrefutable pattern failed" exceptionI am trying to use the GHCi debugger to find out why my code has a StackOverflow exception - but GHCi itself seems to be throwing an exception when I type :history:
```
(temp)[greenrd@localhost megaslurp]$ ghci Web.Twitter.Slurp ...I am trying to use the GHCi debugger to find out why my code has a StackOverflow exception - but GHCi itself seems to be throwing an exception when I type :history:
```
(temp)[greenrd@localhost megaslurp]$ ghci Web.Twitter.Slurp
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Web.Twitter.Slurp ( Web/Twitter/Slurp.hs, interpreted )
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package containers-0.2.0.0 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package filepath-1.1.0.1 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.1 ... linking ... done.
Loading package unix-2.3.1.0 ... linking ... done.
Loading package directory-1.0.0.2 ... linking ... done.
Loading package process-1.0.1.0 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package derive-0.1.4 ... linking ... done.
Ok, modules loaded: Web.Twitter.Slurp.
*Web.Twitter.Slurp> :set -fbreak-on-error
*Web.Twitter.Slurp> :trace slurpRetry "/host/twitter-groups.csv"
Loading package base-3.0.3.0 ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package network-2.2.0.1 ... linking ... done.
Loading package utf8-string-0.3.4 ... linking ... done.
Loading package json-0.4.3 ... linking ... done.
Loading package HTTP-4000.0.5 ... linking ... done.
Loading package binary-0.5.0.1 ... linking ... done.
Loading package mime-0.3.0 ... linking ... done.
Loading package csv-0.1.1 ... linking ... done.
Loading package hs-twitter-0.2.5 ... linking ... done.
Stopped at <exception thrown>
_exception ::
e = GHC.Exception.SomeException (GHC.Exception.:DException _
(GHC.Show.:DShow ...) ....)
GHC.IOBase.StackOverflow
[<exception thrown>] *Web.Twitter.Slurp> :history
*** Exception: main/InteractiveEval.hs:(179,13)-(183,46): Irrefutable pattern failed for pattern Data.Maybe.Just decl
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":":history throws \"Irrefutable pattern failed\" exception","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to use the GHCi debugger to find out why my code has a StackOverflow exception - but GHCi itself seems to be throwing an exception when I type :history:\r\n\r\n{{{\r\n(temp)[greenrd@localhost megaslurp]$ ghci Web.Twitter.Slurp \r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help \r\nLoading package ghc-prim ... linking ... done. \r\nLoading package integer ... linking ... done. \r\nLoading package base ... linking ... done. \r\n[1 of 1] Compiling Web.Twitter.Slurp ( Web/Twitter/Slurp.hs, interpreted )\r\nLoading package syb ... linking ... done. \r\nLoading package array-0.2.0.0 ... linking ... done.\r\nLoading package packedstring-0.1.0.1 ... linking ... done.\r\nLoading package containers-0.2.0.0 ... linking ... done.\r\nLoading package pretty-1.0.1.0 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package mtl-1.1.0.2 ... linking ... done.\r\nLoading package filepath-1.1.0.1 ... linking ... done.\r\nLoading package old-locale-1.0.0.1 ... linking ... done.\r\nLoading package old-time-1.0.0.1 ... linking ... done.\r\nLoading package unix-2.3.1.0 ... linking ... done.\r\nLoading package directory-1.0.0.2 ... linking ... done.\r\nLoading package process-1.0.1.0 ... linking ... done.\r\nLoading package random-1.0.0.1 ... linking ... done.\r\nLoading package derive-0.1.4 ... linking ... done.\r\nOk, modules loaded: Web.Twitter.Slurp.\r\n*Web.Twitter.Slurp> :set -fbreak-on-error\r\n*Web.Twitter.Slurp> :trace slurpRetry \"/host/twitter-groups.csv\"\r\nLoading package base-3.0.3.0 ... linking ... done.\r\nLoading package bytestring-0.9.1.4 ... linking ... done.\r\nLoading package parsec-2.1.0.1 ... linking ... done.\r\nLoading package network-2.2.0.1 ... linking ... done.\r\nLoading package utf8-string-0.3.4 ... linking ... done.\r\nLoading package json-0.4.3 ... linking ... done.\r\nLoading package HTTP-4000.0.5 ... linking ... done.\r\nLoading package binary-0.5.0.1 ... linking ... done.\r\nLoading package mime-0.3.0 ... linking ... done.\r\nLoading package csv-0.1.1 ... linking ... done.\r\nLoading package hs-twitter-0.2.5 ... linking ... done.\r\nStopped at <exception thrown>\r\n_exception ::\r\n e = GHC.Exception.SomeException (GHC.Exception.:DException _\r\n (GHC.Show.:DShow ...) ....)\r\n GHC.IOBase.StackOverflow\r\n[<exception thrown>] *Web.Twitter.Slurp> :history\r\n*** Exception: main/InteractiveEval.hs:(179,13)-(183,46): Irrefutable pattern failed for pattern Data.Maybe.Just decl\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3166recompilation checking too optimistic about infix ops2019-07-07T19:05:03Zrolandrecompilation checking too optimistic about infix opsChanging the infix declaration of an operator, e.g. from infixl to infixr, doesn't trigger recompilation of dependent modules.
This behavior can be observed for type classes, type synonyms, and constants, but not for data and type const...Changing the infix declaration of an operator, e.g. from infixl to infixr, doesn't trigger recompilation of dependent modules.
This behavior can be observed for type classes, type synonyms, and constants, but not for data and type constructors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"recompilation checking too optimistic about infix ops","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Changing the infix declaration of an operator, e.g. from infixl to infixr, doesn't trigger recompilation of dependent modules.\r\n\r\nThis behavior can be observed for type classes, type synonyms, and constants, but not for data and type constructors.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3167Segmentation fault with compacting GC, and multiple threads2019-07-07T19:05:03ZguestSegmentation fault with compacting GC, and multiple threadsIn a program I have experienced a segmentation fault;
not only that but also:
```
* tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= _sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.'
...In a program I have experienced a segmentation fault;
not only that but also:
```
* tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= _sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.'
* internal error: removeThreadFromQueue: not found
(GHC version 6.8.2 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I have managed to write a program that reproduces the problem, it is in attachment.
1. Compile with: *$ghc --make -threaded -O2 main.hs*
1. Execute with: *$./main +RTS -A128M -s -c -N4 -RTS 5000000 500*
This should produce a segmentation fault (or one of the previous errors).
I strongly suspect that the cause is an uncaught stack overflow.
- Executing the code with only 1 threads, there are no more problems.
- Increasing the thread stack size (*-k1M*), there are no more problems.
If the problem is really an uncaught stack overflow, I'm rather sure that a more simple test can be written, to reproduce the problem.
I'm on Linux Debian Etch i386; GHC 6.8.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | manlio.perillo@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"segmentation fault","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["manlio.perillo@gmail.com"],"type":"Bug","description":"In a program I have experienced a segmentation fault;\r\nnot only that but also:\r\n\r\n{{{\r\n* tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= _sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.'\r\n\r\n* internal error: removeThreadFromQueue: not found\r\n (GHC version 6.8.2 for i386_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI have managed to write a program that reproduces the problem, it is in attachment.\r\n\r\n 1. Compile with: ''$ghc --make -threaded -O2 main.hs''\r\n 2. Execute with: ''$./main +RTS -A128M -s -c -N4 -RTS 5000000 500''\r\n\r\nThis should produce a segmentation fault (or one of the previous errors).\r\n\r\nI strongly suspect that the cause is an uncaught stack overflow.\r\n\r\n * Executing the code with only 1 threads, there are no more problems.\r\n * Increasing the thread stack size (''-k1M''), there are no more problems.\r\n\r\n\r\nIf the problem is really an uncaught stack overflow, I'm rather sure that a more simple test can be written, to reproduce the problem.\r\n\r\nI'm on Linux Debian Etch i386; GHC 6.8.2.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3168Unhelpful error message about "hidden" packages2019-07-07T19:05:02ZSimon Peyton JonesUnhelpful error message about "hidden" packagesAnatoly Yakonenko [reported](http://www.haskell.org/pipermail/haskell-cafe/2009-April/059677.html): I am trying to build `ParseP` on the latest ghc, and I am getting this error:
```
Text/ParserCombinators/ParseP/Interface.hs:26:17:
...Anatoly Yakonenko [reported](http://www.haskell.org/pipermail/haskell-cafe/2009-April/059677.html): I am trying to build `ParseP` on the latest ghc, and I am getting this error:
```
Text/ParserCombinators/ParseP/Interface.hs:26:17:
Could not find module `Data.ByteString.Char8':
it is a member of package bytestring-0.9.1.4, which is hidden
```
Ross Mellgren responded (correctly): I assume you're using cabal, which hides all packages by default. Add "bytestring" or "bytestring \>= 0.9.\*" or something along those lines to Build-Depends in your .cabal file.
Suggestion: improve GHC's error message.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Unhelpful error message about \"hidden\" packages","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Anatoly Yakonenko [http://www.haskell.org/pipermail/haskell-cafe/2009-April/059677.html reported]: I am trying to build `ParseP` on the latest ghc, and I am getting this error:\r\n{{{\r\n\r\n Text/ParserCombinators/ParseP/Interface.hs:26:17:\r\n Could not find module `Data.ByteString.Char8':\r\n it is a member of package bytestring-0.9.1.4, which is hidden\r\n}}}\r\nRoss Mellgren responded (correctly): I assume you're using cabal, which hides all packages by default. Add \"bytestring\" or \"bytestring >= 0.9.*\" or something along those lines to Build-Depends in your .cabal file.\r\n\r\nSuggestion: improve GHC's error message.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3169Bad occurs-check error message2019-07-07T19:05:02ZSimon Peyton JonesBad occurs-check error messageConsider this:
```
{-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}
module Map where
import Prelude hiding ( lookup )
class Key k where
type Map k :: * -> *
lookup :: k -> Map k elt -> Maybe elt
instance (Key a, Key b) => Key ...Consider this:
```
{-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}
module Map where
import Prelude hiding ( lookup )
class Key k where
type Map k :: * -> *
lookup :: k -> Map k elt -> Maybe elt
instance (Key a, Key b) => Key (a,b) where
type Map (a,b) = MP a b
lookup (a,b) (m :: Map (a,b) elt)
= case lookup a m :: Maybe (Map b elt) of
Just (m2 :: Map b elt) -> lookup b m2 :: Maybe elt
data MP a b elt = MP (Map a (Map b elt))
```
This ought to typecheck, even in the absence of all those type signatures. But alas:
```
Map.hs:13:12:
Occurs check: cannot construct the infinite type: elt = t elt
In the expression: lookup a m :: Maybe (Map b elt)
In the expression:
case lookup a m :: Maybe (Map b elt) of {
Just (m2 :: Map b elt) -> lookup b m2 :: Maybe elt }
```
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Type families occurs check","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chak"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this:\r\n{{{\r\n{-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}\r\nmodule Map where\r\n\r\nimport Prelude hiding ( lookup )\r\n\r\nclass Key k where\r\n type Map k :: * -> *\r\n lookup :: k -> Map k elt -> Maybe elt\r\n\r\ninstance (Key a, Key b) => Key (a,b) where\r\n type Map (a,b) = MP a b\r\n lookup (a,b) (m :: Map (a,b) elt) \r\n = case lookup a m :: Maybe (Map b elt) of\r\n\t Just (m2 :: Map b elt) -> lookup b m2 :: Maybe elt\r\n\r\ndata MP a b elt = MP (Map a (Map b elt))\r\n}}}\r\nThis ought to typecheck, even in the absence of all those type signatures. But alas:\r\n{{{\r\nMap.hs:13:12:\r\n Occurs check: cannot construct the infinite type: elt = t elt\r\n In the expression: lookup a m :: Maybe (Map b elt)\r\n In the expression:\r\n case lookup a m :: Maybe (Map b elt) of {\r\n Just (m2 :: Map b elt) -> lookup b m2 :: Maybe elt }\r\n}}}\r\nSimon","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/3170-fregs-graph: GraphOps.coalesceNodes: can't coalesce the same node.2019-07-07T19:05:02ZIan Lynagh <igloo@earth.li>-fregs-graph: GraphOps.coalesceNodes: can't coalesce the same node.If `-fregs-graph` is used then the build fails when compiling `PrimOps.cmm`:
```
$ /home/ian/ghc/darcs/ghc/ghc/stage1-inplace/ghc -Werror -H64m -O0 -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -Ieventlog -DCOMPILING_RTS -package-na...If `-fregs-graph` is used then the build fails when compiling `PrimOps.cmm`:
```
$ /home/ian/ghc/darcs/ghc/ghc/stage1-inplace/ghc -Werror -H64m -O0 -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -Ieventlog -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o -fregs-graph
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20090409 for x86_64-unknown-linux):
GraphOps.coalesceNodes: can't coalesce the same node.
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This blocks #2790.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fregs-graph: GraphOps.coalesceNodes: can't coalesce the same node.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If `-fregs-graph` is used then the build fails when compiling `PrimOps.cmm`:\r\n{{{\r\n$ /home/ian/ghc/darcs/ghc/ghc/stage1-inplace/ghc -Werror -H64m -O0 -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -Ieventlog -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c PrimOps.cmm -o PrimOps.o -fregs-graph\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.11.20090409 for x86_64-unknown-linux):\r\n GraphOps.coalesceNodes: can't coalesce the same node.\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis blocks #2790.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1benlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/3171threadDelay causes Ctrl-C to be ignored when running interpreted code2019-07-07T19:05:02ZchowellsthreadDelay causes Ctrl-C to be ignored when running interpreted codethe following program:
```
import Control.Concurrent
import Control.Concurrent.MVar
main = threadDelay 0 >> newEmptyMVar >>= takeMVar
```
will not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and exec...the following program:
```
import Control.Concurrent
import Control.Concurrent.MVar
main = threadDelay 0 >> newEmptyMVar >>= takeMVar
```
will not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and executed.
If the threadDelay is removed, it does respond to Ctrl-C both compiled and interpreted.
In 6.10.1, Ctrl-C has the normal effect whether the program is run compiled or interpreted.
The editline segmentation fault bug prevented us from testing the behavior in ghci.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay causes Ctrl-C to be ignored when running interpreted code","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["runghc"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the following program:\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Concurrent.MVar\r\nmain = threadDelay 0 >> newEmptyMVar >>= takeMVar\r\n}}}\r\nwill not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and executed.\r\n\r\nIf the threadDelay is removed, it does respond to Ctrl-C both compiled and interpreted.\r\n\r\nIn 6.10.1, Ctrl-C has the normal effect whether the program is run compiled or interpreted.\r\n\r\nThe editline segmentation fault bug prevented us from testing the behavior in ghci.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3172syb-0.1.0.1 doesn't require base >= 4 in its .cabal file2019-07-07T19:05:02ZSaizansyb-0.1.0.1 doesn't require base >= 4 in its .cabal filethe syb package imports Data.Data, so it needs base-4.\*.
syb-0.1.0.0 "correctly" depends on base \>= 4 (it's more future proof to use an upper bound too),
but syb-0.1.0.1 just uses base with no version range specified.
This leads cabal...the syb package imports Data.Data, so it needs base-4.\*.
syb-0.1.0.0 "correctly" depends on base \>= 4 (it's more future proof to use an upper bound too),
but syb-0.1.0.1 just uses base with no version range specified.
This leads cabal-install to think it's safe to use base-3 making the build fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | |
| 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":"syb-0.1.0.1 doesn't require base >= 4 in its .cabal file","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["cabal","syb"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the syb package imports Data.Data, so it needs base-4.*.\r\n\r\nsyb-0.1.0.0 \"correctly\" depends on base >= 4 (it's more future proof to use an upper bound too),\r\nbut syb-0.1.0.1 just uses base with no version range specified.\r\nThis leads cabal-install to think it's safe to use base-3 making the build fail.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3173Install fails when using DESTDIR2019-07-07T19:05:01ZfidoriInstall fails when using DESTDIRThe package ghc-6.10.2-i386-unknown-linux fails to install when using `DESTDIR` with `make install`. For example, when configured with
```
./configure --prefix=/tmp/ghc
```
and installed with
```
make install DESTDIR=/tmp/ghc_dest
```...The package ghc-6.10.2-i386-unknown-linux fails to install when using `DESTDIR` with `make install`. For example, when configured with
```
./configure --prefix=/tmp/ghc
```
and installed with
```
make install DESTDIR=/tmp/ghc_dest
```
the install fails with error
```
ghc-pkg: /tmp/ghc_dest/tmp/ghc/lib/ghc-6.10.2/package.conf: openFile: does not exist (No such file or directory)
```
The file `package.conf` is created in directory `/tmp/ghc/lib/ghc-6.10.2` but it seems the install scripts try to find it in `/tmp/ghc_dest/tmp/ghc/lib/ghc-6.10.2`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Install fails when using DESTDIR","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["DESTDIR"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The package ghc-6.10.2-i386-unknown-linux fails to install when using `DESTDIR` with `make install`. For example, when configured with\r\n{{{\r\n./configure --prefix=/tmp/ghc\r\n}}}\r\nand installed with\r\n{{{\r\nmake install DESTDIR=/tmp/ghc_dest\r\n}}}\r\nthe install fails with error\r\n{{{\r\nghc-pkg: /tmp/ghc_dest/tmp/ghc/lib/ghc-6.10.2/package.conf: openFile: does not exist (No such file or directory)\r\n}}}\r\nThe file `package.conf` is created in directory `/tmp/ghc/lib/ghc-6.10.2` but it seems the install scripts try to find it in `/tmp/ghc_dest/tmp/ghc/lib/ghc-6.10.2`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3174decodeFloat (0.0/0.0) = undefined2019-07-07T19:05:01ZcrutcherdecodeFloat (0.0/0.0) = undefinedthere are a number of bugs associated with decoding NaN that could be resolved by changing decodeFloat (0.0/0.0) to be undefined.
http://hackage.haskell.org/trac/ghc/ticket/3070 - floor
http://hackage.haskell.org/trac/ghc/ticket/3134 - ...there are a number of bugs associated with decoding NaN that could be resolved by changing decodeFloat (0.0/0.0) to be undefined.
http://hackage.haskell.org/trac/ghc/ticket/3070 - floor
http://hackage.haskell.org/trac/ghc/ticket/3134 - encodeFloat . decodeFloat
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"decodeFloat (0.0/0.0) = undefined","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"there are a number of bugs associated with decoding NaN that could be resolved by changing decodeFloat (0.0/0.0) to be undefined.\r\n\r\nhttp://hackage.haskell.org/trac/ghc/ticket/3070 - floor\r\nhttp://hackage.haskell.org/trac/ghc/ticket/3134 - encodeFloat . decodeFloat","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3175hpc should not mark otherwise as "always true"2023-05-07T17:19:01ZEdward Z. Yanghpc should not mark otherwise as "always true"It seems odd to me that hpc would be distressed about the otherwise guard always evaluating to true: isn't that the point of otherwise?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...It seems odd to me that hpc would be distressed about the otherwise guard always evaluating to true: isn't that the point of otherwise?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hpc should not mark otherwise as \"always true\"","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems odd to me that hpc would be distressed about the otherwise guard always evaluating to true: isn't that the point of otherwise?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->andy@galois.comandy@galois.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3176erroneous defaulting? behaviour for existentials2019-07-07T19:05:01Zclaus.reinke@talk21.comerroneous defaulting? behaviour for existentialsconsider
```
{-# LANGUAGE NoExtendedDefaultRules #-}
{-# OPTIONS_GHC -fwarn-type-defaults #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ExistentialQuantification #-}
data EShow = forall a. Show a => EShow a
smallPrint t = concatMap (\f...consider
```
{-# LANGUAGE NoExtendedDefaultRules #-}
{-# OPTIONS_GHC -fwarn-type-defaults #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ExistentialQuantification #-}
data EShow = forall a. Show a => EShow a
smallPrint t = concatMap (\f-> case f t of EShow a -> show a) [EShow . foo, EShow . bar, EShow . baz]
data ES = forall a. Show a => ES {unES:: a}
smallPrintES t = concatMap (\f-> show $ unES $ f t) [ES . foo, ES . bar, ES . baz]
data Test = Test { foo :: Int, bar :: Char, baz :: Bool }
main = print $ smallPrintES $ Test 1 'x' False
```
for which
```
$ /cygdrive/c/ghc/ghc-6.11.20090320/bin/ghc -e "main" exists.hs
"()()()"
```
while
```
$ /cygdrive/c/ghc/ghc-6.8.3/bin/ghc -e "main" exists.hs
exists.hs:12:40:
Cannot use record selector `unES' as a function due to escaped type variables
Probably fix: use pattern-matching syntax instead
In the first argument of `($)', namely `unES'
In the second argument of `($)', namely `unES $ f t'
In the expression: show $ unES $ f t
```
The expected results were error message or this
```
$ /cygdrive/c/ghc/ghc-6.11.20090320/bin/ghc -e "smallPrint $ Test 1 'x' False" exists.hs
"1'x'False"
```
There seem to be two issues:
- shouldn't ghc head report the use of `unES` as an error?
- how does ghc head arrive at that result, with these flags, without any warnings?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"erroneous defaulting? behaviour for existentials","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"consider\r\n{{{\r\n{-# LANGUAGE NoExtendedDefaultRules #-}\r\n{-# OPTIONS_GHC -fwarn-type-defaults #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ExistentialQuantification #-}\r\n\r\ndata EShow = forall a. Show a => EShow a\r\n\r\nsmallPrint t = concatMap (\\f-> case f t of EShow a -> show a) [EShow . foo, EShow . bar, EShow . baz]\r\n\r\ndata ES = forall a. Show a => ES {unES:: a}\r\n\r\nsmallPrintES t = concatMap (\\f-> show $ unES $ f t) [ES . foo, ES . bar, ES . baz]\r\n\r\ndata Test = Test { foo :: Int, bar :: Char, baz :: Bool }\r\n\r\nmain = print $ smallPrintES $ Test 1 'x' False\r\n}}}\r\nfor which \r\n{{{\r\n$ /cygdrive/c/ghc/ghc-6.11.20090320/bin/ghc -e \"main\" exists.hs\r\n\"()()()\"\r\n}}}\r\nwhile\r\n{{{\r\n$ /cygdrive/c/ghc/ghc-6.8.3/bin/ghc -e \"main\" exists.hs\r\n\r\nexists.hs:12:40:\r\n Cannot use record selector `unES' as a function due to escaped type variables\r\n Probably fix: use pattern-matching syntax instead\r\n In the first argument of `($)', namely `unES'\r\n In the second argument of `($)', namely `unES $ f t'\r\n In the expression: show $ unES $ f t\r\n}}}\r\nThe expected results were error message or this\r\n{{{\r\n$ /cygdrive/c/ghc/ghc-6.11.20090320/bin/ghc -e \"smallPrint $ Test 1 'x' False\" exists.hs\r\n\"1'x'False\"\r\n}}}\r\n\r\nThere seem to be two issues:\r\n\r\n- shouldn't ghc head report the use of `unES` as an error?\r\n\r\n- how does ghc head arrive at that result, with these flags, without any warnings?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3177support quasiquoting for types2019-07-07T19:05:01Zclaus.reinke@talk21.comsupport quasiquoting for typesCurrently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming...Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).
For just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well.
related: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"support quasiquoting for types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).\r\n\r\nSince so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).\r\n\r\nFor just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well. \r\n\r\nrelated: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3178Fix linking -lpthread for semaphores2019-07-07T19:05:00ZsthibaulFix linking -lpthread for semaphoresHello,
On the GNU/Hurd OS, the posix semaphore library does not link because
of undefined reference to sem_\* functions. I do not know how the ghc
build process works, could it be that it forgets to use -lpthread for
that library?
Samu...Hello,
On the GNU/Hurd OS, the posix semaphore library does not link because
of undefined reference to sem_\* functions. I do not know how the ghc
build process works, could it be that it forgets to use -lpthread for
that library?
Samuel
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix linking -lpthread for semaphores","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nOn the GNU/Hurd OS, the posix semaphore library does not link because\r\nof undefined reference to sem_* functions. I do not know how the ghc\r\nbuild process works, could it be that it forgets to use -lpthread for\r\nthat library?\r\n\r\nSamuel\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3179Linking unix package fails2019-07-07T19:05:00ZeelcoLinking unix package failsI just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:
```
Loading package unix-2.3.2.0 ... <command line>: can't load .so/.D...I just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:
```
Loading package unix-2.3.2.0 ... <command line>: can't load .so/.DLL for:
rt (/usr/lib/librt.so: symbol __librt_multiple_threads, version GLIBC_PRIVATE
not defined in file libc.so.6 with link time reference)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Linking unix package fails","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:\r\n\r\n{{{\r\nLoading package unix-2.3.2.0 ... <command line>: can't load .so/.DLL for: \r\nrt (/usr/lib/librt.so: symbol __librt_multiple_threads, version GLIBC_PRIVATE \r\nnot defined in file libc.so.6 with link time reference)\r\n\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3180TcTyFuns.flattenType: unexpected PredType2019-07-07T19:05:00ZguestTcTyFuns.flattenType: unexpected PredTypelguapo:inez cmoore$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude\> :m +...lguapo:inez cmoore$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude\> :m +NLP.WordNet
Prelude NLP.WordNet\> runWordNet
ghc: panic! (the 'impossible' happened)
> (GHC version 6.10.1 for i386-apple-darwin):
TcTyFuns.flattenType: unexpected PredType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Prelude NLP.WordNet\>
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"TcTyFuns.flattenType: unexpected PredType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"lguapo:inez cmoore$ ghci\r\nGHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nPrelude> :m +NLP.WordNet\r\nPrelude NLP.WordNet> runWordNet\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nPrelude NLP.WordNet> \r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3181Regression in unboxing2019-07-07T19:05:00ZdolioRegression in unboxingGreetings,
Finally having added some benchmarking to my uvector-algorithms package, I came across a regression in performance in the heap sort implementation. With 6.10.2, it did significantly more allocation than I'd remembered, and lo...Greetings,
Finally having added some benchmarking to my uvector-algorithms package, I came across a regression in performance in the heap sort implementation. With 6.10.2, it did significantly more allocation than I'd remembered, and looking at the core, I spotted a boxed type that I have since determined to be the culprit. I'll attach the relevant portion of the algorithm as a test case (I apologize that it's rather large, but I haven't yet figured out how to make a smaller example that works).
The key lines are:
```
do (child' :*: ac) <- maximumChild cmp a off child len
case cmp val ac of
LT -> writeMU a (root + off) ac >> sift val child' len
_ -> writeMU a (root + off) val
```
The monadic (ST) pattern match against the strict pair gets compiled to a function that accepts the arguments of the pair (as well as the ST state parameter) like so:
```
$w$j_s118 :: State# RealWorld
-> Int
-> Int#
-> (# State# RealWorld, () #)
[Arity 3
$w$j_s118 =
\ (w_s108 :: State# RealWorld)
(ww_s10b :: Int)
(ww1_s10e :: Int#) ->
case <# sc3_s11t ww1_s10e of wild11_aY2 {
False ->
case writeIntArray#
@ RealWorld
marr#_aVT
(+# sc2_s11s 40)
sc3_s11t
w_s108
of s2#1_aX6 { __DEFAULT ->
(# s2#1_aX6, () #)
};
True ->
case writeIntArray#
@ RealWorld
marr#_aVT
(+# sc2_s11s 40)
ww1_s10e
w_s108
of s2#1_aX6 { __DEFAULT ->
case ww_s10b of w1_X10F { I# ww2_X11k ->
$s$wa_s11D s2#1_aX6 sc1_s11r ww2_X11k sc3_s11t
}
}
}
```
As can be seen, all that is done with the boxed Int is that it is taken apart in one branch (this identifies the boxed argument as the `child'` variable, the `Int` being returned by `maximumChild`; I verified this by modifying the code to use a custom type:
```
data IP e = IP {-# UNPACK #-} !Int !e
```
this results in the desired unboxing behavior). Further, all calls to this function look like:
```
$w$j_s118 s2#3_XZ1 (I# x_aTU) r#_aXD
```
So this seems to be unnecessary boxing. Further, I have reports that 6.8.2 \*did\* spot this unboxing opportunity, which would explain why my algorithm wasn't performing as well as I had remembered, since the last time I'd seriously inspected the performance was in the 6.8 series.
One theory I had was that the fact that the value was only used in one branch of the case was causing it to look non-strict somehow, despite the pair being strict in its fields (perhaps the pair was eliminated before strictness analysis was done?). However, I've added bang patterns to the `child'` match, and changed the case statement to:
```
case child' `seq` cmp val ac of ...
```
without it making a difference. So I am a bit stumped as to why exactly GHC isn't eliminating this box.
As noted, I can get the desired unboxing with a custom unpacked type, but fixing the regression would be preferable. Thanks for your time and help!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Regression in unboxing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["boxing","unboxing"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Greetings,\r\n\r\nFinally having added some benchmarking to my uvector-algorithms package, I came across a regression in performance in the heap sort implementation. With 6.10.2, it did significantly more allocation than I'd remembered, and looking at the core, I spotted a boxed type that I have since determined to be the culprit. I'll attach the relevant portion of the algorithm as a test case (I apologize that it's rather large, but I haven't yet figured out how to make a smaller example that works).\r\n\r\nThe key lines are:\r\n\r\n{{{\r\ndo (child' :*: ac) <- maximumChild cmp a off child len\r\n case cmp val ac of\r\n LT -> writeMU a (root + off) ac >> sift val child' len\r\n _ -> writeMU a (root + off) val\r\n}}}\r\n\r\nThe monadic (ST) pattern match against the strict pair gets compiled to a function that accepts the arguments of the pair (as well as the ST state parameter) like so:\r\n\r\n{{{\r\n$w$j_s118 :: State# RealWorld\r\n -> Int\r\n -> Int#\r\n -> (# State# RealWorld, () #)\r\n[Arity 3\r\n\r\n$w$j_s118 =\r\n \\ (w_s108 :: State# RealWorld)\r\n (ww_s10b :: Int)\r\n (ww1_s10e :: Int#) ->\r\n case <# sc3_s11t ww1_s10e of wild11_aY2 {\r\n False ->\r\n case writeIntArray#\r\n @ RealWorld\r\n marr#_aVT\r\n (+# sc2_s11s 40)\r\n sc3_s11t\r\n w_s108\r\n of s2#1_aX6 { __DEFAULT ->\r\n (# s2#1_aX6, () #)\r\n };\r\n True ->\r\n case writeIntArray#\r\n @ RealWorld\r\n marr#_aVT\r\n (+# sc2_s11s 40)\r\n ww1_s10e\r\n w_s108\r\n of s2#1_aX6 { __DEFAULT ->\r\n case ww_s10b of w1_X10F { I# ww2_X11k ->\r\n $s$wa_s11D s2#1_aX6 sc1_s11r ww2_X11k sc3_s11t\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nAs can be seen, all that is done with the boxed Int is that it is taken apart in one branch (this identifies the boxed argument as the `child'` variable, the `Int` being returned by `maximumChild`; I verified this by modifying the code to use a custom type:\r\n\r\n{{{\r\ndata IP e = IP {-# UNPACK #-} !Int !e\r\n}}}\r\n\r\nthis results in the desired unboxing behavior). Further, all calls to this function look like:\r\n\r\n{{{\r\n$w$j_s118 s2#3_XZ1 (I# x_aTU) r#_aXD\r\n}}}\r\n\r\nSo this seems to be unnecessary boxing. Further, I have reports that 6.8.2 *did* spot this unboxing opportunity, which would explain why my algorithm wasn't performing as well as I had remembered, since the last time I'd seriously inspected the performance was in the 6.8 series.\r\n\r\nOne theory I had was that the fact that the value was only used in one branch of the case was causing it to look non-strict somehow, despite the pair being strict in its fields (perhaps the pair was eliminated before strictness analysis was done?). However, I've added bang patterns to the `child'` match, and changed the case statement to:\r\n\r\n{{{\r\ncase child' `seq` cmp val ac of ...\r\n}}}\r\n\r\nwithout it making a difference. So I am a bit stumped as to why exactly GHC isn't eliminating this box.\r\n\r\nAs noted, I can get the desired unboxing with a custom unpacked type, but fixing the regression would be preferable. Thanks for your time and help!","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/3182Bad FP code generated by x86_64 native code generator.2019-07-07T19:04:59ZIan Lynagh <igloo@earth.li>Bad FP code generated by x86_64 native code generator.With this module:
```
main :: IO ()
main = mapM_ print $ map log2 vals
log2 :: Int -> Double
log2 x = logBase 2 (fromIntegral x)
vals :: [Int]
vals = [1, 2, 17]
```
on amd64/Linux with the HEAD, I'm seeing:
```
$ ghc -fforce-recomp ...With this module:
```
main :: IO ()
main = mapM_ print $ map log2 vals
log2 :: Int -> Double
log2 x = logBase 2 (fromIntegral x)
vals :: [Int]
vals = [1, 2, 17]
```
on amd64/Linux with the HEAD, I'm seeing:
```
$ ghc -fforce-recomp -O -fregs-graph -o num012 num012.hs; ./num012
0.0
1.2607434391239006e13
5.153241959769104e13
```
Ben, are you able to take a look please?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Bad code generated with -fregs-graph","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"benl"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"With this module:\r\n{{{\r\nmain :: IO ()\r\nmain = mapM_ print $ map log2 vals\r\n\r\nlog2 :: Int -> Double\r\nlog2 x = logBase 2 (fromIntegral x)\r\n\r\nvals :: [Int]\r\nvals = [1, 2, 17]\r\n}}}\r\non amd64/Linux with the HEAD, I'm seeing:\r\n{{{\r\n$ ghc -fforce-recomp -O -fregs-graph -o num012 num012.hs; ./num012\r\n0.0\r\n1.2607434391239006e13\r\n5.153241959769104e13\r\n}}}\r\n\r\nBen, are you able to take a look please?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1benlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/3183unhelpful wording in module error message2019-07-07T19:04:59Zduncanunhelpful wording in module error messageUsers sometimes hit this error message:
```
Could not find module `Control.Monad.State':
it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2
```
The problem is just the wording. It should say from start that the module w...Users sometimes hit this error message:
```
Could not find module `Control.Monad.State':
it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2
```
The problem is just the wording. It should say from start that the module was found in multiple packages, rather than saying that it was not found at all.
How about:
```
Ambiguous module name `Control.Monad.State':
it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2
```
We might also want the message to suggest the flags `-hide-all-packages`, `-hide-package` and/or `-package` as part of the solution.
I'm filing this on behalf of people who ran into this while building UHC (which does not use Cabal and does not use the `-hide-all-packages` flag).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | doaitse@cs.uu.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unhelpful wording in module error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["doaitse@cs.uu.nl"],"type":"Bug","description":"Users sometimes hit this error message:\r\n\r\n{{{\r\nCould not find module `Control.Monad.State':\r\n it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2\r\n}}}\r\n\r\nThe problem is just the wording. It should say from start that the module was found in multiple packages, rather than saying that it was not found at all.\r\n\r\nHow about:\r\n{{{\r\nAmbiguous module name `Control.Monad.State':\r\n it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2\r\n}}}\r\n\r\nWe might also want the message to suggest the flags `-hide-all-packages`, `-hide-package` and/or `-package` as part of the solution.\r\n\r\nI'm filing this on behalf of people who ran into this while building UHC (which does not use Cabal and does not use the `-hide-all-packages` flag).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3184package.conf.d should be under /var, not /usr2019-07-07T19:04:59ZIan Lynagh <igloo@earth.li>package.conf.d should be under /var, not /usrfhs-2.3 says:
```
/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
ho...fhs-2.3 says:
```
/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere.
```
`package.conf.d` is not shareable, as different machines may have different packages installed, so we should put it under /var instead.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3185Compiler error implies incorrect implicit import of a ((->)a) Monad instance2019-07-07T19:04:59ZjkffCompiler error implies incorrect implicit import of a ((->)a) Monad instanceTake the following (incorrect) source:
```
fun :: Integer -> String
fun x = "123"
main = do
s <- readFile "file.in"
let m = read s
writeFile "file.out" (return fun m)
```
Compile it:
```
jkff@jkff-laptop:~$ ghci tmp.hs
GHCi, ve...Take the following (incorrect) source:
```
fun :: Integer -> String
fun x = "123"
main = do
s <- readFile "file.in"
let m = read s
writeFile "file.out" (return fun m)
```
Compile it:
```
jkff@jkff-laptop:~$ ghci tmp.hs
GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( tmp.hs, interpreted )
tmp.hs:8:31:
Couldn't match expected type `String'
against inferred type `Integer -> String'
In the first argument of `return', namely `fun'
In the second argument of `writeFile', namely `(return fun m)'
In the expression: writeFile "file.out" (return fun m)
Failed, modules loaded: none.
```
The error looks like if the compiler has implicitly imported Control.Monad.Instances including the instance for ((-\>)a).
It shouldn't have done so, because Prelude doesn't include this instance.
NoImplicitPrelude doesn't help.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Compiler error implies incorrect implicit import of a ((->)a) Monad instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Take the following (incorrect) source:\r\n\r\n{{{\r\nfun :: Integer -> String\r\nfun x = \"123\"\r\n\r\nmain = do\r\n s <- readFile \"file.in\"\r\n let m = read s\r\n writeFile \"file.out\" (return fun m)\r\n}}}\r\n\r\nCompile it:\r\n\r\n{{{\r\njkff@jkff-laptop:~$ ghci tmp.hs\r\nGHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( tmp.hs, interpreted )\r\n\r\ntmp.hs:8:31:\r\n Couldn't match expected type `String'\r\n against inferred type `Integer -> String'\r\n In the first argument of `return', namely `fun'\r\n In the second argument of `writeFile', namely `(return fun m)'\r\n In the expression: writeFile \"file.out\" (return fun m)\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nThe error looks like if the compiler has implicitly imported Control.Monad.Instances including the instance for ((->)a). \r\nIt shouldn't have done so, because Prelude doesn't include this instance.\r\nNoImplicitPrelude doesn't help.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3186findExeutable does not respect order of search path on Windows2019-07-07T19:04:58ZduncanfindExeutable does not respect order of search path on WindowsOn Windows `findExeutable` is behaving rather strangely.
From a command line window (ie not MSYS):
```
H:\>echo %PATH%
C:\Program Files\MiKTeX 2.7\miktex\bin;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\Program Files\...On Windows `findExeutable` is behaving rather strangely.
From a command line window (ie not MSYS):
```
H:\>echo %PATH%
C:\Program Files\MiKTeX 2.7\miktex\bin;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\Program Files\QuickTime\QTSystem\;
c:\Program Files\Microsoft SQL Server\90\Tools\binn\;
C:\Program Files\MATLAB\R2009a\bin;
C:\Program Files\MATLAB\R2009a\bin\win32;
C:\Program Files\Haskell\bin;
D:\dcoutts\ghc-6.10.1\bin;
D:\dcoutts\Gtk2Hs\bin;
D:\dcoutts\bin
```
(formatted onto multiple lines for clarity)
Now it appears I've got three versions of haddock installed:
```
H:\>where haddock
C:\Program Files\Haskell\bin\haddock.exe
D:\dcoutts\ghc-6.10.1\bin\haddock.exe
D:\dcoutts\bin\haddock.exe
```
However in ghci:
```
H:\>ghci
Prelude> System.Directory.findExecutable "haddock"
Just "D:\\dcoutts\\GHC-61~1.1\\bin\\haddock.exe"
```
But this is bonkers! The version it has found is not in the first directory on the search path.
I don't think it's related to the global/user split in the Windows `%PATH%`. All of the dirs containing haddock.exe are in the user portion of my `%PATH%`.
On Windows `System.Directory.findExecutable` uses the `SearchPathA` Win32 function. The [MSDN docs](http://msdn.microsoft.com/en-us/library/aa365527.aspx) mention that it searches system and the current dirs first and has some "safe" search mode but none of those things seem to be relevant here.
This problem confuses users of Cabal which uses `findExecutable` to find build tools. See \[this thread http://haskell.org/pipermail/cabal-devel/2009-April/005158.html\] from the cabal mailing list.
Perhaps we should just use the pure Haskell version that we use on non-Windows systems. Still, it'd be nice to reflect properly the Windows search path semantics if it's not as simple as looking in the `%PATH%`.
Actually the semantics are pretty weird. Consider this...
Let's cut down to just two versions of haddock:
```
H:\>where haddock
C:\Program Files\Haskell\bin\haddock.exe
D:\dcoutts\ghc-6.10.1\bin\haddock.exe
```
Now lets see what versions we've got where:
```
H:\>"C:\Program Files\Haskell\bin\haddock.exe" --version
Haddock version 2.1.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
H:\>D:\dcoutts\ghc-6.10.1\bin\haddock.exe --version
Haddock version 2.3.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
```
As expected, just running haddock from the command line gives us the first one:
```
H:\>haddock --version
Haddock version 2.1.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
```
Now in ghci:
```
Prelude> System.Process.runCommand "haddock --version"
Haddock version 2.1.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
```
That's fine. It's the first one and consistent with running from the command line (internally `runCommand` uses the command processor).
But now try this:
```
Prelude> System.Process.runProcess "haddock" ["--version"] Nothing Nothing Nothing Nothing Nothing
Haddock version 2.3.0, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
```
WT!? Where did that come from? It's using a different search path from the command interpreter. This one however is consistent with the `findExecutable` function (as it is supposed to be).
No idea what is going on. Can anyone else reproduce or explain this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.2 |
| 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":"findExeutable does not respect order of search path on Windows","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On Windows `findExeutable` is behaving rather strangely.\r\n\r\nFrom a command line window (ie not MSYS):\r\n{{{\r\nH:\\>echo %PATH%\r\nC:\\Program Files\\MiKTeX 2.7\\miktex\\bin;\r\nC:\\WINDOWS\\system32;\r\nC:\\WINDOWS;\r\nC:\\WINDOWS\\System32\\Wbem;\r\nC:\\Program Files\\QuickTime\\QTSystem\\;\r\nc:\\Program Files\\Microsoft SQL Server\\90\\Tools\\binn\\;\r\nC:\\Program Files\\MATLAB\\R2009a\\bin;\r\nC:\\Program Files\\MATLAB\\R2009a\\bin\\win32;\r\nC:\\Program Files\\Haskell\\bin;\r\nD:\\dcoutts\\ghc-6.10.1\\bin;\r\nD:\\dcoutts\\Gtk2Hs\\bin;\r\nD:\\dcoutts\\bin\r\n}}}\r\n(formatted onto multiple lines for clarity)\r\n\r\nNow it appears I've got three versions of haddock installed:\r\n{{{\r\nH:\\>where haddock\r\nC:\\Program Files\\Haskell\\bin\\haddock.exe\r\nD:\\dcoutts\\ghc-6.10.1\\bin\\haddock.exe\r\nD:\\dcoutts\\bin\\haddock.exe\r\n}}}\r\n\r\nHowever in ghci:\r\n{{{\r\nH:\\>ghci\r\nPrelude> System.Directory.findExecutable \"haddock\"\r\nJust \"D:\\\\dcoutts\\\\GHC-61~1.1\\\\bin\\\\haddock.exe\"\r\n}}}\r\n\r\nBut this is bonkers! The version it has found is not in the first directory on the search path.\r\n\r\nI don't think it's related to the global/user split in the Windows `%PATH%`. All of the dirs containing haddock.exe are in the user portion of my `%PATH%`.\r\n\r\nOn Windows `System.Directory.findExecutable` uses the `SearchPathA` Win32 function. The [http://msdn.microsoft.com/en-us/library/aa365527.aspx MSDN docs] mention that it searches system and the current dirs first and has some \"safe\" search mode but none of those things seem to be relevant here.\r\n\r\nThis problem confuses users of Cabal which uses `findExecutable` to find build tools. See [this thread http://haskell.org/pipermail/cabal-devel/2009-April/005158.html] from the cabal mailing list.\r\n\r\nPerhaps we should just use the pure Haskell version that we use on non-Windows systems. Still, it'd be nice to reflect properly the Windows search path semantics if it's not as simple as looking in the `%PATH%`.\r\n\r\nActually the semantics are pretty weird. Consider this...\r\n\r\nLet's cut down to just two versions of haddock:\r\n{{{\r\nH:\\>where haddock\r\nC:\\Program Files\\Haskell\\bin\\haddock.exe\r\nD:\\dcoutts\\ghc-6.10.1\\bin\\haddock.exe\r\n}}}\r\n\r\nNow lets see what versions we've got where:\r\n{{{\r\nH:\\>\"C:\\Program Files\\Haskell\\bin\\haddock.exe\" --version\r\nHaddock version 2.1.0, (c) Simon Marlow 2006\r\nPorted to use the GHC API by David Waern 2006-2008\r\n\r\nH:\\>D:\\dcoutts\\ghc-6.10.1\\bin\\haddock.exe --version\r\nHaddock version 2.3.0, (c) Simon Marlow 2006\r\nPorted to use the GHC API by David Waern 2006-2008\r\n}}}\r\n\r\nAs expected, just running haddock from the command line gives us the first one:\r\n{{{\r\nH:\\>haddock --version\r\nHaddock version 2.1.0, (c) Simon Marlow 2006\r\nPorted to use the GHC API by David Waern 2006-2008\r\n}}}\r\n\r\nNow in ghci:\r\n{{{\r\nPrelude> System.Process.runCommand \"haddock --version\"\r\nHaddock version 2.1.0, (c) Simon Marlow 2006\r\nPorted to use the GHC API by David Waern 2006-2008\r\n}}}\r\nThat's fine. It's the first one and consistent with running from the command line (internally `runCommand` uses the command processor).\r\n\r\nBut now try this:\r\n{{{\r\nPrelude> System.Process.runProcess \"haddock\" [\"--version\"] Nothing Nothing Nothing Nothing Nothing\r\nHaddock version 2.3.0, (c) Simon Marlow 2006\r\nPorted to use the GHC API by David Waern 2006-2008\r\n}}}\r\n\r\nWT!? Where did that come from? It's using a different search path from the command interpreter. This one however is consistent with the `findExecutable` function (as it is supposed to be).\r\n\r\nNo idea what is going on. Can anyone else reproduce or explain this?","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3187ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does ...2019-07-07T19:04:58ZJeremyShawghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist.In GHC 6.1.0.2, ghc-pkg -f new.package.conf register foo.conf, fails if new.package.conf does not exist. In GHC 6.10.1 this worked fine. Not sure if this change is a bug or feature.
<details><summary>Trac metadata</summary>
| Trac fiel...In GHC 6.1.0.2, ghc-pkg -f new.package.conf register foo.conf, fails if new.package.conf does not exist. In GHC 6.10.1 this worked fine. Not sure if this change is a bug or feature.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In GHC 6.1.0.2, ghc-pkg -f new.package.conf register foo.conf, fails if new.package.conf does not exist. In GHC 6.10.1 this worked fine. Not sure if this change is a bug or feature.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3188instance Random for Data.Word2019-07-07T19:04:58Zuznxinstance Random for Data.WordIt would be nice to have instance Random for Word8, Word16, Word32, Word64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6....It would be nice to have instance Random for Word8, Word16, Word32, Word64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"instance Random for Data.Word","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be nice to have instance Random for Word8, Word16, Word32, Word64.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3189Exception in canonicalizePath if path has national symbols2019-07-07T19:04:58ZTonalException in canonicalizePath if path has national symbolsEnvironment: Windows Vista Home Ru + sp1 ghc 6.10.2
Code for reproduced (file tst2.hs):
```
import System.Directory
main = do
cwd <- canonicalizePath "."
putStrLn cwd
setCurrentDirectory cwd
```
Console session:
```
C:\Lang\te...Environment: Windows Vista Home Ru + sp1 ghc 6.10.2
Code for reproduced (file tst2.hs):
```
import System.Directory
main = do
cwd <- canonicalizePath "."
putStrLn cwd
setCurrentDirectory cwd
```
Console session:
```
C:\Lang\test\haskell\Тест>ghc --make tst2.hs
[1 of 1] Compiling Main ( tst2.hs, tst2.o )
Linking tst2.exe ...
C:\Lang\test\haskell\Тест>tst2.exe
C:\Lang\test\haskell\╥хёЄ
tst2.exe: SetCurrentDirectory: does not exist (�5 C405BAO =09B8 C:070==K9 D09;.)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.2 |
| 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":"Exception in canonicalizePath if path has national symbols","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Environment: Windows Vista Home Ru + sp1 ghc 6.10.2\r\n\r\nCode for reproduced (file tst2.hs):\r\n{{{\r\nimport System.Directory\r\n\r\nmain = do\r\n cwd <- canonicalizePath \".\"\r\n putStrLn cwd\r\n setCurrentDirectory cwd\r\n}}}\r\nConsole session:\r\n{{{\r\nC:\\Lang\\test\\haskell\\Тест>ghc --make tst2.hs\r\n[1 of 1] Compiling Main ( tst2.hs, tst2.o )\r\nLinking tst2.exe ...\r\n\r\nC:\\Lang\\test\\haskell\\Тест>tst2.exe\r\nC:\\Lang\\test\\haskell\\╥хёЄ\r\ntst2.exe: SetCurrentDirectory: does not exist (\u001d5 C405BAO =09B8 C:070==K9 D09;.)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3190Type checker fails to unify/expand type definitions in certain contexts2019-07-07T19:04:58ZferridderType checker fails to unify/expand type definitions in certain contextsWhen compiling
type TMvar a = TVar (Maybe a)
mynewEmptyMvar :: STM (TMVar a)
mynewEmptyMvar = newTVar Nothing
the type checker complains
Couldn't match expected type `TMVar a'
against inferred type `TVar (Maybe a1)'
Expe...When compiling
type TMvar a = TVar (Maybe a)
mynewEmptyMvar :: STM (TMVar a)
mynewEmptyMvar = newTVar Nothing
the type checker complains
Couldn't match expected type `TMVar a'
against inferred type `TVar (Maybe a1)'
Expected type: STM (TMVar a)
Inferred type: STM (TVar (Maybe a1))
In the expression: newTVar Nothing
In the definition of \`mynewEmptyMvar':
> mynewEmptyMvar = newTVar Nothing
although the definition of TMvar is
type TMvar a = TVar (Maybe a)
This behaviour could not be duplicated in the IO monad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type checker fails to unify/expand type definitions in certain contexts","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling \r\n\r\ntype TMvar a = TVar (Maybe a)\r\nmynewEmptyMvar :: STM (TMVar a)\r\nmynewEmptyMvar = newTVar Nothing\r\n\r\nthe type checker complains\r\n\r\n Couldn't match expected type `TMVar a'\r\n against inferred type `TVar (Maybe a1)'\r\n Expected type: STM (TMVar a)\r\n Inferred type: STM (TVar (Maybe a1))\r\n In the expression: newTVar Nothing\r\n In the definition of `mynewEmptyMvar':\r\n mynewEmptyMvar = newTVar Nothing\r\n\r\nalthough the definition of TMvar is\r\ntype TMvar a = TVar (Maybe a)\r\n\r\nThis behaviour could not be duplicated in the IO monad.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3191hpc reports spurious results with .lhs files even after processing with ghc -E2019-07-07T19:04:57ZDominichpc reports spurious results with .lhs files even after processing with ghc -EI've done a bit of investigation and it seems there are at least two problems:
1. I have literate haskell files (.lhs).
1. Even if I run them through the pre-processor (ghc -E) they still don't work
but if I manually remove these line...I've done a bit of investigation and it seems there are at least two problems:
1. I have literate haskell files (.lhs).
1. Even if I run them through the pre-processor (ghc -E) they still don't work
but if I manually remove these lines (which seem to get inserted by the
pre-processor)
{-\# LINE 1 "ASNTYPE.lhs" \#-}
\#line 1 "ASNTYPE.lhs"
then it does actually work.
I still have a problem with another project which doesn't use literate haskell
but does require the use of -cpp and has got \#ifdef's. I haven't got to the
bottom of it yet but I'm suspicious that lines starting with \# cause hpc to
misbehave.
It's strange that hpc should behave like this as I would have thought it
wouldn't care about hs / lhs and \# as ghc would have done some of its standard
processing before hpc got engaged.
This happens on linux and windows (not surprisingly).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hpc reports spurious results with .lhs files even after processing with ghc -E","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've done a bit of investigation and it seems there are at least two problems:\r\n\r\n1. I have literate haskell files (.lhs).\r\n\r\n2. Even if I run them through the pre-processor (ghc -E) they still don't work \r\nbut if I manually remove these lines (which seem to get inserted by the\r\npre-processor)\r\n\r\n{-# LINE 1 \"ASNTYPE.lhs\" #-}\r\n#line 1 \"ASNTYPE.lhs\"\r\n\r\nthen it does actually work.\r\n\r\nI still have a problem with another project which doesn't use literate haskell\r\nbut does require the use of -cpp and has got #ifdef's. I haven't got to the\r\nbottom of it yet but I'm suspicious that lines starting with # cause hpc to\r\nmisbehave.\r\n\r\nIt's strange that hpc should behave like this as I would have thought it\r\nwouldn't care about hs / lhs and # as ghc would have done some of its standard\r\nprocessing before hpc got engaged.\r\n\r\nThis happens on linux and windows (not surprisingly).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1andy@galois.comandy@galois.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3192Add dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to...2019-07-07T19:04:57ZguestAdd dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to ghc-apiThe above function would behave much like dynCompileExpr, but skipping the front end. This is extremely useful for tools that are able to produce core code easily themselves from internal data structures. The Bool would indicate (as with...The above function would behave much like dynCompileExpr, but skipping the front end. This is extremely useful for tools that are able to produce core code easily themselves from internal data structures. The Bool would indicate (as with compileCoreModule) whether to invoke the simplifier.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to ghc-api","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The above function would behave much like dynCompileExpr, but skipping the front end. This is extremely useful for tools that are able to produce core code easily themselves from internal data structures. The Bool would indicate (as with compileCoreModule) whether to invoke the simplifier.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3193line number for GADT type error is very inaccurate2019-07-07T19:04:57Znr@eecs.harvard.eduline number for GADT type error is very inaccurateHere is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argu...Here is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argument of `anal_f', namely `g'
In the expression: anal_f g (return . fromZJust) ZNothing
```
This is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.
I'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"line number for GADT type error is very inaccurate","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is an error message from 6.11:\r\n{{{\r\ncmm/ZDF5ex.hs:528:2:\r\n Couldn't match expected type `ZOpen'\r\n against inferred type `ZClosed'\r\n Expected type: ZipGF m l e x\r\n Inferred type: ZipGF m l C O\r\n In the first argument of `anal_f', namely `g'\r\n In the expression: anal_f g (return . fromZJust) ZNothing\r\n}}}\r\nThis is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.\r\n\r\nI'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3194Spurious reading of keyboard in GHCi2019-07-07T19:04:57ZTimAttwoodSpurious reading of keyboard in GHCiSometimes after loading modules in GHCi the first character typed is read incorrectly.
```
*Main> main
<interactive>:1:0: Not in scope: `gain'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ...Sometimes after loading modules in GHCi the first character typed is read incorrectly.
```
*Main> main
<interactive>:1:0: Not in scope: `gain'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Spurious reading of keyboard in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sometimes after loading modules in GHCi the first character typed is read incorrectly.\r\n\r\n{{{\r\n*Main> main\r\n\r\n<interactive>:1:0: Not in scope: `gain'\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3195runghc failing sometimes2019-07-07T19:04:56ZJens Petersenrunghc failing sometimesghc-6.10.2 runghc fails on ppc sometimes:
http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log (haddock)
http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log (HTTP)
Also reproduced first-hand on...ghc-6.10.2 runghc fails on ppc sometimes:
http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log (haddock)
http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log (HTTP)
Also reproduced first-hand on a ppc box.
Furthermore (may be a different issue) runghc fails for me with
recent ghc-6.11 snapshots I have built on x86_64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"runghc failing sometimes","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"ghc-6.10.2 runghc fails on ppc sometimes:\r\n\r\nhttp://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log (haddock)\r\n\r\nhttp://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log (HTTP)\r\n\r\nAlso reproduced first-hand on a ppc box.\r\n\r\nFurthermore (may be a different issue) runghc fails for me with\r\nrecent ghc-6.11 snapshots I have built on x86_64.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3196libHSffi_p.a should not be created when profiled libs are disabled2019-07-07T19:04:56ZJens PetersenlibHSffi_p.a should not be created when profiled libs are disabledWhen building ghc-6.11 without profiling libHSffi_p.a is still created. I guess it need not be.
Attaching a small patch to fix that.
ps IMHO it would would be nice to have a configure switch to turn off profiling (--disable-profiling?)...When building ghc-6.11 without profiling libHSffi_p.a is still created. I guess it need not be.
Attaching a small patch to fix that.
ps IMHO it would would be nice to have a configure switch to turn off profiling (--disable-profiling?).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"libHSffi_p.a should not be created when profiled libs are disabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When building ghc-6.11 without profiling libHSffi_p.a is still created. I guess it need not be.\r\n\r\nAttaching a small patch to fix that.\r\n\r\nps IMHO it would would be nice to have a configure switch to turn off profiling (--disable-profiling?).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3197disambiguating type family instances with qualified names not possible2019-07-07T19:04:56Zclaus.reinke@talk21.comdisambiguating type family instances with qualified names not possibleWhile reading [1](http://www.haskell.org/pipermail/haskell-cafe/2009-April/060665.html), it occured to me that type families could be used to parameterize modules by types. So I modified my example from [2](http://www.haskell.org/piperma...While reading [1](http://www.haskell.org/pipermail/haskell-cafe/2009-April/060665.html), it occured to me that type families could be used to parameterize modules by types. So I modified my example from [2](http://www.haskell.org/pipermail/haskell-cafe/2009-April/060324.html), trying to parameterize two modules `A` and `B` with a shared type `Label` (sharing expressed in `C)`, but ran into a few issues:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE EmptyDataDecls #-}
module LA where
data MyLabel
y = undefined::MyLabel
type family Label a
z = undefined::Label ()
```
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE EmptyDataDecls #-}
module LB where
data MyLabel
y = undefined::MyLabel
type family Label a
z = undefined::Label ()
```
```
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE TypeFamilies #-}
module LC where
import LA
import LB
-- fails = [LA.y,LB.y]
-- express type sharing while leaving actual type open
type family Label a
type instance LA.Label a = LC.Label a
type instance LB.Label a = LC.Label a
ok2 = [LA.z,LB.z]
-- for testing only
-- type instance Label a = () -- can't use with or without qualifier:-(
```
Issues:
- is it really necessary for type families to have at least one index? Without that, type constants could be expressed directly
- uncommenting that last line demonstrates a couple of bugs:
- as it stands, the type instance is ambiguous, but the error message has an incorrect source location (`1:0`)
- trying to disambiguate by defining `type instance LC.Label` results in : "Qualified name in binding position: LC.Label" (note that this is permitted a couple of lines up, so it is related to whether the qualifier refers to the current module or an imported one)
\[the bug is not really in the type checker, but specific to type families..\]
Bug aside, it works (`length ok2` gives two, not an error, as `fail` would).
This could be a useful type family programming pattern (it is probably implicit in the comparisons of SML functors vs Haskell type classes/families, I just don't recall it being made so explicit before, just focussing on type parameterization and sharing)!-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"disambiguating type family instances with qualified names not possible","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While reading [http://www.haskell.org/pipermail/haskell-cafe/2009-April/060665.html 1], it occured to me that type families could be used to parameterize modules by types. So I modified my example from [http://www.haskell.org/pipermail/haskell-cafe/2009-April/060324.html 2], trying to parameterize two modules `A` and `B` with a shared type `Label` (sharing expressed in `C)`, but ran into a few issues:\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE EmptyDataDecls #-}\r\nmodule LA where \r\ndata MyLabel\r\ny = undefined::MyLabel\r\n\r\ntype family Label a\r\nz = undefined::Label ()\r\n}}}\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE EmptyDataDecls #-}\r\nmodule LB where \r\ndata MyLabel\r\ny = undefined::MyLabel\r\n\r\ntype family Label a\r\nz = undefined::Label ()\r\n}}}\r\n{{{\r\n{-# LANGUAGE UndecidableInstances #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule LC where\r\nimport LA\r\nimport LB\r\n\r\n-- fails = [LA.y,LB.y]\r\n\r\n-- express type sharing while leaving actual type open\r\ntype family Label a\r\ntype instance LA.Label a = LC.Label a\r\ntype instance LB.Label a = LC.Label a\r\nok2 = [LA.z,LB.z]\r\n\r\n-- for testing only\r\n-- type instance Label a = () -- can't use with or without qualifier:-(\r\n}}}\r\nIssues:\r\n - is it really necessary for type families to have at least one index? Without that, type constants could be expressed directly\r\n\r\n - uncommenting that last line demonstrates a couple of bugs: \r\n\r\n * as it stands, the type instance is ambiguous, but the error message has an incorrect source location (`1:0`)\r\n\r\n * trying to disambiguate by defining `type instance LC.Label` results in : \"Qualified name in binding position: LC.Label\" (note that this is permitted a couple of lines up, so it is related to whether the qualifier refers to the current module or an imported one)\r\n\r\n[the bug is not really in the type checker, but specific to type families..]\r\n\r\nBug aside, it works (`length ok2` gives two, not an error, as `fail` would). \r\n\r\nThis could be a useful type family programming pattern (it is probably implicit in the comparisons of SML functors vs Haskell type classes/families, I just don't recall it being made so explicit before, just focussing on type parameterization and sharing)!-)","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3198inliner fails to kick in for Double (*)2019-07-07T19:04:56ZJulesBeaninliner fails to kick in for Double (*)In GHC HEAD as of approx March 2009, the following very simple code fails to inline the (\*), which means it fails to generate FPU code:
```
module Print where
printTimes :: Double -> Double -> IO ()
printTimes f g = print (f*g)
```
M...In GHC HEAD as of approx March 2009, the following very simple code fails to inline the (\*), which means it fails to generate FPU code:
```
module Print where
printTimes :: Double -> Double -> IO ()
printTimes f g = print (f*g)
```
My evidence for this is that the generated asm (from -O2 -ddump-asm) includes
```
movl %esi,-4(%ebp)
movl 12(%esi),%eax
movl %eax,-16(%ebp)
movl 8(%esi),%eax
movl %eax,-20(%ebp)
movl $_sC3_info,-12(%ebp)
addl $-20,%ebp
jmp _base_GHCziFloat_timesDouble_info
```
1. ..which calls 'GHC.Float.timesDouble' as a regular function with regular stack calling.
Someone confirmed for me that this also happens for them with the released GHC 6.10 versions.
On my copy of 6.8.3 the inlining is fine, and I get proper x87 opcodes:
```
# gmull %fake0,%fake1,%fake0
#GMUL-xxxcase1
ffree %st(7) ; fld %st(1) ; fmulp %st(0),%st(1)
```
Now, if I try a pure version of the code, that is very simply:
```
module Times where
f :: Double -> Double -> Double
f x y = x * y
```
I don't find it inlines in either HEAD or 6.8. It compiles again to a jump to _base_GHCziFloat_timesDouble_info.
In all cases (that is, HEAD, 6.8, pure code and print code) simply replacing `x*y` with `1+x*y` solves the problem.
It seems this is some kind of inliner fragility but I'm reporting it as a bug since it is also a regression from 6.8, in the first form I discovered.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"inliner fails to kick in for Double (*)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In GHC HEAD as of approx March 2009, the following very simple code fails to inline the (*), which means it fails to generate FPU code:\r\n\r\n{{{\r\nmodule Print where\r\n\r\nprintTimes :: Double -> Double -> IO ()\r\nprintTimes f g = print (f*g)\r\n}}}\r\n\r\nMy evidence for this is that the generated asm (from -O2 -ddump-asm) includes\r\n\r\n{{{\r\n\tmovl %esi,-4(%ebp)\r\n\tmovl 12(%esi),%eax\r\n\tmovl %eax,-16(%ebp)\r\n\tmovl 8(%esi),%eax\r\n\tmovl %eax,-20(%ebp)\r\n\tmovl $_sC3_info,-12(%ebp)\r\n\taddl $-20,%ebp\r\n\tjmp _base_GHCziFloat_timesDouble_info\r\n}}}\r\n\r\n...which calls 'GHC.Float.timesDouble' as a regular function with regular stack calling.\r\n\r\nSomeone confirmed for me that this also happens for them with the released GHC 6.10 versions.\r\n\r\nOn my copy of 6.8.3 the inlining is fine, and I get proper x87 opcodes:\r\n\r\n{{{\r\n#\tgmull %fake0,%fake1,%fake0\r\n\t#GMUL-xxxcase1\r\n\tffree %st(7) ; fld %st(1) ; fmulp %st(0),%st(1)\r\n}}}\r\n\r\nNow, if I try a pure version of the code, that is very simply:\r\n\r\n{{{\r\nmodule Times where\r\n\r\nf :: Double -> Double -> Double\r\nf x y = x * y\r\n}}}\r\n\r\nI don't find it inlines in either HEAD or 6.8. It compiles again to a jump to _base_GHCziFloat_timesDouble_info.\r\n\r\nIn all cases (that is, HEAD, 6.8, pure code and print code) simply replacing {{{x*y}}} with {{{1+x*y}}} solves the problem.\r\n\r\nIt seems this is some kind of inliner fragility but I'm reporting it as a bug since it is also a regression from 6.8, in the first form I discovered.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3199System.Environment provides no access to argv[0]2020-07-03T15:23:55ZguestSystem.Environment provides no access to argv[0]The docs for `getProgName` say:
> Computation getProgName returns the name of the program as it was invoked.
> However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return ...The docs for `getProgName` say:
> Computation getProgName returns the name of the program as it was invoked.
> However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return the leafname of the program as invoked. Even then there are some differences between platforms: on Windows, for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return.
I think the "just return the leafname" part is stupid, because it means there is no way for me to get at C's `argv[0]`. How does mangling `argv[0]` increase portability? It just makes Haskell incompatible with everything else out there. Also, if your platform has `argv[0]`, you might as well return it as-is.
Why do I want `argv[0]` at all? Well, the ability to write a drop-in replacement for a C program that does something like `fprintf(stderr, "%s: %s: %s\n", argv[0], filename, strerror(errno))` would be nice (where "drop-in" = character for character the same output). My current project is an IRC bot that can restart itself via `exec()`, preserving state in its command line arguments. However, I usually don't "install" the bot, I just run it from some directory. In this case `argv[0]` would be perfect: if it contains slashes, the bot was run from some directory (and `exec()` will find it there); if it doesn't, the executable was found in the path (and `exec()` will find that too).
To summarize: I think the inability to get at argv\[0\] from Haskell is a bug. If you don't want to change `getProgName`, please consider adding another function (`getNativeProgName`?).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"System.Environment provides no access to argv[0]","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The docs for `getProgName` say:\r\n\r\n Computation getProgName returns the name of the program as it was invoked.\r\n\r\n However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return the leafname of the program as invoked. Even then there are some differences between platforms: on Windows, for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return.\r\n\r\nI think the \"just return the leafname\" part is stupid, because it means there is no way for me to get at C's `argv[0]`. How does mangling `argv[0]` increase portability? It just makes Haskell incompatible with everything else out there. Also, if your platform has `argv[0]`, you might as well return it as-is.\r\n\r\nWhy do I want `argv[0]` at all? Well, the ability to write a drop-in replacement for a C program that does something like `fprintf(stderr, \"%s: %s: %s\\n\", argv[0], filename, strerror(errno))` would be nice (where \"drop-in\" = character for character the same output). My current project is an IRC bot that can restart itself via `exec()`, preserving state in its command line arguments. However, I usually don't \"install\" the bot, I just run it from some directory. In this case `argv[0]` would be perfect: if it contains slashes, the bot was run from some directory (and `exec()` will find it there); if it doesn't, the executable was found in the path (and `exec()` will find that too).\r\n\r\nTo summarize: I think the inability to get at argv[0] from Haskell is a bug. If you don't want to change `getProgName`, please consider adding another function (`getNativeProgName`?).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3200System.Environment.withProgName strips everything before the last slash2019-07-07T19:04:55ZguestSystem.Environment.withProgName strips everything before the last slashThe documentation for `withProgName` says:
> withProgName name act - while executing action act, have getProgName return name.
However:
```
% ghc -e 'System.Environment.withProgName "Hello / World///." System.Environment.getProgName'
...The documentation for `withProgName` says:
> withProgName name act - while executing action act, have getProgName return name.
However:
```
% ghc -e 'System.Environment.withProgName "Hello / World///." System.Environment.getProgName'
"."
```
I discovered this while trying to work around bug #3199 like this:
```
main = do
exe <- readSymbolicLink "/proc/self/exe"
withProgName exe main'
...
```
So... I need to re-exec my program. Fortunately, there is `argv[0]` containing exactly the information I need. Unfortunately, Haskell doesn't let me access it. Fortunately, Linux provides the full path to my program in a special file and Haskell lets me "fix" the program name at startup. Unfortunately, this functionality is broken: `withProgName` only takes the part after the last slash. Back to square one. :-(
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"System.Environment.withProgName strips everything before the last slash","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The documentation for `withProgName` says:\r\n\r\n withProgName name act - while executing action act, have getProgName return name.\r\n\r\nHowever:\r\n{{{\r\n% ghc -e 'System.Environment.withProgName \"Hello / World///.\" System.Environment.getProgName'\r\n\".\"\r\n}}}\r\n\r\nI discovered this while trying to work around bug #3199 like this:\r\n{{{\r\nmain = do\r\n exe <- readSymbolicLink \"/proc/self/exe\"\r\n withProgName exe main'\r\n...\r\n}}}\r\n\r\nSo... I need to re-exec my program. Fortunately, there is `argv[0]` containing exactly the information I need. Unfortunately, Haskell doesn't let me access it. Fortunately, Linux provides the full path to my program in a special file and Haskell lets me \"fix\" the program name at startup. Unfortunately, this functionality is broken: `withProgName` only takes the part after the last slash. Back to square one. :-(","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3201ar: Bad file number2019-07-07T19:04:55ZSimon Marlowar: Bad file numberSatnam Singh reported to me that he gets
```
xargs: /c/ghc/ghc-6.10.1/bin/ar: Bad file number
```
when trying to build GHC on Windows using MSYS. Turning off `SplitObjs` works around it. We should verify and investigate.
<details><sum...Satnam Singh reported to me that he gets
```
xargs: /c/ghc/ghc-6.10.1/bin/ar: Bad file number
```
when trying to build GHC on Windows using MSYS. Turning off `SplitObjs` works around it. We should verify and investigate.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ar: Bad file number","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Satnam Singh reported to me that he gets\r\n\r\n{{{\r\nxargs: /c/ghc/ghc-6.10.1/bin/ar: Bad file number\r\n}}}\r\n\r\nwhen trying to build GHC on Windows using MSYS. Turning off `SplitObjs` works around it. We should verify and investigate.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3202Make XNoMonomorphismRestriction the default in GHCi2019-07-07T19:04:55ZYitzGaleMake XNoMonomorphismRestriction the default in GHCiWhile it has been a subject of debate whether the
Monomorphism Restriction is helpful in compiled code,
it is quite clear that MR is a major annoyance,
if not a bug, at the GHCi prompt.
MR at the GHCi prompt makes it inconvenient
to def...While it has been a subject of debate whether the
Monomorphism Restriction is helpful in compiled code,
it is quite clear that MR is a major annoyance,
if not a bug, at the GHCi prompt.
MR at the GHCi prompt makes it inconvenient
to define functions using `let` at the prompt. It also
unexpectedly assigns monomorphic types to
expressions entered interactively by the user -
in particular when it types numeric constants
as `Integer` when the user needs an `Int`.
None of the purported benefits of MR are relevant
in GHCi. The kinds of problems that MR might help
avoid are unlikely to arise during an interactive
session, since the structure of functions entered
at the prompt is on average far less complex than
functions in source files. Any problems that do
arise will become clear as the interactive session
continues - likely with a clearer error message
(in my personal experience).
MR at the GHCi prompt is one of the most
confusing aspects of GHCi for inexperienced
users, as evidenced by constant traffic on
haskell-cafe and \#haskell.
Disabling MR at the GHCi prompt would
not be a disruptive change. It would not
change the meaning of any program.
It would improve the GHCi workflow of
inexperienced users, and probably most
experienced users. If there are any
experienced users who feel that this
change disrupts their workflow, they can
easily revert to the current behavior
by adding a single line to their `.ghci`
file.
For reference, here is a long discussion about MR
that took place on haskell-cafe a few years ago:
http://www.haskell.org/pipermail/haskell-prime/2006-January/000038.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make XNoMonomorphismRestriction the default in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"While it has been a subject of debate whether the\r\nMonomorphism Restriction is helpful in compiled code,\r\nit is quite clear that MR is a major annoyance,\r\nif not a bug, at the GHCi prompt.\r\n\r\nMR at the GHCi prompt makes it inconvenient\r\nto define functions using {{{let}}} at the prompt. It also\r\nunexpectedly assigns monomorphic types to\r\nexpressions entered interactively by the user -\r\nin particular when it types numeric constants\r\nas {{{Integer}}} when the user needs an {{{Int}}}.\r\n\r\nNone of the purported benefits of MR are relevant\r\nin GHCi. The kinds of problems that MR might help\r\navoid are unlikely to arise during an interactive\r\nsession, since the structure of functions entered\r\nat the prompt is on average far less complex than\r\nfunctions in source files. Any problems that do\r\narise will become clear as the interactive session\r\ncontinues - likely with a clearer error message\r\n(in my personal experience).\r\n\r\nMR at the GHCi prompt is one of the most\r\nconfusing aspects of GHCi for inexperienced\r\nusers, as evidenced by constant traffic on\r\nhaskell-cafe and #haskell.\r\n\r\nDisabling MR at the GHCi prompt would\r\nnot be a disruptive change. It would not\r\nchange the meaning of any program.\r\nIt would improve the GHCi workflow of\r\ninexperienced users, and probably most\r\nexperienced users. If there are any\r\nexperienced users who feel that this\r\nchange disrupts their workflow, they can\r\neasily revert to the current behavior\r\nby adding a single line to their {{{.ghci}}}\r\nfile.\r\n\r\nFor reference, here is a long discussion about MR\r\nthat took place on haskell-cafe a few years ago:\r\n\r\nhttp://www.haskell.org/pipermail/haskell-prime/2006-January/000038.html\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/3203System.Directory.getDirectoryContents functionality on empty String2019-07-07T19:04:55ZjberrymanSystem.Directory.getDirectoryContents functionality on empty StringHello,
It seems to me that getDirectoryContents should return the contents of
the current directory
when passed an empty string, like so:
getDirectoryContents :: FilePath -\> IO \[FilePath\]
getDirectoryContents "" = getCurrentDirector...Hello,
It seems to me that getDirectoryContents should return the contents of
the current directory
when passed an empty string, like so:
getDirectoryContents :: FilePath -\> IO \[FilePath\]
getDirectoryContents "" = getCurrentDirectory \>\>= getDirectoryContents
getDirectoryContents path = do
-- ...etc.
1. ..this would enable the function to work more easily with the
functions in System.FilePath
for example:
getDirectoryContents (dropFileName "directory/file") == OK
getDirectoryContents (dropFileName "file") == FAIL
getDirectoryContents (dropFileName "./") == OK
getDirectoryContents (dropFileName ".") == FAIL
1. ..it also seems like the expected functionality, mirroring the 'ls'
command on \*nix, etc.
Are there any cases/OSes where trying to open a file named "" wouldn't
fail? Any other reasons why this is a bad idea?
Thanks,
Brandon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Directory.getDirectoryContents functionality on empty String","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":["System.Directory"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Hello,\r\n\r\nIt seems to me that getDirectoryContents should return the contents of\r\nthe current directory\r\nwhen passed an empty string, like so:\r\n\r\ngetDirectoryContents :: FilePath -> IO [FilePath]\r\ngetDirectoryContents \"\" = getCurrentDirectory >>= getDirectoryContents\r\ngetDirectoryContents path = do\r\n-- ...etc.\r\n\r\n...this would enable the function to work more easily with the\r\nfunctions in System.FilePath\r\nfor example:\r\n\r\ngetDirectoryContents (dropFileName \"directory/file\") == OK\r\ngetDirectoryContents (dropFileName \"file\") == FAIL\r\n\r\ngetDirectoryContents (dropFileName \"./\") == OK\r\ngetDirectoryContents (dropFileName \".\") == FAIL\r\n\r\n...it also seems like the expected functionality, mirroring the 'ls'\r\ncommand on *nix, etc.\r\n\r\nAre there any cases/OSes where trying to open a file named \"\" wouldn't\r\nfail? Any other reasons why this is a bad idea?\r\n\r\n\r\nThanks,\r\nBrandon","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3204Binary package of GHC 6.10.2 fails to install on debian etch (amd64)2019-07-07T19:04:54ZsolBinary package of GHC 6.10.2 fails to install on debian etch (amd64)Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: Fi...Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized
`strip --version` gives:
```
GNU strip 2.17 Debian GNU/Linux
```
`uname -a` gives:
```
Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Binary package of GHC 6.10.2 fails to install on debian etch (amd64)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:\r\n\r\n/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized\r\n\r\n\r\n{{{strip --version}}} gives:\r\n{{{\r\nGNU strip 2.17 Debian GNU/Linux\r\n}}}\r\n{{{uname -a}}} gives:\r\n{{{\r\nLinux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3205Generalized isomorphic deriving2022-03-07T08:24:23ZajdGeneralized isomorphic derivingA newtype is isomorphic to the type that it is based on. For example, newtype A = A Int is isomorphic to Int, so it is possible to automatically derive all of Int's instance for A.
It would be nice if this could be extended to other dat...A newtype is isomorphic to the type that it is based on. For example, newtype A = A Int is isomorphic to Int, so it is possible to automatically derive all of Int's instance for A.
It would be nice if this could be extended to other datatypes that were isomorphic to each other. For example, this would work
```
data K a = K a a a
instance C (K a) where
...
data L a = L a a a
deriving (Eq,C<-K,Show)
```
where the `C<-K` notation means "derive an instance of C for this type that is 'the same as' the instance of C for K". The compiler would have to check that K and L were actually isomorphic.
I don't know if this is possible with the current internals of GHC, but it would be cool if it would be done. My main usage scenario would be deriving things for single-argument data constructors based on tuples; for example for serialization classes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generalized isomorphic deriving","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"A newtype is isomorphic to the type that it is based on. For example, newtype A = A Int is isomorphic to Int, so it is possible to automatically derive all of Int's instance for A.\r\n\r\nIt would be nice if this could be extended to other datatypes that were isomorphic to each other. For example, this would work\r\n\r\n{{{\r\ndata K a = K a a a\r\n\r\ninstance C (K a) where\r\n ...\r\n\r\ndata L a = L a a a\r\n deriving (Eq,C<-K,Show)\r\n}}}\r\n\r\nwhere the {{{C<-K}}} notation means \"derive an instance of C for this type that is 'the same as' the instance of C for K\". The compiler would have to check that K and L were actually isomorphic.\r\n\r\nI don't know if this is possible with the current internals of GHC, but it would be cool if it would be done. My main usage scenario would be deriving things for single-argument data constructors based on tuples; for example for serialization classes.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3206Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied2019-07-07T19:04:54ZDmitry123Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission deniedI have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error.....
\[root\@spot\]\# ghc
ghc-6.8.3: internal error: getMBlock: mmap: Perm...I have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error.....
\[root\@spot\]\# ghc
ghc-6.8.3: internal error: getMBlock: mmap: Permission denied
(GHC version 6.8.3 for x86_64_unknown_linux)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":["denied","getMBlock","mmap"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error..... \r\n\r\n\r\n[root@spot]# ghc\r\nghc-6.8.3: internal error: getMBlock: mmap: Permission denied\r\n (GHC version 6.8.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3207readMutVar# is inlined/duplicated2023-01-20T15:28:09ZSimon MarlowreadMutVar# is inlined/duplicatedThe following code:
```
module Main where
import Control.Monad.ST.Lazy
import Data.STRef.Lazy
import Data.Array.ST
import Int
import Debug.Trace
data Refs s = Refs
{ memory :: STArray s Int8 Int8
, pc :: STRef s Int8...The following code:
```
module Main where
import Control.Monad.ST.Lazy
import Data.STRef.Lazy
import Data.Array.ST
import Int
import Debug.Trace
data Refs s = Refs
{ memory :: STArray s Int8 Int8
, pc :: STRef s Int8
}
main :: IO ()
main = do
print $ runST m
where
m = do
m <- newArray_ (0,30)
p <- newSTRef 0
let r = Refs m p
writeArray m 0 0x4
v <- readSTRef p
modifySTRef p (+1)
trace ("v: " ++ show v) $ return ()
op <- readArray m v
case trace ("v: " ++ show v) $ op of
0x4 -> modifySTRef p (+100) -- should run this
n -> error ("should never match this: " ++ show n)
```
generates this output:
```
> ./st
v: 0
v: 1
st: MArray: undefined array element
```
That is, the two instances of `trace (show v)` are printing different results, for the same v!
Looking at the Core, the problem seems to be that a call to `readMutVar#` has been inlined and duplicated. The `readMutVar#` primop doesn't have the `has_side_effects` flag set, and setting it (in `primops.txt.pp`) fixes it, but I'm not completely sure if that's the right fix. If it is, then there are lots of other similar primops that also need that flag set.
Bug report originally from a haskell-cafe post: [http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html](http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"readMutVar# is inlined/duplicated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Control.Monad.ST.Lazy\r\nimport Data.STRef.Lazy\r\nimport Data.Array.ST\r\nimport Int\r\nimport Debug.Trace\r\n\r\ndata Refs s = Refs\r\n { memory :: STArray s Int8 Int8\r\n , pc :: STRef s Int8\r\n }\r\n\r\nmain :: IO ()\r\nmain = do\r\n print $ runST m\r\n where\r\n m = do\r\n m <- newArray_ (0,30)\r\n p <- newSTRef 0\r\n let r = Refs m p\r\n writeArray m 0 0x4\r\n v <- readSTRef p\r\n modifySTRef p (+1)\r\n trace (\"v: \" ++ show v) $ return ()\r\n op <- readArray m v\r\n case trace (\"v: \" ++ show v) $ op of\r\n 0x4 -> modifySTRef p (+100) -- should run this\r\n n -> error (\"should never match this: \" ++ show n)\r\n}}}\r\n\r\ngenerates this output:\r\n\r\n{{{\r\n> ./st \r\nv: 0\r\nv: 1\r\nst: MArray: undefined array element\r\n}}}\r\n\r\nThat is, the two instances of `trace (show v)` are printing different results, for the same v!\r\n\r\nLooking at the Core, the problem seems to be that a call to `readMutVar#` has been inlined and duplicated. The `readMutVar#` primop doesn't have the `has_side_effects` flag set, and setting it (in `primops.txt.pp`) fixes it, but I'm not completely sure if that's the right fix. If it is, then there are lots of other similar primops that also need that flag set.\r\n\r\nBug report originally from a haskell-cafe post: [http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3208Incorrect handling of recursive groups with signatures containing equalities ...2019-07-07T19:04:53ZSimon Peyton JonesIncorrect handling of recursive groups with signatures containing equalities and TFsJan Jakubuv found [this](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-May/017147.html):
```
{-# OPTIONS -fglasgow-exts #-}
module Foo where
class SUBST s where
type STerm s
class OBJECT o where
type OTerm o
...Jan Jakubuv found [this](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-May/017147.html):
```
{-# OPTIONS -fglasgow-exts #-}
module Foo where
class SUBST s where
type STerm s
class OBJECT o where
type OTerm o
apply :: (SUBST s, OTerm o ~ STerm s) => s -> o
fce' f = fce . apply $ f
fce f = fce' f
```
yields, with GHC 6.10 or the HEAD:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
idInfo co{v agz} [tv]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Type family panic (taking the IdInfo of a coercion variable)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chak"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Jan Jakubuv found [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-May/017147.html this]:\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule Foo where\r\n\r\nclass SUBST s where\r\n type STerm s\r\n\r\nclass OBJECT o where\r\n type OTerm o\r\n apply :: (SUBST s, OTerm o ~ STerm s) => s -> o\r\n\r\nfce' f = fce . apply $ f\r\n\r\nfce f = fce' f\r\n}}}\r\nyields, with GHC 6.10 or the HEAD:\r\n{{{\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for i386-unknown-linux):\r\n idInfo co{v agz} [tv]\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/3209Use Levenshtein distance for unknown identifier errors2019-07-07T19:04:53ZksfUse Levenshtein distance for unknown identifier errorsThat is, instead of saying
```
Could not find module `IPprint': Use -v to see a list of the files searched for.
```
Say
`Could not find module `IPprint': Use -v to see a list of the files searched for. Did you mean `IPPrint'?
`
, like...That is, instead of saying
```
Could not find module `IPprint': Use -v to see a list of the files searched for.
```
Say
`Could not find module `IPprint': Use -v to see a list of the files searched for. Did you mean `IPPrint'?
`
, likewise for the other namespaces.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use Levenshtein distance for unknown identifier errors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"That is, instead of saying\r\n{{{\r\nCould not find module `IPprint': Use -v to see a list of the files searched for.\r\n}}}\r\nSay \r\n{{{Could not find module `IPprint': Use -v to see a list of the files searched for. Did you mean `IPPrint'?\r\n}}}\r\n\r\n, likewise for the other namespaces.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3210Allow programs to change the number of capabilities2019-07-07T19:04:53ZNeil MitchellAllow programs to change the number of capabilitiesIt would be useful for a program to choose the number of capabilities it has, perhaps in response to a flag. i.e. I'd like users to type `hlint -j3` rather than `hlint +RTS -N3`.
To support this change one option would be to allow incre...It would be useful for a program to choose the number of capabilities it has, perhaps in response to a flag. i.e. I'd like users to type `hlint -j3` rather than `hlint +RTS -N3`.
To support this change one option would be to allow increasing the number of capabilities after a program has started. Another option would be to provide a primitive `restartWithCapabilities :: Int -> IO ()` that aborted the program, and restarted `main` but with the required settings.
Using RTS flags is unsuitable for people who use Haskell programs but aren't really Haskell developers. As more programs go multi-core, this feature will probably become more desirable. However, it's not too important and can always be solved by a little shell script.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow programs to change the number of capabilities","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"FeatureRequest","description":"It would be useful for a program to choose the number of capabilities it has, perhaps in response to a flag. i.e. I'd like users to type {{{hlint -j3}}} rather than {{{hlint +RTS -N3}}}.\r\n\r\nTo support this change one option would be to allow increasing the number of capabilities after a program has started. Another option would be to provide a primitive {{{restartWithCapabilities :: Int -> IO ()}}} that aborted the program, and restarted {{{main}}} but with the required settings.\r\n\r\nUsing RTS flags is unsuitable for people who use Haskell programs but aren't really Haskell developers. As more programs go multi-core, this feature will probably become more desirable. However, it's not too important and can always be solved by a little shell script.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1