GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:17:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14290Strictness bug with existential contexts on data constructors2019-07-07T18:17:36ZSimon MarlowStrictness bug with existential contexts on data constructorsThe following:
```
{-# LANGUAGE ExistentialQuantification #-}
module Main (main) where
main :: IO ()
main = r `seq` return ()
r :: Rec
r = Rec{ a = error "xxx", b = 3, c = True }
class C t
instance C Bool
data Rec = forall t. C t =...The following:
```
{-# LANGUAGE ExistentialQuantification #-}
module Main (main) where
main :: IO ()
main = r `seq` return ()
r :: Rec
r = Rec{ a = error "xxx", b = 3, c = True }
class C t
instance C Bool
data Rec = forall t. C t => Rec
{ a :: ()
, b :: !Int
, c :: t
}
```
Should succeed, but fails with `error "xxx"` (but only when compiled with `-O`). The problem is that the strictness signature for the data con wrapper doesn't take into account the dictionary fields.
I have a patch which I'll upload to Phabricator shortly...8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/14251LLVM Code Gen messes up registers2020-06-04T18:29:12ZMoritz AngermannLLVM Code Gen messes up registersDue to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers.
A slightly adapted T8064
```hs
{-# LANGUAGE MagicHash, BangPatterns #-}
module Main where
import GHC.Exts
{-# NOINLINE f #-...Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers.
A slightly adapted T8064
```hs
{-# LANGUAGE MagicHash, BangPatterns #-}
module Main where
import GHC.Exts
{-# NOINLINE f #-}
f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String
f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!"
{-# NOINLINE p #-}
p :: Int# -> Float# -> Double# -> Float# -> Double# -> String
p i j k l m = "Hello"
{-# NOINLINE q #-}
q :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String
q _ i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m)
{-# NOINLINE r #-}
r :: Int# -> Float# -> Double# -> Float# -> Double# -> String
r i = let !(I# z) = length [I# 1# .. I# i] in \j k l m -> p z j k l m
-- ghc won't eta-expand around the length, because it has unknown cost
main = do
putStrLn (f p) -- fast call
putStrLn (f r) -- slow call: function but wrong arity
let g = last [q 1#]
putStrLn (f g) -- slow call: thunk
```
will produce the following results:
```
../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm
[1 of 1] Compiling Main ( T6084.hs, T6084.o )
Linking T6084-llvm ...
Hello World!
Hello World!
Hello 4.0 5.0 World!
../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm
[1 of 1] Compiling Main ( T6084.hs, T6084.o )
Linking T6084-asm ...
Hello World!
Hello World!
Hello 6.0 6.9 World!
```
The underlying reason is that (at least for X86_64) the Float and Double registers alternate.
The llvm code gen creates function signatures based on the live registers (instead of all).
For `q` only the last Float and Double register are `live`. However when calling `q` we pass
`f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in
the function body, we now have `f2 <- f1` and `d2 <- d1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, carter, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM Code Gen messes up registers","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","carter","simonmar"],"type":"Bug","description":"Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers.\r\n\r\nA slightly adapted T8064\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash, BangPatterns #-}\r\nmodule Main where\r\n\r\nimport GHC.Exts\r\n\r\n{-# NOINLINE f #-}\r\nf :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String\r\nf g = g 3# 4.0# 5.0## 6.0# 6.9## ++ \" World!\"\r\n\r\n{-# NOINLINE p #-}\r\np :: Int# -> Float# -> Double# -> Float# -> Double# -> String\r\np i j k l m = \"Hello\"\r\n\r\n{-# NOINLINE q #-}\r\nq :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String\r\nq _ i j k l m = \"Hello \" ++ show (F# l) ++ \" \" ++ show (D# m)\r\n\r\n{-# NOINLINE r #-}\r\nr :: Int# -> Float# -> Double# -> Float# -> Double# -> String\r\nr i = let !(I# z) = length [I# 1# .. I# i] in \\j k l m -> p z j k l m\r\n -- ghc won't eta-expand around the length, because it has unknown cost\r\n\r\nmain = do\r\n putStrLn (f p) -- fast call\r\n putStrLn (f r) -- slow call: function but wrong arity\r\n let g = last [q 1#]\r\n putStrLn (f g) -- slow call: thunk\r\n}}}\r\n\r\nwill produce the following results:\r\n\r\n{{{\r\n../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm\r\n[1 of 1] Compiling Main ( T6084.hs, T6084.o )\r\nLinking T6084-llvm ...\r\nHello World!\r\nHello World!\r\nHello 4.0 5.0 World!\r\n\r\n../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm\r\n[1 of 1] Compiling Main ( T6084.hs, T6084.o )\r\nLinking T6084-asm ...\r\nHello World!\r\nHello World!\r\nHello 6.0 6.9 World!\r\n}}}\r\n\r\nThe underlying reason is that (at least for X86_64) the Float and Double registers alternate.\r\nThe llvm code gen creates function signatures based on the live registers (instead of all).\r\n\r\nFor `q` only the last Float and Double register are `live`. However when calling `q` we pass\r\n`f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in\r\nthe function body, we now have `f2 <- f1` and `d2 <- d1`.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Kavon FarvardinKavon Farvardinhttps://gitlab.haskell.org/ghc/ghc/-/issues/14244ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers2019-07-07T18:17:48ZPeter Trommlerptrommler@acm.orgghc-prim: hs_atomicread* and hs_atomicwrite* missing barriersThe comments in `compiler/prelude/primops.txt.pp` for both operations say "... Implies a full memory barrier."
The implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `lib...The comments in `compiler/prelude/primops.txt.pp` for both operations say "... Implies a full memory barrier."
The implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `libraries/ghc-prim/cbits/atomic.c`.
```c
StgWord
hs_atomicread32(StgWord x)
{
return *(volatile StgWord32 *) x;
}
```
and
```c
void
hs_atomicwrite32(StgWord x, StgWord val)
{
*(volatile StgWord32 *) x = (StgWord32) val;
}
```
The native code generator for X86/amd64 and the LLVM backend do not generate calls to these functions but generate the necessary barrier (`mfence`) directly and thus are not affected by this issue.
There are no gcc `__sync_*` intrinsics for the two operations. The new `__atomic_*` intrinisics have the required operations but require gcc 4.7 or later.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The comments in `compiler/prelude/primops.txt.pp` for both operations say \"... Implies a full memory barrier.\"\r\n\r\nThe implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `libraries/ghc-prim/cbits/atomic.c`.\r\n{{{#!c\r\nStgWord\r\nhs_atomicread32(StgWord x)\r\n{\r\n return *(volatile StgWord32 *) x;\r\n}\r\n}}}\r\nand\r\n{{{#!c\r\nvoid\r\nhs_atomicwrite32(StgWord x, StgWord val)\r\n{\r\n *(volatile StgWord32 *) x = (StgWord32) val;\r\n}\r\n}}}\r\n\r\nThe native code generator for X86/amd64 and the LLVM backend do not generate calls to these functions but generate the necessary barrier (`mfence`) directly and thus are not affected by this issue.\r\n\r\nThere are no gcc `__sync_*` intrinsics for the two operations. The new `__atomic_*` intrinisics have the required operations but require gcc 4.7 or later. ","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/14238`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.12019-07-07T18:17:49ZRyan Scott`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1Load this program into GHCi on 8.2.1 or later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Foo (k :: Type) :: k -> Type where
MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)
```
And ask it w...Load this program into GHCi on 8.2.1 or later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Foo (k :: Type) :: k -> Type where
MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)
```
And ask it what the kind of `Foo` is:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main ( Bug.hs, interpreted )
Ok, 1 module loaded.
λ> :k Foo
Foo :: k -> *
```
This is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one.
A workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`:
```
λ> :set -fprint-explicit-foralls
λ> :k Foo
Foo :: forall k -> k -> *
```
This is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then:
```
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main ( Bug.hs, interpreted )
Ok, modules loaded: Main.
λ> :k Foo
Foo :: forall k -> k -> Type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Load this program into GHCi on 8.2.1 or later:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeInType #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Foo (k :: Type) :: k -> Type where\r\n MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)\r\n}}}\r\n\r\nAnd ask it what the kind of `Foo` is:\r\n\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Main ( Bug.hs, interpreted )\r\nOk, 1 module loaded.\r\nλ> :k Foo\r\nFoo :: k -> *\r\n}}}\r\n\r\nThis is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one.\r\n\r\nA workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`:\r\n\r\n{{{\r\nλ> :set -fprint-explicit-foralls \r\nλ> :k Foo\r\nFoo :: forall k -> k -> *\r\n}}}\r\n\r\nThis is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then:\r\n\r\n{{{\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Main ( Bug.hs, interpreted )\r\nOk, modules loaded: Main.\r\nλ> :k Foo\r\nFoo :: forall k -> k -> Type\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14228PatternSynonyms Non-exhaustive with UnboxedSums2019-07-07T18:17:51ZGuillaume BouchardPatternSynonyms Non-exhaustive with UnboxedSumsThe following implementation of `Maybe` using UnboxedSums results in `Non-exhaustive patterns in case`:
(`Failure.hs` file)
```haskell
{-# LANGUAGE UnboxedSums #-}
{-# LANGUAGE PatternSynonyms #-}
type Maybe' t = (# t | () #)
pattern...The following implementation of `Maybe` using UnboxedSums results in `Non-exhaustive patterns in case`:
(`Failure.hs` file)
```haskell
{-# LANGUAGE UnboxedSums #-}
{-# LANGUAGE PatternSynonyms #-}
type Maybe' t = (# t | () #)
pattern Just' :: a -> Maybe' a
pattern Just' x = (# x | #)
pattern Nothing' :: Maybe' a
pattern Nothing' = (# | () #)
foo x = case x of
Nothing' -> putStrLn "nothing"
Just' _ -> putStrLn "just"
main = do
putStrLn "Nothing'"
foo Nothing'
putStrLn "Just'"
foo (Just' "hello")
```
When executed, it prints:
```
Nothing'
nothing
Just'
Failure: Failure.hs:10:20-29: Non-exhaustive patterns in case
```
Compiled with `ghc Failure.hs`.
Please note that by removing the `pattern`s, and writting `foo` as following works as expected:
```haskell
foo x = case x of
(# | () #) -> putStrLn "nothing"
(# _ | #) -> putStrLn "just"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"PatternSynonyms Non-exhaustive with UnboxedSums","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["PatternSynonyms","UnboxedSum,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following implementation of `Maybe` using UnboxedSums results in `Non-exhaustive patterns in case`:\r\n\r\n(`Failure.hs` file)\r\n\r\n{{{#!haskell\r\n{-# LANGUAGE UnboxedSums #-}\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\ntype Maybe' t = (# t | () #)\r\n\r\npattern Just' :: a -> Maybe' a\r\npattern Just' x = (# x | #)\r\n\r\npattern Nothing' :: Maybe' a\r\npattern Nothing' = (# | () #)\r\n\r\nfoo x = case x of\r\n Nothing' -> putStrLn \"nothing\"\r\n Just' _ -> putStrLn \"just\"\r\n\r\nmain = do\r\n putStrLn \"Nothing'\"\r\n foo Nothing'\r\n\r\n putStrLn \"Just'\"\r\n foo (Just' \"hello\")\r\n}}}\r\n\r\nWhen executed, it prints:\r\n\r\n{{{\r\nNothing'\r\nnothing\r\nJust'\r\nFailure: Failure.hs:10:20-29: Non-exhaustive patterns in case\r\n}}}\r\n\r\nCompiled with `ghc Failure.hs`.\r\n\r\nPlease note that by removing the `pattern`s, and writting `foo` as following works as expected:\r\n\r\n{{{#!haskell\r\nfoo x = case x of\r\n (# | () #) -> putStrLn \"nothing\"\r\n (# _ | #) -> putStrLn \"just\"\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/14150Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)2022-07-27T10:30:03ZRyan ScottCtrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+...On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell.
In GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to "exit" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!).
(Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ctrl+C causes GHCi 8.2.1 to \"exit\" in Windows (which didn't happen in 8.0.2)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx"],"type":"Bug","description":"On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell.\r\n\r\nIn GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to \"exit\" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!). \r\n\r\n(Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.)","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/14085powModInteger sometimes ignores sign of argument2019-07-07T18:18:31ZocheronpowModInteger sometimes ignores sign of argumentFunction `intToSBigNat#` returns a `PosBN` result when input is \< -1, but it should be `NegBN` instead.
As a consequence functions like `powModInteger` give incorrect result for small negative numbers:
```
$ ghci
GHCi, version 8.2.1: ...Function `intToSBigNat#` returns a `PosBN` result when input is \< -1, but it should be `NegBN` instead.
As a consequence functions like `powModInteger` give incorrect result for small negative numbers:
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
> :m GHC.Integer.GMP.Internals
> powModInteger (-2) 3 123
8
> (-2)^3 `mod` 123
115
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"powModInteger sometimes ignores sign of argument","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["integer-gmp"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Function `intToSBigNat#` returns a `PosBN` result when input is < -1, but it should be `NegBN` instead.\r\n\r\nAs a consequence functions like `powModInteger` give incorrect result for small negative numbers:\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n> :m GHC.Integer.GMP.Internals\r\n> powModInteger (-2) 3 123\r\n8\r\n> (-2)^3 `mod` 123\r\n115\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1ocheronocheronhttps://gitlab.haskell.org/ghc/ghc/-/issues/14084Strange behavior of GHC by writing the types in GHCi2019-07-07T18:18:32ZvantoStrange behavior of GHC by writing the types in GHCi- A: you type `:set +t` then you write `1:2`, the answer is:\\\\
```
Prelude> :set +t
```
```
Prelude> 1:2
<interactive>:8:1: error:
* Non type-variable argument in the constraint: Num [a]
(Use FlexibleContexts to permit thi...- A: you type `:set +t` then you write `1:2`, the answer is:\\\\
```
Prelude> :set +t
```
```
Prelude> 1:2
<interactive>:8:1: error:
* Non type-variable argument in the constraint: Num [a]
(Use FlexibleContexts to permit this)
* When checking the inferred type
it :: forall a. (Num [a], Num a) => [a]
```
\\\\
- B: you type `:t 1:2`, the answer is:\\\\
```
Prelude> :t 1:2
1:2 :: (Num [a], Num a) => [a]
```
\\\\
There is an obvious bug. Don't answer me that this behavior is correct, please!
The two answers should be the same.
Either answer A or answer B.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Strange behavior of GHC by writing the types in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"* A: you type {{{:set +t}}} then you write {{{1:2}}}, the answer is:\\\\\r\n\r\n{{{\r\nPrelude> :set +t\r\n}}}\r\n\r\n{{{\r\nPrelude> 1:2\r\n\r\n<interactive>:8:1: error:\r\n * Non type-variable argument in the constraint: Num [a]\r\n (Use FlexibleContexts to permit this)\r\n * When checking the inferred type\r\n it :: forall a. (Num [a], Num a) => [a]\r\n}}}\r\n\\\\\r\n* B: you type {{{:t 1:2}}}, the answer is:\\\\\r\n\r\n{{{\r\nPrelude> :t 1:2\r\n1:2 :: (Num [a], Num a) => [a]\r\n}}}\r\n\\\\\r\nThere is an obvious bug. Don't answer me that this behavior is correct, please!\r\nThe two answers should be the same.\r\nEither answer A or answer B.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14054Cabal generates ill-typed Paths module when relocatable2019-07-07T18:18:41ZEdward Z. YangCabal generates ill-typed Paths module when relocatableA PR has been submitted https://github.com/haskell/cabal/pull/4638 and we know this bug affects the Cabal fixed with GHC. When we do 8.2.2 we should make sure we get a fixed version of Cabal.
<details><summary>Trac metadata</summary>
|...A PR has been submitted https://github.com/haskell/cabal/pull/4638 and we know this bug affects the Cabal fixed with GHC. When we do 8.2.2 we should make sure we get a fixed version of Cabal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cabal generates ill-typed Paths module when relocatable","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"8.2.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["Cabal"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A PR has been submitted https://github.com/haskell/cabal/pull/4638 and we know this bug affects the Cabal fixed with GHC. When we do 8.2.2 we should make sure we get a fixed version of Cabal.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/14027__GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.12019-07-07T18:18:48Zchoenerzs__GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1__GLASGOW_HASKELL__ is 802 with ghc-8.2.1.
```
#if __GLASGOW_HASKELL__ >= 803
thisShouldFail
#endif
```
Does not fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---...__GLASGOW_HASKELL__ is 802 with ghc-8.2.1.
```
#if __GLASGOW_HASKELL__ >= 803
thisShouldFail
#endif
```
Does not fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"__GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"__GLASGOW_HASKELL__ is 802 with ghc-8.2.1.\r\n\r\n{{{\r\n#if __GLASGOW_HASKELL__ >= 803\r\nthisShouldFail\r\n#endif\r\n}}}\r\n\r\n\r\nDoes not fail.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13988GADT constructor with kind equality constraint quantifies unused existential ...2019-07-07T18:18:58ZRyan ScottGADT constructor with kind equality constraint quantifies unused existential type variablesReproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`):
```
$ /opt/ghc/8.2.1/bin/ghci
GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configurati...Reproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`):
```
$ /opt/ghc/8.2.1/bin/ghci
GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XTypeInType -XGADTs -fprint-explicit-foralls
λ> import Data.Kind
λ> data Foo (a :: k) where MkFoo :: (k ~ Type) => Foo (a :: k)
λ> :type +v MkFoo
MkFoo :: forall k1 (a :: k1) k2 (k3 :: k2). k1 ~ * => Foo a
```
Note that `MkFoo` quantifies two extra existential type variables, `k2` and `k3` which are completely unused!
Note that this does not occur if the `MkFoo` constructor uses an explicit `forall`:
```
λ> :set -XScopedTypeVariables
λ> data Foo (a :: k) where MkFoo :: forall k (a :: k). (k ~ Type) => Foo (a :: k)
λ> :type +v MkFoo
MkFoo :: forall k (a :: k). k ~ * => Foo a
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GADT constructor with kind equality constraint quantifies unused existential type variables","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`):\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghci\r\nGHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> :set -XTypeInType -XGADTs -fprint-explicit-foralls \r\nλ> import Data.Kind\r\nλ> data Foo (a :: k) where MkFoo :: (k ~ Type) => Foo (a :: k)\r\nλ> :type +v MkFoo\r\nMkFoo :: forall k1 (a :: k1) k2 (k3 :: k2). k1 ~ * => Foo a\r\n}}}\r\n\r\nNote that `MkFoo` quantifies two extra existential type variables, `k2` and `k3` which are completely unused!\r\n\r\nNote that this does not occur if the `MkFoo` constructor uses an explicit `forall`:\r\n\r\n{{{\r\nλ> :set -XScopedTypeVariables \r\nλ> data Foo (a :: k) where MkFoo :: forall k (a :: k). (k ~ Type) => Foo (a :: k)\r\nλ> :type +v MkFoo\r\nMkFoo :: forall k (a :: k). k ~ * => Foo a\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13942Pretty-printer butchers function arrow fixity on GHC HEAD2019-07-07T18:19:18ZRyan ScottPretty-printer butchers function arrow fixity on GHC HEADThis code:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| f :: Either Int (Int -> Int)
f = undefined
|])
```
Pretty-prints incorrectly on GHC HEAD:
```
$ /opt/ghc/head/bin/g...This code:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| f :: Either Int (Int -> Int)
f = undefined
|])
```
Pretty-prints incorrectly on GHC HEAD:
```
$ /opt/ghc/head/bin/ghci Bug.hs
GHCi, version 8.3.20170706: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(5,3)-(7,6): Splicing declarations
[d| f_a1sG :: Either Int (Int -> Int)
f_a1sG = undefined |]
======>
f_a4bj :: Either Int Int -> Int
f_a4bj = undefined
```
But not on GHC 8.2.1-rc3:
```
$ /opt/ghc/8.2.1/bin/ghci Bug.hs
GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(5,3)-(7,6): Splicing declarations
[d| f_a1su :: Either Int (Int -> Int)
f_a1su = undefined |]
======>
f_a4aV :: Either Int (Int -> Int)
f_a4aV = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 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":"Pretty-printer butchers function arrow fixity on GHC HEAD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\n$([d| f :: Either Int (Int -> Int)\r\n f = undefined\r\n |])\r\n}}}\r\n\r\nPretty-prints incorrectly on GHC HEAD:\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghci Bug.hs\r\nGHCi, version 8.3.20170706: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(5,3)-(7,6): Splicing declarations\r\n [d| f_a1sG :: Either Int (Int -> Int)\r\n f_a1sG = undefined |]\r\n ======>\r\n f_a4bj :: Either Int Int -> Int\r\n f_a4bj = undefined\r\n}}}\r\n\r\nBut not on GHC 8.2.1-rc3:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghci Bug.hs\r\nGHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(5,3)-(7,6): Splicing declarations\r\n [d| f_a1su :: Either Int (Int -> Int)\r\n f_a1su = undefined |]\r\n ======>\r\n f_a4aV :: Either Int (Int -> Int)\r\n f_a4aV = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/13911GHC RTS VEH swallowing exceptions2019-07-07T18:19:31Ztim-m89GHC RTS VEH swallowing exceptionsOn ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches.
#13108 improved things a little by giving some basic info upon segfaults, but otherwise left everythi...On ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches.
#13108 improved things a little by giving some basic info upon segfaults, but otherwise left everything as is.
Rather than trying to catch all exceptions, I think it would be more worthwhile to leave them uncaught, and let current & future tools have an eyes open approach to debugging.
If something needs to go in the place of the global handler, perhaps SetUnhandledExceptionFilter is of use?
VEH overrides all other exception handlers as far as I'm aware (C++, SEH, .NET), so trying to interop with any other code that wants to handle it's own exceptions won't work unless said code is also using VEH.
This is causing an issue for some code I've been working on, and I've documented similar to this bug report there also: https://gitlab.com/tim-m89/clr-haskell/issues/25\#note_33960203
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | RuntimeCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC RTS VEH swallowing exceptions","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"On ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches.\r\n\r\n#13108 improved things a little by giving some basic info upon segfaults, but otherwise left everything as is. \r\n\r\nRather than trying to catch all exceptions, I think it would be more worthwhile to leave them uncaught, and let current & future tools have an eyes open approach to debugging.\r\n\r\nIf something needs to go in the place of the global handler, perhaps SetUnhandledExceptionFilter is of use?\r\n\r\nVEH overrides all other exception handlers as far as I'm aware (C++, SEH, .NET), so trying to interop with any other code that wants to handle it's own exceptions won't work unless said code is also using VEH.\r\n\r\nThis is causing an issue for some code I've been working on, and I've documented similar to this bug report there also: https://gitlab.com/tim-m89/clr-haskell/issues/25#note_33960203\r\n","type_of_failure":"RuntimeCrash","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13903KQueue evtmgr backend fails to register for write events2022-02-11T15:58:15ZwaldheinzKQueue evtmgr backend fails to register for write eventsThe root of the problem is that the `GHC.Event.KQueue.toFilter` function has type `GHC.Event.Internal.Event -> Filter` with GHC's `Event` being a bitmask which can represent read events, write events or a combination of those.
It happen...The root of the problem is that the `GHC.Event.KQueue.toFilter` function has type `GHC.Event.Internal.Event -> Filter` with GHC's `Event` being a bitmask which can represent read events, write events or a combination of those.
It happens that the event manager requests it's backend to be notified about read *and* write events on some fd, and because the kqueue `EVFILT_*`s are *not* bitmasks, the above function cannot capture this, silently dropping the desire to be notified about write events.
The following program triggers the problematic behaviour:
```
import Control.Concurrent ( forkIO, killThread )
import Control.Exception ( finally )
import Control.Monad.Trans.Resource ( runResourceT )
import Control.Monad.IO.Class ( liftIO )
import qualified Data.ByteString as BS
import Data.Conduit ( ($$), ($=) )
import qualified Data.Conduit.Binary as CB
import qualified Data.Conduit.List as CL
import qualified Data.Conduit.Network as CN
import Data.IORef ( newIORef, modifyIORef', readIORef)
main :: IO ()
main = CN.runTCPClient (CN.clientSettings 5555 "192.168.2.11") client
where
logMsg cnt = CL.mapM $ \bs -> liftIO $ do
modifyIORef' cnt (+ 1)
readIORef cnt >>= \x -> putStrLn $
"msg #" ++ show x ++ " of size: " ++ show (BS.length bs)
return bs
client ad = do
reader <- forkIO (runResourceT $ CN.appSource ad
$$ CL.mapM_ ( \bs -> (liftIO . putStrLn) $
"read " ++ show (BS.length bs) ++ " bytes"))
cnt <- newIORef ( 0 :: Int )
let
runPipe = runResourceT $ CB.sourceFile "cool-linux-distro.iso"
$$ logMsg cnt
$= CN.appSink ad
runPipe `finally` (killThread reader)
```
Having a `nc -l -p 5555 > /dev/null` running on another machine is sufficient to sink the data.
Assuming that we can read `bigfile.iso` faster than we can send out over the socket, the `send` syscall will at some point give an `EAGAIN` as can be seen in the `truss` output:
```
write(1,"msg #20 of size: 32752\n",23) = 23 (0x17)
sendto(12,"\f\2409\0\M^RA\^T\M-&A\M-'\M-d8"...,32752,0x0,NULL,0x0) = 32752 (0x7ff0)
read(13,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752) = 32752 (0x7ff0)
poll({ 1/POLLOUT },1,0) = 1 (0x1)
msg #21 of size: 32752
write(1,"msg #21 of size: 32752\n",23) = 23 (0x17)
sendto(12,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752,0x0,NULL,0x0) = 19204 (0x4b04)
sendto(12,"\M-j$2\M^BH\M-#-\^A\M-E\^O\M^Y\a"...,13548,0x0,NULL,0x0) ERR#35 'Resource temporarily unavailable'
SIGNAL 26 (SIGVTALRM)
sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0)
sigreturn(0x7fffffff9c60) ERR#35 'Resource temporarily unavailable'
kevent(3,{ 12,EVFILT_READ,EV_ADD|EV_ONESHOT,0x0,0x0,0x0 },1,0x0,0,{ 0.000000000 }) = 0 (0x0)
_umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 26 (SIGVTALRM)
sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0)
sigreturn(0x7fffffffdc00) ERR#4 'Interrupted system call'
_umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 26 (SIGVTALRM)
```
Not the `sendto` call on fd 12 resulting in `ERR#35`, soon followed by an `kevent` call for that same fd and only `EVFILT_READ` set. This makes little sense as it was an attempt to *write* that just failed. This is caused by `toFilter` giving precedence to `read` events, dropping the write event. Not starting the `reader` thread prevents bad things from happening as then the `write` events are properly passed thru to kqueue.
I have an initial version of a patch fixing this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"KQueue evtmgr backend fails to register for write events","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The root of the problem is that the `GHC.Event.KQueue.toFilter` function has type `GHC.Event.Internal.Event -> Filter` with GHC's `Event` being a bitmask which can represent read events, write events or a combination of those.\r\n\r\nIt happens that the event manager requests it's backend to be notified about read ''and'' write events on some fd, and because the kqueue `EVFILT_*`s are ''not'' bitmasks, the above function cannot capture this, silently dropping the desire to be notified about write events.\r\n\r\nThe following program triggers the problematic behaviour:\r\n\r\n{{{\r\n\r\nimport Control.Concurrent ( forkIO, killThread )\r\nimport Control.Exception ( finally )\r\nimport Control.Monad.Trans.Resource ( runResourceT )\r\nimport Control.Monad.IO.Class ( liftIO )\r\nimport qualified Data.ByteString as BS\r\nimport Data.Conduit ( ($$), ($=) )\r\nimport qualified Data.Conduit.Binary as CB\r\nimport qualified Data.Conduit.List as CL\r\nimport qualified Data.Conduit.Network as CN\r\nimport Data.IORef ( newIORef, modifyIORef', readIORef)\r\n\r\nmain :: IO ()\r\nmain = CN.runTCPClient (CN.clientSettings 5555 \"192.168.2.11\") client\r\n where\r\n logMsg cnt = CL.mapM $ \\bs -> liftIO $ do\r\n modifyIORef' cnt (+ 1)\r\n readIORef cnt >>= \\x -> putStrLn $\r\n \"msg #\" ++ show x ++ \" of size: \" ++ show (BS.length bs)\r\n return bs\r\n\r\n client ad = do\r\n reader <- forkIO (runResourceT $ CN.appSource ad\r\n $$ CL.mapM_ ( \\bs -> (liftIO . putStrLn) $\r\n \"read \" ++ show (BS.length bs) ++ \" bytes\"))\r\n cnt <- newIORef ( 0 :: Int )\r\n\r\n let\r\n runPipe = runResourceT $ CB.sourceFile \"cool-linux-distro.iso\"\r\n $$ logMsg cnt\r\n $= CN.appSink ad\r\n\r\n runPipe `finally` (killThread reader)\r\n}}}\r\n\r\nHaving a `nc -l -p 5555 > /dev/null` running on another machine is sufficient to sink the data.\r\n\r\nAssuming that we can read `bigfile.iso` faster than we can send out over the socket, the `send` syscall will at some point give an `EAGAIN` as can be seen in the `truss` output:\r\n\r\n{{{\r\nwrite(1,\"msg #20 of size: 32752\\n\",23) = 23 (0x17)\r\nsendto(12,\"\\f\\2409\\0\\M^RA\\^T\\M-&A\\M-'\\M-d8\"...,32752,0x0,NULL,0x0) = 32752 (0x7ff0)\r\nread(13,\"\\M^?\\0'\\\\\\M-B\\M-:+\\^]D\\M-0\\M-=\"...,32752) = 32752 (0x7ff0)\r\npoll({ 1/POLLOUT },1,0) = 1 (0x1)\r\nmsg #21 of size: 32752\r\nwrite(1,\"msg #21 of size: 32752\\n\",23) = 23 (0x17)\r\nsendto(12,\"\\M^?\\0'\\\\\\M-B\\M-:+\\^]D\\M-0\\M-=\"...,32752,0x0,NULL,0x0) = 19204 (0x4b04)\r\nsendto(12,\"\\M-j$2\\M^BH\\M-#-\\^A\\M-E\\^O\\M^Y\\a\"...,13548,0x0,NULL,0x0) ERR#35 'Resource temporarily unavailable'\r\nSIGNAL 26 (SIGVTALRM)\r\nsigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0)\r\nsigreturn(0x7fffffff9c60) ERR#35 'Resource temporarily unavailable'\r\nkevent(3,{ 12,EVFILT_READ,EV_ADD|EV_ONESHOT,0x0,0x0,0x0 },1,0x0,0,{ 0.000000000 }) = 0 (0x0)\r\n_umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call'\r\nSIGNAL 26 (SIGVTALRM)\r\nsigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0)\r\nsigreturn(0x7fffffffdc00) ERR#4 'Interrupted system call'\r\n_umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call'\r\nSIGNAL 26 (SIGVTALRM)\r\n}}}\r\n\r\nNot the `sendto` call on fd 12 resulting in `ERR#35`, soon followed by an `kevent` call for that same fd and only `EVFILT_READ` set. This makes little sense as it was an attempt to ''write'' that just failed. This is caused by `toFilter` giving precedence to `read` events, dropping the write event. Not starting the `reader` thread prevents bad things from happening as then the `write` events are properly passed thru to kqueue.\r\n\r\nI have an initial version of a patch fixing this.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13887Template Haskell pretty-printer doesn't parenthesize infix datatype names in ...2019-07-07T18:19:38ZRyan ScottTemplate Haskell pretty-printer doesn't parenthesize infix datatype names in data declarationsIf you run this program:
```hs
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
module Foo where
import Language.Haskell...If you run this program:
```hs
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
module Foo where
import Language.Haskell.TH
main :: IO ()
main = do
putStrLn $([d| data a :~: b where Refl1 :: a :~: a |] >>= stringE . pprint)
putStrLn $([d| data a :~~: b = a ~ b => Refl2 |] >>= stringE . pprint)
```
```
$ /opt/ghc/8.2.1/bin/runghc Foo.hs
data :~:_0 a_1 b_2 where Refl1_3 :: :~:_0 a_4 a_4
data :~~:_0 a_1 b_2 = a_1 ~ b_2 => Refl2_3
```
It'll print the output incorrectly. Those infix names `:~:` and `:~~:` ought to be surrounded by parentheses, since they're used in prefix position.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you run this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ExistentialQuantification #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Foo where\r\n\r\nimport Language.Haskell.TH\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $([d| data a :~: b where Refl1 :: a :~: a |] >>= stringE . pprint)\r\n putStrLn $([d| data a :~~: b = a ~ b => Refl2 |] >>= stringE . pprint)\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/runghc Foo.hs\r\ndata :~:_0 a_1 b_2 where Refl1_3 :: :~:_0 a_4 a_4\r\ndata :~~:_0 a_1 b_2 = a_1 ~ b_2 => Refl2_3\r\n}}}\r\n\r\nIt'll print the output incorrectly. Those infix names `:~:` and `:~~:` ought to be surrounded by parentheses, since they're used in prefix position.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Evgenii AkentevEvgenii Akentevhttps://gitlab.haskell.org/ghc/ghc/-/issues/13885Template Haskell doesn't freshen GADT type variables properly2023-02-05T14:13:33ZRyan ScottTemplate Haskell doesn't freshen GADT type variables properlyA simple way to illustrate this bug is with this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeOperators #-}
module Foo where
import qualified Data.Type.Equality as DTE ...A simple way to illustrate this bug is with this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeOperators #-}
module Foo where
import qualified Data.Type.Equality as DTE ((:~:))
import Language.Haskell.TH
data a :~: b where
Refl :: a :~: a
$(return [])
main :: IO ()
main = do
putStrLn "Imported\n-----"
putStrLn $(reify ''(DTE.:~:) >>= stringE . pprint)
putStrLn "-----\n\nLocally defined\n-----"
putStrLn $(reify ''(:~:) >>= stringE . pprint)
putStrLn "-----"
```
Here, I'm pretty-printing the reified Template Haskell information about two datatypes: one that is imported from another package (`base`), and another that is defined locally. Aside from their definition sites, they are otherwise identical. However, when reifying them with Template Haskell, there is another distinction one can observe:
```
$ /opt/ghc/8.2.1/bin/runghc Foo.hs
Imported
-----
data Data.Type.Equality.:~: (a_0 :: k_1) (b_2 :: k_1) where
Data.Type.Equality.Refl :: forall (k_1 :: *) (a_0 :: k_1) . Data.Type.Equality.:~: a_0
a_0
-----
Locally defined
-----
data Foo.:~: (a_0 :: k_1) (b_2 :: k_1) where
Foo.Refl :: forall (k_3 :: *) (a_4 :: k_3) . Foo.:~: a_4 a_4
-----
```
The locally defined information looks fine, but the one imported from `base` is suspicious. Namely, the `k_1` variable is used both in the datatype head and in the quantified variables for the constructor! To confirm this, you can print out more verbose info with `show` instead of `pprint`:
```
Imported
-----
TyConI (DataD [] Data.Type.Equality.:~: [KindedTV a_6989586621679026781 (VarT k_6989586621679026780),KindedTV b_6989586621679026782 (VarT k_6989586621679026780)] Nothing [ForallC [KindedTV k_6989586621679026780 StarT,KindedTV a_6989586621679026781 (VarT k_6989586621679026780)] [] (GadtC [Data.Type.Equality.Refl] [] (AppT (AppT (ConT Data.Type.Equality.:~:) (VarT a_6989586621679026781)) (VarT a_6989586621679026781)))] [])
-----
Locally defined
-----
TyConI (DataD [] Foo.:~: [KindedTV a_6989586621679016094 (VarT k_6989586621679016098),KindedTV b_6989586621679016095 (VarT k_6989586621679016098)] Nothing [ForallC [KindedTV k_6989586621679016108 StarT,KindedTV a_6989586621679016096 (VarT k_6989586621679016108)] [] (GadtC [Foo.Refl] [] (AppT (AppT (ConT Foo.:~:) (VarT a_6989586621679016096)) (VarT a_6989586621679016096)))] [])
-----
```
Sure enough, the variable `k_6989586621679026780` is used in both places. I would expect this not to happen, since the two sets of variables are scoped differently, and in practice, I have to work around this by freshening the type variables for the constructor, which is annoying.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell doesn't freshen GADT kind variables properly when imported from another package","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A simple way to illustrate this bug is with this code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Foo where\r\n\r\nimport qualified Data.Type.Equality as DTE ((:~:))\r\nimport Language.Haskell.TH\r\n\r\ndata a :~: b where\r\n Refl :: a :~: a\r\n\r\n$(return [])\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn \"Imported\\n-----\"\r\n putStrLn $(reify ''(DTE.:~:) >>= stringE . pprint)\r\n putStrLn \"-----\\n\\nLocally defined\\n-----\"\r\n putStrLn $(reify ''(:~:) >>= stringE . pprint)\r\n putStrLn \"-----\"\r\n}}}\r\n\r\nHere, I'm pretty-printing the reified Template Haskell information about two datatypes: one that is imported from another package (`base`), and another that is defined locally. Aside from their definition sites, they are otherwise identical. However, when reifying them with Template Haskell, there is another distinction one can observe:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/runghc Foo.hs\r\nImported\r\n-----\r\ndata Data.Type.Equality.:~: (a_0 :: k_1) (b_2 :: k_1) where\r\n Data.Type.Equality.Refl :: forall (k_1 :: *) (a_0 :: k_1) . Data.Type.Equality.:~: a_0\r\n a_0\r\n-----\r\n\r\nLocally defined\r\n-----\r\ndata Foo.:~: (a_0 :: k_1) (b_2 :: k_1) where\r\n Foo.Refl :: forall (k_3 :: *) (a_4 :: k_3) . Foo.:~: a_4 a_4\r\n-----\r\n}}}\r\n\r\nThe locally defined information looks fine, but the one imported from `base` is suspicious. Namely, the `k_1` variable is used both in the datatype head and in the quantified variables for the constructor! To confirm this, you can print out more verbose info with `show` instead of `pprint`:\r\n\r\n{{{\r\nImported\r\n-----\r\nTyConI (DataD [] Data.Type.Equality.:~: [KindedTV a_6989586621679026781 (VarT k_6989586621679026780),KindedTV b_6989586621679026782 (VarT k_6989586621679026780)] Nothing [ForallC [KindedTV k_6989586621679026780 StarT,KindedTV a_6989586621679026781 (VarT k_6989586621679026780)] [] (GadtC [Data.Type.Equality.Refl] [] (AppT (AppT (ConT Data.Type.Equality.:~:) (VarT a_6989586621679026781)) (VarT a_6989586621679026781)))] [])\r\n-----\r\n\r\nLocally defined\r\n-----\r\nTyConI (DataD [] Foo.:~: [KindedTV a_6989586621679016094 (VarT k_6989586621679016098),KindedTV b_6989586621679016095 (VarT k_6989586621679016098)] Nothing [ForallC [KindedTV k_6989586621679016108 StarT,KindedTV a_6989586621679016096 (VarT k_6989586621679016108)] [] (GadtC [Foo.Refl] [] (AppT (AppT (ConT Foo.:~:) (VarT a_6989586621679016096)) (VarT a_6989586621679016096)))] [])\r\n-----\r\n}}}\r\n\r\nSure enough, the variable `k_6989586621679026780` is used in both places. I would expect this not to happen, since the two sets of variables are scoped differently, and in practice, I have to work around this by freshening the type variables for the constructor, which is annoying.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13783更合理的instance Monad []2019-07-07T18:20:05Zzaoqi更合理的instance Monad []使
```hs
join $ map (\y->map (\x->(x,y)) [1..]) [1..]
```
的结果更合理:
https://github.com/zaoqi/zaoqilc/blob/master/featuring/MonadList.hs
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...使
```hs
join $ map (\y->map (\x->(x,y)) [1..]) [1..]
```
的结果更合理:
https://github.com/zaoqi/zaoqilc/blob/master/featuring/MonadList.hs
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"更合理的instance Monad []","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"使\r\n{{{#!hs\r\njoin $ map (\\y->map (\\x->(x,y)) [1..]) [1..]\r\n}}}\r\n的结果更合理:\r\nhttps://github.com/zaoqi/zaoqilc/blob/master/featuring/MonadList.hs","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13635Incorrect result at runtime with list comprehensions in that case2019-07-07T18:20:50ZvantoIncorrect result at runtime with list comprehensions in that case1. With GHC 8.0.2\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:1:12: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
*...1. With GHC 8.0.2\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:1:12: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
* In the expression: _
In the expression: [_, _]
In a stmt of a list comprehension: x <- [_, _]
* Relevant bindings include it :: [t] (bound at <interactive>:1:1)
<interactive>:1:15: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
* In the expression: _
In the expression: [_, _]
In a stmt of a list comprehension: x <- [_, _]
* Relevant bindings include it :: [t] (bound at <interactive>:1:1)
Prelude>\\
```
This result makes no sense here.\\\\
The result will always be the empty list \[\].\\\\
1. With GHC 7.6.3\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:2:12: Pattern syntax in expression context: _
<interactive>:2:12: Pattern syntax in expression context: _
Prelude>
```
This result also makes no sense here.\\\\
Similarly this result will always be the empty list \[\].
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Incorrect result at runtime with list comprehensions in that case","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1. With GHC 8.0.2\\\\\r\n\r\n{{{\r\nPrelude> [x | x <- [_, _], False]\r\n\r\n<interactive>:1:12: error:\r\n * Found hole: _ :: t\r\n Where: `t' is a rigid type variable bound by\r\n the inferred type of it :: [t] at <interactive>:1:1\r\n * In the expression: _\r\n In the expression: [_, _]\r\n In a stmt of a list comprehension: x <- [_, _]\r\n * Relevant bindings include it :: [t] (bound at <interactive>:1:1)\r\n\r\n<interactive>:1:15: error:\r\n * Found hole: _ :: t\r\n Where: `t' is a rigid type variable bound by\r\n the inferred type of it :: [t] at <interactive>:1:1\r\n * In the expression: _\r\n In the expression: [_, _]\r\n In a stmt of a list comprehension: x <- [_, _]\r\n * Relevant bindings include it :: [t] (bound at <interactive>:1:1)\r\nPrelude>\\\\\r\n}}}\r\nThis result makes no sense here.\\\\\r\nThe result will always be the empty list [].\\\\\r\n\r\n\r\n2. With GHC 7.6.3\\\\\r\n\r\n{{{\r\nPrelude> [x | x <- [_, _], False]\r\n\r\n<interactive>:2:12: Pattern syntax in expression context: _\r\n\r\n<interactive>:2:12: Pattern syntax in expression context: _\r\nPrelude>\r\n}}}\r\nThis result also makes no sense here.\\\\\r\nSimilarly this result will always be the empty list [].\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13634num009 fails on POWER82022-01-16T09:37:43ZPeter Trommlerptrommler@acm.orgnum009 fails on POWER8This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running op...This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 fails on POWER8","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr"],"type":"Bug","description":"This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:\r\n{{{\r\n+uh oh! tanf 1.5707964\r\n+-2.2877334e7\r\n+-2.2877332e7\r\n+(-11438667,1)\r\n+(-11438666,1)\r\n Done\r\n}}}\r\n\r\nThe test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13631In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone2019-07-07T18:20:51ZvantoIn GHCi a result is wrong when -fdefer-typed-holes is used with underscore aloneI open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report i...I open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report it is said that :\\\\
1. underscore "_ " all by itself is a reserved identifier.\\\\
1. underscore "_" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\
So `_e` is an identifier like `__`\\\\
GHCi gives a bad result when he computed the code below.\\\\
```
Prelude> :set -fdefer-typed-holes
Prelude> let f = map (\x -> True) [_, _]
<interactive>:2:27: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
<interactive>:2:30: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
Prelude> f
[True,True]
```
The underscore "_" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\
This is the bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I open this ticket instead of {{{#13579}}} to restate it and I closed the other.\\\\\r\nIn fact a result of the compiler which I think is wrong misled me.\\\\\r\nTherefore I close tickets {{{#13602}}} and {{{#13557}}}.\\\\\r\nIn Haskell2010 Language Report it is said that :\\\\\r\n1. underscore \"_ \" all by itself is a reserved identifier.\\\\\r\n2. underscore \"_\" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\\r\nSo {{{_e}}} is an identifier like {{{__}}}\\\\\r\n\r\nGHCi gives a bad result when he computed the code below.\\\\\r\n\r\n\r\n{{{\r\nPrelude> :set -fdefer-typed-holes\r\nPrelude> let f = map (\\x -> True) [_, _]\r\n\r\n<interactive>:2:27: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\n\r\n<interactive>:2:30: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\nPrelude> f\r\n[True,True]\r\n}}}\r\nThe underscore \"_\" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\\r\nThis is the bug.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->