GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-06T20:42:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15287T11627[ab] fail on some Darwin environments2024-03-06T20:42:17ZBen GamariT11627[ab] fail on some Darwin environmentsAs of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!):
```
Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 )
Stderr ( T...As of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!):
```
Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 )
Stderr ( T11627b ):
/bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS
*** unexpected failure for T11627b(prof_hr)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"T11627[ab] fail on some Darwin environments","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":"Bug","description":"As of d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!):\r\n{{{\r\nWrong exit code for T11627b(prof_hr)(expected 0 , actual 139 )\r\nStderr ( T11627b ):\r\n/bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS\r\n*** unexpected failure for T11627b(prof_hr)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15661Nullary constraint in GHCi breaks `:t` command2024-01-21T16:33:56ZtaktoaNullary constraint in GHCi breaks `:t` commandIf you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing ...If you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing the type.
Expected output:
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XFlexibleContexts
Prelude> data Foo = Foo
Prelude> let x :: (Show Foo) => () ; x = ()
Prelude> :t x
x :: Show Foo => ()
```
Actual output:
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XFlexibleContexts
Prelude> data Foo = Foo
Prelude> let x :: (Show Foo) => () ; x = ()
Prelude> :t x
<interactive>:1:1: error:
No instance for (Show Foo) arising from a use of ‘x’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nullary constraint in GHCi breaks `:t` command","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing the type.\r\n\r\nExpected output:\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XFlexibleContexts\r\nPrelude> data Foo = Foo\r\nPrelude> let x :: (Show Foo) => () ; x = ()\r\nPrelude> :t x\r\nx :: Show Foo => ()\r\n}}}\r\n\r\nActual output:\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XFlexibleContexts\r\nPrelude> data Foo = Foo\r\nPrelude> let x :: (Show Foo) => () ; x = ()\r\nPrelude> :t x\r\n\r\n<interactive>:1:1: error:\r\n No instance for (Show Foo) arising from a use of ‘x’\r\n}}}\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15290QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar"2024-01-11T02:06:42ZRichard Eisenbergrae@richarde.devQuantifiedConstraints: panic "addTcEvBind NoEvBindsVar"I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:
```hs
{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}
module Bug where
import Prelude hiding ( Monad(..) )
import Da...I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:
```hs
{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}
module Bug where
import Prelude hiding ( Monad(..) )
import Data.Coerce ( Coercible )
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a
newtype StateT s m a = StateT { runStateT :: s -> m (s, a) }
instance Monad m => Monad (StateT s m) where
ma >>= fmb = StateT $ \s -> runStateT ma s >>= \(s1, a) -> runStateT (fmb a) s1
join ssa = StateT $ \s -> runStateT ssa s >>= \(s, sa) -> runStateT sa s
newtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a }
deriving instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m)
```
This looks like it should be accepted. But I get
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180617 for x86_64-apple-darwin):
addTcEvBind NoEvBindsVar
[G] df_a67k
= \ (@ p_a62C) (@ q_a62D) (v_B1 :: Coercible p_a62C q_a62D) ->
coercible_sel
@ *
@ (m_a64Z[ssk:1] p_a62C)
@ (m_a64Z[ssk:1] q_a62D)
(df_a651 @ p_a62C @ q_a62D v_B1)
a67c
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"QuantifiedConstraints: panic \"addTcEvBind NoEvBindsVar\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}\r\n\r\nmodule Bug where\r\n\r\nimport Prelude hiding ( Monad(..) )\r\nimport Data.Coerce ( Coercible )\r\n\r\nclass Monad m where\r\n (>>=) :: m a -> (a -> m b) -> m b\r\n join :: m (m a) -> m a\r\n\r\nnewtype StateT s m a = StateT { runStateT :: s -> m (s, a) }\r\n\r\ninstance Monad m => Monad (StateT s m) where\r\n ma >>= fmb = StateT $ \\s -> runStateT ma s >>= \\(s1, a) -> runStateT (fmb a) s1\r\n join ssa = StateT $ \\s -> runStateT ssa s >>= \\(s, sa) -> runStateT sa s\r\n\r\nnewtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a }\r\n\r\nderiving instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m)\r\n\r\n}}}\r\n\r\nThis looks like it should be accepted. But I get\r\n\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180617 for x86_64-apple-darwin):\r\n\taddTcEvBind NoEvBindsVar\r\n [G] df_a67k\r\n = \\ (@ p_a62C) (@ q_a62D) (v_B1 :: Coercible p_a62C q_a62D) ->\r\n coercible_sel\r\n @ *\r\n @ (m_a64Z[ssk:1] p_a62C)\r\n @ (m_a64Z[ssk:1] q_a62D)\r\n (df_a651 @ p_a62C @ q_a62D v_B1)\r\n a67c\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15226GHC doesn't know that seq# produces something in WHNF2023-12-18T14:30:21ZDavid FeuerGHC doesn't know that seq# produces something in WHNF```hs
data Str a = Str !a
bar :: Maybe a -> IO (Str (Maybe a))
bar x = do
x' <- evaluate x
pure (Str x')
```
This compiles to
```hs
Test.bar1
= \ (@ a_a3Ld)
(x_a3Ah :: Maybe a_a3Ld)
(s_i3Nz :: GHC.Prim.State# GHC.Prim...```hs
data Str a = Str !a
bar :: Maybe a -> IO (Str (Maybe a))
bar x = do
x' <- evaluate x
pure (Str x')
```
This compiles to
```hs
Test.bar1
= \ (@ a_a3Ld)
(x_a3Ah :: Maybe a_a3Ld)
(s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.seq#
@ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz
of
{ (# ipv_i3NC, ipv1_i3ND #) ->
(# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #)
}
```
We suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining
```hs
evaluate x = IO $ \s ->
case seq# x s of
(# s', !x' #) -> (# s', x' #)
```
but that seems more than a little bit silly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC doesn't know that seq# produces something in WHNF","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":["simonmar"],"type":"Bug","description":"{{{#!hs\r\ndata Str a = Str !a\r\nbar :: Maybe a -> IO (Str (Maybe a))\r\nbar x = do\r\n x' <- evaluate x\r\n pure (Str x')\r\n}}}\r\n\r\nThis compiles to\r\n\r\n{{{#!hs\r\nTest.bar1\r\n = \\ (@ a_a3Ld)\r\n (x_a3Ah :: Maybe a_a3Ld)\r\n (s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n case GHC.Prim.seq#\r\n @ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz\r\n of\r\n { (# ipv_i3NC, ipv1_i3ND #) ->\r\n (# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #)\r\n }\r\n}}}\r\n\r\nWe suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining\r\n\r\n{{{#!hs\r\nevaluate x = IO $ \\s ->\r\n case seq# x s of\r\n (# s', !x' #) -> (# s', x' #)\r\n}}}\r\n\r\nbut that seems more than a little bit silly.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15631Lost opportunity to eliminate seq2023-12-13T16:16:12ZSimon Peyton JonesLost opportunity to eliminate seqConsider this:
```
f xs = let ys = reverse xs in
ys `seq` length xs +
length (reverse (case ys of { a:as -> as; [] -> [] }))
```
We end up with this
```
Foo.$wf
= \ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) ->
(1) c...Consider this:
```
f xs = let ys = reverse xs in
ys `seq` length xs +
length (reverse (case ys of { a:as -> as; [] -> [] }))
```
We end up with this
```
Foo.$wf
= \ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) ->
(1) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0)
of ys_ap9 { __DEFAULT ->
case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0#
of ww2_a49t { __DEFAULT ->
(2) case ys_ap9 of {
[] ->
case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 ->
GHC.Prim.+# ww2_a49t v1_B2
};
: a1_aK8 as_aK9 ->
case GHC.List.$wlenAcc
@ a_s4a0
(GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0))
0#
of ww1_X49V
{ __DEFAULT ->
GHC.Prim.+# ww2_a49t ww1_X49V
} } } }
```
The case expression (1) is the `seq` on ys. The case marked (2) is the
case analysis in the argument of the second `reverse`.
But that first `seq` is redundant! We could equally well say
```
Foo.$wf
= \ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) ->
case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0#
of ww2_a49t { __DEFAULT ->
(2) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0) of {
[] ->
case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 ->
GHC.Prim.+# ww2_a49t v1_B2
};
: a1_aK8 as_aK9 ->
case GHC.List.$wlenAcc
@ a_s4a0
(GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0))
0#
of ww1_X49V
{ __DEFAULT ->
GHC.Prim.+# ww2_a49t ww1_X49V
} } } }
```
That's better because we generate code for only two evals rather than three.
The general pattern is
```
case <scrut> of b { DEFAULT -> <body> }
==>
let b = <scrut> in <body>
```
where the case binder `b` is used strictly in `<body>`. In this case it's
safe to switch to a `let` (marked as strict) which can now be inlined
or floated in a way that `case` expressions cannot.
We already do this transformation, here in `Simplify.rebuildCase`:
```
rebuildCase env scrut case_bndr alts@[(_, bndrs, rhs)] cont
...
| all_dead_bndrs
, if isUnliftedType (idType case_bndr)
then exprOkForSpeculation scrut
else exprIsHNF scrut || scrut_is_demanded_var scrut
= ...turn case into let...
```
The key bit (for this situation) is `scrut_is_demanded_var`.
**But it only fires if `<scrut>` is a variable**.
I see no reason for this restriction. I think it's sound
regardless. Yes, if we decide to inline the binding `b = <scrut>` we
might change which exception appears; but that is within the semantics
of exceptions; and it's still true if `<scrut>` is a variable.
So I think we can safely replace `scrut_is_demand_var` with just
`case_bndr_is_demanded`, independent of what `scrut` looks like.
I dug back into ghc history to see how the current code came about, bu it had a long evolution and I didn't find any reason for sticking to a variable here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"Lost opportunity to eliminate seq","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":"Bug","description":"Consider this:\r\n{{{\r\nf xs = let ys = reverse xs in\r\n ys `seq` length xs +\r\n length (reverse (case ys of { a:as -> as; [] -> [] }))\r\n}}}\r\nWe end up with this\r\n{{{\r\nFoo.$wf\r\n = \\ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) ->\r\n(1) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0)\r\n of ys_ap9 { __DEFAULT ->\r\n case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0#\r\n of ww2_a49t { __DEFAULT ->\r\n(2) case ys_ap9 of {\r\n [] ->\r\n case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 ->\r\n GHC.Prim.+# ww2_a49t v1_B2\r\n };\r\n : a1_aK8 as_aK9 ->\r\n case GHC.List.$wlenAcc\r\n @ a_s4a0\r\n (GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0))\r\n 0#\r\n of ww1_X49V\r\n { __DEFAULT ->\r\n GHC.Prim.+# ww2_a49t ww1_X49V\r\n } } } }\r\n}}}\r\nThe case expression (1) is the `seq` on ys. The case marked (2) is the\r\ncase analysis in the argument of the second `reverse`.\r\n\r\nBut that first `seq` is redundant! We could equally well say\r\n{{{\r\nFoo.$wf\r\n = \\ (@ a_s4a0) (w_s4a1 :: [a_s4a0]) ->\r\n case GHC.List.$wlenAcc @ a_s4a0 w_s4a1 0#\r\n of ww2_a49t { __DEFAULT ->\r\n(2) case GHC.List.reverse1 @ a_s4a0 w_s4a1 (GHC.Types.[] @ a_s4a0) of {\r\n [] ->\r\n case Foo.f1 @ a_s4a0 of { GHC.Types.I# v1_B2 ->\r\n GHC.Prim.+# ww2_a49t v1_B2\r\n };\r\n : a1_aK8 as_aK9 ->\r\n case GHC.List.$wlenAcc\r\n @ a_s4a0\r\n (GHC.List.reverse1 @ a_s4a0 as_aK9 (GHC.Types.[] @ a_s4a0))\r\n 0#\r\n of ww1_X49V\r\n { __DEFAULT ->\r\n GHC.Prim.+# ww2_a49t ww1_X49V\r\n } } } }\r\n}}}\r\nThat's better because we generate code for only two evals rather than three.\r\n\r\nThe general pattern is\r\n{{{\r\n case <scrut> of b { DEFAULT -> <body> }\r\n==>\r\n let b = <scrut> in <body>\r\n}}}\r\nwhere the case binder `b` is used strictly in `<body>`. In this case it's\r\nsafe to switch to a `let` (marked as strict) which can now be inlined\r\nor floated in a way that `case` expressions cannot.\r\n\r\nWe already do this transformation, here in `Simplify.rebuildCase`:\r\n{{{\r\nrebuildCase env scrut case_bndr alts@[(_, bndrs, rhs)] cont\r\n...\r\n | all_dead_bndrs\r\n , if isUnliftedType (idType case_bndr)\r\n then exprOkForSpeculation scrut\r\n else exprIsHNF scrut || scrut_is_demanded_var scrut\r\n = ...turn case into let...\r\n}}}\r\nThe key bit (for this situation) is `scrut_is_demanded_var`.\r\n'''But it only fires if `<scrut>` is a variable'''.\r\n\r\nI see no reason for this restriction. I think it's sound\r\nregardless. Yes, if we decide to inline the binding `b = <scrut>` we\r\nmight change which exception appears; but that is within the semantics\r\nof exceptions; and it's still true if `<scrut>` is a variable.\r\n\r\nSo I think we can safely replace `scrut_is_demand_var` with just\r\n`case_bndr_is_demanded`, independent of what `scrut` looks like.\r\n\r\nI dug back into ghc history to see how the current code came about, bu it had a long evolution and I didn't find any reason for sticking to a variable here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15485GHC uses 300% CPU when calling into blocking C call2023-12-01T13:50:01ZoconnoreGHC uses 300% CPU when calling into blocking C callHello,
I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:
```hs
lockPwd f = bracket main recover (\_ -> f)
where
mode = unionFileModes ownerReadMode ownerWriteMode
...Hello,
I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:
```hs
lockPwd f = bracket main recover (\_ -> f)
where
mode = unionFileModes ownerReadMode ownerWriteMode
main = do
fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags
putStrLn "waiting to set lock"
waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0)
putStrLn "got lock"
return fd
recover = flip setLock (Unlock, AbsoluteSeek, 0, 0)
```
When I run it, my fans go wild, and CPU usage hits 300%.
/u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/
> Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket.
Maybe an argument could be made that this waitToSetLock call should be converted to be [interruptible](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#interruptible-foreign-calls), but it also seems like I should be able to make my haskell program block patiently if I want it to.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| 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":"GHC uses 300% CPU when calling into blocking C call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nI'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:\r\n\r\n{{{#!hs\r\nlockPwd f = bracket main recover (\\_ -> f)\r\n where\r\n mode = unionFileModes ownerReadMode ownerWriteMode\r\n main = do\r\n fd <- openFd \"/etc/.pwd.lock\" WriteOnly (Just mode) defaultFileFlags\r\n putStrLn \"waiting to set lock\"\r\n waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0)\r\n putStrLn \"got lock\"\r\n return fd\r\n recover = flip setLock (Unlock, AbsoluteSeek, 0, 0)\r\n}}}\r\n\r\nWhen I run it, my fans go wild, and CPU usage hits 300%.\r\n\r\n/u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/\r\n\r\n> Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is \"descheduled\" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket.\r\n\r\nMaybe an argument could be made that this waitToSetLock call should be converted to be [[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#interruptible-foreign-calls|interruptible]], but it also seems like I should be able to make my haskell program block patiently if I want it to. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10915Statistical profiling support in the RTS2023-11-25T22:03:34ZBen GamariStatistical profiling support in the RTSNow since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on exter...Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack.
A more feasible alternative is to incorporate a simple statistical profiler into the RTS.
Profiling is defined loosely here as the collection of information describing the current state of evaluation in response to certain triggers. In practice this will be the collection of the current symbol being evaluated triggered on a few events of interest,
- Memory allocation
- Periodic timers for time-based profiling
- Blackhole blocking for locating performance problems due to sharing in parallel programs8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11260Re-compilation driver/recomp11 test fails2023-10-20T08:03:16ZPeter Trommlerptrommler@acm.orgRe-compilation driver/recomp11 test failsrecomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```recomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15108Panic: collectNBinders2023-09-01T12:15:47ZcdisselkoenPanic: collectNBindersGHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists.
Steps to reproduce:
`stack.yaml`:
```
resolver...GHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists.
Steps to reproduce:
`stack.yaml`:
```
resolver: nightly-2018-04-30
```
`bug.cabal`:
```
name: bug
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
executable bug
main-is: Main.hs
build-depends: base
default-language: Haskell2010
```
`Main.hs`:
```
module Main where
main :: IO ()
main = do
_ <- return $ getInt Circle
return ()
newtype MyInt = MyInt Int
data Shape = Circle
| Square
getInt :: Shape -> MyInt
getInt sh =
case sh of
Circle ->
let (MyInt i) = MyInt 3
in myInt i
Square ->
let (MyInt i) = MyInt 2
in myInt i
where
myInt = MyInt
```
Then run:
```
$ stack ghc -- --version
The Glorious Glasgow Haskell Compilation System, version 8.4.2
$ stack build --profile
bug-0.1.0.0: configure (exe)
Configuring bug-0.1.0.0...
bug-0.1.0.0: build (exe)
Preprocessing executable 'bug' for bug-0.1.0.0..
Building executable 'bug' for bug-0.1.0.0..
[1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.2 for x86_64-unknown-linux):
collectNBinders
1
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in ghc:CoreSyn
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building custom Setup.hs for package bug-0.1.0.0 using:
/usr/local/home/cdisselk/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build exe:bug --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/4879Deprecate exports (in modules)2023-08-18T13:53:25ZbasvandijkDeprecate exports (in modules)*Since this was originally written, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst was created and approved formalizing the feature we want. The rest of this is subsumed by that...*Since this was originally written, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst was created and approved formalizing the feature we want. The rest of this is subsumed by that and just for historical interest.*
------
## Motivation
During the library submission process there's sometimes the desire to have the ability to deprecate an export from a module.
For example [during the discussing](http://article.gmane.org/gmane.comp.lang.haskell.libraries/14524) about ticket #4422, I would have liked the ability to deprecate the exports of the `String` functions: `lines`, `words`, `unlines` and `unwords` from `Data.List` in favour of importing them from `Data.String`. However I wasn't able to do so, so these exports remain.
Similarly, [during the discussion](http://article.gmane.org/gmane.comp.lang.haskell.libraries/14925) about ticket #4865, Ian also desired to deprecate the export of `catch` from `System.IO.Error` but was unable to do so.
## Syntax
To deprecate an export simply place a `DEPRECATE` pragma for the export inside the export list, as in:
```
module Data.List
( ...
{-# DEPRECATE lines "Exported from Data.String instead" #-}
, lines
...
) where
...
```
Another design might be to have a different pragma as in:
```
{-# DEPRECATE_EXPORT lines "Exported from Data.String instead" #-}
```
But I find the former much prettier and more obvious.
## Semantics
If the `lines` export from `Data.List` is deprecated the following should raise deprecation warnings:
- Directly importing a deprecated export:
```
import Data.List (lines)
```
- Referring to a deprecated export:
```
import Data.List
foo = lines
```
If you import the same symbol from different modules and only some of them are deprecated exports then referring to the symbol won't give a deprecation warning. For example the following should not give deprecation warnings:
```
import Data.List
import Data.String
foo = lines
```
### What exports can be deprecated?
- Functions.
- Types.
- Classes.
- Constructors. Possible syntax:
```
module A
( {-# DEPRECATE T(C1) "The export of C1 is deprecated" #-}
T(C1, C2, C3)
) where
```
- Modules. Possible syntax:
```
module A
( {-# DEPRECATE module B "The export of module B is deprecated" #-}
module B
) where
```
The semantics of deprecating a module export is that you get deprecation warnings for all symbols from module `B` that you refer to inside a module that imports `A`. (Does that make sense?)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deprecate exports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"== Motivation ==\r\nDuring the library submission process there's sometimes the desire to have the ability to deprecate an export from a module.\r\n\r\nFor example [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14524 during the discussing] about ticket #4422, I would have liked the ability to deprecate the exports of the `String` functions: `lines`, `words`, `unlines` and `unwords` from `Data.List` in favour of importing them from `Data.String`. However I wasn't able to do so, so these exports remain.\r\n\r\nSimilarly, [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14925 during the discussion] about ticket #4865, Ian also desired to deprecate the export of `catch` from `System.IO.Error` but was unable to do so.\r\n\r\n== Syntax ==\r\n\r\nTo deprecate an export simply place a `DEPRECATE` pragma for the export inside the export list, as in: \r\n\r\n{{{\r\nmodule Data.List\r\n ( ...\r\n {-# DEPRECATE lines \"Exported from Data.String instead\" #-}\r\n , lines\r\n ...\r\n ) where\r\n...\r\n}}}\r\n\r\nAnother design might be to have a different pragma as in:\r\n\r\n{{{\r\n{-# DEPRECATE_EXPORT lines \"Exported from Data.String instead\" #-}\r\n}}}\r\n\r\nBut I find the former much prettier and more obvious.\r\n\r\n== Semantics ==\r\n\r\nIf the `lines` export from `Data.List` is deprecated the following should raise deprecation warnings:\r\n\r\n * Directly importing a deprecated export:\r\n{{{\r\nimport Data.List (lines)\r\n}}}\r\n\r\n * Referring to a deprecated export:\r\n{{{\r\nimport Data.List\r\nfoo = lines\r\n}}}\r\n\r\nIf you import the same symbol from different modules and only some of them are deprecated exports then referring to the symbol won't give a deprecation warning. For example the following should not give deprecation warnings:\r\n\r\n{{{\r\nimport Data.List\r\nimport Data.String\r\nfoo = lines\r\n}}}\r\n\r\n=== What exports can be deprecated? ===\r\n\r\n * Functions.\r\n * Types.\r\n * Classes.\r\n * Constructors. Possible syntax:\r\n{{{\r\nmodule A\r\n ( {-# DEPRECATE T(C1) \"The export of C1 is deprecated\" #-}\r\n T(C1, C2, C3)\r\n ) where\r\n}}}\r\n * Modules. Possible syntax:\r\n{{{\r\nmodule A\r\n ( {-# DEPRECATE module B \"The export of module B is deprecated\" #-}\r\n module B\r\n ) where\r\n}}}\r\nThe semantics of deprecating a module export is that you get deprecation warnings for all symbols from module `B` that you refer to inside a module that imports `A`. (Does that make sense?)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14335Plugins don't work with -fexternal-interpreter2023-08-08T13:45:03ZBen GamariPlugins don't work with -fexternal-interpreterPlugins don't work with -fexternal-interpreter.
The current plan to fix this is to enable GHC to always use the internal interpreter for plugins, even when `-fexternal-interpreter` is given. `-fexternal-interpreter` only determines whic...Plugins don't work with -fexternal-interpreter.
The current plan to fix this is to enable GHC to always use the internal interpreter for plugins, even when `-fexternal-interpreter` is given. `-fexternal-interpreter` only determines which interpreter is used for running Template Haskell splices. The following tasks have been identified:
- [X] Support loading two different `UnitState` (available units): one for the target, one for plugins
- [ ] Add command-line flags (`-plugin-package-db`, etc.) to build the plugins UnitState
- [ ] Refactor many functions to explicitly pass Platform configuration (Platform, ways, etc.) as arguments. Currently we often pass `DynFlags` and callee functions implicitly use the `UnitState` of the target platform. It doesn't compose well and we want to be explicit about the platform we are using (target or host) (see also #17957).
- [x] Pretty-printing of `Unit` (via its `Outputable` instance) implicitly queries the `UnitState` of the target platform (via `sdocWithDynFlags`). We need to remove this `Outputable` instance.8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10189explicit promotions of prefix data constructors can't be parsed naturally2023-06-16T21:25:26Zshiatsumatexplicit promotions of prefix data constructors can't be parsed naturallyWhen used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the c...When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor.
On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.)
I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax.
In a GHCi:
```hs
> :set -XDataKinds -XTypeOperators
> data a :* b = a :* b
> :kind! Int :* Int
Int :* Int :: *
= Int :* Int
> :kind! Int ':* Int
Int ':* Int :: * :* *
= Int ':* Int
> :kind! (:*)
(:*) :: * -> * -> *
= (:*)
> :kind! '(:*)
'(:*) :: k -> k1 -> k :* k1
= forall (k :: BOX) (k :: BOX). (':*)
> :kind! (':*)
<interactive>:1:3: parse error on input ‘:*’
```8.6.1shiatsumatshiatsumathttps://gitlab.haskell.org/ghc/ghc/-/issues/12218Implement -fexternal-interpreter via static linking2023-06-13T08:00:25ZSimon MarlowImplement -fexternal-interpreter via static linkingAn interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH ...An interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15650Add (or document if already exist) ability to derive custom typeclasses via s...2023-06-09T09:15:40ZDmitrii KovanikovAdd (or document if already exist) ability to derive custom typeclasses via source plugins## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using ...## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:
```hs
data Bar = Bar | Baz
deriving (Eq, Ord, Foo)
```
There're already two possible ways to derive instances of custom typeclasses:
1. `anyclass` deriving strategy (usually involves `Generic`)
1. `-XTemplateHaskell` solution.
But I would like to have source-plugin-based solution for this problem so I can just add `-fplugin=Foo.Plugin` and enjoy deriving capabilities.
## Advantage over existing approaches
Solution with `-XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/th-abstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:
```hs
{-# LANGUAGE TemplateHaskell #-}
data Bar = Bar | Baz
deriving (Eq, Ord)
deriveFoo ''Bar
```
Solution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like *parsing CLI arguments* but it's more important if you want to have efficient binary serialisation.
Also, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1-beta1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add (or document if already exist) ability to derive custom typeclasses via source plugins","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1-beta1","keywords":["plugins,deriving,typeclass","source"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"== Problem\r\n\r\nSuppose, I have some custom typeclass `Foo` defined in some library `foo`:\r\n\r\n{{{#!hs\r\nclass Foo a where\r\n ... some methods ...\r\n}}}\r\n\r\nI would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:\r\n\r\n{{{#!hs\r\ndata Bar = Bar | Baz\r\n deriving (Eq, Ord, Foo)\r\n}}}\r\n\r\nThere're already two possible ways to derive instances of custom typeclasses:\r\n\r\n1. `anyclass` deriving strategy (usually involves `Generic`)\r\n2. `-XTemplateHaskell` solution.\r\n\r\nBut I would like to have source-plugin-based solution for this problem so I can just add `-fplugin=Foo.Plugin` and enjoy deriving capabilities.\r\n\r\n== Advantage over existing approaches\r\n\r\nSolution with `-XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/th-abstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\ndata Bar = Bar | Baz\r\n deriving (Eq, Ord)\r\n\r\nderiveFoo ''Bar\r\n}}}\r\n\r\nSolution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like ''parsing CLI arguments'' but it's more important if you want to have efficient binary serialisation. \r\n\r\nAlso, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15523GHC Panic on malformed newtype and StrictData2023-04-26T17:43:47ZrdnettoGHC Panic on malformed newtype and StrictDataThe following source causes a panic:
```hs
{-# LANGUAGE StrictData #-}
module Main where
newtype Duration = Foo
data Literal = LitDuration Duration
```
Result:
```
[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/...The following source causes a panic:
```hs
{-# LANGUAGE StrictData #-}
module Main where
newtype Duration = Foo
data Literal = LitDuration Duration
```
Result:
```
[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
mkNewTyConRhs
Foo []
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
If we remove the StrictData pragma, then we get a syntax error as expected:
```
/home/reuben/tcalc/src/Main.hs:3:20: error:
• The constructor of a newtype must have exactly one field
but ‘Foo’ has none
• In the definition of data constructor ‘Foo’
In the newtype declaration for ‘Duration’
|
3 | newtype Duration = Foo
| ^^^
```
I was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected.
A test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC Panic on malformed newtype and StrictData","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":"Bug","description":"The following source causes a panic:\r\n{{{#!hs\r\n{-# LANGUAGE StrictData #-}\r\n\r\nmodule Main where\r\n\r\nnewtype Duration = Foo\r\ndata Literal = LitDuration Duration\r\n}}}\r\n\r\nResult:\r\n{{{\r\n[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n mkNewTyConRhs\r\n Foo []\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nIf we remove the StrictData pragma, then we get a syntax error as expected:\r\n{{{\r\n/home/reuben/tcalc/src/Main.hs:3:20: error:\r\n • The constructor of a newtype must have exactly one field\r\n but ‘Foo’ has none\r\n • In the definition of data constructor ‘Foo’\r\n In the newtype declaration for ‘Duration’\r\n |\r\n3 | newtype Duration = Foo\r\n | ^^^\r\n}}}\r\n\r\nI was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected.\r\n\r\nA test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15541package environment files and the GHC API2023-03-21T12:06:34Zlspitznerpackage environment files and the GHC APIThe GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for th...The GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"package environment files and the GHC API","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["environment","package"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC API respects package environment files, which is not documented and was not announced.\r\n\r\nI consider this to be at least a severe documentation bug.\r\n\r\nAfaik this goes back to ghc-8.0.\r\n\r\n#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14078-ddump-json doesn't work well with GHCi2023-02-14T16:58:08Zdramforever-ddump-json doesn't work well with GHCiCurrently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit.
However, I believe this completely defeats the purpose ...Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit.
However, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused.
This proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely.
Reporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump-json` and `:set -ddump-json`. Sorry if it was not warranted.
## Steps to reproduce
`cmd>` is the shell prompt.
```hs
cmd> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.1
cmd> type tmp.hs
main = print 2 + 2
cmd> ghci -ddump-json tmp.hs
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( tmp.hs, interpreted )
tmp.hs:1:8: error:
? No instance for (Num (IO ())) arising from a use of ‘+’
? In the expression: print 2 + 2
In an equation for ‘main’: main = print 2 + 2
|
1 | main = print 2 + 2
| ^^^^^^^^^^^
Failed, 0 modules loaded.
Prelude> :q
Leaving GHCi.
[]
cmd> ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -ddump-json
Prelude> :l tmp.hs
[1 of 1] Compiling Main ( tmp.hs, interpreted )
tmp.hs:1:8: error:
? No instance for (Num (IO ())) arising from a use of ‘+’
? In the expression: print 2 + 2
In an equation for ‘main’: main = print 2 + 2
|
1 | main = print 2 + 2
| ^^^^^^^^^^^
Failed, 0 modules loaded.
Prelude> :q
Leaving GHCi.
[
{"span": {"file": "tmp.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 19},"doc": "\u2022 No instance for (Num (IO ())) arising from a use of \u2018+\u2019\n\u2022 In the expression: print 2 + 2\n In an equation for \u2018main\u2019: main = print 2 + 2","severity": "SevError","reason": null},
{"span": null,"doc": "[1 of 1] Compiling Main ( tmp.hs, interpreted )","severity": "SevOutput","reason": null}]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-ddump-json doesn't work well with GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit.\r\n\r\nHowever, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused. \r\n\r\nThis proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely.\r\n\r\nReporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump-json` and `:set -ddump-json`. Sorry if it was not warranted.\r\n\r\n== Steps to reproduce\r\n\r\n`cmd>` is the shell prompt.\r\n\r\n{{{#!hs\r\n\r\ncmd> ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.1\r\n\r\ncmd> type tmp.hs\r\nmain = print 2 + 2\r\n\r\ncmd> ghci -ddump-json tmp.hs\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( tmp.hs, interpreted )\r\n\r\ntmp.hs:1:8: error:\r\n ? No instance for (Num (IO ())) arising from a use of ‘+’\r\n ? In the expression: print 2 + 2\r\n In an equation for ‘main’: main = print 2 + 2\r\n |\r\n1 | main = print 2 + 2\r\n | ^^^^^^^^^^^\r\nFailed, 0 modules loaded.\r\nPrelude> :q\r\nLeaving GHCi.\r\n[]\r\n\r\ncmd> ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -ddump-json\r\nPrelude> :l tmp.hs\r\n[1 of 1] Compiling Main ( tmp.hs, interpreted )\r\n\r\ntmp.hs:1:8: error:\r\n ? No instance for (Num (IO ())) arising from a use of ‘+’\r\n ? In the expression: print 2 + 2\r\n In an equation for ‘main’: main = print 2 + 2\r\n |\r\n1 | main = print 2 + 2\r\n | ^^^^^^^^^^^\r\nFailed, 0 modules loaded.\r\nPrelude> :q\r\nLeaving GHCi.\r\n[\r\n {\"span\": {\"file\": \"tmp.hs\",\"startLine\": 1,\"startCol\": 8,\"endLine\": 1,\"endCol\": 19},\"doc\": \"\\u2022 No instance for (Num (IO ())) arising from a use of \\u2018+\\u2019\\n\\u2022 In the expression: print 2 + 2\\n In an equation for \\u2018main\\u2019: main = print 2 + 2\",\"severity\": \"SevError\",\"reason\": null},\r\n\r\n {\"span\": null,\"doc\": \"[1 of 1] Compiling Main ( tmp.hs, interpreted )\",\"severity\": \"SevOutput\",\"reason\": null}]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12669Add some weird Kmettian tests to the test suite2023-01-22T04:01:20ZDavid FeuerAdd some weird Kmettian tests to the test suite`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` an...`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` and `#` to stick raw `MutArr#` pointers into arrays. I believe Kmett also uses `unsafeCoerce# reallyUnsafePtrEquality#` to compare pointers of kind `#` to others (of possibly different types).
None of these things are anything like officially supported. However, breaking them could be expensive for the ecosystem. Dealing with breakage when someone discovers it months later can be very hard, so I think some of these things should probably be added to the GHC test suite. Failures shouldn't categorically prevent changes from being merged, but they would provide an early warning and get conversations started earlier.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add some weird Kmettian tests to the test suite","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"FeatureRequest","description":"`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` and `#` to stick raw `MutArr#` pointers into arrays. I believe Kmett also uses `unsafeCoerce# reallyUnsafePtrEquality#` to compare pointers of kind `#` to others (of possibly different types).\r\n\r\nNone of these things are anything like officially supported. However, breaking them could be expensive for the ecosystem. Dealing with breakage when someone discovers it months later can be very hard, so I think some of these things should probably be added to the GHC test suite. Failures shouldn't categorically prevent changes from being merged, but they would provide an early warning and get conversations started earlier.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/8281The impossible happened: primRepToFFIType2023-01-20T21:12:40ZtibbeThe impossible happened: primRepToFFITypeI ran into this error while trying to use GHCi on the hashable package:
```
$ cabal repl
Preprocessing library hashable-1.2.0.10...
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... d...I ran into this error while trying to use GHCi on the hashable package:
```
$ cabal repl
Preprocessing library hashable-1.2.0.10...
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading object (static) dist/build/cbits/fnv.o ... done
Loading object (static) dist/build/cbits/getRandomBytes.o ... done
final link ... done
[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]
[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-apple-darwin):
primRepToFFIType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"The impossible happened: primRepToFFIType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran into this error while trying to use GHCi on the hashable package:\r\n\r\n{{{\r\n$ cabal repl\r\nPreprocessing library hashable-1.2.0.10...\r\nGHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.4.0.1 ... linking ... done.\r\nLoading package deepseq-1.3.0.1 ... linking ... done.\r\nLoading package bytestring-0.10.0.2 ... linking ... done.\r\nLoading package text-0.11.3.1 ... linking ... done.\r\nLoading object (static) dist/build/cbits/fnv.o ... done\r\nLoading object (static) dist/build/cbits/getRandomBytes.o ... done\r\nfinal link ... done\r\n[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]\r\n[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.2 for x86_64-apple-darwin):\r\n\tprimRepToFFIType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15689s390x builds flood with -Wunused-label warnings2023-01-18T15:42:57ZJens Petersens390x builds flood with -Wunused-label warningsThis has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.
For example this build: https://k...This has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.
For example this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=29940997 (note the logs are only kept for 2 weeks)
The build.log is 11MB and this is just for compiling less than half of ghc-cabal (270 modules), which generated around 50k unused-label warnings!! So you can imagine the size of a full build.
(Well ghc-8.2.2.69.fc29 full build.log was "only" 33MB for s390x vs 8.8MB for x86_64.)
For now I patched warnings.mk on s390x to workaround this, but it would be better to fix the root cause I suppose.
Here is a small part of the buildlog:
```
"/usr/bin/ghc" -H32m -O -Wall \
-optc-Wall -optc-fno-stack-protector \
\
-hide-all-packages \
-package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \
--make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \
-no-user-package-db \
-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
-DCABAL_VERSION=2,2,0,1 \
-DCABAL_PARSEC \
-DBOOTSTRAPPING \
-odir bootstrapping \
-hidir bootstrapping \
libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \
-ilibraries/Cabal/Cabal \
-ilibraries/binary/src \
-ilibraries/filepath \
-ilibraries/hpc \
-ilibraries/mtl \
-ilibraries/text \
libraries/text/cbits/cbits.c \
-Ilibraries/text/include \
-ilibraries/parsec/src \
\
"rm" -f compiler/stage1/build/Config.hs
Creating compiler/stage1/build/Config.hs ...
done.
"rm" -f utils/ghc-pkg/dist/build/Version.hs
echo "module Version where" >> utils/ghc-pkg/dist/build/Version.hs
echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist/build/Version.hs
echo "version = \"8.4.3\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetOS = \"linux\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetARCH = \"s390x\"" >> utils/ghc-pkg/dist/build/Version.hs
[ 1 of 270] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o )
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:16:1: error:
warning: label ‘_c3bA’ defined but not used [-Wunused-label]
_c3bA:
^~~~~
|
16 | _c3bA:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bx_entry’:
/tmp/ghc705e_0/ghc_130.hc:34:1: error:
warning: label ‘_c3bx’ defined but not used [-Wunused-label]
_c3bx:
^~~~~
|
34 | _c3bx:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_callCC_entry’:
/tmp/ghc705e_0/ghc_130.hc:54:1: error:
warning: label ‘_c3bO’ defined but not used [-Wunused-label]
_c3bO:
^~~~~
|
54 | _c3bO:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bL_entry’:
/tmp/ghc705e_0/ghc_130.hc:72:1: error:
warning: label ‘_c3bL’ defined but not used [-Wunused-label]
_c3bL:
^~~~~
|
72 | _c3bL:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38I_entry’:
/tmp/ghc705e_0/ghc_130.hc:98:1: error:
warning: label ‘_c3ca’ defined but not used [-Wunused-label]
_c3ca:
^~~~~
|
98 | _c3ca:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38J_entry’:
/tmp/ghc705e_0/ghc_130.hc:125:1: error:
warning: label ‘_c3cf’ defined but not used [-Wunused-label]
_c3cf:
^~~~~
|
125 | _c3cf:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT1_entry’:
/tmp/ghc705e_0/ghc_130.hc:152:1: error:
warning: label ‘_c3ck’ defined but not used [-Wunused-label]
_c3ck:
^~~~~
|
152 | _c3ck:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38M_entry’:
/tmp/ghc705e_0/ghc_130.hc:181:1: error:
warning: label ‘_c3cx’ defined but not used [-Wunused-label]
_c3cx:
^~~~~
|
181 | _c3cx:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorTzuzdcp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:206:1: error:
warning: label ‘_c3cA’ defined but not used [-Wunused-label]
_c3cA:
^~~~~
|
206 | _c3cA:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Q_entry’:
/tmp/ghc705e_0/ghc_130.hc:235:1: error:
warning: label ‘_c3cO’ defined but not used [-Wunused-label]
_c3cO:
^~~~~
|
235 | _c3cO:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38P_entry’:
/tmp/ghc705e_0/ghc_130.hc:257:1: error:
warning: label ‘_c3cV’ defined but not used [-Wunused-label]
_c3cV:
^~~~~
|
257 | _c3cV:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT_entry’:
/tmp/ghc705e_0/ghc_130.hc:285:1: error:
warning: label ‘_c3cZ’ defined but not used [-Wunused-label]
_c3cZ:
^~~~~
|
285 | _c3cZ:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38W_entry’:
/tmp/ghc705e_0/ghc_130.hc:323:1: error:
warning: label ‘_c3dj’ defined but not used [-Wunused-label]
_c3dj:
^~~~~
|
323 | _c3dj:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38X_entry’:
/tmp/ghc705e_0/ghc_130.hc:350:1: error:
warning: label ‘_c3do’ defined but not used [-Wunused-label]
_c3do:
^~~~~
|
350 | _c3do:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptT1_entry’:
/tmp/ghc705e_0/ghc_130.hc:377:1: error:
warning: label ‘_c3dt’ defined but not used [-Wunused-label]
_c3dt:
^~~~~
|
377 | _c3dt:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Z_entry’:
/tmp/ghc705e_0/ghc_130.hc:411:1: error:
warning: label ‘_c3dG’ defined but not used [-Wunused-label]
_c3dG:
^~~~~
|
411 | _c3dG:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptTzuzdcp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:435:1: error:
warning: label ‘_c3dJ’ defined but not used [-Wunused-label]
_c3dJ:
^~~~~
|
435 | _c3dJ:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s392_entry’:
/tmp/ghc705e_0/ghc_130.hc:462:1: error:
warning: label ‘_c3dX’ defined but not used [-Wunused-label]
_c3dX:
^~~~~
|
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.6.1 |
| 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":"s390x builds flood with -Wunused-label warnings","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.\r\n\r\nFor example this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=29940997 (note the logs are only kept for 2 weeks)\r\nThe build.log is 11MB and this is just for compiling less than half of ghc-cabal (270 modules), which generated around 50k unused-label warnings!! So you can imagine the size of a full build.\r\n\r\n(Well ghc-8.2.2.69.fc29 full build.log was \"only\" 33MB for s390x vs 8.8MB for x86_64.)\r\n\r\nFor now I patched warnings.mk on s390x to workaround this, but it would be better to fix the root cause I suppose.\r\n\r\nHere is a small part of the buildlog:\r\n\r\n{{{\r\n\"/usr/bin/ghc\" -H32m -O -Wall \\\r\n -optc-Wall -optc-fno-stack-protector \\\r\n \\\r\n -hide-all-packages \\\r\n -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \\\r\n --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \\\r\n -no-user-package-db \\\r\n -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \\\r\n -DCABAL_VERSION=2,2,0,1 \\\r\n -DCABAL_PARSEC \\\r\n -DBOOTSTRAPPING \\\r\n -odir bootstrapping \\\r\n -hidir bootstrapping \\\r\n libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \\\r\n -ilibraries/Cabal/Cabal \\\r\n -ilibraries/binary/src \\\r\n -ilibraries/filepath \\\r\n -ilibraries/hpc \\\r\n -ilibraries/mtl \\\r\n -ilibraries/text \\\r\n libraries/text/cbits/cbits.c \\\r\n -Ilibraries/text/include \\\r\n -ilibraries/parsec/src \\\r\n \\\r\n \r\n\"rm\" -f compiler/stage1/build/Config.hs \r\nCreating compiler/stage1/build/Config.hs ... \r\ndone.\r\n\"rm\" -f utils/ghc-pkg/dist/build/Version.hs \r\necho \"module Version where\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version, targetOS, targetARCH :: String\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version = \\\"8.4.3\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetOS = \\\"linux\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetARCH = \\\"s390x\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\n[ 1 of 270] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o )\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:16:1: error:\r\n warning: label ‘_c3bA’ defined but not used [-Wunused-label]\r\n _c3bA:\r\n ^~~~~\r\n |\r\n16 | _c3bA:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bx_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:34:1: error:\r\n warning: label ‘_c3bx’ defined but not used [-Wunused-label]\r\n _c3bx:\r\n ^~~~~\r\n |\r\n34 | _c3bx:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_callCC_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:54:1: error:\r\n warning: label ‘_c3bO’ defined but not used [-Wunused-label]\r\n _c3bO:\r\n ^~~~~\r\n |\r\n54 | _c3bO:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bL_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:72:1: error:\r\n warning: label ‘_c3bL’ defined but not used [-Wunused-label]\r\n _c3bL:\r\n ^~~~~\r\n |\r\n72 | _c3bL:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38I_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:98:1: error:\r\n warning: label ‘_c3ca’ defined but not used [-Wunused-label]\r\n _c3ca:\r\n ^~~~~\r\n |\r\n98 | _c3ca:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38J_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:125:1: error:\r\n warning: label ‘_c3cf’ defined but not used [-Wunused-label]\r\n _c3cf:\r\n ^~~~~\r\n |\r\n125 | _c3cf:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT1_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:152:1: error:\r\n warning: label ‘_c3ck’ defined but not used [-Wunused-label]\r\n _c3ck:\r\n ^~~~~\r\n |\r\n152 | _c3ck:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38M_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:181:1: error:\r\n warning: label ‘_c3cx’ defined but not used [-Wunused-label]\r\n _c3cx:\r\n ^~~~~\r\n |\r\n181 | _c3cx:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorTzuzdcp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:206:1: error:\r\n warning: label ‘_c3cA’ defined but not used [-Wunused-label]\r\n _c3cA:\r\n ^~~~~\r\n |\r\n206 | _c3cA:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Q_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:235:1: error:\r\n warning: label ‘_c3cO’ defined but not used [-Wunused-label]\r\n _c3cO:\r\n ^~~~~\r\n |\r\n235 | _c3cO:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38P_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:257:1: error:\r\n warning: label ‘_c3cV’ defined but not used [-Wunused-label]\r\n _c3cV:\r\n ^~~~~\r\n |\r\n257 | _c3cV:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:285:1: error:\r\n warning: label ‘_c3cZ’ defined but not used [-Wunused-label]\r\n _c3cZ:\r\n ^~~~~\r\n |\r\n285 | _c3cZ:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38W_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:323:1: error:\r\n warning: label ‘_c3dj’ defined but not used [-Wunused-label]\r\n _c3dj:\r\n ^~~~~\r\n |\r\n323 | _c3dj:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38X_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:350:1: error:\r\n warning: label ‘_c3do’ defined but not used [-Wunused-label]\r\n _c3do:\r\n ^~~~~\r\n |\r\n350 | _c3do:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptT1_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:377:1: error:\r\n warning: label ‘_c3dt’ defined but not used [-Wunused-label]\r\n _c3dt:\r\n ^~~~~\r\n |\r\n377 | _c3dt:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Z_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:411:1: error:\r\n warning: label ‘_c3dG’ defined but not used [-Wunused-label]\r\n _c3dG:\r\n ^~~~~\r\n |\r\n411 | _c3dG:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptTzuzdcp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:435:1: error:\r\n warning: label ‘_c3dJ’ defined but not used [-Wunused-label]\r\n _c3dJ:\r\n ^~~~~\r\n |\r\n435 | _c3dJ:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s392_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:462:1: error:\r\n warning: label ‘_c3dX’ defined but not used [-Wunused-label]\r\n _c3dX:\r\n ^~~~~\r\n |\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1