GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:42:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8961Require PatternSynonyms language extension to *use* pattern synonyms2019-07-07T18:42:32ZGergő ÉrdiRequire PatternSynonyms language extension to *use* pattern synonymsTo keep in the spirit of #2905, especially in light of the immaturity of the pattern synonyms extensions, GHC should require the `PatternSynonyms` language extension to be turned on when encountering a pattern synonym occurance.
<detail...To keep in the spirit of #2905, especially in light of the immaturity of the pattern synonyms extensions, GHC should require the `PatternSynonyms` language extension to be turned on when encountering a pattern synonym occurance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Require PatternSynonyms language extension to *use* pattern synonyms","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"cactus"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To keep in the spirit of #2905, especially in light of the immaturity of the pattern synonyms extensions, GHC should require the `PatternSynonyms` language extension to be turned on when encountering a pattern synonym occurance.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/8958Allow role inference on datatype contexts2019-07-07T18:42:33ZRichard Eisenbergrae@richarde.devAllow role inference on datatype contextsCurrently, role inference on a datatype examines the use of a type parameter in all constructors of that datatype. This, of course, includes any constraint contexts on these datatypes. But, the (stupid) datatype context is not consulted,...Currently, role inference on a datatype examines the use of a type parameter in all constructors of that datatype. This, of course, includes any constraint contexts on these datatypes. But, the (stupid) datatype context is not consulted, as there is no need to do so for type safety.
However, by examining the datatype context, we can create a lightweight way of annotating roles, like this:
```
class Nominal a
instance Nominal a
type role Nominal nominal -- this is redundant, but here for completeness
class Representational a
instance Representational a
type role Representational representational -- this requires -XIncoherentInstances
class Phantom a -- any use of this class is redundant, but here for completeness
instance Phantom a
type role Phantom phantom
data (Nominal k, Representational v) => Map k v = ...
```
Because of the universal instances, these constraints never get in the way. This is admittedly an abuse of existing constructs, but it seems so useful that it's worth a little abuse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1-rc2 |
| 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":"Allow role inference on datatype contexts","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, role inference on a datatype examines the use of a type parameter in all constructors of that datatype. This, of course, includes any constraint contexts on these datatypes. But, the (stupid) datatype context is not consulted, as there is no need to do so for type safety.\r\n\r\nHowever, by examining the datatype context, we can create a lightweight way of annotating roles, like this:\r\n\r\n{{{\r\nclass Nominal a\r\ninstance Nominal a\r\ntype role Nominal nominal -- this is redundant, but here for completeness\r\n\r\nclass Representational a\r\ninstance Representational a\r\ntype role Representational representational -- this requires -XIncoherentInstances\r\n\r\nclass Phantom a -- any use of this class is redundant, but here for completeness\r\ninstance Phantom a\r\ntype role Phantom phantom\r\n\r\ndata (Nominal k, Representational v) => Map k v = ...\r\n}}}\r\n\r\nBecause of the universal instances, these constraints never get in the way. This is admittedly an abuse of existing constructs, but it seems so useful that it's worth a little abuse.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/8952Bang patterns don't work as the specification says2019-07-07T18:42:39ZdolioBang patterns don't work as the specification saysIn investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:
```
case Nothing of
!(~(Just x)) -> 5
Nothing -...In investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:
```
case Nothing of
!(~(Just x)) -> 5
Nothing -> 12
```
This evaluates to 12. In other words, !(\~p) is equivalent to p. However, the bang patterns description says that this should be equivalent to:
```
Nothing `seq` case Nothing of
~(Just x) -> 5
Nothing -> 12
```
which evaluates to 5. So, one of either the description or the implementation must be incorrect. In fact, GHC is even a bit confused, as it issues a warning about overlapping patterns for the bang pattern case statement, even though the successful branch is the 'unreachable' one.
The description makes more sense to me, but I'm not terribly invested in the behavior of this; it is admittedly a pretty obscure corner case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Bang patterns don't work as the specification says","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:\r\n\r\n{{{\r\ncase Nothing of\r\n !(~(Just x)) -> 5\r\n Nothing -> 12\r\n}}}\r\n\r\nThis evaluates to 12. In other words, !(~p) is equivalent to p. However, the bang patterns description says that this should be equivalent to:\r\n\r\n{{{\r\nNothing `seq` case Nothing of\r\n ~(Just x) -> 5\r\n Nothing -> 12\r\n}}}\r\n\r\nwhich evaluates to 5. So, one of either the description or the implementation must be incorrect. In fact, GHC is even a bit confused, as it issues a warning about overlapping patterns for the bang pattern case statement, even though the successful branch is the 'unreachable' one.\r\n\r\nThe description makes more sense to me, but I'm not terribly invested in the behavior of this; it is admittedly a pretty obscure corner case.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8937Wrong jump target in stg_maskUninterruptiblezh2019-07-07T18:42:44ZhsjunnWrong jump target in stg_maskUninterruptiblezhThe stack check there reads:
STK_CHK_P_LL (WDS(1)/\* worst case \*/, stg_maskAsyncExceptionszh, R1);
Isn't that supposed to be
STK_CHK_P_LL (WDS(1)/\* worst case \*/, stg_maskUninterruptiblezh, R1);
?
<details><summary>Trac metadata</s...The stack check there reads:
STK_CHK_P_LL (WDS(1)/\* worst case \*/, stg_maskAsyncExceptionszh, R1);
Isn't that supposed to be
STK_CHK_P_LL (WDS(1)/\* worst case \*/, stg_maskUninterruptiblezh, R1);
?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong jump target in stg_maskUninterruptiblezh","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The stack check there reads:\r\nSTK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1);\r\n\r\nIsn't that supposed to be\r\nSTK_CHK_P_LL (WDS(1)/* worst case */, stg_maskUninterruptiblezh, R1);\r\n?","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8931The type defaulting in GHCi with Typeable2019-07-07T18:42:45Zskata@cs.miyazaki-u.ac.jpThe type defaulting in GHCi with TypeableThe type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than with older versions, though there is no change in the related part of the documentation (i.e., "2.4.7 Type defaulting in GHCi").
```
skata@kata58:~$ ghc --version
T...The type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than with older versions, though there is no change in the related part of the documentation (i.e., "2.4.7 Type defaulting in GHCi").
```
skata@kata58:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228
skata@kata58:~$ ghci
GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Typeable
Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined <== This is the expected result.
Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined}
Prelude Data.Typeable> f (\x -> (x == 3)) <== Type defaulting does not work in this case.
<interactive>:6:1:
No instance for (Typeable a0) arising from a use of ‘f’
The type variable ‘a0’ is ambiguous
Note: there are several potential instances:
instance [overlap ok] Typeable ()
-- Defined in ‘Data.Typeable.Internal’
instance [overlap ok] Typeable Bool
-- Defined in ‘Data.Typeable.Internal’
instance [overlap ok] Typeable Char
-- Defined in ‘Data.Typeable.Internal’
...plus 14 others
In the expression: f (\ x -> (x == 3))
In an equation for ‘it’: it = f (\ x -> (x == 3))
<interactive>:6:13:
No instance for (Eq a0) arising from a use of ‘==’
The type variable ‘a0’ is ambiguous
Relevant bindings include x :: a0 (bound at <interactive>:6:5)
Note: there are several potential instances:
instance Eq a => Eq (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’
instance Eq Integer -- Defined in ‘integer-gmp:GHC.Integer.Type’
instance Eq () -- Defined in ‘GHC.Classes’
...plus 33 others
In the expression: (x == 3)
In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’
In the expression: f (\ x -> (x == 3))
<interactive>:6:16:
No instance for (Num a0) arising from the literal ‘3’
The type variable ‘a0’ is ambiguous
Relevant bindings include x :: a0 (bound at <interactive>:6:5)
Note: there are several potential instances:
instance Num Double -- Defined in ‘GHC.Float’
instance Num Float -- Defined in ‘GHC.Float’
instance Integral a => Num (GHC.Real.Ratio a)
-- Defined in ‘GHC.Real’
...plus 7 others
In the second argument of ‘(==)’, namely ‘3’
In the expression: (x == 3)
In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’
```
On the other hand,
```
skata@kata58:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
skata@kata58:~$ ghci
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Typeable
Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined
Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined
```
I think the old behavior is compliant with the documentation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The type defaulting in GHCi with Typeable","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":["Typeable","defaulting,","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThe type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than with older versions, though there is no change in the related part of the documentation (i.e., \"2.4.7 Type defaulting in GHCi\").\r\n\r\n\r\n{{{\r\nskata@kata58:~$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228\r\nskata@kata58:~$ ghci\r\nGHCi, version 7.8.0.20140228: 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\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined}\r\nPrelude Data.Typeable> f (\\x -> (x == 3))\r\n*** Exception: Prelude.undefined <== This is the expected result.\r\nPrelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined}\r\nPrelude Data.Typeable> f (\\x -> (x == 3)) <== Type defaulting does not work in this case.\r\n\r\n<interactive>:6:1:\r\n No instance for (Typeable a0) arising from a use of ‘f’\r\n The type variable ‘a0’ is ambiguous\r\n Note: there are several potential instances:\r\n instance [overlap ok] Typeable ()\r\n -- Defined in ‘Data.Typeable.Internal’\r\n instance [overlap ok] Typeable Bool\r\n -- Defined in ‘Data.Typeable.Internal’\r\n instance [overlap ok] Typeable Char\r\n -- Defined in ‘Data.Typeable.Internal’\r\n ...plus 14 others\r\n In the expression: f (\\ x -> (x == 3))\r\n In an equation for ‘it’: it = f (\\ x -> (x == 3))\r\n\r\n<interactive>:6:13:\r\n No instance for (Eq a0) arising from a use of ‘==’\r\n The type variable ‘a0’ is ambiguous\r\n Relevant bindings include x :: a0 (bound at <interactive>:6:5)\r\n Note: there are several potential instances:\r\n instance Eq a => Eq (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’\r\n instance Eq Integer -- Defined in ‘integer-gmp:GHC.Integer.Type’\r\n instance Eq () -- Defined in ‘GHC.Classes’\r\n ...plus 33 others\r\n In the expression: (x == 3)\r\n In the first argument of ‘f’, namely ‘(\\ x -> (x == 3))’\r\n In the expression: f (\\ x -> (x == 3))\r\n\r\n<interactive>:6:16:\r\n No instance for (Num a0) arising from the literal ‘3’\r\n The type variable ‘a0’ is ambiguous\r\n Relevant bindings include x :: a0 (bound at <interactive>:6:5)\r\n Note: there are several potential instances:\r\n instance Num Double -- Defined in ‘GHC.Float’\r\n instance Num Float -- Defined in ‘GHC.Float’\r\n instance Integral a => Num (GHC.Real.Ratio a)\r\n -- Defined in ‘GHC.Real’\r\n ...plus 7 others\r\n In the second argument of ‘(==)’, namely ‘3’\r\n In the expression: (x == 3)\r\n In the first argument of ‘f’, namely ‘(\\ x -> (x == 3))’\r\n\r\n}}}\r\n\r\nOn the other hand,\r\n\r\n\r\n{{{\r\nskata@kata58:~$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.4.1\r\nskata@kata58:~$ ghci\r\nGHCi, version 7.4.1: 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\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f = undefined}\r\nPrelude Data.Typeable> f (\\x -> (x == 3))\r\n*** Exception: Prelude.undefined\r\nPrelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f = undefined}\r\nPrelude Data.Typeable> f (\\x -> (x == 3))\r\n*** Exception: Prelude.undefined\r\n}}}\r\n\r\nI think the old behavior is compliant with the documentation.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8917:kind! does not work under type constructors2019-07-07T18:42:49ZRichard Eisenbergrae@richarde.dev:kind! does not work under type constructorsSay I have the following:
```
{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-}
module Scratch where
data Nat = Zero | Succ Nat
type family a + b where
Zero + a = a
(Succ n) + m = Succ (n + m)
```
I load this into ghci. See wha...Say I have the following:
```
{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-}
module Scratch where
data Nat = Zero | Succ Nat
type family a + b where
Zero + a = a
(Succ n) + m = Succ (n + m)
```
I load this into ghci. See what happens next:
```
GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Scratch ( Scratch.hs, interpreted )
Ok, modules loaded: Scratch.
*Scratch> :kind! Zero + Succ Zero
Zero + Succ Zero :: Nat
= 'Succ 'Zero
*Scratch> :kind! Succ (Zero + Zero)
Succ (Zero + Zero) :: Nat
= 'Succ ('Zero + 'Zero)
```
Note the last line. It doesn't reduce under the `Succ`!
I will fix shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":":kind! does not work under type constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Say I have the following:\r\n\r\n{{{\r\n{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-}\r\n\r\nmodule Scratch where\r\n\r\ndata Nat = Zero | Succ Nat\r\ntype family a + b where\r\n Zero + a = a\r\n (Succ n) + m = Succ (n + m)\r\n}}}\r\n\r\nI load this into ghci. See what happens next:\r\n\r\n{{{\r\nGHCi, version 7.8.0.20140228: 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\n[1 of 1] Compiling Scratch ( Scratch.hs, interpreted )\r\nOk, modules loaded: Scratch.\r\n*Scratch> :kind! Zero + Succ Zero\r\nZero + Succ Zero :: Nat\r\n= 'Succ 'Zero\r\n*Scratch> :kind! Succ (Zero + Zero)\r\nSucc (Zero + Zero) :: Nat\r\n= 'Succ ('Zero + 'Zero)\r\n}}}\r\n\r\nNote the last line. It doesn't reduce under the `Succ`!\r\n\r\nI will fix shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/8893-XPolyKinds causes "*** Exception: Prelude.(!!): index too large"2019-07-07T18:42:55Zghorn-XPolyKinds causes "*** Exception: Prelude.(!!): index too large"The following program will compile fine:
```
{-# OPTIONS_GHC -Wall #-}
{-# Language DeriveFunctor #-}
--{-# Language PolyKinds #-}
module Bug where
data V a = V [a] deriving Functor
data C x a = C (V (P x a)) deriving Functor
data P...The following program will compile fine:
```
{-# OPTIONS_GHC -Wall #-}
{-# Language DeriveFunctor #-}
--{-# Language PolyKinds #-}
module Bug where
data V a = V [a] deriving Functor
data C x a = C (V (P x a)) deriving Functor
data P x a = P (x a) deriving Functor
```
But when PolyKinds is enabled, GHC crashes with
```
$ ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:37:ghc: panic! (the 'impossible' happened)
(GHC version 7.8.0.20140228 for x86_64-unknown-linux):
Prelude.(!!): index too large
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"-XPolyKinds causes \"*** Exception: Prelude.(!!): index too large\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":["PolyKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program will compile fine:\r\n{{{\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# Language DeriveFunctor #-}\r\n--{-# Language PolyKinds #-}\r\n\r\nmodule Bug where\r\n\r\ndata V a = V [a] deriving Functor\r\n\r\ndata C x a = C (V (P x a)) deriving Functor\r\n\r\ndata P x a = P (x a) deriving Functor\r\n}}}\r\n\r\nBut when PolyKinds is enabled, GHC crashes with\r\n\r\n{{{\r\n$ ghc Bug.hs \r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:9:37:ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.0.20140228 for x86_64-unknown-linux):\r\n\tPrelude.(!!): index too large\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8892Ghc panics (variable not found)2019-07-07T18:42:55ZjwlatoGhc panics (variable not found)When attempting to compile a module with ghc-7.8-RC2, using the flags `--ghc-options=-j8 -O2 -Werror`, I encountered this error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.0.20140228 for x86_64-unknown-linux):
...When attempting to compile a module with ghc-7.8-RC2, using the flags `--ghc-options=-j8 -O2 -Werror`, I encountered this error:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.0.20140228 for x86_64-unknown-linux):
StgCmmEnv: variable not found
foldlM'_loop{v i1iSV} [lid]
local binds for:
```
followed by about 1100 bindings (none of are the binding in question). Omitting the `-j` flag makes no difference. Building `-O0` succeeds.
I don't have a standalone test case, and it's not clear to me how to make one as I have no idea what's causing this. I'll try to narrow it down, but if anyone could suggest some flags to twiddle or some other factor to adjust I'd appreciate it. I'm suspecting that it's a function referenced from inlining something vector-related.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Ghc panics (variable not found)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When attempting to compile a module with ghc-7.8-RC2, using the flags `--ghc-options=-j8 -O2 -Werror`, I encountered this error:\r\n\r\n{{{\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.0.20140228 for x86_64-unknown-linux):\r\n StgCmmEnv: variable not found\r\n foldlM'_loop{v i1iSV} [lid]\r\n local binds for:\r\n}}}\r\n\r\nfollowed by about 1100 bindings (none of are the binding in question). Omitting the `-j` flag makes no difference. Building `-O0` succeeds.\r\n\r\nI don't have a standalone test case, and it's not clear to me how to make one as I have no idea what's causing this. I'll try to narrow it down, but if anyone could suggest some flags to twiddle or some other factor to adjust I'd appreciate it. I'm suspecting that it's a function referenced from inlining something vector-related.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8889GHCI reports nasty type signatures2019-07-07T18:42:56ZMikeIzbickiGHCI reports nasty type signaturesLoad a file that contains:
```
{-# LANGUAGE TypeFamilies
, ConstraintKinds
, MultiParamTypeClasses
, UndecidableInstances
, FlexibleInstances
#-}
import GHC.Prim
import Prelude hiding (Fun...Load a file that contains:
```
{-# LANGUAGE TypeFamilies
, ConstraintKinds
, MultiParamTypeClasses
, UndecidableInstances
, FlexibleInstances
#-}
import GHC.Prim
import Prelude hiding (Functor(..))
class Functor f where
type C_fmap_a f a :: Constraint
type C_fmap_a f a = ()
type C_fmap_b f b :: Constraint
type C_fmap_b f b = ()
fmap :: (C_fmap_a f a, C_fmap_b f b) => (a -> b) -> f a -> f b
fmap1 :: (ValidFunctor f a, ValidFunctor f b) => (a -> b) -> f a -> f b
fmap2 :: (ValidFunctor' f a, ValidFunctor' f b) => (a -> b) -> f a -> f b
type ValidFunctor f a =
( Functor f
, C_fmap_a f a
, C_fmap_b f a
)
class ValidFunctor f a => ValidFunctor' f a
instance ValidFunctor f a => ValidFunctor' f a
```
Then check the following types in ghci
```
ghci> :t fmap
fmap
:: (t, t1, Functor f, C_fmap_b f b ~ t1, C_fmap_a f a ~ t) =>
(a -> b) -> f a -> f b
ghci> :t fmap1
fmap1
:: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,
C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>
(a -> b) -> f a -> f b
ghci> :t fmap2
fmap2
:: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,
C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>
(a -> b) -> f a -> f b
```
These types are much nastier looking than they need to be. There are two problems:
1) Bogus types t,t1,t2,t3 are introduced when they don't need to be. This is confuses the type signatures quite a bit.
2) The type alias ValidFunctor is being desugared in the type signature for fmap1. This makes type aliases for constraints rather pointless.
Also, I tried to solve problem two by adding an extra class, and hoping the class would be displayed instead, but this still doesn't work. I assume this is actually intended behavior though.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCI reports nasty type signatures","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Load a file that contains:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE TypeFamilies\r\n , ConstraintKinds\r\n , MultiParamTypeClasses\r\n , UndecidableInstances\r\n , FlexibleInstances \r\n #-}\r\n\r\nimport GHC.Prim\r\nimport Prelude hiding (Functor(..))\r\n\r\nclass Functor f where\r\n type C_fmap_a f a :: Constraint\r\n type C_fmap_a f a = ()\r\n type C_fmap_b f b :: Constraint\r\n type C_fmap_b f b = ()\r\n fmap :: (C_fmap_a f a, C_fmap_b f b) => (a -> b) -> f a -> f b\r\n\r\n fmap1 :: (ValidFunctor f a, ValidFunctor f b) => (a -> b) -> f a -> f b\r\n fmap2 :: (ValidFunctor' f a, ValidFunctor' f b) => (a -> b) -> f a -> f b\r\n\r\ntype ValidFunctor f a = \r\n ( Functor f\r\n , C_fmap_a f a\r\n , C_fmap_b f a\r\n )\r\n \r\nclass ValidFunctor f a => ValidFunctor' f a\r\ninstance ValidFunctor f a => ValidFunctor' f a\r\n \r\n}}}\r\n\r\nThen check the following types in ghci\r\n{{{\r\nghci> :t fmap\r\nfmap\r\n :: (t, t1, Functor f, C_fmap_b f b ~ t1, C_fmap_a f a ~ t) =>\r\n (a -> b) -> f a -> f b\r\n\r\nghci> :t fmap1\r\nfmap1\r\n :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,\r\n C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>\r\n (a -> b) -> f a -> f b\r\n\r\nghci> :t fmap2\r\nfmap2\r\n :: (t, t1, t2, t3, Functor f, C_fmap_b f b ~ t3, C_fmap_b f a ~ t1,\r\n C_fmap_a f b ~ t2, C_fmap_a f a ~ t) =>\r\n (a -> b) -> f a -> f b\r\n}}}\r\n\r\nThese types are much nastier looking than they need to be. There are two problems:\r\n\r\n1) Bogus types t,t1,t2,t3 are introduced when they don't need to be. This is confuses the type signatures quite a bit.\r\n\r\n2) The type alias ValidFunctor is being desugared in the type signature for fmap1. This makes type aliases for constraints rather pointless.\r\n\r\nAlso, I tried to solve problem two by adding an extra class, and hoping the class would be displayed instead, but this still doesn't work. I assume this is actually intended behavior though.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8888Document Coercible in user's guide2019-07-07T18:42:56ZRichard Eisenbergrae@richarde.devDocument Coercible in user's guideAs far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be...As far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be included.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nomeata |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Document Coercible in user's guide","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nomeata"],"type":"Bug","description":"As far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be included.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8884Reifying closed type families is broken2019-07-07T18:42:57ZRichard Eisenbergrae@richarde.devReifying closed type families is brokenIf I say
```
{-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-}
module Scratch where
import Language.Haskell.TH
type family Foo a where
Foo x = x
$( do FamilyI foo [] <- reify ''Foo
runIO $ putStrLn $ show foo
r...If I say
```
{-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-}
module Scratch where
import Language.Haskell.TH
type family Foo a where
Foo x = x
$( do FamilyI foo [] <- reify ''Foo
runIO $ putStrLn $ show foo
return [] )
```
and compile, I see (with uniques suppressed)
```
ClosedTypeFamilyD Scratch.Foo
[KindedTV a (VarT k)]
(Just (AppT (AppT ArrowT (VarT k)) (VarT k)))
[TySynEqn [VarT k,VarT x] (VarT x)]
```
There are two problems here:
1. The return kind (the third parameter to `ClosedTypeFamilyD`) should be just that -- the return kind. In the output, we see the full kind of the type family. `k -> k`.
1. The equation includes the kind variable `k`, which should be implicit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.1-rc2 |
| 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":"Reifying closed type families is broken","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I say\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-}\r\n\r\nmodule Scratch where\r\n\r\nimport Language.Haskell.TH\r\n\r\ntype family Foo a where\r\n Foo x = x\r\n\r\n$( do FamilyI foo [] <- reify ''Foo\r\n runIO $ putStrLn $ show foo\r\n return [] )\r\n}}}\r\n\r\nand compile, I see (with uniques suppressed)\r\n\r\n{{{\r\nClosedTypeFamilyD Scratch.Foo\r\n [KindedTV a (VarT k)]\r\n (Just (AppT (AppT ArrowT (VarT k)) (VarT k)))\r\n [TySynEqn [VarT k,VarT x] (VarT x)]\r\n}}}\r\n\r\nThere are two problems here:\r\n\r\n1. The return kind (the third parameter to `ClosedTypeFamilyD`) should be just that -- the return kind. In the output, we see the full kind of the type family. `k -> k`.\r\n\r\n2. The equation includes the kind variable `k`, which should be implicit.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/8878Export runTcInteractive from TcRnDriver2019-07-07T18:42:59ZholzenspExport runTcInteractive from TcRnDriverFor people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single...For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes.
(patch to follow shortly)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Export runTcInteractive from TcRnDriver","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes.\r\n\r\n(patch to follow shortly)","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1holzenspholzensphttps://gitlab.haskell.org/ghc/ghc/-/issues/8870GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits2019-07-07T18:43:01ZfacundoqGHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bitsWindows shows a window that says "GHC has stopped working" when compiling a simple hello world.
Steps to reproduce
1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.bz2)
2) Ex...Windows shows a window that says "GHC has stopped working" when compiling a simple hello world.
Steps to reproduce
1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.bz2)
2) Extract the contents of the tar to folder $GHC$
3) Add $GHC$\\bin and $GHC$\\mingw\\bin folder to the PATH, add env var "LANG=C".
4) Create file test.hs with contents:
main = putStrLn "Hello, World!"
5) run "ghc test.hs".
Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully.
GHCi appears to work normally (when doing simple tests).
More details:
http://stackoverflow.com/questions/22291739/cant-install-packages-with-cabal-using-ghc-7-8rc2-and-windows-7
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Windows shows a window that says \"GHC has stopped working\" when compiling a simple hello world.\r\n\r\nSteps to reproduce\r\n1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.bz2)\r\n2) Extract the contents of the tar to folder $GHC$\r\n3) Add $GHC$\\bin and $GHC$\\mingw\\bin folder to the PATH, add env var \"LANG=C\". \r\n4) Create file test.hs with contents:\r\n\r\nmain = putStrLn \"Hello, World!\"\r\n\r\n5) run \"ghc test.hs\".\r\n\r\nInterestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully.\r\n\r\nGHCi appears to work normally (when doing simple tests).\r\n\r\nMore details:\r\nhttp://stackoverflow.com/questions/22291739/cant-install-packages-with-cabal-using-ghc-7-8rc2-and-windows-7","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8865Cannot derive well-kinded instance of form ‘Category2019-07-07T18:43:02ZAlfredo Di NapoliCannot derive well-kinded instance of form ‘CategoryHello everyone,
sorry if this was already reported somewhere.
I'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x
```
newtype ArgArrow a b = ArgAr...Hello everyone,
sorry if this was already reported somewhere.
I'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x
```
newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b)
deriving (Category, Arrow, ArrowChoice)
```
but that yields the following in GHC 7.8.1-RC2
```
Cannot derive well-kinded instance of form ‘Category (ArgArrow ...)’
Class ‘Category’ expects an argument of kind ‘k -> k -> *’
In the newtype declaration for ‘ArgArrow’
```
This might be related to the new feature of GHC 7.8, namely "kind variables" (you get the idea, even if the name is not 100% accurate). To make the code compile I had to enable ` StandaloneDeriving ` and write the following:
```
newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b)
deriving (Arrow, ArrowChoice)
deriving instance Category ArgArrow
```
Is this by design or is a genuine bug? Thanks!
Alfredo
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Cannot derive well-kinded instance of form ‘Category","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello everyone,\r\nsorry if this was already reported somewhere.\r\n\r\nI'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x\r\n\r\n\r\n{{{\r\nnewtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b)\r\n deriving (Category, Arrow, ArrowChoice)\r\n}}}\r\n\r\nbut that yields the following in GHC 7.8.1-RC2\r\n\r\n{{{\r\n Cannot derive well-kinded instance of form ‘Category (ArgArrow ...)’\r\n Class ‘Category’ expects an argument of kind ‘k -> k -> *’\r\n In the newtype declaration for ‘ArgArrow’\r\n}}}\r\n\r\nThis might be related to the new feature of GHC 7.8, namely \"kind variables\" (you get the idea, even if the name is not 100% accurate). To make the code compile I had to enable {{{ StandaloneDeriving }}} and write the following:\r\n\r\n{{{\r\nnewtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b)\r\n deriving (Arrow, ArrowChoice)\r\n\r\nderiving instance Category ArgArrow\r\n}}}\r\n\r\nIs this by design or is a genuine bug? Thanks!\r\n\r\nAlfredo","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8863ghc 7.6.3: type parser accepts => as -> (sometimes)2019-07-07T18:43:03Zpatrikjghc 7.6.3: type parser accepts => as -> (sometimes)The following examples are all parsed and type checked even though they don't seem to be conforming to the Haskell standard syntax:
```haskell
a :: Int => Int
a = (1+)
b :: a -> a => a
b = const
c :: Num a => [a => a => a]
c = [(+)]
`...The following examples are all parsed and type checked even though they don't seem to be conforming to the Haskell standard syntax:
```haskell
a :: Int => Int
a = (1+)
b :: a -> a => a
b = const
c :: Num a => [a => a => a]
c = [(+)]
```
Slight variations fail (as the should) - for example
```haskell
b' :: a -> b => a
b' = const
```
/Patrik
----
```
Linux cse-814009 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
```7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8858Wrong maxStkSize calculation2019-07-07T18:43:04ZawsonWrong maxStkSize calculationWhen fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words.
It did not manifest itself yet, but I've decided to provide a patch.
...When fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words.
It did not manifest itself yet, but I've decided to provide a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong maxStkSize calculation","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words.\r\n\r\nIt did not manifest itself yet, but I've decided to provide a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8857Sparc needs to be on the NoSharedLibsPlatformList2019-07-07T18:43:04ZJoachim Breitnermail@joachim-breitner.deSparc needs to be on the NoSharedLibsPlatformListI see build failures with GHC-7.8 RC2 on sparc:
https://buildd.debian.org/status/logs.php?pkg=ghc&ver=7.8.20140228-1&arch=sparc
These go away if I apply this patch, as suggested by Karel Gardas:
```
Index: ghc-7.8.20140228/mk/config.mk...I see build failures with GHC-7.8 RC2 on sparc:
https://buildd.debian.org/status/logs.php?pkg=ghc&ver=7.8.20140228-1&arch=sparc
These go away if I apply this patch, as suggested by Karel Gardas:
```
Index: ghc-7.8.20140228/mk/config.mk.in
===================================================================
--- ghc-7.8.20140228.orig/mk/config.mk.in 2014-03-06 09:48:52.000000000 +0000
+++ ghc-7.8.20140228/mk/config.mk.in 2014-03-06 09:49:55.000000000 +0000
@@ -98,7 +98,8 @@
NoSharedLibsPlatformList = arm-unknown-linux \
powerpc-unknown-linux \
x86_64-unknown-mingw32 \
- i386-unknown-mingw32
+ i386-unknown-mingw32 \
+ sparc-unknown-linux
ifeq "$(SOLARIS_BROKEN_SHLD)" "YES"
NoSharedLibsPlatformList += i386-unknown-solaris2
```
Please consider applying this fix before next RC or the final release. Thanks!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Sparc needs to be on the NoSharedLibsPlatformList","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I see build failures with GHC-7.8 RC2 on sparc:\r\nhttps://buildd.debian.org/status/logs.php?pkg=ghc&ver=7.8.20140228-1&arch=sparc\r\n\r\nThese go away if I apply this patch, as suggested by Karel Gardas:\r\n{{{\r\nIndex: ghc-7.8.20140228/mk/config.mk.in\r\n===================================================================\r\n--- ghc-7.8.20140228.orig/mk/config.mk.in 2014-03-06 09:48:52.000000000 +0000\r\n+++ ghc-7.8.20140228/mk/config.mk.in 2014-03-06 09:49:55.000000000 +0000\r\n@@ -98,7 +98,8 @@\r\n NoSharedLibsPlatformList = arm-unknown-linux \\\r\n powerpc-unknown-linux \\\r\n x86_64-unknown-mingw32 \\\r\n- i386-unknown-mingw32\r\n+ i386-unknown-mingw32 \\\r\n+ sparc-unknown-linux\r\n \r\n ifeq \"$(SOLARIS_BROKEN_SHLD)\" \"YES\"\r\n NoSharedLibsPlatformList += i386-unknown-solaris2\r\n}}}\r\n\r\nPlease consider applying this fix before next RC or the final release. Thanks!","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8856ScopedTypeVariables & PolyKinds lead to weird error message2019-07-07T18:43:04ZRichard Eisenbergrae@richarde.devScopedTypeVariables & PolyKinds lead to weird error messageWhen I try to compile
```
{-# LANGUAGE ScopedTypeVariables, RankNTypes, PolyKinds #-}
module Bug where
import Data.Proxy
foo = (undefined :: Proxy a) :: forall a. Proxy a
```
I get
```
Bug.hs:7:27:
Kind variable ‘k’ used as a t...When I try to compile
```
{-# LANGUAGE ScopedTypeVariables, RankNTypes, PolyKinds #-}
module Bug where
import Data.Proxy
foo = (undefined :: Proxy a) :: forall a. Proxy a
```
I get
```
Bug.hs:7:27:
Kind variable ‘k’ used as a type
In an expression type signature: Proxy a
In the expression: (undefined :: Proxy a) :: forall a. Proxy a
In an equation for ‘foo’:
foo = (undefined :: Proxy a) :: forall a. Proxy a
```
This is all the more odd given that `k` does not appear in my code!
This bug happens both in HEAD and in 7.8.1 RC 2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"ScopedTypeVariables & PolyKinds lead to weird error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to compile\r\n\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, RankNTypes, PolyKinds #-}\r\n\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\nfoo = (undefined :: Proxy a) :: forall a. Proxy a\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nBug.hs:7:27:\r\n Kind variable ‘k’ used as a type\r\n In an expression type signature: Proxy a\r\n In the expression: (undefined :: Proxy a) :: forall a. Proxy a\r\n In an equation for ‘foo’:\r\n foo = (undefined :: Proxy a) :: forall a. Proxy a\r\n}}}\r\n\r\nThis is all the more odd given that `k` does not appear in my code!\r\n\r\nThis bug happens both in HEAD and in 7.8.1 RC 2.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8855LLVM backend needs to use `-globalopt` explicitly2019-07-07T18:43:05ZBen GamariLLVM backend needs to use `-globalopt` explicitlyWhile `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM f...While `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM from the dynamic linking blacklist)\[1\].
\[1\] https://github.com/bgamari/ghc/commits/ghc-7.8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | <scpmw@leeds.ac.uk>, Peter, Wortmann |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM backend needs to use `-globalopt` explicitly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["<scpmw@leeds.ac.uk>","Peter","Wortmann"],"type":"Bug","description":"While `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM from the dynamic linking blacklist)[1].\r\n\r\n[1] https://github.com/bgamari/ghc/commits/ghc-7.8","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8851Standalone deriving and GND behave differently2019-07-07T18:43:06ZSimon Peyton JonesStandalone deriving and GND behave differentlySergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit:
https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04
Is it an intended behaviour that st...Sergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit:
https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04
Is it an intended behaviour that standalone deriving (A)
```
deriving instance Parsing IdrisInnerParser
```
is capable of doing more, than a deriving clause (B)
```
newtype IdrisInnerParser a
= IdrisInnerParser { runInnerParser :: Parser a }
deriving (Parsing)
```
where the class is defined thus
```
class Alternative m => Parsing m where
....
notFollowedBy :: (Monad m, Show a) => m a -> m ()
notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())
```
The error message from the (B) is
```
[50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o )
src/Idris/ParseHelpers.hs:40:97:
Could not coerce from ‘Monad Parser’ to ‘Monad IdrisInnerParser’
because the first type argument of ‘Monad’ has role Nominal,
but the arguments ‘Parser’ and ‘IdrisInnerParser’ differ
arising from the coercion of the method ‘notFollowedBy’ from type
‘forall a. (Monad Parser, Show a) => Parser a -> Parser ()’ to type
‘forall a.
(Monad IdrisInnerParser, Show a) =>
IdrisInnerParser a -> IdrisInnerParser ()’
Possible fix:
use a standalone 'deriving instance' declaration,
so you can specify the instance context yourself
When deriving the instance for (Parsing IdrisInnerParser)
```
Answer: no they should not behave differently.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Standalone deriving and GND behave differently","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit:\r\n\r\nhttps://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04\r\n\r\nIs it an intended behaviour that standalone deriving (A)\r\n{{{\r\n deriving instance Parsing IdrisInnerParser\r\n}}}\r\nis capable of doing more, than a deriving clause (B)\r\n{{{\r\n newtype IdrisInnerParser a \r\n = IdrisInnerParser { runInnerParser :: Parser a } \r\n deriving (Parsing)\r\n}}}\r\nwhere the class is defined thus\r\n{{{\r\nclass Alternative m => Parsing m where\r\n ....\r\n notFollowedBy :: (Monad m, Show a) => m a -> m ()\r\n notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())\r\n}}}\r\n\r\nThe error message from the (B) is\r\n{{{\r\n[50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o )\r\n\r\nsrc/Idris/ParseHelpers.hs:40:97:\r\n Could not coerce from ‘Monad Parser’ to ‘Monad IdrisInnerParser’\r\n because the first type argument of ‘Monad’ has role Nominal,\r\n but the arguments ‘Parser’ and ‘IdrisInnerParser’ differ\r\n arising from the coercion of the method ‘notFollowedBy’ from type\r\n ‘forall a. (Monad Parser, Show a) => Parser a -> Parser ()’ to type\r\n ‘forall a.\r\n (Monad IdrisInnerParser, Show a) =>\r\n IdrisInnerParser a -> IdrisInnerParser ()’\r\n Possible fix:\r\n use a standalone 'deriving instance' declaration,\r\n so you can specify the instance context yourself\r\n When deriving the instance for (Parsing IdrisInnerParser)\r\n}}}\r\n\r\nAnswer: no they should not behave differently.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1