GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-01-20T15:28:09Zhttps://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/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/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/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/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/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/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/3097Parser doesn't support doc comments on type aliases2019-07-07T19:05:25ZwaernParser doesn't support doc comments on type aliasesI want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype ...I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype
```
Types with comments are already defined as `ctypedoc` and used for top-level types.
So it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.
The differences are:
- `ctype` disallows foralls/contexts after a contex implication (=\>).
- `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).
- `ctype` allows type equalities (\~) outside contexts. Seems to be disallowed later also.
I haven't seen any further differences (besides comments).
Can I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:
```
(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c
```
<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":"Parser doesn't support doc comments on type aliases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["Haddock"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.\r\n\r\n http://trac.haskell.org/haddock/ticket/9\r\n\r\nIn the parser, the rule for type synonyms is:\r\n{{{\r\n'type' type '=' ctype \r\n}}}\r\n\r\nTypes with comments are already defined as `ctypedoc` and used for top-level types.\r\n\r\nSo it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.\r\n\r\nThe differences are:\r\n\r\n * `ctype` disallows foralls/contexts after a contex implication (=>).\r\n * `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).\r\n * `ctype` allows type equalities (~) outside contexts. Seems to be disallowed later also.\r\n\r\nI haven't seen any further differences (besides comments).\r\n\r\nCan I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:\r\n{{{\r\n(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2921__GLASGOW_HASKELL__ undefined2019-07-07T19:06:16Zguest__GLASGOW_HASKELL__ undefinedAfter manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.
<details><summary>Trac metadata</summary>
|...After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.
<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":"__GLASGOW_HASKELL__ undefined","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":"After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2822Arity expansion not working right2019-07-07T19:06:41ZSimon Peyton JonesArity expansion not working rightWith GHC 6.10, the arity of `GHC.Handle.openFile` is reported as 2. But its definition is
```
openFile fp im = Prelude.catch (...) (...)
```
and `Prelude.catch` has arity 3. Somehow `openFile` isn't getting eta-expanded properly.
It...With GHC 6.10, the arity of `GHC.Handle.openFile` is reported as 2. But its definition is
```
openFile fp im = Prelude.catch (...) (...)
```
and `Prelude.catch` has arity 3. Somehow `openFile` isn't getting eta-expanded properly.
It's not a huge deal, but arity expansion is an important optimisation so I want to track places it isn't happening.
<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":"Arity expansion not working right","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 GHC 6.10, the arity of `GHC.Handle.openFile` is reported as 2. But its definition is\r\n{{{\r\n openFile fp im = Prelude.catch (...) (...)\r\n}}}\r\nand `Prelude.catch` has arity 3. Somehow `openFile` isn't getting eta-expanded properly.\r\n\r\nIt's not a huge deal, but arity expansion is an important optimisation so I want to track places it isn't happening.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2763while installing cabal from darcs, 1.6.0.1 and 1.4.0.22019-07-07T19:06:59Zguestwhile installing cabal from darcs, 1.6.0.1 and 1.4.0.2I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1
Running ubuntu 8.04, running ghc that comes with it
```
root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v
Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2...I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1
Running ubuntu 8.04, running ghc that comes with it
```
root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v
Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2
Using package config file: /usr/lib/ghc-6.8.2/package.conf
Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf
hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1
wired-in package base mapped to base-3.0.1.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package template-haskell mapped to template-haskell-2.2.0.0
wired-in package ndp not found.
Hsc static flags: -static
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc-6.8.2: no input files
Usage: For basic information, try the `--help' option.
root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v
Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2
Using package config file: /usr/lib/ghc-6.8.2/package.conf
Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf
hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1
wired-in package base mapped to base-3.0.1.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package template-haskell mapped to template-haskell-2.2.0.0
wired-in package ndp not found.
Hsc static flags: -static
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc-6.8.2: no input files
Usage: For basic information, try the `--help' option.
root@burn:~/projects/haskell/Cabal-1.4.0.2# uname -a
Linux burn 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux
```
```
root@burn:~/projects/haskell/Cabal-1.4.0.2# ./Setup build
Preprocessing library Cabal-1.4.0.2...
Building Cabal-1.4.0.2...
[13 of 45] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o )
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for x86_64-unknown-linux):
applyTypeToArgs
unix-2.3.0.0:System.Posix.Signals.a38{v rBu} [gid]
(unix-2.3.0.0:System.Posix.Signals.a5{v rBt} [gid]
`cast` (base:GHC.Prim.sym{(w) tc 34v}
(base:Foreign.C.Types.:CoCInt{tc ryy})
:: <pred>base:GHC.Int.Int32{tc 3V}
~
<nt>base:Foreign.C.Types.CInt{tc rz9}))
unix-2.3.0.0:System.Posix.Signals.Ignore{v rBs} [gid]
(base:Data.Maybe.Nothing{v r6a} [gid]
@ <nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr})
eta{v a2Rl} [lid]
(# base:GHC.Prim.State#{(w) tc 32q}
base:GHC.Prim.RealWorld{(w) tc 31E},
<nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr} #)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Another one:
```
@burn:~/projects/haskell/cabal$ ./Setup build
Preprocessing library Cabal-1.6.0.1...
Building Cabal-1.6.0.1...
[ 1 of 50] Compiling Distribution.Simple.GHC.Makefile ( Distribution/Simple/GHC/Makefile.hs, dist/build/Distribution/Simple/GHC/Makefile.o )
[ 2 of 50] Compiling Distribution.Compat.Permissions ( Distribution/Compat/Permissions.hs, dist/build/Distribution/Compat/Permissions.o )
[ 3 of 50] Compiling Distribution.Compat.Exception ( Distribution/Compat/Exception.hs, dist/build/Distribution/Compat/Exception.o )
[ 4 of 50] Compiling Distribution.Compat.TempFile ( Distribution/Compat/TempFile.hs, dist/build/Distribution/Compat/TempFile.o )
[ 5 of 50] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o )
[ 6 of 50] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o )
[ 7 of 50] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o )
[ 8 of 50] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o )
[ 9 of 50] Compiling Language.Haskell.Extension ( Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o )
[10 of 50] Compiling Distribution.System ( Distribution/System.hs, dist/build/Distribution/System.o )
[11 of 50] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o )
[12 of 50] Compiling Distribution.ReadE ( Distribution/ReadE.hs, dist/build/Distribution/ReadE.o )
[13 of 50] Compiling Distribution.Verbosity ( Distribution/Verbosity.hs, dist/build/Distribution/Verbosity.o )
[14 of 50] Compiling Distribution.Package ( Distribution/Package.hs, dist/build/Distribution/Package.o )
[15 of 50] Compiling Distribution.ModuleName ( Distribution/ModuleName.hs, dist/build/Distribution/ModuleName.o )
[16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o )
ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for x86_64-unknown-linux):
applyTypeToArgs
unix-2.3.0.0:System.Posix.Signals.a38{v roIc} [gid]
(unix-2.3.0.0:System.Posix.Signals.a5{v roIb} [gid]
`cast` (base:GHC.Prim.sym{(w) tc 34v}
(base:Foreign.C.Types.:CoCInt{tc r1dN})
:: <pred>base:GHC.Int.Int32{tc 3V}
~
<nt>base:Foreign.C.Types.CInt{tc r17X}))
unix-2.3.0.0:System.Posix.Signals.Ignore{v roIa} [gid]
(base:Data.Maybe.Nothing{v r6E} [gid]
@ <nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9})
eta{v apPk} [lid]
(# base:GHC.Prim.State#{(w) tc 32q}
base:GHC.Prim.RealWorld{(w) tc 31E},
<nt>unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9} #)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2723Unnecessary warning for record wildcards2019-07-07T19:07:09ZjudahUnnecessary warning for record wildcardsWhen compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.
I reproduced this with both 6....When compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.
I reproduced this with both 6.8.3 and 6.10.0.20081007:
```
{-# LANGUAGE RecordWildCards #-}
module WildCard where
data Record = Record {field1 :: Int, field2 :: Double}
test :: Record
test = let
field1 = 10
field2 = 10.0
in Record {..}
```
```
$ ghc --make -Wall WildCard.hs
[1 of 1] Compiling WildCard ( WildCard.hs, WildCard.o )
WildCard.hs:8:4:
Warning: This binding for `field1' shadows the existing binding
defined at WildCard.hs:4:22
In the binding group for: field1, field2
WildCard.hs:9:4:
Warning: This binding for `field2' shadows the existing binding
defined at WildCard.hs:4:37
In the binding group for: field1, field2
```
<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":"Unnecessary warning for record wildcards","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.\r\n\r\nI reproduced this with both 6.8.3 and 6.10.0.20081007:\r\n\r\n{{{\r\n{-# LANGUAGE RecordWildCards #-}\r\nmodule WildCard where\r\n\r\ndata Record = Record {field1 :: Int, field2 :: Double}\r\n\r\ntest :: Record\r\ntest = let\r\n field1 = 10\r\n field2 = 10.0\r\n in Record {..}\r\n}}}\r\n\r\n{{{\r\n$ ghc --make -Wall WildCard.hs\r\n[1 of 1] Compiling WildCard ( WildCard.hs, WildCard.o )\r\n\r\nWildCard.hs:8:4:\r\n Warning: This binding for `field1' shadows the existing binding\r\n defined at WildCard.hs:4:22\r\n In the binding group for: field1, field2\r\n\r\nWildCard.hs:9:4:\r\n Warning: This binding for `field2' shadows the existing binding\r\n defined at WildCard.hs:4:37\r\n In the binding group for: field1, field2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2720eyeball/inline1 still isn't optimised with -fno-method-sharing2019-07-07T19:07:10Zrl@cse.unsw.edu.aueyeball/inline1 still isn't optimised with -fno-method-sharingJust as a reminder: `eyeball/inline1.hs` isn't optimised properly if `-fno-method-sharing` is set after this patch:
```
Tue Sep 9 08:50:11 PDT 2008 simonpj@microsoft.com
* Important performance wibble to callSiteInline (the n_vals_wa...Just as a reminder: `eyeball/inline1.hs` isn't optimised properly if `-fno-method-sharing` is set after this patch:
```
Tue Sep 9 08:50:11 PDT 2008 simonpj@microsoft.com
* Important performance wibble to callSiteInline (the n_vals_wanted > 0 thing)
```
This affects DPH code quite a bit.
<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":"eyeball/inline1 still isn't optimised with -fno-method-sharing","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":"Just as a reminder: `eyeball/inline1.hs` isn't optimised properly if `-fno-method-sharing` is set after this patch:\r\n{{{\r\nTue Sep 9 08:50:11 PDT 2008 simonpj@microsoft.com\r\n * Important performance wibble to callSiteInline (the n_vals_wanted > 0 thing)\r\n}}}\r\nThis affects DPH code quite a bit.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2652fancier prompts for ghci2019-07-07T19:07:30Zjsnxfancier prompts for ghciIt'd be nice to put newlines in a GHCi prompt using standard escape sequences.
It is really unnecessary to support anything more than `%s` as a formatting directive.
<details><summary>Trac metadata</summary>
| Trac field |...It'd be nice to put newlines in a GHCi prompt using standard escape sequences.
It is really unnecessary to support anything more than `%s` as a formatting directive.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| 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":"fancier prompts for ghci","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It'd be nice to put newlines in a GHCi prompt using standard escape sequences.\r\n\r\nIt is really unnecessary to support anything more than `%s` as a formatting directive.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2651BlockedIndefinitely not thrown when it should be2019-07-07T19:07:30ZgovereauBlockedIndefinitely not thrown when it should beThe following program demonstrates the bug.
When run with no arguments, the "die" thread gets a BlockedIndefinitely exception, when run with command line arguments it does not.
```
module Main where
import Control.Monad
import Control.C...The following program demonstrates the bug.
When run with no arguments, the "die" thread gets a BlockedIndefinitely exception, when run with command line arguments it does not.
```
module Main where
import Control.Monad
import Control.Concurrent
import Control.Concurrent.STM
import System.Environment
main :: IO ()
main = do { flags <- getArgs
; if (length flags > 0)
then forkIO die >> -- die does not die
threadDelay 10000000
else die -- die dies
}
-- expect BlockedIndefinitely exception to be thrown
die :: IO ()
die = newTVarIO "die" >>= f >>= print
where f tv = atomically $ do { x <- readTVar tv
; if x == "die" then retry else return x
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"BlockedIndefinitely not thrown when it should be","status":"New","operating_system":"MacOS X","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"The following program demonstrates the bug.\r\nWhen run with no arguments, the \"die\" thread gets a BlockedIndefinitely exception, when run with command line arguments it does not.\r\n{{{\r\nmodule Main where\r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport Control.Concurrent.STM\r\nimport System.Environment\r\n\r\nmain :: IO ()\r\nmain = do { flags <- getArgs\r\n ; if (length flags > 0)\r\n then forkIO die >> -- die does not die\r\n threadDelay 10000000\r\n else die -- die dies \r\n }\r\n\r\n-- expect BlockedIndefinitely exception to be thrown\r\ndie :: IO ()\r\ndie = newTVarIO \"die\" >>= f >>= print\r\n where f tv = atomically $ do { x <- readTVar tv\r\n ; if x == \"die\" then retry else return x\r\n }\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2635ghc panic2019-07-07T19:07:35Zjorzoghc panicghc-6.8.3: panic! (the 'impossible' happened)
(GHC version 6.8.3 for powerpc-apple-darwin):
> parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case
I've been getting intermittent hangs or crashes from GHC such as the er...ghc-6.8.3: panic! (the 'impossible' happened)
(GHC version 6.8.3 for powerpc-apple-darwin):
> parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case
I've been getting intermittent hangs or crashes from GHC such as the error message above. When I restart the build, it successfully compiles. I did not observe this for ghc 6.8.2 on intel. I only observe it for ghc 6.8.3 for ppc which I am running under the Rosetta JIT compiler in order to cross compile to ppc binaries from an intel macintosh.
<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":"ghc panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-6.8.3: panic! (the 'impossible' happened)\r\n (GHC version 6.8.3 for powerpc-apple-darwin):\r\n parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case\r\n\r\nI've been getting intermittent hangs or crashes from GHC such as the error message above. When I restart the build, it successfully compiles. I did not observe this for ghc 6.8.2 on intel. I only observe it for ghc 6.8.3 for ppc which I am running under the Rosetta JIT compiler in order to cross compile to ppc binaries from an intel macintosh.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2568hSetBuffering NoBuffering and getChar don't work properly on Windows2022-02-06T02:43:42ZIan Lynagh <igloo@earth.li>hSetBuffering NoBuffering and getChar don't work properly on WindowsWith this program:
```
import System.IO
main = do { hSetBuffering stdin NoBuffering; run }
run = do { getChar; putStrLn "yes"; run }
```
if I type
```
abc<enter>def<enter><control-C>
```
then:
On Linux and OS X I get the desired ou...With this program:
```
import System.IO
main = do { hSetBuffering stdin NoBuffering; run }
run = do { getChar; putStrLn "yes"; run }
```
if I type
```
abc<enter>def<enter><control-C>
```
then:
On Linux and OS X I get the desired output:
```
$ ./q
ayes
byes
cyes
yes
dyes
eyes
fyes
yes
^Cq: interrupted
```
In an MSYS window I get:
```
$ ./q
abc
def
```
In a cygwin window or a cmd windows I get:
```
$ ./q
abc
yes
yes
yes
yes
def
yes
yes
yes
yes
```
and the program doesn't die.
SSHing into cygwin I get:
```
$ ./q
abc
def
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"hSetBuffering NoBuffering and getChar don't work properly on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With this program:\r\n{{{\r\nimport System.IO\r\n\r\nmain = do { hSetBuffering stdin NoBuffering; run }\r\nrun = do { getChar; putStrLn \"yes\"; run }\r\n}}}\r\nif I type\r\n{{{\r\nabc<enter>def<enter><control-C>\r\n}}}\r\nthen:\r\n\r\nOn Linux and OS X I get the desired output:\r\n{{{\r\n$ ./q\r\nayes\r\nbyes\r\ncyes\r\n\r\nyes\r\ndyes\r\neyes\r\nfyes\r\n\r\nyes\r\n^Cq: interrupted\r\n}}}\r\n\r\nIn an MSYS window I get:\r\n{{{\r\n$ ./q\r\nabc\r\ndef\r\n\r\n}}}\r\nIn a cygwin window or a cmd windows I get:\r\n{{{\r\n$ ./q\r\nabc\r\nyes\r\nyes\r\nyes\r\nyes\r\ndef\r\nyes\r\nyes\r\nyes\r\nyes\r\n}}}\r\nand the program doesn't die.\r\n\r\nSSHing into cygwin I get:\r\n{{{\r\n$ ./q\r\nabc\r\ndef\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2502segfault with GHC.Handle.fdToHandle'2019-07-07T19:08:18ZEricKowsegfault with GHC.Handle.fdToHandle'While trying to configure darcs, a FreeBSD user discovered that the following program segfaults if you compile it with "ghc -threaded -optl-L/usr/local/lib -optl-L/usr/local/lib/ -optl-pthread"
```
import GHC.Handle ( fdToHandle' )
impo...While trying to configure darcs, a FreeBSD user discovered that the following program segfaults if you compile it with "ghc -threaded -optl-L/usr/local/lib -optl-L/usr/local/lib/ -optl-pthread"
```
import GHC.Handle ( fdToHandle' )
import IO ( IOMode(..) )
main = fdToHandle' 1 Nothing False "stdout" WriteMode True
```
For more details, please see http://bugs.darcs.net/issue979
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"segfault with GHC.Handle.fdToHandle'","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to configure darcs, a FreeBSD user discovered that the following program segfaults if you compile it with \"ghc -threaded -optl-L/usr/local/lib -optl-L/usr/local/lib/ -optl-pthread\"\r\n\r\n{{{\r\nimport GHC.Handle ( fdToHandle' )\r\nimport IO ( IOMode(..) )\r\n\r\nmain = fdToHandle' 1 Nothing False \"stdout\" WriteMode True\r\n}}}\r\n\r\nFor more details, please see http://bugs.darcs.net/issue979","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2471generate C wrappers for FFI functions2019-07-07T19:08:25ZSimon Marlowgenerate C wrappers for FFI functionsWe often need to go via a wrapper when calling a C function using the FFI, because the function is part of the API but not the ABI (e.g. it is defined using a CPP macro, or renamed using a CPP macro). In order to support these calls more...We often need to go via a wrapper when calling a C function using the FFI, because the function is part of the API but not the ABI (e.g. it is defined using a CPP macro, or renamed using a CPP macro). In order to support these calls more easily, we could have GHC automatically generate the appropriate C wrappers into the stub file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"generate C wrappers for FFI functions","status":"New","operating_system":"Unknown","component":"Compiler (FFI)","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"We often need to go via a wrapper when calling a C function using the FFI, because the function is part of the API but not the ABI (e.g. it is defined using a CPP macro, or renamed using a CPP macro). In order to support these calls more easily, we could have GHC automatically generate the appropriate C wrappers into the stub file.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2420Multi-method classes are inlined/specialized better than single-method classe...2019-07-07T19:08:40ZsedillardMulti-method classes are inlined/specialized better than single-method classes for strict typesInstances of single-method class are optimized better than instances of multi-method classes. Attached is a small example,
```
class Square a where
square :: a -> a
```
and a simple data type
```
data Pair a = Pair !a !a
instance ...Instances of single-method class are optimized better than instances of multi-method classes. Attached is a small example,
```
class Square a where
square :: a -> a
```
and a simple data type
```
data Pair a = Pair !a !a
instance Num a => Square (Pair a) where
square (Pair a b) = Pair (a*a) (b*b)
```
and a specialized function
```
squarepd :: Pair Double -> Pair Double
squarepd = pair
```
Compiled as is, squarepd will turn into this
```
Test.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(U(L)U(L))m]
Test.squarepd =
\ (eta_sgh :: Test.Pair GHC.Float.Double) ->
case eta_sgh of wild_B1 { Test.Pair a_a60 b_a61 ->
case a_a60 of wild1_agE { GHC.Float.D# x_agG ->
case b_a61 of wild2_Xh2 { GHC.Float.D# x1_Xh7 ->
Test.Pair
@ GHC.Float.Double
(GHC.Float.D# (GHC.Prim.*## x_agG x_agG))
(GHC.Float.D# (GHC.Prim.*## x1_Xh7 x1_Xh7))
}}}
```
Now if you add another method to class Square (anything at all), this happens
```
Test.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(U(L)U(L))m]
Test.squarepd =
__inline_me (\ (ds_dgv :: Test.Pair GHC.Float.Double) ->
case ds_dgv of wild_Xi { Test.Pair a_a5Y b_a5Z ->
Test.$WPair
@ GHC.Float.Double
(GHC.Float.timesDouble a_a5Y a_a5Y)
(GHC.Float.timesDouble b_a5Z b_a5Z)
})
```
Which also what you get when you remove the strictness annotations from 'Pair'.
<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 | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Multi-method classes are inlined/specialized better than single-method classes for strict types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Instances of single-method class are optimized better than instances of multi-method classes. Attached is a small example,\r\n\r\n{{{\r\nclass Square a where\r\n square :: a -> a\r\n}}}\r\n\r\nand a simple data type\r\n\r\n{{{\r\ndata Pair a = Pair !a !a\r\n\r\ninstance Num a => Square (Pair a) where\r\n square (Pair a b) = Pair (a*a) (b*b)\r\n}}}\r\n\r\nand a specialized function \r\n\r\n{{{\r\nsquarepd :: Pair Double -> Pair Double\r\nsquarepd = pair\r\n}}}\r\n\r\n\r\nCompiled as is, squarepd will turn into this\r\n{{{\r\nTest.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double\r\n[GlobalId]\r\n[Arity 1\r\n NoCafRefs\r\n Str: DmdType U(U(L)U(L))m]\r\nTest.squarepd =\r\n \\ (eta_sgh :: Test.Pair GHC.Float.Double) ->\r\n case eta_sgh of wild_B1 { Test.Pair a_a60 b_a61 ->\r\n case a_a60 of wild1_agE { GHC.Float.D# x_agG ->\r\n case b_a61 of wild2_Xh2 { GHC.Float.D# x1_Xh7 ->\r\n Test.Pair\r\n @ GHC.Float.Double\r\n (GHC.Float.D# (GHC.Prim.*## x_agG x_agG))\r\n (GHC.Float.D# (GHC.Prim.*## x1_Xh7 x1_Xh7)) \r\n }}}\r\n}}}\r\n\r\nNow if you add another method to class Square (anything at all), this happens\r\n\r\n{{{\r\nTest.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double\r\n[GlobalId]\r\n[Arity 1\r\n NoCafRefs\r\n Str: DmdType U(U(L)U(L))m]\r\nTest.squarepd =\r\n __inline_me (\\ (ds_dgv :: Test.Pair GHC.Float.Double) ->\r\n case ds_dgv of wild_Xi { Test.Pair a_a5Y b_a5Z ->\r\n Test.$WPair\r\n @ GHC.Float.Double\r\n (GHC.Float.timesDouble a_a5Y a_a5Y)\r\n (GHC.Float.timesDouble b_a5Z b_a5Z)\r\n })\r\n}}}\r\n\r\nWhich also what you get when you remove the strictness annotations from 'Pair'.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branch