GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:20:47Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13652Add integer division to GHC.TypeLits2019-07-07T18:20:47ZAlexey VagarenkoAdd integer division to GHC.TypeLitsGHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level:
```hs
quot
rem
div
mod
quotRem
divMod
```
?
<details><summary>Trac...GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level:
```hs
quot
rem
div
mod
quotRem
divMod
```
?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.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":"Add integer division to GHC.TypeLits","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level:\r\n{{{#!hs\r\nquot\r\nrem\r\ndiv\r\nmod\r\nquotRem\r\ndivMod\r\n}}}\r\n?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13651Invalid redundant pattern matches with -XTypeFamilyDependencies2019-07-07T18:20:47ZEric CrockettInvalid redundant pattern matches with -XTypeFamilyDependenciesThe following code triggers a warning about a redundant pattern match for `foo`:
```
{-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-}
type family F r s = f | f -> r s
type instance F (Bar h (Foo r)) (Bar h (Foo s)) = Bar h (Bar r...The following code triggers a warning about a redundant pattern match for `foo`:
```
{-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-}
type family F r s = f | f -> r s
type instance F (Bar h (Foo r)) (Bar h (Foo s)) = Bar h (Bar r s)
data Bar s b
data Foo a
foo :: (F cr cu ~ Bar h (Bar r u),
F cu cs ~ Bar (Foo h) (Bar u s))
=> Bar h (Bar r u) -> Bar (Foo h) (Bar u s) -> Foo (cr -> cs)
foo = undefined
```
```
warning: [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘foo’: foo = ..
```
This warning seems invalid to me: I'm not sure how a single definition could constitute a redundant pattern match. Moreover, if I try to address the warning by removing the "redundant" pattern, the code (of course) fails to compile because there is no accompanying binding for the signature of `foo`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Invalid redundant pattern matches with -XTypeFamilyDependencies","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":["InjectiveFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code triggers a warning about a redundant pattern match for `foo`:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-}\r\n\r\ntype family F r s = f | f -> r s\r\n\r\ntype instance F (Bar h (Foo r)) (Bar h (Foo s)) = Bar h (Bar r s)\r\n\r\ndata Bar s b\r\ndata Foo a\r\n\r\nfoo :: (F cr cu ~ Bar h (Bar r u), \r\n F cu cs ~ Bar (Foo h) (Bar u s))\r\n => Bar h (Bar r u) -> Bar (Foo h) (Bar u s) -> Foo (cr -> cs)\r\nfoo = undefined\r\n}}}\r\n\r\n\r\n{{{\r\nwarning: [-Woverlapping-patterns]\r\n Pattern match is redundant\r\n In an equation for ‘foo’: foo = ..\r\n}}}\r\n\r\nThis warning seems invalid to me: I'm not sure how a single definition could constitute a redundant pattern match. Moreover, if I try to address the warning by removing the \"redundant\" pattern, the code (of course) fails to compile because there is no accompanying binding for the signature of `foo`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13650Implement KPush in types2021-10-04T14:41:09ZRichard Eisenbergrae@richarde.devImplement KPush in typesA recent commit contributed a Note (https://gitlab.haskell.org/ghc/ghc/-/commit/ef0ff34d462e3780210567a13d58b868ec3399e0#07ce9a046fb8ea6659690020b0a8551d94cfdf1c_1175_1163) that explains why we need the dreaded KPush rule to be implement...A recent commit contributed a Note (https://gitlab.haskell.org/ghc/ghc/-/commit/ef0ff34d462e3780210567a13d58b868ec3399e0#07ce9a046fb8ea6659690020b0a8551d94cfdf1c_1175_1163) that explains why we need the dreaded KPush rule to be implemented in `splitTyConApp`. Without KPush there, it's possible that we can have two types t1 and t2 such that `t1 `eqType` t2` and yet they respond differently to `splitTyConApp`: t1 = `(T |> co1) (a |> co2)` and t2 = `T a`. Both t1 and t2 are well-kinded and can have the same kind. But one is a `TyConApp` and one is an `AppTy`. (Actually, looking at this, perhaps the magic will be in `mkAppTy`, not `splitTyConApp`.) But I have to look closer.
This ticket serves as a reminder to do so.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement KPush in types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"A recent commit contributed a [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Type.hs;a483e711da7834bc952367f554ac4e877b4e157a$1191 Note] that explains why we need the dreaded KPush rule to be implemented in `splitTyConApp`. Without KPush there, it's possible that we can have two types t1 and t2 such that {{{t1 `eqType` t2}}} and yet they respond differently to `splitTyConApp`: t1 = `(T |> co1) (a |> co2)` and t2 = `T a`. Both t1 and t2 are well-kinded and can have the same kind. But one is a `TyConApp` and one is an `AppTy`. (Actually, looking at this, perhaps the magic will be in `mkAppTy`, not `splitTyConApp`.) But I have to look closer.\r\n\r\nThis ticket serves as a reminder to do so.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/13649RebindableSyntax causes type errors when 'fail' is not defined, even if not u...2019-07-07T18:20:47ZAaronFrielRebindableSyntax causes type errors when 'fail' is not defined, even if not used.With -XRebindableSyntax and a wildcard pattern on an action, a spurious compiler error occurs if `fail` is not in scope:
```
Not in scope: ‘fail’
Perhaps you want to add ‘fail’ to the import list in the import of
‘Prelude’ (...With -XRebindableSyntax and a wildcard pattern on an action, a spurious compiler error occurs if `fail` is not in scope:
```
Not in scope: ‘fail’
Perhaps you want to add ‘fail’ to the import list in the import of
‘Prelude’ (rebind.hs:6:1-53).
|
27 | _ <- m1
| ^^^^^^^
```
```hs
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RebindableSyntax #-}
module Main where
import Prelude (String, print, Maybe (..), error, id)
class MyFunctor f where
fmap :: (a -> b) -> f a -> f b
class MyApplicative f where
pure :: a -> f a
(<*>) :: f (a -> b) -> f a -> f b
class MyMonad m where
return :: a -> m a
(>>) :: m a -> m b -> m b
(>>=) :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a
-- Uncommenting the following lines allows testCase1 to compile:
-- class MyFail m where
-- fail :: String -> m a
-- But testCase1 will not require a 'MyFail m' constraint.
testCase1 :: MyMonad m => m a -> m ()
testCase1 m1 = do
_ <- m1
return ()
testCase2 :: MyMonad m => m a -> m ()
testCase2 m1 = do
m1
return ()
```
In this example, testCase1 will fail to compile until the type class `MyFail` is uncommented.
As with #13648, I think this looks like an easy fix before the 8.2.1 release, and I would be happy to submit a patch next week if someone could point me the way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc1 |
| 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":"RebindableSyntax causes type errors when 'fail' is not defined, even if not used.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc1","keywords":["RebindableSyntax"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"With -XRebindableSyntax and a wildcard pattern on an action, a spurious compiler error occurs if `fail` is not in scope:\r\n\r\n{{{\r\n Not in scope: ‘fail’\r\n Perhaps you want to add ‘fail’ to the import list in the import of\r\n ‘Prelude’ (rebind.hs:6:1-53).\r\n |\r\n27 | _ <- m1\r\n | ^^^^^^^\r\n}}}\r\n\r\n{{{#!hs\r\n{-# LANGUAGE NoImplicitPrelude #-}\r\n{-# LANGUAGE RebindableSyntax #-}\r\n\r\nmodule Main where\r\n\r\nimport Prelude (String, print, Maybe (..), error, id)\r\n\r\nclass MyFunctor f where\r\n fmap :: (a -> b) -> f a -> f b\r\n\r\nclass MyApplicative f where\r\n pure :: a -> f a\r\n (<*>) :: f (a -> b) -> f a -> f b\r\n\r\nclass MyMonad m where\r\n return :: a -> m a\r\n (>>) :: m a -> m b -> m b\r\n (>>=) :: m a -> (a -> m b) -> m b\r\n join :: m (m a) -> m a\r\n\r\n-- Uncommenting the following lines allows testCase1 to compile:\r\n-- class MyFail m where\r\n-- fail :: String -> m a\r\n\r\n-- But testCase1 will not require a 'MyFail m' constraint.\r\ntestCase1 :: MyMonad m => m a -> m ()\r\ntestCase1 m1 = do\r\n _ <- m1\r\n return ()\r\n\r\ntestCase2 :: MyMonad m => m a -> m ()\r\ntestCase2 m1 = do\r\n m1\r\n return ()\r\n}}}\r\n\r\nIn this example, testCase1 will fail to compile until the type class `MyFail` is uncommented.\r\n\r\nAs with #13648, I think this looks like an easy fix before the 8.2.1 release, and I would be happy to submit a patch next week if someone could point me the way.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13648ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without p...2019-07-07T18:20:47ZAaronFrielApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns.GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -...GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -XRebindableSyntax spec (see: #12490).
Example:
```hs
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RebindableSyntax #-}
-- Bug vanishes if this next line is removed:
{-# LANGUAGE ApplicativeDo #-}
module Main where
import Prelude (String, print)
class MyFunctor f where
fmap :: (a -> b) -> f a -> f b
class MyApplicative f where
pure :: a -> f a
(<*>) :: f (a -> b) -> f a -> f b
class MyMonad m where
return :: a -> m a
(>>) :: m a -> m b -> m b
(>>=) :: m a -> (a -> m b) -> m b
fail :: String -> m a
join :: m (m a) -> m a
testCase1 m1 m2 = do
m1
m2
return ()
testCase2 m1 m2 = do
_ <- m1
_ <- m2
return ()
main = print "42"
```
```
:t testCase1
testCase1
:: (MyFunctor f, MyApplicative f, MyMonad f, Monad f) =>
f a2 -> f a1 -> f ()
:t testCase2
:: testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f ()
```
The desugaring for testCase1 shows the issue:
```hs
testCase1' m1 m2 =
(<*>)
(fmap
(\ r1 r2 ->
case r1 of { () -> case r2 of { () -> () } })
(m1 >> (GHC.Base.Monad.return ())))
(m2 >> (GHC.Base.Monad.return ()))
-- or:
testCase1'' m1 m2 = (fmap (\() () -> () ) (m1 >> (GHC.Base.Monad.return ()))) <*> (m2 >> (GHC.Base.Monad.return ()))
```
I would be able to work on this if someone pointed me in the right direction. It looks like it would be in `compiler/rename/RnEnv` and `compiler/rename/RnExpr`, as with #12490?
As a proposed fix, I would want to implement a limited-scope fix before the 8.2.1 release which would not address the thornier issue of #10892. The patch would:
1. Replace `GHC.Base.Monad.return` with local `pure`, removing the `Monad` constraint.
1. Replace `>>` with `*>`, removing the `MyMonad` constraint.
This isn't a _complete_ fix, as this would still leave the unnecessary pattern matches in the use of `fmap`. The resulting desugaring would be:
```hs
testCase1''' m1 m2 = (fmap (\() () -> () ) (m1 *> (pure ()))) <*> (m2 *> (pure ()))
```https://gitlab.haskell.org/ghc/ghc/-/issues/13647Tidy up TcTypeable2020-01-23T19:31:02ZSimon Peyton JonesTidy up TcTypeableThere is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it.
But it's pretty hard to understand. And it generates a staggering amount...There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it.
But it's pretty hard to understand. And it generates a staggering amount of data structure, when
compiling `GHC.Types`.
```
Result size of Tidy Core
= {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0}
```
Why? Well, it injects a `TyCon` binding for each unboxed tuple size.
For example, here is the code for pairs `(#,#)`
```
$tc(#,#)
= TyCon 16533601304077481746##
7902994497850328874##
tr$ModuleGHCPrim
$tc(#,#)2
2#
$tc(#,#)1
-- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))
$tc(#,#)1 :: KindRep
$tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE
$krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD
-- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))
$krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC
$krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep)
-- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))
$krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA
$krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep)
-- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))
$krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ
$krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY
$krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX
$krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep)
-- ': RuntimeRep #1 ('[] RuntimeRep)
$krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV
$krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU
$krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT
$krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep)
-- '[] RuntimeRep
$krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ
$krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep)
-- RuntimeRep
$tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep)
-------------- TYPE #0
$krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh
$krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep)
$krep61_r5Ma = KindRepVar 0#
-------------- TYPE #1
$krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj
$krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep)
$krep60_r5M9 = KindRepVar 1#
```
That's a lot, and it's only for pairs.
We generate all this up to 62-tuples!
Suggestions (read `Note [Representing TyCon kinds: KindRep]` first)
- `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`.
- One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller.
- We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`.
- Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary
None of this is essential, but I think that matters can be improved.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Tidy up TcTypeable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it.\r\n\r\nBut it's pretty hard to understand. And it generates a staggering amount of data structure, when\r\ncompiling `GHC.Types`.\r\n{{{\r\nResult size of Tidy Core\r\n = {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0}\r\n}}}\r\nWhy? Well, it injects a `TyCon` binding for each unboxed tuple size.\r\nFor example, here is the code for pairs `(#,#)`\r\n{{{\r\n$tc(#,#)\r\n = TyCon 16533601304077481746##\r\n 7902994497850328874##\r\n tr$ModuleGHCPrim\r\n $tc(#,#)2\r\n 2#\r\n $tc(#,#)1\r\n\r\n-- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))\r\n$tc(#,#)1 :: KindRep\r\n$tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE\r\n\r\n$krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD\r\n\r\n-- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))))\r\n$krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC\r\n$krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep)\r\n\r\n-- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))\r\n$krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA\r\n$krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep)\r\n\r\n-- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))\r\n$krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ\r\n$krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY\r\n$krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX\r\n$krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep)\r\n\r\n-- ': RuntimeRep #1 ('[] RuntimeRep)\r\n$krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV\r\n$krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU\r\n$krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT\r\n$krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep)\r\n\r\n-- '[] RuntimeRep\r\n$krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ\r\n$krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep)\r\n\r\n-- RuntimeRep\r\n$tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep)\r\n\r\n-------------- TYPE #0\r\n$krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh\r\n$krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep)\r\n$krep61_r5Ma = KindRepVar 0#\r\n\r\n-------------- TYPE #1\r\n$krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj\r\n$krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep)\r\n$krep60_r5M9 = KindRepVar 1#\r\n}}}\r\nThat's a lot, and it's only for pairs.\r\nWe generate all this up to 62-tuples!\r\n\r\nSuggestions (read `Note [Representing TyCon kinds: KindRep]` first)\r\n\r\n* `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`.\r\n\r\n* One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller.\r\n\r\n* We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`.\r\n\r\n* Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary\r\n\r\nNone of this is essential, but I think that matters can be improved.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13646strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-patt...2019-07-07T18:20:48Zexphpstrict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-bindsIn each of the following programs, a bang pattern is used to force evaluation of a bottom, the intent being to perform fail-fast error checking. Unfortunately, however, they also generate `-Wunused-pattern-binds`.
```hs
{-# OPTIONS_GHC ...In each of the following programs, a bang pattern is used to force evaluation of a bottom, the intent being to perform fail-fast error checking. Unfortunately, however, they also generate `-Wunused-pattern-binds`.
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE BangPatterns #-}
main :: IO ()
main = do
let !Nothing = Just ()
pure ()
```
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE BangPatterns #-}
import Control.Exception
main :: IO ()
main = do
let !() = assert False ()
pure ()
```
```
src/Lib.hs:6:9: warning: [-Wunused-pattern-binds]
This pattern-binding binds no variables: !Nothing = Just ()
Linking src/Lib ...
Lib: src/Lib.hs:6:9-26: Irrefutable pattern failed for pattern Nothing
--------------------
src/Lib.hs:8:9: warning: [-Wunused-pattern-binds]
This pattern-binding binds no variables: !() = assert False ()
Linking src/Lib ...
Lib: Assertion failed
CallStack (from HasCallStack):
assert, called at src/Lib.hs:8:15 in main:Main
```
For clarity, non-monadic `let ... in` patterns are also affected; I only gloss over them because there tends to be other equally ergonomic alternatives in such cases.
I found this #9127 (ticket), where a patch was accepted to allow wildcards of the form `!_`. However, `!_` is unsatisfactory and perhaps even dangerous for such usage, as it does not constrain the type in any manner. In particular, there is nothing to prevent somebody from writing
```hs
main = do
let !_ = assert someCondition -- (missing an argument)
pure ()
```
which //is// in fact useless.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In each of the following programs, a bang pattern is used to force evaluation of a bottom, the intent being to perform fail-fast error checking. Unfortunately, however, they also generate `-Wunused-pattern-binds`.\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE BangPatterns #-}\r\n\r\nmain :: IO ()\r\nmain = do\r\n let !Nothing = Just ()\r\n pure ()\r\n}}}\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE BangPatterns #-}\r\n\r\nimport Control.Exception\r\n\r\nmain :: IO ()\r\nmain = do\r\n let !() = assert False ()\r\n pure ()\r\n}}}\r\n{{{\r\nsrc/Lib.hs:6:9: warning: [-Wunused-pattern-binds]\r\n This pattern-binding binds no variables: !Nothing = Just ()\r\nLinking src/Lib ...\r\nLib: src/Lib.hs:6:9-26: Irrefutable pattern failed for pattern Nothing\r\n\r\n--------------------\r\n\r\nsrc/Lib.hs:8:9: warning: [-Wunused-pattern-binds]\r\n This pattern-binding binds no variables: !() = assert False ()\r\nLinking src/Lib ...\r\nLib: Assertion failed\r\nCallStack (from HasCallStack):\r\n assert, called at src/Lib.hs:8:15 in main:Main\r\n}}}\r\nFor clarity, non-monadic `let ... in` patterns are also affected; I only gloss over them because there tends to be other equally ergonomic alternatives in such cases.\r\n\r\nI found this #9127 (ticket), where a patch was accepted to allow wildcards of the form `!_`. However, `!_` is unsatisfactory and perhaps even dangerous for such usage, as it does not constrain the type in any manner. In particular, there is nothing to prevent somebody from writing\r\n{{{#!hs\r\nmain = do\r\n let !_ = assert someCondition -- (missing an argument)\r\n pure ()\r\n}}}\r\nwhich //is// in fact useless.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13645whoCreated produces an uninformative stack trace when an exception is raised ...2019-07-07T18:20:48ZrefoldwhoCreated produces an uninformative stack trace when an exception is raised in a CAFConsider the following program:
```hs
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import Control.Exception
import GHC.Stack
{-# NOINLINE caf #-}
caf :: [Int]
caf = [1..500]
{-# NOINLINE caf_exc #-}
caf_exc :: Int
caf_exc =...Consider the following program:
```hs
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import Control.Exception
import GHC.Stack
{-# NOINLINE caf #-}
caf :: [Int]
caf = [1..500]
{-# NOINLINE caf_exc #-}
caf_exc :: Int
caf_exc = caf !! 1000
{-# NOINLINE foo #-}
foo :: Int -> Int
foo 0 = caf_exc
foo n = foo $ n - 1
{-# NOINLINE bar #-}
bar :: Int -> Int
bar n = bar' n
where
bar' 0 = foo n
bar' m = bar' $ m - 1
main :: IO ()
main = print (bar 10) `catch`
\(e :: SomeException) -> do stacktrace <- whoCreated e
print stacktrace
```
By default, when built with profiling, `whoCreated` in the example above produces a quite uninformative stack trace:
```shell
$ ./caf-nostack
["GHC.List.CAF (<entire-module>)"]
```
However, if you run the program with `+RTS -xc`, you'll see that it prints a stack trace with much more context:
```shell
$ ./caf-nostack +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace:
GHC.List.CAF
--> evaluated by: Main.caf_exc,
called from Main.CAF
--> evaluated by: Main.foo,
called from Main.bar.bar',
called from Main.bar,
called from Main.main,
called from Main.CAF
--> evaluated by: Main.main
["GHC.List.CAF (<entire-module>)"]
```
It'd be nice if `whoCreated` produced something closer to the `+RTS -xc` output in this case.
Cabalised test project: https://github.com/23Skidoo/caf-nostack
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"whoCreated produces an uninformative stack trace when an exception is raised in a CAF","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nmodule Main where\r\n\r\nimport Control.Exception\r\nimport GHC.Stack\r\n\r\n{-# NOINLINE caf #-}\r\ncaf :: [Int]\r\ncaf = [1..500]\r\n\r\n{-# NOINLINE caf_exc #-}\r\ncaf_exc :: Int\r\ncaf_exc = caf !! 1000\r\n\r\n{-# NOINLINE foo #-}\r\nfoo :: Int -> Int\r\nfoo 0 = caf_exc\r\nfoo n = foo $ n - 1\r\n\r\n{-# NOINLINE bar #-}\r\nbar :: Int -> Int\r\nbar n = bar' n\r\n where\r\n bar' 0 = foo n\r\n bar' m = bar' $ m - 1\r\n\r\nmain :: IO ()\r\nmain = print (bar 10) `catch`\r\n \\(e :: SomeException) -> do stacktrace <- whoCreated e\r\n print stacktrace\r\n}}}\r\n\r\nBy default, when built with profiling, `whoCreated` in the example above produces a quite uninformative stack trace:\r\n\r\n{{{#!shell\r\n$ ./caf-nostack\r\n[\"GHC.List.CAF (<entire-module>)\"]\r\n}}}\r\n\r\nHowever, if you run the program with `+RTS -xc`, you'll see that it prints a stack trace with much more context:\r\n\r\n{{{#!shell\r\n$ ./caf-nostack +RTS -xc\r\n*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: \r\n GHC.List.CAF\r\n --> evaluated by: Main.caf_exc,\r\n called from Main.CAF\r\n --> evaluated by: Main.foo,\r\n called from Main.bar.bar',\r\n called from Main.bar,\r\n called from Main.main,\r\n called from Main.CAF\r\n --> evaluated by: Main.main\r\n[\"GHC.List.CAF (<entire-module>)\"]\r\n}}}\r\n\r\nIt'd be nice if `whoCreated` produced something closer to the `+RTS -xc` output in this case.\r\n\r\nCabalised test project: https://github.com/23Skidoo/caf-nostack","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13644overloaded name used in record pattern matching leads to panic! (the 'imposs...2019-07-07T18:20:48Zpjljvdlaaroverloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghcIn Haskell,
1. The scope of definitions can be controled.
1. The same name can be used to define both a function and a field of record.
1. The user can use that name in record pattern matching when only the function is within scope. For...In Haskell,
1. The scope of definitions can be controled.
1. The same name can be used to define both a function and a field of record.
1. The user can use that name in record pattern matching when only the function is within scope. For example
```
FuncId{ name = nm }
```
resulting in the following bug
```
[38 of 39] Compiling TxsUtils ( src\TxsUtils.hs, .stack-work\dist\1f7101f2\build\Txs
Utils.o )
ghc.EXE: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-mingw32):
translateConPatVec: lookup
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In Haskell,\r\n1. The scope of definitions can be controled.\r\n2. The same name can be used to define both a function and a field of record.\r\n3. The user can use that name in record pattern matching when only the function is within scope. For example \r\n{{{\r\nFuncId{ name = nm }\r\n}}}\r\nresulting in the following bug\r\n\r\n{{{\r\n[38 of 39] Compiling TxsUtils ( src\\TxsUtils.hs, .stack-work\\dist\\1f7101f2\\build\\Txs\r\nUtils.o )\r\nghc.EXE: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-mingw32):\r\n translateConPatVec: lookup\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/13643Core lint error with TypeInType and TypeFamilyDependencies2019-07-07T18:20:49ZIcelandjackCore lint error with TypeInType and TypeFamilyDependenciesIn the code
```hs
{-# Language TypeFamilyDependencies #-}
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language DataKinds #-}
{-# Language TypeInType #-}
{-# Language GADTs...In the code
```hs
{-# Language TypeFamilyDependencies #-}
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language DataKinds #-}
{-# Language TypeInType #-}
{-# Language GADTs #-}
import Data.Kind (Type)
data Code = I
type family
Interp (a :: Code) = (res :: Type) | res -> a where
Interp I = Bool
data T :: forall a. Interp a -> Type where
MkNat :: T False
instance Show (T a) where show _ = "MkNat"
main = do
print MkNat
```
but add `{-# Options_GHC -dcore-lint #-}` and we get the attached log from running `runghc /tmp/tPb2.hs > /tmp/tPb2.log`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #12102 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core lint error with TypeInType and TypeFamilyDependencies","status":"New","operating_system":"","component":"Compiler","related":[12102],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["InjectiveFamilies,","TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the code\r\n\r\n{{{#!hs\r\n{-# Language TypeFamilyDependencies #-}\r\n{-# Language RankNTypes #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language DataKinds #-}\r\n{-# Language TypeInType #-}\r\n{-# Language GADTs #-}\r\n\r\nimport Data.Kind (Type)\r\n\r\ndata Code = I\r\n\r\ntype family\r\n Interp (a :: Code) = (res :: Type) | res -> a where\r\n Interp I = Bool\r\n\r\ndata T :: forall a. Interp a -> Type where\r\n MkNat :: T False\r\n\r\ninstance Show (T a) where show _ = \"MkNat\"\r\n\r\nmain = do\r\n print MkNat\r\n}}}\r\n\r\nbut add `{-# Options_GHC -dcore-lint #-}` and we get the attached log from running `runghc /tmp/tPb2.hs > /tmp/tPb2.log`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13642GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature2019-07-07T18:20:49ZRyan ScottGHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signatureThis is a pretty bizarre behavior I've noticed recently that only happens in GHC 8.2 or later. If you try to use a Template Haskell splice with a very particular feature (a datatype whose kind uses `forall`) in GHCi, then GHCi will flat-...This is a pretty bizarre behavior I've noticed recently that only happens in GHC 8.2 or later. If you try to use a Template Haskell splice with a very particular feature (a datatype whose kind uses `forall`) in GHCi, then GHCi will flat-out ignore it!
```
$ /opt/ghc/8.2.1/bin/ghci
GHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes
λ> import Language.Haskell.TH (stringE, pprint)
λ> import Data.Kind (Type)
λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)
λ> print (5 + length $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint))
λ> 5
5
λ> it
5
λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)
λ> it
5
```
Notice how none of my attempts to use the splice seemed to register with GHCi.
This isn't really a regression //per se//, since GHC 8.0.1 nor 8.0.2 even allowed you to get that far:
```
$ /opt/ghc/8.0.2/bin/ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes
λ> import Language.Haskell.TH (stringE, pprint)
λ> import Data.Kind (Type)
λ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)
<interactive>:4:3: error:
Exotic form of kind not (yet) handled by Template Haskell
forall a. a -> Type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi 8.2 simply ignores TH splice using datatype with a forall'd kind signature","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a pretty bizarre behavior I've noticed recently that only happens in GHC 8.2 or later. If you try to use a Template Haskell splice with a very particular feature (a datatype whose kind uses `forall`) in GHCi, then GHCi will flat-out ignore it!\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghci\r\nGHCi, version 8.2.0.20170427: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes \r\nλ> import Language.Haskell.TH (stringE, pprint)\r\nλ> import Data.Kind (Type)\r\nλ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)\r\nλ> print (5 + length $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint))\r\nλ> 5\r\n5\r\nλ> it\r\n5\r\nλ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)\r\nλ> it\r\n5\r\n}}}\r\n\r\nNotice how none of my attempts to use the splice seemed to register with GHCi.\r\n\r\nThis isn't really a regression //per se//, since GHC 8.0.1 nor 8.0.2 even allowed you to get that far:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.2/bin/ghci\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> :set -XGADTs -XTypeInType -XTemplateHaskell -XRankNTypes \r\nλ> import Language.Haskell.TH (stringE, pprint)\r\nλ> import Data.Kind (Type)\r\nλ> $([d| data Foo :: forall a. a -> Type where MkFoo :: Foo Int |] >>= stringE . pprint)\r\n\r\n<interactive>:4:3: error:\r\n Exotic form of kind not (yet) handled by Template Haskell\r\n forall a. a -> Type\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13641Compile error while performing stack upgrade2019-07-07T18:20:49ZpisomojadoCompile error while performing stack upgradeHello, I'm a very green user of this ticket system, as well as GHC, so apologies if I have not given useful details.
I'm complying with the request of stack/ghc, as you can see down towards the bottom of my attempt to upgrade stack on m...Hello, I'm a very green user of this ticket system, as well as GHC, so apologies if I have not given useful details.
I'm complying with the request of stack/ghc, as you can see down towards the bottom of my attempt to upgrade stack on my host. Any help would be appreciated.
```
pisomojado@host:~$ stack upgrade
Fetching package index ...remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
Fetched package index.
aeson-1.0.2.1: configure
aeson-1.0.2.1: build
Cabal-1.24.2.0: configure
Cabal-1.24.2.0: build
ed25519-0.0.5.0: configure
ed25519-0.0.5.0: build
cryptohash-sha256-0.11.100.1: configure
cryptohash-sha256-0.11.100.1: build
cryptohash-sha256-0.11.100.1: copy/register
http-client-0.5.3.3: configure
http-client-0.5.3.3: build
ed25519-0.0.5.0: copy/register
optparse-applicative-0.13.0.0: configure
optparse-applicative-0.13.0.0: build
optparse-applicative-0.13.0.0: copy/register
optparse-simple-0.0.3: configure
optparse-simple-0.0.3: build
optparse-simple-0.0.3: copy/register
pid1-0.1.0.0: configure
pid1-0.1.0.0: build
http-client-0.5.3.3: copy/register
http-client-tls-0.3.4: configure
pid1-0.1.0.0: copy/register
http-client-tls-0.3.4: build
store-core-0.3: configure
store-core-0.3: build
http-client-tls-0.3.4: copy/register
text-metrics-0.1.0: configure
store-core-0.3: copy/register
text-metrics-0.1.0: build
th-orphans-0.13.1: configure
th-orphans-0.13.1: build
text-metrics-0.1.0: copy/register
th-orphans-0.13.1: copy/register
th-utilities-0.2.0.1: configure
th-utilities-0.2.0.1: build
th-utilities-0.2.0.1: copy/register
store-0.3: configure
store-0.3: build
store-0.3: copy/register
aeson-1.0.2.1: copy/register
aeson-compat-0.3.6: configure
aeson-compat-0.3.6: build
binary-tagged-0.1.4.1: configure
binary-tagged-0.1.4.1: build
http-conduit-2.2.3: configure
http-conduit-2.2.3: build
aeson-compat-0.3.6: copy/register
path-0.5.9: configure
path-0.5.9: build
http-conduit-2.2.3: copy/register
persistent-2.6: configure
persistent-2.6: build
path-0.5.9: copy/register
path-io-1.1.0: configure
path-io-1.1.0: build
binary-tagged-0.1.4.1: copy/register
yaml-0.8.20: configure
yaml-0.8.20: build
path-io-1.1.0: copy/register
yaml-0.8.20: copy/register
hpack-0.17.0: configure
hpack-0.17.0: build
persistent-2.6: copy/register
persistent-template-2.5.1.6: configure
persistent-template-2.5.1.6: build
persistent-sqlite-2.6: configure
persistent-sqlite-2.6: build
Cabal-1.24.2.0: copy/register
hpack-0.17.0: copy/register
hackage-security-0.5.2.2: configure
hackage-security-0.5.2.2: build
persistent-template-2.5.1.6: copy/register
hackage-security-0.5.2.2: copy/register
persistent-sqlite-2.6: copy/register
stack-1.4.0: configure
[1 of 1] Compiling Main ( /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/Setup.hs, /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )
Linking /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...
Configuring stack-1.4.0...
stack-1.4.0: build
Preprocessing library stack-1.4.0...
[ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )
[ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o )
[ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o )
[ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )
[ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )
[ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )
[ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )
[ 8 of 124] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )
[ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )
[ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )
[ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib, 5): no suitable image found. Did find:
/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib: malformed mach-o: load commands size (49672) > 32768
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Completed 26 action(s).
-- While building package stack-1.4.0 using:
/private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
```
<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":"Compile error while performing stack upgrade","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":"Hello, I'm a very green user of this ticket system, as well as GHC, so apologies if I have not given useful details.\r\n\r\nI'm complying with the request of stack/ghc, as you can see down towards the bottom of my attempt to upgrade stack on my host. Any help would be appreciated.\r\n\r\n{{{\r\npisomojado@host:~$ stack upgrade\r\nFetching package index ...remote: Counting objects: 1, done.\r\nremote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0\r\nUnpacking objects: 100% (1/1), done.\r\nFetched package index. \r\naeson-1.0.2.1: configure\r\naeson-1.0.2.1: build\r\nCabal-1.24.2.0: configure\r\nCabal-1.24.2.0: build\r\ned25519-0.0.5.0: configure\r\ned25519-0.0.5.0: build\r\ncryptohash-sha256-0.11.100.1: configure\r\ncryptohash-sha256-0.11.100.1: build\r\ncryptohash-sha256-0.11.100.1: copy/register\r\nhttp-client-0.5.3.3: configure\r\nhttp-client-0.5.3.3: build\r\ned25519-0.0.5.0: copy/register\r\noptparse-applicative-0.13.0.0: configure\r\noptparse-applicative-0.13.0.0: build\r\noptparse-applicative-0.13.0.0: copy/register\r\noptparse-simple-0.0.3: configure\r\noptparse-simple-0.0.3: build\r\noptparse-simple-0.0.3: copy/register\r\npid1-0.1.0.0: configure\r\npid1-0.1.0.0: build\r\nhttp-client-0.5.3.3: copy/register\r\nhttp-client-tls-0.3.4: configure\r\npid1-0.1.0.0: copy/register\r\nhttp-client-tls-0.3.4: build\r\nstore-core-0.3: configure\r\nstore-core-0.3: build\r\nhttp-client-tls-0.3.4: copy/register\r\ntext-metrics-0.1.0: configure\r\nstore-core-0.3: copy/register\r\ntext-metrics-0.1.0: build\r\nth-orphans-0.13.1: configure\r\nth-orphans-0.13.1: build\r\ntext-metrics-0.1.0: copy/register\r\nth-orphans-0.13.1: copy/register\r\nth-utilities-0.2.0.1: configure\r\nth-utilities-0.2.0.1: build\r\nth-utilities-0.2.0.1: copy/register\r\nstore-0.3: configure\r\nstore-0.3: build\r\nstore-0.3: copy/register\r\naeson-1.0.2.1: copy/register\r\naeson-compat-0.3.6: configure\r\naeson-compat-0.3.6: build\r\nbinary-tagged-0.1.4.1: configure\r\nbinary-tagged-0.1.4.1: build\r\nhttp-conduit-2.2.3: configure\r\nhttp-conduit-2.2.3: build\r\naeson-compat-0.3.6: copy/register\r\npath-0.5.9: configure\r\npath-0.5.9: build\r\nhttp-conduit-2.2.3: copy/register\r\npersistent-2.6: configure\r\npersistent-2.6: build\r\npath-0.5.9: copy/register\r\npath-io-1.1.0: configure\r\npath-io-1.1.0: build\r\nbinary-tagged-0.1.4.1: copy/register\r\nyaml-0.8.20: configure\r\nyaml-0.8.20: build\r\npath-io-1.1.0: copy/register\r\nyaml-0.8.20: copy/register\r\nhpack-0.17.0: configure\r\nhpack-0.17.0: build\r\npersistent-2.6: copy/register\r\npersistent-template-2.5.1.6: configure\r\npersistent-template-2.5.1.6: build\r\npersistent-sqlite-2.6: configure\r\npersistent-sqlite-2.6: build\r\nCabal-1.24.2.0: copy/register\r\nhpack-0.17.0: copy/register\r\nhackage-security-0.5.2.2: configure\r\nhackage-security-0.5.2.2: build\r\npersistent-template-2.5.1.6: copy/register\r\nhackage-security-0.5.2.2: copy/register\r\npersistent-sqlite-2.6: copy/register\r\nstack-1.4.0: configure\r\n[1 of 1] Compiling Main ( /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/Setup.hs, /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )\r\nLinking /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...\r\nConfiguring stack-1.4.0...\r\nstack-1.4.0: build\r\nPreprocessing library stack-1.4.0...\r\n[ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )\r\n[ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o )\r\n[ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o )\r\n[ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )\r\n[ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )\r\n[ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )\r\n[ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )\r\n[ 8 of 124] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )\r\n[ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )\r\n[ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )\r\n[ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-apple-darwin):\r\n Loading temp shared object failed: dlopen(/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib, 5): no suitable image found. Did find:\r\n /var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc7482_0/libghc_68.dylib: malformed mach-o: load commands size (49672) > 32768\r\n \r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n \r\nCompleted 26 action(s).\r\n\r\n-- While building package stack-1.4.0 using:\r\n /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack-upgrade4706/stack-1.4.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13640Core lint error with deferred type holes2019-07-07T18:20:49ZIcelandjackCore lint error with deferred type holesThe following program (note the `-dcore-lint`)
```hs
{-# Options_GHC -dcore-lint -fdefer-typed-holes #-}
import Prelude hiding ((.))
class Functor' f where
map' :: (a -> b) -> f a -> f b
class Bifunctor' f where
map2' :: (a -> b)...The following program (note the `-dcore-lint`)
```hs
{-# Options_GHC -dcore-lint -fdefer-typed-holes #-}
import Prelude hiding ((.))
class Functor' f where
map' :: (a -> b) -> f a -> f b
class Bifunctor' f where
map2' :: (a -> b) -> f a c -> f b c
bimap' :: Bifunctor' f => (a -> b) -> (c -> d) -> (f a c -> f b d)
bimap' f g = map2' f . map'
```
produces a `*** Core Lint errors : in result of Desugar (after optimization) ***`, more information in attached [the log](https://ghc.haskell.org/trac/ghc/attachment/ticket/13640/tN4R.log).https://gitlab.haskell.org/ghc/ghc/-/issues/13639Skylighting package compilation is glacial2019-07-07T18:20:50ZBen GamariSkylighting package compilation is glacialCompiling the `skylighting` package in profiled and non-profiled configuration takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate.Compiling the `skylighting` package in profiled and non-profiled configuration takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate.8.6.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/13638configure error: GHC is required.2019-07-07T18:20:50ZQuRyuconfigure error: GHC is required.While I was trying to download GHC source code from Github and to build it myself, I encountered the error "configure: error: GHC is required." when I was doing "./configure". The "perl boot" raised no warning or error, and the source co...While I was trying to download GHC source code from Github and to build it myself, I encountered the error "configure: error: GHC is required." when I was doing "./configure". The "perl boot" raised no warning or error, and the source code was directly downloaded from Github using "git clone --recursive git://github.com/ghc/ghc.git".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"configure error: GHC is required.","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While I was trying to download GHC source code from Github and to build it myself, I encountered the error \"configure: error: GHC is required.\" when I was doing \"./configure\". The \"perl boot\" raised no warning or error, and the source code was directly downloaded from Github using \"git clone --recursive git://github.com/ghc/ghc.git\". ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13637Printing type operators adds extraneous parenthesis2019-07-07T18:20:50ZdarchonPrinting type operators adds extraneous parenthesisGiven the code:
```
{-# LANGUAGE TypeOperators #-}
type name ::: a = a
f :: Int ::: Int -> Int
f = id
```
In GHCi-8.0.2 I get:
```
>>> :t f
f :: Int ::: Int -> Int
```
But in GHCi-8.2.0.20170427 I get:
```
>>> :t f
f :: (Int ::: I...Given the code:
```
{-# LANGUAGE TypeOperators #-}
type name ::: a = a
f :: Int ::: Int -> Int
f = id
```
In GHCi-8.0.2 I get:
```
>>> :t f
f :: Int ::: Int -> Int
```
But in GHCi-8.2.0.20170427 I get:
```
>>> :t f
f :: (Int ::: Int) -> Int
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Printing type operators adds extraneous parenthesis","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given the code:\r\n\r\n{{{\r\n{-# LANGUAGE TypeOperators #-}\r\n\r\ntype name ::: a = a\r\n\r\nf :: Int ::: Int -> Int\r\nf = id\r\n}}}\r\n\r\nIn GHCi-8.0.2 I get:\r\n\r\n{{{\r\n>>> :t f\r\nf :: Int ::: Int -> Int\r\n}}}\r\n\r\nBut in GHCi-8.2.0.20170427 I get:\r\n\r\n{{{\r\n>>> :t f\r\nf :: (Int ::: Int) -> Int\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/13636Enable -Wcpp-undef2019-07-07T18:20:50ZBen GamariEnable -Wcpp-undefe5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp-undef` in `mk/warnings.mk`,
```make
SRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef
SRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef
```
Unfortunately, this caused build ...e5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp-undef` in `mk/warnings.mk`,
```make
SRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef
SRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef
```
Unfortunately, this caused build failures in boot libraries on some platforms (e.g. `time` on Darwin). Resolve these and reenable `-Wcpp-undef`.
An alternative would be to instead only add `-Wcpp-undef` to `GhcRtsHcOpts`, `GhcStage1HcOpts` and `GhcStage2HcOpts`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Enable -Wcpp-undef","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"e5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp-undef` in `mk/warnings.mk`,\r\n{{{#!make\r\nSRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef\r\nSRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef\r\n}}}\r\n\r\nUnfortunately, this caused build failures in boot libraries on some platforms (e.g. `time` on Darwin). Resolve these and reenable `-Wcpp-undef`.\r\n\r\nAn alternative would be to instead only add `-Wcpp-undef` to `GhcRtsHcOpts`, `GhcStage1HcOpts` and `GhcStage2HcOpts`.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13635Incorrect result at runtime with list comprehensions in that case2019-07-07T18:20:50ZvantoIncorrect result at runtime with list comprehensions in that case1. With GHC 8.0.2\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:1:12: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
*...1. With GHC 8.0.2\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:1:12: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
* In the expression: _
In the expression: [_, _]
In a stmt of a list comprehension: x <- [_, _]
* Relevant bindings include it :: [t] (bound at <interactive>:1:1)
<interactive>:1:15: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: [t] at <interactive>:1:1
* In the expression: _
In the expression: [_, _]
In a stmt of a list comprehension: x <- [_, _]
* Relevant bindings include it :: [t] (bound at <interactive>:1:1)
Prelude>\\
```
This result makes no sense here.\\\\
The result will always be the empty list \[\].\\\\
1. With GHC 7.6.3\\\\
```
Prelude> [x | x <- [_, _], False]
<interactive>:2:12: Pattern syntax in expression context: _
<interactive>:2:12: Pattern syntax in expression context: _
Prelude>
```
This result also makes no sense here.\\\\
Similarly this result will always be the empty list \[\].
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect result at runtime with list comprehensions in that case","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1. With GHC 8.0.2\\\\\r\n\r\n{{{\r\nPrelude> [x | x <- [_, _], False]\r\n\r\n<interactive>:1:12: error:\r\n * Found hole: _ :: t\r\n Where: `t' is a rigid type variable bound by\r\n the inferred type of it :: [t] at <interactive>:1:1\r\n * In the expression: _\r\n In the expression: [_, _]\r\n In a stmt of a list comprehension: x <- [_, _]\r\n * Relevant bindings include it :: [t] (bound at <interactive>:1:1)\r\n\r\n<interactive>:1:15: error:\r\n * Found hole: _ :: t\r\n Where: `t' is a rigid type variable bound by\r\n the inferred type of it :: [t] at <interactive>:1:1\r\n * In the expression: _\r\n In the expression: [_, _]\r\n In a stmt of a list comprehension: x <- [_, _]\r\n * Relevant bindings include it :: [t] (bound at <interactive>:1:1)\r\nPrelude>\\\\\r\n}}}\r\nThis result makes no sense here.\\\\\r\nThe result will always be the empty list [].\\\\\r\n\r\n\r\n2. With GHC 7.6.3\\\\\r\n\r\n{{{\r\nPrelude> [x | x <- [_, _], False]\r\n\r\n<interactive>:2:12: Pattern syntax in expression context: _\r\n\r\n<interactive>:2:12: Pattern syntax in expression context: _\r\nPrelude>\r\n}}}\r\nThis result also makes no sense here.\\\\\r\nSimilarly this result will always be the empty list [].\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13634num009 fails on POWER82022-01-16T09:37:43ZPeter Trommlerptrommler@acm.orgnum009 fails on POWER8This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running op...This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:
```
+uh oh! tanf 1.5707964
+-2.2877334e7
+-2.2877332e7
+(-11438667,1)
+(-11438666,1)
Done
```
The test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 fails on POWER8","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr"],"type":"Bug","description":"This failure is produced on a POWER8 running openSUSE Leap 42.2 for powerpc64le:\r\n{{{\r\n+uh oh! tanf 1.5707964\r\n+-2.2877334e7\r\n+-2.2877332e7\r\n+(-11438667,1)\r\n+(-11438666,1)\r\n Done\r\n}}}\r\n\r\nThe test passes on a PowerPC 970MP (PowerMac G5) running openSUSE 13.2 powerpc64 (big endian).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13633testwsdeque failure on POWER82020-02-07T22:55:13ZPeter Trommlerptrommler@acm.orgtestwsdeque failure on POWER8On a POWER8 `testwsdeque` fails occasionally under load:
```
Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 )
Stderr ( testwsdeque ):
internal error: FAIL: 277808608 3 13
(GHC version 8.3.20170430 for powerpc64le...On a POWER8 `testwsdeque` fails occasionally under load:
```
Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 )
Stderr ( testwsdeque ):
internal error: FAIL: 277808608 3 13
(GHC version 8.3.20170430 for powerpc64le_unknown_linux)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"testwsdeque failure on POWER8","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["SMP"],"differentials":[],"test_case":"","architecture":"","cc":["erikd","hvr","simonmar"],"type":"Bug","description":"On a POWER8 `testwsdeque` fails occasionally under load:\r\n\r\n{{{\r\nWrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 )\r\nStderr ( testwsdeque ):\r\ninternal error: FAIL: 277808608 3 13\r\n (GHC version 8.3.20170430 for powerpc64le_unknown_linux)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.org