GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:20:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13752Odd pattern synonym type errors2019-07-07T18:20:15ZDavid FeuerOdd pattern synonym type errorsSuppose we have
```hs
newtype Arrange = Arrange {getArrange :: [Int] -> [Int]}
```
If I write
```hs
pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange
pattern Heh f <- Arrange f
```
I get
```
• Couldn't m...Suppose we have
```hs
newtype Arrange = Arrange {getArrange :: [Int] -> [Int]}
```
If I write
```hs
pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange
pattern Heh f <- Arrange f
```
I get
```
• Couldn't match type ‘[Int] -> [Int]’
with ‘forall a. Int ~ a => [a] -> [a]’
Expected type: forall a. c a => [a] -> [a]
Actual type: [Int] -> [Int]
• In the declaration for pattern synonym ‘Heh’
```
It surprises me that these don't match. I can hack around that a bit:
```hs
newtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]}
pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange
pattern Heh f <- ((\x -> Help (getArrange x)) -> Help f)
```
Now this compiles, and I can use it in a variety of ways, but not quite all. If I write
```hs
pattern Heh' :: ([Int] -> [Int]) -> Arrange
pattern Heh' f <- Heh f
```
I get
```
Haha.hs:78:23: error:
• Couldn't match expected type ‘[Int] -> [Int]’
with actual type ‘forall a. Int ~ a => [a] -> [a]’
• In the declaration for pattern synonym ‘Heh'’
|
78 | pattern Heh' f <- Heh f
| ^
```
This strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck!
```hs
pattern Heh' :: ([Int] -> [Int]) -> Arrange
pattern Heh' f <- ((\(Heh g) -> g @ Int) -> f)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Odd pattern synonym type errors","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Suppose we have\r\n\r\n{{{#!hs\r\nnewtype Arrange = Arrange {getArrange :: [Int] -> [Int]}\r\n}}}\r\n\r\nIf I write\r\n\r\n{{{#!hs\r\npattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange\r\npattern Heh f <- Arrange f\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\n • Couldn't match type ‘[Int] -> [Int]’\r\n with ‘forall a. Int ~ a => [a] -> [a]’\r\n Expected type: forall a. c a => [a] -> [a]\r\n Actual type: [Int] -> [Int]\r\n • In the declaration for pattern synonym ‘Heh’\r\n}}}\r\n\r\nIt surprises me that these don't match. I can hack around that a bit:\r\n\r\n{{{#!hs\r\nnewtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]}\r\n\r\npattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange\r\npattern Heh f <- ((\\x -> Help (getArrange x)) -> Help f)\r\n}}}\r\n\r\nNow this compiles, and I can use it in a variety of ways, but not quite all. If I write\r\n\r\n{{{#!hs\r\npattern Heh' :: ([Int] -> [Int]) -> Arrange\r\npattern Heh' f <- Heh f\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nHaha.hs:78:23: error:\r\n • Couldn't match expected type ‘[Int] -> [Int]’\r\n with actual type ‘forall a. Int ~ a => [a] -> [a]’\r\n • In the declaration for pattern synonym ‘Heh'’\r\n |\r\n78 | pattern Heh' f <- Heh f\r\n | ^\r\n}}}\r\n\r\nThis strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck!\r\n\r\n{{{#!hs\r\npattern Heh' :: ([Int] -> [Int]) -> Arrange\r\npattern Heh' f <- ((\\(Heh g) -> g @ Int) -> f)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13751Runtime crash with <<loop>> after concurrent stressing of STM computations2019-07-07T18:20:15ZliteronRuntime crash with <<loop>> after concurrent stressing of STM computationsFor reproduction, see stack project at https://github.com/robinp/bugreports/tree/master/blackhole. Copying its readme here:
\#\#\# Compiler & OS
GHC 7.10.3, 8.0.1, 8.0.2 (didn't check others).
Linux: 4.10.13-1-ARCH #1 SMP PREEMPT x86_...For reproduction, see stack project at https://github.com/robinp/bugreports/tree/master/blackhole. Copying its readme here:
\#\#\# Compiler & OS
GHC 7.10.3, 8.0.1, 8.0.2 (didn't check others).
Linux: 4.10.13-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux 4-core
\#\#\# What does the code do?
TLDR endlessly forks a batch of 8 threads, and waits for them to finish. Each
thread calls `observeDuration` on an irrelevant IO action. `observeDuration`
measures the time, then updates some data structures in `STM` context in a
`TVar`.
After a short while (usually within 1 minute), the program aborts with
`<<loop>>`. See below for a more detailed investigation.
\#\#\# To run
> stack install
> \# Restart if doesn't terminate in a minute.
> loop-exe +RTS -N4 -Ds \> debug 2\> debug.out ; beep
\#\#\# Observe
`debug` shows the metering batches run for a while, then get stuck.
`debug.out` contains `<<loop>>`.
My debug log reading fu is poor, but in less cleaned-up versions of the program
it was more trivial to see that two threads get blocked on each others
blackhole.
In the current log there is mentioning of blackholes, but also MVars, and I
don't see what's going on.
\#\#\# Tracking down
When built with profiling (remove `--eventlog --debug` from cabal file, then
`stack clean` then `stack build --profile`), and running with `+RTS -N4 -xc`
the following stack traces appear:
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Prometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Prometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.meter,
called from Main.mainPrometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (IND_STATIC), stack trace:
Prometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
loop-exe: loop-exe: \<\<loop\>\>
\<\<loop\>\>
loop-exe: thread blocked indefinitely in an MVar operation
An other stack trace from an other run as bonus (these two are representative):
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Prometheus.Metric.Summary.invariant,
called from Prometheus.Metric.Summary.compress,
called from Prometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Prometheus.Metric.Summary.invariant,
called from Prometheus.Metric.Summary.compress,
called from Prometheus.Metric.Summary.observe,
called from Prometheus.Metric.Summary.observeDuration,
called from Main.meter.action,
called from Main.meter.cfork,
called from Main.meter,
called from Main.main
loop-exe: \<\<loop\>\>
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.meter,
called from Main.main
- \*\* Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.meter,
called from Main.main
loop-exe: thread blocked indefinitely in an MVar operation
I tried to even simplify by removing `prometheus-client` dep, but it seems that
the kind of computation done in Prometheus.Metric.Summary.observe, namely
putting a lazy computation inside a data type stored in a TVar, are needed to
trigger the blackholing. When I tried to simplify those operations, or bang
the remaining few fields of the data type, the error didn't reproduce (at least
couldn't reproduce as quick as it usually does).
The relevant pieces of code from prometheus-client's P.M.Summary module. Note:
I manually replaced the `MonadMonitor` constraint with plain IO in that call
chain, but it didn't have much effect.
```hs
data Estimator = Estimator {
estCount :: !Int64
, estSum :: !Double
, estQuantiles :: [Quantile]
, estItems :: [Item]
} deriving (Show)
newtype Summary = MkSummary (STM.TVar Estimator)
observeDuration :: IO a -> Metric Summary -> IO a
observeDuration io metric = do
start <- getCurrentTime
result <- io
end <- getCurrentTime
let dt = fromRational $ toRational $ end `diffUTCTime` start
withSummary metric dt
return result
observe :: MonadMonitor m => Double -> Metric Summary -> m ()
observe v s = withSummary s (insert v)
withSummary :: MonadMonitor m => Metric Summary -> (Estimator -> Estimator) -> m ()
withSummary (Metric {handle = MkSummary valueTVar}) f =
doIO $ STM.atomically $ do
STM.modifyTVar' valueTVar compress
STM.modifyTVar' valueTVar f
insert :: Double -> Estimator -> Estimator
insert = ...
compress :: Estimator -> Estimator
compress = ...
```
I checked `insert` and `compress` and they don't seem to be able to loop in
any edge case, so this bug is likely an RTS thing.
\#\#\# Related tickets I found:
#10218
GHC creates incorrect code which throws \<\<loop\>\>
#10414 :
> Buggy behavior with threaded runtime (-N1 working, -N2 getting into \<\<loop\>\>)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Runtime crash with <<loop>> after concurrent stressing of STM computatinos.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","simonmar"],"type":"Bug","description":"For reproduction, see stack project at https://github.com/robinp/bugreports/tree/master/blackhole. Copying its readme here:\r\n\r\n### Compiler & OS\r\n\r\nGHC 7.10.3, 8.0.1, 8.0.2 (didn't check others).\r\n\r\nLinux: 4.10.13-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux 4-core\r\n\r\n### What does the code do?\r\n\r\nTLDR endlessly forks a batch of 8 threads, and waits for them to finish. Each\r\nthread calls `observeDuration` on an irrelevant IO action. `observeDuration`\r\nmeasures the time, then updates some data structures in `STM` context in a\r\n`TVar`.\r\n\r\nAfter a short while (usually within 1 minute), the program aborts with\r\n`<<loop>>`. See below for a more detailed investigation.\r\n\r\n### To run\r\n\r\n stack install\r\n\r\n # Restart if doesn't terminate in a minute.\r\n\r\n loop-exe +RTS -N4 -Ds > debug 2> debug.out ; beep\r\n\r\n### Observe\r\n\r\n`debug` shows the metering batches run for a while, then get stuck.\r\n\r\n`debug.out` contains `<<loop>>`.\r\n\r\nMy debug log reading fu is poor, but in less cleaned-up versions of the program\r\nit was more trivial to see that two threads get blocked on each others\r\nblackhole.\r\n\r\nIn the current log there is mentioning of blackholes, but also MVars, and I\r\ndon't see what's going on.\r\n\r\n### Tracking down\r\n\r\nWhen built with profiling (remove `--eventlog --debug` from cabal file, then\r\n`stack clean` then `stack build --profile`), and running with `+RTS -N4 -xc`\r\nthe following stack traces appear:\r\n\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tMain.meter,\r\n\t\t\tcalled from Main.main\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tPrometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tPrometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tMain.meter,\r\n\t\t\tcalled from Main.mainPrometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\r\n\t\t*** Exception (reporting due to +RTS -xc): (IND_STATIC), stack trace: \r\n\t\t\tPrometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\t\tloop-exe: loop-exe: <<loop>>\r\n\t\t<<loop>>\r\n\t\tloop-exe: thread blocked indefinitely in an MVar operation\r\n\r\nAn other stack trace from an other run as bonus (these two are representative):\r\n\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tPrometheus.Metric.Summary.invariant,\r\n\t\t\tcalled from Prometheus.Metric.Summary.compress,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tPrometheus.Metric.Summary.invariant,\r\n\t\t\tcalled from Prometheus.Metric.Summary.compress,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observe,\r\n\t\t\tcalled from Prometheus.Metric.Summary.observeDuration,\r\n\t\t\tcalled from Main.meter.action,\r\n\t\t\tcalled from Main.meter.cfork,\r\n\t\t\tcalled from Main.meter,\r\n\t\t\tcalled from Main.main\r\n\t\tloop-exe: <<loop>>\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tMain.meter,\r\n\t\t\tcalled from Main.main\r\n\t\t*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n\t\t\tMain.meter,\r\n\t\t\tcalled from Main.main\r\n\t\tloop-exe: thread blocked indefinitely in an MVar operation\r\n\r\nI tried to even simplify by removing `prometheus-client` dep, but it seems that\r\nthe kind of computation done in Prometheus.Metric.Summary.observe, namely\r\nputting a lazy computation inside a data type stored in a TVar, are needed to\r\ntrigger the blackholing. When I tried to simplify those operations, or bang\r\nthe remaining few fields of the data type, the error didn't reproduce (at least\r\ncouldn't reproduce as quick as it usually does).\r\n\r\nThe relevant pieces of code from prometheus-client's P.M.Summary module. Note:\r\nI manually replaced the `MonadMonitor` constraint with plain IO in that call\r\nchain, but it didn't have much effect.\r\n\r\n{{{#!hs\r\n\t\tdata Estimator = Estimator {\r\n\t estCount :: !Int64\r\n\t\t, estSum :: !Double\r\n\t\t, estQuantiles :: [Quantile]\r\n\t\t, estItems :: [Item]\r\n\t\t} deriving (Show)\r\n\r\n\t\tnewtype Summary = MkSummary (STM.TVar Estimator)\r\n\r\n\t\tobserveDuration :: IO a -> Metric Summary -> IO a\r\n\t\tobserveDuration io metric = do\r\n\t\t\t\tstart <- getCurrentTime\r\n\t\t\t\tresult <- io\r\n\t\t\t\tend <- getCurrentTime\r\n\t\t\t\tlet dt = fromRational $ toRational $ end `diffUTCTime` start\r\n\t\t\t\twithSummary metric dt\r\n\t\t\t\treturn result\r\n\r\n\t\tobserve :: MonadMonitor m => Double -> Metric Summary -> m ()\r\n\t\tobserve v s = withSummary s (insert v)\r\n\r\n\t\twithSummary :: MonadMonitor m => Metric Summary -> (Estimator -> Estimator) -> m ()\r\n\t\twithSummary (Metric {handle = MkSummary valueTVar}) f =\r\n\t\t\t\tdoIO $ STM.atomically $ do\r\n\t\t\t\t\t\tSTM.modifyTVar' valueTVar compress\r\n\t\t\t\t\t\tSTM.modifyTVar' valueTVar f\r\n\r\n\r\n\t\tinsert :: Double -> Estimator -> Estimator\r\n insert = ...\r\n\r\n\t\tcompress :: Estimator -> Estimator\r\n compress = ...\r\n}}}\r\n\r\nI checked `insert` and `compress` and they don't seem to be able to loop in\r\nany edge case, so this bug is likely an RTS thing.\r\n\r\n### Related tickets I found:\r\n\r\nhttps://ghc.haskell.org/trac/ghc/ticket/10218\r\n\t\tGHC creates incorrect code which throws <<loop>>\r\n\r\nhttps://ghc.haskell.org/trac/ghc/ticket/10414 :\r\n Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/13750GHC produces incorrect coercions in hairy code2019-07-07T18:20:16ZDavid FeuerGHC produces incorrect coercions in hairy codeAndres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly ...Andres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly bogus definition in `-ddump-simpl` (with -O):
```
Main.gshowP_$dAll :: All MyShow GHC.Exts.Any
[GblId,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False,
WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]
Main.gshowP_$dAll
= ghc-prim-0.5.0.0:GHC.Classes.$p1(%,%)
@ (All MyShow GHC.Exts.Any)
@ (All (All MyShow) GHC.Exts.Any)
(ghc-prim-0.5.0.0:GHC.Classes.C:(%%)
`cast` (Sub (Sym (Main.D:R:AllFk_c[][0] <[*]>_N <All MyShow>_N))
; Sym (Main.N:All[0] <[*]>_N <All MyShow>_N <'[]>_N)
; Sub
(Nth:1
(Sub
(Sym
(Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <'[Char]>_N <'[]>_N))
; (AllF
<[*]>_N
<All MyShow>_N
((':)
<[*]>_N
(UnsafeCo nominal '[Char] GHC.Exts.Any)
(UnsafeCo nominal '[] GHC.Exts.Any))_N)_R
; Sub
(Main.D:R:AllFkc:[0]
<[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N)))
; Main.N:All[0]
<[*]>_N
<All MyShow>_N
(UnsafeCo nominal GHC.Exts.Any (GHC.Exts.Any : GHC.Exts.Any))
; Sub
(Main.D:R:AllFkc:[0]
<[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N)
:: (() :: Constraint :: Constraint)
~R#
((All MyShow GHC.Exts.Any,
All (All MyShow) GHC.Exts.Any) :: Constraint)))
```
<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 | kosmikus |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC produces incorrect coercions in hairy code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["kosmikus"],"type":"Bug","description":"Andres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly bogus definition in `-ddump-simpl` (with -O):\r\n\r\n{{{\r\nMain.gshowP_$dAll :: All MyShow GHC.Exts.Any\r\n[GblId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False,\r\n WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nMain.gshowP_$dAll\r\n = ghc-prim-0.5.0.0:GHC.Classes.$p1(%,%)\r\n @ (All MyShow GHC.Exts.Any)\r\n @ (All (All MyShow) GHC.Exts.Any)\r\n (ghc-prim-0.5.0.0:GHC.Classes.C:(%%)\r\n `cast` (Sub (Sym (Main.D:R:AllFk_c[][0] <[*]>_N <All MyShow>_N))\r\n ; Sym (Main.N:All[0] <[*]>_N <All MyShow>_N <'[]>_N)\r\n ; Sub\r\n (Nth:1\r\n (Sub\r\n (Sym\r\n (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <'[Char]>_N <'[]>_N))\r\n ; (AllF\r\n <[*]>_N\r\n <All MyShow>_N\r\n ((':)\r\n <[*]>_N\r\n (UnsafeCo nominal '[Char] GHC.Exts.Any)\r\n (UnsafeCo nominal '[] GHC.Exts.Any))_N)_R\r\n ; Sub\r\n (Main.D:R:AllFkc:[0]\r\n <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N)))\r\n ; Main.N:All[0]\r\n <[*]>_N\r\n <All MyShow>_N\r\n (UnsafeCo nominal GHC.Exts.Any (GHC.Exts.Any : GHC.Exts.Any))\r\n ; Sub\r\n (Main.D:R:AllFkc:[0]\r\n <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N)\r\n :: (() :: Constraint :: Constraint)\r\n ~R#\r\n ((All MyShow GHC.Exts.Any,\r\n All (All MyShow) GHC.Exts.Any) :: Constraint)))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/13749Panic (initTc: unresolved constraints) on some bad code2019-07-07T18:20:16ZuraniumPanic (initTc: unresolved constraints) on some bad codeI was just refactoring some code, and partway through, before it was all compiling, I hit the below error. The code's probably just terrible in an interestingly new way; I'm pretty inexperienced at Haskell. I'll attach the file.
Prelude...I was just refactoring some code, and partway through, before it was all compiling, I hit the below error. The code's probably just terrible in an interestingly new way; I'm pretty inexperienced at Haskell. I'll attach the file.
Prelude\> :r
\[1 of 1\] Compiling Main ( /home/uranium/projects/server/src/Main.hs, interpreted )
ghc: panic! (the 'impossible' happened)
> (GHC version 8.0.2 for x86_64-unknown-linux):
initTc: unsolved constraints
WC {wc_insol =
<table><tr><th>\[W\] get_aGsK </th>
<td>t_aGsJ\[tau:1\] (CHoleCan: get)</td></tr>
<tr><th>\[W\] execState_aGsX </th>
<td>t_aGsW\[tau:1\] (CHoleCan: execState)</td></tr>
<tr><th>\[W\] get_aGvL </th>
<td>t_aGvK\[tau:1\] (CHoleCan: get)</td></tr>
<tr><th>\[W\] lift_aGvU </th>
<td>t_aGvT\[tau:1\] (CHoleCan: lift)</td></tr>
<tr><th>\[W\] put_aGw3 </th>
<td>t_aGw2\[tau:1\] (CHoleCan: put)</td></tr>
<tr><th>\[W\] cellType_aGwy </th>
<td>t_aGwx\[tau:1\] (CHoleCan: cellType)</td></tr>
<tr><th>\[W\] insts_aGwB </th>
<td>t_aGwA\[tau:1\] (CHoleCan: insts)</td></tr>
<tr><th>\[W\] ports_aGwE </th>
<td>t_aGwD\[tau:1\] (CHoleCan: ports)</td></tr>
<tr><th>\[W\] conns_aGwH </th>
<td>t_aGwG\[tau:1\] (CHoleCan: conns)</td></tr>
<tr><th>\[W\] annos_aGwK </th>
<td>t_aGwJ\[tau:1\] (CHoleCan: annos)</td></tr>
<tr><th>\[W\] comms_aGwN </th>
<td>t_aGwM\[tau:1\] (CHoleCan: comms)}</td></tr></table>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Panic (initTc: unresolved constraints) on some bad code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was just refactoring some code, and partway through, before it was all compiling, I hit the below error. The code's probably just terrible in an interestingly new way; I'm pretty inexperienced at Haskell. I'll attach the file.\r\n\r\nPrelude> :r\r\n[1 of 1] Compiling Main ( /home/uranium/projects/server/src/Main.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n\tinitTc: unsolved constraints\r\n WC {wc_insol =\r\n [W] get_aGsK :: t_aGsJ[tau:1] (CHoleCan: get)\r\n [W] execState_aGsX :: t_aGsW[tau:1] (CHoleCan: execState)\r\n [W] get_aGvL :: t_aGvK[tau:1] (CHoleCan: get)\r\n [W] lift_aGvU :: t_aGvT[tau:1] (CHoleCan: lift)\r\n [W] put_aGw3 :: t_aGw2[tau:1] (CHoleCan: put)\r\n [W] cellType_aGwy :: t_aGwx[tau:1] (CHoleCan: cellType)\r\n [W] insts_aGwB :: t_aGwA[tau:1] (CHoleCan: insts)\r\n [W] ports_aGwE :: t_aGwD[tau:1] (CHoleCan: ports)\r\n [W] conns_aGwH :: t_aGwG[tau:1] (CHoleCan: conns)\r\n [W] annos_aGwK :: t_aGwJ[tau:1] (CHoleCan: annos)\r\n [W] comms_aGwN :: t_aGwM[tau:1] (CHoleCan: comms)}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13748Variables pretty-printed from -ddump-deriv are not scoped properly2019-07-07T18:20:17ZRyan ScottVariables pretty-printed from -ddump-deriv are not scoped properlyThis bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in #13738\##13748. Take this code:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE PolyKinds #-}
{-# OPTIONS_GHC -ddump-deriv #-}
module Works ...This bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in #13738\##13748. Take this code:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE PolyKinds #-}
{-# OPTIONS_GHC -ddump-deriv #-}
module Works where
newtype Wrap f a = Wrap (f a) deriving C
class C f where
c :: f a
```
When you compile it with GHC 8.0.2, you'll get this unsavory output:
```
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Works ( Works.hs, interpreted )
==================== Derived instances ====================
Derived instances:
instance forall k_a14U (f_a14V :: k_a14U -> *).
Works.C f_a14V =>
Works.C (Works.Wrap f_a14V) where
Works.c
= GHC.Prim.coerce
@(forall (a_a13F :: k_a14u). f_a13G a_a13F)
@(forall (a_a13F :: k_a14u). Works.Wrap f_a13G a_a13F)
Works.c
GHC.Generics representation types:
```
This is wrong, since the quantified variables in the instance head (`k_a14U` and `f_a14V`) do not match the occurrences that they bind (`k_a14u` and `f_a13G`). This is somewhat easier to see on GHC 8.2.1 or HEAD, since the binding sites are printed without uniques:
```
GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Works ( Works.hs, interpreted )
==================== Derived instances ====================
Derived class instances:
instance forall k (f :: k -> *).
Works.C f =>
Works.C (Works.Wrap f) where
Works.c
= GHC.Prim.coerce
@(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD)
@(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD)
Works.c
Derived type family instances:
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Variables pretty-printed from -ddump-deriv are not scoped properly","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug is present on GHC 8.0.1, 8.0.2, 8.2.1 and HEAD, and originally noted in https://ghc.haskell.org/trac/ghc/ticket/13738#comment:2. Take this code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# OPTIONS_GHC -ddump-deriv #-}\r\nmodule Works where\r\n\r\nnewtype Wrap f a = Wrap (f a) deriving C\r\n\r\nclass C f where\r\n c :: f a\r\n}}}\r\n\r\nWhen you compile it with GHC 8.0.2, you'll get this unsavory output:\r\n\r\n{{{\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Works ( Works.hs, interpreted )\r\n\r\n==================== Derived instances ====================\r\nDerived instances:\r\n instance forall k_a14U (f_a14V :: k_a14U -> *).\r\n Works.C f_a14V =>\r\n Works.C (Works.Wrap f_a14V) where\r\n Works.c\r\n = GHC.Prim.coerce\r\n @(forall (a_a13F :: k_a14u). f_a13G a_a13F)\r\n @(forall (a_a13F :: k_a14u). Works.Wrap f_a13G a_a13F)\r\n Works.c\r\n \r\n\r\nGHC.Generics representation types:\r\n}}}\r\n\r\nThis is wrong, since the quantified variables in the instance head (`k_a14U` and `f_a14V`) do not match the occurrences that they bind (`k_a14u` and `f_a13G`). This is somewhat easier to see on GHC 8.2.1 or HEAD, since the binding sites are printed without uniques:\r\n\r\n{{{\r\nGHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Works ( Works.hs, interpreted )\r\n\r\n==================== Derived instances ====================\r\nDerived class instances:\r\n instance forall k (f :: k -> *).\r\n Works.C f =>\r\n Works.C (Works.Wrap f) where\r\n Works.c\r\n = GHC.Prim.coerce\r\n @(forall (a_a1tD :: k_a1uE). f_a1tE a_a1tD)\r\n @(forall (a_a1tD :: k_a1uE). Works.Wrap f_a1tE a_a1tD)\r\n Works.c\r\n \r\n\r\nDerived type family instances:\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13747Can't use 'instance' keyword in associated type family instance2019-09-23T10:48:33ZNiklas Hambüchenmail@nh2.meCan't use 'instance' keyword in associated type family instance[The manual on type families says:](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#associated-instances)
> When an associated data or type synonym family instance is declared within a type class instan...[The manual on type families says:](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#associated-instances)
> When an associated data or type synonym family instance is declared within a type class instance, we (optionally) may drop the instance keyword in the family instance"
But that doesn't work for me.
Using
```
class Myclass a where
type family MyFamily a :: *
```
then the code
```
instance Myclass Mytype where
type instance MyFamily Mytype = Int
```
doesn't compile but
```
instance Myclass Mytype where
type MyFamily Mytype = Int
```
I'd expect to be able to use the `instance` keyword here.
I'd prefer this to be treated as an implementation bug instead of a doc bug, because I think it can be useful to be explicit for the ease of reading (and it work works the same way for class declaration, as the example also demonstrates).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't use 'instance' keyword in associated type family instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#associated-instances The manual on type families says:]\r\n\r\n> When an associated data or type synonym family instance is declared within a type class instance, we (optionally) may drop the instance keyword in the family instance\"\r\n\r\nBut that doesn't work for me.\r\n\r\nUsing\r\n\r\n{{{\r\nclass Myclass a where\r\n type family MyFamily a :: *\r\n}}}\r\n\r\nthen the code\r\n\r\n{{{\r\ninstance Myclass Mytype where\r\n type instance MyFamily Mytype = Int\r\n}}}\r\n\r\ndoesn't compile but\r\n\r\n{{{\r\ninstance Myclass Mytype where\r\n type MyFamily Mytype = Int\r\n}}}\r\n\r\nI'd expect to be able to use the `instance` keyword here.\r\n\r\nI'd prefer this to be treated as an implementation bug instead of a doc bug, because I think it can be useful to be explicit for the ease of reading (and it work works the same way for class declaration, as the example also demonstrates).","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1erdeszterdeszthttps://gitlab.haskell.org/ghc/ghc/-/issues/13746Typeable changes in base-4.10 break ChasingBottoms's test suite2019-07-07T18:20:18ZrefoldTypeable changes in base-4.10 break ChasingBottoms's test suiteWhen compiled against base-4.10, `ChasingBottoms`'s test suite fails with:
```
Approx:
ChasingBottomsTestSuite: typeRepTyCon: FunTy
CallStack (from HasCallStack):
error, called at libraries/base/Data/Typeable/Internal.hs:308:33 in bas...When compiled against base-4.10, `ChasingBottoms`'s test suite fails with:
```
Approx:
ChasingBottomsTestSuite: typeRepTyCon: FunTy
CallStack (from HasCallStack):
error, called at libraries/base/Data/Typeable/Internal.hs:308:33 in base:Data.Typeable.Internal
```
This is due to the use of `error` in the following function in [\`Data.Typeable.Internal\`](https://github.com/ghc/ghc/blob/master/libraries/base/Data/Typeable/Internal.hs#L308):
```hs
-- | Observe the type constructor of a type representation
typeRepTyCon :: TypeRep a -> TyCon
typeRepTyCon (TrTyCon _ tc _) = tc
typeRepTyCon (TrApp _ a _) = typeRepTyCon a
typeRepTyCon (TrFun _ _ _) = error "typeRepTyCon: FunTy" -- TODO
```
`ChasingBottoms`'s test suite works fine when compiled with GHC 8.0.2. It seems to me that the change in behaviour constitutes a bug or a breaking change (for which there is no mention in the changelog).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typeable changes in base-4.10 break ChasingBottoms's test suite","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiled against base-4.10, `ChasingBottoms`'s test suite fails with:\r\n\r\n{{{\r\nApprox:\r\nChasingBottomsTestSuite: typeRepTyCon: FunTy\r\nCallStack (from HasCallStack):\r\n error, called at libraries/base/Data/Typeable/Internal.hs:308:33 in base:Data.Typeable.Internal\r\n}}}\r\n\r\nThis is due to the use of `error` in the following function in [https://github.com/ghc/ghc/blob/master/libraries/base/Data/Typeable/Internal.hs#L308 `Data.Typeable.Internal`]:\r\n\r\n{{{#!hs\r\n-- | Observe the type constructor of a type representation\r\ntypeRepTyCon :: TypeRep a -> TyCon\r\ntypeRepTyCon (TrTyCon _ tc _) = tc\r\ntypeRepTyCon (TrApp _ a _) = typeRepTyCon a\r\ntypeRepTyCon (TrFun _ _ _) = error \"typeRepTyCon: FunTy\" -- TODO\r\n}}}\r\n\r\n`ChasingBottoms`'s test suite works fine when compiled with GHC 8.0.2. It seems to me that the change in behaviour constitutes a bug or a breaking change (for which there is no mention in the changelog).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13745Investigate compile-time regressions in regex-tdfa-1.2.22019-11-04T10:55:02ZBen GamariInvestigate compile-time regressions in regex-tdfa-1.2.2hvr [points out](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html) that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically whil...hvr [points out](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html) that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose.
```
GHC 8.0.2:
<<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes
residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed),
55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>>
GHC 8.2.1:
<<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes
residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed),
64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>>
```
## Reproducing
```
$ cabal unpack regex-tdfa-1.2.2
$ cd regex-tdfa-1.2.2
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
$ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \
-XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \
-XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \
-XFlexibleContexts -XUnliftedFFITypes
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Investigate compile-time regressions in regex-tdfa-1.2.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"hvr [[https://mail.haskell.org/pipermail/ghc-devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose.\r\n\r\n{{{\r\nGHC 8.0.2:\r\n\r\n<<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes\r\nresidency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed),\r\n55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>>\r\n\r\nGHC 8.2.1:\r\n\r\n<<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes\r\nresidency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed),\r\n64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>>\r\n}}}\r\n\r\n== Reproducing ==\r\n\r\n{{{\r\n$ cabal unpack regex-tdfa-1.2.2\r\n$ cd regex-tdfa-1.2.2\r\n$ cabal install --only-dependencies\r\n$ cabal configure\r\n$ cabal build\r\n$ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \\\r\n -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \\\r\n -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \\\r\n -XFlexibleContexts -XUnliftedFFITypes\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/13744Compile-time regression in 8.2 when compiling bloodhound's test suite2021-03-30T11:44:01ZrefoldCompile-time regression in 8.2 when compiling bloodhound's test suiteGHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory.
How to reproduce:
```
$ gi...GHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory.
How to reproduce:
```
$ git clone -b ghc-8.2 https://github.com/23Skidoo/bloodhound.git
$ cd bloodhound
$ cabal new-build -w ghc-8.0.1 --enable-tests
$ cabal new-build -w ghc-8.2.1 --enable-tests
```
GHC version:
```
$ ghc-8.2.1 --version
The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505
```
These warnings (fixed in my `ghc-8.2` branch of `bloodhound`) may provide a clue to what's happening:
```
tests/V1/tests.hs:1876:17: warning: [-Wsimplifiable-class-constraints]
• The constraint ‘SOP.All SOP.SListI (SOP.GCode a)’
matches an instance declaration
instance forall k (f :: k -> Constraint) (xs :: [k]).
(Generics.SOP.Constraint.AllF f xs, SOP.SListI xs) =>
SOP.All f xs
-- Defined in ‘Generics.SOP.Constraint’
This makes type inference for inner bindings fragile;
either use MonoLocalBinds, or simplify it using the instance
• In the type signature:
sopArbitrary :: forall a.
(Generic a,
SOP.GTo a,
SOP.All SOP.SListI (SOP.GCode a),
SOP.All2 Arbitrary (SOP.GCode a)) =>
Gen a
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compile-time regression in 8.2 when compiling bloodhound's test suite","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory. \r\n\r\nHow to reproduce:\r\n\r\n{{{\r\n$ git clone -b ghc-8.2 https://github.com/23Skidoo/bloodhound.git\r\n$ cd bloodhound\r\n$ cabal new-build -w ghc-8.0.1 --enable-tests\r\n$ cabal new-build -w ghc-8.2.1 --enable-tests \r\n}}}\r\n\r\n\r\nGHC version:\r\n\r\n{{{\r\n$ ghc-8.2.1 --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505\r\n}}}\r\n\r\nThese warnings (fixed in my `ghc-8.2` branch of `bloodhound`) may provide a clue to what's happening:\r\n\r\n{{{\r\ntests/V1/tests.hs:1876:17: warning: [-Wsimplifiable-class-constraints]\r\n • The constraint ‘SOP.All SOP.SListI (SOP.GCode a)’\r\n matches an instance declaration\r\n instance forall k (f :: k -> Constraint) (xs :: [k]).\r\n (Generics.SOP.Constraint.AllF f xs, SOP.SListI xs) =>\r\n SOP.All f xs\r\n -- Defined in ‘Generics.SOP.Constraint’\r\n This makes type inference for inner bindings fragile;\r\n either use MonoLocalBinds, or simplify it using the instance\r\n • In the type signature:\r\n sopArbitrary :: forall a.\r\n (Generic a,\r\n SOP.GTo a,\r\n SOP.All SOP.SListI (SOP.GCode a),\r\n SOP.All2 Arbitrary (SOP.GCode a)) =>\r\n Gen a\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13743Colourise command output2019-07-07T18:20:19ZIcelandjackColourise command outputOur error messages are now colourful (#10073), can we do the same for the output of commands like `:info`?
`:info` has gotten bloated (I also think the context / instance head should be swapped, but that's another story), adding colour ...Our error messages are now colourful (#10073), can we do the same for the output of commands like `:info`?
`:info` has gotten bloated (I also think the context / instance head should be swapped, but that's another story), adding colour would make it easier to read
```html
<pre class="wiki">
>>> :i Int
data <span style="color: red;font-weight: bold">Int</span> = I# E.Int# -- Defined in ‘GHC.Types’</br>
instance <span style="font-weight: bold">Eq</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Classes’
instance <span style="font-weight: bold">Ord</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Classes’
instance <span style="font-weight: bold">Show</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Show’
instance <span style="font-weight: bold">Read</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Read’
instance <span style="font-weight: bold">Enum</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Enum’
instance <span style="font-weight: bold">Num</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Num’
instance <span style="font-weight: bold">Real</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Real’
instance [safe] <span style="font-weight: bold">NFData</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘Control.DeepSeq’
instance <span style="font-weight: bold">Data</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘Data.Data’
instance <span style="font-weight: bold">Bounded</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Enum’
instance <span style="font-weight: bold">O.Outputable</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘Outputable’
instance [safe] <span style="font-weight: bold">PrintfArg</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘Text.Printf’
instance <span style="font-weight: bold">Integral</span> <span style="color: red;font-weight: bold">Int</span> -- Defined in ‘GHC.Real’
</pre>
```https://gitlab.haskell.org/ghc/ghc/-/issues/13742Code using ConstraintKinds needs explicit kind signature with GHC 8.2.12023-03-31T13:27:24ZalbertovCode using ConstraintKinds needs explicit kind signature with GHC 8.2.1The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2.
Mentioned in this [ghc-dev thread](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014222.html).
Compiling the att...The attached module compiles without errors with GHC 8.0.1 but needs an explicit kind signature with GHC 8.2.1-rc2.
Mentioned in this [ghc-dev thread](https://mail.haskell.org/pipermail/ghc-devs/2017-May/014222.html).
Compiling the attached file fails gives the error:
```
[[1 of 1] Compiling CKBug ( CKBug.hs, interpreted )
CKBug.hs:33:4: error:
• Expected a type, but
‘(PropagIOConstraint l a,
Missing (PropagIOVector l) (PropagIONullable l a),
Elem (PropagIONullable l a) ~ a)’ has kind
‘Constraint’
• In the type ‘((PropagIOConstraint l a,
Missing (PropagIOVector l) (PropagIONullable l a),
Elem (PropagIONullable l a) ~ a))’
In the type declaration for ‘CanSerialize’
|
33 | (( PropagIOConstraint l a
| ^^^^^^^^^^^^^^^^^^^^^^^^...
CKBug.hs:42:4: error:
• Expected a constraint,
but ‘(CanSerialize l Double, CanSerialize l Int)’ has kind ‘*’
• In the type ‘(CanSerialize l Double, CanSerialize l Int)’
In the type declaration for ‘CanSerializePropagTypes’
|
42 | ( CanSerialize l Double
| ^^^^^^^^^^^^^^^^^^^^^^^...
```https://gitlab.haskell.org/ghc/ghc/-/issues/13741Newtype unwrapping causes GHC panic2019-07-07T18:20:20ZVaibhav SagarNewtype unwrapping causes GHC panicSome combination of newtypes and infix operators is causing GHCi to panic.
Steps to reproduce:
1. Open a fresh GHCi session.
1. Define `Cont`: `newtype Cont r a = Cont {(>>-) :: (a -> r) -> r}`
1. Define a `Functor` instance for `Cont`...Some combination of newtypes and infix operators is causing GHCi to panic.
Steps to reproduce:
1. Open a fresh GHCi session.
1. Define `Cont`: `newtype Cont r a = Cont {(>>-) :: (a -> r) -> r}`
1. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k`
1. Observe the following:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
get_op >>>-
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Discovered [here](https://www.reddit.com/r/haskell/comments/6clkgs/discovering_continuations_with_typed_holes/dhvluoq/).https://gitlab.haskell.org/ghc/ghc/-/issues/13740GHC panic with operator constructor of newtype2019-07-07T18:20:20ZcodebjeGHC panic with operator constructor of newtypeThe following code causes a GHC panic:
```
newtype Cont r a = Cont { (>>-) :: (a -> r) -> r }
x = \a b c -> c >>- a . b
```
This slight modification, however, is fine:
```
newtype Cont r a = Cont { (>>-) :: (a -> r) -> r }
x = \a b c ...The following code causes a GHC panic:
```
newtype Cont r a = Cont { (>>-) :: (a -> r) -> r }
x = \a b c -> c >>- a . b
```
This slight modification, however, is fine:
```
newtype Cont r a = Cont { (>>-) :: (a -> r) -> r }
x = \a b c -> c >>- (a . b)
```
The presence or absence of a type signature for `x` makes no difference. Compiling with "-v" suggests the panic occurs during type checking:
```
Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3
Using binary package database: /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/package.cache
Using binary package database: /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache
Using binary package database: /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache
loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d
loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb
loading package database /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb
wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
wired-in package base mapped to base-4.9.1.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.11.1.0
wired-in package ghc mapped to ghc-8.0.2
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d
loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb
loading package database /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb
wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
wired-in package base mapped to base-4.9.1.0
wired-in package rts mapped to rts-1.0
wired-in package template-haskell mapped to template-haskell-2.11.1.0
wired-in package ghc mapped to ghc-8.0.2
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *panic.hs
!!! Chasing dependencies: finished in 0.57 milliseconds, allocated 0.224 megabytes
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2017-05-22 07:07:41 UTC
ms_mod = Main,
ms_textual_imps = [(Nothing, Prelude)]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file panic.hs
*** Checking old interface for Main:
[1 of 1] Compiling Main ( panic.hs, panic.o )
*** Parser [Main]:
!!! Parser [Main]: finished in 0.38 milliseconds, allocated 0.209 megabytes
*** Renamer/typechecker [Main]:
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-apple-darwin):
get_op >>-
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic with operator constructor of newtype","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a GHC panic:\r\n\r\n{{{\r\nnewtype Cont r a = Cont { (>>-) :: (a -> r) -> r }\r\nx = \\a b c -> c >>- a . b\r\n}}}\r\n\r\nThis slight modification, however, is fine:\r\n\r\n{{{\r\nnewtype Cont r a = Cont { (>>-) :: (a -> r) -> r }\r\nx = \\a b c -> c >>- (a . b)\r\n}}}\r\n\r\nThe presence or absence of a type signature for `x` makes no difference. Compiling with \"-v\" suggests the panic occurs during type checking:\r\n\r\n{{{\r\nGlasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3\r\nUsing binary package database: /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/package.cache\r\nUsing binary package database: /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache\r\nUsing binary package database: /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache\r\nloading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d\r\nloading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb\r\nloading package database /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb\r\nwired-in package ghc-prim mapped to ghc-prim-0.5.0.0\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.1\r\nwired-in package base mapped to base-4.9.1.0\r\nwired-in package rts mapped to rts\r\nwired-in package template-haskell mapped to template-haskell-2.11.1.0\r\nwired-in package ghc mapped to ghc-8.0.2\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags:\r\nloading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d\r\nloading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb\r\nloading package database /Users/bje/.stack/global/.stack-work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb\r\nwired-in package ghc-prim mapped to ghc-prim-0.5.0.0\r\nwired-in package integer-gmp mapped to integer-gmp-1.0.0.1\r\nwired-in package base mapped to base-4.9.1.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.11.1.0\r\nwired-in package ghc mapped to ghc-8.0.2\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *panic.hs\r\n!!! Chasing dependencies: finished in 0.57 milliseconds, allocated 0.224 megabytes\r\nStable obj: []\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2017-05-22 07:07:41 UTC\r\n ms_mod = Main,\r\n ms_textual_imps = [(Nothing, Prelude)]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting:\r\ncompile: input file panic.hs\r\n*** Checking old interface for Main:\r\n[1 of 1] Compiling Main ( panic.hs, panic.o )\r\n*** Parser [Main]:\r\n!!! Parser [Main]: finished in 0.38 milliseconds, allocated 0.209 megabytes\r\n*** Renamer/typechecker [Main]:\r\n*** Deleting temp files:\r\nDeleting:\r\n*** Deleting temp dirs:\r\nDeleting:\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-apple-darwin):\r\n\tget_op >>-\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13739very slow linking of executables with ld.bfd < 2.272019-07-07T18:20:20ZDouglas Wilsondouglas@well-typed.comvery slow linking of executables with ld.bfd < 2.27While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed.
I don't have a minimal test case.
Testing on cabal head source tree
```
cabal --version
>cabal-install version 2.1.0.0...While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed.
I don't have a minimal test case.
Testing on cabal head source tree
```
cabal --version
>cabal-install version 2.1.0.0
>compiled using version 2.1.0.0 of the Cabal library
cabal new-configure --enable-profiling --enable-newer --with-ghc=/opt/ghc-8.2.1/bin/ghc
cabal build cabal-install
# hit Ctrl-C during linking
time cabal build cabal-install
```
gives
real 1m54.833s
user 1m52.936s
sys 0m1.620s
doing the same with 8.0.2 links in less than a second
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Very slow linking of profiled executables","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While building profiled executables with 8.2.1rc2 I've noticed the link times seem to have significantly regressed.\r\n\r\nI don't have a minimal test case.\r\n\r\nTesting on cabal head source tree\r\n{{{\r\ncabal --version\r\n>cabal-install version 2.1.0.0\r\n>compiled using version 2.1.0.0 of the Cabal library \r\ncabal new-configure --enable-profiling --enable-newer --with-ghc=/opt/ghc-8.2.1/bin/ghc\r\ncabal build cabal-install\r\n\r\n# hit Ctrl-C during linking\r\ntime cabal build cabal-install\r\n}}}\r\n\r\ngives\r\nreal\t1m54.833s\r\nuser\t1m52.936s\r\nsys\t0m1.620s\r\n\r\ndoing the same with 8.0.2 links in less than a second\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13738TypeApplications-related GHC internal error2019-07-07T18:20:21ZRyan ScottTypeApplications-related GHC internal errorThis is reproducible with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Coerce
class...This is reproducible with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Coerce
class MFunctor t where
hoist :: (Monad m) => (forall a . m a -> n a) -> t m b -> t n b
newtype TaggedTrans tag trans m a = TaggedTrans (trans m a)
instance MFunctor trans => MFunctor (TaggedTrans tag trans) where
hoist = coerce
@(forall (m :: * -> *)
(n :: * -> *)
(b :: k).
Monad m =>
(forall (a :: *).
m a -> n a)
-> trans m b -> trans n b)
@(forall (m :: * -> *)
(n :: * -> *)
(b :: k).
Monad m =>
(forall (a :: *).
m a -> n a)
-> TaggedTrans tag trans m b
-> TaggedTrans tag trans n b)
hoist
```
```
GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:18:26: error:
• GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a1tR :-> Type variable ‘m’ = m,
a1tS :-> Type variable ‘n’ = n, a1tT :-> Type variable ‘b’ = b,
a1tV :-> Type variable ‘trans’ = trans,
a1tW :-> Type variable ‘tag’ = tag, a1tX :-> Type variable ‘m’ = m,
a1tY :-> Type variable ‘n’ = n, a1KE :-> Type variable ‘k’ = k,
a1KF :-> Type variable ‘k’ = k]
• In the kind ‘k’
In the type ‘(forall (m :: * -> *) (n :: * -> *) (b :: k).
Monad m =>
(forall (a :: *). m a -> n a) -> trans m b -> trans n b)’
In the expression:
coerce
@(forall (m :: * -> *) (n :: * -> *) (b :: k).
Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b)
@(forall (m :: * -> *) (n :: * -> *) (b :: k).
Monad m =>
(forall (a :: *). m a -> n a)
-> TaggedTrans tag trans m b -> TaggedTrans tag trans n b)
hoist
|
18 | (b :: k).
| ^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"TypeApplications-related GHC internal error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is reproducible with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeApplications #-}\r\nmodule Bug where\r\n\r\nimport Data.Coerce\r\n\r\nclass MFunctor t where\r\n hoist :: (Monad m) => (forall a . m a -> n a) -> t m b -> t n b\r\n\r\nnewtype TaggedTrans tag trans m a = TaggedTrans (trans m a)\r\n\r\ninstance MFunctor trans => MFunctor (TaggedTrans tag trans) where\r\n hoist = coerce\r\n @(forall (m :: * -> *)\r\n (n :: * -> *)\r\n (b :: k).\r\n Monad m =>\r\n (forall (a :: *).\r\n m a -> n a)\r\n -> trans m b -> trans n b)\r\n @(forall (m :: * -> *)\r\n (n :: * -> *)\r\n (b :: k).\r\n Monad m =>\r\n (forall (a :: *).\r\n m a -> n a)\r\n -> TaggedTrans tag trans m b\r\n -> TaggedTrans tag trans n b)\r\n hoist\r\n}}}\r\n\r\n{{{\r\nGHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:18:26: error:\r\n • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [a1tR :-> Type variable ‘m’ = m,\r\n a1tS :-> Type variable ‘n’ = n, a1tT :-> Type variable ‘b’ = b,\r\n a1tV :-> Type variable ‘trans’ = trans,\r\n a1tW :-> Type variable ‘tag’ = tag, a1tX :-> Type variable ‘m’ = m,\r\n a1tY :-> Type variable ‘n’ = n, a1KE :-> Type variable ‘k’ = k,\r\n a1KF :-> Type variable ‘k’ = k]\r\n • In the kind ‘k’\r\n In the type ‘(forall (m :: * -> *) (n :: * -> *) (b :: k).\r\n Monad m =>\r\n (forall (a :: *). m a -> n a) -> trans m b -> trans n b)’\r\n In the expression:\r\n coerce\r\n @(forall (m :: * -> *) (n :: * -> *) (b :: k).\r\n Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b)\r\n @(forall (m :: * -> *) (n :: * -> *) (b :: k).\r\n Monad m =>\r\n (forall (a :: *). m a -> n a)\r\n -> TaggedTrans tag trans m b -> TaggedTrans tag trans n b)\r\n hoist\r\n |\r\n18 | (b :: k).\r\n | ^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/13737Have typechecking produce HsType Typechecked instead of Type2019-07-07T18:20:21ZRichard Eisenbergrae@richarde.devHave typechecking produce HsType Typechecked instead of TypeRight now, there is an unfortunate lack of parallelism between expressions and types. When an expression is typechecked, it is transformed from `HsExpr Name` to `HsExpr TcId`. When a type is typechecked, it is transformed from `HsType Na...Right now, there is an unfortunate lack of parallelism between expressions and types. When an expression is typechecked, it is transformed from `HsExpr Name` to `HsExpr TcId`. When a type is typechecked, it is transformed from `HsType Name` to `Type`.
This arrangement has served us well enough for some time, but it has several drawbacks:
- Validity checking is really meant to be done over user-written syntax. This bit when implementing #11715, when validity checking couldn't tell the difference between `Int => Int` (bad) and `Int -> Int` (good). There may be other opportunities for simplification by having the user-written syntax available.
- The situation above extends to type-level declarations. That is, an `HsDecl Name` for a datatype goes straight to a `TyCon`, instead of to a typechecked form of source. This is problematic because it means that all of typechecking must happen *twice*. The first is to figure out the kind of the `TyCon` (the is the `kc` pass); the actual result is discarded. Then, typechecking is repeated with the known `TyCon` kind; this pass should always succeed and is more like desugaring than typechecking. But all the constraint generation and solving happens again.
- This second pass uses knot-tied `TyCon`s, leading to `Note [Type-checking inside the knot]` in !TsHsType.
If we have a form of types in `HsSyn` that occurs *after* typechecking, we can fix the above problems, leading both to a runtime improvement (no double-checking type declarations) and code simplification (no more typechecking in the knot).
This is a significant refactor, and it should proceed in at least two stages: one for just plain types, and one for type declarations.
Note that we can't produce `HsType TcTyVar`, because `Name`s in `HsType Name` sometimes become `TyCon`s and sometimes become `TcTyVar`s. We really need `HsType (TyCon + TcTyVar)` or some such. But perhaps it would be better to wait until after refactoring with respect to the Trees That Grow paper.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Have typechecking produce HsType Typechecked instead of Type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Right now, there is an unfortunate lack of parallelism between expressions and types. When an expression is typechecked, it is transformed from `HsExpr Name` to `HsExpr TcId`. When a type is typechecked, it is transformed from `HsType Name` to `Type`.\r\n\r\nThis arrangement has served us well enough for some time, but it has several drawbacks:\r\n - Validity checking is really meant to be done over user-written syntax. This bit when implementing #11715, when validity checking couldn't tell the difference between `Int => Int` (bad) and `Int -> Int` (good). There may be other opportunities for simplification by having the user-written syntax available.\r\n - The situation above extends to type-level declarations. That is, an `HsDecl Name` for a datatype goes straight to a `TyCon`, instead of to a typechecked form of source. This is problematic because it means that all of typechecking must happen ''twice''. The first is to figure out the kind of the `TyCon` (the is the `kc` pass); the actual result is discarded. Then, typechecking is repeated with the known `TyCon` kind; this pass should always succeed and is more like desugaring than typechecking. But all the constraint generation and solving happens again.\r\n - This second pass uses knot-tied `TyCon`s, leading to `Note [Type-checking inside the knot]` in !TsHsType.\r\n\r\nIf we have a form of types in `HsSyn` that occurs ''after'' typechecking, we can fix the above problems, leading both to a runtime improvement (no double-checking type declarations) and code simplification (no more typechecking in the knot).\r\n\r\nThis is a significant refactor, and it should proceed in at least two stages: one for just plain types, and one for type declarations.\r\n\r\nNote that we can't produce `HsType TcTyVar`, because `Name`s in `HsType Name` sometimes become `TyCon`s and sometimes become `TcTyVar`s. We really need `HsType (TyCon + TcTyVar)` or some such. But perhaps it would be better to wait until after refactoring with respect to the Trees That Grow paper.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13736GHC panic with DataKinds and TypeOperators2019-07-07T18:20:22ZturionGHC panic with DataKinds and TypeOperatorsThe following program causes a GHC panic:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE KindSignatures #-}
import GHC.TypeLits
data Proxy (n :: Nat) = Proxy
data Foo a = Foo a
foo :: Foo (Proxy (2 * 2))...The following program causes a GHC panic:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE KindSignatures #-}
import GHC.TypeLits
data Proxy (n :: Nat) = Proxy
data Foo a = Foo a
foo :: Foo (Proxy (2 * 2))
foo = Foo _
```
The error message is:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
initTc: unsolved constraints
WC {wc_insol = [W] __aBJ :: t_aBI[tau:1] (CHoleCan: _)}
```https://gitlab.haskell.org/ghc/ghc/-/issues/13735RankNTypes don't work with PatternSynonyms2019-07-07T18:20:22ZIcelandjackRankNTypes don't work with PatternSynonyms```hs
data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a)
| Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a)
| Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a)
| App (PLambda a) (PLambd...```hs
data PLambda a = Var a | Int Int | Bool Bool | If (PLambda a) (PLambda a) (PLambda a)
| Add (PLambda a) (PLambda a) | Mult (PLambda a) (PLambda a)
| Eq (PLambda a) (PLambda a) | Lam (a -> PLambda a)
| App (PLambda a) (PLambda a)
newtype Lam = L { un :: forall a. PLambda a }
```
```hs
llam :: (forall a. a -> PLambda a) -> Lam
llam f = L (Lam f)
```
works fine, but does not with pattern synonyms:
```hs
-- $ ghci -ignore-dot-ghci tirr.hs
-- GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help
-- [1 of 1] Compiling Main ( tirr.hs, interpreted )
--
-- tirr.hs:20:25: error:
-- • Couldn't match expected type ‘forall a. a -> PLambda a’
-- with actual type ‘a0 -> PLambda a0’
-- • In the declaration for pattern synonym ‘LLam’
-- • Relevant bindings include
-- a :: a0 -> PLambda a0 (bound at tirr.hs:20:25)
-- |
-- 20 | pattern LLam a = L (Lam a)
-- | ^
-- Failed, modules loaded: none.
-- Prelude>
pattern LLam :: (forall a. a -> PLambda a) -> Lam
pattern LLam a = L (Lam a)
```https://gitlab.haskell.org/ghc/ghc/-/issues/13734Code requires ScopedTypeVariables, possibly erroneously2019-07-07T18:20:22ZIcelandjackCode requires ScopedTypeVariables, possibly erroneouslyThis doesn't work without `ScopedTypeVariables`, but shouldn't it? (on `8.0.1`, 8.2.0.20170507\`)
```hs
{-# Language ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes, InstanceSigs #-}
class Sized f where
size :: Int
instan...This doesn't work without `ScopedTypeVariables`, but shouldn't it? (on `8.0.1`, 8.2.0.20170507\`)
```hs
{-# Language ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes, InstanceSigs #-}
class Sized f where
size :: Int
instance Sized Int where
size :: Int
size = 42
instance (Sized a, Sized b) => Sized (a, b) where
size :: Int
size = size @a + size @b
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Code requires ScopedTypeVariables, possibly erroneously","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This doesn't work without `ScopedTypeVariables`, but shouldn't it? (on `8.0.1`, 8.2.0.20170507`)\r\n\r\n{{{#!hs\r\n{-# Language ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes, InstanceSigs #-}\r\n\r\nclass Sized f where\r\n size :: Int\r\n\r\ninstance Sized Int where\r\n size :: Int\r\n size = 42\r\n\r\ninstance (Sized a, Sized b) => Sized (a, b) where\r\n size :: Int\r\n size = size @a + size @b\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13733Simplify constraints on RULES LHS2019-07-07T18:20:22ZJoachim Breitnermail@joachim-breitner.deSimplify constraints on RULES LHSTL;DR: Rewrite rules should be able to match instance methods.
I know that the interaction of rewrite rules and classes/instances/methods is unsatisfying, and probably will be for the forseeable future given the current design. But we m...TL;DR: Rewrite rules should be able to match instance methods.
I know that the interaction of rewrite rules and classes/instances/methods is unsatisfying, and probably will be for the forseeable future given the current design. But we might still improve little bits.
Consider this code:
```
{-# RULES
"[Integer] Eq Refl" forall (xs :: [Integer]). xs == xs = True
#-}
```
This is the best I can to express the intention of “dear compile, this is a rule for the equality on lists if the elements are integers”. But what I get is
```
"[Integer] Eq Refl" [ALWAYS]
forall ($dEq_a1Jv :: Eq [Integer]) (xs_a1Hd :: [Integer]).
== @ [Integer] $dEq_a1Jv xs_a1Hd xs_a1Hd
= GHC.Types.True
```
which is a rule about the method `==` applied to *any* evidence of equality about lists. This works in the most obvious cases, such as
```
alwaysTrue :: [Integer]-> Bool
alwaysTrue xs = xs == xs
```
but it does not fire with
```
delayedId :: a -> a
delayedId x = x
{-# INLINE [0] delayedId #-}
alwaysTrue :: [Integer]-> Bool
alwaysTrue xs = xs == delayedId xs
{-# NOINLINE alwaysTrue #-}
```
The reason is that directly after the simplifier, in the former case, the Core looks like this
```
$dEq_a1HH :: Eq [Integer]
[LclId, Str=DmdType]
$dEq_a1HH = GHC.Classes.$fEq[] @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger
alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool
[LclIdX, Str=DmdType]
alwaysTrue = \ (xs_aGT :: [Integer]) -> == @ [Integer] $dEq_a1HH xs_aGT xs_aGT
```
which matches the rule, but in the latter case, by the time the `delayedId` is out of the way, we have
```
alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool
[LclIdX, Arity=1, Str=DmdType <S,U>]
alwaysTrue =
\ (xs_aGT :: [Integer]) ->
GHC.Classes.$fEq[]_$c==
@ Integer
integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger
xs_aGT
xs_aGT
```
One possible way forward would be to simplify the wanted constraints on the LHS of the rule using the instances in scope:
```
"[Integer] Eq Refl" [ALWAYS]
forall (xs_a1Hd :: [Integer]).
GHC.Classes.$fEq[]_$c==
@ Integer
integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger
xs_a1Hd
xs_a1Hd
= True
```
This might be tricky, of course, as this requires not only help from the type checker, but also some careful tuned simplification of the LHS afterwards (e.g. unfold dictionary accessors)).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simplify constraints on RULES LHS","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"TL;DR: Rewrite rules should be able to match instance methods.\r\n\r\nI know that the interaction of rewrite rules and classes/instances/methods is unsatisfying, and probably will be for the forseeable future given the current design. But we might still improve little bits.\r\n\r\nConsider this code:\r\n\r\n{{{\r\n{-# RULES\r\n \"[Integer] Eq Refl\" forall (xs :: [Integer]). xs == xs = True\r\n#-}\r\n}}}\r\n\r\nThis is the best I can to express the intention of “dear compile, this is a rule for the equality on lists if the elements are integers”. But what I get is\r\n\r\n{{{\r\n\"[Integer] Eq Refl\" [ALWAYS]\r\n forall ($dEq_a1Jv :: Eq [Integer]) (xs_a1Hd :: [Integer]).\r\n == @ [Integer] $dEq_a1Jv xs_a1Hd xs_a1Hd\r\n = GHC.Types.True\r\n}}}\r\n\r\nwhich is a rule about the method `==` applied to ''any'' evidence of equality about lists. This works in the most obvious cases, such as\r\n\r\n{{{\r\nalwaysTrue :: [Integer]-> Bool\r\nalwaysTrue xs = xs == xs\r\n}}} \r\n\r\nbut it does not fire with\r\n\r\n{{{\r\ndelayedId :: a -> a\r\ndelayedId x = x\r\n{-# INLINE [0] delayedId #-}\r\n\r\nalwaysTrue :: [Integer]-> Bool\r\nalwaysTrue xs = xs == delayedId xs\r\n{-# NOINLINE alwaysTrue #-}\r\n}}}\r\n\r\nThe reason is that directly after the simplifier, in the former case, the Core looks like this\r\n\r\n{{{\r\n$dEq_a1HH :: Eq [Integer]\r\n[LclId, Str=DmdType]\r\n$dEq_a1HH = GHC.Classes.$fEq[] @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger\r\n\r\nalwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool\r\n[LclIdX, Str=DmdType]\r\nalwaysTrue = \\ (xs_aGT :: [Integer]) -> == @ [Integer] $dEq_a1HH xs_aGT xs_aGT\r\n}}}\r\n\r\nwhich matches the rule, but in the latter case, by the time the `delayedId` is out of the way, we have\r\n\r\n{{{\r\nalwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool\r\n[LclIdX, Arity=1, Str=DmdType <S,U>]\r\nalwaysTrue =\r\n \\ (xs_aGT :: [Integer]) ->\r\n GHC.Classes.$fEq[]_$c==\r\n @ Integer\r\n integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger\r\n xs_aGT\r\n xs_aGT\r\n}}}\r\n\r\nOne possible way forward would be to simplify the wanted constraints on the LHS of the rule using the instances in scope:\r\n{{{\r\n\"[Integer] Eq Refl\" [ALWAYS]\r\n forall (xs_a1Hd :: [Integer]).\r\n GHC.Classes.$fEq[]_$c==\r\n @ Integer\r\n integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger\r\n xs_a1Hd\r\n xs_a1Hd\r\n = True\r\n}}}\r\n\r\nThis might be tricky, of course, as this requires not only help from the type checker, but also some careful tuned simplification of the LHS afterwards (e.g. unfold dictionary accessors)).","type_of_failure":"OtherFailure","blocking":[]} -->