GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:03:21Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15707More liberally kinded coercions for newtypes2019-07-07T18:03:21ZmniipMore liberally kinded coercions for newtypesConsider the infinite data family (possible thanks to #12369):
```hs
data family I :: k -> k
newtype instance I a = I0 (a)
newtype instance I a x = I1 (a x)
newtype instance I a x y = I2 (a x y)
newtype instance I a x y z = I3 (a x y z)...Consider the infinite data family (possible thanks to #12369):
```hs
data family I :: k -> k
newtype instance I a = I0 (a)
newtype instance I a x = I1 (a x)
newtype instance I a x y = I2 (a x y)
newtype instance I a x y z = I3 (a x y z)
...
```
We end up with a family of eta-contracted coercions:
```hs
forall (a :: *). a ~R I a
forall (a :: k -> *). a ~R I a
forall (a :: k -> l -> *). a ~R I a
forall (a :: k -> l -> m -> *). a ~R I a
...
```
What if we could somehow indicate that we desire a polykinded newtype (so to speak) with a coercion `forall (a :: k). a ~R I a`
Maybe even do so by default: `newtype I a = I0 a` would create such a polykinded coercion. Though the `I0` data constructor and pattern would still only use the \*-kinded restriction of it.
We could then recover other constructors with:
```hs
i1 :: a x -> I a x
i1 = coerce
...
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15705Confusing parser error in 8.62020-02-24T21:36:31ZIavor S. DiatchkiConfusing parser error in 8.6Consider the following example:
```
f x =
case x of
A -> 'a'
B -> 'b'
```
The problem here is that `B` is misaligned, which is quite a common mistake, especially in a bigger case block.
GHC reports the following error:
```
...Consider the following example:
```
f x =
case x of
A -> 'a'
B -> 'b'
```
The problem here is that `B` is misaligned, which is quite a common mistake, especially in a bigger case block.
GHC reports the following error:
```
Unexpected case expression in function application:
case x of { A -> 'a' }
You could write it with parentheses
Or perhaps you meant to enable BlockArguments?
```
This is quite confusing, especially since the program won't parse, `BlockArguments` or not. My guess is that we are being a bit too eager with reporting the `BlockArguments` issue.
One way to work around this would be to just remember if we used `BlockArguments` while parsing, but only do the check that the extension is enabled after a successful parse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Confusing parser error in 8.6","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following example:\r\n{{{\r\nf x =\r\n case x of\r\n A -> 'a'\r\n B -> 'b'\r\n}}}\r\n\r\nThe problem here is that `B` is misaligned, which is quite a common mistake, especially in a bigger case block.\r\n\r\nGHC reports the following error:\r\n{{{\r\n Unexpected case expression in function application:\r\n case x of { A -> 'a' }\r\n You could write it with parentheses\r\n Or perhaps you meant to enable BlockArguments?\r\n}}}\r\nThis is quite confusing, especially since the program won't parse, `BlockArguments` or not. My guess is that we are being a bit too eager with reporting the `BlockArguments` issue.\r\n\r\nOne way to work around this would be to just remember if we used `BlockArguments` while parsing, but only do the check that the extension is enabled after a successful parse.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15704Different saturations of the same polymorphic-kinded type constructor aren't ...2019-07-07T18:03:22ZmniipDifferent saturations of the same polymorphic-kinded type constructor aren't seen as apart types```hs
{-# LANGUAGE TypeFamilies, PolyKinds #-}
module A where
data family D :: k
type family F (a :: k) :: *
type instance F (D Int) = Int
type instance F (f a b) = Char
type instance F (D Int Bool) = Char
```
The last equation, eve...```hs
{-# LANGUAGE TypeFamilies, PolyKinds #-}
module A where
data family D :: k
type family F (a :: k) :: *
type instance F (D Int) = Int
type instance F (f a b) = Char
type instance F (D Int Bool) = Char
```
The last equation, even though a specialization of the middle one, trips up the equality consistency check:
```hs
a.hs:9:15: error:
Conflicting family instance declarations:
F (D Int) = Int -- Defined at a.hs:9:15
F (D Int Bool) = Char -- Defined at a.hs:10:15
|
9 | type instance F (D Int) = Int
| ^
```
So GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.1 |
| 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":"Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE TypeFamilies, PolyKinds #-}\r\n\r\nmodule A where\r\n\r\ndata family D :: k\r\n\r\ntype family F (a :: k) :: *\r\n\r\ntype instance F (D Int) = Int\r\ntype instance F (f a b) = Char\r\ntype instance F (D Int Bool) = Char\r\n}}}\r\n\r\nThe last equation, even though a specialization of the middle one, trips up the equality consistency check:\r\n{{{#!hs\r\na.hs:9:15: error:\r\n Conflicting family instance declarations:\r\n F (D Int) = Int -- Defined at a.hs:9:15\r\n F (D Int Bool) = Char -- Defined at a.hs:10:15\r\n |\r\n9 | type instance F (D Int) = Int\r\n | ^\r\n}}}\r\n\r\nSo GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1mniipmniiphttps://gitlab.haskell.org/ghc/ghc/-/issues/15699Run sanity checker in more testsuite runs2019-07-07T18:03:23ZBen GamariRun sanity checker in more testsuite runsEvery testsuite run should run at least a subset of tests with the sanity checker enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- ...Every testsuite run should run at least a subset of tests with the sanity checker enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Run sanity checker in more testsuite runs","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Every testsuite run should run at least a subset of tests with the sanity checker enabled.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15697Typed holes inferring a more polymorphic type2019-07-08T11:15:20ZsreenidhiTyped holes inferring a more polymorphic typeConsider these two snippets.
```hs
testFailure :: Char
testFailure =
let x = id _
in x
```
Suggestions provided were
```
/home/sreenidhi/Experiments/TypedHole.hs:3:14: error:
• Found hole: _ :: a
Where: ‘a’ is a rigid t...Consider these two snippets.
```hs
testFailure :: Char
testFailure =
let x = id _
in x
```
Suggestions provided were
```
/home/sreenidhi/Experiments/TypedHole.hs:3:14: error:
• Found hole: _ :: a
Where: ‘a’ is a rigid type variable bound by
the inferred type of x :: a
at /home/sreenidhi/Experiments/TypedHole.hs:3:7-14
• In the first argument of ‘id’, namely ‘_’
In the expression: id _
In an equation for ‘x’: x = id _
• Relevant bindings include
x :: a (bound at /home/sreenidhi/Experiments/TypedHole.hs:3:7)
testFailure :: Char
(bound at /home/sreenidhi/Experiments/TypedHole.hs:2:1)
```
whereas for this one
```hs
testSuccess :: Char
testSuccess = _
```
It correctly suggests
```
/home/sreenidhi/Experiments/TypedHole.hs:7:15: error:
• Found hole: _ :: Char
• In the expression: _
In an equation for ‘testSuccess’: testSuccess = _
• Relevant bindings include
testSuccess :: Char
(bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1)
Valid hole fits include
testSuccess :: Char
(bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1)
testFailure :: Char
(defined at /home/sreenidhi/Experiments/TypedHole.hs:2:1)
maxBound :: forall a. Bounded a => a
with maxBound @Char
(imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1
(and originally defined in ‘GHC.Enum’))
minBound :: forall a. Bounded a => a
with minBound @Char
(imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1
(and originally defined in ‘GHC.Enum’))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Typed holes inferring a more polymorphic type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider these two snippets.\r\n\r\n{{{#!hs\r\ntestFailure :: Char\r\ntestFailure =\r\n let x = id _\r\n in x\r\n}}}\r\n\r\n\r\nSuggestions provided were\r\n{{{\r\n/home/sreenidhi/Experiments/TypedHole.hs:3:14: error:\r\n • Found hole: _ :: a\r\n Where: ‘a’ is a rigid type variable bound by\r\n the inferred type of x :: a\r\n at /home/sreenidhi/Experiments/TypedHole.hs:3:7-14\r\n • In the first argument of ‘id’, namely ‘_’\r\n In the expression: id _\r\n In an equation for ‘x’: x = id _\r\n • Relevant bindings include\r\n x :: a (bound at /home/sreenidhi/Experiments/TypedHole.hs:3:7)\r\n testFailure :: Char\r\n (bound at /home/sreenidhi/Experiments/TypedHole.hs:2:1)\r\n\r\n}}}\r\n\r\nwhereas for this one\r\n\r\n{{{#!hs\r\ntestSuccess :: Char\r\ntestSuccess = _\r\n}}}\r\n\r\nIt correctly suggests\r\n\r\n{{{\r\n/home/sreenidhi/Experiments/TypedHole.hs:7:15: error:\r\n • Found hole: _ :: Char\r\n • In the expression: _\r\n In an equation for ‘testSuccess’: testSuccess = _\r\n • Relevant bindings include\r\n testSuccess :: Char\r\n (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1)\r\n Valid hole fits include\r\n testSuccess :: Char\r\n (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1)\r\n testFailure :: Char\r\n (defined at /home/sreenidhi/Experiments/TypedHole.hs:2:1)\r\n maxBound :: forall a. Bounded a => a\r\n with maxBound @Char\r\n (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1\r\n (and originally defined in ‘GHC.Enum’))\r\n minBound :: forall a. Bounded a => a\r\n with minBound @Char\r\n (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1\r\n (and originally defined in ‘GHC.Enum’))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15694GHC panic from pattern synonym, "Type-correct unfilled coercion hole"2019-07-07T18:03:25ZIcelandjackGHC panic from pattern synonym, "Type-correct unfilled coercion hole"```hs
{-# Language RankNTypes, PatternSynonyms, TypeOperators, DataKinds, PolyKinds, KindSignatures, GADTs #-}
import Data.Kind
import Data.Type.Equality
data Ctx :: Type -> Type where
E :: Ctx(Type)
(:&:) :: a -> Ctx(as) -> Ctx(...```hs
{-# Language RankNTypes, PatternSynonyms, TypeOperators, DataKinds, PolyKinds, KindSignatures, GADTs #-}
import Data.Kind
import Data.Type.Equality
data Ctx :: Type -> Type where
E :: Ctx(Type)
(:&:) :: a -> Ctx(as) -> Ctx(a -> as)
data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where
AO :: a -> ApplyT(Type) a E
AS :: ApplyT(ks) (f a) ctx
-> ApplyT(k -> ks) f (a:&:ctx)
pattern ASSO :: () => forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx ks) (ks1 :: Type) k1 (a2 :: k1) (ctx1 :: Ctx ks1) a3. (kind ~ (k -> ks), a ~~ f, b ~~ (a1 :&: ctx), ks ~ (k1 -> ks1), ctx ~~ (a2 :&: E), ks1 ~ Type, f a1 a2 ~~ a3) => a3 -> ApplyT kind a b
pattern ASSO a = AS (AS (AO a))
```
```
$ ghci -ignore-dot-ghci 465.hs
GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 465.hs, interpreted )
WARNING: file compiler/types/TyCoRep.hs, line 2378
in_scope InScope {kind_a1Cw a_a1Cx b_a1Cy ks_a1Cz k_a1CA f_a1CB
a1_a1CC ctx_a1CD ks1_a1CE k1_a1CF a2_a1CG ctx1_a1CH a3_a1CI
k0_a1F8}
tenv [a1Cw :-> kind_a1Cw[sk:0], a1Cx :-> a_a1Cx[sk:0],
a1Cy :-> b_a1Cy[sk:0], a1Cz :-> ks_a1Cz[sk:0],
a1CA :-> k_a1CA[sk:0], a1CB :-> f_a1CB[sk:0],
a1CC :-> a1_a1CC[sk:0], a1CD :-> ctx_a1CD[sk:0],
a1CE :-> ks1_a1CE[sk:0], a1CF :-> k1_a1CF[sk:0],
a1CG :-> a2_a1CG[sk:0], a1CH :-> ctx1_a1CH[sk:0],
a1CI :-> a3_a1CI[sk:0]]
cenv []
tys [kind_a1Cw[sk:1] ~ (k_a1CA[sk:2] -> ks_a1Cz[sk:2]),
a_a1Cx[sk:1] ~~ f_a1CB[sk:2],
b_a1Cy[sk:1] ~~ (a1_a1CC[sk:2] ':&: ctx_a1CD[sk:2]),
ks_a1Cz[sk:2] ~ (k1_a1CF[sk:2] -> ks1_a1CE[sk:2]),
ctx_a1CD[sk:2] ~~ (a2_a1CG[sk:2] ':&: 'E), ks1_a1CE[sk:2] ~ *,
(f_a1CB[sk:2] a1_a1CC[sk:2] |> {co_a1Fc}) a2_a1CG[sk:2]
~~ a3_a1CI[sk:2]]
cos []
needInScope [a1F8 :-> k0_a1F8[sk:2], a1Fc :-> co_a1Fc]
WARNING: file compiler/types/TyCoRep.hs, line 2378
in_scope InScope {kind_a1Cw a_a1Cx b_a1Cy k0_a1HA ks_a1HB k_a1HC
f_a1HD a1_a1HE ctx_a1HF ks1_a1HG k1_a1HH a2_a1HI ctx1_a1HJ a3_a1HK}
tenv [a1Cz :-> ks_a1HB[tau:4], a1CA :-> k_a1HC[tau:4],
a1CB :-> f_a1HD[tau:4], a1CC :-> a1_a1HE[tau:4],
a1CD :-> ctx_a1HF[tau:4], a1CE :-> ks1_a1HG[tau:4],
a1CF :-> k1_a1HH[tau:4], a1CG :-> a2_a1HI[tau:4],
a1CH :-> ctx1_a1HJ[tau:4], a1CI :-> a3_a1HK[tau:4],
a1F8 :-> k0_a1HA[tau:4]]
cenv []
tys [kind_a1Cw[sk:0] ~ (k_a1CA[sk:0] -> ks_a1Cz[sk:0]),
a_a1Cx[sk:0] ~~ f_a1CB[sk:0],
b_a1Cy[sk:0] ~~ (a1_a1CC[sk:0] ':&: ctx_a1CD[sk:0]),
ks_a1Cz[sk:0] ~ (k1_a1CF[sk:0] -> ks1_a1CE[sk:0]),
ctx_a1CD[sk:0] ~~ (a2_a1CG[sk:0] ':&: 'E), ks1_a1CE[sk:0] ~ *,
(f_a1CB[sk:0] a1_a1CC[sk:0] |> {co_a1Fc}) a2_a1CG[sk:0]
~~ a3_a1CI[sk:0]]
cos []
needInScope [a1Cw :-> kind_a1Cw[sk:0], a1Cx :-> a_a1Cx[sk:0],
a1Cy :-> b_a1Cy[sk:0], a1Fc :-> co_a1Fc]
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20180828 for x86_64-unknown-linux):
ASSERT failed!
Type-correct unfilled coercion hole {co_a1Fc}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1716:99 in ghc:TcHsSyn
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15693Abstracting out pattern into a pattern synonym fails with scary error2019-07-07T18:03:25ZIcelandjackAbstracting out pattern into a pattern synonym fails with scary errorThis **works**
```hs
{-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-}
import Data.Kind
data Ctx :: Type -> Type where
E :: Ctx(Type)
(:&:) :: a -> Ctx(as) -> Ctx(a -> as)
data ApplyT(kind::Type) :: k...This **works**
```hs
{-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-}
import Data.Kind
data Ctx :: Type -> Type where
E :: Ctx(Type)
(:&:) :: a -> Ctx(as) -> Ctx(a -> as)
data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where
AO :: a -> ApplyT(Type) a E
AS :: ApplyT(ks) (f a) ctx
-> ApplyT(k -> ks) f (a:&:ctx)
foo :: ApplyT(Type -> Type -> Type) Either a -> ()
foo (ASSO (Left a)) = ()
pattern ASSO a = AS (AS (AO a))
```
but then you might think, let's give a name (pattern synonym) to `ASSO (Left a)`
This **fails**
```hs
{-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-}
import Data.Kind
data Ctx :: Type -> Type where
E :: Ctx(Type)
(:&:) :: a -> Ctx(as) -> Ctx(a -> as)
data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where
AO :: a -> ApplyT(Type) a E
AS :: ApplyT(ks) (f a) ctx
-> ApplyT(k -> ks) f (a:&:ctx)
pattern ASSO a = AS (AS (AO a))
pattern ASSOLeft a = ASSO (Left a)
```
```
$ ghci -ignore-dot-ghci 464.hs
GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( hs/464.hs, interpreted )
hs/464.hs:16:22: error:
• Couldn't match type ‘k1’ with ‘*’
‘k1’ is a rigid type variable bound by
the signature for pattern synonym ‘ASSOLeft’
at hs/464.hs:16:1-34
Expected type: ApplyT kind a b
Actual type: ApplyT (* -> * -> *) Either (a1 ':&: (a20 ':&: 'E))
• In the expression: ASSO (Left a)
In an equation for ‘ASSOLeft’: ASSOLeft a = ASSO (Left a)
|
16 | pattern ASSOLeft a = ASSO (Left a)
| ^^^^^^^^^^^^^
hs/464.hs:16:28: error:
• Could not deduce: k1 ~ *
from the context: (kind ~ (k -> ks), a ~~ f, b ~~ (a2 ':&: ctx),
ks ~ (k1 -> ks1), f a2 ~~ f1, ctx ~~ (a3 ':&: ctx1), ks1 ~ *,
f1 a3 ~~ a4, ctx1 ~~ 'E)
bound by a pattern with pattern synonym:
ASSO :: forall kind (a :: kind) (b :: Ctx kind).
() =>
forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx
ks) ks1 k1 (f1 :: k1
-> ks1) (a2 :: k1) (ctx1 :: Ctx
ks1) a3.
(kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1),
f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3,
ctx1 ~~ 'E) =>
a3 -> ApplyT kind a b,
in a pattern synonym declaration
at hs/464.hs:16:22-34
‘k1’ is a rigid type variable bound by
a pattern with pattern synonym:
ASSO :: forall kind (a :: kind) (b :: Ctx kind).
() =>
forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx
ks) ks1 k1 (f1 :: k1
-> ks1) (a2 :: k1) (ctx1 :: Ctx
ks1) a3.
(kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1),
f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3,
ctx1 ~~ 'E) =>
a3 -> ApplyT kind a b,
in a pattern synonym declaration
at hs/464.hs:16:22-34
When matching types
a3 :: k1
b0 :: *
Expected type: a4
Actual type: Either a1 b0
• In the pattern: Left a
In the pattern: ASSO (Left a)
In the declaration for pattern synonym ‘ASSOLeft’
|
16 | pattern ASSOLeft a = ASSO (Left a)
| ^^^^^^
Failed, no modules loaded.
Prelude>
```
----
Can I, as a user, assume that any valid pattern `foo (ASSO (Left a)) = ...` can be abstracted into a pattern synonym? There error message is too scary for me to sensibly know what to expect
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Abstracting out pattern into a pattern synonym fails with scary error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This '''works'''\r\n\r\n{{{#!hs\r\n{-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Ctx :: Type -> Type where\r\n E :: Ctx(Type)\r\n (:&:) :: a -> Ctx(as) -> Ctx(a -> as)\r\n\r\ndata ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where\r\n AO :: a -> ApplyT(Type) a E\r\n AS :: ApplyT(ks) (f a) ctx\r\n -> ApplyT(k -> ks) f (a:&:ctx)\r\n\r\nfoo :: ApplyT(Type -> Type -> Type) Either a -> ()\r\nfoo (ASSO (Left a)) = ()\r\n\r\npattern ASSO a = AS (AS (AO a))\r\n}}}\r\n\r\nbut then you might think, let's give a name (pattern synonym) to `ASSO (Left a)`\r\n\r\nThis '''fails'''\r\n{{{#!hs\r\n{-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Ctx :: Type -> Type where\r\n E :: Ctx(Type)\r\n (:&:) :: a -> Ctx(as) -> Ctx(a -> as)\r\n\r\ndata ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where\r\n AO :: a -> ApplyT(Type) a E\r\n AS :: ApplyT(ks) (f a) ctx\r\n -> ApplyT(k -> ks) f (a:&:ctx)\r\n\r\npattern ASSO a = AS (AS (AO a))\r\n\r\npattern ASSOLeft a = ASSO (Left a)\r\n}}}\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci 464.hs\r\nGHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( hs/464.hs, interpreted )\r\n\r\nhs/464.hs:16:22: error:\r\n • Couldn't match type ‘k1’ with ‘*’\r\n ‘k1’ is a rigid type variable bound by\r\n the signature for pattern synonym ‘ASSOLeft’\r\n at hs/464.hs:16:1-34\r\n Expected type: ApplyT kind a b\r\n Actual type: ApplyT (* -> * -> *) Either (a1 ':&: (a20 ':&: 'E))\r\n • In the expression: ASSO (Left a)\r\n In an equation for ‘ASSOLeft’: ASSOLeft a = ASSO (Left a)\r\n |\r\n16 | pattern ASSOLeft a = ASSO (Left a)\r\n | ^^^^^^^^^^^^^\r\n\r\nhs/464.hs:16:28: error:\r\n • Could not deduce: k1 ~ *\r\n from the context: (kind ~ (k -> ks), a ~~ f, b ~~ (a2 ':&: ctx),\r\n ks ~ (k1 -> ks1), f a2 ~~ f1, ctx ~~ (a3 ':&: ctx1), ks1 ~ *,\r\n f1 a3 ~~ a4, ctx1 ~~ 'E)\r\n bound by a pattern with pattern synonym:\r\n ASSO :: forall kind (a :: kind) (b :: Ctx kind).\r\n () =>\r\n forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx\r\n ks) ks1 k1 (f1 :: k1\r\n -> ks1) (a2 :: k1) (ctx1 :: Ctx\r\n ks1) a3.\r\n (kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1),\r\n f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3,\r\n ctx1 ~~ 'E) =>\r\n a3 -> ApplyT kind a b,\r\n in a pattern synonym declaration\r\n at hs/464.hs:16:22-34\r\n ‘k1’ is a rigid type variable bound by\r\n a pattern with pattern synonym:\r\n ASSO :: forall kind (a :: kind) (b :: Ctx kind).\r\n () =>\r\n forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx\r\n ks) ks1 k1 (f1 :: k1\r\n -> ks1) (a2 :: k1) (ctx1 :: Ctx\r\n ks1) a3.\r\n (kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1),\r\n f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3,\r\n ctx1 ~~ 'E) =>\r\n a3 -> ApplyT kind a b,\r\n in a pattern synonym declaration\r\n at hs/464.hs:16:22-34\r\n When matching types\r\n a3 :: k1\r\n b0 :: *\r\n Expected type: a4\r\n Actual type: Either a1 b0\r\n • In the pattern: Left a\r\n In the pattern: ASSO (Left a)\r\n In the declaration for pattern synonym ‘ASSOLeft’\r\n |\r\n16 | pattern ASSOLeft a = ASSO (Left a)\r\n | ^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\n----\r\n\r\nCan I, as a user, assume that any valid pattern `foo (ASSO (Left a)) = ...` can be abstracted into a pattern synonym? There error message is too scary for me to sensibly know what to expect","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15691Marking Pred(S n) = n as injective2019-07-07T18:03:26ZIcelandjackMarking Pred(S n) = n as injectiveShould `Pred` be injective? Please close the ticket if this is a known limitation
```hs
{-# Language DataKinds, TypeFamilyDependencies #-}
data N = O | S N
type family
Pred n = res | res -> n where
Pred(S n) = n
```
fails with
```...Should `Pred` be injective? Please close the ticket if this is a known limitation
```hs
{-# Language DataKinds, TypeFamilyDependencies #-}
data N = O | S N
type family
Pred n = res | res -> n where
Pred(S n) = n
```
fails with
```
• Type family equation violates injectivity annotation.
RHS of injective type family equation is a bare type variable
but these LHS type and kind patterns are not bare variables: ‘'S n’
Pred ('S n) = n -- Defined at 462.hs:7:2
• In the equations for closed type family ‘Pred’
In the type family declaration for ‘Pred’
|
7 | Pred(S n) = n
| ^^^^^^^^^^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.1 |
| 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":"Marking Pred(S n) = n as injective","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["InjectiveFamilies","TypeFamilies,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Should `Pred` be injective? Please close the ticket if this is a known limitation \r\n\r\n{{{#!hs\r\n{-# Language DataKinds, TypeFamilyDependencies #-}\r\n\r\ndata N = O | S N\r\n\r\ntype family\r\n Pred n = res | res -> n where\r\n Pred(S n) = n\r\n}}}\r\n\r\nfails with\r\n\r\n{{{\r\n • Type family equation violates injectivity annotation.\r\n RHS of injective type family equation is a bare type variable\r\n but these LHS type and kind patterns are not bare variables: ‘'S n’\r\n Pred ('S n) = n -- Defined at 462.hs:7:2\r\n • In the equations for closed type family ‘Pred’\r\n In the type family declaration for ‘Pred’\r\n |\r\n7 | Pred(S n) = n\r\n | ^^^^^^^^^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15689s390x builds flood with -Wunused-label warnings2023-01-18T15:42:57ZJens Petersens390x builds flood with -Wunused-label warningsThis has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.
For example this build: https://k...This has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.
For example this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=29940997 (note the logs are only kept for 2 weeks)
The build.log is 11MB and this is just for compiling less than half of ghc-cabal (270 modules), which generated around 50k unused-label warnings!! So you can imagine the size of a full build.
(Well ghc-8.2.2.69.fc29 full build.log was "only" 33MB for s390x vs 8.8MB for x86_64.)
For now I patched warnings.mk on s390x to workaround this, but it would be better to fix the root cause I suppose.
Here is a small part of the buildlog:
```
"/usr/bin/ghc" -H32m -O -Wall \
-optc-Wall -optc-fno-stack-protector \
\
-hide-all-packages \
-package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \
--make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \
-no-user-package-db \
-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
-DCABAL_VERSION=2,2,0,1 \
-DCABAL_PARSEC \
-DBOOTSTRAPPING \
-odir bootstrapping \
-hidir bootstrapping \
libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \
-ilibraries/Cabal/Cabal \
-ilibraries/binary/src \
-ilibraries/filepath \
-ilibraries/hpc \
-ilibraries/mtl \
-ilibraries/text \
libraries/text/cbits/cbits.c \
-Ilibraries/text/include \
-ilibraries/parsec/src \
\
"rm" -f compiler/stage1/build/Config.hs
Creating compiler/stage1/build/Config.hs ...
done.
"rm" -f utils/ghc-pkg/dist/build/Version.hs
echo "module Version where" >> utils/ghc-pkg/dist/build/Version.hs
echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist/build/Version.hs
echo "version = \"8.4.3\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetOS = \"linux\"" >> utils/ghc-pkg/dist/build/Version.hs
echo "targetARCH = \"s390x\"" >> utils/ghc-pkg/dist/build/Version.hs
[ 1 of 270] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o )
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:16:1: error:
warning: label ‘_c3bA’ defined but not used [-Wunused-label]
_c3bA:
^~~~~
|
16 | _c3bA:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bx_entry’:
/tmp/ghc705e_0/ghc_130.hc:34:1: error:
warning: label ‘_c3bx’ defined but not used [-Wunused-label]
_c3bx:
^~~~~
|
34 | _c3bx:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_callCC_entry’:
/tmp/ghc705e_0/ghc_130.hc:54:1: error:
warning: label ‘_c3bO’ defined but not used [-Wunused-label]
_c3bO:
^~~~~
|
54 | _c3bO:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bL_entry’:
/tmp/ghc705e_0/ghc_130.hc:72:1: error:
warning: label ‘_c3bL’ defined but not used [-Wunused-label]
_c3bL:
^~~~~
|
72 | _c3bL:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38I_entry’:
/tmp/ghc705e_0/ghc_130.hc:98:1: error:
warning: label ‘_c3ca’ defined but not used [-Wunused-label]
_c3ca:
^~~~~
|
98 | _c3ca:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38J_entry’:
/tmp/ghc705e_0/ghc_130.hc:125:1: error:
warning: label ‘_c3cf’ defined but not used [-Wunused-label]
_c3cf:
^~~~~
|
125 | _c3cf:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT1_entry’:
/tmp/ghc705e_0/ghc_130.hc:152:1: error:
warning: label ‘_c3ck’ defined but not used [-Wunused-label]
_c3ck:
^~~~~
|
152 | _c3ck:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38M_entry’:
/tmp/ghc705e_0/ghc_130.hc:181:1: error:
warning: label ‘_c3cx’ defined but not used [-Wunused-label]
_c3cx:
^~~~~
|
181 | _c3cx:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorTzuzdcp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:206:1: error:
warning: label ‘_c3cA’ defined but not used [-Wunused-label]
_c3cA:
^~~~~
|
206 | _c3cA:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Q_entry’:
/tmp/ghc705e_0/ghc_130.hc:235:1: error:
warning: label ‘_c3cO’ defined but not used [-Wunused-label]
_c3cO:
^~~~~
|
235 | _c3cO:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38P_entry’:
/tmp/ghc705e_0/ghc_130.hc:257:1: error:
warning: label ‘_c3cV’ defined but not used [-Wunused-label]
_c3cV:
^~~~~
|
257 | _c3cV:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT_entry’:
/tmp/ghc705e_0/ghc_130.hc:285:1: error:
warning: label ‘_c3cZ’ defined but not used [-Wunused-label]
_c3cZ:
^~~~~
|
285 | _c3cZ:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38W_entry’:
/tmp/ghc705e_0/ghc_130.hc:323:1: error:
warning: label ‘_c3dj’ defined but not used [-Wunused-label]
_c3dj:
^~~~~
|
323 | _c3dj:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38X_entry’:
/tmp/ghc705e_0/ghc_130.hc:350:1: error:
warning: label ‘_c3do’ defined but not used [-Wunused-label]
_c3do:
^~~~~
|
350 | _c3do:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptT1_entry’:
/tmp/ghc705e_0/ghc_130.hc:377:1: error:
warning: label ‘_c3dt’ defined but not used [-Wunused-label]
_c3dt:
^~~~~
|
377 | _c3dt:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Z_entry’:
/tmp/ghc705e_0/ghc_130.hc:411:1: error:
warning: label ‘_c3dG’ defined but not used [-Wunused-label]
_c3dG:
^~~~~
|
411 | _c3dG:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptTzuzdcp1MonadCont_entry’:
/tmp/ghc705e_0/ghc_130.hc:435:1: error:
warning: label ‘_c3dJ’ defined but not used [-Wunused-label]
_c3dJ:
^~~~~
|
435 | _c3dJ:
| ^
/tmp/ghc705e_0/ghc_130.hc: In function ‘s392_entry’:
/tmp/ghc705e_0/ghc_130.hc:462:1: error:
warning: label ‘_c3dX’ defined but not used [-Wunused-label]
_c3dX:
^~~~~
|
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"s390x builds flood with -Wunused-label warnings","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output.\r\n\r\nFor example this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=29940997 (note the logs are only kept for 2 weeks)\r\nThe build.log is 11MB and this is just for compiling less than half of ghc-cabal (270 modules), which generated around 50k unused-label warnings!! So you can imagine the size of a full build.\r\n\r\n(Well ghc-8.2.2.69.fc29 full build.log was \"only\" 33MB for s390x vs 8.8MB for x86_64.)\r\n\r\nFor now I patched warnings.mk on s390x to workaround this, but it would be better to fix the root cause I suppose.\r\n\r\nHere is a small part of the buildlog:\r\n\r\n{{{\r\n\"/usr/bin/ghc\" -H32m -O -Wall \\\r\n -optc-Wall -optc-fno-stack-protector \\\r\n \\\r\n -hide-all-packages \\\r\n -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \\\r\n --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \\\r\n -no-user-package-db \\\r\n -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \\\r\n -DCABAL_VERSION=2,2,0,1 \\\r\n -DCABAL_PARSEC \\\r\n -DBOOTSTRAPPING \\\r\n -odir bootstrapping \\\r\n -hidir bootstrapping \\\r\n libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \\\r\n -ilibraries/Cabal/Cabal \\\r\n -ilibraries/binary/src \\\r\n -ilibraries/filepath \\\r\n -ilibraries/hpc \\\r\n -ilibraries/mtl \\\r\n -ilibraries/text \\\r\n libraries/text/cbits/cbits.c \\\r\n -Ilibraries/text/include \\\r\n -ilibraries/parsec/src \\\r\n \\\r\n \r\n\"rm\" -f compiler/stage1/build/Config.hs \r\nCreating compiler/stage1/build/Config.hs ... \r\ndone.\r\n\"rm\" -f utils/ghc-pkg/dist/build/Version.hs \r\necho \"module Version where\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version, targetOS, targetARCH :: String\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"version = \\\"8.4.3\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetOS = \\\"linux\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\necho \"targetARCH = \\\"s390x\\\"\" >> utils/ghc-pkg/dist/build/Version.hs\r\n[ 1 of 270] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o )\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:16:1: error:\r\n warning: label ‘_c3bA’ defined but not used [-Wunused-label]\r\n _c3bA:\r\n ^~~~~\r\n |\r\n16 | _c3bA:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bx_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:34:1: error:\r\n warning: label ‘_c3bx’ defined but not used [-Wunused-label]\r\n _c3bx:\r\n ^~~~~\r\n |\r\n34 | _c3bx:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_callCC_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:54:1: error:\r\n warning: label ‘_c3bO’ defined but not used [-Wunused-label]\r\n _c3bO:\r\n ^~~~~\r\n |\r\n54 | _c3bO:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘c3bL_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:72:1: error:\r\n warning: label ‘_c3bL’ defined but not used [-Wunused-label]\r\n _c3bL:\r\n ^~~~~\r\n |\r\n72 | _c3bL:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38I_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:98:1: error:\r\n warning: label ‘_c3ca’ defined but not used [-Wunused-label]\r\n _c3ca:\r\n ^~~~~\r\n |\r\n98 | _c3ca:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38J_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:125:1: error:\r\n warning: label ‘_c3cf’ defined but not used [-Wunused-label]\r\n _c3cf:\r\n ^~~~~\r\n |\r\n125 | _c3cf:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT1_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:152:1: error:\r\n warning: label ‘_c3ck’ defined but not used [-Wunused-label]\r\n _c3ck:\r\n ^~~~~\r\n |\r\n152 | _c3ck:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38M_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:181:1: error:\r\n warning: label ‘_c3cx’ defined but not used [-Wunused-label]\r\n _c3cx:\r\n ^~~~~\r\n |\r\n181 | _c3cx:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorTzuzdcp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:206:1: error:\r\n warning: label ‘_c3cA’ defined but not used [-Wunused-label]\r\n _c3cA:\r\n ^~~~~\r\n |\r\n206 | _c3cA:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Q_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:235:1: error:\r\n warning: label ‘_c3cO’ defined but not used [-Wunused-label]\r\n _c3cO:\r\n ^~~~~\r\n |\r\n235 | _c3cO:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38P_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:257:1: error:\r\n warning: label ‘_c3cV’ defined but not used [-Wunused-label]\r\n _c3cV:\r\n ^~~~~\r\n |\r\n257 | _c3cV:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:285:1: error:\r\n warning: label ‘_c3cZ’ defined but not used [-Wunused-label]\r\n _c3cZ:\r\n ^~~~~\r\n |\r\n285 | _c3cZ:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38W_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:323:1: error:\r\n warning: label ‘_c3dj’ defined but not used [-Wunused-label]\r\n _c3dj:\r\n ^~~~~\r\n |\r\n323 | _c3dj:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38X_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:350:1: error:\r\n warning: label ‘_c3do’ defined but not used [-Wunused-label]\r\n _c3do:\r\n ^~~~~\r\n |\r\n350 | _c3do:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptT1_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:377:1: error:\r\n warning: label ‘_c3dt’ defined but not used [-Wunused-label]\r\n _c3dt:\r\n ^~~~~\r\n |\r\n377 | _c3dt:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s38Z_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:411:1: error:\r\n warning: label ‘_c3dG’ defined but not used [-Wunused-label]\r\n _c3dG:\r\n ^~~~~\r\n |\r\n411 | _c3dG:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptTzuzdcp1MonadCont_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:435:1: error:\r\n warning: label ‘_c3dJ’ defined but not used [-Wunused-label]\r\n _c3dJ:\r\n ^~~~~\r\n |\r\n435 | _c3dJ:\r\n | ^\r\n/tmp/ghc705e_0/ghc_130.hc: In function ‘s392_entry’:\r\n/tmp/ghc705e_0/ghc_130.hc:462:1: error:\r\n warning: label ‘_c3dX’ defined but not used [-Wunused-label]\r\n _c3dX:\r\n ^~~~~\r\n |\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15687Type synonym unused binds no warning?2019-07-07T18:03:26ZAntCType synonym unused binds no warning?I was taken aback this was accepted
```hs
type Silly a b = Maybe b
x :: Silly Int Bool
x = Just True
y :: Silly Char Bool
y = Just False
z = x == y -- returns False
```
What's with the `a` in `Silly`'s decl? That'...I was taken aback this was accepted
```hs
type Silly a b = Maybe b
x :: Silly Int Bool
x = Just True
y :: Silly Char Bool
y = Just False
z = x == y -- returns False
```
What's with the `a` in `Silly`'s decl? That's not a phantom type. It's ignored and thrown away. So `x` and `y` are the same type, and can be compare for equality.
I expected a rule: all tyvars in the `type`'s head must appear on rhs. Or at least a warning there was something silly. I tried `-Wall, -fwarn-unused-binds`, `-Wunused-type-patterns`.
I was just checking up on [a remark](https://github.com/ghc-proposals/ghc-proposals/pull/173#issuecomment-424980779) that type synonyms are at the type level like implicit bidirectional pattern synonyms. For those, all vars must appear on both sides.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type synonym unused binds no warning?","status":"New","operating_system":"Windows","component":"Compiler (Parser)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I was taken aback this was accepted\r\n\r\n{{{#!hs\r\ntype Silly a b = Maybe b\r\n\r\nx :: Silly Int Bool\r\nx = Just True\r\ny :: Silly Char Bool\r\ny = Just False\r\n\r\nz = x == y -- returns False\r\n\r\n}}}\r\n\r\nWhat's with the `a` in `Silly`'s decl? That's not a phantom type. It's ignored and thrown away. So `x` and `y` are the same type, and can be compare for equality.\r\n\r\nI expected a rule: all tyvars in the `type`'s head must appear on rhs. Or at least a warning there was something silly. I tried `-Wall, -fwarn-unused-binds`, `-Wunused-type-patterns`.\r\n\r\nI was just checking up on [https://github.com/ghc-proposals/ghc-proposals/pull/173#issuecomment-424980779 a remark] that type synonyms are at the type level like implicit bidirectional pattern synonyms. For those, all vars must appear on both sides.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15684Add tests for SIMD loads and stores2019-07-07T18:03:27ZBen GamariAdd tests for SIMD loads and storesThe NCG SIMD patch tests most of the arithmetic operations but not loads and stores.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...The NCG SIMD patch tests most of the arithmetic operations but not loads and stores.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Add tests for SIMD loads and stores","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The NCG SIMD patch tests most of the arithmetic operations but not loads and stores.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15683coerce fails for Coercible type families2021-10-14T08:39:12ZIcelandjackcoerce fails for Coercible type familiesI want to bring attention to this [reddit post](https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/) that boils down to
```hs
type family X a
type instance X Int = String
type instance X B...I want to bring attention to this [reddit post](https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/) that boils down to
```hs
type family X a
type instance X Int = String
type instance X Bool = String
data T a = T (X a)
```
but not being able to coerce
```hs
coerce :: T Int -> T Bool
```
This gives the error “Couldn't match type ‘`Int`’ with ‘`Bool`’ arising from a use of ‘`coerce`’”.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"coerce fails for Coercible type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to bring attention to this [https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/ reddit post] that boils down to \r\n\r\n{{{#!hs\r\ntype family X a\r\ntype instance X Int = String\r\ntype instance X Bool = String\r\n\r\ndata T a = T (X a)\r\n}}}\r\n\r\nbut not being able to coerce\r\n\r\n{{{#!hs\r\ncoerce :: T Int -> T Bool\r\n}}}\r\n\r\nThis gives the error “Couldn't match type ‘`Int`’ with ‘`Bool`’ arising from a use of ‘`coerce`’”.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15682evolve / improve Native Gen Format in Format.hs (especially in context of pos...2019-07-07T18:03:27ZCarter Schonwaldevolve / improve Native Gen Format in Format.hs (especially in context of post simd cleanup)Currently `GlobalReg` represents the STG machine registers. However, some STG registers get aliased to the same machine registers (e.g. `FloatReg 1` and `DoubleReg 1`; see `Note [Overlapping global registers]`). To make matters worse, we...Currently `GlobalReg` represents the STG machine registers. However, some STG registers get aliased to the same machine registers (e.g. `FloatReg 1` and `DoubleReg 1`; see `Note [Overlapping global registers]`). To make matters worse, we assume that we can always determine the `CmmType` of a `GlobalReg`. However, in the case of SIMD registers this isn't necessarily the case (e.g. a XMM register may contain 1 or 2 double-precision floats, or 1, 2, 4, 8, or 16 integers).
for ghc/compiler/nativeGen/Format.hs
```
data Format
= II8
| II16
| II32
| II64
| FF32
| FF64
| FF80
deriving (Show, Eq)
```
currently this is meant to "encode" both physical bit size AND which register class the value is.
we also have the issue that this register class distinction stops being true once simd integer operations.
this gets worse with simd once we want to track (perhaps?) the size / number of elements used in the xmm/ymm/zmm / arm simd vectors.
perhaps also: signedness?
this actually also relates to how GlobalRegisters and Format are related!
is GlobalRegisters meant for STG machine vs native Machine?
this intersects with ABI questions. Plus we currently have eg Float and Double which are different logically/semantically, BUT the same registers in most native machine architectures
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"evolve / improve Native Gen Format in Format.hs (especially in context of post simd cleanup)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently `GlobalReg` represents the STG machine registers. However, some STG registers get aliased to the same machine registers (e.g. `FloatReg 1` and `DoubleReg 1`; see `Note [Overlapping global registers]`). To make matters worse, we assume that we can always determine the `CmmType` of a `GlobalReg`. However, in the case of SIMD registers this isn't necessarily the case (e.g. a XMM register may contain 1 or 2 double-precision floats, or 1, 2, 4, 8, or 16 integers).\r\n\r\n\r\nfor ghc/compiler/nativeGen/Format.hs \r\n\r\n{{{\r\ndata Format\r\n = II8\r\n | II16\r\n | II32\r\n | II64\r\n | FF32\r\n | FF64\r\n | FF80\r\n deriving (Show, Eq)\r\n}}}\r\n\r\ncurrently this is meant to \"encode\" both physical bit size AND which register class the value is.\r\nwe also have the issue that this register class distinction stops being true once simd integer operations.\r\n\r\nthis gets worse with simd once we want to track (perhaps?) the size / number of elements used in the xmm/ymm/zmm / arm simd vectors.\r\n\r\nperhaps also: signedness?\r\n\r\nthis actually also relates to how GlobalRegisters and Format are related!\r\nis GlobalRegisters meant for STG machine vs native Machine?\r\n\r\nthis intersects with ABI questions. Plus we currently have eg Float and Double which are different logically/semantically, BUT the same registers in most native machine architectures","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15680Flag for printing absolute paths in diagnostics2022-11-20T11:19:42ZquasicomputationalFlag for printing absolute paths in diagnosticsCurrently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.
This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in ...Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.
This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations.
In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output.
[Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.](https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896) I can personally report that this makes the development process a lot more pleasant!
I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding.
I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Flag for printing absolute paths in diagnostics","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.\r\n\r\nThis is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations.\r\n\r\nIn particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output.\r\n\r\n[https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896 Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant!\r\n\r\nI think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding.\r\n\r\nI had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15679Use String rather than [Char] where possible2020-06-05T13:28:30ZSimon Peyton JonesUse String rather than [Char] where possibleTry this in GHCi
```
Prelude> :t "foo"
"foo" :: [Char]
```
It would be better to say
```
"foo" :: String
```
Why don't we? Because of this in `TysWiredIn`
```
stringTy :: Type
stringTy = mkListTy charTy -- convenience only
```
That...Try this in GHCi
```
Prelude> :t "foo"
"foo" :: [Char]
```
It would be better to say
```
"foo" :: String
```
Why don't we? Because of this in `TysWiredIn`
```
stringTy :: Type
stringTy = mkListTy charTy -- convenience only
```
That is, where GHC needs `String` is uses `stringTy` which is just `[Char]`.
How to fix? Two ways:
1. Make `String` into a "wired-in type". That's not hard, but it increases the number of wired-in types, which is generally undesirable.
1. Make `String` into a "knonw-key name", and look it up in the type environment on the (few) occasions where we need `stringTy`. That's a little harder -- notably `hsLitType` would become monadic -- but not difficult.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Use String rather than [Char] where possible","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Try this in GHCi\r\n{{{\r\nPrelude> :t \"foo\"\r\n\"foo\" :: [Char]\r\n}}}\r\nIt would be better to say \r\n{{{\r\n\"foo\" :: String\r\n}}}\r\nWhy don't we? Because of this in `TysWiredIn`\r\n{{{\r\nstringTy :: Type\r\nstringTy = mkListTy charTy -- convenience only\r\n}}}\r\nThat is, where GHC needs `String` is uses `stringTy` which is just `[Char]`. \r\n\r\nHow to fix? Two ways:\r\n\r\n1. Make `String` into a \"wired-in type\". That's not hard, but it increases the number of wired-in types, which is generally undesirable.\r\n\r\n2. Make `String` into a \"knonw-key name\", and look it up in the type environment on the (few) occasions where we need `stringTy`. That's a little harder -- notably `hsLitType` would become monadic -- but not difficult.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15676Users guide: broken external links2019-07-07T18:03:29ZAntCUsers guide: broken external linksSection 10.9 'Type Families' intro has external links to three papers, labelled
\[AssocDataTypes2005\]
\[AssocTypeSyn2005\]
\[TypeFamilies2008\]
The links point to http://www.cse.unsw.edu.au/\~chak/papers/....html. I get Access Forbidd...Section 10.9 'Type Families' intro has external links to three papers, labelled
\[AssocDataTypes2005\]
\[AssocTypeSyn2005\]
\[TypeFamilies2008\]
The links point to http://www.cse.unsw.edu.au/\~chak/papers/....html. I get Access Forbidden Error 403.
Instead they could point to the microsoft research publications versions(?) (Each is co-authored by Chak and SPJ and others.) But beware some of those are draft versions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Users guide: broken external links","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Section 10.9 'Type Families' intro has external links to three papers, labelled\r\n\r\n[AssocDataTypes2005]\t\r\n[AssocTypeSyn2005]\r\n[TypeFamilies2008]\r\n\r\nThe links point to http://www.cse.unsw.edu.au/~chak/papers/....html. I get Access Forbidden Error 403.\r\n\r\nInstead they could point to the microsoft research publications versions(?) (Each is co-authored by Chak and SPJ and others.) But beware some of those are draft versions.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15674GADT's displayed type is misleading2019-07-07T18:03:29ZAntCGADT's displayed type is misleadingGHCi's `:t` alleges these three data constructors have the same type `:: Int -> T Int` (modulo name of the type constructor):
```hs
data DG a where MkDG :: Int -> DG Int
MkDG2 :: (a ~ Int) => a -> DG a
data...GHCi's `:t` alleges these three data constructors have the same type `:: Int -> T Int` (modulo name of the type constructor):
```hs
data DG a where MkDG :: Int -> DG Int
MkDG2 :: (a ~ Int) => a -> DG a
data family DF a
data instance DF Int where MkDF :: Int -> DF Int
```
I tried switching on verbosity flags, but to no avail: `-fprint-explicit-foralls, -fprint-equality-relations`, and a few others.
The `DG` constructors are GADTs, the `DF` constructor is not. So it's not hard to see different type-level behaviour:
```hs
f (MkDF x) = x -- accepted without a signature
-- f :: DF Int -> Int -- inferred signature, or you can spec it
-- f :: DF a -> a -- rejected: signature is too general/
-- a is a rigid type variable
g (MkDG x) = x -- } without a signature, rejected
g (MkDG2 x) = x -- } "untouchable" type (Note)
-- g :: DG Int -> Int -- } g accepted with either sig
-- g :: DG a -> a -- } ?but MkDG doesn't return DG a, allegedly
```
**Note:** at least the error message re `MkDG2` does show its type as `:: (forall a). (a ~ Int) => DG a -> a`. But doggedly `MkDG :: Int -> DG Int`.
"Untouchable" error messages are a fertile source of questions on StackOverflow. The message does say `Possible fix: add a type signature for 'g'`, but gives no clue what the signature might be.
If you've imported these data constructors from a library, such that you can't (easily) see they're GADTs, couldn't `:t` give you better help to show what's going on? Or should one of the verbosity flags already do this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1-beta1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GADT's displayed type is misleading","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1-beta1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"FeatureRequest","description":"GHCi's `:t` alleges these three data constructors have the same type `:: Int -> T Int` (modulo name of the type constructor):\r\n\r\n{{{#!hs\r\ndata DG a where MkDG :: Int -> DG Int \r\n MkDG2 :: (a ~ Int) => a -> DG a\r\n\r\ndata family DF a\r\ndata instance DF Int where MkDF :: Int -> DF Int\r\n}}}\r\n\r\nI tried switching on verbosity flags, but to no avail: `-fprint-explicit-foralls, -fprint-equality-relations`, and a few others.\r\n\r\nThe `DG` constructors are GADTs, the `DF` constructor is not. So it's not hard to see different type-level behaviour:\r\n\r\n{{{#!hs\r\nf (MkDF x) = x -- accepted without a signature\r\n-- f :: DF Int -> Int -- inferred signature, or you can spec it\r\n-- f :: DF a -> a -- rejected: signature is too general/\r\n -- a is a rigid type variable\r\n\r\ng (MkDG x) = x -- } without a signature, rejected\r\ng (MkDG2 x) = x -- } \"untouchable\" type (Note)\r\n\r\n-- g :: DG Int -> Int -- } g accepted with either sig \r\n-- g :: DG a -> a -- } ?but MkDG doesn't return DG a, allegedly\r\n}}}\r\n\r\n'''Note:''' at least the error message re `MkDG2` does show its type as `:: (forall a). (a ~ Int) => DG a -> a`. But doggedly `MkDG :: Int -> DG Int`.\r\n\r\n\"Untouchable\" error messages are a fertile source of questions on StackOverflow. The message does say `Possible fix: add a type signature for 'g'`, but gives no clue what the signature might be. \r\n\r\nIf you've imported these data constructors from a library, such that you can't (easily) see they're GADTs, couldn't `:t` give you better help to show what's going on? Or should one of the verbosity flags already do this?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15672Flags missing documentation.2021-02-07T15:26:55ZMerijn VerstraatenFlags missing documentation.The following flags are missing documentation in the flag reference section of the GHC user guide: `-fprint-bind-contents`, `-fprint-evld-with-show`, `-fimplicit-import-qualified`, `-copy-libs-when-linking`, `-Werror=compat`, `-Wwarn=com...The following flags are missing documentation in the flag reference section of the GHC user guide: `-fprint-bind-contents`, `-fprint-evld-with-show`, `-fimplicit-import-qualified`, `-copy-libs-when-linking`, `-Werror=compat`, `-Wwarn=compat`, and `-Wno-error=compat`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"Flags missing documentation.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following flags are missing documentation in the flag reference section of the GHC user guide: `-fprint-bind-contents`, `-fprint-evld-with-show`, `-fimplicit-import-qualified`, `-copy-libs-when-linking`, `-Werror=compat`, `-Wwarn=compat`, and `-Wno-error=compat`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15670FloatFnInverses seems to show some weird rounding/precision issues.2022-04-08T14:00:08ZTamar ChristinaFloatFnInverses seems to show some weird rounding/precision issues.There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout...There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100
+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100
@@ -8,8 +8,8 @@
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]
+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FloatFnInverses seems to show some weird rounding/precision issues.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThere seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.\r\n\r\n{{{\r\n--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100\r\n+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100\r\n@@ -8,8 +8,8 @@\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]\r\n+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15668Allocations values for some compile tests are way too hight2019-07-07T18:03:31ZTamar ChristinaAllocations values for some compile tests are way too hightThese tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm...These tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm) bytes allocated: 139100464 +/-5%
Lower bound T12425(optasm) bytes allocated: 132145440
Upper bound T12425(optasm) bytes allocated: 146055488
Actual T12425(optasm) bytes allocated: 149370944
Deviation T12425(optasm) bytes allocated: 7.4 %
*** unexpected stat test failure for T12425(optasm)
bytes allocated value is too high:
Expected MultiLayerModules(normal) bytes allocated: 5619893176 +/-10%
Lower bound MultiLayerModules(normal) bytes allocated: 5057903858
Upper bound MultiLayerModules(normal) bytes allocated: 6181882494
Actual MultiLayerModules(normal) bytes allocated: 6693788656
Deviation MultiLayerModules(normal) bytes allocated: 19.1 %
*** unexpected stat test failure for MultiLayerModules(normal)
bytes allocated value is too high:
Expected T11303b(normal) bytes allocated: 54373936 +/-10%
Lower bound T11303b(normal) bytes allocated: 48936542
Upper bound T11303b(normal) bytes allocated: 59811330
Actual T11303b(normal) bytes allocated: 62015072
Deviation T11303b(normal) bytes allocated: 14.1 %
*** unexpected stat test failure for T11303b(normal)
bytes allocated value is too high:
Expected T12234(optasm) bytes allocated: 79889200 +/-5%
Lower bound T12234(optasm) bytes allocated: 75894740
Upper bound T12234(optasm) bytes allocated: 83883660
Actual T12234(optasm) bytes allocated: 91583520
Deviation T12234(optasm) bytes allocated: 14.6 %
*** unexpected stat test failure for T12234(optasm)
```
These are a bit too high for me to just blindly update them without knowing why.8.6.1