GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:16:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14503Killing a thread will block if there is another process reading from a handle2019-07-07T18:16:46ZdnadalesKilling a thread will block if there is another process reading from a handleWhen trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [this sample code](https://github.com/capitanbatata/sandbox/tree/master...When trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [this sample code](https://github.com/capitanbatata/sandbox/tree/master/dangling-connections). I'll explain the relevant details below.
I have the following Haskell code:
```hs
someFuncWithChans :: IO ()
someFuncWithChans = withSocketsDo $ do
h <- connectTo "localhost" (PortNumber 9090)
hSetBuffering h NoBuffering
ch <- newChan
putStrLn "Starting the handler reader"
readerTid <- forkIO $ handleReader h ch
cmdsHandler h ch
putStrLn "Killing the handler reader"
killThread readerTid
putStrLn "Closing the handle"
hClose h
cmdsHandler :: Handle -> Chan Action -> IO ()
cmdsHandler h ch = do
act <- readChan ch
case act of
Quit -> putStrLn "Bye bye"
Line line -> do
hPutStrLn h (reverse line)
cmdsHandler h ch
handleReader :: Handle -> Chan Action -> IO ()
handleReader h ch = forever $ do
line <- strip <$> hGetLine h
case line of
"quit" -> writeChan ch Quit
_ -> writeChan ch (Line line)
data Action = Quit | Line String
```
Is the function `someFuncWithChans` is run along with the following Java program, then the former will block while killing the handler reader (`readerTid`).
```java
public static void main(String[] args) throws IOException, InterruptedException {
ServerSocket serverSock = new ServerSocket(9090);
Socket sock = serverSock.accept();
InputStream inStream = sock.getInputStream();
BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream));
OutputStream outStream = sock.getOutputStream();
PrintWriter sockOut = new PrintWriter(new OutputStreamWriter(outStream));
while (true) {
Thread.sleep(1000);
System.out.println("Sending foo");
sockOut.println("foo");
sockOut.flush();
String s = sockIn.readLine();
System.out.println("Got " + s );
Thread.sleep(1000);
System.out.println("Sending bar");
sockOut.println("bar");
sockOut.flush();
s = sockIn.readLine();
System.out.println("Got " + s );
Thread.sleep(1000);
System.out.println("Sending quit");
sockOut.println("quit");
sockOut.flush();
// This will cause someFuncWithChans to block when killing the
// reader thread.
s = sockIn.readLine();
System.out.println("Got " + s );
}
}
```
If the `sockIn.readLine()` is commented out, then killing the thread will succeed. This problem appears only on my Windows machine (at work), whereas it does not on my personal Linux machine.
<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":"Killing a thread will block if there is another process reading from a handle","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":"When trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [https://github.com/capitanbatata/sandbox/tree/master/dangling-connections this sample code]. I'll explain the relevant details below.\r\n\r\nI have the following Haskell code:\r\n\r\n{{{#!hs\r\nsomeFuncWithChans :: IO ()\r\nsomeFuncWithChans = withSocketsDo $ do\r\n h <- connectTo \"localhost\" (PortNumber 9090)\r\n hSetBuffering h NoBuffering\r\n ch <- newChan\r\n putStrLn \"Starting the handler reader\"\r\n readerTid <- forkIO $ handleReader h ch\r\n cmdsHandler h ch\r\n putStrLn \"Killing the handler reader\"\r\n killThread readerTid\r\n putStrLn \"Closing the handle\"\r\n hClose h\r\n\r\ncmdsHandler :: Handle -> Chan Action -> IO ()\r\ncmdsHandler h ch = do\r\n act <- readChan ch\r\n case act of\r\n Quit -> putStrLn \"Bye bye\"\r\n Line line -> do\r\n hPutStrLn h (reverse line)\r\n cmdsHandler h ch\r\n\r\nhandleReader :: Handle -> Chan Action -> IO ()\r\nhandleReader h ch = forever $ do\r\n line <- strip <$> hGetLine h\r\n case line of\r\n \"quit\" -> writeChan ch Quit\r\n _ -> writeChan ch (Line line)\r\n\r\ndata Action = Quit | Line String\r\n\r\n}}}\r\n\r\nIs the function `someFuncWithChans` is run along with the following Java program, then the former will block while killing the handler reader (`readerTid`).\r\n\r\n{{{#!java\r\n public static void main(String[] args) throws IOException, InterruptedException {\r\n\r\n ServerSocket serverSock = new ServerSocket(9090);\r\n\r\n Socket sock = serverSock.accept();\r\n\r\n InputStream inStream = sock.getInputStream();\r\n BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream));\r\n\r\n OutputStream outStream = sock.getOutputStream();\r\n PrintWriter sockOut = new PrintWriter(new OutputStreamWriter(outStream));\r\n\r\n\r\n\r\n while (true) {\r\n Thread.sleep(1000);\r\n System.out.println(\"Sending foo\");\r\n sockOut.println(\"foo\");\r\n sockOut.flush();\r\n String s = sockIn.readLine();\r\n System.out.println(\"Got \" + s );\r\n Thread.sleep(1000);\r\n System.out.println(\"Sending bar\");\r\n sockOut.println(\"bar\");\r\n sockOut.flush();\r\n s = sockIn.readLine();\r\n System.out.println(\"Got \" + s );\r\n Thread.sleep(1000);\r\n System.out.println(\"Sending quit\");\r\n sockOut.println(\"quit\");\r\n sockOut.flush();\r\n // This will cause someFuncWithChans to block when killing the\r\n // reader thread.\r\n s = sockIn.readLine();\r\n System.out.println(\"Got \" + s );\r\n }\r\n }\r\n}}}\r\n\r\nIf the `sockIn.readLine()` is commented out, then killing the thread will succeed. This problem appears only on my Windows machine (at work), whereas it does not on my personal Linux machine.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14489GHC panic from emacs haskell mode2019-07-07T18:16:50ZggoetzGHC panic from emacs haskell modeHello,
I encountered a ghc panic while going through one of the chapters from "Haskell Programming from first principles".
The following error message is reported from flycheck checker from src/Main.hs in the attached files:
```
Suspic...Hello,
I encountered a ghc panic while going through one of the chapters from "Haskell Programming from first principles".
The following error message is reported from flycheck checker from src/Main.hs in the attached files:
```
Suspicious state from syntax checker haskell-stack-ghc: Flycheck checker haskell-stack-ghc returned non-zero exit code 1, but its output contained no errors: [1 of 2] Compiling Morse ( [some path]/haskell_programming/ch14/morse/src/Morse.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc-cache90097PyL/Morse.o )
[2 of 2] Compiling Main ( /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck90097c8R/Main.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc-cache90097PyL/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-apple-darwin):
initTc: unsolved constraints
WC {wc_insol =
[W] convertLine_a2Ml :: t_a2Mk[tau:1] (CHoleCan: convertLine)}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Try installing a more recent version of haskell-stack-ghc, and please open a bug report if the issue persists in the latest release. Thanks!
```
Stack upgrade reports "Skipping binary upgrade, you are already running the most recent version". I'm not entirely sure whether this should be reported or not (I can't say I know what I'm doing...), so I'm reporting it just in case.
<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":"GHC panic from emacs haskell mode","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":"Hello,\r\n\r\nI encountered a ghc panic while going through one of the chapters from \"Haskell Programming from first principles\". \r\nThe following error message is reported from flycheck checker from src/Main.hs in the attached files: \r\n\r\n{{{\r\nSuspicious state from syntax checker haskell-stack-ghc: Flycheck checker haskell-stack-ghc returned non-zero exit code 1, but its output contained no errors: [1 of 2] Compiling Morse ( [some path]/haskell_programming/ch14/morse/src/Morse.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc-cache90097PyL/Morse.o )\r\n[2 of 2] Compiling Main ( /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck90097c8R/Main.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc-cache90097PyL/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-apple-darwin):\r\n\tinitTc: unsolved constraints\r\n WC {wc_insol =\r\n [W] convertLine_a2Ml :: t_a2Mk[tau:1] (CHoleCan: convertLine)}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nTry installing a more recent version of haskell-stack-ghc, and please open a bug report if the issue persists in the latest release. Thanks!\r\n}}}\r\n\r\nStack upgrade reports \"Skipping binary upgrade, you are already running the most recent version\". I'm not entirely sure whether this should be reported or not (I can't say I know what I'm doing...), so I'm reporting it just in case. ","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14176sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks...2019-07-07T18:18:08ZkostmosortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted"Given the following code (full Stack project attached):
```haskell
module Foo where
import Data.List
data MyRecord = MyRecord {
f1 :: Maybe String
, f2 :: Maybe String
, f3 :: Maybe String
, f4 :: Maybe String
, f5 :: Mayb...Given the following code (full Stack project attached):
```haskell
module Foo where
import Data.List
data MyRecord = MyRecord {
f1 :: Maybe String
, f2 :: Maybe String
, f3 :: Maybe String
, f4 :: Maybe String
, f5 :: Maybe String
, f6 :: Maybe String
, f7 :: Maybe String
, f8 :: Maybe String
, f9 :: Maybe String
, f10 :: Maybe String
, f11 :: Maybe String
, f12 :: Maybe String
}
getComparisonValue x = (
f1 x
, f2 x
, f3 x
, f4 x
, f5 x
, f6 x
, f7 x
, f8 x
, f9 x
)
doSort = sortOn getComparisonValue
```
The following error results:
```
$ stack build
ghc-bug-0.0.0: build (lib)
Preprocessing library ghc-bug-0.0.0...
[1 of 1] Compiling Foo ( Foo.hs, .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.2.0/build/Foo.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone $j_s72t
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 324566
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building package ghc-bug-0.0.0 using:
/home/kostmo/.stack/setup-exe-cache/x86_64-linux-nopie/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-nopie/Cabal-1.24.2.0 build lib:ghc-bug --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
```
Generating a tuple from elements of an object for the purpose of sorting is an idiom I have used in Python at times.
The original use case in Haskell for me was excluding some fields of the record in the comparison (e.g. `f10`, `f11`, `f12` fields), rather than using a simple `sort` with `deriving Ord` on `MyRecord`. I worked around the issue for now by blanking out the record fields I with to ignore, instead of re-instantiating a tuple of field values:
```haskell
getComparisonValue x = x {
f10 = Nothing
, f11 = Nothing
, f12 = Nothing
}
```
<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":"sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with \"Simplifier ticks exhausted\"","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":"Given the following code (full Stack project attached):\r\n\r\n{{{#!haskell\r\nmodule Foo where\r\n\r\nimport Data.List\r\n\r\ndata MyRecord = MyRecord {\r\n f1 :: Maybe String\r\n , f2 :: Maybe String\r\n , f3 :: Maybe String\r\n , f4 :: Maybe String\r\n , f5 :: Maybe String\r\n , f6 :: Maybe String\r\n , f7 :: Maybe String\r\n , f8 :: Maybe String\r\n , f9 :: Maybe String\r\n , f10 :: Maybe String\r\n , f11 :: Maybe String\r\n , f12 :: Maybe String\r\n }\r\n\r\ngetComparisonValue x = (\r\n f1 x\r\n , f2 x\r\n , f3 x\r\n , f4 x\r\n , f5 x\r\n , f6 x\r\n , f7 x\r\n , f8 x\r\n , f9 x\r\n )\r\n\r\ndoSort = sortOn getComparisonValue\r\n}}}\r\n\r\n\r\nThe following error results:\r\n\r\n{{{\r\n$ stack build\r\nghc-bug-0.0.0: build (lib)\r\nPreprocessing library ghc-bug-0.0.0...\r\n[1 of 1] Compiling Foo ( Foo.hs, .stack-work/dist/x86_64-linux-nopie/Cabal-1.24.2.0/build/Foo.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone $j_s72t\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 324566\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n-- While building package ghc-bug-0.0.0 using:\r\n /home/kostmo/.stack/setup-exe-cache/x86_64-linux-nopie/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-nopie/Cabal-1.24.2.0 build lib:ghc-bug --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n}}}\r\n\r\nGenerating a tuple from elements of an object for the purpose of sorting is an idiom I have used in Python at times.\r\n\r\nThe original use case in Haskell for me was excluding some fields of the record in the comparison (e.g. `f10`, `f11`, `f12` fields), rather than using a simple `sort` with `deriving Ord` on `MyRecord`. I worked around the issue for now by blanking out the record fields I with to ignore, instead of re-instantiating a tuple of field values:\r\n\r\n\r\n{{{#!haskell\r\ngetComparisonValue x = x {\r\n f10 = Nothing\r\n , f11 = Nothing\r\n , f12 = Nothing\r\n }\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14102panic! (the 'impossible' happened)2019-07-07T18:18:27Zpmckelvypanic! (the 'impossible' happened)```
(GHC version 8.0.2 for x86_64-apple-darwin):
initTc: unsolved constraints
WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)}
```
Code:
```hs
import Data.Char
import Data.List
data InvoiceStruct = InvoiceStruc...```
(GHC version 8.0.2 for x86_64-apple-darwin):
initTc: unsolved constraints
WC {wc_insol = [W] action_a1Ei :: t_a1Eh[tau:1] (CHoleCan: action)}
```
Code:
```hs
import Data.Char
import Data.List
data InvoiceStruct = InvoiceStruct
{ total :: Int
, shippedItemCount :: Int
} deriving (Show)
invoice :: InvoiceStruct -> String -> Int -> InvoiceStruct
invoice i comp val = (action) i[total] val
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14028ghc panic: -fexternal-interpreter + .o + QuasiQuotes?2021-04-21T06:45:52Zblynnghc panic: -fexternal-interpreter + .o + QuasiQuotes?1. Compile an object file with -fPIC, e.g:
```
cat > hello.c << EOF
#include <stdio.h>
void hi(){puts("Hello, World!");}
EOF
gcc -c -fPIC hello.c
```
1. Write Haskell that uses QuasiQuotes, e.g:
```
cat > h.hs << EOF
{-# LANGUAGE Quas...1. Compile an object file with -fPIC, e.g:
```
cat > hello.c << EOF
#include <stdio.h>
void hi(){puts("Hello, World!");}
EOF
gcc -c -fPIC hello.c
```
1. Write Haskell that uses QuasiQuotes, e.g:
```
cat > h.hs << EOF
{-# LANGUAGE QuasiQuotes #-}
import Text.Heredoc (here)
s :: String
s = [here|goes nothing|]
EOF
```
1. Compile with -fexternal-interpreter:
```
cabal install heredoc
ghc -fexternal-interpreter h.hs hello.o
```
I saw:
\[1 of 1\] Compiling Main ( h.hs, h.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
> Loading temp shared object failed: /home/blynn/.local/lib/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so: undefined symbol: stg_thawArrayzh
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<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":"ghc panic: -fexternal-interpreter + .o + QuasiQuotes?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":["ghc","impossible","panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1. Compile an object file with -fPIC, e.g:\r\n\r\n{{{\r\ncat > hello.c << EOF\r\n#include <stdio.h>\r\nvoid hi(){puts(\"Hello, World!\");}\r\nEOF\r\ngcc -c -fPIC hello.c\r\n}}}\r\n\r\n2. Write Haskell that uses QuasiQuotes, e.g:\r\n\r\n{{{\r\ncat > h.hs << EOF\r\n{-# LANGUAGE QuasiQuotes #-}\r\nimport Text.Heredoc (here)\r\ns :: String\r\ns = [here|goes nothing|]\r\nEOF\r\n}}}\r\n\r\n3. Compile with -fexternal-interpreter:\r\n\r\n{{{\r\ncabal install heredoc\r\nghc -fexternal-interpreter h.hs hello.o\r\n}}}\r\n\r\nI saw:\r\n\r\n[1 of 1] Compiling Main ( h.hs, h.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n Loading temp shared object failed: /home/blynn/.local/lib/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so: undefined symbol: stg_thawArrayzh\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13984Panic when using a TH splice in a do bind pattern2019-07-07T18:19:01ZmbieleckPanic when using a TH splice in a do bind patternWhen compiling this file with HEAD (f656fba19d0cefe05643ddea35d080ea332a6584):
```hs
{-# LANGUAGE TemplateHaskell #-}
module Panic where
import Language.Haskell.TH
expr :: IO Exp
expr = runQ $ do
name <- newName "foo"
[| do $(varP...When compiling this file with HEAD (f656fba19d0cefe05643ddea35d080ea332a6584):
```hs
{-# LANGUAGE TemplateHaskell #-}
module Panic where
import Language.Haskell.TH
expr :: IO Exp
expr = runQ $ do
name <- newName "foo"
[| do $(varP name) <- pure (); pure () |]
```
I get this message:
```
[1 of 1] Compiling Panic ( Panic.hs, Panic.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.3.20170713 for x86_64-unknown-linux):
isIrrefutableHsPat:
$(varP name)
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/hsSyn/HsPat.hs:643:15 in ghc:HsPat
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
It compiles normally with GHC 8.2.1-rc2 (20170507). The bug exists in rc3 (20170704). I am unable to perform a more precise bisect.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic when using a TH splice in a do bind pattern","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":["panic","template-haskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling this file with HEAD (f656fba19d0cefe05643ddea35d080ea332a6584):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Panic where\r\n\r\nimport Language.Haskell.TH\r\n\r\nexpr :: IO Exp\r\nexpr = runQ $ do\r\n name <- newName \"foo\"\r\n [| do $(varP name) <- pure (); pure () |]\r\n\r\n}}}\r\n\r\nI get this message:\r\n\r\n{{{\r\n[1 of 1] Compiling Panic ( Panic.hs, Panic.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.3.20170713 for x86_64-unknown-linux):\r\n isIrrefutableHsPat:\r\n $(varP name)\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/hsSyn/HsPat.hs:643:15 in ghc:HsPat\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nIt compiles normally with GHC 8.2.1-rc2 (20170507). The bug exists in rc3 (20170704). I am unable to perform a more precise bisect.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13979Don't use gtar to produce FreeBSD binary distribution2019-07-07T18:19:04ZBen GamariDon't use gtar to produce FreeBSD binary distributionMentioned in #13974.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| Ty...Mentioned in #13974.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Don't use gtar to produce FreeBSD binary distribution","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Mentioned in #13974. ","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13977ExnStr doesn't propagate "outwards"2019-07-07T18:19:05ZBen GamariExnStr doesn't propagate "outwards"While looking into #8091 (see [ticket:8091\#comment:139352](https://gitlab.haskell.org//ghc/ghc/issues/8091#note_139352)) and #13916, I noticed something that I found rather surprising. Consider this program,
```hs
hello :: STM Char -> ...While looking into #8091 (see [ticket:8091\#comment:139352](https://gitlab.haskell.org//ghc/ghc/issues/8091#note_139352)) and #13916, I noticed something that I found rather surprising. Consider this program,
```hs
hello :: STM Char -> STM Char
hello a = a `orElse` pure 'a'
```
Recall that `catchRetry#` (which `orElse` is defined in terms of) has the following demand signature,
```
<xC(S),1*C1(U)><L,1*C1(U)><L,U>
```
Note the `x` here: this means it is `ExnStr`, since it doesn't bottom even if the first argument does (despite the fact that it's strict).
So, the question is this: What demand should `hello` place on its first argument? I would have thought that it should be precisely the same as the demand that `catchRetry#` places on \*\*its\*\* first argument. However, the demand analyser seems to conclude this:
```
<C(S),1*C1(U)>
```
Note the lack of an `x`. I believe this may be what causes #13916. 8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13974Official FreeBSD 10.3 distribution should link against libutil.so.9, not libu...2019-07-07T18:19:06ZmqudsiOfficial FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8The official distribution of GHC for FreeBSD, as retrieved from \[0\] attempts to link against libutil.so.8
FreeBSD 10.3 is actually built against libutil.so.9, and there is no /lib/libutil.so.8 (and no version 8 of the library availabl...The official distribution of GHC for FreeBSD, as retrieved from \[0\] attempts to link against libutil.so.8
FreeBSD 10.3 is actually built against libutil.so.9, and there is no /lib/libutil.so.8 (and no version 8 of the library available via the package manager/ports).
Symlinking /lib/libutil.so.9 to /lib/libutil.so.8 appears to allow GHC to run without issue, but I can't guarantee the results.
Since the distributed GHC tarball is specific to FreeBSD 10.3, it should probably link against libutil.so.9 as well.
(I am completely new to Haskell/GHC and have no clue what "component" to tag this as. I was looking for a 'distribution' or 'packages' component, but can find none. My apologies in advance for tagging it as 'None')
\[0\]: https://www.haskell.org/ghc/download_ghc_7_10_3.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The official distribution of GHC for FreeBSD, as retrieved from [0] attempts to link against libutil.so.8\r\n\r\nFreeBSD 10.3 is actually built against libutil.so.9, and there is no /lib/libutil.so.8 (and no version 8 of the library available via the package manager/ports).\r\n\r\nSymlinking /lib/libutil.so.9 to /lib/libutil.so.8 appears to allow GHC to run without issue, but I can't guarantee the results.\r\n\r\nSince the distributed GHC tarball is specific to FreeBSD 10.3, it should probably link against libutil.so.9 as well.\r\n\r\n(I am completely new to Haskell/GHC and have no clue what \"component\" to tag this as. I was looking for a 'distribution' or 'packages' component, but can find none. My apologies in advance for tagging it as 'None')\r\n\r\n\r\n[0]: https://www.haskell.org/ghc/download_ghc_7_10_3.html","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13970Segmentation fault inside threadPaused2019-07-07T18:19:07ZalbertovSegmentation fault inside threadPausedA multithreaded program generated by latest release candidate occasionally segfaults inside the runtime system. It is always at the same instruction:
```
(gdb) bt
#0 0x00007f25ca77fde3 in threadPaused ()
from /nix/store/995xifyvjlbv...A multithreaded program generated by latest release candidate occasionally segfaults inside the runtime system. It is always at the same instruction:
```
(gdb) bt
#0 0x00007f25ca77fde3 in threadPaused ()
from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr-ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr-ghc8.2.0.20170704.so
#1 0x00007f25ca795068 in stg_returnToSched ()
from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr-ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr-ghc8.2.0.20170704.so
#2 0x0000000000000000 in ?? ()
(gdb) disassemble
Dump of assembler code for function threadPaused:
0x00007f25ca77fda0 <+0>: push %r15
0x00007f25ca77fda2 <+2>: push %r14
0x00007f25ca77fda4 <+4>: push %r13
0x00007f25ca77fda6 <+6>: push %r12
0x00007f25ca77fda8 <+8>: mov %rdi,%r12
0x00007f25ca77fdab <+11>: push %rbp
0x00007f25ca77fdac <+12>: push %rbx
0x00007f25ca77fdad <+13>: mov %rsi,%rbp
0x00007f25ca77fdb0 <+16>: sub $0x28,%rsp
0x00007f25ca77fdb4 <+20>: callq 0x7f25ca77a640 <maybePerformBlockedException>
0x00007f25ca77fdb9 <+25>: cmpw $0x3,0x20(%rbp)
0x00007f25ca77fdbe <+30>: je 0x7f25ca77fe1d <threadPaused+125>
0x00007f25ca77fdc0 <+32>: mov 0x18(%rbp),%rax
0x00007f25ca77fdc4 <+36>: mov 0x8(%rax),%edx
0x00007f25ca77fdc7 <+39>: mov 0x10(%rax),%rbx
0x00007f25ca77fdcb <+43>: lea 0x18(%rax,%rdx,8),%r13
0x00007f25ca77fdd0 <+48>: cmp %rbx,%r13
0x00007f25ca77fdd3 <+51>: jbe 0x7f25ca77fe16 <threadPaused+118>
0x00007f25ca77fdd5 <+53>: xor %r9d,%r9d
0x00007f25ca77fdd8 <+56>: xor %r14d,%r14d
0x00007f25ca77fddb <+59>: xor %r15d,%r15d
0x00007f25ca77fdde <+62>: xor %ecx,%ecx
0x00007f25ca77fde0 <+64>: mov (%rbx),%rdx
=> 0x00007f25ca77fde3 <+67>: mov -0x8(%rdx),%eax
0x00007f25ca77fde6 <+70>: cmp $0x21,%eax
0x00007f25ca77fde9 <+73>: je 0x7f25ca77ff10 <threadPaused+368>
0x00007f25ca77fdef <+79>: jb 0x7f25ca77fed0 <threadPaused+304>
0x00007f25ca77fdf5 <+85>: lea -0x23(%rax),%esi
0x00007f25ca77fdf8 <+88>: cmp $0x1,%esi
0x00007f25ca77fdfb <+91>: ja 0x7f25ca77fed0 <threadPaused+304>
0x00007f25ca77fe01 <+97>: cmp $0x8,%r15d
0x00007f25ca77fe05 <+101>: setbe %dl
0x00007f25ca77fe08 <+104>: test %ecx,%ecx
0x00007f25ca77fe0a <+106>: setne %al
0x00007f25ca77fe0d <+109>: test %al,%dl
0x00007f25ca77fe0f <+111>: jne 0x7f25ca77fe30 <threadPaused+144>
0x00007f25ca77fe11 <+113>: cmp %r15d,%ecx
0x00007f25ca77fe14 <+116>: ja 0x7f25ca77fe30 <threadPaused+144>
0x00007f25ca77fe16 <+118>: andl $0xffffff7f,0x24(%rbp)
0x00007f25ca77fe1d <+125>: add $0x28,%rsp
0x00007f25ca77fe21 <+129>: pop %rbx
0x00007f25ca77fe22 <+130>: pop %rbp
0x00007f25ca77fe23 <+131>: pop %r12
0x00007f25ca77fe25 <+133>: pop %r13
0x00007f25ca77fe27 <+135>: pop %r14
0x00007f25ca77fe29 <+137>: pop %r15
0x00007f25ca77fe2b <+139>: retq
0x00007f25ca77fe2c <+140>: nopl 0x0(%rax)
0x00007f25ca77fe30 <+144>: lea 0x3e2c9(%rip),%rax # 0x7f25ca7be100 <RtsFlags>
0x00007f25ca77fe37 <+151>: cmpb $0x0,0x4c(%rax)
0x00007f25ca77fe3b <+155>: je 0x7f25ca77fe16 <threadPaused+118>
0x00007f25ca77fe3d <+157>: mov 0x18(%rbp),%rax
0x00007f25ca77fe41 <+161>: mov 0x10(%rax),%r14
0x00007f25ca77fe45 <+165>: cmp %rbx,%r14
0x00007f25ca77fe48 <+168>: lea -0x10(%r14),%r13
0x00007f25ca77fe4c <+172>: ja 0x7f25ca780082 <threadPaused+738>
0x00007f25ca77fe52 <+178>: xor %ecx,%ecx
0x00007f25ca77fe54 <+180>: jmp 0x7f25ca77fe70 <threadPaused+208>
0x00007f25ca77fe56 <+182>: nopw %cs:0x0(%rax,%rax,1)
0x00007f25ca77fe60 <+192>: add $0x1,%ecx
0x00007f25ca77fe63 <+195>: add $0x10,%r14
0x00007f25ca77fe67 <+199>: cmp %rbx,%r14
0x00007f25ca77fe6a <+202>: ja 0x7f25ca780060 <threadPaused+704>
0x00007f25ca77fe70 <+208>: mov (%r14),%rdx
0x00007f25ca77fe73 <+211>: mov -0x8(%rdx),%eax
0x00007f25ca77fe76 <+214>: cmp $0x21,%eax
0x00007f25ca77fe79 <+217>: je 0x7f25ca77fe60 <threadPaused+192>
0x00007f25ca77fe7b <+219>: cmp $0x1,%ecx
0x00007f25ca77fe7e <+222>: jbe 0x7f25ca77fe9b <threadPaused+251>
0x00007f25ca77fe80 <+224>: lea -0x10(%r14),%rdx
0x00007f25ca77fe84 <+228>: mov %r13,%r8
0x00007f25ca77fe87 <+231>: mov %rbp,%rsi
0x00007f25ca77fe8a <+234>: mov %r12,%rdi
0x00007f25ca77fe8d <+237>: callq 0x7f25ca77fce0 <updateAdjacentFrames>
0x00007f25ca77fe92 <+242>: mov (%r14),%rdx
0x00007f25ca77fe95 <+245>: mov %rax,%r13
0x00007f25ca77fe98 <+248>: mov -0x8(%rdx),%eax
0x00007f25ca77fe9b <+251>: cmp $0x1f,%eax
0x00007f25ca77fe9e <+254>: je 0x7f25ca780048 <threadPaused+680>
0x00007f25ca77fea4 <+260>: cmp $0x20,%eax
0x00007f25ca77fea7 <+263>: je 0x7f25ca780038 <threadPaused+664>
0x00007f25ca77fead <+269>: cmp $0x1d,%eax
0x00007f25ca77feb0 <+272>: je 0x7f25ca780020 <threadPaused+640>
...
```
Which I believe is the same place as reported in #9130.
Apart from this error, the program also crashes, occasionally, with:
```
sigym4-propag: internal error: scavenge_stack: weird activation record found on stack: -1717986919
(GHC version 8.2.0.20170704 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
(The activation record number changes between runs).
I believe these to be related since I've found (after a long git-bisect session) that they both began manifesting themselves after the same GHC commit: c1c0985416a6f9766c03d361449f556905bf8e1d
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc3 |
| 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":"Segmentation fault inside threadPaused","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A multithreaded program generated by latest release candidate occasionally segfaults inside the runtime system. It is always at the same instruction: \r\n{{{\r\n(gdb) bt\r\n#0 0x00007f25ca77fde3 in threadPaused ()\r\n from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr-ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr-ghc8.2.0.20170704.so\r\n#1 0x00007f25ca795068 in stg_returnToSched ()\r\n from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr-ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr-ghc8.2.0.20170704.so\r\n#2 0x0000000000000000 in ?? ()\r\n\r\n(gdb) disassemble \r\nDump of assembler code for function threadPaused:\r\n 0x00007f25ca77fda0 <+0>: push %r15\r\n 0x00007f25ca77fda2 <+2>: push %r14\r\n 0x00007f25ca77fda4 <+4>: push %r13\r\n 0x00007f25ca77fda6 <+6>: push %r12\r\n 0x00007f25ca77fda8 <+8>: mov %rdi,%r12\r\n 0x00007f25ca77fdab <+11>: push %rbp\r\n 0x00007f25ca77fdac <+12>: push %rbx\r\n 0x00007f25ca77fdad <+13>: mov %rsi,%rbp\r\n 0x00007f25ca77fdb0 <+16>: sub $0x28,%rsp\r\n 0x00007f25ca77fdb4 <+20>: callq 0x7f25ca77a640 <maybePerformBlockedException>\r\n 0x00007f25ca77fdb9 <+25>: cmpw $0x3,0x20(%rbp)\r\n 0x00007f25ca77fdbe <+30>: je 0x7f25ca77fe1d <threadPaused+125>\r\n 0x00007f25ca77fdc0 <+32>: mov 0x18(%rbp),%rax\r\n 0x00007f25ca77fdc4 <+36>: mov 0x8(%rax),%edx\r\n 0x00007f25ca77fdc7 <+39>: mov 0x10(%rax),%rbx\r\n 0x00007f25ca77fdcb <+43>: lea 0x18(%rax,%rdx,8),%r13\r\n 0x00007f25ca77fdd0 <+48>: cmp %rbx,%r13\r\n 0x00007f25ca77fdd3 <+51>: jbe 0x7f25ca77fe16 <threadPaused+118>\r\n 0x00007f25ca77fdd5 <+53>: xor %r9d,%r9d\r\n 0x00007f25ca77fdd8 <+56>: xor %r14d,%r14d\r\n 0x00007f25ca77fddb <+59>: xor %r15d,%r15d\r\n 0x00007f25ca77fdde <+62>: xor %ecx,%ecx\r\n 0x00007f25ca77fde0 <+64>: mov (%rbx),%rdx\r\n=> 0x00007f25ca77fde3 <+67>: mov -0x8(%rdx),%eax\r\n 0x00007f25ca77fde6 <+70>: cmp $0x21,%eax\r\n 0x00007f25ca77fde9 <+73>: je 0x7f25ca77ff10 <threadPaused+368>\r\n 0x00007f25ca77fdef <+79>: jb 0x7f25ca77fed0 <threadPaused+304>\r\n 0x00007f25ca77fdf5 <+85>: lea -0x23(%rax),%esi\r\n 0x00007f25ca77fdf8 <+88>: cmp $0x1,%esi\r\n 0x00007f25ca77fdfb <+91>: ja 0x7f25ca77fed0 <threadPaused+304>\r\n 0x00007f25ca77fe01 <+97>: cmp $0x8,%r15d\r\n 0x00007f25ca77fe05 <+101>: setbe %dl\r\n 0x00007f25ca77fe08 <+104>: test %ecx,%ecx\r\n 0x00007f25ca77fe0a <+106>: setne %al\r\n 0x00007f25ca77fe0d <+109>: test %al,%dl\r\n 0x00007f25ca77fe0f <+111>: jne 0x7f25ca77fe30 <threadPaused+144>\r\n 0x00007f25ca77fe11 <+113>: cmp %r15d,%ecx\r\n 0x00007f25ca77fe14 <+116>: ja 0x7f25ca77fe30 <threadPaused+144>\r\n 0x00007f25ca77fe16 <+118>: andl $0xffffff7f,0x24(%rbp)\r\n 0x00007f25ca77fe1d <+125>: add $0x28,%rsp\r\n 0x00007f25ca77fe21 <+129>: pop %rbx\r\n 0x00007f25ca77fe22 <+130>: pop %rbp\r\n 0x00007f25ca77fe23 <+131>: pop %r12\r\n 0x00007f25ca77fe25 <+133>: pop %r13\r\n 0x00007f25ca77fe27 <+135>: pop %r14\r\n 0x00007f25ca77fe29 <+137>: pop %r15\r\n 0x00007f25ca77fe2b <+139>: retq \r\n 0x00007f25ca77fe2c <+140>: nopl 0x0(%rax)\r\n 0x00007f25ca77fe30 <+144>: lea 0x3e2c9(%rip),%rax # 0x7f25ca7be100 <RtsFlags>\r\n 0x00007f25ca77fe37 <+151>: cmpb $0x0,0x4c(%rax)\r\n 0x00007f25ca77fe3b <+155>: je 0x7f25ca77fe16 <threadPaused+118>\r\n 0x00007f25ca77fe3d <+157>: mov 0x18(%rbp),%rax\r\n 0x00007f25ca77fe41 <+161>: mov 0x10(%rax),%r14\r\n 0x00007f25ca77fe45 <+165>: cmp %rbx,%r14\r\n 0x00007f25ca77fe48 <+168>: lea -0x10(%r14),%r13\r\n 0x00007f25ca77fe4c <+172>: ja 0x7f25ca780082 <threadPaused+738>\r\n 0x00007f25ca77fe52 <+178>: xor %ecx,%ecx\r\n 0x00007f25ca77fe54 <+180>: jmp 0x7f25ca77fe70 <threadPaused+208>\r\n 0x00007f25ca77fe56 <+182>: nopw %cs:0x0(%rax,%rax,1)\r\n 0x00007f25ca77fe60 <+192>: add $0x1,%ecx\r\n 0x00007f25ca77fe63 <+195>: add $0x10,%r14\r\n 0x00007f25ca77fe67 <+199>: cmp %rbx,%r14\r\n 0x00007f25ca77fe6a <+202>: ja 0x7f25ca780060 <threadPaused+704>\r\n 0x00007f25ca77fe70 <+208>: mov (%r14),%rdx\r\n 0x00007f25ca77fe73 <+211>: mov -0x8(%rdx),%eax\r\n 0x00007f25ca77fe76 <+214>: cmp $0x21,%eax\r\n 0x00007f25ca77fe79 <+217>: je 0x7f25ca77fe60 <threadPaused+192>\r\n 0x00007f25ca77fe7b <+219>: cmp $0x1,%ecx\r\n 0x00007f25ca77fe7e <+222>: jbe 0x7f25ca77fe9b <threadPaused+251>\r\n 0x00007f25ca77fe80 <+224>: lea -0x10(%r14),%rdx\r\n 0x00007f25ca77fe84 <+228>: mov %r13,%r8\r\n 0x00007f25ca77fe87 <+231>: mov %rbp,%rsi\r\n 0x00007f25ca77fe8a <+234>: mov %r12,%rdi\r\n 0x00007f25ca77fe8d <+237>: callq 0x7f25ca77fce0 <updateAdjacentFrames>\r\n 0x00007f25ca77fe92 <+242>: mov (%r14),%rdx\r\n 0x00007f25ca77fe95 <+245>: mov %rax,%r13\r\n 0x00007f25ca77fe98 <+248>: mov -0x8(%rdx),%eax\r\n 0x00007f25ca77fe9b <+251>: cmp $0x1f,%eax\r\n 0x00007f25ca77fe9e <+254>: je 0x7f25ca780048 <threadPaused+680>\r\n 0x00007f25ca77fea4 <+260>: cmp $0x20,%eax\r\n 0x00007f25ca77fea7 <+263>: je 0x7f25ca780038 <threadPaused+664>\r\n 0x00007f25ca77fead <+269>: cmp $0x1d,%eax\r\n 0x00007f25ca77feb0 <+272>: je 0x7f25ca780020 <threadPaused+640>\r\n...\r\n}}}\r\n\r\nWhich I believe is the same place as reported in #9130.\r\n\r\nApart from this error, the program also crashes, occasionally, with:\r\n\r\n{{{\r\nsigym4-propag: internal error: scavenge_stack: weird activation record found on stack: -1717986919\r\n (GHC version 8.2.0.20170704 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n(The activation record number changes between runs).\r\n\r\nI believe these to be related since I've found (after a long git-bisect session) that they both began manifesting themselves after the same GHC commit: c1c0985416a6f9766c03d361449f556905bf8e1d","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13948GHC incorrectly suggests a data constructor is in scope in 8.22019-07-07T18:19:16ZRyan ScottGHC incorrectly suggests a data constructor is in scope in 8.2After commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (the fix for #13568), which debuted in GHC 8.2, GHC thinks that out-of-scope identifiers are actually in-scope!
```hs
module Bug where
f :: T
f = undefined
```
In GHC 8.2.1-rc3, th...After commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (the fix for #13568), which debuted in GHC 8.2, GHC thinks that out-of-scope identifiers are actually in-scope!
```hs
module Bug where
f :: T
f = undefined
```
In GHC 8.2.1-rc3, the error message is:
```
$ /opt/ghc/8.2.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:3:6: error:
Not in scope: type constructor or class ‘T’
A data constructor of that name is in scope; did you mean DataKinds?
|
3 | f :: T
| ^
```
Compare this to GHC 8.0.2, which gives a more sensible error message:
```
$ /opt/ghc/8.0.2/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:3:6: error: Not in scope: type constructor or class ‘T’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mrkgnao |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC incorrectly suggests a data constructor is in scope in 8.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mrkgnao"],"type":"Bug","description":"After commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (the fix for #13568), which debuted in GHC 8.2, GHC thinks that out-of-scope identifiers are actually in-scope!\r\n\r\n{{{#!hs\r\nmodule Bug where\r\n\r\nf :: T\r\nf = undefined\r\n}}}\r\n\r\nIn GHC 8.2.1-rc3, the error message is:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:3:6: error:\r\n Not in scope: type constructor or class ‘T’\r\n A data constructor of that name is in scope; did you mean DataKinds?\r\n |\r\n3 | f :: T\r\n | ^\r\n}}}\r\n\r\nCompare this to GHC 8.0.2, which gives a more sensible error message:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.2/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:3:6: error: Not in scope: type constructor or class ‘T’\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13941STG linter's type equality can loop2019-07-07T18:19:18ZBen GamariSTG linter's type equality can loop`stgEqType` will currently loop when given the following,
```hs
stgEqType (a -> IO ()) (a -> IO ())
```
The problem is that the `(->)` tycon now takes runtime rep arguments.
To see why, let's look at the (paraphrased) implementation,
...`stgEqType` will currently loop when given the following,
```hs
stgEqType (a -> IO ()) (a -> IO ())
```
The problem is that the `(->)` tycon now takes runtime rep arguments.
To see why, let's look at the (paraphrased) implementation,
```hs
stgEqType orig_ty1 orig_ty2
= gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)
where
gos :: [PrimRep] -> [PrimRep] -> Bool
gos [_] [_] = go orig_ty1 orig_ty2
gos reps1 reps2 = reps1 == reps2
go :: UnaryType -> UnaryType -> Bool
go ty1 ty2
| Just (tc1, tc_args1) <- splitTyConApp_maybe ty1
, Just (tc2, tc_args2) <- splitTyConApp_maybe ty2
, let res = if tc1 == tc2
then equalLength tc_args1 tc_args2
&& and (zipWith (gos `on` typePrimRep) tc_args1 tc_args2)
else (isFamilyTyCon tc1 || isFamilyTyCon tc2)
= res
| otherwise = True -- Conservatively say "fine".
```
Our example will begin by looking at the `gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)` and, seeing that the `orig_ty`s are unary, enter `go`. We will then split the applications such that,
```
tc1, tc2 = (->)
tc_args1, tc_args2 = ['LiftedPtrRep, 'LiftedPtrRep, a, IO ()]
```
Seeing that the tycons are equal, we will enter `gos` on each of the `tc_args`. Of course, one would think that `typePrimRep 'LiftedPtrRep` should throw an error, but because `gos` only forces the spine of the list, that error doesn't get thrown. Instead we incorrectly conclude that `'LiftedPtrRep` is a unary type and recurse into `go orig_ty1 orig_ty2`, thus looping.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"STG linter's type equality can loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`stgEqType` will currently loop when given the following,\r\n{{{#!hs\r\nstgEqType (a -> IO ()) (a -> IO ())\r\n}}}\r\nThe problem is that the `(->)` tycon now takes runtime rep arguments. \r\n\r\nTo see why, let's look at the (paraphrased) implementation,\r\n{{{#!hs\r\nstgEqType orig_ty1 orig_ty2\r\n = gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)\r\n where\r\n gos :: [PrimRep] -> [PrimRep] -> Bool\r\n gos [_] [_] = go orig_ty1 orig_ty2\r\n gos reps1 reps2 = reps1 == reps2\r\n\r\n go :: UnaryType -> UnaryType -> Bool\r\n go ty1 ty2\r\n | Just (tc1, tc_args1) <- splitTyConApp_maybe ty1\r\n , Just (tc2, tc_args2) <- splitTyConApp_maybe ty2\r\n , let res = if tc1 == tc2\r\n then equalLength tc_args1 tc_args2 \r\n && and (zipWith (gos `on` typePrimRep) tc_args1 tc_args2)\r\n else (isFamilyTyCon tc1 || isFamilyTyCon tc2)\r\n = res\r\n\r\n | otherwise = True -- Conservatively say \"fine\".\r\n}}}\r\n\r\nOur example will begin by looking at the `gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)` and, seeing that the `orig_ty`s are unary, enter `go`. We will then split the applications such that,\r\n{{{\r\ntc1, tc2 = (->)\r\ntc_args1, tc_args2 = ['LiftedPtrRep, 'LiftedPtrRep, a, IO ()]\r\n}}}\r\nSeeing that the tycons are equal, we will enter `gos` on each of the `tc_args`. Of course, one would think that `typePrimRep 'LiftedPtrRep` should throw an error, but because `gos` only forces the spine of the list, that error doesn't get thrown. Instead we incorrectly conclude that `'LiftedPtrRep` is a unary type and recurse into `go orig_ty1 orig_ty2`, thus looping.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13937@progbits is used incorrectly throughout GHC2019-07-07T18:19:20ZBen Gamari@progbits is used incorrectly throughout GHCGHC uses `.section $SECTION_NAME,$FLAGS,@progbits` directives throughout its produced assembler. However, some architectures (e.g. ARM) use `@` as a comment character and therefore must use some other prefix for section types.
<details>...GHC uses `.section $SECTION_NAME,$FLAGS,@progbits` directives throughout its produced assembler. However, some architectures (e.g. ARM) use `@` as a comment character and therefore must use some other prefix for section types.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"@progbits is used incorrectly throughout GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC uses `.section $SECTION_NAME,$FLAGS,@progbits` directives throughout its produced assembler. However, some architectures (e.g. ARM) use `@` as a comment character and therefore must use some other prefix for section types. ","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13935AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing ...2019-07-07T18:19:21Zmjvoge02AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to failCode in \[\[GhcFile(configure.ac)\]\] incorrectly assesses that pthread functions will be available without explicitly providing `-lpthread` to gcc. This causes the build to fail.
Forcing `need_lpthread=1` in \[\[GhcFile(configure.ac)\]...Code in \[\[GhcFile(configure.ac)\]\] incorrectly assesses that pthread functions will be available without explicitly providing `-lpthread` to gcc. This causes the build to fail.
Forcing `need_lpthread=1` in \[\[GhcFile(configure.ac)\]\] causes the build to succeed and produce a perfectly functional GHC.
From conversation on \#GHC:
"It looks like the combination of the following two commits has caused the breakage: e94bfb677298de3c4b4e0d1223fbc589849b79be, c0872bf99ff891e440f118bf9eea20b980c2cfca.\[\[br\]\]
The first makes the configure script check if the `-lpthread` argument is required when building GHC, and the second uses that knowledge at runtime to decide whether to pass `-lpthread` when linking programs. \[\[br\]\]
Stage 0 builds stage 1 just fine, since it doesn't have these commits and decides whether to pass `-lpthread` based purely on the platform. But the code from the first commit is yielding a false result (I don't know why), so stage 1 fails to build stage 2, since the second commit makes it use the false result to choose not to pass `-lpthread`."
Also, doesn't determining the need for `-lpthread` like this have problematic implications for cross compilation? Whether `-lpthread` is required could be different between linking GHC and GHC doing linking (e.g. a cross compiler built on a system that does need the flag targeting a system that doesn't.)
Ignoring that, using AX_PTHREAD or ACX_PTHREAD could potentially help resolve the issue.
Relevant code from \[\[GhcFile(configure.ac)\]\]:
```bash
dnl Some platforms (e.g. Android's Bionic) have pthreads support available
dnl without linking against libpthread. Check whether -lpthread is necessary
dnl to use pthreads.
dnl
dnl Note that it is important that this happens before we AC_CHECK_LIB(thread)
AC_MSG_CHECKING(whether -lpthread is needed for pthreads)
AC_CHECK_FUNC(pthread_create,
[
AC_MSG_RESULT(no)
need_lpthread=0
],
[
AC_CHECK_LIB(pthread, pthread_create,
[
AC_MSG_RESULT(yes)
need_lpthread=1
],
[
AC_MSG_RESULT([no pthreads support found.])
need_lpthread=0
])
])
AC_DEFINE_UNQUOTED([NEED_PTHREAD_LIB], [$need_lpthread],
[Define 1 if we need to link code using pthreads with -lpthread])
```
System information:
Linux nixos 4.9.30 x86_64 GNU/Linux
gcc 5.4.0
ghc 7.10.3
Attempting to build GHC HEAD fails with
```bash
...
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O0 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/hsSyn/HsTypes.hs -o compiler/stage2/build/HsTypes.o -dyno compiler/stage2/build/HsTypes.dyn_o
includes/rts/OSThreads.h:58:0: error:
error: undefined reference to 'pthread_mutex_trylock'
|
58 | return pthread_mutex_trylock(mutex);
| ^
includes/rts/OSThreads.h:58:0: error:
error: undefined reference to 'pthread_mutex_trylock'
|
58 | return pthread_mutex_trylock(mutex);
| ^
rts/posix/OSThreads.c:137:0: error:
error: undefined reference to 'pthread_create'
|
137 | int result = pthread_create(pId, NULL, (void *(*)(void *))startProc, param);
| ^
rts/posix/OSThreads.c:139:0: error:
error: undefined reference to 'pthread_detach'
|
139 | pthread_detach(*pId);
| ^
rts/posix/OSThreads.c:141:0: error:
error: undefined reference to 'pthread_setname_np'
|
141 | pthread_setname_np(*pId, name);
| ^
rts/posix/OSThreads.c:184:0: error:
error: undefined reference to 'pthread_key_create'
|
184 | if ((r = pthread_key_create(key, NULL)) != 0) {
| ^
rts/posix/OSThreads.c:203:0: error:
error: undefined reference to 'pthread_setspecific'
|
203 | if ((r = pthread_setspecific(*key,value)) != 0) {
| ^
rts/posix/OSThreads.c:212:0: error:
error: undefined reference to 'pthread_key_delete'
|
212 | if ((r = pthread_key_delete(*key)) != 0) {
| ^
rts/posix/OSThreads.c:233:0: error:
error: undefined reference to 'pthread_create'
|
233 | int result = pthread_create(&tid, NULL,
| ^
rts/posix/OSThreads.c:236:0: error:
error: undefined reference to 'pthread_detach'
|
236 | pthread_detach(tid);
| ^
rts/posix/OSThreads.c:192:0: error:
error: undefined reference to 'pthread_getspecific'
|
192 | return pthread_getspecific(*key);
| ^
rts/posix/OSThreads.c:371:0: error:
error: undefined reference to 'pthread_kill'
|
371 | pthread_kill(id, SIGPIPE);
| ^
rts/posix/itimer/Pthread.c:171:0: error:
error: undefined reference to 'pthread_create'
|
171 | if (! pthread_create(&thread, NULL, itimer_thread_func, (void*)handle_tick)) {
| ^
rts/posix/itimer/Pthread.c:210:0: error:
error: undefined reference to 'pthread_join'
|
210 | if (pthread_join(thread, NULL)) {
| ^
rts/posix/itimer/Pthread.c:173:0: error:
error: undefined reference to 'pthread_setname_np'
|
173 | pthread_setname_np(thread, "ghc_ticker");
| ^
rts/posix/itimer/Pthread.c:214:0: error:
error: undefined reference to 'pthread_detach'
|
214 | pthread_detach(thread);
| ^
includes/rts/OSThreads.h:58:0: error:
error: undefined reference to 'pthread_mutex_trylock'
|
58 | return pthread_mutex_trylock(mutex);
| ^
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [iserv/ghc.mk:72: iserv/stage2/build/tmp/ghc-iserv] Error 1
make[1]: *** Waiting for unfinished jobs....
<<ghc: 755844888 bytes, 149 GCs, 9956929/25185088 avg/max bytes residency (7 samples), 61M in use, 0.000 INIT (0.000 elapsed), 0.853 MUT (1.097 elapsed), 0.495 GC (0.509 elapsed) :ghc>>
<<ghc: 2330135232 bytes, 288 GCs, 19895226/58582272 avg/max bytes residency (9 samples), 155M in use, 0.000 INIT (0.000 elapsed), 2.533 MUT (2.833 elapsed), 1.352 GC (1.362 elapsed) :ghc>>
<<ghc: 8736365112 bytes, 461 GCs, 112580024/575893400 avg/max bytes residency (11 samples), 1191M in use, 0.000 INIT (0.000 elapsed), 4.416 MUT (4.569 elapsed), 7.235 GC (7.250 elapsed) :ghc>>
<<ghc: 15569982136 bytes, 4099 GCs, 61572431/188646672 avg/max bytes residency (20 samples), 454M in use, 0.000 INIT (0.000 elapsed), 9.533 MUT (10.274 elapsed), 6.490 GC (6.536 elapsed) :ghc>>
make: *** [Makefile:127: all] Error 2
```
<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":"AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["AC_CHECK_FUNC,","autoconf,","configure,","nixos"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Code in [[GhcFile(configure.ac)]] incorrectly assesses that pthread functions will be available without explicitly providing `-lpthread` to gcc. This causes the build to fail.\r\n\r\nForcing `need_lpthread=1` in [[GhcFile(configure.ac)]] causes the build to succeed and produce a perfectly functional GHC.\r\n\r\nFrom conversation on #GHC:\r\n\r\n\"It looks like the combination of the following two commits has caused the breakage: e94bfb677298de3c4b4e0d1223fbc589849b79be, c0872bf99ff891e440f118bf9eea20b980c2cfca.[[br]]\r\nThe first makes the configure script check if the `-lpthread` argument is required when building GHC, and the second uses that knowledge at runtime to decide whether to pass `-lpthread` when linking programs. [[br]]\r\nStage 0 builds stage 1 just fine, since it doesn't have these commits and decides whether to pass `-lpthread` based purely on the platform. But the code from the first commit is yielding a false result (I don't know why), so stage 1 fails to build stage 2, since the second commit makes it use the false result to choose not to pass `-lpthread`.\"\r\n\r\nAlso, doesn't determining the need for `-lpthread` like this have problematic implications for cross compilation? Whether `-lpthread` is required could be different between linking GHC and GHC doing linking (e.g. a cross compiler built on a system that does need the flag targeting a system that doesn't.)\r\n\r\nIgnoring that, using AX_PTHREAD or ACX_PTHREAD could potentially help resolve the issue.\r\n\r\nRelevant code from [[GhcFile(configure.ac)]]:\r\n{{{#!bash\r\ndnl Some platforms (e.g. Android's Bionic) have pthreads support available\r\ndnl without linking against libpthread. Check whether -lpthread is necessary\r\ndnl to use pthreads.\r\ndnl\r\ndnl Note that it is important that this happens before we AC_CHECK_LIB(thread)\r\nAC_MSG_CHECKING(whether -lpthread is needed for pthreads)\r\nAC_CHECK_FUNC(pthread_create,\r\n [\r\n AC_MSG_RESULT(no)\r\n need_lpthread=0\r\n ],\r\n [\r\n AC_CHECK_LIB(pthread, pthread_create,\r\n [\r\n AC_MSG_RESULT(yes)\r\n need_lpthread=1\r\n ],\r\n [\r\n AC_MSG_RESULT([no pthreads support found.])\r\n need_lpthread=0\r\n ])\r\n ])\r\nAC_DEFINE_UNQUOTED([NEED_PTHREAD_LIB], [$need_lpthread],\r\n [Define 1 if we need to link code using pthreads with -lpthread])\r\n\r\n}}}\r\n\r\nSystem information:\r\nLinux nixos 4.9.30 x86_64 GNU/Linux\r\n\r\ngcc 5.4.0\r\n\r\nghc 7.10.3\r\n\r\nAttempting to build GHC HEAD fails with \r\n{{{#!bash\r\n...\r\n\"inplace/bin/ghc-stage1\" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O0 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/hsSyn/HsTypes.hs -o compiler/stage2/build/HsTypes.o -dyno compiler/stage2/build/HsTypes.dyn_o\r\n\r\nincludes/rts/OSThreads.h:58:0: error:\r\n error: undefined reference to 'pthread_mutex_trylock'\r\n |\r\n58 | return pthread_mutex_trylock(mutex);\r\n | ^\r\n\r\nincludes/rts/OSThreads.h:58:0: error:\r\n error: undefined reference to 'pthread_mutex_trylock'\r\n |\r\n58 | return pthread_mutex_trylock(mutex);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:137:0: error:\r\n error: undefined reference to 'pthread_create'\r\n |\r\n137 | int result = pthread_create(pId, NULL, (void *(*)(void *))startProc, param);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:139:0: error:\r\n error: undefined reference to 'pthread_detach'\r\n |\r\n139 | pthread_detach(*pId);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:141:0: error:\r\n error: undefined reference to 'pthread_setname_np'\r\n |\r\n141 | pthread_setname_np(*pId, name);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:184:0: error:\r\n error: undefined reference to 'pthread_key_create'\r\n |\r\n184 | if ((r = pthread_key_create(key, NULL)) != 0) {\r\n | ^\r\n\r\nrts/posix/OSThreads.c:203:0: error:\r\n error: undefined reference to 'pthread_setspecific'\r\n |\r\n203 | if ((r = pthread_setspecific(*key,value)) != 0) {\r\n | ^\r\n\r\nrts/posix/OSThreads.c:212:0: error:\r\n error: undefined reference to 'pthread_key_delete'\r\n |\r\n212 | if ((r = pthread_key_delete(*key)) != 0) {\r\n | ^\r\n\r\nrts/posix/OSThreads.c:233:0: error:\r\n error: undefined reference to 'pthread_create'\r\n |\r\n233 | int result = pthread_create(&tid, NULL,\r\n | ^\r\n\r\nrts/posix/OSThreads.c:236:0: error:\r\n error: undefined reference to 'pthread_detach'\r\n |\r\n236 | pthread_detach(tid);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:192:0: error:\r\n error: undefined reference to 'pthread_getspecific'\r\n |\r\n192 | return pthread_getspecific(*key);\r\n | ^\r\n\r\nrts/posix/OSThreads.c:371:0: error:\r\n error: undefined reference to 'pthread_kill'\r\n |\r\n371 | pthread_kill(id, SIGPIPE);\r\n | ^\r\n\r\nrts/posix/itimer/Pthread.c:171:0: error:\r\n error: undefined reference to 'pthread_create'\r\n |\r\n171 | if (! pthread_create(&thread, NULL, itimer_thread_func, (void*)handle_tick)) {\r\n | ^\r\n\r\nrts/posix/itimer/Pthread.c:210:0: error:\r\n error: undefined reference to 'pthread_join'\r\n |\r\n210 | if (pthread_join(thread, NULL)) {\r\n | ^\r\n\r\nrts/posix/itimer/Pthread.c:173:0: error:\r\n error: undefined reference to 'pthread_setname_np'\r\n |\r\n173 | pthread_setname_np(thread, \"ghc_ticker\");\r\n | ^\r\n\r\nrts/posix/itimer/Pthread.c:214:0: error:\r\n error: undefined reference to 'pthread_detach'\r\n |\r\n214 | pthread_detach(thread);\r\n | ^\r\n\r\nincludes/rts/OSThreads.h:58:0: error:\r\n error: undefined reference to 'pthread_mutex_trylock'\r\n |\r\n58 | return pthread_mutex_trylock(mutex);\r\n | ^\r\ncollect2: error: ld returned 1 exit status\r\n`gcc' failed in phase `Linker'. (Exit code: 1)\r\nmake[1]: *** [iserv/ghc.mk:72: iserv/stage2/build/tmp/ghc-iserv] Error 1\r\nmake[1]: *** Waiting for unfinished jobs....\r\n<<ghc: 755844888 bytes, 149 GCs, 9956929/25185088 avg/max bytes residency (7 samples), 61M in use, 0.000 INIT (0.000 elapsed), 0.853 MUT (1.097 elapsed), 0.495 GC (0.509 elapsed) :ghc>>\r\n<<ghc: 2330135232 bytes, 288 GCs, 19895226/58582272 avg/max bytes residency (9 samples), 155M in use, 0.000 INIT (0.000 elapsed), 2.533 MUT (2.833 elapsed), 1.352 GC (1.362 elapsed) :ghc>>\r\n<<ghc: 8736365112 bytes, 461 GCs, 112580024/575893400 avg/max bytes residency (11 samples), 1191M in use, 0.000 INIT (0.000 elapsed), 4.416 MUT (4.569 elapsed), 7.235 GC (7.250 elapsed) :ghc>>\r\n<<ghc: 15569982136 bytes, 4099 GCs, 61572431/188646672 avg/max bytes residency (20 samples), 454M in use, 0.000 INIT (0.000 elapsed), 9.533 MUT (10.274 elapsed), 6.490 GC (6.536 elapsed) :ghc>>\r\nmake: *** [Makefile:127: all] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13934FP_CONVERT_CPU fails to convert CPU when invoked from bindist2019-07-07T18:19:21ZBen GamariFP_CONVERT_CPU fails to convert CPU when invoked from bindistTrying to pass `--target=arm-linux-gnueabihf` to a ARM 8.0.2 bindist's `configure` on my AArch64 box fails with,
```
$ ./configure --prefix=/mnt/ext/arm/roots/ghc/8.0.1-armv7 --target=arm-linux-gnueabihf
checking for path to top of buil...Trying to pass `--target=arm-linux-gnueabihf` to a ARM 8.0.2 bindist's `configure` on my AArch64 box fails with,
```
$ ./configure --prefix=/mnt/ext/arm/roots/ghc/8.0.1-armv7 --target=arm-linux-gnueabihf
checking for path to top of build tree... /mnt/ext/arm/ghc-8.0.2
Build platform inferred as: arm-unknown-linux
Host platform inferred as: arm-unknown-linux
Unknown CPU
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FP_CONVERT_CPU fails to convert CPU when invoked from bindist","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to pass `--target=arm-linux-gnueabihf` to a ARM 8.0.2 bindist's `configure` on my AArch64 box fails with,\r\n{{{\r\n$ ./configure --prefix=/mnt/ext/arm/roots/ghc/8.0.1-armv7 --target=arm-linux-gnueabihf\r\nchecking for path to top of build tree... /mnt/ext/arm/ghc-8.0.2\r\nBuild platform inferred as: arm-unknown-linux\r\nHost platform inferred as: arm-unknown-linux\r\nUnknown CPU\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13916Optimizations create run time seg faults2019-07-07T18:19:30ZistandleetOptimizations create run time seg faultsIn the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough...In the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough, and I must explicitly begin the Bracket module with `{-# OPTIONS_GHC -O0 #-}` -- however, that may be due to stack or some other build tool.
The main logic which fails is in Bracket.hs, which provides an api to convert bracket-like environment handlers (those with open/close capabilities) to caches which you can run concurrent actions against. The API allows two types of limit on the number of concurrent environments - a `Lax` limit, which will spin up additional connections if none are available, and a `Hard` limit, which caps the environment count. This seems like a detail, but if I remove the `Lax` option (as in BracketOneType), the bug goes away. With both options present, both options manifest the bug.
The main.hs module is just a toy program aimed at this api, where we write 1000 lines split to arbitrary files (in a `__dir` specified on the top line - set to tmp). None of this code is important - the actual use case (which fails) is handling multiple concurrent connections to a database.
The other programs (mainList, mainOneModule, and mainOneType) all appear to run correctly, and represent my attempts to create minimal cases. In particular, these respectively replace Vector with List, move all code into a single module, and get rid of the multiple options for cache types. The modules should all be the same modulo imports (or inlining) of different `Bracket` modules.
I have replicated the bug on Linux, Windows, and Windows Creator Update, all with their respective versions of GHC-8.0.2. The code fails for at least vector-0.11.0.0 and vector-0.12.0.1.
NB: There are times with the database access example where, worse than crashing, the program will simply return bad results. I think this might have to do with the laziness of `withEnv`, and our production version uses NFData to deepseq arguments before returning the environment to the cache - that was omitted in this test case for simplicity's sake.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimizations create run time seg faults","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":["optimization"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough, and I must explicitly begin the Bracket module with `{-# OPTIONS_GHC -O0 #-}` -- however, that may be due to stack or some other build tool. \r\n\r\nThe main logic which fails is in Bracket.hs, which provides an api to convert bracket-like environment handlers (those with open/close capabilities) to caches which you can run concurrent actions against. The API allows two types of limit on the number of concurrent environments - a `Lax` limit, which will spin up additional connections if none are available, and a `Hard` limit, which caps the environment count. This seems like a detail, but if I remove the `Lax` option (as in BracketOneType), the bug goes away. With both options present, both options manifest the bug. \r\n\r\nThe main.hs module is just a toy program aimed at this api, where we write 1000 lines split to arbitrary files (in a `__dir` specified on the top line - set to tmp). None of this code is important - the actual use case (which fails) is handling multiple concurrent connections to a database.\r\n\r\nThe other programs (mainList, mainOneModule, and mainOneType) all appear to run correctly, and represent my attempts to create minimal cases. In particular, these respectively replace Vector with List, move all code into a single module, and get rid of the multiple options for cache types. The modules should all be the same modulo imports (or inlining) of different `Bracket` modules.\r\n\r\nI have replicated the bug on Linux, Windows, and Windows Creator Update, all with their respective versions of GHC-8.0.2. The code fails for at least vector-0.11.0.0 and vector-0.12.0.1.\r\n\r\nNB: There are times with the database access example where, worse than crashing, the program will simply return bad results. I think this might have to do with the laziness of `withEnv`, and our production version uses NFData to deepseq arguments before returning the environment to the cache - that was omitted in this test case for simplicity's sake. ","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13915GHC 8.2 regression: "Can't find interface-file declaration" for promoted data...2019-07-07T18:19:30ZRyan ScottGHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instanceDue to #12088, you can't define a data family instance and promote it in the same module. One could, up until GHC 8.2, work around this using (somewhat obscure) wisdom: define the data family instance in a separate module from where it's...Due to #12088, you can't define a data family instance and promote it in the same module. One could, up until GHC 8.2, work around this using (somewhat obscure) wisdom: define the data family instance in a separate module from where it's promoted. For example, `Bug` typechecks in GHC 8.0.1 and 8.0.2:
```hs
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family T a
data instance T Int = MkT
```
```hs
{-# LANGUAGE TypeInType #-}
module Bug where
import Foo
data Proxy (a :: k)
data S = MkS (Proxy 'MkT)
```
However, this stopped typechecking in GHC 8.2:
```
$ /opt/ghc/8.2.1/bin/ghci Bug.hs
GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 2] Compiling Foo ( Foo.hs, interpreted )
[2 of 2] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:1:1: error:
Can't find interface-file declaration for variable Foo.$tc'MkT
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
|
1 | {-# LANGUAGE TypeInType #-}
| ^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.2 regression: \"Can't find interface-file declaration\" for promoted data family instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":["TypeFamilies","TypeInType,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Due to #12088, you can't define a data family instance and promote it in the same module. One could, up until GHC 8.2, work around this using (somewhat obscure) wisdom: define the data family instance in a separate module from where it's promoted. For example, `Bug` typechecks in GHC 8.0.1 and 8.0.2:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Foo where\r\n\r\ndata family T a\r\ndata instance T Int = MkT\r\n}}}\r\n{{{#!hs\r\n{-# LANGUAGE TypeInType #-}\r\nmodule Bug where\r\n\r\nimport Foo\r\n\r\ndata Proxy (a :: k)\r\ndata S = MkS (Proxy 'MkT)\r\n}}}\r\n\r\nHowever, this stopped typechecking in GHC 8.2:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghci Bug.hs\r\nGHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 2] Compiling Foo ( Foo.hs, interpreted )\r\n[2 of 2] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:1:1: error:\r\n Can't find interface-file declaration for variable Foo.$tc'MkT\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n |\r\n1 | {-# LANGUAGE TypeInType #-}\r\n | ^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13899Improve [-Wmissing-home-modules] error message2019-07-07T18:19:35ZAlan ZimmermanImprove [-Wmissing-home-modules] error messageAt the moment when this warning is triggered, GHC emits something like
```hs
<no location info>: warning: [-Wmissing-home-modules]
Modules are not listed in command line: Language.Haskell.GHC.ExactPrint
```
It is not clear that thi...At the moment when this warning is triggered, GHC emits something like
```hs
<no location info>: warning: [-Wmissing-home-modules]
Modules are not listed in command line: Language.Haskell.GHC.ExactPrint
```
It is not clear that this is actually reporting a problem in the cabal file which has incomplete "other-modules" for one or other target.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improve [-Wmissing-home-modules] error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"At the moment when this warning is triggered, GHC emits something like\r\n\r\n{{{#!hs\r\n<no location info>: warning: [-Wmissing-home-modules]\r\n Modules are not listed in command line: Language.Haskell.GHC.ExactPrint\r\n}}}\r\n\r\nIt is not clear that this is actually reporting a problem in the cabal file which has incomplete \"other-modules\" for one or other target.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13894isByteArrayPinned# should consider BF_LARGE2022-11-18T13:57:09ZwinterisByteArrayPinned# should consider BF_LARGEFirst of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` ...First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).
Currently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c\#L33](https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33) to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"isByteArrayPinned# should consider BF_LARGE","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray#/MutableByteArray#' is movable during safe FFI call, isn't it?\r\n\r\nIf that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).\r\n\r\nCurrently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33] to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.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 Akentev