GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:37:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10193TypeRep Show instance doesn't add parens around type operators2019-07-07T18:37:09Zpawel.nowakTypeRep Show instance doesn't add parens around type operatorsThe following code
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
{-# LANGUAGE TypeOperators #-}
import Data.Typeable
data a :*: b = Pair a b
main = print (typeOf (Pair 'a' 'b'))
```
prints
```hs
:*: Char Char
```
which is not valid Has...The following code
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
{-# LANGUAGE TypeOperators #-}
import Data.Typeable
data a :*: b = Pair a b
main = print (typeOf (Pair 'a' 'b'))
```
prints
```hs
:*: Char Char
```
which is not valid Haskell. I belive it should print
```hs
(:*:) Char Char
```
In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation:
```hs
let type_str = show $ Data.Typeable.typeOf wit
...
let expr_typesig = concat [parens e, " :: ", type_str]
```
What results in a parse error.
I can write a patch if someone confirms that's the desired behavior and doesn't break anything.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TypeRep Show instance doesn't add parens around type operators","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The following code\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AutoDeriveTypeable #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nimport Data.Typeable\r\n\r\ndata a :*: b = Pair a b\r\n\r\nmain = print (typeOf (Pair 'a' 'b'))\r\n}}}\r\n\r\nprints\r\n\r\n{{{#!hs\r\n:*: Char Char\r\n}}}\r\n\r\nwhich is not valid Haskell. I belive it should print\r\n\r\n{{{#!hs\r\n(:*:) Char Char\r\n}}}\r\n\r\nIn my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation:\r\n\r\n{{{#!hs\r\nlet type_str = show $ Data.Typeable.typeOf wit\r\n...\r\nlet expr_typesig = concat [parens e, \" :: \", type_str]\r\n}}}\r\nWhat results in a parse error.\r\n\r\nI can write a patch if someone confirms that's the desired behavior and doesn't break anything.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10169bracket not running the final action on termination through SIGTERM2022-03-01T11:55:54ZSven Bartschersven.bartscher@weltraumschlangen.debracket not running the final action on termination through SIGTERMIf a program compiled with GHC receives a SIGTERM signal, while in a bracket, the final action of the bracket isn't executed. This can be tested with this program:
```hs
import Control.Exception
import Control.Concurrent
main = bracket...If a program compiled with GHC receives a SIGTERM signal, while in a bracket, the final action of the bracket isn't executed. This can be tested with this program:
```hs
import Control.Exception
import Control.Concurrent
main = bracket (return "ending")
(\x -> putStrLn x)
(\_ -> threadDelay 10000000000)
```
When running this and interrupting with ctrl-c (thus SIGINT) it prints "ending", like expected. When interrupting it with `killall -TERM test` (assuming the program was named test) "ending" isn't printed and the program terminates immediately. It prints a system specific message though.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bracket not running the final action on termination through SIGTERM","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"If a program compiled with GHC receives a SIGTERM signal, while in a bracket, the final action of the bracket isn't executed. This can be tested with this program:\r\n\r\n{{{#!hs\r\nimport Control.Exception\r\nimport Control.Concurrent\r\n\r\nmain = bracket (return \"ending\")\r\n (\\x -> putStrLn x)\r\n (\\_ -> threadDelay 10000000000)\r\n}}}\r\n\r\nWhen running this and interrupting with ctrl-c (thus SIGINT) it prints \"ending\", like expected. When interrupting it with {{{killall -TERM test}}} (assuming the program was named test) \"ending\" isn't printed and the program terminates immediately. It prints a system specific message though.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10160GHCi :sprint has odd/unhelpful behavior for values defined within the REPL2021-11-15T21:21:26ZbitemyappGHCi :sprint has odd/unhelpful behavior for values defined within the REPLWanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain ...Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness.
Examples with code in the REPL:
```
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> :sprint x
x = [1,2,3]
-- errr, what?
Prelude> let x = Just (1 :: Integer)
Prelude> :sprint x
x = Just 1
Prelude> let just = Just
Prelude> let x = just (1 :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = Just (undefined :: Integer)
Prelude> :sprint x
x = Just _
Prelude> let x = just (undefined :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> let y = x
Prelude> :sprint y
y = [1,2,3]
Prelude> let x = 1 : 2 : (3 :: Integer) : []
Prelude> :sprint x
x = [1,2,3]
Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)]
Prelude> :sprint x
x = _
Prelude> let y = (:)
Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` []))
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = [1,2,3]
```
So the behavior here seems to be:
Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated
Example, but with loading data from a file:
Contents of the file:
```
x :: Num a => [a]
x = [1, 2, 3]
```
GHCi session:
```
Prelude> :t x
x :: Num a => [a]
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = _
-- ^^ this is expected
```
Then when x is loaded from a file, but has a different type:
```
Prelude> :t x
x :: [Integer]
Prelude> :sprint x
x = _
Prelude> head x
1
Prelude> :sprint x
x = [1,2,3]
-- ^^ this is not
```
Now, this is a bit confusing. Earlier I was able to get :sprint to return \[1, _, _\] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior.
Is there documentation that explains:
1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi
1. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this)
1. Why evaluating 'head x' forces the other values as well
Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on.
:sprint not demonstrating semantics that match what I expect from a non-strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values.
```
-- So that you know i picked "7.8.4" as the version consciously
[callen@atlantis ~/Work/fpbook]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
[callen@atlantis ~/Work/fpbook]$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
```https://gitlab.haskell.org/ghc/ghc/-/issues/10123GHCi won't start in Powershell ISE2019-07-07T18:37:24ZqwfyGHCi won't start in Powershell ISETo reproduce,
1. Start Powershell ISE (Windows PowerShell ISE Host 4.0 on Windows 8.1)
1. Type "ghci"
You will see the output:
```
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... ...To reproduce,
1. Start Powershell ISE (Windows PowerShell ISE Host 4.0 on Windows 8.1)
1. Type "ghci"
You will see the output:
```
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
```
After `Loading package base ... linking ... done.`, GHCi just hangs, won't continue, the prompt is never displayed.https://gitlab.haskell.org/ghc/ghc/-/issues/10111hp2ps silently discards samples2019-07-07T18:37:27ZEdward Z. Yanghp2ps silently discards samplesConsider the following hp file:
```
JOB "whatever"
DATE "Sat Feb 21 12:56 2015"
SAMPLE_UNIT "seconds"
VALUE_UNIT "bytes"
BEGIN_SAMPLE 0.00
MAIN 1000
END_SAMPLE 0.00
BEGIN_SAMPLE 0.00
MAIN 100
END_SAMPLE 0.00
BEGIN_SAMPLE 0.01
MAIN 500
E...Consider the following hp file:
```
JOB "whatever"
DATE "Sat Feb 21 12:56 2015"
SAMPLE_UNIT "seconds"
VALUE_UNIT "bytes"
BEGIN_SAMPLE 0.00
MAIN 1000
END_SAMPLE 0.00
BEGIN_SAMPLE 0.00
MAIN 100
END_SAMPLE 0.00
BEGIN_SAMPLE 0.01
MAIN 500
END_SAMPLE 0.01
```
hp2ps will generate a graph showing heap usage going from 100 bytes to 500 bytes... not 1000-100-500 as expected. This is because hp2ps only uses the last sample with the same timestamp.
These hp files show in practice because GHC doesn't output BEGIN_SAMPLE entries with enough precision, see also https://phabricator.haskell.org/D679 to increase the precision.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"hp2ps silently discards samples","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following hp file:\r\n\r\n{{{\r\nJOB \"whatever\"\r\nDATE \"Sat Feb 21 12:56 2015\"\r\nSAMPLE_UNIT \"seconds\"\r\nVALUE_UNIT \"bytes\"\r\nBEGIN_SAMPLE 0.00\r\nMAIN\t1000\r\nEND_SAMPLE 0.00\r\nBEGIN_SAMPLE 0.00\r\nMAIN\t100\r\nEND_SAMPLE 0.00\r\nBEGIN_SAMPLE 0.01\r\nMAIN\t500\r\nEND_SAMPLE 0.01\r\n}}}\r\n\r\nhp2ps will generate a graph showing heap usage going from 100 bytes to 500 bytes... not 1000-100-500 as expected. This is because hp2ps only uses the last sample with the same timestamp.\r\n\r\nThese hp files show in practice because GHC doesn't output BEGIN_SAMPLE entries with enough precision, see also https://phabricator.haskell.org/D679 to increase the precision.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10092lex doesn't handle binary literals2019-07-07T18:37:35ZRyan Scottlex doesn't handle binary literalsThe `lex` function from `Text.Read.Lex` (on which the `Read` instance for `Lexeme` is based) can't read binary literals on GHC 7.10.1-rc2:
```
$ ghci -XBinaryLiterals
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for he...The `lex` function from `Text.Read.Lex` (on which the `Read` instance for `Lexeme` is based) can't read binary literals on GHC 7.10.1-rc2:
```
$ ghci -XBinaryLiterals
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
λ> 0b101010
42
λ> import Text.Read.Lex
λ> read "0b101010" :: Lexeme
*** Exception: Prelude.read: no parse
```
This should be a simple fix, but I'm not sure if this is the intended behavior or not, since `BinaryLiterals` isn't a part of the Haskell 2010 standard (and I'm not sure how closely `lex` adheres to that).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lex doesn't handle binary literals","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2:\r\n\r\n{{{\r\n$ ghci -XBinaryLiterals\r\nGHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help\r\nλ> 0b101010\r\n42\r\nλ> import Text.Read.Lex\r\nλ> read \"0b101010\" :: Lexeme\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nThis should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that).","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10082Church Booleans - xor2019-07-07T18:37:37Zhonza889Church Booleans - xorWhen I use following implementation of Church Booleans, all is ok:
```hs
lTrue = \x y -> x
lFalse = \x y -> y
lNot = \t -> t lFalse lTrue
lXor = \u v -> u (lNot v) (lNot lNot v)
lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse)
```
B...When I use following implementation of Church Booleans, all is ok:
```hs
lTrue = \x y -> x
lFalse = \x y -> y
lNot = \t -> t lFalse lTrue
lXor = \u v -> u (lNot v) (lNot lNot v)
lXor' = \u v -> u (v lFalse lTrue) (v lTrue lFalse)
```
But this simplified versions of lXor fails, if first parameter is lFalse:
```hs
lXor'' = \u v -> u (lNot v) (v) -- not work, bug in ghc?
lXor''' = \u v -> u (lNot v) v -- not work, bug in ghc?
```
```hs
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
Prelude> :l lambda.hs
[1 of 1] Compiling Main ( lambda.hs, interpreted )
Ok, modules loaded: Main.
*Main> (lXor'' lFalse lFalse) 1 0
<interactive>:3:1:
Non type-variable argument in the constraint: Num (t5 -> t4 -> t5)
(Use FlexibleContexts to permit this)
When checking that ‘it’ has the inferred type
it :: forall t4 t5. Num (t5 -> t4 -> t5) => t5 -> t4 -> t5
<interactive>:3:24:
Could not deduce (Num (t20 -> t30 -> t30))
arising from the literal ‘1’
from the context (Num (t5 -> t4 -> t5))
bound by the inferred type of
it :: Num (t5 -> t4 -> t5) => t5 -> t4 -> t5
at <interactive>:3:1-26
The type variables ‘t20’, ‘t30’ are ambiguous
In the third argument of ‘lXor''’, namely ‘1’
In the expression: (lXor'' lFalse lFalse) 1 0
In an equation for ‘it’: it = (lXor'' lFalse lFalse) 1 0
```
Because both lXor implementations in first example works ok and simplified implementation should be equivalent, I believe this is bug in ghc. But similar problem occure also in older versions of ghc:
```hs
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :l lambda.hs
[1 of 1] Compiling Main ( lambda.hs, interpreted )
Ok, modules loaded: Main.
*Main> (lXor'' lFalse lFalse) 1 0
<interactive>:3:24:
No instance for (Num (t20 -> t30 -> t30))
arising from the literal `1'
Possible fix:
add an instance declaration for (Num (t20 -> t30 -> t30))
In the third argument of lXor'', namely `1'
In the expression: (lXor'' lFalse lFalse) 1 0
In an equation for `it': it = (lXor'' lFalse lFalse) 1 0
<interactive>:3:26:
No instance for (Num (t50 -> t40 -> t50))
arising from the literal `0'
Possible fix:
add an instance declaration for (Num (t50 -> t40 -> t50))
In the fourth argument of lXor'', namely `0'
In the expression: (lXor'' lFalse lFalse) 1 0
In an equation for `it': it = (lXor'' lFalse lFalse) 1 0
```https://gitlab.haskell.org/ghc/ghc/-/issues/10081SIGTERM ignored when process has been detached from terminal2019-07-07T18:37:37ZnakalSIGTERM ignored when process has been detached from terminalI've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:
```hs
import Control.Concurrent
import Control.Monad
import System.Exit
import System.IO
import System.Posix.Signals
loop = foreve...I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:
```hs
import Control.Concurrent
import Control.Monad
import System.Exit
import System.IO
import System.Posix.Signals
loop = forever $ threadDelay 1000000
main = do
ppid <- myThreadId
mapM (\sig -> installHandler sig (Catch $ trap ppid) Nothing)
[ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ]
loop
trap tid = do
hPutStrLn stderr "Signal received.\n"
throwTo tid ExitSuccess
```
Such daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal:
```
> ./daemon
Signal received.
```
With:
```
> killall daemon
```
in other terminal.
Other test, when I run it in background:
```
> ./daemon
(press Ctrl+Z)
> bg
> killall daemon
Signal received.
```
This case is also ok. Now the third test which is also OK:
```
> ./daemon > log 2>&1
(press Ctrl+Z)
> bg
> exit
```
In second terminal:
```
> cat log
> killall daemon
> cat log
Signal received.
> killall daemon
No matching processes belonging to you were found
```
Now the fourth test which is simply without a log file and this one fails:
```
> ./daemon
(press Ctrl+Z)
> bg
> exit
```
On some other terminal try to kill the process:
```
> killall xxx
> killall xxx
> killall xxx
> killall -9 xxx
> killall xxx
No matching processes belonging to you were found
```
Signal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | FreeBSD |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SIGTERM ignored when process has been detached from terminal","status":"New","operating_system":"FreeBSD","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport System.Exit\r\nimport System.IO\r\nimport System.Posix.Signals\r\n\r\nloop = forever $ threadDelay 1000000\r\n\r\nmain = do\r\n ppid <- myThreadId\r\n mapM (\\sig -> installHandler sig (Catch $ trap ppid) Nothing)\r\n [ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ]\r\n loop\r\n\r\ntrap tid = do\r\n hPutStrLn stderr \"Signal received.\\n\"\r\n throwTo tid ExitSuccess\r\n}}}\r\n\r\nSuch daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal:\r\n\r\n{{{\r\n> ./daemon\r\nSignal received.\r\n}}}\r\n\r\nWith:\r\n{{{\r\n> killall daemon\r\n}}}\r\n\r\nin other terminal.\r\n\r\nOther test, when I run it in background:\r\n{{{\r\n> ./daemon\r\n(press Ctrl+Z)\r\n> bg\r\n> killall daemon\r\nSignal received.\r\n}}}\r\n\r\nThis case is also ok. Now the third test which is also OK:\r\n\r\n{{{\r\n> ./daemon > log 2>&1\r\n(press Ctrl+Z)\r\n> bg\r\n> exit\r\n}}}\r\n\r\nIn second terminal:\r\n{{{\r\n> cat log\r\n> killall daemon\r\n> cat log\r\nSignal received.\r\n\r\n> killall daemon\r\nNo matching processes belonging to you were found\r\n}}}\r\n\r\nNow the fourth test which is simply without a log file and this one fails:\r\n{{{\r\n> ./daemon\r\n(press Ctrl+Z)\r\n> bg\r\n> exit\r\n}}}\r\n\r\nOn some other terminal try to kill the process:\r\n{{{ \r\n> killall xxx\r\n> killall xxx\r\n> killall xxx\r\n> killall -9 xxx\r\n> killall xxx\r\nNo matching processes belonging to you were found\r\n}}}\r\n\r\nSignal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10078tcPluginStop of a type checker plugin is not called if an error occurs2019-07-07T18:37:39ZjbrackertcPluginStop of a type checker plugin is not called if an error occursWhen a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChec...When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.
### Test plugin
`MyPlugin.hs`:
```hs
module MyPlugin
( plugin ) where
import Plugins
import TcRnTypes
import TcPluginM
plugin :: Plugin
plugin = defaultPlugin
{ tcPlugin = \clos -> Just $ TcPlugin
{ tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init"
, tcPluginSolve = \_ _ _ _ -> do
tcPluginIO $ putStrLn ">>> Plugin Solve"
return $ TcPluginOk [] []
, tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop"
}
}
```
### Minimal example (with type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return 1
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Solve
Main.hs:6:10:
Could not deduce (Num ()) arising from the literal ‘1’
from the context: Monad m
bound by the type signature for: main :: Monad m => m ()
at Main.hs:4:9-25
In the first argument of ‘return’, namely ‘1’
In a stmt of a 'do' block: return 1
In the expression: do { return 1 }
```
Which means `tcPluginStop` was _not_ called.
### Minimal example (without type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return ()
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Stop
Linking Main ...
```
Which means `tcPluginStop` _was_ called.
### Possible solution
As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
to
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
case eitherRes of
Left e -> failM
Right res -> return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
.
I have tried this. It compiles and my minimal example delivers the correct result.
Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | adamgundry |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tcPluginStop of a type checker plugin is not called if an error occurs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["adamgundry"],"type":"Bug","description":"When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.\r\n\r\nI am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.\r\n\r\n=== Test plugin\r\n\r\n`MyPlugin.hs`:\r\n{{{#!hs\r\nmodule MyPlugin\r\n ( plugin ) where\r\n\r\nimport Plugins\r\nimport TcRnTypes\r\nimport TcPluginM\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin \r\n { tcPlugin = \\clos -> Just $ TcPlugin \r\n { tcPluginInit = tcPluginIO $ putStrLn \">>> Plugin Init\"\r\n , tcPluginSolve = \\_ _ _ _ -> do\r\n tcPluginIO $ putStrLn \">>> Plugin Solve\"\r\n return $ TcPluginOk [] []\r\n , tcPluginStop = \\_ -> tcPluginIO $ putStrLn \">>> Plugin Stop\"\r\n }\r\n }\r\n}}}\r\n\r\n=== Minimal example (with type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return 1\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n\r\nMain.hs:6:10:\r\n Could not deduce (Num ()) arising from the literal ‘1’\r\n from the context: Monad m\r\n bound by the type signature for: main :: Monad m => m ()\r\n at Main.hs:4:9-25\r\n In the first argument of ‘return’, namely ‘1’\r\n In a stmt of a 'do' block: return 1\r\n In the expression: do { return 1 }\r\n}}}\r\nWhich means `tcPluginStop` was _not_ called.\r\n\r\n=== Minimal example (without type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return ()\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Stop\r\nLinking Main ...\r\n}}}\r\nWhich means `tcPluginStop` _was_ called.\r\n\r\n=== Possible solution\r\n\r\nAs far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n res <- updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\nto\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n eitherRes <- tryM $ do updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n case eitherRes of\r\n Left e -> failM\r\n Right res -> return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\n.\r\n\r\nI have tried this. It compiles and my minimal example delivers the correct result.\r\n\r\nAre there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1jbrackerjbrackerhttps://gitlab.haskell.org/ghc/ghc/-/issues/10046Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales2019-07-07T18:37:48ZHoward B. GoldenLinker script patch in rts/Linker.c doesn't work for (non-C or non-en..) localesPlease see [ticket:2615\#comment:95729](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95729) and replies.
A bug is illustrated by this Haskell program:
```
import ObjLink
import Foreign
import Foreign.C.Types
import Foreign.C.St...Please see [ticket:2615\#comment:95729](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95729) and replies.
A bug is illustrated by this Haskell program:
```
import ObjLink
import Foreign
import Foreign.C.Types
import Foreign.C.String
foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO CString
main = do
withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc
r <- loadDLL "/usr/lib/libc.so"
putStrLn (show r)
```
which outputs:
```
Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836"
```
The "\\26080\\25928\\30340 ELF \\22836" part is "无效的ELF头" in Chinese.
This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale.
The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see [ticket:2615\#comment:95752](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95752)) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary.
Also see #9237 for another corner case in the linker script code that should be dealt with at the same time.8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10018Cannot define custom fixity for infix data constructors in GHCi2019-07-07T18:37:54ZRyan ScottCannot define custom fixity for infix data constructors in GHCiWhen compiling from a module, declaring a custom fixity for an infix data constructor is valid:
```hs
module DataFixity where
data Infix a b = a :@: b
infixl 4 :@:
```
And GHCi recognizes this:
```
$ ghci DataFixity.hs
GHCi, version ...When compiling from a module, declaring a custom fixity for an infix data constructor is valid:
```hs
module DataFixity where
data Infix a b = a :@: b
infixl 4 :@:
```
And GHCi recognizes this:
```
$ ghci DataFixity.hs
GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling DataFixity ( DataFixity.hs, interpreted )
Ok, modules loaded: DataFixity.
λ> :i :@:
data Infix a b = a :@: b -- Defined at DataFixity.hs:3:18
infixl 4 :@:
```
However, one cannot do this entirely in GHCi:
```
$ ghci
GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ> data Infix a b = a :@: b; infixl 4 :@:
λ> :i (:@:)
data Infix a b = a :@: b -- Defined at <interactive>:2:18
```
GHCi simply assumes `:@:` has the default infix precedence.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot define custom fixity for infix data constructors in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"When compiling from a module, declaring a custom fixity for an infix data constructor is valid:\r\n\r\n{{{#!hs\r\nmodule DataFixity where\r\n\r\ndata Infix a b = a :@: b\r\ninfixl 4 :@:\r\n}}}\r\n\r\nAnd GHCi recognizes this:\r\n\r\n{{{\r\n$ ghci DataFixity.hs\r\nGHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling DataFixity ( DataFixity.hs, interpreted )\r\nOk, modules loaded: DataFixity.\r\nλ> :i :@:\r\ndata Infix a b = a :@: b -- Defined at DataFixity.hs:3:18\r\ninfixl 4 :@:\r\n}}}\r\n\r\nHowever, one cannot do this entirely in GHCi:\r\n{{{\r\n$ ghci\r\nGHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nλ> data Infix a b = a :@: b; infixl 4 :@:\r\nλ> :i (:@:)\r\ndata Infix a b = a :@: b -- Defined at <interactive>:2:18\r\n}}}\r\n\r\nGHCi simply assumes {{{:@:}}} has the default infix precedence.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10010LLVM/optimized code for sqrt incorrect for negative values2023-08-23T11:41:57ZglguyLLVM/optimized code for sqrt incorrect for negative valuesThe LLVM sqrt intrinsic is undefined below values of -0.0
See http://llvm.org/docs/LangRef.html\#llvm-sqrt-intrinsic
In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.
This cause...The LLVM sqrt intrinsic is undefined below values of -0.0
See http://llvm.org/docs/LangRef.html\#llvm-sqrt-intrinsic
In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.
This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen.
```
main = print (sqrt (-7 :: Double))
```
```
$ ghc -O -fllvm Sqrt.hs
[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )
Linking Sqrt ...
$ ./Sqrt
0.0
$ ghc -O Sqrt.hs
[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )
Linking Sqrt ...
$ ./Sqrt
NaN
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM/optimized code for sqrt incorrect for negative values","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The LLVM sqrt intrinsic is undefined below values of -0.0\r\n\r\nSee http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic\r\n\r\nIn some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined.\r\n\r\nThis causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen.\r\n\r\n{{{\r\nmain = print (sqrt (-7 :: Double))\r\n}}}\r\n\r\n{{{\r\n$ ghc -O -fllvm Sqrt.hs\r\n[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )\r\nLinking Sqrt ...\r\n$ ./Sqrt \r\n0.0\r\n$ ghc -O Sqrt.hs\r\n[1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o )\r\nLinking Sqrt ...\r\n$ ./Sqrt \r\nNaN\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/9991runghc shows the value produced by main when its type is a non-() Show instance2019-07-07T18:38:01Zshachafrunghc shows the value produced by main when its type is a non-() Show instanceWhen running a program like this:
```hs
main :: IO Int
main = return 5
```
With `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior:
```
$ runghc Main.hs
5
$ ghc Main.hs
[1 of 1] Comp...When running a program like this:
```hs
main :: IO Int
main = return 5
```
With `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior:
```
$ runghc Main.hs
5
$ ghc Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
$
```
This is the same as `ghci`'s behavior with an IO action, so presumably `runghc` is taking a shortcut here. But a program should behave the same way in both cases.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| 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":"runghc shows the value produced by main when its type is a non-() Show instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When running a program like this:\r\n\r\n{{{#!hs\r\nmain :: IO Int\r\nmain = return 5\r\n}}}\r\n\r\nWith `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior:\r\n\r\n{{{\r\n$ runghc Main.hs\r\n5\r\n$ ghc Main.hs\r\n[1 of 1] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main\r\n$\r\n}}}\r\n\r\nThis is the same as `ghci`'s behavior with an IO action, so presumably `runghc` is taking a shortcut here. But a program should behave the same way in both cases.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9965getChanContents BlockedIndefinitelyOnMVar on 7.10 RC12019-07-07T18:38:11ZjberrymangetChanContents BlockedIndefinitelyOnMVar on 7.10 RC1All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10:
```hs
module Main where
import Control.Concurrent.Chan
import Control.Monad
main = do
io <- newChan
let inp = [0] :: [Int]
mapM_ (writeChan io...All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10:
```hs
module Main where
import Control.Concurrent.Chan
import Control.Monad
main = do
io <- newChan
let inp = [0] :: [Int]
mapM_ (writeChan io) inp
{-
-- WORKS:
outp <- getChanContents io
if 0 == head outp
then putStrLn "OK"
else error $ "Smoke test failed"
-}
-- BROKEN ON 7.10 (BlockedIndefinitelyOnMVar):
outp <- getChanContents io
if and (zipWith (==) inp outp)
then putStrLn "OK"
else error $ "Smoke test failed"
{-
-- WORKS:
forM_ inp $ \xIn-> do
xOut <- readChan io
unless (xIn == xOut) $
error $ "Smoke test failed"
-}
```
I first noticed the behavior in a Chan-like library I wrote, whose internals are completely different from Chan, but where the getChanContents is a copy-paste from Chan. So I assume it has something to do with `unsafeInterleaveIO`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport Control.Concurrent.Chan\r\nimport Control.Monad\r\n\r\nmain = do\r\n io <- newChan\r\n let inp = [0] :: [Int]\r\n mapM_ (writeChan io) inp\r\n{-\r\n -- WORKS:\r\n outp <- getChanContents io\r\n if 0 == head outp\r\n then putStrLn \"OK\"\r\n else error $ \"Smoke test failed\"\r\n-}\r\n -- BROKEN ON 7.10 (BlockedIndefinitelyOnMVar):\r\n outp <- getChanContents io\r\n if and (zipWith (==) inp outp)\r\n then putStrLn \"OK\"\r\n else error $ \"Smoke test failed\"\r\n{-\r\n -- WORKS:\r\n forM_ inp $ \\xIn-> do\r\n xOut <- readChan io\r\n unless (xIn == xOut) $\r\n error $ \"Smoke test failed\"\r\n-}\r\n}}}\r\n\r\nI first noticed the behavior in a Chan-like library I wrote, whose internals are completely different from Chan, but where the getChanContents is a copy-paste from Chan. So I assume it has something to do with `unsafeInterleaveIO`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9936Data.Fixed truncates 5.17 to 5.162019-07-07T18:38:21ZsingpolymaData.Fixed truncates 5.17 to 5.16`(realToFrac (5.17 :: Double) :: Centi) == 5.16`
is true -- it should be false.
The offender seems to be the assumption in `fromRational`:
`fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))`
Uses `floor`...`(realToFrac (5.17 :: Double) :: Centi) == 5.16`
is true -- it should be false.
The offender seems to be the assumption in `fromRational`:
`fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))`
Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Fixed truncates 5.17 to 5.16","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"`(realToFrac (5.17 :: Double) :: Centi) == 5.16`\r\nis true -- it should be false.\r\n\r\nThe offender seems to be the assumption in `fromRational`:\r\n\r\n`fromRational r = withResolution (\\res -> MkFixed (floor (r * (toRational res))))`\r\n\r\nUses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9891Fixity declarations for pattern synonyms not persisted2019-07-07T18:38:36ZklkblakeFixity declarations for pattern synonyms not persistedIt appears fixity declarations for pattern synonyms only affect modules being compiled in the same run as the module the definition is in. For example, take the following files:
Foo.hs:
```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo...It appears fixity declarations for pattern synonyms only affect modules being compiled in the same run as the module the definition is in. For example, take the following files:
Foo.hs:
```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo where
data Type = Type Int RawType
data RawType = Product Type Type
| Num
pattern a :*: b <- Type _ (Product a b)
infixr 7 :*:
```
Bar.hs:
```hs
{-# LANGUAGE PatternSynonyms #-}
module Main where
import Foo
value = Type 0 $ Product (Type 1 Num) $ Type 2 $ Product (Type 3 Num) $ Type 4 Num
somethingElse = 23
main = case value of
_ :*: _ :*: _ -> putStrLn "Success"
_ -> putStrLn "Fail"
```
On the first compile, the executable will print "Success". Modifying Bar and recompiling will result in it printing "Fail". Modifying both and recompiling results in "Success" again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Fixity declarations for pattern synonyms not persisted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears fixity declarations for pattern synonyms only affect modules being compiled in the same run as the module the definition is in. For example, take the following files:\r\n\r\nFoo.hs:\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\nmodule Foo where\r\n\r\ndata Type = Type Int RawType\r\n\r\ndata RawType = Product Type Type\r\n | Num\r\n\r\npattern a :*: b <- Type _ (Product a b)\r\ninfixr 7 :*:\r\n}}}\r\n\r\nBar.hs:\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\nmodule Main where\r\n\r\nimport Foo\r\n\r\nvalue = Type 0 $ Product (Type 1 Num) $ Type 2 $ Product (Type 3 Num) $ Type 4 Num\r\n\r\nsomethingElse = 23\r\n\r\nmain = case value of\r\n _ :*: _ :*: _ -> putStrLn \"Success\"\r\n _ -> putStrLn \"Fail\"\r\n}}}\r\n\r\nOn the first compile, the executable will print \"Success\". Modifying Bar and recompiling will result in it printing \"Fail\". Modifying both and recompiling results in \"Success\" again.","type_of_failure":"OtherFailure","blocking":[]} -->Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/9860Package flags not command line completable in 7.82019-07-07T18:38:44Zkolmodin@dtek.chalmers.sePackage flags not command line completable in 7.8Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<details><summary>Trac me...Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Package flags not command line completable in 7.8","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Passing `--show-options` to ghc shows all the flags that ghc understands.\r\n\r\nUnfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.\r\n\r\nRequires a 1 line fix in `ghc/Main.hs`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4kolmodin@dtek.chalmers.sekolmodin@dtek.chalmers.sehttps://gitlab.haskell.org/ghc/ghc/-/issues/9853Stateful transformation causes non-termination in Hoopl analysis.2019-07-07T18:38:45ZAndreasVoellmyStateful transformation causes non-termination in Hoopl analysis.It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that ...It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow.
The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever.
Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/hoopl |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stateful transformation causes non-termination in Hoopl analysis.","status":"New","operating_system":"","component":"libraries/hoopl","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow.\r\n\r\nThe attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called \"Funny\" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. \r\n\r\nIs this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9844Bang pattern doesn't work on a newtype constructor2019-07-07T18:38:48Ztakano-akioBang pattern doesn't work on a newtype constructorAccording to the documentation, `f0` and `f1` in the following program should have the identical semantics:
```hs
{-# LANGUAGE BangPatterns #-}
module Main where
newtype N = N Int
f0 :: N -> Int
f0 n = case n of
!(N _) -> 0
_ -> 1...According to the documentation, `f0` and `f1` in the following program should have the identical semantics:
```hs
{-# LANGUAGE BangPatterns #-}
module Main where
newtype N = N Int
f0 :: N -> Int
f0 n = case n of
!(N _) -> 0
_ -> 1
f1 :: N -> Int
f1 n = n `seq` case n of
N _ -> 0
_ -> 1
main = do
print $ f0 undefined
print $ f1 undefined
```
However, ghc only compiles `f1` into a strict function:
```
% ./bang-newtype
0
bang-newtype: Prelude.undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Bang pattern doesn't work on a newtype constructor","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the documentation, {{{f0}}} and {{{f1}}} in the following program should have the identical semantics:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\nmodule Main where\r\n\r\nnewtype N = N Int\r\n\r\nf0 :: N -> Int\r\nf0 n = case n of\r\n !(N _) -> 0\r\n _ -> 1\r\n\r\nf1 :: N -> Int\r\nf1 n = n `seq` case n of\r\n N _ -> 0\r\n _ -> 1\r\n\r\nmain = do\r\n print $ f0 undefined\r\n print $ f1 undefined\r\n}}}\r\n\r\nHowever, ghc only compiles {{{f1}}} into a strict function:\r\n\r\n{{{\r\n% ./bang-newtype \r\n0\r\nbang-newtype: Prelude.undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9830Standalone-derived Show instance for type constructor has different precedenc...2022-01-25T22:28:14ZRyan ScottStandalone-derived Show instance for type constructor has different precedence if orphan instanceIf you are using `StandaloneDeriving` to derive a `Show` instance for a data type with an infix constructor, its precedence will be different depending on which module the `deriving instance ...` declaration is in. For example, with this...If you are using `StandaloneDeriving` to derive a `Show` instance for a data type with an infix constructor, its precedence will be different depending on which module the `deriving instance ...` declaration is in. For example, with this code:
```hs
-- InfixShow.hs
{-# LANGUAGE StandaloneDeriving #-}
module InfixShow where
infixr 6 :?:
data ADT a b = a :?: b deriving (Eq, Ord, Read)
deriving instance (Show a, Show b) => Show (ADT a b)
```
```hs
-- Main.hs
module Main where
import InfixShow
main :: IO ()
main = do
putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") ""
putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") ""
putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") ""
putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") ""
```
Calling `runhaskell Main.hs` will produce this output, as expected:
```
Prec 6: "test" :?: "show"
Prec 7: ("test" :?: "show")
Prec 9: ("test" :?: "show")
Prec 10: ("test" :?: "show")
```
However, if the code is changed so that the `deriving instance ...` declaration is in `Main.hs` instead:
```hs
-- InfixShow.hs
module InfixShow where
infixr 6 :?:
data ADT a b = a :?: b deriving (Eq, Ord, Read)
```
```hs
-- Main.hs
{-# LANGUAGE StandaloneDeriving #-}
module Main where
import InfixShow
deriving instance (Show a, Show b) => Show (ADT a b)
main :: IO ()
main = do
putStrLn $ "Prec 6: " ++ showsPrec 6 ("test" :?: "show") ""
putStrLn $ "Prec 7: " ++ showsPrec 7 ("test" :?: "show") ""
putStrLn $ "Prec 9: " ++ showsPrec 9 ("test" :?: "show") ""
putStrLn $ "Prec 10: " ++ showsPrec 10 ("test" :?: "show") ""
```
Then the output of `runhaskell Main.hs` is different:
```
Prec 6: "test" :?: "show"
Prec 7: "test" :?: "show"
Prec 9: "test" :?: "show"
Prec 10: ("test" :?: "show")
```
This seems to indicate that `:?:` has the default maximum operator precedence (9) instead of the precedence defined in `InfixShow` (6).