GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:22Zhttps://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/15932DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as cov...2021-03-04T08:53:07ZdaveanDeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as coveredWhen testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question ap...When testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question appear to be ones derived via DeriveFunctor and GeneralizedNewtypeDeriving. Problems have been observed with at least Functor, Applicative, and Monad.
A minimal example is attached, and available as a cabal project at https://code.xkrd.net/davean/minimal-coverage-test. To reproduce, run "cabal v2-test --enable-coverage" and view the resulting coverage HTML files.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question appear to be ones derived via DeriveFunctor and GeneralizedNewtypeDeriving. Problems have been observed with at least Functor, Applicative, and Monad.\r\n\r\nA minimal example is attached, and available as a cabal project at https://code.xkrd.net/davean/minimal-coverage-test. To reproduce, run \"cabal v2-test --enable-coverage\" and view the resulting coverage HTML files.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3Javran ChengJavran Chenghttps://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/15928Improve error message: Reduction stack overflow when using "coerce"2024-01-21T16:25:19ZharendraImprove error message: Reduction stack overflow when using "coerce"EDIT: Executive summary: The error messages below are confusing and not perspicuous to users. We should fix. [ticket:15928\#comment:163956](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163956) has a concrete suggestion to use as...EDIT: Executive summary: The error messages below are confusing and not perspicuous to users. We should fix. [ticket:15928\#comment:163956](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163956) has a concrete suggestion to use as a starting point, and [ticket:15928\#comment:163991](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163991) suggests we print out the role signature of any tycons involved.
Compiling the following snippet results in a "Reduction stack overflow" error message:
```hs
{-# Language ScopedTypeVariables #-}
{-# Language RankNTypes #-}
import Data.Functor.Identity
import Data.Coerce
newtype Stream m a =
Stream {
unStream :: forall r. (Stream m a -> m r) -> m r
}
newtype SerialT m a = SerialT (Stream m a)
g :: SerialT Identity a -> Identity Bool
g m = undefined
idSerial :: SerialT Identity a -> SerialT Identity a
idSerial = id
f :: SerialT Identity a -> Identity Bool
f = g . idSerial . coerce
main = undefined
```
The following error message is produced on compiling this with ghc-8.6.2:
```
xy.hs:26:20: error:
• Reduction stack overflow; size = 201
When simplifying the following type:
Coercible
((Stream Identity a -> Identity r) -> Identity r)
((Stream Identity a0 -> Identity r) -> Identity r)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the second argument of ‘(.)’, namely ‘coerce’
In the second argument of ‘(.)’, namely ‘idSerial . coerce’
In the expression: g . idSerial . coerce
|
26 | f = g . idSerial . coerce
| ^^^^^^
```
When I use an inline signature like this:
```hs
f :: SerialT Identity a -> Identity Bool
f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
main = undefined
```
It again results in the same error:
```
xy.hs:18:60: error:
• Reduction stack overflow; size = 201
When simplifying the following type:
Coercible
((Stream Identity a -> Identity r) -> Identity r)
((Stream Identity a0 -> Identity r) -> Identity r)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the second argument of ‘(.)’, namely ‘coerce’
In the second argument of ‘(.)’, namely
‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’
In the expression:
g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
|
18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
| ^^^^^^
```
Everything works fine is I use an inline signature with a `forall` keyword like this:
```hs
f :: forall a. SerialT Identity a -> Identity Bool
f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
```
I have following questions:
1) Why the first version results in a panic? Is that a bug?
2) The second version might possibly be incorrect code because the types do not unify, but still it should not result in a panic, because of the panic I could not figure out what the problem is. It took a long time to isolate the code and then do some trial and error on it.8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15927Weird interaction between fundeps and overlappable instances2022-09-06T11:41:06ZDarwin226Weird interaction between fundeps and overlappable instancesConsider this code
```hs
class MyState s m | m -> s where
getMyState :: m s
instance {-# OVERLAPPABLE #-} (MyState s m, MonadTrans t, Monad m) => MyState s (t m) where
getMyState = lift getMyState
instance Monad m => MyState s (...Consider this code
```hs
class MyState s m | m -> s where
getMyState :: m s
instance {-# OVERLAPPABLE #-} (MyState s m, MonadTrans t, Monad m) => MyState s (t m) where
getMyState = lift getMyState
instance Monad m => MyState s (StateT s m) where
getMyState = get
f :: (MyState Int m, MyState Char m, MonadIO m) => m ()
f = do
int <- getMyState
str <- getMyState
liftIO $ putStrLn (replicate int str)
works1 :: (MyState s m, Show s, MonadIO m) => m ()
works1 = do
a <- getMyState
liftIO (print a)
works2 = runStateT (runStateT f (5 :: Int)) 'a'
```
It defines a class similar to `MonadState` of mtl. There is a functional dependency in place, just like with `MonadState` and we can see that it works the same because `works1` compiles where `a` would have an ambiguous type otherwise.
The `f` function "shouldn't" compile because it's using two different states at once subverting the functional dependency restriction. It does however compile because an explicit type signature is provided with an unsolvable constraint.
Now the really weird part is that `works2` also compiles and produces the expected result even though it's using `f`.
Here's what I think is happening: instance resolution is looking for `MyState Int (StateT Char m)` and it finds the `MyState s (StateT s m)` instance. Instead of complaining that `Int` doesn't match `Char` (due to the fundep), it just rejects the instance and takes the overlappable one that does match. In the case where the state is unknown (i.e. both instances match), the fundep kicks in. That's why `runStateT works1 True` works.
Is this intended behavior? It seems pretty useful in some situations and I've tested this with 8.2 and 8.6 with the same results.
<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":"Weird interaction between fundeps and overlappable instances","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":"Consider this code\r\n\r\n{{{#!hs\r\nclass MyState s m | m -> s where\r\n getMyState :: m s\r\ninstance {-# OVERLAPPABLE #-} (MyState s m, MonadTrans t, Monad m) => MyState s (t m) where\r\n getMyState = lift getMyState\r\ninstance Monad m => MyState s (StateT s m) where\r\n getMyState = get\r\n\r\nf :: (MyState Int m, MyState Char m, MonadIO m) => m ()\r\nf = do\r\n int <- getMyState\r\n str <- getMyState\r\n liftIO $ putStrLn (replicate int str)\r\n\r\n\r\nworks1 :: (MyState s m, Show s, MonadIO m) => m ()\r\nworks1 = do\r\n a <- getMyState\r\n liftIO (print a)\r\n\r\nworks2 = runStateT (runStateT f (5 :: Int)) 'a'\r\n}}}\r\n\r\nIt defines a class similar to `MonadState` of mtl. There is a functional dependency in place, just like with `MonadState` and we can see that it works the same because `works1` compiles where `a` would have an ambiguous type otherwise.\r\n\r\nThe `f` function \"shouldn't\" compile because it's using two different states at once subverting the functional dependency restriction. It does however compile because an explicit type signature is provided with an unsolvable constraint. \r\n\r\nNow the really weird part is that `works2` also compiles and produces the expected result even though it's using `f`.\r\n\r\nHere's what I think is happening: instance resolution is looking for `MyState Int (StateT Char m)` and it finds the `MyState s (StateT s m)` instance. Instead of complaining that `Int` doesn't match `Char` (due to the fundep), it just rejects the instance and takes the overlappable one that does match. In the case where the state is unknown (i.e. both instances match), the fundep kicks in. That's why `runStateT works1 True` works.\r\n\r\nIs this intended behavior? It seems pretty useful in some situations and I've tested this with 8.2 and 8.6 with the same results.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15921Data.List.maximumBy uses counter-intuitive ordering2020-10-27T22:29:26ZMarten WijnjaData.List.maximumBy uses counter-intuitive ordering```hs
Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)]
```
What do you expect the outcome to be?
All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. H...```hs
Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)]
```
What do you expect the outcome to be?
All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the *last* occurrence of a 'maximum' element) is kept.
Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request:
- If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it.
- If its behaviour is intentionally the opposite, this should be specified in the documentation.
<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":"Foldable.maximumBy uses counter-intuitive ordering","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["List","maximumBy","minimumBy"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nData.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)]\r\n}}}\r\nWhat do you expect the outcome to be?\r\nAll Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept.\r\n\r\nFurthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request:\r\n\r\n- If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it.\r\n- If its behaviour is intentionally the opposite, this should be specified in the documentation.","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/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/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/15905Data familes should end in Type2022-08-19T19:16:24ZSimon Peyton JonesData familes should end in TypeCurrently we allow
```
data family Fix (f :: Type -> k) :: k
```
with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`.
That seems attractive because we can then have
```
data instance Fix (f :: Typ...Currently we allow
```
data family Fix (f :: Type -> k) :: k
```
with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`.
That seems attractive because we can then have
```
data instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x)
```
But what about this?
```
type family F a
type instance F Int = Type -> Type
data instance Fix (f :: Type -> F Int) (x :: Type) = …
```
The type inference engine (tcInferApps) will type the LHS as something like
```
((Fix (f :: Type -> F Int)) |> co1)
(x |> co2)
where co1 :: F Int ~ Type
co2 :: Type ~ F Int
```
But the LHS of a family axiom has to look like
```
F t1 t2 … tn
```
not
```
((F t1 |> co) t2 t3) |> co4) …tn
```
with casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh!
And indeed GHC HEAD does accept the first, but rejects the second with the error message
```
• Expected kind ‘* -> * -> *’,
but ‘f :: Type -> F Int’ has kind ‘* -> F Int’
• In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’
In the data instance declaration for ‘Fix’
```
That's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely
how it happens, but it must be fragile: a change in solve order, or more aggressive solving
might change the behaviour.
I don't see how to solve this. I propose instead to require data family kinds to
end in `Type`, not in a type *variable* (as we currently allow).
I don't know how many people that would affect, but the current state of affairs
looks untenable.
<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":"Data familes should end in Type","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":"Currently we allow\r\n{{{\r\ndata family Fix (f :: Type -> k) :: k\r\n}}}\r\nwith a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`.\r\n\r\nThat seems attractive because we can then have\r\n{{{\r\ndata instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x)\r\n}}}\r\nBut what about this?\r\n{{{\r\ntype family F a\r\ntype instance F Int = Type -> Type\r\ndata instance Fix (f :: Type -> F Int) (x :: Type) = …\r\n}}}\r\nThe type inference engine (tcInferApps) will type the LHS as something like\r\n{{{\r\n\t((Fix (f :: Type -> F Int)) |> co1)\r\n (x |> co2)\r\n\r\nwhere co1 :: F Int ~ Type\r\n co2 :: Type ~ F Int\r\n}}}\r\nBut the LHS of a family axiom has to look like\r\n{{{\r\n\tF t1 t2 … tn\r\n}}}\r\nnot\r\n{{{\r\n\t((F t1 |> co) t2 t3) |> co4) …tn\r\n}}}\r\nwith casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh!\r\n\r\nAnd indeed GHC HEAD does accept the first, but rejects the second with the error message\r\n{{{\r\n • Expected kind ‘* -> * -> *’,\r\n but ‘f :: Type -> F Int’ has kind ‘* -> F Int’\r\n • In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’\r\n In the data instance declaration for ‘Fix’\r\n}}}\r\nThat's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely\r\nhow it happens, but it must be fragile: a change in solve order, or more aggressive solving\r\nmight change the behaviour.\r\n\r\nI don't see how to solve this. I propose instead to require data family kinds to\r\nend in `Type`, not in a type ''variable'' (as we currently allow).\r\n\r\nI don't know how many people that would affect, but the current state of affairs\r\nlooks untenable.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15891Excessive system time during execution of GHC-built executables on macOS2019-07-07T18:02:33ZRichard Eisenbergrae@richarde.devExcessive system time during execution of GHC-built executables on macOSIt seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.
Here is what I know.
- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is...It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.
Here is what I know.
- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1.
- When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl.
- Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.)
- I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f
- I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02
- System information:
- macOS High Sierra, 10.13.6
- Processor: 3.5 GHz Intel Core i5
- Memory: 16 GB 2400 MHz DDR4
- SSD main storage, formatted with APFS
- happy 1.19.9
- alex 3.2.4
- XCode 10.1
- gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix
Others (see [thread](https://mail.haskell.org/pipermail/ghc-devs/2018-November/016507.html)) have not been able to repro, but this is very reliable for me.
Any ideas?
<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":"Excessive system time during execution of GHC-built executables on macOS","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":"It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.\r\n\r\nHere is what I know.\r\n\r\n- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1.\r\n\r\n- When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl.\r\n\r\n- Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.)\r\n\r\n- I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f\r\n\r\n- I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02\r\n\r\n- System information:\r\n * macOS High Sierra, 10.13.6\r\n * Processor: 3.5 GHz Intel Core i5\r\n * Memory: 16 GB 2400 MHz DDR4\r\n * SSD main storage, formatted with APFS\r\n * happy 1.19.9\r\n * alex 3.2.4\r\n * XCode 10.1\r\n * gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix\r\n\r\nOthers (see [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016507.html thread]) have not been able to repro, but this is very reliable for me.\r\n\r\nAny ideas?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15889ghc documentation doesn't explain difference between dwarf levels 1 2 and 32019-07-07T18:02:34ZCarter Schonwaldghc documentation doesn't explain difference between dwarf levels 1 2 and 3I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any diffe...I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)
<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":"ghc documentation doesn't explain difference between dwarf levels 1 2 and 3","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":"I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.\r\n\r\nThe docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15888Quantified constraints can be loopy2019-07-07T18:02:34ZRichard Eisenbergrae@richarde.devQuantified constraints can be loopyConsider this abuse:
```hs
{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}
module Bug where
data T1 a
data T2 a
class C a where
meth :: a
instance (forall a. C (T2 a)) => C (T1 b) where
meth = error "instance T1"
i...Consider this abuse:
```hs
{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}
module Bug where
data T1 a
data T2 a
class C a where
meth :: a
instance (forall a. C (T2 a)) => C (T1 b) where
meth = error "instance T1"
instance (forall a. C (T1 a)) => C (T2 b) where
meth = error "instance T2"
example :: T1 Int
example = meth
```
GHC says
```
• Reduction stack overflow; size = 201
When simplifying the following type: C (T1 a)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the expression: meth
In an equation for ‘example’: example = meth
```
Of course, I've taken on some responsibility for my actions here by saying `UndecidableInstances`, but GHC really should be able to figure this out. Here's what's happening:
1. We get a Wanted `C (T1 Int)`.
1. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T2 a)`.
1. GHC skolemizes the `a` to `a1` and tries solve a Wanted `C (T2 a1)`.
1. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T1 a)`.
1. GHC skolemizes the `a` to `a2` and tries to solve a Wanted `C (T1 a2)`.
And around and around we go.
(This loop is guessed at from knowing GHC's algorithms in general. I did not look at a trace.)
We *could* get this one, though. Before skolemizing, we could stash the Wanted in the `inert_solved_dicts`, which is where we record uses of top-level instances. (See `Note [Solved dictionaries]` in TcSMonad.) Then, later, when we see the same Wanted arise again, we would just use the cached value, making a well-formed recursive dictionary.
This deficiency was discovered in `singletons` (https://github.com/goldfirere/singletons/issues/371). Perhaps that's not "the wild", but it's not quite contrived either.
Note that we don't need two datatypes to trigger this, but having one recursive instance like this seems awfully silly.
<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":"Quantified constraints can be loopy","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this abuse:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}\r\n\r\nmodule Bug where\r\n\r\ndata T1 a\r\ndata T2 a\r\n\r\nclass C a where\r\n meth :: a\r\n\r\ninstance (forall a. C (T2 a)) => C (T1 b) where\r\n meth = error \"instance T1\"\r\n\r\ninstance (forall a. C (T1 a)) => C (T2 b) where\r\n meth = error \"instance T2\"\r\n\r\nexample :: T1 Int\r\nexample = meth\r\n}}}\r\n\r\nGHC says\r\n\r\n{{{\r\n • Reduction stack overflow; size = 201\r\n When simplifying the following type: C (T1 a)\r\n Use -freduction-depth=0 to disable this check\r\n (any upper bound you could choose might fail unpredictably with\r\n minor updates to GHC, so disabling the check is recommended if\r\n you're sure that type checking should terminate)\r\n • In the expression: meth\r\n In an equation for ‘example’: example = meth\r\n}}}\r\n\r\nOf course, I've taken on some responsibility for my actions here by saying `UndecidableInstances`, but GHC really should be able to figure this out. Here's what's happening:\r\n\r\n1. We get a Wanted `C (T1 Int)`.\r\n\r\n2. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T2 a)`.\r\n\r\n3. GHC skolemizes the `a` to `a1` and tries solve a Wanted `C (T2 a1)`.\r\n\r\n4. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T1 a)`.\r\n\r\n5. GHC skolemizes the `a` to `a2` and tries to solve a Wanted `C (T1 a2)`.\r\n\r\nAnd around and around we go.\r\n\r\n(This loop is guessed at from knowing GHC's algorithms in general. I did not look at a trace.)\r\n\r\nWe ''could'' get this one, though. Before skolemizing, we could stash the Wanted in the `inert_solved_dicts`, which is where we record uses of top-level instances. (See `Note [Solved dictionaries]` in TcSMonad.) Then, later, when we see the same Wanted arise again, we would just use the cached value, making a well-formed recursive dictionary.\r\n\r\nThis deficiency was discovered in `singletons` (https://github.com/goldfirere/singletons/issues/371). Perhaps that's not \"the wild\", but it's not quite contrived either.\r\n\r\nNote that we don't need two datatypes to trigger this, but having one recursive instance like this seems awfully silly.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15885Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (outpu...2021-02-22T21:15:08ZShayan-NajdEnhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) typesOn our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [...On our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [a pattern synonym](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations) similar to the following:
```hs
pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a
pattern LL s m <- (decomposeSrcSpan -> (m , s))
where
LL s m = composeSrcSpan (m , s)
```
We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).
As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.
I believe we need to enhance COMPLETE pragmas to support such pattern synonyms.
This can be done either syntactically, or (preferably) type-directed.
For example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.
In the type-directed approach
a. the totality checker \*may\* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and
b. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by \@carter).
For example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.
<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":"Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types","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":"On our work on the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow new front-end AST for GHC] based on [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG], we would like to use [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations a pattern synonym] similar to the following:\r\n\r\n{{{#!hs\r\npattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a\r\npattern LL s m <- (decomposeSrcSpan -> (m , s))\r\n where\r\n LL s m = composeSrcSpan (m , s)\r\n}}}\r\n\r\nWe know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).\r\n\r\nAs far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.\r\nI believe we need to enhance COMPLETE pragmas to support such pattern synonyms.\r\n\r\nThis can be done either syntactically, or (preferably) type-directed.\r\n\r\nFor example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.\r\n\r\nIn the type-directed approach\r\na. the totality checker *may* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and\r\nb. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by @carter).\r\n\r\nFor example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15882:load in ghci should expose the entire namespace of a module2019-07-07T18:02:35ZEyalLotem:load in ghci should expose the entire namespace of a moduleWhen using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no ...When using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":load in ghci should expose the entire namespace of a module","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When using \"import\" in ghci, only exported names are available.\r\n\r\nWhen using :load, the use case is typically for \"toying around\" or testing a module. In that case, the export list restrictions are much less useful.\r\n \r\nThere is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary \"import\" namespace semantics are after all available too.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15880GHC.Stats: Add info on amount of pinned memory2019-08-03T11:16:56ZNiklas Hambüchenmail@nh2.meGHC.Stats: Add info on amount of pinned memoryhttps://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amo...https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amount of memory in use by the RTS" (`gcdetails_mem_in_use_bytes`)
There currently doesn't seem to be a way to get the amount of pinned memory in use.
So some questions:
- Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?
- If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?
- If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?
In general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Stats: Add info on amount of pinned memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Task","description":"https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html\r\n\r\n`GHC.Stats`'s `GCDetails` tells us, separately, the amount of \r\n\r\n* total heap data (including large objects and compact data)\r\n* large ojects\r\n* compact data\r\n* \"Total amount of memory in use by the RTS\" (`gcdetails_mem_in_use_bytes`)\r\n\r\nThere currently doesn't seem to be a way to get the amount of pinned memory in use.\r\n\r\nSo some questions:\r\n\r\n* Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?\r\n* If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?\r\n* If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?\r\n\r\nIn general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15878Unused data type with a "deriving" clause is falsely considered used2021-06-17T16:32:40ZEyalLotemUnused data type with a "deriving" clause is falsely considered usedmodule M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from in...module M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from instance declarations, it is necessarily unused in the program.
One potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the \*type\* is unused.
<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":"Unused data type with a \"deriving\" clause is falsely considered used","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":"module M () where data Foo = Bar deriving (Eq)\r\n\r\nIf there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.\r\n\r\nEven if it is referenced, but only from instance declarations, it is necessarily unused in the program.\r\n\r\nOne potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the *type* is unused.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15876Function versioning instead of compilation flags...2019-07-07T18:02:36ZMichalGajdaFunction versioning instead of compilation flags...Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags....Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags.
Instead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/
This would allow us to write code like this:
{-\# target(avx512) \#-}
c_memchr = ...SIMD code...
{-\# !target(avx512) \#-}
c_memchr = ...current code...
We currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)
Ideally we could also use it to remove some of _flavoring_ in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | abhir00p, marlowsd@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Function versioning instead of compilation flags...","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["flavors,","simd,","speed"],"differentials":[],"test_case":"","architecture":"","cc":["abhir00p","marlowsd@gmail.com"],"type":"FeatureRequest","description":"Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).\r\n\r\nThis would require recompiling most of the libraries for new flags.\r\n\r\nInstead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/\r\n\r\nThis would allow us to write code like this:\r\n{-# target(avx512) #-}\r\nc_memchr = ...SIMD code...\r\n{-# !target(avx512) #-}\r\nc_memchr = ...current code...\r\n\r\nWe currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)\r\n\r\nIdeally we could also use it to remove some of _flavoring_ in the future.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/14613Validate Failure On OSX -- implicit fall through error for machO linker suppo...2019-07-07T18:16:17ZCarter SchonwaldValidate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5)seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do
` __attribute__ ((fallthrough)); `, which is allegedly...seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do
` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang?
```
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o
rts/linker/MachO.c: In function 'ocGetNames_MachO':
rts/linker/MachO.c:1532:17: error:
error: this statement may fall through [-Werror=implicit-fallthrough=]
secArray[i].info->relocation_info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
= (MachORelocationInfo*)(oc->image + section->reloff);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
1532 | = (MachORelocationInfo*)(oc->image + section->reloff);
| ^
rts/linker/MachO.c:1534:13: error:
note: here
default: {
^~~~~~~
|
1534 | default: {
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd@mega-nerd.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5)","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd@mega-nerd.com"],"type":"Bug","description":"seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do \r\n` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang?\r\n\r\n{{{\r\n\r\n\"inplace/bin/ghc-stage1\" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\\\"rts_dyn\\\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o\r\nrts/linker/MachO.c: In function 'ocGetNames_MachO':\r\n\r\nrts/linker/MachO.c:1532:17: error:\r\n error: this statement may fall through [-Werror=implicit-fallthrough=]\r\n secArray[i].info->relocation_info\r\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n = (MachORelocationInfo*)(oc->image + section->reloff);\r\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n |\r\n1532 | = (MachORelocationInfo*)(oc->image + section->reloff);\r\n | ^\r\n\r\nrts/linker/MachO.c:1534:13: error:\r\n note: here\r\n default: {\r\n ^~~~~~~\r\n |\r\n1534 | default: {\r\n\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3