GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:38Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15870No skolem info panic2019-07-07T18:02:38Zsheafsam.derbyshire@gmail.comNo skolem info panicI've been toying with some type-level lenses and running into some issues with kind unification, when I ran into a panic:
```
bug.hs:30:34: error:ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.6.2 for x86_64-unknown-mingw3...I've been toying with some type-level lenses and running into some issues with kind unification, when I ran into a panic:
```
bug.hs:30:34: error:ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.6.2 for x86_64-unknown-mingw32):
No skolem info:
[k_a1Hgj]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\utils\Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler\\typecheck\\TcErrors.hs:2891:5 in ghc:TcErrors
```
Here's a boiled down version (with a bit of extraneous code left in for context, as it's so short):
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
data Optic a where
--Index :: Nat -> Optic a
--Name :: Symbol -> Optic a
(:.:) :: Optic a -> Optic b -> Optic a -- composition
class Gettable a (optic :: Optic a) where
type Get a (optic :: Optic a)
{-
some basic instances, e.g.
instance Gettable (a,b) (Index 0) where
type Get (a,b) (Index 0) = a
...
-}
instance forall a b (g1 :: Optic a) (g2 :: Optic b).
( Gettable a g1
, b ~ Get a g1
, Gettable b g2
) => Gettable a (g1 :.: g2) where
type Get a (g1 :.: g2) = Get a g2
```
The program I am actually trying to write has the instance declaration changed to
```hs
instance forall a b (g1 :: Optic a) (g2 :: Optic (Get a g1)).
( Gettable a g1
, b ~ Get a g1
, Gettable b g2
) => Gettable a (g1 :.: g2) where
type Get a (g1 :.: g2) = Get (Get a g1) g2
```
but GHC complains that it can't match kinds:
```
• Expected kind ‘Optic b’, but ‘g2’ has kind ‘Optic (Get a g1)’
• In the second argument of ‘Gettable’, namely ‘g2’
In the instance declaration for ‘Gettable a (g1 :.: g2)’
|
20 | , Gettable b g2
|
```
I don't know if there is a way around that, and I'd be interested to hear any advice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.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":"No skolem info panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been toying with some type-level lenses and running into some issues with kind unification, when I ran into a panic:\r\n\r\n\r\n{{{\r\nbug.hs:30:34: error:ghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 8.6.2 for x86_64-unknown-mingw32):\r\n No skolem info:\r\n [k_a1Hgj]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler\\\\typecheck\\\\TcErrors.hs:2891:5 in ghc:TcErrors\r\n}}}\r\n\r\nHere's a boiled down version (with a bit of extraneous code left in for context, as it's so short):\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n\r\ndata Optic a where\r\n --Index :: Nat -> Optic a\r\n --Name :: Symbol -> Optic a\r\n (:.:) :: Optic a -> Optic b -> Optic a -- composition\r\n\r\nclass Gettable a (optic :: Optic a) where\r\n type Get a (optic :: Optic a)\r\n\r\n{-\r\nsome basic instances, e.g.\r\ninstance Gettable (a,b) (Index 0) where\r\n type Get (a,b) (Index 0) = a\r\n...\r\n-}\r\n\r\ninstance forall a b (g1 :: Optic a) (g2 :: Optic b).\r\n ( Gettable a g1\r\n , b ~ Get a g1\r\n , Gettable b g2\r\n ) => Gettable a (g1 :.: g2) where\r\n type Get a (g1 :.: g2) = Get a g2\r\n}}}\r\n\r\nThe program I am actually trying to write has the instance declaration changed to\r\n{{{#!hs\r\ninstance forall a b (g1 :: Optic a) (g2 :: Optic (Get a g1)).\r\n ( Gettable a g1\r\n , b ~ Get a g1\r\n , Gettable b g2\r\n ) => Gettable a (g1 :.: g2) where\r\n type Get a (g1 :.: g2) = Get (Get a g1) g2\r\n}}}\r\nbut GHC complains that it can't match kinds:\r\n\r\n{{{\r\n • Expected kind ‘Optic b’, but ‘g2’ has kind ‘Optic (Get a g1)’\r\n • In the second argument of ‘Gettable’, namely ‘g2’\r\n In the instance declaration for ‘Gettable a (g1 :.: g2)’\r\n |\r\n20 | , Gettable b g2\r\n |\r\n}}}\r\nI don't know if there is a way around that, and I'd be interested to hear any advice.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15875Detection of ranlib by binary distribution is broken2019-07-07T18:02:37ZBen GamariDetection of ranlib by binary distribution is brokenThe `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.
<details><summary>Trac metadata</summary>
| Trac ...The `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Detection of ranlib by binary distribution is broken","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15879Make UniqDSet a newtype2019-07-07T18:02:36ZSebastian GrafMake UniqDSet a newtypeFor the same reasons as in #13114 and [D3146](https://phabricator.haskell.org/D3146) we should make `UniqDSet` a newtype of `UniqDFM`.
I wonder if we can also have a prettier `Outputable` instance this way.
<details><summary>Trac metad...For the same reasons as in #13114 and [D3146](https://phabricator.haskell.org/D3146) we should make `UniqDSet` a newtype of `UniqDFM`.
I wonder if we can also have a prettier `Outputable` instance this way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make UniqDSet a newtype","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"For the same reasons as in #13114 and Phab:D3146 we should make `UniqDSet` a newtype of `UniqDFM`.\r\n\r\nI wonder if we can also have a prettier `Outputable` instance this way.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15881GHC Panic: data A n (a :: n) :: a -> Type2019-07-07T18:02:35ZIcelandjackGHC Panic: data A n (a :: n) :: a -> Type```hs
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import Data.Kind
data A n (a :: n) :: a -> Type
```
causes a panic on 8.7.20181017
```
$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_b...```hs
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import Data.Kind
data A n (a :: n) :: a -> Type
```
causes a panic on 8.7.20181017
```
$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs
GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 665_bug.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181017 for x86_64-unknown-linux):
ASSERT failed!
Type-correct unfilled coercion hole {co_a1xR}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
and an assertion failure in 8.7.20181029
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 665_bug.hs, interpreted )
*** Exception: ASSERT failed! file compiler/types/TyCon.hs, line 420
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC Panic: data A n (a :: n) :: a -> Type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language KindSignatures #-}\r\n{-# Language PolyKinds #-}\r\n\r\nimport Data.Kind\r\n\r\ndata A n (a :: n) :: a -> Type\r\n}}}\r\n\r\ncauses a panic on 8.7.20181017\r\n\r\n{{{\r\n$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs\r\nGHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 665_bug.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181017 for x86_64-unknown-linux):\r\n\tASSERT failed!\r\n Type-correct unfilled coercion hole {co_a1xR}\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable\r\n assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}\r\n\r\nand an assertion failure in 8.7.20181029\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 665_bug.hs, interpreted )\r\n*** Exception: ASSERT failed! file compiler/types/TyCon.hs, line 420\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15886Spurious warning about incomplete pattern with PatternSynonyms2019-07-07T18:02:34ZselingerSpurious warning about incomplete pattern with PatternSynonyms```hs
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE PatternSynonyms #-}
module Test where
f :: Int -> Bool
f (id -> a) = True
pattern X a <- (id -> a)
g :: Int -> Bool
g (X a) = True
```
When compiling with -Wincomplete-patterns, this ...```hs
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE PatternSynonyms #-}
module Test where
f :: Int -> Bool
f (id -> a) = True
pattern X a <- (id -> a)
g :: Int -> Bool
g (X a) = True
```
When compiling with -Wincomplete-patterns, this code produces an (incorrect) warning for `g`, but not for `f`. The only difference is that `g` uses a pattern synonym.
```
K.hs:12:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘g’: Patterns not matched: _
|
12 | g (X a) = True
| ^^^^^^^^^^^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Spurious warning about incomplete pattern with PatternSynonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE ViewPatterns #-}\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\nmodule Test where\r\n\r\nf :: Int -> Bool\r\nf (id -> a) = True\r\n\r\npattern X a <- (id -> a)\r\n\r\ng :: Int -> Bool\r\ng (X a) = True\r\n}}}\r\n\r\nWhen compiling with -Wincomplete-patterns, this code produces an (incorrect) warning for `g`, but not for `f`. The only difference is that `g` uses a pattern synonym.\r\n\r\n{{{\r\nK.hs:12:1: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘g’: Patterns not matched: _\r\n |\r\n12 | g (X a) = True\r\n | ^^^^^^^^^^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15892Segmentation fault with ByteString2019-07-07T18:02:33Ztakano-akioSegmentation fault with ByteStringThe attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.
To reproduce:
```
ghc segfault.hs
```
then,
```
./segfault >/dev/...The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.
To reproduce:
```
ghc segfault.hs
```
then,
```
./segfault >/dev/null
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault with ByteString and -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.\r\n\r\nTo reproduce:\r\n\r\n{{{\r\nghc segfault.hs\r\n}}}\r\n\r\nthen,\r\n\r\n{{{\r\n./segfault >/dev/null\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15894Cannot find symbol during interactive linking using new-repl on Windows2019-07-07T18:02:33ZYellPikaCannot find symbol during interactive linking using new-repl on WindowsOriginally from https://github.com/haskell/cabal/issues/5683.
I get the following error on Windows 10:
```
> cabal new-repl --build-depends=ieee754
... GHCi loads ...
Prelude> import Numeric.IEEE
Prelude Numeric.IEEE> infinity
ghc.ex...Originally from https://github.com/haskell/cabal/issues/5683.
I get the following error on Windows 10:
```
> cabal new-repl --build-depends=ieee754
... GHCi loads ...
Prelude> import Numeric.IEEE
Prelude Numeric.IEEE> infinity
ghc.exe: | C:\Users\Anthony\AppData\Roaming\cabal\store\ghc-8.6.2\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\lib\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign'
ghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above.
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
```
This occurs with both cabal-install 2.4.0.0 and HEAD. This does not occur if I install ieee754 into a sandbox and use `cabal repl`. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Cannot find symbol during interactive linking using new-repl on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":["Phyx-"],"type":"Bug","description":"Originally from https://github.com/haskell/cabal/issues/5683.\r\n\r\nI get the following error on Windows 10:\r\n{{{\r\n> cabal new-repl --build-depends=ieee754\r\n\r\n... GHCi loads ...\r\n\r\nPrelude> import Numeric.IEEE\r\nPrelude Numeric.IEEE> infinity\r\nghc.exe: | C:\\Users\\Anthony\\AppData\\Roaming\\cabal\\store\\ghc-8.6.2\\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\\lib\\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign'\r\nghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above.\r\n\r\n\r\nByteCodeLink.lookupCE\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n}}}\r\n\r\nThis occurs with both cabal-install 2.4.0.0 and HEAD. This does not occur if I install ieee754 into a sandbox and use `cabal repl`. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15898Promoted type constructors don't print right in HsType2019-07-07T18:02:32ZSimon Peyton JonesPromoted type constructors don't print right in HsTypeConsider this
```
ghci> import Data.Proxy
ghci> undefined :: '() -> Int
<interactive>:11:14: error:
• Expected a type, but ‘ '()’ has kind ‘()’
• In an expression type signature: '() -> Int
```
What is that strange space doin...Consider this
```
ghci> import Data.Proxy
ghci> undefined :: '() -> Int
<interactive>:11:14: error:
• Expected a type, but ‘ '()’ has kind ‘()’
• In an expression type signature: '() -> Int
```
What is that strange space doing before the `'()`?
Similarly
```
undefined :: Proxy '() Int
<interactive>:12:14: error:
• Expected kind ‘* -> *’, but ‘Proxy '()’ has kind ‘*’
• In an expression type signature: Proxy '() Int
```
Again, the strange space.
It comes from the `HsType` pretty printer, which is worried
about printing the type
```
'['K]
```
That is, a promoted list with one element `K`. The trouble is that looks
like a character literal `'['`.
So we add an extra space, thus `'[ 'K]`. ''But we add it before every
promoded data constructor!" Hence the spurious spaces.
In `IfaceType` exactly the same thing happens, but we are more clever,
and only print the leading space if the promoted data con immediately
follows `'[` or `'(`. We should do the same thing for `HsType`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Promoted type constructors don't print right in HsType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this\r\n{{{\r\nghci> import Data.Proxy\r\nghci> undefined :: '() -> Int\r\n\r\n<interactive>:11:14: error:\r\n • Expected a type, but ‘ '()’ has kind ‘()’\r\n • In an expression type signature: '() -> Int\r\n}}}\r\nWhat is that strange space doing before the `'()`?\r\n\r\nSimilarly\r\n{{{\r\nundefined :: Proxy '() Int\r\n\r\n<interactive>:12:14: error:\r\n • Expected kind ‘* -> *’, but ‘Proxy '()’ has kind ‘*’\r\n • In an expression type signature: Proxy '() Int\r\n}}}\r\nAgain, the strange space.\r\n\r\nIt comes from the `HsType` pretty printer, which is worried\r\nabout printing the type\r\n{{{\r\n '['K]\r\n}}}\r\nThat is, a promoted list with one element `K`. The trouble is that looks\r\nlike a character literal `'['`.\r\n\r\nSo we add an extra space, thus `'[ 'K]`. ''But we add it before every\r\npromoded data constructor!\" Hence the spurious spaces.\r\n\r\nIn `IfaceType` exactly the same thing happens, but we are more clever,\r\nand only print the leading space if the promoted data con immediately\r\nfollows `'[` or `'(`. We should do the same thing for `HsType`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15906Stable name allocation causes heap corruption when GC is triggered in the primop2019-07-07T18:02:30ZÖmer Sinan AğacanStable name allocation causes heap corruption when GC is triggered in the primopThe error is originally reported in #15241, and is caught by the test `memo001`
when run with `-debug` (which only happens in sanity way currently).
Here's the problem. mkStableName\# is defined like this:
```
stg_makeStableNamezh ( P_...The error is originally reported in #15241, and is caught by the test `memo001`
when run with `-debug` (which only happens in sanity way currently).
Here's the problem. mkStableName\# is defined like this:
```
stg_makeStableNamezh ( P_ obj )
{
W_ index, sn_obj;
(index) = ccall lookupStableName(obj "ptr");
/* Is there already a StableName for this heap object?
* stable_name_table is a pointer to an array of snEntry structs.
*/
if ( snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) == NULL ) {
ALLOC_PRIM (SIZEOF_StgStableName); <------------ PROBLEM HERE ----------
sn_obj = Hp - SIZEOF_StgStableName + WDS(1);
SET_HDR(sn_obj, stg_STABLE_NAME_info, CCCS);
StgStableName_sn(sn_obj) = index;
snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) = sn_obj;
} else {
sn_obj = snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry);
}
return (sn_obj);
}
```
There's a problem in the annotated line: if we allocate a `snEntry` in the
stable name table, but run out of heap to actually allocate the `StgStableName`
we call GC with incorrect `snEntry` contents. As a reminder, this is `snEntry`:
```
typedef struct {
StgPtr addr; // Haskell object when entry is in use, next free
// entry (NULL when this is the last free entry)
// otherwise. May be NULL temporarily during GC (when
// pointee dies).
StgPtr old; // Old Haskell object, used during GC
StgClosure *sn_obj; // The StableName object, or NULL when the entry is
// free
} snEntry;
```
In summary, `sn_obj == NULL` means the entry is free. When we trigger the GC
after allocating the `snEntry` but before allocating the `StgStableName`, we end
up calling the GC with `sn_obj == NULL` even though the `snEntry` is not
actually free. In particular, the `addr` field should be updated by
`gcStableNameTable`, but it's currently not because `gcStableNameTable` sees
`sn_obj` as NULL and skips the entry.
The is caught by memo001 when run with -debug.
I already have a fix and will submit a patch soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stable name allocation causes heap corruption when GC is triggered in the primop","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The error is originally reported in #15241, and is caught by the test `memo001`\r\nwhen run with `-debug` (which only happens in sanity way currently).\r\n\r\nHere's the problem. mkStableName# is defined like this:\r\n\r\n{{{\r\nstg_makeStableNamezh ( P_ obj )\r\n{\r\n W_ index, sn_obj;\r\n\r\n (index) = ccall lookupStableName(obj \"ptr\");\r\n\r\n /* Is there already a StableName for this heap object?\r\n * stable_name_table is a pointer to an array of snEntry structs.\r\n */\r\n if ( snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) == NULL ) {\r\n ALLOC_PRIM (SIZEOF_StgStableName); <------------ PROBLEM HERE ----------\r\n sn_obj = Hp - SIZEOF_StgStableName + WDS(1);\r\n SET_HDR(sn_obj, stg_STABLE_NAME_info, CCCS);\r\n StgStableName_sn(sn_obj) = index;\r\n snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) = sn_obj;\r\n } else {\r\n sn_obj = snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry);\r\n }\r\n\r\n return (sn_obj);\r\n}\r\n}}}\r\n\r\nThere's a problem in the annotated line: if we allocate a `snEntry` in the\r\nstable name table, but run out of heap to actually allocate the `StgStableName`\r\nwe call GC with incorrect `snEntry` contents. As a reminder, this is `snEntry`:\r\n\r\n{{{\r\ntypedef struct {\r\n StgPtr addr; // Haskell object when entry is in use, next free\r\n // entry (NULL when this is the last free entry)\r\n // otherwise. May be NULL temporarily during GC (when\r\n // pointee dies).\r\n\r\n StgPtr old; // Old Haskell object, used during GC\r\n\r\n StgClosure *sn_obj; // The StableName object, or NULL when the entry is\r\n // free\r\n} snEntry;\r\n}}}\r\n\r\nIn summary, `sn_obj == NULL` means the entry is free. When we trigger the GC\r\nafter allocating the `snEntry` but before allocating the `StgStableName`, we end\r\nup calling the GC with `sn_obj == NULL` even though the `snEntry` is not\r\nactually free. In particular, the `addr` field should be updated by\r\n`gcStableNameTable`, but it's currently not because `gcStableNameTable` sees\r\n`sn_obj` as NULL and skips the entry.\r\n\r\nThe is caught by memo001 when run with -debug.\r\n\r\nI already have a fix and will submit a patch soon.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15910GHC missreports import as redundant.2019-07-07T18:02:29ZAndreas KlebingerGHC missreports import as redundant.In the following code GHC claims the first import is redundant.
```
import Data.Map (Map)
import qualified Data.Map as M
type MT = Map
```
```
test.hs:5:1: warning: [-Wunused-imports]
The qualified import of `Data.Map' is redunda...In the following code GHC claims the first import is redundant.
```
import Data.Map (Map)
import qualified Data.Map as M
type MT = Map
```
```
test.hs:5:1: warning: [-Wunused-imports]
The qualified import of `Data.Map' is redundant
except perhaps to import instances from `Data.Map'
To import instances alone, use: import Data.Map()
|
5 | import qualified Data.Map as M
```
Reproduceable on 8.4 and HEAD at least.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC missreports import as redundant.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following code GHC claims the first import is redundant.\r\n\r\n{{{\r\nimport Data.Map (Map)\r\n\r\nimport qualified Data.Map as M\r\n\r\ntype MT = Map\r\n}}}\r\n\r\n\r\n{{{\r\ntest.hs:5:1: warning: [-Wunused-imports]\r\n The qualified import of `Data.Map' is redundant\r\n except perhaps to import instances from `Data.Map'\r\n To import instances alone, use: import Data.Map()\r\n |\r\n5 | import qualified Data.Map as M\r\n}}}\r\n\r\n\r\nReproduceable on 8.4 and HEAD at least.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15923Skip performance tests if not in a git repo2019-07-07T18:02:26ZdavideSkip performance tests if not in a git repoAs of #12758 performance tests now compare to the results of the previous commit. Results are stored in git notes. If for some reason the rood directory is not a git repo, we have no results to compare to, nor can we save the new results...As of #12758 performance tests now compare to the results of the previous commit. Results are stored in git notes. If for some reason the rood directory is not a git repo, we have no results to compare to, nor can we save the new results to git notes. Hence we should skip all performance tests.
Such a use case was encountered in simonpj's workflow where he copies/syslinks the work tree without the .git directory before validating. An open question is can we allow performance testing while not in a git repo or by adjusting the workflow?
Tasks:
- When the ghc root directory is not a git repository, skip all performance tests.
- Update the [wiki page](https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Skip performance tests if not in a git repo","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["git","notes","performance","tests"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"As of #12758 performance tests now compare to the results of the previous commit. Results are stored in git notes. If for some reason the rood directory is not a git repo, we have no results to compare to, nor can we save the new results to git notes. Hence we should skip all performance tests.\r\n\r\nSuch a use case was encountered in simonpj's workflow where he copies/syslinks the work tree without the .git directory before validating. An open question is can we allow performance testing while not in a git repo or by adjusting the workflow?\r\n\r\nTasks:\r\n* When the ghc root directory is not a git repository, skip all performance tests.\r\n* Update the [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests wiki page].","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3davidedavidehttps://gitlab.haskell.org/ghc/ghc/-/issues/15936Rethink Choice of Baseline Commit for Performance Tests2019-07-07T18:02:23ZdavideRethink Choice of Baseline Commit for Performance Tests# Intro
Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results a...# Intro
Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results when they were run locally on your machine). This is by design: we want to avoid comparing results form different machines.
Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit.
# Proposed Solution
- Search for a baseline per test/test_env/metric/way
- Start at HEAD\^ and use local metrics. If none exist, use CI metrics. If none exist continue the search at the parent.
- Stop after a constant number of commits (failing to find a baseline).
- Stop the search if the child commit has expected changes for this test/metric/way (failing to find a baseline).
- It's possible that there are multiple runs of the test (e.g if the test was run many times locally). In that case take the average.
- If no baseline is found, show a warning and let the test pass.
### Handling Expected changes
If there are expected changes between HEAD and a potential baseline commit, then that baseline cannot be used. We make no attempt to approximate a baseline. A warning will be issued telling the user to run the tests of the previous commit or try and fetch CI results.
#### Issues
- The programmer is responsible for the final commit message having the correct expected changes. This is particularly important when merged via gitlab with a squash (this can change the commit message).
- We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests (This seems fragile and far too expensive).
### When to automatically fetch CI results?
Do not fetch CI results. Allow the user to do this, but give the exact git command so they can just copy and paste.
# Alternative Solution
Ultimately this was deemed too complicated. It assumes that commits will be squashed and merged into master (not always true).
- When running performance tests, results will be compared to a baseline commit that is the merge base with master (most recent commit from master). If HEAD is already in master, then the previous commit is used instead.
- If any locally generated performance results exist, they are used exclusively for the baseline.
- Else if any CI generated performance results exist (and have been fetched), they are used exclusively for the baseline.
- Else performance tests trivially pass, and a warning is given to the user.
To find the baseline commit:
```
mergeBase = merge-base master HEAD
baselineCommit = if mergeBase == HEAD
then HEAD^
else mergeBase
```
### Reasoning
- We want each commit in master not to introduce a significant change in performance: hence we compare commits in mater to the previous commit.
- If not on master (1 or more ahead and 0 or more commits behind master). We assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master as a single commit. On the other hand we don't want to consider changes in master from after we branched. Instead of using master HEAD as the baseline, we use the commit from which we branched from master (i.e. the merge base). In other words we are concerned only with the change in performance introduced by the newly crated commits.8.6.3davidedavidehttps://gitlab.haskell.org/ghc/ghc/-/issues/15943"ASSERT failed" with quantified constraints2019-07-07T18:02:21ZIcelandjack"ASSERT failed" with quantified constraints```hs
{-# Language RankNTypes #-}
{-# Language DataKinds #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
{-# Language TypeFamilyDependencies #-}
{-# Language GADTs ...```hs
{-# Language RankNTypes #-}
{-# Language DataKinds #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
{-# Language TypeFamilyDependencies #-}
{-# Language GADTs #-}
{-# Language TypeSynonymInstances #-}
{-# Language FlexibleInstances #-}
{-# Language QuantifiedConstraints #-}
import Data.Type.Equality
import Data.Coerce
import Data.Type.Coercion
import Data.Kind
newtype WrapFalse a b = WrapFalse (Hom False a b)
newtype WrapTrue a b = WrapTrue (Hom True a b)
class
(forall (x :: ob) (y :: ob). Coercible (WrapFalse x y) (WrapTrue y x))
=>
Ríki ob where
type Hom (or::Bool) = (res :: ob -> ob -> Type) | res -> or
instance Ríki Type where
type Hom False = (->)
type Hom True = Op
newtype Op :: Type -> Type -> Type where
Op :: (b -> a) -> Op a b
```
```
$ ghc-stage2 --interactive -ignore-dot-ghci 740_bug.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 740_bug.hs, interpreted )
*** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1288
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"ASSERT failed\" with quantified constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language DataKinds #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language PolyKinds #-}\r\n{-# Language TypeFamilyDependencies #-}\r\n{-# Language GADTs #-}\r\n{-# Language TypeSynonymInstances #-}\r\n{-# Language FlexibleInstances #-}\r\n{-# Language QuantifiedConstraints #-}\r\n\r\nimport Data.Type.Equality\r\nimport Data.Coerce\r\nimport Data.Type.Coercion\r\nimport Data.Kind\r\n\r\nnewtype WrapFalse a b = WrapFalse (Hom False a b)\r\nnewtype WrapTrue a b = WrapTrue (Hom True a b)\r\n\r\nclass\r\n (forall (x :: ob) (y :: ob). Coercible (WrapFalse x y) (WrapTrue y x))\r\n =>\r\n Ríki ob where\r\n\r\n type Hom (or::Bool) = (res :: ob -> ob -> Type) | res -> or\r\n\r\ninstance Ríki Type where\r\n type Hom False = (->)\r\n type Hom True = Op\r\n\r\nnewtype Op :: Type -> Type -> Type where\r\n Op :: (b -> a) -> Op a b\r\n}}}\r\n\r\n{{{\r\n$ ghc-stage2 --interactive -ignore-dot-ghci 740_bug.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 740_bug.hs, interpreted )\r\n*** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1288\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/1594780 unexpected failiures for make test on mac on ghc 8.6.22019-07-07T18:02:20Zgeorge.colpitts80 unexpected failiures for make test on mac on ghc 8.6.280 unexpected faillures for make test on mac on ghc 8.6.2; I'm using an 8.6.2 from the binary distribution
Xcode 10.1, macos 10.13.6
Attached is the compressed output from "make test \>& test.log &"
I don't know what the results are on o...80 unexpected faillures for make test on mac on ghc 8.6.2; I'm using an 8.6.2 from the binary distribution
Xcode 10.1, macos 10.13.6
Attached is the compressed output from "make test \>& test.log &"
I don't know what the results are on other platforms.
```
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.2
bash-3.2$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
bash-3.2$ python3 --version
Python 3.7.0
bash-3.2$ uname -a
Darwin iMac27.local 17.7.0 Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64 x86_64
bash-3.2$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv -fno-builtin")
,("C compiler command","gcc")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags"," ")
,("C compiler supports -no-pie","NO")
,("Haskell CPP command","gcc")
,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs")
,("ld command","ld")
,("ld flags","")
,("ld supports compact unwind","YES")
,("ld supports build-id","NO")
,("ld supports filelist","YES")
,("ld is GNU ld","NO")
,("ar command","ar")
,("ar flags","qcls")
,("ar supports at file","NO")
,("ranlib command","")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/local/bin/perl")
,("cross compiling","NO")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has .ident directive","True")
,("target has subsections via symbols","True")
,("target has RTS linker","YES")
,("Unregisterised","NO")
,("LLVM llc command","llc")
,("LLVM opt command","opt")
,("LLVM clang command","clang")
,("Project version","8.6.2")
,("Project Git commit id","41f0f6c2f571ea05c49f9f6ed64beebdc5a9f9fc")
,("Booter version","8.4.4")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
,("RTS expects libdw","NO")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Support Backpack","YES")
,("Requires unified installed package IDs","YES")
,("Uses package keys","YES")
,("Uses unit IDs","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","YES")
,("GHC Profiled","NO")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/lib/ghc-8.6.2")
,("Global Package DB","/usr/local/lib/ghc-8.6.2/package.conf.d")
]
bash-3.2$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"80 unexpected failiures for make test on mac on ghc 8.6.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"80 unexpected faillures for make test on mac on ghc 8.6.2; I'm using an 8.6.2 from the binary distribution\r\nXcode 10.1, macos 10.13.6\r\nAttached is the compressed output from \"make test >& test.log &\"\r\nI don't know what the results are on other platforms.\r\n{{{\r\n ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.6.2\r\nbash-3.2$ gcc --version\r\nConfigured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1\r\nApple LLVM version 10.0.0 (clang-1000.11.45.5)\r\nTarget: x86_64-apple-darwin17.7.0\r\nThread model: posix\r\nInstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin\r\nbash-3.2$ python3 --version\r\nPython 3.7.0\r\nbash-3.2$ uname -a\r\nDarwin iMac27.local 17.7.0 Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64 x86_64\r\nbash-3.2$ ghc --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"GCC extra via C opts\",\" -fwrapv -fno-builtin\")\r\n ,(\"C compiler command\",\"gcc\")\r\n ,(\"C compiler flags\",\" -fno-stack-protector\")\r\n ,(\"C compiler link flags\",\" \")\r\n ,(\"C compiler supports -no-pie\",\"NO\")\r\n ,(\"Haskell CPP command\",\"gcc\")\r\n ,(\"Haskell CPP flags\",\"-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs\")\r\n ,(\"ld command\",\"ld\")\r\n ,(\"ld flags\",\"\")\r\n ,(\"ld supports compact unwind\",\"YES\")\r\n ,(\"ld supports build-id\",\"NO\")\r\n ,(\"ld supports filelist\",\"YES\")\r\n ,(\"ld is GNU ld\",\"NO\")\r\n ,(\"ar command\",\"ar\")\r\n ,(\"ar flags\",\"qcls\")\r\n ,(\"ar supports at file\",\"NO\")\r\n ,(\"ranlib command\",\"\")\r\n ,(\"touch command\",\"touch\")\r\n ,(\"dllwrap command\",\"/bin/false\")\r\n ,(\"windres command\",\"/bin/false\")\r\n ,(\"libtool command\",\"libtool\")\r\n ,(\"perl command\",\"/usr/local/bin/perl\")\r\n ,(\"cross compiling\",\"NO\")\r\n ,(\"target os\",\"OSDarwin\")\r\n ,(\"target arch\",\"ArchX86_64\")\r\n ,(\"target word size\",\"8\")\r\n ,(\"target has GNU nonexec stack\",\"False\")\r\n ,(\"target has .ident directive\",\"True\")\r\n ,(\"target has subsections via symbols\",\"True\")\r\n ,(\"target has RTS linker\",\"YES\")\r\n ,(\"Unregisterised\",\"NO\")\r\n ,(\"LLVM llc command\",\"llc\")\r\n ,(\"LLVM opt command\",\"opt\")\r\n ,(\"LLVM clang command\",\"clang\")\r\n ,(\"Project version\",\"8.6.2\")\r\n ,(\"Project Git commit id\",\"41f0f6c2f571ea05c49f9f6ed64beebdc5a9f9fc\")\r\n ,(\"Booter version\",\"8.4.4\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Build platform\",\"x86_64-apple-darwin\")\r\n ,(\"Host platform\",\"x86_64-apple-darwin\")\r\n ,(\"Target platform\",\"x86_64-apple-darwin\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting supported\",\"NO\")\r\n ,(\"Have native code generator\",\"YES\")\r\n ,(\"Support SMP\",\"YES\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn\")\r\n ,(\"RTS expects libdw\",\"NO\")\r\n ,(\"Support dynamic-too\",\"YES\")\r\n ,(\"Support parallel --make\",\"YES\")\r\n ,(\"Support reexported-modules\",\"YES\")\r\n ,(\"Support thinning and renaming package flags\",\"YES\")\r\n ,(\"Support Backpack\",\"YES\")\r\n ,(\"Requires unified installed package IDs\",\"YES\")\r\n ,(\"Uses package keys\",\"YES\")\r\n ,(\"Uses unit IDs\",\"YES\")\r\n ,(\"Dynamic by default\",\"NO\")\r\n ,(\"GHC Dynamic\",\"YES\")\r\n ,(\"GHC Profiled\",\"NO\")\r\n ,(\"Leading underscore\",\"YES\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/usr/local/lib/ghc-8.6.2\")\r\n ,(\"Global Package DB\",\"/usr/local/lib/ghc-8.6.2/package.conf.d\")\r\n ]\r\nbash-3.2$ \r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15964PartialTypeSignatures warnings should be turned off with -Wno-partial-type-si...2019-07-07T18:02:15ZMatthew PickeringPartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures```
Foo.hs:638:18: warning: [-Wpartial-type-signatures]
```
The warning when using `PartialTypeSignatures` suggests that the warning is enabled by `-Wpartial-type-signatures`. However, if you try and disable this warning using `-Wno-par...```
Foo.hs:638:18: warning: [-Wpartial-type-signatures]
```
The warning when using `PartialTypeSignatures` suggests that the warning is enabled by `-Wpartial-type-signatures`. However, if you try and disable this warning using `-Wno-partial-type-signatures` then GHC complains that it is not a recognised flag. The correct way to turn it off is to use `-fno-warn-partial-signatures`. It seems that for consistency the first way that I tried should also work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nFoo.hs:638:18: warning: [-Wpartial-type-signatures]\r\n}}}\r\n\r\nThe warning when using `PartialTypeSignatures` suggests that the warning is enabled by `-Wpartial-type-signatures`. However, if you try and disable this warning using `-Wno-partial-type-signatures` then GHC complains that it is not a recognised flag. The correct way to turn it off is to use `-fno-warn-partial-signatures`. It seems that for consistency the first way that I tried should also work.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15967can't build ghc on Mac with any level of dwarf for base library2019-07-07T18:02:14ZCarter Schonwaldcan't build ghc on Mac with any level of dwarf for base libraryi tried building base in 8.6.2 with -g1
and i get the following error pretty consitently from the system linker
```
ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout-build/libraries/base/dist-install/build/libHSbase-4.12.0....i tried building base in 8.6.2 with -g1
and i get the following error pretty consitently from the system linker
```
ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout-build/libraries/base/dist-install/build/libHSbase-4.12.0.0_p.a(Base.p_o), sectionForAddress(0x8066) address not in any section for architecture x86_64
```
if i do
```
GhcLibHcOpts += -g1
```
or higher in the build.mk file, i get this linker error at some point in building ghc or resulting executables .
I'm not sure if its \*just\* for profiled libs or every lib, but it looks like theres actually no way to handle the number of dwarf sections for large archives on OSX?!
or equivalently, we may need support for more parsimonious dwarf annotations if at all?
point being: if we can't support debug symbols for base on a tier 1 platform, either debug symbols working isn't part of our support SLA for tier 1 platforms, OR its a release blocker we've not had in our validate configuration matrix.8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15974QuantifiedConstraints: Spurious error involving superclass constraints2019-07-07T18:02:12ZAlexis KingQuantifiedConstraints: Spurious error involving superclass constraints```hs
{-# LANGUAGE KindSignatures, QuantifiedConstraints, UndecidableInstances #-}
```
Consider the following datatype and two classes:
```hs
data X (f :: * -> *)
class A a
class A a => B a
```
If I create an instance `A (X f)` invol...```hs
{-# LANGUAGE KindSignatures, QuantifiedConstraints, UndecidableInstances #-}
```
Consider the following datatype and two classes:
```hs
data X (f :: * -> *)
class A a
class A a => B a
```
If I create an instance `A (X f)` involving a quantified constraint
```hs
instance (forall a. A a => A (f a)) => A (X f)
```
then curiously, the following instance declaration for `B (X f)` is rejected with the accompanying error message:
```hs
instance (forall a. B a => B (f a)) => B (X f)
```
```
/tmp/qc.hs:11:10: error:
• Could not deduce (B a)
arising from the superclasses of an instance declaration
from the context: forall a. B a => B (f a)
bound by the instance declaration at /tmp/qc.hs:11:10-46
or from: A a bound by a quantified context at /tmp/qc.hs:1:1
Possible fix: add (B a) to the context of a quantified context
• In the instance declaration for ‘B (X f)’
|
11 | instance (forall a. B a => B (f a)) => B (X f)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Notably, if the instance declaration for `A (X f)` is altered to not use a quantified constraint, as in
```hs
instance A (f (X f)) => A (X f)
```
or even just
```hs
instance A (X f)
```
then the above instance declaration for `B (X f)` is accepted.
I see no reason that the `B (X f)` declaration should be rejected, even with the quantified constraint in the instance context for `A (X f)`. The error message complains that the typechecker cannot deduce `B a`, and it even suggests adding `B a` to the context of the quantified constraint, but `B a` is //already// in that context.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Spurious error involving superclass constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE KindSignatures, QuantifiedConstraints, UndecidableInstances #-}\r\n}}}\r\n\r\nConsider the following datatype and two classes:\r\n\r\n{{{#!hs\r\ndata X (f :: * -> *)\r\n\r\nclass A a\r\nclass A a => B a\r\n}}}\r\n\r\nIf I create an instance `A (X f)` involving a quantified constraint\r\n\r\n{{{#!hs\r\ninstance (forall a. A a => A (f a)) => A (X f)\r\n}}}\r\n\r\nthen curiously, the following instance declaration for `B (X f)` is rejected with the accompanying error message:\r\n\r\n{{{#!hs\r\ninstance (forall a. B a => B (f a)) => B (X f)\r\n}}}\r\n{{{\r\n/tmp/qc.hs:11:10: error:\r\n • Could not deduce (B a)\r\n arising from the superclasses of an instance declaration\r\n from the context: forall a. B a => B (f a)\r\n bound by the instance declaration at /tmp/qc.hs:11:10-46\r\n or from: A a bound by a quantified context at /tmp/qc.hs:1:1\r\n Possible fix: add (B a) to the context of a quantified context\r\n • In the instance declaration for ‘B (X f)’\r\n |\r\n11 | instance (forall a. B a => B (f a)) => B (X f)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nNotably, if the instance declaration for `A (X f)` is altered to not use a quantified constraint, as in\r\n\r\n{{{#!hs\r\ninstance A (f (X f)) => A (X f)\r\n}}}\r\n\r\nor even just\r\n\r\n{{{#!hs\r\ninstance A (X f)\r\n}}}\r\n\r\nthen the above instance declaration for `B (X f)` is accepted.\r\n\r\nI see no reason that the `B (X f)` declaration should be rejected, even with the quantified constraint in the instance context for `A (X f)`. The error message complains that the typechecker cannot deduce `B a`, and it even suggests adding `B a` to the context of the quantified constraint, but `B a` is //already// in that context.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15980unpin a mutable byte array2019-07-07T18:02:10ZAndrew Martinunpin a mutable byte arraySometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it m...Sometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it might not be useful for it to be pinned anymore. If it's a little byte array, it may contribute to a fragmented heap. Even if it's large, the fact that the user explicitly asked pin it prohibits it from ever being added to a compact region (pinned bytearrays that were pinned simply because they are over 3KB can be added to compact regions). A workaround for either of these problems is to copy the pinned bytearray into an unpinned byte array afterwards. But that's kind of wasteful. Is it possible to have a primop
```
unpinMutableByteArray :: MutableByteArray s -> State# s -> State# s
```
After this, the mutable byte array could be moved in memory. This would require `isMutableByteArrayPinned#` to undergo a similar transition as `sizeofMutableByteArray#` (which was superceeded by `getSizeofMutableByteArray#`) underwent.
Is this possible? Or are pinned things allocated in a special place that makes unpinning impossible?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unpin a mutable byte array","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Sometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it might not be useful for it to be pinned anymore. If it's a little byte array, it may contribute to a fragmented heap. Even if it's large, the fact that the user explicitly asked pin it prohibits it from ever being added to a compact region (pinned bytearrays that were pinned simply because they are over 3KB can be added to compact regions). A workaround for either of these problems is to copy the pinned bytearray into an unpinned byte array afterwards. But that's kind of wasteful. Is it possible to have a primop\r\n\r\n{{{\r\nunpinMutableByteArray :: MutableByteArray s -> State# s -> State# s\r\n}}}\r\n\r\nAfter this, the mutable byte array could be moved in memory. This would require `isMutableByteArrayPinned#` to undergo a similar transition as `sizeofMutableByteArray#` (which was superceeded by `getSizeofMutableByteArray#`) underwent.\r\n\r\nIs this possible? Or are pinned things allocated in a special place that makes unpinning impossible?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15994Duplicate entries in -ddump-minimal-imports2019-07-07T18:02:07ZSimon Peyton JonesDuplicate entries in -ddump-minimal-importsConsider
```
module Foo where
import System.IO
f = [ReadMode, ReadMode]
```
We get this:
```
$ ghc -c -ddump-minimal-imports Foo.hs
$ cat Foo.imports
import System.IO ( IOMode(ReadMode, ReadMode) )
```
Notice that `ReadMode` appear...Consider
```
module Foo where
import System.IO
f = [ReadMode, ReadMode]
```
We get this:
```
$ ghc -c -ddump-minimal-imports Foo.hs
$ cat Foo.imports
import System.IO ( IOMode(ReadMode, ReadMode) )
```
Notice that `ReadMode` appears twice.
Turns out this is because of a refactoring in `RnNames`
```
commit 6353efc7694ba8ec86c091918e02595662169ae2
Author: David Eichmann <EichmannD@gmail.com>
Date: Thu Nov 22 14:48:05 2018 -0500
Fix unused-import warnings
This patch fixes a fairly long-standing bug (dating back to 2015) in
RdrName.bestImport, namely
```
(which I wrote -- don't blame David!).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Duplicate entries in -ddump-minimal-imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n{{{\r\nmodule Foo where\r\n\r\nimport System.IO\r\n\r\nf = [ReadMode, ReadMode]\r\n}}}\r\nWe get this:\r\n{{{\r\n$ ghc -c -ddump-minimal-imports Foo.hs\r\n$ cat Foo.imports\r\nimport System.IO ( IOMode(ReadMode, ReadMode) )\r\n}}}\r\nNotice that `ReadMode` appears twice.\r\n\r\nTurns out this is because of a refactoring in `RnNames`\r\n{{{\r\ncommit 6353efc7694ba8ec86c091918e02595662169ae2\r\nAuthor: David Eichmann <EichmannD@gmail.com>\r\nDate: Thu Nov 22 14:48:05 2018 -0500\r\n\r\n Fix unused-import warnings\r\n \r\n This patch fixes a fairly long-standing bug (dating back to 2015) in\r\n RdrName.bestImport, namely\r\n}}}\r\n(which I wrote -- don't blame David!).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/16000Don't suggest Rank2Types and RankNTypes, only the latter2019-07-07T18:02:05ZchessaiDon't suggest Rank2Types and RankNTypes, only the latterCurrently (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------------------...Currently (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Don't suggest Rank2Types and RankNTypes, only the latter","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3