GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:30Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15907memo001 causes compile time panic with fails with -O -dannot-lint2019-07-07T18:02:30ZÖmer Sinan Ağacanmemo001 causes compile time panic with fails with -O -dannot-lint```
$ cd libraries/base/tests; ghc-stage2 memo001.hs -O -dannot-lint
[1 of 2] Compiling Memo1 ( Memo1.lhs, Memo1.o ) [Optimisation flags changed]
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181116 for x...```
$ cd libraries/base/tests; ghc-stage2 memo001.hs -O -dannot-lint
[1 of 2] Compiling Memo1 ( Memo1.lhs, Memo1.o ) [Optimisation flags changed]
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181116 for x86_64-unknown-linux):
idInfo
val_a3pf
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Var.hs:567:34 in ghc:Var
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"memo001 causes compile time panic with fails with -O -dannot-lint","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cd libraries/base/tests; ghc-stage2 memo001.hs -O -dannot-lint\r\n[1 of 2] Compiling Memo1 ( Memo1.lhs, Memo1.o ) [Optimisation flags changed]\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181116 for x86_64-unknown-linux):\r\n idInfo\r\n val_a3pf\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/basicTypes/Var.hs:567:34 in ghc:Var\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15909prepareAlts does not take into account equalities which are in scope2019-07-07T18:02:29ZMatthew PickeringprepareAlts does not take into account equalities which are in scopeIf we consider this program submitted for our consideration by Andres we see some surprising behaviour.
https://gist.github.com/kosmikus/237946a2335600690208a4a36efef988
```
{-# LANGUAGE TypeOperators, GADTs, FlexibleContexts, DataKind...If we consider this program submitted for our consideration by Andres we see some surprising behaviour.
https://gist.github.com/kosmikus/237946a2335600690208a4a36efef988
```
{-# LANGUAGE TypeOperators, GADTs, FlexibleContexts, DataKinds, RankNTypes, PolyKinds, TypeFamilies, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, ConstraintKinds, TypeApplications, EmptyCase, ScopedTypeVariables, PartialTypeSignatures, TemplateHaskell #-}
module Partition where
import Data.Coerce
import Data.Kind
import Data.Proxy
data NP (f :: k -> Type) (xs :: [k]) where
Nil :: NP f '[]
(:*) :: f x -> NP f xs -> NP f (x : xs)
infixr 5 :*
strictToPair :: forall f a b . NP f '[a, b] -> (f a, f b)
strictToPair np =
case np of
(fx :* fxs) ->
case (fxs {- :: NP f '[b] -}) of
(fy :* fys) ->
(fx, fy)
```
Both pattern matches are exhaustive so we don't need to generate any failure cases when pattern matching.
Notice in the generated core that we have a match on `Partition.Nil` even though the match will never
be reached.
```
Partition.strictToPair
:: forall k (f :: k -> *) (a :: k) (b :: k).
Partition.NP f '[a, b] -> (f a, f b)
[GblId, Arity=1, Str=<S,1*U>m, Unf=OtherCon []]
Partition.strictToPair
= \ (@ k_a1gV)
(@ (f_a1gW :: k_a1gV -> *))
(@ (a_a1gX :: k_a1gV))
(@ (b_a1gY :: k_a1gV))
(np_s1yz [Occ=Once!] :: Partition.NP f_a1gW '[a_a1gX, b_a1gY]) ->
case np_s1yz of
{ Partition.:* @ x_a1h2 @ xs_a1h3 co_a1h4 fx_s1yB [Occ=Once]
fxs_s1yC [Occ=Once!] ->
case fxs_s1yC of {
Partition.Nil _ [Occ=Dead, Dmd=<B,A>] ->
Partition.strictToPair1 @ k_a1gV @ a_a1gX @ f_a1gW @ b_a1gY;
Partition.:* @ x1_a1h7 @ xs1_a1h8 co1_a1h9 fy_s1yE [Occ=Once]
_ [Occ=Dead] ->
(fx_s1yB
`cast` (<f_a1gW>_R (Nth:1 (Sym co_a1h4))
:: (f_a1gW x_a1h2 :: *) ~R# (f_a1gW a_a1gX :: *)),
fy_s1yE
`cast` (<f_a1gW>_R (Nth:1 (Sym co1_a1h9 ; Nth:2 (Sym co_a1h4)))
:: (f_a1gW x1_a1h7 :: *) ~R# (f_a1gW b_a1gY :: *)))
}
}
```
This is because in `prepareAlts` are try to inspect the type of `fxs` which looks like a type variable, however it has since been refined by the pattern match on `np` above. Adding the explicit type signature to `fxs` makes `prepareAlts` treat it correctly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"prepareAlts does not take into account equalities which are in scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If we consider this program submitted for our consideration by Andres we see some surprising behaviour.\r\n\r\nhttps://gist.github.com/kosmikus/237946a2335600690208a4a36efef988\r\n\r\n{{{\r\n{-# LANGUAGE TypeOperators, GADTs, FlexibleContexts, DataKinds, RankNTypes, PolyKinds, TypeFamilies, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, ConstraintKinds, TypeApplications, EmptyCase, ScopedTypeVariables, PartialTypeSignatures, TemplateHaskell #-}\r\nmodule Partition where\r\n\r\nimport Data.Coerce\r\nimport Data.Kind\r\nimport Data.Proxy\r\n\r\ndata NP (f :: k -> Type) (xs :: [k]) where\r\n Nil :: NP f '[]\r\n (:*) :: f x -> NP f xs -> NP f (x : xs)\r\n\r\ninfixr 5 :*\r\n\r\nstrictToPair :: forall f a b . NP f '[a, b] -> (f a, f b)\r\nstrictToPair np =\r\n case np of\r\n (fx :* fxs) ->\r\n case (fxs {- :: NP f '[b] -}) of\r\n (fy :* fys) ->\r\n (fx, fy)\r\n}}}\r\n\r\nBoth pattern matches are exhaustive so we don't need to generate any failure cases when pattern matching. \r\n\r\nNotice in the generated core that we have a match on `Partition.Nil` even though the match will never\r\nbe reached. \r\n\r\n\r\n{{{\r\n Partition.strictToPair \r\n :: forall k (f :: k -> *) (a :: k) (b :: k). \r\n Partition.NP f '[a, b] -> (f a, f b) \r\n [GblId, Arity=1, Str=<S,1*U>m, Unf=OtherCon []] \r\n Partition.strictToPair \r\n = \\ (@ k_a1gV) \r\n (@ (f_a1gW :: k_a1gV -> *)) \r\n (@ (a_a1gX :: k_a1gV)) \r\n (@ (b_a1gY :: k_a1gV)) \r\n (np_s1yz [Occ=Once!] :: Partition.NP f_a1gW '[a_a1gX, b_a1gY]) -> \r\n case np_s1yz of \r\n { Partition.:* @ x_a1h2 @ xs_a1h3 co_a1h4 fx_s1yB [Occ=Once] \r\n fxs_s1yC [Occ=Once!] -> \r\n case fxs_s1yC of { \r\n Partition.Nil _ [Occ=Dead, Dmd=<B,A>] -> \r\n Partition.strictToPair1 @ k_a1gV @ a_a1gX @ f_a1gW @ b_a1gY; \r\n Partition.:* @ x1_a1h7 @ xs1_a1h8 co1_a1h9 fy_s1yE [Occ=Once] \r\n _ [Occ=Dead] -> \r\n (fx_s1yB \r\n `cast` (<f_a1gW>_R (Nth:1 (Sym co_a1h4)) \r\n :: (f_a1gW x_a1h2 :: *) ~R# (f_a1gW a_a1gX :: *)), \r\n fy_s1yE \r\n `cast` (<f_a1gW>_R (Nth:1 (Sym co1_a1h9 ; Nth:2 (Sym co_a1h4))) \r\n :: (f_a1gW x1_a1h7 :: *) ~R# (f_a1gW b_a1gY :: *))) \r\n } \r\n } \r\n}}}\r\n\r\nThis is because in `prepareAlts` are try to inspect the type of `fxs` which looks like a type variable, however it has since been refined by the pattern match on `np` above. Adding the explicit type signature to `fxs` makes `prepareAlts` treat it correctly. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15911internal error: evacuate(static): strange closure type -1275332472019-07-07T18:02:29Zbfraikininternal error: evacuate(static): strange closure type -127533247internal error: evacuate(static): strange closure type -127533247
(GHC version 8.4.4 for x86_64_apple_darwin)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
<details><summary>Trac metadata</s...internal error: evacuate(static): strange closure type -127533247
(GHC version 8.4.4 for x86_64_apple_darwin)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: evacuate(static): strange closure type -127533247","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"internal error: evacuate(static): strange closure type -127533247\r\n (GHC version 8.4.4 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap: 6","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15929Explore whether adding XRay attributes to LLVM IR is worthwhile2019-07-07T18:02:24ZMatthew PickeringExplore whether adding XRay attributes to LLVM IR is worthwhileLLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling....LLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling.
https://llvm.org/docs/XRay.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explore whether adding XRay attributes to LLVM IR is worthwhile","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"LLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling. \r\n\r\n\r\nhttps://llvm.org/docs/XRay.html","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15940Source plugins should be able to opt-out from appearing in dependencies2019-07-07T18:02:22ZFacundo DomínguezSource plugins should be able to opt-out from appearing in dependenciesCurrently when ghc build a module M using a source plugin in a package P, P shows up in the interface file of M (`M.hi`).
According to `--show-iface`, P shows up in the `package dependencies` section, and in an `addDependentFile` entry....Currently when ghc build a module M using a source plugin in a package P, P shows up in the interface file of M (`M.hi`).
According to `--show-iface`, P shows up in the `package dependencies` section, and in an `addDependentFile` entry.
Presumably, this is necessary to recompile M if P ever changes. But unfortunately, including P in the interface file is the wrong thing to do when the plugin does not affect the result of the compilation of M.
It is only fair to wonder what the point would be in using a plugin which does not modify the compilation. I hit this case when using the upcoming haskell-indexer-plugin, which extracts source code information for later examination.
If the indexer plugin changes, there is no point in rebuilding M, unless the user really wants to reindex the source code. As things stand, `ghc` wants to know where the plugin is every time it is mentioned in the dependencies of a module which is being linked, even though the plugin won't be used for anything. This sometimes can make the plugin harder to use in a large project.
Can we change the plugin interface to opt-out of tracking dependencies? Or would it work better to provide a ghc flag to control this?8.6.3Moritz AngermannMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/15944Wrong warning given ViewPatterns and -Wmonomorphism-restriction2019-07-07T18:02:21ZpacakWrong warning given ViewPatterns and -Wmonomorphism-restrictionI understand ghc complaining about `b`, but not about `a`.
No warnings when view patterns are not used.
```hs
{-# LANGUAGE ViewPatterns #-}
{-# OPTIONS -Wmonomorphism-restriction #-}
module Foo where
{-
demo.hs:11:9: warning: [-Wmon...I understand ghc complaining about `b`, but not about `a`.
No warnings when view patterns are not used.
```hs
{-# LANGUAGE ViewPatterns #-}
{-# OPTIONS -Wmonomorphism-restriction #-}
module Foo where
{-
demo.hs:11:9: warning: [-Wmonomorphism-restriction]
• The Monomorphism Restriction applies to the bindings for ‘a’, ‘b’
Consider giving them a type signature
• In the expression: let Foo a (round -> b) = f in a + b
In an equation for ‘bar’:
bar f = let Foo a (round -> b) = f in a + b
|
11 | let Foo a (round -> b) = f
| ^^^^^^^^^^^^^^^^^^^^^^
-}
data Foo = Foo Int Double
bar :: Foo -> Int
bar f =
let Foo a (round -> b) = f
in a + b
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong warning given ViewPatterns and -Wmonomorphism-restriction","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I understand ghc complaining about `b`, but not about `a`.\r\n\r\nNo warnings when view patterns are not used.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ViewPatterns #-}\r\n{-# OPTIONS -Wmonomorphism-restriction #-}\r\n\r\nmodule Foo where\r\n\r\n{-\r\n\r\ndemo.hs:11:9: warning: [-Wmonomorphism-restriction]\r\n • The Monomorphism Restriction applies to the bindings for ‘a’, ‘b’\r\n Consider giving them a type signature\r\n • In the expression: let Foo a (round -> b) = f in a + b\r\n In an equation for ‘bar’:\r\n bar f = let Foo a (round -> b) = f in a + b\r\n |\r\n11 | let Foo a (round -> b) = f\r\n | ^^^^^^^^^^^^^^^^^^^^^^\r\n-} \r\n\r\ndata Foo = Foo Int Double\r\n\r\nbar :: Foo -> Int\r\nbar f =\r\n let Foo a (round -> b) = f\r\n in a + b\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15958Missing documentation for '-fno-ghci-sandbox'2019-07-07T18:02:17ZGhost UserMissing documentation for '-fno-ghci-sandbox'The option '-fno-ghci-sandbox' is mentioned in https://downloads.haskell.org/\~ghc/7.0.2/docs/html/users_guide/release-7-0-1.html with the following explanation:
> There is a new -fno-ghci-sandbox flag, which stops GHCi running computat...The option '-fno-ghci-sandbox' is mentioned in https://downloads.haskell.org/\~ghc/7.0.2/docs/html/users_guide/release-7-0-1.html with the following explanation:
> There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread.
However, it doesn't seem to be documented on the GHC user's guide (search box didn't find anything).
Sorry if I just couldn't find it!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.2 |
| 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":"Missing documentation for '-fno-ghci-sandbox'","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The option '-fno-ghci-sandbox' is mentioned in https://downloads.haskell.org/~ghc/7.0.2/docs/html/users_guide/release-7-0-1.html with the following explanation:\r\n\r\n There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread.\r\n\r\nHowever, it doesn't seem to be documented on the GHC user's guide (search box didn't find anything).\r\n\r\nSorry if I just couldn't find it!","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15973Int used to represent target integer literals2019-07-07T18:02:12ZBen GamariInt used to represent target integer literalsThere are numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following:
```hs
-- XXX: should really be Integer, since Int doesn't necessarily cover
-- the full ...There are numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following:
```hs
-- XXX: should really be Integer, since Int doesn't necessarily cover
-- the full range of target Ints.
mkIntCLit :: DynFlags -> Int -> CmmLit
mkIntCLit dflags i = CmmInt (toInteger i) (wordWidth dflags)
```
This could go very wrong when cross-compiling from a 32-bit machine to a 64-bit target.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Int used to represent target integer literals","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following:\r\n{{{#!hs\r\n-- XXX: should really be Integer, since Int doesn't necessarily cover\r\n-- the full range of target Ints.\r\nmkIntCLit :: DynFlags -> Int -> CmmLit\r\nmkIntCLit dflags i = CmmInt (toInteger i) (wordWidth dflags)\r\n}}}\r\nThis could go very wrong when cross-compiling from a 32-bit machine to a 64-bit target.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15977Restructure typechecking modules2019-07-07T18:02:11ZRichard Eisenbergrae@richarde.devRestructure typechecking modulesSome of the kind-checking and type-checking modules have become unruly.
Simon and I propose the new structure:
- KcTyClsDecls will handle kind-checking and generalization of datatype declarations. (That is, `kcTyClGroup` and children, ...Some of the kind-checking and type-checking modules have become unruly.
Simon and I propose the new structure:
- KcTyClsDecls will handle kind-checking and generalization of datatype declarations. (That is, `kcTyClGroup` and children, including related functions in TcHsType)
- TcInstBinds will handle `tcInstDecls2` and children
- TcTyConValidity will handle `checkValidTyCon` and children
- Fold the rest of TcInstDecls (essentially, `tcInstDecls1`) into what's left of TcTyClsDecls. TcInstDecls is removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Restructure typechecking modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Some of the kind-checking and type-checking modules have become unruly.\r\n\r\nSimon and I propose the new structure:\r\n\r\n- KcTyClsDecls will handle kind-checking and generalization of datatype declarations. (That is, `kcTyClGroup` and children, including related functions in TcHsType)\r\n\r\n- TcInstBinds will handle `tcInstDecls2` and children\r\n\r\n- TcTyConValidity will handle `checkValidTyCon` and children\r\n\r\n- Fold the rest of TcInstDecls (essentially, `tcInstDecls1`) into what's left of TcTyClsDecls. TcInstDecls is removed.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15983Built-in support for half-floats2019-07-07T18:02:09ZLevent ErkökBuilt-in support for half-floatsHalf-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's ar...Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set.
It would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double.
I'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| 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":"Built-in support for half-floats","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set.\r\n\r\nIt would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double.\r\n\r\nI'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15984Backpack accepts ill-kinded instantiations. Can cause GHC panic2019-07-07T18:02:09ZaaronvargoBackpack accepts ill-kinded instantiations. Can cause GHC panicGiven the following:
```hs
{-# language KindSignatures #-}
signature A where
data A :: *
```
```hs
module Foo where
import A
foo :: A -> A
foo = id
```
```hs
module IllKindedA where
type A = Maybe
```
GHC allows the signature `A`...Given the following:
```hs
{-# language KindSignatures #-}
signature A where
data A :: *
```
```hs
module Foo where
import A
foo :: A -> A
foo = id
```
```hs
module IllKindedA where
type A = Maybe
```
GHC allows the signature `A` to be instantiated with `IllKindedA`:
```
mixins: foo (Foo as Bug) requires (A as IllKindedA)
```
Using the resulting module can cause odd errors or a panic. E.g. the following causes a panic:
```hs
module Bar where
import Bug
bar = foo
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.2 for x86_64-unknown-linux):
getRuntimeRep
A :: * -> *
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2049:18 in ghc:Type
```8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15988Remove Text.Printf and System.Console.GetOpt from base2019-07-07T18:02:08ZAndrew MartinRemove Text.Printf and System.Console.GetOpt from baseThis was touched on in brief in a recent mailing list thread found at https://mail.haskell.org/pipermail/libraries/2018-October/029012.html. I propose removing `Text.Printf` and `System.Console.GetOpt` from `base` and moving them into th...This was touched on in brief in a recent mailing list thread found at https://mail.haskell.org/pipermail/libraries/2018-October/029012.html. I propose removing `Text.Printf` and `System.Console.GetOpt` from `base` and moving them into their own packages named `printf` and `getopt` that would be managed by the haskell github organization. These two libraries, when built against newer versions of base, would provide the modules. When built against old versions of base, they would simply reexport the modules. There would be breakage from doing this, but libraries and applications that use these APIs would only need to add a single line to `build-depends` to continue being compatible with all versions of `base`.
The benefits of doing this are small. As a matter of principle, it seems unfair that these two APIs are blessed by being a part of base when the would likely struggle to compete if they were in ordinary libraries. In particular, `printf` is less idiomatic and performs worse that the functions from `Numeric` (like `showFFloat`), but its prominent position in `base` encourages users to overlook the more type-safe options available for formatting numbers.
More practically, the size of base does occassionally cause problems. In https://github.com/haskell/primitive/issues/218\#issuecomment-443534850, Carter writes
> base getting bigger actually hurts folk, eg, base recently got big enough that dwarf data gnerated by ghc at -g1 is now sooo much that you can't do a dwarf annotated build of base on mac OS X! anymore
Moving these APIs out of `base` makes a small step toward addressing this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove Text.Printf and System.Console.GetOpt from base","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This was touched on in brief in a recent mailing list thread found at https://mail.haskell.org/pipermail/libraries/2018-October/029012.html. I propose removing `Text.Printf` and `System.Console.GetOpt` from `base` and moving them into their own packages named `printf` and `getopt` that would be managed by the haskell github organization. These two libraries, when built against newer versions of base, would provide the modules. When built against old versions of base, they would simply reexport the modules. There would be breakage from doing this, but libraries and applications that use these APIs would only need to add a single line to `build-depends` to continue being compatible with all versions of `base`.\r\n\r\nThe benefits of doing this are small. As a matter of principle, it seems unfair that these two APIs are blessed by being a part of base when the would likely struggle to compete if they were in ordinary libraries. In particular, `printf` is less idiomatic and performs worse that the functions from `Numeric` (like `showFFloat`), but its prominent position in `base` encourages users to overlook the more type-safe options available for formatting numbers.\r\n\r\nMore practically, the size of base does occassionally cause problems. In https://github.com/haskell/primitive/issues/218#issuecomment-443534850, Carter writes\r\n\r\n> base getting bigger actually hurts folk, eg, base recently got big enough that dwarf data gnerated by ghc at -g1 is now sooo much that you can't do a dwarf annotated build of base on mac OS X! anymore\r\n\r\nMoving these APIs out of `base` makes a small step toward addressing this problem.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15989Adding extra quantified constraints leads to resolution failure2019-07-07T18:02:08ZerorAdding extra quantified constraints leads to resolution failure```
{-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-}
import Control.Monad.Reader
data T x = T
ok :: ( forall x x'. MonadReader (T x) (m x') )
=> m y Bool
ok = fmap not (pure True)
bad :: ( forall x x'. MonadReader (T x) (...```
{-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-}
import Control.Monad.Reader
data T x = T
ok :: ( forall x x'. MonadReader (T x) (m x') )
=> m y Bool
ok = fmap not (pure True)
bad :: ( forall x x'. MonadReader (T x) (m x')
, forall x. Monad (m x) )
=> m y Bool
bad = fmap not (pure True)
better :: ( forall x x'. MonadReader (T x) (m x')
, forall x. Applicative (m x)
, forall x. Functor (m x) )
=> m y Bool
better = fmap not (pure True)
```
`ok` and `better` compile, but `bad` fails to resolve, despite having strictly more in the context than `ok`:
```
BadQC.hs:15:7: error:
• Could not deduce (Functor (m y)) arising from a use of ‘fmap’
from the context: (forall x x'. MonadReader (T x) (m x'),
forall x. Monad (m x))
bound by the type signature for:
bad :: forall (m :: * -> * -> *) y.
(forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) =>
m y Bool
at BadQC.hs:(12,1)-(14,15)
• In the expression: fmap not (pure True)
In an equation for ‘bad’: bad = fmap not (pure True)
|
15 | bad = fmap not (pure True)
| ^^^^^^^^^^^^^^^^^^^^
BadQC.hs:15:17: error:
• Could not deduce (Applicative (m y)) arising from a use of ‘pure’
from the context: (forall x x'. MonadReader (T x) (m x'),
forall x. Monad (m x))
bound by the type signature for:
bad :: forall (m :: * -> * -> *) y.
(forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) =>
m y Bool
at BadQC.hs:(12,1)-(14,15)
• In the second argument of ‘fmap’, namely ‘(pure True)’
In the expression: fmap not (pure True)
In an equation for ‘bad’: bad = fmap not (pure True)
|
15 | bad = fmap not (pure True)
| ^^^^^^^^^
Failed, no modules loaded.
```
Also:
- `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables
- `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused
- `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters
- `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15992Alternative instance for Data.Functor.Compose causes <<loop>>s with some types2019-07-07T18:02:07ZglaebhoerlAlternative instance for Data.Functor.Compose causes <<loop>>s with some types`many` and `some` are [omitted](http://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Functor.Compose.html#line-119) and are filled in by their defaults from `Alternative`, instead of re-using the definitions provided for `f`; t...`many` and `some` are [omitted](http://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Functor.Compose.html#line-119) and are filled in by their defaults from `Alternative`, instead of re-using the definitions provided for `f`; this manifests as infinite grammars being created in the case of the Earley parsing library, resulting in `<<loop>>` errors at runtime.
The fix is just to add:
```hs
many = Compose . fmap sequenceA . many . getCompose
some = Compose . fmap sequenceA . some . getCompose
```
Related twitter thread: https://twitter.com/ollfredo/status/1067498140100628480
(It seems like this bug has been around for some time: https://github.com/feuerbach/regex-applicative/issues/19)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Alternative instance for Data.Functor.Compose causes <<loop>>s with some types","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`many` and `some` are [http://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Functor.Compose.html#line-119 omitted] and are filled in by their defaults from `Alternative`, instead of re-using the definitions provided for `f`; this manifests as infinite grammars being created in the case of the Earley parsing library, resulting in `<<loop>>` errors at runtime.\r\n\r\nThe fix is just to add:\r\n\r\n{{{#!hs\r\n many = Compose . fmap sequenceA . many . getCompose\r\n some = Compose . fmap sequenceA . some . getCompose\r\n}}}\r\n\r\nRelated twitter thread: https://twitter.com/ollfredo/status/1067498140100628480\r\n\r\n(It seems like this bug has been around for some time: https://github.com/feuerbach/regex-applicative/issues/19)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15997EventManager could benefit from Data.Primitive.UnliftedArray2019-07-07T18:02:06ZchessaiEventManager could benefit from Data.Primitive.UnliftedArray```hs
-- | The event manager state.
data EventManager = EventManager
{ emBackend :: !Backend
, emFds :: {-# UNPACK #-} !(Array Int (MVar (IntTable [FdData])))
, emState :: {-# UNPACK #-} !(IORef State)
...```hs
-- | The event manager state.
data EventManager = EventManager
{ emBackend :: !Backend
, emFds :: {-# UNPACK #-} !(Array Int (MVar (IntTable [FdData])))
, emState :: {-# UNPACK #-} !(IORef State)
, emUniqueSource :: {-# UNPACK #-} !UniqueSource
, emControl :: {-# UNPACK #-} !Control
, emLock :: {-# UNPACK #-} !(MVar ())
}
```
the field in question is an `Array Int (MVar (IntTable [FdData]))`.
`EventManager` could instead be:
```hs
type MVarIO = MVar# RealWorld -- type synonym for brevity
-- | The event manager state.
data EventManager = EventManager
{ emBackend :: !Backend
, emFds :: {-# UNPACK #-} !(UnliftedArray (MVarIO (IntTable [FdData])))
, emState :: {-# UNPACK #-} !(IORef State)
, emUniqueSource :: {-# UNPACK #-} !UniqueSource
, emControl :: {-# UNPACK #-} !Control
, emLock :: {-# UNPACK #-} !(MVar ())
}
```
now the `UnliftedArray` contains non-thunks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"EventManager could benefit from Data.Primitive.UnliftedArray","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{#!hs\r\n-- | The event manager state.\r\ndata EventManager = EventManager\r\n { emBackend :: !Backend\r\n , emFds :: {-# UNPACK #-} !(Array Int (MVar (IntTable [FdData])))\r\n , emState :: {-# UNPACK #-} !(IORef State)\r\n , emUniqueSource :: {-# UNPACK #-} !UniqueSource\r\n , emControl :: {-# UNPACK #-} !Control\r\n , emLock :: {-# UNPACK #-} !(MVar ())\r\n }\r\n}}}\r\n\r\nthe field in question is an `Array Int (MVar (IntTable [FdData]))`.\r\n\r\n`EventManager` could instead be:\r\n\r\n{{{#!hs\r\n\r\ntype MVarIO = MVar# RealWorld -- type synonym for brevity\r\n\r\n-- | The event manager state.\r\ndata EventManager = EventManager\r\n { emBackend :: !Backend\r\n , emFds :: {-# UNPACK #-} !(UnliftedArray (MVarIO (IntTable [FdData])))\r\n , emState :: {-# UNPACK #-} !(IORef State)\r\n , emUniqueSource :: {-# UNPACK #-} !UniqueSource\r\n , emControl :: {-# UNPACK #-} !Control\r\n , emLock :: {-# UNPACK #-} !(MVar ())\r\n }\r\n}}}\r\n\r\nnow the `UnliftedArray` contains non-thunks.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15998GHC.Event.Thread.eventManager has a lot of indirections2019-07-07T18:02:06ZchessaiGHC.Event.Thread.eventManager has a lot of indirectionsCurrent `eventManager`:
```hs
eventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager)))
eventManager = unsafePerformIO $ do
...
```
That's a lot of indirections just to grab your thread's event manager.
Consider the followi...Current `eventManager`:
```hs
eventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager)))
eventManager = unsafePerformIO $ do
...
```
That's a lot of indirections just to grab your thread's event manager.
Consider the following, which I believe would improve the performance of this:
```hs
data UnliftedIORef :: TYPE 'UnliftedRep -> Type where
UnliftedIORef :: MutVar# RealWorld a -> UnliftedIORef a
eventManager :: UnliftedIORef (MutableArray# RealWorld Things)
data Things = Things !ThreadId !EventManager
```
I think the Maybe can be eliminated. I'm unsure. What makes me think it can be is the following snippet:
```hs
getSystemEventManager :: IO (Maybe EventManager)
getSystemEventManager = do
t <- myThreadId
(cap, _) <- threadCapability t
eventManagerArray <- readIORef eventManager
mmgr <- readIOArray eventManagerArray cap
return $ fmap snd mmgr
getSystemEventManager_ :: IO EventManager
getSystemEventManager_ = do
Just mgr <- getSystemEventManager
return mgr
{-# INLINE getSystemEventManager_ #-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Event.Thread.eventManager has a lot of indirections","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Current `eventManager`:\r\n\r\n{{{#!hs\r\neventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager)))\r\neventManager = unsafePerformIO $ do\r\n...\r\n}}}\r\n\r\nThat's a lot of indirections just to grab your thread's event manager.\r\n\r\nConsider the following, which I believe would improve the performance of this:\r\n\r\n{{{#!hs\r\ndata UnliftedIORef :: TYPE 'UnliftedRep -> Type where\r\n UnliftedIORef :: MutVar# RealWorld a -> UnliftedIORef a\r\n\r\neventManager :: UnliftedIORef (MutableArray# RealWorld Things)\r\n\r\ndata Things = Things !ThreadId !EventManager\r\n}}}\r\n\r\nI think the Maybe can be eliminated. I'm unsure. What makes me think it can be is the following snippet:\r\n\r\n{{{#!hs\r\ngetSystemEventManager :: IO (Maybe EventManager)\r\ngetSystemEventManager = do\r\n t <- myThreadId\r\n (cap, _) <- threadCapability t\r\n eventManagerArray <- readIORef eventManager\r\n mmgr <- readIOArray eventManagerArray cap\r\n return $ fmap snd mmgr\r\n\r\ngetSystemEventManager_ :: IO EventManager\r\ngetSystemEventManager_ = do\r\n Just mgr <- getSystemEventManager\r\n return mgr\r\n{-# INLINE getSystemEventManager_ #-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/16004Vector performance regression in GHC 8.62019-07-07T18:02:04ZGuillaume BouchardVector performance regression in GHC 8.6Hello.
With the following code, I can observe a performance regression between ghc 8.4 and 8.6:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.Vector.Unboxed.Mutable as Vector
import qualified D...Hello.
With the following code, I can observe a performance regression between ghc 8.4 and 8.6:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.Vector.Unboxed.Mutable as Vector
import qualified Data.Vector.Unboxed as VectorU
import Data.Foldable (for_)
main :: IO ()
main = do
let n = 1000
let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\i -> fromIntegral i)
v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable
for_ [0..(n - 1)] $ \k -> do
for_ [0..(n - 1)] $ \i -> do
for_ [0..(n - 1)] $ \j -> do
a <- Vector.unsafeRead v (i * n + k)
b <- Vector.unsafeRead v (k * n + j)
c <- Vector.unsafeRead v (i * n + j)
Vector.unsafeWrite v (i * n + j) (min (a + b) c)
```
Built with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results:
GHC 8.2.2
> no llvm: 1.7s
> llvm: 1.0s
GHC 8.4.4
> no llvm: 1.6s
> llvm: 0.9s
GHC 8.6.2
> no llvm: 4.8s
> llvm: 4.3s
I'm using the following bash + nix script to gather theses timings:
```bash
nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench"
nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench"
nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench"
nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench"
nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench"
nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Vector performance regression in GHC 8.6","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello.\r\n\r\nWith the following code, I can observe a performance regression between ghc 8.4 and 8.6:\r\n\r\n\r\n{{{#!haskell\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nmodule Main where\r\nimport qualified Data.Vector.Unboxed.Mutable as Vector\r\nimport qualified Data.Vector.Unboxed as VectorU\r\n\r\nimport Data.Foldable (for_)\r\n\r\nmain :: IO ()\r\nmain = do\r\n let n = 1000\r\n\r\n let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\\i -> fromIntegral i)\r\n v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable\r\n\r\n for_ [0..(n - 1)] $ \\k -> do\r\n for_ [0..(n - 1)] $ \\i -> do\r\n for_ [0..(n - 1)] $ \\j -> do\r\n a <- Vector.unsafeRead v (i * n + k)\r\n b <- Vector.unsafeRead v (k * n + j)\r\n c <- Vector.unsafeRead v (i * n + j)\r\n Vector.unsafeWrite v (i * n + j) (min (a + b) c)\r\n}}}\r\n\r\nBuilt with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results:\r\n\r\nGHC 8.2.2\r\n no llvm: 1.7s\r\n llvm: 1.0s\r\nGHC 8.4.4\r\n no llvm: 1.6s\r\n llvm: 0.9s\r\nGHC 8.6.2\r\n no llvm: 4.8s\r\n llvm: 4.3s\r\n\r\nI'm using the following bash + nix script to gather theses timings:\r\n\r\n{{{#!bash\r\nnix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench\"\r\nnix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench\"\r\nnix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench\"\r\nnix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench\"\r\nnix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp; time ./FloydBench\"\r\nnix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run \"ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench\"\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/16021Hadrian: remove/refactor package specific hacks2019-07-07T18:01:59ZdavideHadrian: remove/refactor package specific hacksHadrian implements a number of package specific hacks (e.g. see #16020). Such hacks should be discussed in this ticket and ideally removed or refactored.
Hacks:
- libffi (#16020)
<details><summary>Trac metadata</summary>
| Trac field...Hadrian implements a number of package specific hacks (e.g. see #16020). Such hacks should be discussed in this ticket and ideally removed or refactored.
Hacks:
- libffi (#16020)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian: remove/refactor package specific hacks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hadrian implements a number of package specific hacks (e.g. see #16020). Such hacks should be discussed in this ticket and ideally removed or refactored.\r\n\r\nHacks:\r\n* libffi (#16020)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3David EichmannDavid Eichmannhttps://gitlab.haskell.org/ghc/ghc/-/issues/16027Cannot use DefaultSignatures for TypeFamiles2019-07-07T18:01:58ZJohn EricsonCannot use DefaultSignatures for TypeFamilesI'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.
In short, I want to do something like:
```
class Monad m => MyMonad m where
type AssociatedMonad m :: Type -> Type
default type AssociatedMonad m :: (...I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.
In short, I want to do something like:
```
class Monad m => MyMonad m where
type AssociatedMonad m :: Type -> Type
default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type
type AssociatedMonad (t m') = t (AssociatedMonad m')
fun :: Foo -> m ()
default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m ()
fun = lift . fun
```
The syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out.
The use-case, like the normal method original, is to assist with monad transformer boilerplate. `MonadTrans` wouldn't be enough, but `MFunctor` from mmorph might be depending on the method using the associated type.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| 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":"Cannot use DefaultSignatures for TypeFamiles","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.\r\n\r\nIn short, I want to do something like:\r\n{{{\r\nclass Monad m => MyMonad m where\r\n type AssociatedMonad m :: Type -> Type\r\n default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type\r\n type AssociatedMonad (t m') = t (AssociatedMonad m')\r\n\r\n fun :: Foo -> m ()\r\n default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m ()\r\n fun = lift . fun\r\n}}}\r\n\r\nThe syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out.\r\n\r\nThe use-case, like the normal method original, is to assist with monad transformer boilerplate. {{{MonadTrans}}} wouldn't be enough, but {{{MFunctor}}} from mmorph might be depending on the method using the associated type.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3