GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:05Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15142GHC HEAD regression: tcTyVarDetails2019-07-07T18:14:05ZRyan ScottGHC HEAD regression: tcTyVarDetailsThis regression prevents the `generic-lens` library from building. Here is a minimized test case:
```hs
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
module Bug where
import Data.Kind
...This regression prevents the `generic-lens` library from building. Here is a minimized test case:
```hs
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
module Bug where
import Data.Kind
class ListTuple (tuple :: Type) (as :: [(k, Type)]) where
type ListToTuple as :: Type
```
On GHC 8.4.2, this compiles, but on GHC HEAD, it panics:
```
$ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180511 for x86_64-unknown-linux):
tcTyVarDetails
co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *)
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression: tcTyVarDetails","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeFamilies","TypeInType,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This regression prevents the `generic-lens` library from building. Here is a minimized test case:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\nclass ListTuple (tuple :: Type) (as :: [(k, Type)]) where\r\n type ListToTuple as :: Type\r\n}}}\r\n\r\nOn GHC 8.4.2, this compiles, but on GHC HEAD, it panics:\r\n\r\n{{{\r\n$ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180511 for x86_64-unknown-linux):\r\n tcTyVarDetails\r\n co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *)\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable\r\n pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15136High CPU when asynchronous exception and unblocking retry on TVar raced2019-07-07T18:14:07ZnshimazaHigh CPU when asynchronous exception and unblocking retry on TVar racedDetail: https://github.com/nshimaza/race-tmvar-async-exception
Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar.
- Reproduces with +RTS -Nx where x \> 1
- Does NOT reproduce with +...Detail: https://github.com/nshimaza/race-tmvar-async-exception
Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar.
- Reproduces with +RTS -Nx where x \> 1
- Does NOT reproduce with +RTS -N1
- Program stalls at `killThread`
- High CPU based on given -Nx
- CPU won't be 100% if you gave x smaller than available hardware threads of your platform.
- Does NOT reproduce if TVar/retry is replaced by MVar
- Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4))
- Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65)
- Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce-mac65)
Minimal reproducing code here. (You can find more verbose code on the above github repo.)
```hs
main :: IO ()
main = do
let volume = 1000
forM_ [1..1000] $ \i -> do
putStrFlush $ show i ++ " "
-- Spawn massive number of threads.
threads <- replicateM volume $ do
trigger <- newTVarIO False
tid <- forkIO $ void $ atomically $ do
t <- readTVar trigger
if t then pure t else retry
pure (trigger, tid)
-- Make sure all threads are spawned.
threadDelay 30000
-- Let threads start to exit normally.
forkIO $ forM_ threads $ \(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True)
-- Concurrently kill threads in order to create race.
-- TMVar operation and asynchronous exception can hit same thread simultaneously.
-- Adjust threadDelay if you don't reproduce very well.
threadDelay 1000
forM_ threads $ \(_, tid) -> do
putCharFlush 'A'
killThread tid -- When the issue reproduced, this killThread doesn't return.
putCharFlush '\b'
```
This program intentionally creates race condition between asynchronous exception
and unblocking operation of `retry` on TVar. From one side, a `writeTVar
trigger True` is attempted from external thread while target thread is blocking
at `retry` on the same `TVar`. On the other side, an asynchronous exception
`ThreadKilled` is thrown by yet another external thread to the same target
thread.
In other word, it attempts to kill a thread about to unblock.
I guess when the above two operation hit the same thread at the same time in
parallel in SMP environment, GHC runtime falls into high CPU.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"High CPU when asynchronous exception and unblocking retry on TVar raced","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Detail: https://github.com/nshimaza/race-tmvar-async-exception\r\n\r\nRuntime falls into high CPU under racing condition between async exception and unblocking retry on TVar.\r\n\r\n* Reproduces with +RTS -Nx where x > 1\r\n* Does NOT reproduce with +RTS -N1\r\n* Program stalls at `killThread`\r\n* High CPU based on given -Nx\r\n * CPU won't be 100% if you gave x smaller than available hardware threads of your platform.\r\n* Does NOT reproduce if TVar/retry is replaced by MVar\r\n* Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4))\r\n* Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65)\r\n* Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce-mac65)\r\n\r\n\r\nMinimal reproducing code here. (You can find more verbose code on the above github repo.)\r\n{{{#!hs\r\nmain :: IO ()\r\nmain = do\r\n let volume = 1000\r\n forM_ [1..1000] $ \\i -> do\r\n putStrFlush $ show i ++ \" \"\r\n\r\n -- Spawn massive number of threads.\r\n threads <- replicateM volume $ do\r\n trigger <- newTVarIO False\r\n tid <- forkIO $ void $ atomically $ do\r\n t <- readTVar trigger\r\n if t then pure t else retry\r\n pure (trigger, tid)\r\n\r\n -- Make sure all threads are spawned.\r\n threadDelay 30000\r\n\r\n -- Let threads start to exit normally.\r\n forkIO $ forM_ threads $ \\(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True)\r\n\r\n -- Concurrently kill threads in order to create race.\r\n -- TMVar operation and asynchronous exception can hit same thread simultaneously.\r\n -- Adjust threadDelay if you don't reproduce very well.\r\n threadDelay 1000\r\n forM_ threads $ \\(_, tid) -> do\r\n putCharFlush 'A'\r\n killThread tid -- When the issue reproduced, this killThread doesn't return.\r\n putCharFlush '\\b'\r\n}}}\r\n\r\nThis program intentionally creates race condition between asynchronous exception\r\nand unblocking operation of `retry` on TVar. From one side, a `writeTVar\r\ntrigger True` is attempted from external thread while target thread is blocking\r\nat `retry` on the same `TVar`. On the other side, an asynchronous exception\r\n`ThreadKilled` is thrown by yet another external thread to the same target\r\nthread.\r\n\r\nIn other word, it attempts to kill a thread about to unblock.\r\n\r\nI guess when the above two operation hit the same thread at the same time in\r\nparallel in SMP environment, GHC runtime falls into high CPU.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15122GHC HEAD typechecker regression2019-07-07T18:14:10ZfmixingGHC HEAD typechecker regressionThis code, distilled from the `type-level-sets` library:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeO...This code, distilled from the `type-level-sets` library:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module Bug where
data Proxy (p :: k) = Proxy
data Set (n :: [k]) where
Empty :: Set '[]
Ext :: e -> Set s -> Set (e ': s)
type family (m :: [k]) :\ (x :: k) :: [k] where
'[] :\ x = '[]
(x ': xs) :\ x = xs
(y ': xs) :\ x = y ': (xs :\ x)
class Remove s t where
remove :: Set s -> Proxy t -> Set (s :\ t)
instance Remove '[] t where
remove Empty Proxy = Empty
instance {-# OVERLAPS #-} Remove (x ': xs) x where
remove (Ext _ xs) Proxy = xs
instance {-# OVERLAPPABLE #-} (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x)
=> Remove (y ': xs) x where
remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
```
Typechecks in GHC 8.4.2, but not in GHC HEAD:
```
$ /opt/ghc/head/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:31:33: error:
• Could not deduce: ((e : s) :\ x) ~ (e : (s :\ x))
from the context: (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x)
bound by the instance declaration at Bug.hs:(29,31)-(30,27)
or from: (k ~ *, (y : xs :: [k]) ~~ (e : s :: [*]))
bound by a pattern with constructor:
Ext :: forall e (s :: [*]). e -> Set s -> Set (e : s),
in an equation for ‘remove’
at Bug.hs:31:11-18
Expected type: Set ((y : xs) :\ x)
Actual type: Set (e : (s :\ x))
• In the expression: Ext y (remove xs x)
In an equation for ‘remove’:
remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
In the instance declaration for ‘Remove (y : xs) x’
• Relevant bindings include
x :: Proxy x (bound at Bug.hs:31:22)
xs :: Set s (bound at Bug.hs:31:17)
y :: e (bound at Bug.hs:31:15)
remove :: Set (y : xs) -> Proxy x -> Set ((y : xs) :\ x)
(bound at Bug.hs:31:3)
|
31 | remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
| ^^^^^^^^^^^^^^^^^^^
```
This regression was introduced in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.).8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15112ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'2021-10-03T00:49:22Zelaforgeghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'```
% cat Nopie.hs
module Nopie where
main :: IO ()
main = putStrLn "hi"
% ghc -fforce-recomp -c -fhpc Nopie.hs
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unuse...```
% cat Nopie.hs
module Nopie where
main :: IO ()
main = putStrLn "hi"
% ghc -fforce-recomp -c -fhpc Nopie.hs
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
```
This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output.
Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n% cat Nopie.hs\r\nmodule Nopie where\r\n\r\nmain :: IO ()\r\nmain = putStrLn \"hi\"\r\n% ghc -fforce-recomp -c -fhpc Nopie.hs\r\nclang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]\r\nclang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]\r\n}}}\r\n\r\nThis happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output.\r\n\r\nIncidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15061print022 testcase fails on i3862019-07-07T18:14:27ZBen Gamariprint022 testcase fails on i386CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr....CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised 2018-04-19 13:53:47.685662431 +0000
@@ -0,0 +1 @@
+*** Exception: Prelude.chr: bad argument: 1493110744
*** unexpected failure for print022(ghci)
```
This is a bit frightening as it suggests that there is memory unsafety here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"print022 testcase fails on i386","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,\r\n{{{\r\nActual stderr output differs from expected:\r\n--- /dev/null\t2018-04-18 16:05:23.479353000 +0000\r\n+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised\t2018-04-19 13:53:47.685662431 +0000\r\n@@ -0,0 +1 @@\r\n+*** Exception: Prelude.chr: bad argument: 1493110744\r\n*** unexpected failure for print022(ghci)\r\n}}}\r\n\r\nThis is a bit frightening as it suggests that there is memory unsafety here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15051-split-objs generates excessively many files on Windows2019-07-07T18:14:32Zkanetw-split-objs generates excessively many files on WindowsA BuildFlavour = perf build generated \~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.
<detail...A BuildFlavour = perf build generated \~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"-split-objs generates excessively many files on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"A BuildFlavour = perf build generated ~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/14808GHC HEAD regression: GADT constructors no longer quantify tyvars in topologic...2019-07-07T18:15:30ZRyan ScottGHC HEAD regression: GADT constructors no longer quantify tyvars in topological orderOriginally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f...Originally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f :: [()] -> ECC () [] ()
f = ECC @() @[] @()
```
Typechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:12:5: error:
• Couldn't match type ‘()’ with ‘[]’
Expected type: [()] -> ECC (() :: Constraint) [] ()
Actual type: () [] -> ECC (() :: Constraint) () []
• In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^^^^^^^^^^^^^^
Bug.hs:12:10: error:
• Expected kind ‘* -> *’, but ‘()’ has kind ‘*’
• In the type ‘()’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
Bug.hs:12:14: error:
• Expecting one more argument to ‘[]’
Expected a type, but ‘[]’ has kind ‘* -> *’
• In the type ‘[]’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
```
This is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's
```
$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (ctx :: Constraint) (f :: * -> *) a.
ctx =>
f a -> ECC ctx f a
```
In GHC HEAD, however, it's:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (f :: * -> *) a (ctx :: Constraint).
ctx =>
f a -> ECC ctx f a
```
This regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"Originally noticed in #14796. This program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeApplications #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata ECC ctx f a where\r\n ECC :: ctx => f a -> ECC ctx f a\r\n\r\nf :: [()] -> ECC () [] ()\r\nf = ECC @() @[] @()\r\n}}}\r\n\r\nTypechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:12:5: error:\r\n • Couldn't match type ‘()’ with ‘[]’\r\n Expected type: [()] -> ECC (() :: Constraint) [] ()\r\n Actual type: () [] -> ECC (() :: Constraint) () []\r\n • In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^^^^^^^^^^^^^^\r\n\r\nBug.hs:12:10: error:\r\n • Expected kind ‘* -> *’, but ‘()’ has kind ‘*’\r\n • In the type ‘()’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n\r\nBug.hs:12:14: error:\r\n • Expecting one more argument to ‘[]’\r\n Expected a type, but ‘[]’ has kind ‘* -> *’\r\n • In the type ‘[]’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n}}}\r\n\r\nThis is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's\r\n\r\n{{{\r\n$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.4.0.20180209: 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\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (ctx :: Constraint) (f :: * -> *) a.\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nIn GHC HEAD, however, it's:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.5.20180213: 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\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (f :: * -> *) a (ctx :: Constraint).\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nThis regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/14737Improve performance of Simplify.simplCast2019-09-23T07:37:55ZTobias Dammerstdammers@gmail.comImprove performance of Simplify.simplCastSplitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs](https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs), `simplCast` eats up more execution time than we ...Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs](https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs), `simplCast` eats up more execution time than we think it should.
From [https://ghc.haskell.org/trac/ghc/ticket/11735\#comment:10](https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10):
> Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given
>
> ```
> (fun |> co) @t1 @t2 ... @tn
> ```
>
> we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`.
>
> Solution: gather up those type arguments (easy) and define
>
> ```
> pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion)
> ```
And [https://ghc.haskell.org/trac/ghc/ticket/11735\#comment:41](https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41):
> OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen.
>
> Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions.
>
> This should be an easy win all around.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire, simonpj, tdammers |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improve performance of Simplify.simplCast","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire","simonpj","tdammers"],"type":"Bug","description":"Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs], `simplCast` eats up more execution time than we think it should.\r\n\r\nFrom [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10]:\r\n\r\n> Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given\r\n> {{{\r\n> (fun |> co) @t1 @t2 ... @tn\r\n> }}}\r\n> we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`.\r\n> \r\n> Solution: gather up those type arguments (easy) and define\r\n> {{{\r\n> pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion)\r\n> }}}\r\n\r\nAnd [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41]:\r\n\r\n> OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen.\r\n> \r\n> Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions.\r\n> \r\n> This should be an easy win all around.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/143468.2.1 regression: heap corruption after safe foreign calls2022-07-06T16:47:17Zandrewchen8.2.1 regression: heap corruption after safe foreign callsTest case: (compile with ghc 8.2.1 and -threaded option)
```haskell
module Main where
import Control.Concurrent
import Control.Monad
import Data.Word
import Foreign.Marshal.Alloc
import Foreign.Ptr
import Foreign.Storable
foreign impo...Test case: (compile with ghc 8.2.1 and -threaded option)
```haskell
module Main where
import Control.Concurrent
import Control.Monad
import Data.Word
import Foreign.Marshal.Alloc
import Foreign.Ptr
import Foreign.Storable
foreign import ccall safe "test"
c_test :: Ptr Word32 -> IO ()
main :: IO ()
main = do
replicateM_ 1000 $ threadDelay 1000
_ <- forkIO $ forever $ threadDelay 100
allocaBytes 4 $ \p -> forever $ do
c_test p
x <- peek p
unless (x == 0xDEADBEEF) $ putStrLn "value mismatch"
```
```c
void test(unsigned int *buf) {
*buf = 0xDEADBEEF;
}
```
On my machine, it detects a few value mismatches before crashing with sigsegv.
```
$ time ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug
value mismatch
value mismatch
value mismatch
value mismatch
zsh: segmentation fault (core dumped) ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug
./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug 2.11s user 0.25s system 66% cpu 3.543 total
```
I believe this is what is causing crashes in xmobar. See discussion: https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar still happens without -threaded option, while this example only breaks when compiled with -threaded.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"8.2.1 regression: heap corruption after safe foreign calls","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case: (compile with ghc 8.2.1 and -threaded option)\r\n{{{#!haskell\r\nmodule Main where\r\n\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Data.Word\r\nimport Foreign.Marshal.Alloc\r\nimport Foreign.Ptr\r\nimport Foreign.Storable\r\n\r\nforeign import ccall safe \"test\"\r\n c_test :: Ptr Word32 -> IO ()\r\n\r\nmain :: IO ()\r\nmain = do\r\n replicateM_ 1000 $ threadDelay 1000\r\n _ <- forkIO $ forever $ threadDelay 100\r\n allocaBytes 4 $ \\p -> forever $ do\r\n c_test p\r\n x <- peek p\r\n unless (x == 0xDEADBEEF) $ putStrLn \"value mismatch\"\r\n}}}\r\n{{{#!c\r\nvoid test(unsigned int *buf) {\r\n *buf = 0xDEADBEEF;\r\n}\r\n}}}\r\n\r\nOn my machine, it detects a few value mismatches before crashing with sigsegv.\r\n{{{\r\n$ time ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug\r\nvalue mismatch\r\nvalue mismatch\r\nvalue mismatch\r\nvalue mismatch\r\nzsh: segmentation fault (core dumped) ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug\r\n./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug 2.11s user 0.25s system 66% cpu 3.543 total\r\n}}}\r\n\r\nI believe this is what is causing crashes in xmobar. See discussion: https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar still happens without -threaded option, while this example only breaks when compiled with -threaded.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13900Core lint in BuildFlavour=perf-llvm2019-07-07T18:19:35ZBen GamariCore lint in BuildFlavour=perf-llvmI found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm` and `GhcStage2HcOpts += -dcore-lint -dcmm-lint`,
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsu...I found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm` and `GhcStage2HcOpts += -dcore-lint -dcmm-lint`,
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -package-id time-1.8.0.1 -package-id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O2 -dcore-lint -dcmm-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI/Tags.hs -o ghc/stage2/build/GHCi/UI/Tags.dyn_o
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of $wgo_XtpE :: [Name]
-> Session
-> State# RealWorld
-> (# State# RealWorld, [[TagInfo]] #)]
Rule "SC:$wgo0": lhs type: (# State# RealWorld, [[TagInfo]] #)
rhs type: (# State# RealWorld, [Maybe TyThing] #)
*** Offending Program ***
(see attached)
```8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11786Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep l...2020-03-16T15:44:12ZSimon Peyton JonesNeed -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaksAfter #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:
```
:info ($)
Prelude> :i ($)
($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).
(a -> b) -> a ->...After #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:
```
:info ($)
Prelude> :i ($)
($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).
(a -> b) -> a -> b
-- Defined in ‘GHC.Base’
```
This happens because the runtime-rep-suppression happens on `Type`, but for `:info` we use `pprInfo` which uses `tyThingToIfaceDecl` and then prints it. And `tyThingToIfaceDecl` doesn't know about the `-fprint-explicit-runtime-reps` flag; and I'd like to keep it that way.
We want to change `pprType` to convert to `IfaceType` and then print anyway.
I suppose that this means that the pretty-printer for `IfaceType` needs to know about this runtime-rep suppression. That's a bit tiresome, but not impossible, especially since there is no shadowing to worry about.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:\r\n{{{\r\n:info ($)\r\nPrelude> :i ($)\r\n($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).\r\n (a -> b) -> a -> b\r\n \t-- Defined in ‘GHC.Base’\r\n}}}\r\nThis happens because the runtime-rep-suppression happens on `Type`, but for `:info` we use `pprInfo` which uses `tyThingToIfaceDecl` and then prints it. And `tyThingToIfaceDecl` doesn't know about the `-fprint-explicit-runtime-reps` flag; and I'd like to keep it that way.\r\n\r\nWe want to change `pprType` to convert to `IfaceType` and then print anyway.\r\n\r\nI suppose that this means that the pretty-printer for `IfaceType` needs to know about this runtime-rep suppression. That's a bit tiresome, but not impossible, especially since there is no shadowing to worry about.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15390Figure out why CircleCI isn't generating haddocks2019-07-07T18:12:51ZBen GamariFigure out why CircleCI isn't generating haddocks<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"Figure out why CircleCI isn't generating haddocks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15300Unboxed Sums Crash2019-07-07T18:13:22ZAndrew MartinUnboxed Sums CrashI've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC ...I've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC 8.4.3), do the following:
```
git clone https://github.com/andrewthad/packed
cd packed
cabal new-build
```
We use `cabal new-build` for its side effect of creating a `.ghc.environment.xyz` file. Now, create a minimal example in the directory called `eol.hs` with the following contents:
```hs
import Packed.Bytes.Parser (Parser)
import Data.Word
import Packed.Bytes (Bytes)
import GHC.Exts (RealWorld)
import Packed.Bytes.Stream.IO (ByteStream)
import qualified Packed.Bytes as B
import qualified Data.Char
import qualified Packed.Bytes.Parser as P
import qualified Packed.Bytes.Stream.IO as Stream
main :: IO ()
main = do
r <- runExampleParser
( do P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
) (foldMap Stream.singleton (map charToWord8 "the\nemporium\rhas\narrived"))
print r
runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, Maybe String)
runExampleParser parser stream = do
P.Result mleftovers r _ <- P.parseStreamIO stream () parser
mextra <- case mleftovers of
Nothing -> return Nothing
Just (P.Leftovers chunk remainingStream) -> do
bs <- Stream.unpack remainingStream
return (Just (map word8ToChar (B.unpack chunk ++ bs)))
return (either (const Nothing) Just r,mextra)
word8ToChar :: Word8 -> Char
word8ToChar = Data.Char.chr . fromIntegral
charToWord8 :: Char -> Word8
charToWord8 = fromIntegral . Data.Char.ord
s2b :: String -> Bytes
s2b = B.pack . map charToWord8
c2w :: Char -> Word8
c2w = charToWord8
```
Finally, build this with `ghc -O2 eol.hs`, and then run the executable this produces to get the following:
```
(Nothing,Just "\rhas\narrived")
eol: internal error: stg_ap_n_ret
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Things worth noting:
1. I think the program fails in the final GC that runs right before the program terminates. We can see that it produces a correct result of `(Nothing,Just "\rhas\narrived")`, but something on the heap has definitely been corrupted.
1. This only happens with `-O2` turned on.
1. This only happens when the parser does not successfully parse its input.
Here's some more context around this. I've been working on a parser that uses unboxed sums instead of continuations. After #15038 was fixed, everything had been going well. Then, I took the parser type and added two things to it: (1) context and (2) typed errors. Context is basically like throwing `StateT` on top and errors are like throwing `ExceptT` on top. After this, everything in my test suite kept working except for a single test, which now consistently crashes my test suite. So, I originally had this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Maybe# a #)
newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# s r a #)
}
```
But I changed it to this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Either# a (b :: TYPE r) = (# a | b #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# e c s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Either# (Maybe e) a, c #)
newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
c
-> Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# e c s r a #)
}
```
Specifically, the function causing trouble is (as currently defined):
```hs
{-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-}
takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes#
takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) where
go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s BytesRep Bytes# #)
go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c #) #)
go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# off0) (I# len0) 10 13 (ByteArray arr0) of
Nothing -> case streamFunc s0 of
(# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1
Just (I# ix, W8# theByte) -> case theByte of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
-- second case means it was 13
_ -> case ix <# (off0 +# len0 -# 1#) of
1# -> case indexWord8Array# arr0 (ix +# 1# ) of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 #) #), (# Nothing | #), c #) #)
_ -> case nextNonEmpty stream0 s0 of
(# s1, m #) -> case m of
(# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton 13), Stream.empty #) #), (# Nothing | #), c #) #)
(# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case indexWord8Array# arr1 0# of
10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes bytes1)), stream1 #) #), (# Nothing | #), c #) #)
```
That's all I've got for now. If no one's able to make headway, I'll probably come back to this and try to make a more minimal example at some point. I won't have time to do this soon though.8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/14416CI with CircleCI2019-07-07T18:17:07ZManuel M T ChakravartyCI with CircleCIMerging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- |...Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CI with CircleCI","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamari