GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-08-02T15:32:49Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14429Remove constraint types from HsExtension, post TTG2019-08-02T15:32:49ZAlan ZimmermanRemove constraint types from HsExtension, post TTGOnce Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs`
Hopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go.
<details><summary>Trac metadata</summary>
| Trac field |...Once Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs`
Hopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sh.najd |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove constraint types from HsExtension, post TTG","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sh.najd"],"type":"Task","description":"Once Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs`\r\n\r\nHopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go.","type_of_failure":"OtherFailure","blocking":[]} -->Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/14428Rework HsValBindsLR2019-08-02T15:34:17ZAlan ZimmermanRework HsValBindsLROnce Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it.
From a comment on https://phabricator.haskell.org/D4147
> Nothing here gives any clue that this is intended for the output of the renamer. An...Once Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it.
From a comment on https://phabricator.haskell.org/D4147
> Nothing here gives any clue that this is intended for the output of the renamer. And typechecker I think.
> Plus I wonder if we'd be better served by
```hs
data HsValBindsLR idL idR
= ValBinds
[(RecFlag, LHsBindsLR idL idR)]
[LSig GhcRn]
```
> Then the parser can generate a giant singleton Rec and the renamer can sort it out. Less fuss.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rework HsValBindsLR","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Once Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it.\r\n\r\nFrom a comment on https://phabricator.haskell.org/D4147\r\n\r\n> Nothing here gives any clue that this is intended for the output of the renamer. And typechecker I think.\r\n\r\n> Plus I wonder if we'd be better served by\r\n\r\n{{{#!hs\r\ndata HsValBindsLR idL idR\r\n = ValBinds\r\n [(RecFlag, LHsBindsLR idL idR)]\r\n [LSig GhcRn]\r\n}}}\r\n\r\n> Then the parser can generate a giant singleton Rec and the renamer can sort it out. Less fuss.","type_of_failure":"OtherFailure","blocking":[]} -->Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/14423{-# complete #-} should be able to handle | like {-# minimal #-}2019-07-07T18:17:05ZEdward Kmett{-# complete #-} should be able to handle | like {-# minimal #-}It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of pattern...It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of patterns.
I have at least one use case where something that would be a trivial pattern to express with one (complicated) expression involving `|` becomes 64 lines of complete pragmas, and every time I extend it this count doubles.
Consider what happens if you add a mix of actual and smart views of a data type:
```hs
{-# language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving #-}
newtype Delta = Delta Int deriving (Eq,Num)
instance Monoid Delta where
mempty = 0
mappend = (+)
data Exp = Var !Int | AP !Delta !Exp !Exp | LAM !Delta !Exp
rel 0 xs = xs
rel d (AP d' l r) = AP (d + d') l r
rel d (LAM d' b) = LAM (d + d') b
rel _ (Var n) = Var n
pattern Ap a b <- AP d (rel d -> a) (rel d -> b) where
Ap a b = AP 0 a b
pattern Lam b <- LAM d (rel d -> b) where
Lam b = LAM 0 b
{-# complete Var, AP, Lam #-}
{-# complete Var, Ap, LAM #-}
{-# complete Var, AP, LAM #-}
```
Every data constructor I add with a smart view adds to the powerset of complete pragmas I should supply.
On the other hand with `|` patterns:
```hs
{-# complete Var, (Ap | AP), (Lam | LAM) #-}
```
extends linearly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"{-# complete #-} should be able to handle | like {-# minimal #-}","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of patterns. \r\n\r\nI have at least one use case where something that would be a trivial pattern to express with one (complicated) expression involving `|` becomes 64 lines of complete pragmas, and every time I extend it this count doubles.\r\n\r\nConsider what happens if you add a mix of actual and smart views of a data type:\r\n\r\n{{{#!hs\r\n{-# language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving #-}\r\n\r\nnewtype Delta = Delta Int deriving (Eq,Num)\r\n\r\ninstance Monoid Delta where\r\n mempty = 0\r\n mappend = (+)\r\n\r\ndata Exp = Var !Int | AP !Delta !Exp !Exp | LAM !Delta !Exp\r\n\r\nrel 0 xs = xs\r\nrel d (AP d' l r) = AP (d + d') l r\r\nrel d (LAM d' b) = LAM (d + d') b\r\nrel _ (Var n) = Var n\r\n\r\npattern Ap a b <- AP d (rel d -> a) (rel d -> b) where\r\n Ap a b = AP 0 a b\r\n\r\npattern Lam b <- LAM d (rel d -> b) where\r\n Lam b = LAM 0 b\r\n\r\n{-# complete Var, AP, Lam #-}\r\n{-# complete Var, Ap, LAM #-}\r\n{-# complete Var, AP, LAM #-}\r\n}}}\r\n\r\nEvery data constructor I add with a smart view adds to the powerset of complete pragmas I should supply.\r\n\r\nOn the other hand with `|` patterns:\r\n\r\n{{{#!hs\r\n{-# complete Var, (Ap | AP), (Lam | LAM) #-}\r\n}}} \r\n\r\nextends linearly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14422{-# complete #-} should be able to be at least partially type directed2021-09-16T13:34:34ZEdward Kmett{-# complete #-} should be able to be at least partially type directedThe fact that `{-# complete #-}` pragma that was added in #8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice.
Say I have a bunch of types that happen to share...The fact that `{-# complete #-}` pragma that was added in #8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice.
Say I have a bunch of types that happen to share a common `(:<)` and `Empty` pattern, for views. I'd like to be able to say that for one particular type `{-# complete (:<), Empty #-}` holds, but since both aren't defined in the same module and neither one mentions my type, I'm stuck in the same `-Wno-incomplete-patterns` mess I was in before.
I cant move the pragma to the individual view patterns because in general they aren't known to be a complete pattern set.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"{-# complete #-} should be able to be at least partially type directed","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The fact that `{-# complete #-}` pragma that was added in#8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice.\r\n\r\nSay I have a bunch of types that happen to share a common `(:<)` and `Empty` pattern, for views. I'd like to be able to say that for one particular type `{-# complete (:<), Empty #-}` holds, but since both aren't defined in the same module and neither one mentions my type, I'm stuck in the same `-Wno-incomplete-patterns` mess I was in before. \r\n\r\nI cant move the pragma to the individual view patterns because in general they aren't known to be a complete pattern set.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14419Check kinds for ambiguity2020-06-21T12:03:16ZRichard Eisenbergrae@richarde.devCheck kinds for ambiguityGHC does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected:
```hs
type family F a
data T :: F a -> Type
```
`T`'s kind is ambiguous, and any occurrence of `T` will be rejected....GHC does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected:
```hs
type family F a
data T :: F a -> Type
```
`T`'s kind is ambiguous, and any occurrence of `T` will be rejected. Instead of rejecting usage sites, let's just reject the definition site.
This check would be disabled by `AllowAmbiguousTypes`.
Happily, I think the implementation should be easy, and that the current algorithm to check for ambiguous types should work for kinds, too. After all, types and kinds are the same these days.
This was inspired by #14203, but no need to read that ticket to understand this one.
EDIT: See [ticket:14419\#comment:160844](https://gitlab.haskell.org//ghc/ghc/issues/14419#note_160844) and [ticket:14419\#comment:163265](https://gitlab.haskell.org//ghc/ghc/issues/14419#note_163265) for the nub of what needs to be done here.https://gitlab.haskell.org/ghc/ghc/-/issues/14414Profiled program runs 2.5x faster than non-profiled2019-08-05T08:38:41ZMateusz KowalczykProfiled program runs 2.5x faster than non-profiledI was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without!
To run without profiling:
``...I was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without!
To run without profiling:
```
ghc --make -Wall -fforce-recomp -fllvm -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null
```
Same program with profiling
```
ghc --make -fforce-recomp -fllvm -prof -fprof-auto -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -p -s -RTS 250000 > /dev/null
```
I also attach Core outputs for both profiled and unprofiled version.
To me this seems very strange: profiled version is somehow faster. Perhaps what's worse is that this means that there's some optimisation GHC is performing when profiling is not on that makes the program a lot slower than it could be!
This program is not minimised.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Profiled program runs 2.5x faster than non-profiled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without!\r\n\r\nTo run without profiling:\r\n{{{\r\nghc --make -Wall -fforce-recomp -fllvm -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null\r\n}}}\r\n\r\nSame program with profiling\r\n{{{\r\n ghc --make -fforce-recomp -fllvm -prof -fprof-auto -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -p -s -RTS 250000 > /dev/null\r\n}}}\r\n\r\nI also attach Core outputs for both profiled and unprofiled version.\r\n\r\nTo me this seems very strange: profiled version is somehow faster. Perhaps what's worse is that this means that there's some optimisation GHC is performing when profiling is not on that makes the program a lot slower than it could be!\r\n\r\nThis program is not minimised.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14409Split GHC(-API) into multiple packages2023-07-13T13:25:14ZLemmingSplit GHC(-API) into multiple packagesCurrent GHC-API is pretty monolithic and a lot of data is hidden in monads.
I'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use t...Current GHC-API is pretty monolithic and a lot of data is hidden in monads.
I'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use the first two, maybe three, steps. Advanced editing features in an IDE would use only the first three steps. A compiler for a Haskell dialect might use only optimizer and code generator.
The packages should have clean interfaces. E.g. it should be possible to enter a Text or String into the parser and get a ByteString containing code or a pointer to executable code in memory from the code generator, with no need to write temporary files.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"Split GHC(-API) into multiple packages","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Current GHC-API is pretty monolithic and a lot of data is hidden in monads.\r\nI'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use the first two, maybe three, steps. Advanced editing features in an IDE would use only the first three steps. A compiler for a Haskell dialect might use only optimizer and code generator.\r\nThe packages should have clean interfaces. E.g. it should be possible to enter a Text or String into the parser and get a ByteString containing code or a pointer to executable code in memory from the code generator, with no need to write temporary files.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14407rts: Threads/caps affinity2019-07-07T18:17:09Zpacakrts: Threads/caps affinityCurrently GHC supports two kinds of threads with respect to thread migration - pinned to a specific capability and those it can migrate between any capabilities. For purposes of achieving lower latency in Haskell applications it would be...Currently GHC supports two kinds of threads with respect to thread migration - pinned to a specific capability and those it can migrate between any capabilities. For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC rts can migrate but within a certain subset of capabilities only.
I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so.
I have a patch for rts that implements this proposal
```hs
{- | 'setThreadAffinity' limits RTS ability to migrate thread to
capabilities with numbers that matches set bits of affinity mask, thus
mask of `0b101` (5) will allow RTS to migrate this thread to caps
0 (64, 128, ..) and 3 (64 + 3 = 67, 128 + 3 = 131, ...).
Setting all bits to 0 or 1 will disable the restriction.
-}
setThreadAffinity :: ThreadId -> Int -> IO ()
```
This allows to define up to 64 distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 5-7 bulk things.
Sample program using this API
```hs
{-# LANGUAGE LambdaCase #-}
import Data.Time
import Control.Monad
import Control.Concurrent
import System.Environment (getArgs)
import GHC.Conc
wastetime :: Bool -> IO ()
wastetime affine = do
tid <- forkIO $ do
myThreadId >>= \tid -> labelThread tid "timewaster"
forever $ do
when (sum [1..1000000] < (0 :: Integer)) $
print "impossible"
threadDelay 100
yield
when affine $ setThreadAffinity tid (255 - 2)
client :: Bool -> IO ()
client affine = do
myThreadId >>= \tid -> labelThread tid "client"
when affine $ myThreadId >>= \tid -> setThreadAffinity tid 2
before <- getCurrentTime
replicateM_ 10 $ do
threadDelay 10000
after <- getCurrentTime
print $ after `diffUTCTime` before
startClient :: Bool -> IO ()
startClient = {- replicateM_ 10 . -} client
main :: IO ()
main = do
getArgs >>= \case
[wno's, aff's] -> do
let wno = read wno's
aff = read aff's
putStrLn $ unwords ["Affinity:", show aff, "Timewasters:", show wno]
replicateM_ wno (wastetime aff)
startClient aff
_ -> putStrLn "Usage: <progname> <number of time wasters> <enable affinity: True/False>"
```
Compiled with -threaded and running with rts -N8 on 6 core (12 threads) machine.
Results are noisy but repeatable
```
Affinity: False Timewasters: 24
0.42482036s
```
```
Affinity: True Timewasters: 24
0.111743474s
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"rts: Threads/caps affinity","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"\r\nCurrently GHC supports two kinds of threads with respect to thread migration - pinned to a specific capability and those it can migrate between any capabilities. For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC rts can migrate but within a certain subset of capabilities only.\r\n\r\nI'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so.\r\n\r\nI have a patch for rts that implements this proposal\r\n\r\n\r\n{{{#!hs\r\n\r\n{- | 'setThreadAffinity' limits RTS ability to migrate thread to\r\ncapabilities with numbers that matches set bits of affinity mask, thus\r\nmask of `0b101` (5) will allow RTS to migrate this thread to caps\r\n0 (64, 128, ..) and 3 (64 + 3 = 67, 128 + 3 = 131, ...).\r\n\r\nSetting all bits to 0 or 1 will disable the restriction.\r\n-}\r\nsetThreadAffinity :: ThreadId -> Int -> IO ()\r\n}}}\r\n\r\nThis allows to define up to 64 distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 5-7 bulk things.\r\n\r\n\r\nSample program using this API\r\n\r\n{{{#!hs\r\n{-# LANGUAGE LambdaCase #-}\r\n\r\nimport Data.Time\r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport System.Environment (getArgs)\r\nimport GHC.Conc\r\n\r\n\r\nwastetime :: Bool -> IO ()\r\nwastetime affine = do\r\n tid <- forkIO $ do\r\n\r\n myThreadId >>= \\tid -> labelThread tid \"timewaster\"\r\n\r\n forever $ do\r\n when (sum [1..1000000] < (0 :: Integer)) $\r\n print \"impossible\"\r\n threadDelay 100\r\n yield\r\n when affine $ setThreadAffinity tid (255 - 2)\r\n\r\nclient :: Bool -> IO ()\r\nclient affine = do\r\n myThreadId >>= \\tid -> labelThread tid \"client\"\r\n when affine $ myThreadId >>= \\tid -> setThreadAffinity tid 2\r\n before <- getCurrentTime\r\n replicateM_ 10 $ do\r\n threadDelay 10000\r\n after <- getCurrentTime\r\n print $ after `diffUTCTime` before\r\n\r\nstartClient :: Bool -> IO ()\r\nstartClient = {- replicateM_ 10 . -} client\r\n\r\n\r\nmain :: IO ()\r\nmain = do\r\n\r\n getArgs >>= \\case\r\n [wno's, aff's] -> do\r\n let wno = read wno's\r\n aff = read aff's\r\n putStrLn $ unwords [\"Affinity:\", show aff, \"Timewasters:\", show wno]\r\n replicateM_ wno (wastetime aff)\r\n startClient aff\r\n _ -> putStrLn \"Usage: <progname> <number of time wasters> <enable affinity: True/False>\"\r\n\r\n\r\n}}}\r\n\r\n\r\nCompiled with -threaded and running with rts -N8 on 6 core (12 threads) machine.\r\n\r\nResults are noisy but repeatable\r\n\r\n{{{\r\nAffinity: False Timewasters: 24\r\n0.42482036s\r\n}}}\r\n\r\n{{{\r\nAffinity: True Timewasters: 24\r\n0.111743474s\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14405Remove core-spec.pdf from repository2020-01-23T19:27:39ZBen GamariRemove core-spec.pdf from repositoryCurrently we track `core-spec.pdf` in the repository, which is generated from ott sources. This is a rather flagrant violation of a central tenant of version control: don't track derived files. However, simonpj would like to ensure that ...Currently we track `core-spec.pdf` in the repository, which is generated from ott sources. This is a rather flagrant violation of a central tenant of version control: don't track derived files. However, simonpj would like to ensure that there is an easily accessible copy of this artifact somewhere, so we can't remove it yet. Let's ensure that it is produced by documentation artifact produced by CircleCI.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove core-spec.pdf from repository","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently we track `core-spec.pdf` in the repository, which is generated from ott sources. This is a rather flagrant violation of a central tenant of version control: don't track derived files. However, simonpj would like to ensure that there is an easily accessible copy of this artifact somewhere, so we can't remove it yet. Let's ensure that it is produced by documentation artifact produced by CircleCI.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14401Add a test ensuring that TypeReps can be stored in compact regions2020-01-23T19:27:40ZDavid FeuerAdd a test ensuring that TypeReps can be stored in compact regionsMy work thus far on [D4085](https://phabricator.haskell.org/D4085) has involved `TypeRep`s with cyclical structure. That bit me in `break011` and `break024` because `:force` doesn't work with cyclical structures. This would also have cau...My work thus far on [D4085](https://phabricator.haskell.org/D4085) has involved `TypeRep`s with cyclical structure. That bit me in `break011` and `break024` because `:force` doesn't work with cyclical structures. This would also have caused trouble for storing `TypeRep`s in compact regions. If we eventually make `:force` work with cyclical structures (see #14400), then cyclical `TypeRep`s won't break the test suite but might break user code using compact regions. So let's test for that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add a test ensuring that TypeReps can be stored in compact regions","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["Typeable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"My work thus far on Phab:D4085 has involved `TypeRep`s with cyclical structure. That bit me in `break011` and `break024` because `:force` doesn't work with cyclical structures. This would also have caused trouble for storing `TypeRep`s in compact regions. If we eventually make `:force` work with cyclical structures (see #14400), then cyclical `TypeRep`s won't break the test suite but might break user code using compact regions. So let's test for that.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14400Make :sprint, :print, and :force work with cyclical structures2020-01-23T19:27:39ZDavid FeuerMake :sprint, :print, and :force work with cyclical structures```
> t = "hi" : t
> :force t
```
never completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable ...```
> t = "hi" : t
> :force t
```
never completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable representation of the graph.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| 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":"Make :sprint, :print, and :force work with cyclical structures","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{\r\n> t = \"hi\" : t\r\n> :force t\r\n}}}\r\n\r\nnever completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable representation of the graph.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14399NCG: dead code stripping prevention wastes space2019-07-07T18:17:10ZGabor GreifNCG: dead code stripping prevention wastes space# Symptom
Consider this NCG-generated code:
```
.long _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp
.data
.align 3
.align 0
.globl _T5001a_mapzusentence_closure
_T5001a_mapzusentence_closure:
.quad _T5001a_mapzusente...# Symptom
Consider this NCG-generated code:
```
.long _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp
.data
.align 3
.align 0
.globl _T5001a_mapzusentence_closure
_T5001a_mapzusentence_closure:
.quad _T5001a_mapzusentence_info
.text
.align 3
_T5001a_mapzusentence_info_dsp:
.align 3
.quad 4294967301
.quad 0
.quad 14
.globl _T5001a_mapzusentence_info
_T5001a_mapzusentence_info:
```
There is an inert `.long` at the end of each Cmm procedure. This fills up precious instruction cache and wastes space.
# Potential solutions
Some ideas to improve the situation follow:
1. Move all those longs to a "table" at the end of the compilation unit (idea by Henning Thielemann),
1. coalesce the relocation into the previous instruction by explicitly calculating the opcode (craziness by me),
1. coalesce the relocation into the following info table like this:
```
.quad 4294967301 - 24 + _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp
```
1. Instead of exporting `_T5001a_mapzusentence_info` export `_T5001a_mapzusentence_info_dsp` and jump/call `_T5001a_mapzusentence_info_dsp + 24` instead. (Idea by Henning Thielemann.)
## Discussion
1. Improves instruction cache only
1. hard to implement, leads to ugly assembly
1. wastes a long per compilation unit (at the end), needs a new state in the assembly writer
1. leads to unintuitive (ugly?) assembly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"NCG: dead code stripping prevention wastes space","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["low-hanging"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"= Symptom\r\n\r\nConsider this NCG-generated code:\r\n{{{\r\n\t.long _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp\r\n.data\r\n.align 3\r\n.align 0\r\n.globl _T5001a_mapzusentence_closure\r\n_T5001a_mapzusentence_closure:\r\n\t.quad\t_T5001a_mapzusentence_info\r\n.text\r\n.align 3\r\n_T5001a_mapzusentence_info_dsp:\r\n.align 3\r\n\t.quad\t4294967301\r\n\t.quad\t0\r\n\t.quad\t14\r\n.globl _T5001a_mapzusentence_info\r\n_T5001a_mapzusentence_info:\r\n}}}\r\nThere is an inert `.long` at the end of each Cmm procedure. This fills up precious instruction cache and wastes space.\r\n\r\n= Potential solutions\r\n\r\nSome ideas to improve the situation follow:\r\n\r\n1. Move all those longs to a \"table\" at the end of the compilation unit (idea by Henning Thielemann),\r\n2. coalesce the relocation into the previous instruction by explicitly calculating the opcode (craziness by me),\r\n3. coalesce the relocation into the following info table like this:\r\n{{{\r\n \t.quad\t4294967301 - 24 + _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp\r\n}}}\r\n4. Instead of exporting `_T5001a_mapzusentence_info` export `_T5001a_mapzusentence_info_dsp` and jump/call `_T5001a_mapzusentence_info_dsp + 24` instead. (Idea by Henning Thielemann.)\r\n\r\n== Discussion\r\n\r\n1. Improves instruction cache only\r\n2. hard to implement, leads to ugly assembly\r\n3. wastes a long per compilation unit (at the end), needs a new state in the assembly writer\r\n4. leads to unintuitive (ugly?) assembly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14398Fail to install haskell platform on Windows2019-07-07T18:17:11ZKAAAsSFail to install haskell platform on WindowsI can't run WinGHCi after my installation. When I use command "ghci" in cmd, it returns:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
ghc.exe: internal error: mkPath failed converting char* to wchar_t*
(GHC vers...I can't run WinGHCi after my installation. When I use command "ghci" in cmd, it returns:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
ghc.exe: internal error: mkPath failed converting char* to wchar_t*
(GHC version 8.2.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
I had tried to reinstall or download the Core(64-bit) version, but nothing changed. I think there's nothing wrong with my install precedure.
Sorry for my poor English!
BTW, my windows is under Chinese code system. I don't know whether this matters or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fail to install haskell platform on Windows","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I can't run WinGHCi after my installation. When I use command \"ghci\" in cmd, it returns: \r\n\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nghc.exe: internal error: mkPath failed converting char* to wchar_t*\r\n (GHC version 8.2.1 for x86_64_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\r\nPlease contact the application's support team for more information.\r\n}}}\r\n\r\nI had tried to reinstall or download the Core(64-bit) version, but nothing changed. I think there's nothing wrong with my install precedure.\r\n\r\nSorry for my poor English!\r\n\r\nBTW, my windows is under Chinese code system. I don't know whether this matters or not.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14397For type error involving inferred types, show source of the type2019-07-07T18:17:11Zmax630For type error involving inferred types, show source of the typeConsider the code:
```hs
module TestTypes where
a = 42
b = a ++ "hello"
```
The type Error is (ghc-8.2.1):
```
TestTypes.hs:3:5: error:
• No instance for (Num [Char]) arising from the literal ‘42’
• In the expression: 42
...Consider the code:
```hs
module TestTypes where
a = 42
b = a ++ "hello"
```
The type Error is (ghc-8.2.1):
```
TestTypes.hs:3:5: error:
• No instance for (Num [Char]) arising from the literal ‘42’
• In the expression: 42
In an equation for ‘a’: a = 42
|
3 | a = 42
| ^^
```
Actually, the real mistake is in line 5, where `a` is inferred as of type `[Char]`, while it was not meant to. But that location is not reported to the error. As you can guess, in real code location where the unexpected type is inferred for a binding is not that obvious to find.
Suggestion: track locations where bindings' types are inferred, and in case of type error involvin the bindings, add them to the "Relevant bindings" section, or otherwise show it.https://gitlab.haskell.org/ghc/ghc/-/issues/14386GHC doesn't allow Coercion between partly-saturated type constructors2019-07-07T18:17:13ZIcelandjackGHC doesn't allow Coercion between partly-saturated type constructorsIf I define an "opposite category" `newtype Op cat a b = Op (cat b a)` then representationally it forms an involution: applying `Op` twice gives the same representation as not applying it at all
```
$ ... -ignore-dot-ghci
GHCi, version ...If I define an "opposite category" `newtype Op cat a b = Op (cat b a)` then representationally it forms an involution: applying `Op` twice gives the same representation as not applying it at all
```
$ ... -ignore-dot-ghci
GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help
Prelude> import Data.Coerce
Prelude Data.Coerce> import Data.Type.Coercion
Prelude Data.Coerce Data.Type.Coercion> newtype Op cat a b = Op (cat b a)
Prelude Data.Coerce Data.Type.Coercion> :t coerce :: Op (Op cat) a b -> cat a b
coerce :: Op (Op cat) a b -> cat a b :: Op (Op cat) a b -> cat a b
Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a b) (cat a b)
Coercion :: Coercion (Op (Op cat) a b) (cat a b)
:: Coercion (Op (Op cat) a b) (cat a b)
```
But these don't work:
```
Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a) (cat a)
<interactive>:1:1: error:
• Couldn't match representation of type ‘Op (Op cat1) a1’
with that of ‘cat1 a1’
arising from a use of ‘Coercion’
• In the expression: Coercion :: Coercion (Op (Op cat) a) (cat a)
Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) cat
<interactive>:1:38: error:
parse error (possibly incorrect indentation or mismatched brackets)
Prelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat)) cat
<interactive>:1:1: error:
• Couldn't match representation of type ‘cat1’
with that of ‘Op (Op cat1)’
arising from a use of ‘Coercion’
‘cat1’ is a rigid type variable bound by
an expression type signature:
forall (cat1 :: * -> * -> *). Coercion (Op (Op cat1)) cat1
at <interactive>:1:13-38
• In the expression: Coercion :: Coercion (Op (Op cat)) cat
```
I'm wondering if this is intentional
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC doesn't allow Coercion between partly-saturated type constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":["roles"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I define an \"opposite category\" `newtype Op cat a b = Op (cat b a)` then representationally it forms an involution: applying `Op` twice gives the same representation as not applying it at all\r\n\r\n{{{\r\n$ ... -ignore-dot-ghci\r\nGHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help\r\nPrelude> import Data.Coerce\r\nPrelude Data.Coerce> import Data.Type.Coercion \r\nPrelude Data.Coerce Data.Type.Coercion> newtype Op cat a b = Op (cat b a)\r\nPrelude Data.Coerce Data.Type.Coercion> :t coerce :: Op (Op cat) a b -> cat a b\r\ncoerce :: Op (Op cat) a b -> cat a b :: Op (Op cat) a b -> cat a b\r\nPrelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a b) (cat a b)\r\nCoercion :: Coercion (Op (Op cat) a b) (cat a b)\r\n :: Coercion (Op (Op cat) a b) (cat a b)\r\n}}}\r\n\r\nBut these don't work:\r\n\r\n{{{\r\nPrelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) a) (cat a)\r\n\r\n<interactive>:1:1: error:\r\n • Couldn't match representation of type ‘Op (Op cat1) a1’\r\n with that of ‘cat1 a1’\r\n arising from a use of ‘Coercion’\r\n • In the expression: Coercion :: Coercion (Op (Op cat) a) (cat a)\r\nPrelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat) cat\r\n\r\n<interactive>:1:38: error:\r\n parse error (possibly incorrect indentation or mismatched brackets)\r\nPrelude Data.Coerce Data.Type.Coercion> :t Coercion :: Coercion (Op (Op cat)) cat\r\n\r\n<interactive>:1:1: error:\r\n • Couldn't match representation of type ‘cat1’\r\n with that of ‘Op (Op cat1)’\r\n arising from a use of ‘Coercion’\r\n ‘cat1’ is a rigid type variable bound by\r\n an expression type signature:\r\n forall (cat1 :: * -> * -> *). Coercion (Op (Op cat1)) cat1\r\n at <interactive>:1:13-38\r\n • In the expression: Coercion :: Coercion (Op (Op cat)) cat\r\n}}}\r\n\r\nI'm wondering if this is intentional","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14382The 'impossible' happened whilst installing gi-gtk via cabal2019-07-07T18:17:14ZmaartenjacobsThe 'impossible' happened whilst installing gi-gtk via cabalI've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary.
```
...
[91 of 95] Compiling GI.Pango...I've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary.
```
...
[91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found
You are in a maze of twisty little passages, all alike.
While forcing the thunk for TyThing Layout
which was lazily initialized by initIfaceCheck typecheckLoop,
I tried to tie the knot, but I couldn't find Layout
in the current type environment.
If you are developing GHC, please read Note [Tying the knot]
and Note [Type-checking inside the knot].
Consider rebuilding GHC with profiling for a better stack trace.
Contents of current type environment: []
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install gi-pango-1.0.15
cabal: Error: some packages failed to install:
gi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to
install.
gi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to
install.
gi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The
exception was:
ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The 'impossible' happened whilst installing gi-gtk via cabal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["gtk,","pango"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been trying to install gi-gtk using \"cabal install gi-gtk\". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary. \r\n\r\n{{{\r\n...\r\n[91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-unknown-linux):\r\n\ttcIfaceGlobal (local): not found\r\n You are in a maze of twisty little passages, all alike.\r\n While forcing the thunk for TyThing Layout\r\n which was lazily initialized by initIfaceCheck typecheckLoop,\r\n I tried to tie the knot, but I couldn't find Layout\r\n in the current type environment.\r\n If you are developing GHC, please read Note [Tying the knot]\r\n and Note [Type-checking inside the knot].\r\n Consider rebuilding GHC with profiling for a better stack trace.\r\n Contents of current type environment: []\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nFailed to install gi-pango-1.0.15\r\ncabal: Error: some packages failed to install:\r\ngi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to\r\ninstall.\r\ngi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to\r\ninstall.\r\ngi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The\r\nexception was:\r\nExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/14376Testsuite contains "ddump-cps-cmm"2019-07-07T18:17:16ZGabor GreifTestsuite contains "ddump-cps-cmm"Low hanging: change those to "ddump-cmm-cps". Run test suite.
Implement warning for non-recognised dump flags.
-------- IRC ----------
heisenbug: git grep ddump-cps-cmm \| grep -v /tests/
\[11:26am\] heisenbug: \^\^\^\^ is empty
\[11:2...Low hanging: change those to "ddump-cmm-cps". Run test suite.
Implement warning for non-recognised dump flags.
-------- IRC ----------
heisenbug: git grep ddump-cps-cmm \| grep -v /tests/
\[11:26am\] heisenbug: \^\^\^\^ is empty
\[11:27am\] heisenbug: git grep ddump-cmm-cps
\[11:27am\] heisenbug: \^\^\^\^ correct spelling
\[11:27am\] slyfox: should be fixed
\[11:28am\] heisenbug: should I update the tests?
\[11:28am\] slyfox: i'd say yes. do they run and fail?
\[11:29am\] heisenbug: I just found it, cannot say
\[11:29am\] heisenbug: I am researching…
\[11:30am\] heisenbug: strange that the wrong -ddump flags are not rejected…
\[11:30am\] slyfox: 'git log -p -Scps-cmm' shows the flag was renamed in f6f881f09c1ac69be2ae1850cb3067459f623360
\[11:31am\] heisenbug: but not the tests ?
\[11:31am\] slyfox: maybe they should emit at least a warning. that way tests would fails with stderr rejection
\[11:31am\] slyfox: not the tests
\[11:31am\] heisenbug: absolutely
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite contains \"ddump-cps-cmm\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Low hanging: change those to \"ddump-cmm-cps\". Run test suite.\r\nImplement warning for non-recognised dump flags.\r\n\r\n\r\n-------- IRC ----------\r\n\r\nheisenbug: git grep ddump-cps-cmm | grep -v /tests/\r\n[11:26am] heisenbug: ^^^^ is empty\r\n[11:27am] heisenbug: git grep ddump-cmm-cps\r\n[11:27am] heisenbug: ^^^^ correct spelling\r\n[11:27am] slyfox: should be fixed\r\n[11:28am] heisenbug: should I update the tests?\r\n[11:28am] slyfox: i'd say yes. do they run and fail?\r\n[11:29am] heisenbug: I just found it, cannot say\r\n[11:29am] heisenbug: I am researching…\r\n[11:30am] heisenbug: strange that the wrong -ddump flags are not rejected…\r\n[11:30am] slyfox: 'git log -p -Scps-cmm' shows the flag was renamed in f6f881f09c1ac69be2ae1850cb3067459f623360\r\n[11:31am] heisenbug: but not the tests ?\r\n[11:31am] slyfox: maybe they should emit at least a warning. that way tests would fails with stderr rejection\r\n[11:31am] slyfox: not the tests\r\n[11:31am] heisenbug: absolutely","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14374group by using groupWith seems stricter than it need be2019-07-07T18:17:16Zistandleetgroup by using groupWith seems stricter than it need beUsing TransformListComps:
```hs
import GHC.Exts (the, groupWith)
is = [1..10]
fs = map ((,) False) is
ts = map ((,) True ) is
r1 = [(the b, take 5 n) | (b,n) <- ts ++ fs, then group by b using groupWith]
r2 = [(the b, take 5 n) | (b,n...Using TransformListComps:
```hs
import GHC.Exts (the, groupWith)
is = [1..10]
fs = map ((,) False) is
ts = map ((,) True ) is
r1 = [(the b, take 5 n) | (b,n) <- ts ++ fs, then group by b using groupWith]
r2 = [(the b, take 5 n) | (b,n) <- ts ++ fs ++ [undefined], then group by b using groupWith]
r3 = take 2 r2
```
As of GHC 8.2.1, both r2 and r3 fail.
While getting r2 to work seems difficult - it would require realizing that the domain of Bool has been satisfied - r3 seems like it might be more feasible to get working.
As a motivator, this pattern is pretty common in data science, where we want to map elements of a large list to a small result domain and get examples of those elements with each result without iterating through the whole list.https://gitlab.haskell.org/ghc/ghc/-/issues/14372CMM contains a bunch of tail-merging opportunities2019-07-07T18:17:17ZGabor GreifCMM contains a bunch of tail-merging opportunitiesCompile this code to CMM
```hs
data Small = S1 | S2 | S3 | S4 deriving (Show, Enum)
data Big = B1 | B2 | B3 | B4 | B5 | B6 | B7 | B8 | B9 | B10 deriving (Show, Enum)
{-# NOINLINE quux #-}
quux B1 = 'a'
quux B2 = 'b'
quux B3 = 'c'
quux...Compile this code to CMM
```hs
data Small = S1 | S2 | S3 | S4 deriving (Show, Enum)
data Big = B1 | B2 | B3 | B4 | B5 | B6 | B7 | B8 | B9 | B10 deriving (Show, Enum)
{-# NOINLINE quux #-}
quux B1 = 'a'
quux B2 = 'b'
quux B3 = 'c'
quux B4 = 'd'
quux B5 = 'e'
quux B6 = 'f'
quux B7 = 'g'
quux B8 = 'h'
quux B9 = 'i'
quux B10 = 'j'
{-# NOINLINE qaax #-}
qaax B1 = 'a'
qaax B2 = 'b'
qaax B3 = 'c'
qaax B4 = 'd'
qaax B5 = 'e'
qaax B7 = 'g'
qaax B8 = 'h'
qaax B9 = 'i'
qaax B10 = 'j'
{-# NOINLINE foo #-}
foo B1 = S1
foo B2 = S2
foo B3 = S3
foo B4 = S4
{-# NOINLINE bar #-}
bar S1 = B1
bar S2 = B2
bar S3 = B3
bar S4 = B4
main = do print $ take 100000 (repeat (foo <$> [B1 .. B4]))
print $ take 100000 (repeat (bar <$> [S1 .. S4]))
print $ take 100000 (repeat (quux <$> [B1 .. B10]))
print $ qaax B1
```
When `Char` or *enum-like* ADT is returned, I see lots of case branches, which only differ in the first instruction.
E.g.
```
c30l: // global
R1 = stg_CHARLIKE_closure+1649;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30m: // global
R1 = stg_CHARLIKE_closure+1665;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
u30Z: // global
if (_c30p::I64 < 9) goto c30n; else goto c30o;
c30n: // global
R1 = stg_CHARLIKE_closure+1681;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30o: // global
R1 = stg_CHARLIKE_closure+1697;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
```
It would be nice to factor out the common tails, e.g. by branching to the first tail already emitted.
Bonus points for rewriting switch tables to contain the above numbers and compile to a lookup + common code.
This is what I am talking about:
```
c307: // global
_s2ON::P64 = R1;
_c30j::P64 = _s2ON::P64 & 7;
switch [1 .. 7] _c30j::P64 {
case 1 : goto c30d;
case 2 : goto c30e;
case 3 : goto c30f;
case 4 : goto c30g;
case 5 : goto c30h;
...
}
...
c30h: // global
R1 = stg_CHARLIKE_closure+1617;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30g: // global
R1 = stg_CHARLIKE_closure+1601;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30f: // global
R1 = stg_CHARLIKE_closure+1585;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30e: // global
R1 = stg_CHARLIKE_closure+1569;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c30d: // global
R1 = stg_CHARLIKE_closure+1553;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
```
There should be an array \[1553, 1569, 1585, ...\]
and each case should be the same:
```
R1 = stg_CHARLIKE_closure;
R1 = R1 + array[tag];
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
```
See also #14666https://gitlab.haskell.org/ghc/ghc/-/issues/14370improve documentation of -fdefer-typed-holes for naked expressions in ghci2023-04-13T23:16:33ZBertram Felgenhauerimprove documentation of -fdefer-typed-holes for naked expressions in ghciConsider the following ghci session.
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -fdefer-typed-holes -Wno-typed-holes
Prelude> :set -fdefer-out-of-scope-variables -Wno-deferred-out-of-scope-variables
...Consider the following ghci session.
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -fdefer-typed-holes -Wno-typed-holes
Prelude> :set -fdefer-out-of-scope-variables -Wno-deferred-out-of-scope-variables
Prelude> let x = [_]; y = [r]
Prelude> (length x, length y)
(1,1)
Prelude> length [_]
<interactive>:4:9: error:
• Found hole: _ :: a0
Where: ‘a0’ is an ambiguous type variable
• In the expression: _
In the first argument of ‘length’, namely ‘[_]’
In the expression: length [_]
• Relevant bindings include it :: Int (bound at <interactive>:4:1)
Prelude> length [r]
1
```
Why does the `length [_]` expression produce a type error immediately instead of being deferred?
\~\~(I've asked the same question in #14367 but this looks like a real bug.)\~\~
The documentation can be improved here, see \[\#[ticket:14370\#comment:144137](https://gitlab.haskell.org//ghc/ghc/issues/14370#note_144137) comment 2\]