GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:20:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13732Incorrectly suggests ‘TypeOperators’2019-07-07T18:20:23ZIcelandjackIncorrectly suggests ‘TypeOperators’Loading the code
```hs
{-# Language RankNTypes, GADTs, MagicHash, PolyKinds, TypeInType, ConstraintKinds #-}
import Data.Kind
import GHC.Exts
import qualified Prelude
class Semi (a :: TYPE rep) where
data Free :: forall rep. (TYPE re...Loading the code
```hs
{-# Language RankNTypes, GADTs, MagicHash, PolyKinds, TypeInType, ConstraintKinds #-}
import Data.Kind
import GHC.Exts
import qualified Prelude
class Semi (a :: TYPE rep) where
data Free :: forall rep. (TYPE rep -> Constraint) -> TYPE rep -> Type where
Free :: (forall q. ctx q => (p -> q) -> q) -> Free ctx p
```
gives an incorrect suggestion
```
GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( tXMX.hs, interpreted )
Ok, modules loaded: Main.
*Main> :kind Free Semi
Free Semi :: * -> *
*Main> :kind Free Semi Int#
<interactive>:1:1: error:
Not in scope: type constructor or class ‘#’
<interactive>:1:1: error:
Illegal operator ‘#’ in type ‘Free Semi Int #’
Use TypeOperators to allow operators in types
<interactive>:1:1: error:
Operator applied to too few arguments: Free Semi Int #
*Main>
```
This should recommend enabling `MagicHash` instead.
<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":"Incorrectly suggests ‘TypeOperators’","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":"Loading the code\r\n\r\n{{{#!hs\r\n{-# Language RankNTypes, GADTs, MagicHash, PolyKinds, TypeInType, ConstraintKinds #-}\r\n\r\nimport Data.Kind\r\nimport GHC.Exts\r\nimport qualified Prelude\r\n\r\nclass Semi (a :: TYPE rep) where\r\n\r\ndata Free :: forall rep. (TYPE rep -> Constraint) -> TYPE rep -> Type where\r\n Free :: (forall q. ctx q => (p -> q) -> q) -> Free ctx p\r\n}}}\r\n\r\ngives an incorrect suggestion\r\n\r\n{{{\r\nGHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( tXMX.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> :kind Free Semi\r\nFree Semi :: * -> *\r\n*Main> :kind Free Semi Int#\r\n\r\n<interactive>:1:1: error:\r\n Not in scope: type constructor or class ‘#’\r\n\r\n<interactive>:1:1: error:\r\n Illegal operator ‘#’ in type ‘Free Semi Int #’\r\n Use TypeOperators to allow operators in types\r\n\r\n<interactive>:1:1: error:\r\n Operator applied to too few arguments: Free Semi Int #\r\n*Main> \r\n}}}\r\n\r\nThis should recommend enabling `MagicHash` instead.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13731DeriveFunctor and friends don't understand type families2020-06-08T17:11:37ZSophie TaylorDeriveFunctor and friends don't understand type families```hs
{-# LANGUAGE DeriveFunctor #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeFamilies #-}
data Test ext a where
Foo :: a -> Test ext a
Extend :: (ExtensionType e...```hs
{-# LANGUAGE DeriveFunctor #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeFamilies #-}
data Test ext a where
Foo :: a -> Test ext a
Extend :: (ExtensionType ext a) -> Test ext a
type family ExtensionType ext a
data ListExtension
type instance ExtensionType ListExtension a = [a]
deriving instance Functor (Test ListExtension)
{-
a.hs:15:1: error:
• Can't make a derived instance of ‘Functor (Test ListExtension)’:
Constructor ‘Extend’ must use the type variable only as the last argument of a data type
• In the stand-alone deriving instance for
‘Functor (Test ListExtension)’
|
15 | deriving instance Functor (Test ListExtension)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, modules loaded: none.
-}
```
<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":"DeriveFunctor and friends don't understand type families","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":"{{{#!hs\r\n{-# LANGUAGE DeriveFunctor #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE StandaloneDeriving #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ndata Test ext a where\r\n Foo :: a -> Test ext a\r\n Extend :: (ExtensionType ext a) -> Test ext a\r\n\r\ntype family ExtensionType ext a\r\ndata ListExtension\r\ntype instance ExtensionType ListExtension a = [a]\r\n\r\nderiving instance Functor (Test ListExtension)\r\n\r\n{-\r\n\r\na.hs:15:1: error:\r\n • Can't make a derived instance of ‘Functor (Test ListExtension)’:\r\n Constructor ‘Extend’ must use the type variable only as the last argument of a data type\r\n • In the stand-alone deriving instance for\r\n ‘Functor (Test ListExtension)’\r\n |\r\n15 | deriving instance Functor (Test ListExtension)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, modules loaded: none.\r\n-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13730Running GLUT code in GHCi yields NSInternalInconsistencyException2019-07-07T18:20:23ZRyan ScottRunning GLUT code in GHCi yields NSInternalInconsistencyExceptionI tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this:
```
$ cabal install GLFW-0.5.2.5
```
And run this module in with `...I tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this:
```
$ cabal install GLFW-0.5.2.5
```
And run this module in with `runghc`:
```hs
-- GLUT.hs
module Main where
import Graphics.UI.GLUT (($=), getArgsAndInitialize, createWindow, displayCallback, mainLoop)
main :: IO ()
main = do
(_progName, _args) <- getArgsAndInitialize
_window <- createWindow "Hello World"
displayCallback $= return ()
mainLoop
```
```
$ runghc GLUT.hs
2017-05-19 12:03:02.199 ghc[24628:669385] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread!
```
On the other hand, compiling and running the executable works without issue.
Alternatively, you can compile the attached files, which require no dependencies:
```
$ ghc HsGLUT.c GLUT2.hs
[1 of 1] Compiling Main ( GLUT2.hs, GLUT2.o )
Linking GLUT2 ...
$ ghci HsGLUT.o GLUT2.hs
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/rscott/.ghci
[1 of 1] Compiling Main ( GLUT2.hs, interpreted )
Ok, modules loaded: Main.
λ> main
2017-05-19 12:06:15.365 ghc[24671:670166] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Running GLUT code in GHCi yields NSInternalInconsistencyException","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this:\r\n\r\n{{{\r\n$ cabal install GLFW-0.5.2.5\r\n}}}\r\n\r\nAnd run this module in with `runghc`:\r\n\r\n{{{#!hs\r\n-- GLUT.hs\r\nmodule Main where\r\n\r\nimport Graphics.UI.GLUT (($=), getArgsAndInitialize, createWindow, displayCallback, mainLoop)\r\n\r\nmain :: IO ()\r\nmain = do\r\n (_progName, _args) <- getArgsAndInitialize\r\n _window <- createWindow \"Hello World\"\r\n displayCallback $= return ()\r\n mainLoop\r\n}}}\r\n\r\n{{{\r\n$ runghc GLUT.hs\r\n2017-05-19 12:03:02.199 ghc[24628:669385] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread!\r\n}}}\r\n\r\nOn the other hand, compiling and running the executable works without issue.\r\n\r\nAlternatively, you can compile the attached files, which require no dependencies:\r\n\r\n{{{\r\n$ ghc HsGLUT.c GLUT2.hs\r\n[1 of 1] Compiling Main ( GLUT2.hs, GLUT2.o )\r\nLinking GLUT2 ...\r\n\r\n$ ghci HsGLUT.o GLUT2.hs\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /Users/rscott/.ghci\r\n[1 of 1] Compiling Main ( GLUT2.hs, interpreted )\r\nOk, modules loaded: Main.\r\nλ> main\r\n2017-05-19 12:06:15.365 ghc[24671:670166] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/13729ghc does not pick up TH changes across package boundaries2019-07-07T18:20:24ZFeuerbachghc does not pick up TH changes across package boundariesI have the following three modules:
```hs
module Types where
data Foo = Bar
```
```hs
{-# LANGUAGE TemplateHaskell #-}
module TH where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
import Types
th_string = lift . show...I have the following three modules:
```hs
module Types where
data Foo = Bar
```
```hs
{-# LANGUAGE TemplateHaskell #-}
module TH where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
import Types
th_string = lift . show =<< reify ''Foo
```
```hs
{-# LANGUAGE TemplateHaskell #-}
module Main where
import TH
main = putStrLn $(th_string)
```
The goal is to make Main recompile if the definition of Types.Foo changes.
If I simply put the three files in the same directory and compile with ghc, it works.
However, if I put Types and TH in package A and Main in package B, then ghc doesn't recompile B.Main if I change the definition of A.Types.Foo and reinstall the package A.
I tried this with both stack and cabal-install. In both cases I compiled B.Main directly with ghc, so it's not Cabal that's hiding the changes. If I pass -fforce-recomp to ghc, Main recompiles as expected.
<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":"ghc does not pick up TH changes across package boundaries","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":"I have the following three modules:\r\n\r\n{{{#!hs\r\nmodule Types where\r\n\r\ndata Foo = Bar\r\n}}}\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule TH where\r\n\r\nimport Language.Haskell.TH\r\nimport Language.Haskell.TH.Syntax\r\nimport Types\r\n\r\nth_string = lift . show =<< reify ''Foo\r\n}}}\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Main where\r\n\r\nimport TH\r\n\r\nmain = putStrLn $(th_string)\r\n}}}\r\n\r\nThe goal is to make Main recompile if the definition of Types.Foo changes.\r\n\r\nIf I simply put the three files in the same directory and compile with ghc, it works.\r\n\r\nHowever, if I put Types and TH in package A and Main in package B, then ghc doesn't recompile B.Main if I change the definition of A.Types.Foo and reinstall the package A.\r\n\r\nI tried this with both stack and cabal-install. In both cases I compiled B.Main directly with ghc, so it's not Cabal that's hiding the changes. If I pass -fforce-recomp to ghc, Main recompiles as expected.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13728Clarify the difference between NameL and NameU in Template Haskell2019-07-07T18:20:24ZFeuerbachClarify the difference between NameL and NameU in Template HaskellReading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type
```hs
data P a b = P a b
```
defined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as Nam...Reading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type
```hs
data P a b = P a b
```
defined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as NameUs.
Are NameLs used anywhere at all? In any case, I think the docs should be updated to explain the difference clearly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clarify the difference between NameL and NameU in Template Haskell","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type\r\n\r\n{{{#!hs\r\ndata P a b = P a b\r\n}}}\r\n\r\ndefined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as NameUs.\r\n\r\nAre NameLs used anywhere at all? In any case, I think the docs should be updated to explain the difference clearly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13727`-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules2019-07-07T18:20:24ZHerbert Valerio Riedelhvr@gnu.org`-Wmissing-home-modules` doesn't properly recognize filepath-qualified modulesThe `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables...The `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables this way, as Cabal needs to provide the path to the Main module directly.
Consider the following two files:
- `src-lib/M1.hs`
```hs
module M1 where
```
- `src-exe/Main.hs`
```hs
import M1
main = return ()
```
And now consider the following inconsistent results:
Expected good behaviour:
```
ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe Main
<no location info>: warning: [-Wmissing-home-modules]
Modules are not listed in command line: M1
[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )
[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )
Linking src-exe/Main ...
```
```
ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe M1 Main
[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )
[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )
Linking src-exe/Main ...
```
Unexpected bad behaviour:
```
ghc-8.2.1 -fforce-recomp -Wmissing-home-modules src-lib/M1.hs src-exe/Main.hs
<no location info>: warning: [-Wmissing-home-modules]
Modules are not listed in command line: M1 Main
[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )
[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )
Linking src-exe/Main ...
```
```
ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib M1 src-exe/Main
<no location info>: warning: [-Wmissing-home-modules]
Modules are not listed in command line: Main
[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )
[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )
Linking src-exe/Main ...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Yuras |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Yuras"],"type":"Bug","description":"The `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables this way, as Cabal needs to provide the path to the Main module directly.\r\n\r\nConsider the following two files:\r\n\r\n- `src-lib/M1.hs`\r\n{{{#!hs\r\nmodule M1 where\r\n}}}\r\n\r\n- `src-exe/Main.hs`\r\n{{{#!hs\r\nimport M1\r\n\r\nmain = return ()\r\n}}}\r\n\r\nAnd now consider the following inconsistent results:\r\n\r\nExpected good behaviour:\r\n\r\n{{{\r\nghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe Main\r\n\r\n<no location info>: warning: [-Wmissing-home-modules]\r\n Modules are not listed in command line: M1\r\n[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )\r\n[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )\r\nLinking src-exe/Main ...\r\n}}}\r\n\r\n{{{\r\nghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe M1 Main\r\n[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )\r\n[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )\r\nLinking src-exe/Main ...\r\n}}}\r\n\r\nUnexpected bad behaviour:\r\n\r\n{{{\r\nghc-8.2.1 -fforce-recomp -Wmissing-home-modules src-lib/M1.hs src-exe/Main.hs \r\n\r\n<no location info>: warning: [-Wmissing-home-modules]\r\n Modules are not listed in command line: M1 Main\r\n[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )\r\n[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )\r\nLinking src-exe/Main ...\r\n}}}\r\n\r\n{{{\r\nghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib M1 src-exe/Main\r\n\r\n<no location info>: warning: [-Wmissing-home-modules]\r\n Modules are not listed in command line: Main\r\n[1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o )\r\n[2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o )\r\nLinking src-exe/Main ...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1YurasYurashttps://gitlab.haskell.org/ghc/ghc/-/issues/13726Declaring GADT constructor and associated data family with the same name give...2020-02-18T13:39:59ZmrkgnaoDeclaring GADT constructor and associated data family with the same name gives weird errorThe code this is from is really messy. I'll submit a minimal example in a short while if this isn't a known bug fixed in 8.2.1. GHC complains about the kinds not matching instead of giving a "multiple definitions" error.The code this is from is really messy. I'll submit a minimal example in a short while if this isn't a known bug fixed in 8.2.1. GHC complains about the kinds not matching instead of giving a "multiple definitions" error.https://gitlab.haskell.org/ghc/ghc/-/issues/13725Remove false dependency on the destination of the popcnt instruction2022-02-17T04:45:19ZBen GamariRemove false dependency on the destination of the popcnt instructionfryguybob writes in [D3539](https://phabricator.haskell.org/D3539),
> Some Intel processors appear to have a false dependency on the destination of the popcnt instruction. This could lead to poor performance. A simple way to prevent thi...fryguybob writes in [D3539](https://phabricator.haskell.org/D3539),
> Some Intel processors appear to have a false dependency on the destination of the popcnt instruction. This could lead to poor performance. A simple way to prevent this is to clear the destination register immediately before the popcnt instruction. Currently I can't produce code from GHC where the source and destination registers are not the same (perhaps someone is interested in producing a test case that does). I'm putting this here in case anyone is interested in investigating further.
I'm opening this ticket so I can bump the diff out of the review queue, in hopes that someone might some day pick it up.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"Remove false dependency on the destination of the popcnt instruction","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"fryguybob writes in Phab:D3539,\r\n\r\n> Some Intel processors appear to have a false dependency on the destination of the popcnt instruction. This could lead to poor performance. A simple way to prevent this is to clear the destination register immediately before the popcnt instruction. Currently I can't produce code from GHC where the source and destination registers are not the same (perhaps someone is interested in producing a test case that does). I'm putting this here in case anyone is interested in investigating further.\r\n\r\nI'm opening this ticket so I can bump the diff out of the review queue, in hopes that someone might some day pick it up.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13724Clamping of llvm llc to -O1 and -O22020-01-23T19:31:02ZMoritz AngermannClamping of llvm llc to -O1 and -O2We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`.
The reason is that with `-O0`, the naive register allocator can topple over with
```
Error while trying to spill R1 from class GPR: Cannot scavenge...We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`.
The reason is that with `-O0`, the naive register allocator can topple over with
```
Error while trying to spill R1 from class GPR: Cannot scavenge register
without an emergency spill slot!
```
and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling
`rts/HeapStackCheck.cmm` with the stage1 ghc.
```
0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 llc 0x0000000102ae69a6 SignalHandler(int) + 358
2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26
3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876
4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699
5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381
6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457
7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20
8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134
9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498
10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67
11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920
12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133
13 llc 0x000000010195bf0b main + 491
14 libdyld.dylib 0x00007fffc21e5235 start + 1
Stack dump:
0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
```
`opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clamping of llvm llc to -O1 and -O2","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`.\r\n\r\nThe reason is that with `-O0`, the naive register allocator can topple over with\r\n\r\n{{{\r\n Error while trying to spill R1 from class GPR: Cannot scavenge register\r\n without an emergency spill slot!\r\n}}}\r\n\r\nand with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling\r\n`rts/HeapStackCheck.cmm` with the stage1 ghc.\r\n\r\n{{{\r\n0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40\r\n1 llc 0x0000000102ae69a6 SignalHandler(int) + 358\r\n2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26\r\n3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876\r\n4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699\r\n5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381\r\n6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457\r\n7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20\r\n8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134\r\n9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498\r\n10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67\r\n11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920\r\n12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133\r\n13 llc 0x000000010195bf0b main + 491\r\n14 libdyld.dylib 0x00007fffc21e5235 start + 1\r\nStack dump:\r\n0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s\r\n1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'.\r\n2. Running pass 'ARM Instruction Selection' on function '@\"stg_gc_f1$def\"'\r\n}}}\r\n\r\n`opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13723Recover gracefully from simplifier tick exhaustion2020-01-23T19:31:02ZDavid FeuerRecover gracefully from simplifier tick exhaustionCurrently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't *really* be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of t...Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't *really* be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are
### Transformations that must be performed before `CorePrep`
I hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug.
### Transformations that always reduce program size
If a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size *immediately*. For example,
```hs
foldr c n (build f) ==> f c n
```
is always fine. These transformations can share a tick limit with the mandatory transformations mentioned above.
### Transformations that never increase program size
We can be generous with these, but need some limit.
### Transformations that may increase program size
These need the harshest limit, of course, but probably not (much?) harsher than what we currently have.
----
The idea is that even if one tick limit is exceeded, the "higher priority" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| 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":"Recover gracefully from simplifier tick exhaustion","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't ''really'' be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are\r\n\r\n=== Transformations that must be performed before `CorePrep` ===\r\n\r\nI hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug.\r\n\r\n=== Transformations that always reduce program size ===\r\n\r\nIf a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size ''immediately''. For example,\r\n\r\n{{{#!hs\r\nfoldr c n (build f) ==> f c n\r\n}}}\r\n\r\nis always fine. These transformations can share a tick limit with the mandatory transformations mentioned above.\r\n\r\n=== Transformations that never increase program size ===\r\n\r\nWe can be generous with these, but need some limit.\r\n\r\n=== Transformations that may increase program size ===\r\n\r\nThese need the harshest limit, of course, but probably not (much?) harsher than what we currently have.\r\n\r\n----\r\n\r\nThe idea is that even if one tick limit is exceeded, the \"higher priority\" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13722intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded22019-07-07T18:20:26Zgeorge.colpittsintermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2in a bash shell type
for i in {1..10}; do make TEST=hs_try_putmvar003 WAY=threaded2 ; done
if you look at the output you will probably see at least one instance of
```
cd "./concurrent/should_run/hs_try_putmvar003.run" && ./hs_try_put...in a bash shell type
for i in {1..10}; do make TEST=hs_try_putmvar003 WAY=threaded2 ; done
if you look at the output you will probably see at least one instance of
```
cd "./concurrent/should_run/hs_try_putmvar003.run" && ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100
Wrong exit code for hs_try_putmvar003(threaded2)(expected 0 , actual 134 )
Stderr ( hs_try_putmvar003 ):
/bin/sh: line 1: 45386 Abort trap: 6 ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100
*** unexpected failure for hs_try_putmvar003(threaded2)
```
This was on a Mac running the latest OS and Xcode. I can attach the Apple problem report if that helps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"intermittent abort crash from make TEST=hs_try_putmvar003 WAY=threaded2","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"in a bash shell type \r\n\r\nfor i in {1..10}; do make TEST=hs_try_putmvar003 WAY=threaded2 ; done\r\n\r\nif you look at the output you will probably see at least one instance of \r\n{{{\r\ncd \"./concurrent/should_run/hs_try_putmvar003.run\" && ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100\r\nWrong exit code for hs_try_putmvar003(threaded2)(expected 0 , actual 134 )\r\nStderr ( hs_try_putmvar003 ):\r\n/bin/sh: line 1: 45386 Abort trap: 6 ./hs_try_putmvar003 +RTS -N2 -ls -RTS 1 16 32 100\r\n*** unexpected failure for hs_try_putmvar003(threaded2)\r\n}}}\r\n\r\nThis was on a Mac running the latest OS and Xcode. I can attach the Apple problem report if that helps.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13721posix004 test succeeds but then I get an Apple problem report window that say...2019-07-07T18:20:26Zgeorge.colpittsposix004 test succeeds but then I get an Apple problem report window that says: "posix004 quit unexpectedly"make TEST=posix004
```
results in
...
cd "../../libraries/unix/tests/libposix/posix004.run" && ./posix004
SUMMARY for test run started at Thu May 18 18:21:52 2017 ADT
0:00:03 spent to go through
1 total tests, which gave rise...make TEST=posix004
```
results in
...
cd "../../libraries/unix/tests/libposix/posix004.run" && ./posix004
SUMMARY for test run started at Thu May 18 18:21:52 2017 ADT
0:00:03 spent to go through
1 total tests, which gave rise to
10 test cases, of which
9 were skipped
0 had missing libraries
1 expected passes
0 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
0 unexpected failures
0 unexpected stat failures
```
but then I get an Apple problem report window that says: "posix004 quit unexpectedly"
Problem details and system configuration attached. This my be Mac specifc but leaving as unknown for now until we have more details
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"posix004 test succeeds but then I get an Apple problem report window that says: \"posix004 quit unexpectedly\"","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":" make TEST=posix004 \r\n{{{\r\nresults in\r\n...\r\ncd \"../../libraries/unix/tests/libposix/posix004.run\" && ./posix004 \r\n\r\nSUMMARY for test run started at Thu May 18 18:21:52 2017 ADT\r\n 0:00:03 spent to go through\r\n 1 total tests, which gave rise to\r\n 10 test cases, of which\r\n 9 were skipped\r\n\r\n 0 had missing libraries\r\n 1 expected passes\r\n 0 expected failures\r\n\r\n 0 caused framework failures\r\n 0 caused framework warnings\r\n 0 unexpected passes\r\n 0 unexpected failures\r\n 0 unexpected stat failures\r\n}}}\r\nbut then I get an Apple problem report window that says: \"posix004 quit unexpectedly\"\r\n\r\nProblem details and system configuration attached. This my be Mac specifc but leaving as unknown for now until we have more details","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13720INLINE pragma semantics changed since 8.0.22019-07-07T18:20:27ZMatthew PickeringINLINE pragma semantics changed since 8.0.2It now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before.
```hs
module A where
{-# INLINE f #-}
f x = h x
h x = x
{-# RULES "h x" forall x . h x = error "REWRI...It now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before.
```hs
module A where
{-# INLINE f #-}
f x = h x
h x = x
{-# RULES "h x" forall x . h x = error "REWRITE" #-}
```
```hs
module B where
import A
qux = f 5
```
Then running
```
> ghc-8.0.2 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5
qux :: Integer
[GblId, Str=DmdType x]
qux =
error ....
```
```
> ghc-8.2.0.20170507 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5
qux :: Integer
[GblId,
Caf=NoCafRefs,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}]
qux = 5
```
Inspecting the unfoldings, we see that 8.2 optimises the unfoldings to inline `h` before the rule can apply.
```
d61439f58ce9c5a268304423a43b9b44
f :: p -> p
{- Arity: 1, HasNoCafRefs, Strictness: <S,1*U>,
Inline: (sat-args=1),
Unfolding: InlineRule (1, False, True) (\ @ p (x :: p) -> x) -}
```
Is this new behaviour intentional? It seems possible that it will break some programs which use rewrite rules.
<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":"INLINE pragma semantics changed since 8.0.2","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":"It now seems that unfoldings for INLINE things are optimised slightly. This causes different interactions with `RULES` than before.\r\n\r\n{{{#!hs\r\nmodule A where\r\n\r\n{-# INLINE f #-}\r\nf x = h x\r\n\r\nh x = x\r\n\r\n{-# RULES \"h x\" forall x . h x = error \"REWRITE\" #-}\r\n}}}\r\n\r\n{{{#!hs\r\nmodule B where\r\n\r\nimport A\r\n\r\nqux = f 5\r\n}}}\r\n\r\nThen running\r\n\r\n{{{\r\n> ghc-8.0.2 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5\r\nqux :: Integer\r\n[GblId, Str=DmdType x]\r\nqux =\r\n error ....\r\n}}}\r\n\r\n{{{\r\n> ghc-8.2.0.20170507 B.hs -O2 -fforce-recomp -ddump-simpl | grep qux -A5\r\nqux :: Integer\r\n[GblId,\r\n Caf=NoCafRefs,\r\n Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}]\r\nqux = 5\r\n}}}\r\n\r\nInspecting the unfoldings, we see that 8.2 optimises the unfoldings to inline `h` before the rule can apply. \r\n\r\n{{{\r\nd61439f58ce9c5a268304423a43b9b44\r\n f :: p -> p\r\n {- Arity: 1, HasNoCafRefs, Strictness: <S,1*U>,\r\n Inline: (sat-args=1),\r\n Unfolding: InlineRule (1, False, True) (\\ @ p (x :: p) -> x) -}\r\n}}}\r\n\r\n\r\nIs this new behaviour intentional? It seems possible that it will break some programs which use rewrite rules.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13719checkFamInstConsistency dominates compile time2019-07-07T18:20:27ZniteriacheckFamInstConsistency dominates compile timeI'm looking into compile time issues on our internal code base.
`checkFamInstConsistency` takes 50% of all compile time for `:load` in `ghci` for us.
I've created a synthetic test case that approximates the issue and in which compiling ...I'm looking into compile time issues on our internal code base.
`checkFamInstConsistency` takes 50% of all compile time for `:load` in `ghci` for us.
I've created a synthetic test case that approximates the issue and in which compiling 300 modules with one small data type each takes 65s total, and `checkFamInstConsistency` is 87% of that and 94.1% of allocations.
`checkFamInstConsistency` is run to ensure consistency of a type family associated with Generics, but that's only semi-relevant.
To reproduce:
```
./gen.sh
./inplace/bin/ghc-stage2 -keep-tmp-files DummyLevel3M100.hs
```
Profile with some relevant cost centres: https://phabricator.haskell.org/P150
The next step is to look into implementing: #13092\##13719
I also plan to add this test case to the codebase.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, ezyang, rwbarton, simonmar, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"checkFamInstConsistency dominates compile time","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","ezyang","rwbarton","simonmar","simonpj"],"type":"Bug","description":"I'm looking into compile time issues on our internal code base.\r\n`checkFamInstConsistency` takes 50% of all compile time for `:load` in `ghci` for us.\r\n\r\nI've created a synthetic test case that approximates the issue and in which compiling 300 modules with one small data type each takes 65s total, and `checkFamInstConsistency` is 87% of that and 94.1% of allocations.\r\n`checkFamInstConsistency` is run to ensure consistency of a type family associated with Generics, but that's only semi-relevant. \r\n\r\nTo reproduce:\r\n{{{\r\n./gen.sh\r\n./inplace/bin/ghc-stage2 -keep-tmp-files DummyLevel3M100.hs\r\n}}}\r\n\r\nProfile with some relevant cost centres: https://phabricator.haskell.org/P150\r\n\r\nThe next step is to look into implementing: https://ghc.haskell.org/trac/ghc/ticket/13092#comment:14\r\n\r\nI also plan to add this test case to the codebase.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13718diagnostic colors: differentiate between message head and message body2019-07-07T18:20:27ZBertram Felgenhauerdiagnostic colors: differentiate between message head and message bodyWhen a diagnostic message is printed, currently the whole message is colored by the "message" color (bold by default). I'd find it useful if the message body and the header could be differentiated (I do like the idea that the header stan...When a diagnostic message is printed, currently the whole message is colored by the "message" color (bold by default). I'd find it useful if the message body and the header could be differentiated (I do like the idea that the header stands out).
Motivation: Consider the following error message,
```
GHCi, version 8.2.0.20170508: http://www.haskell.org/ghc/ :? for help
Prelude> () ()
<interactive>:1:1: error:
• Couldn't match expected type ‘() -> t’ with actual type ‘()’
• The function ‘()’ is applied to one argument,
but its type ‘()’ has none
In the expression: () ()
In an equation for ‘it’: it = () ()
• Relevant bindings include it :: t (bound at <interactive>:1:1)
```
which by default is all bold, with the `error:` part in red. I want the message body to use normal text. Thanks to #13444 I can achieve that by setting `GHC_COLORS="message=0"`. However, that setting also affects the initial `<interactive>:1:1` part of the headline, which now looks odd because normal and bold text are mixed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| 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":"diagnostic colors: differentiate between message head and message body","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":"FeatureRequest","description":"When a diagnostic message is printed, currently the whole message is colored by the \"message\" color (bold by default). I'd find it useful if the message body and the header could be differentiated (I do like the idea that the header stands out).\r\n\r\nMotivation: Consider the following error message,\r\n{{{\r\nGHCi, version 8.2.0.20170508: http://www.haskell.org/ghc/ :? for help\r\nPrelude> () ()\r\n\r\n<interactive>:1:1: error:\r\n • Couldn't match expected type ‘() -> t’ with actual type ‘()’\r\n • The function ‘()’ is applied to one argument,\r\n but its type ‘()’ has none\r\n In the expression: () ()\r\n In an equation for ‘it’: it = () ()\r\n • Relevant bindings include it :: t (bound at <interactive>:1:1)\r\n}}}\r\nwhich by default is all bold, with the {{{error:}}} part in red. I want the message body to use normal text. Thanks to #13444 I can achieve that by setting {{{GHC_COLORS=\"message=0\"}}}. However, that setting also affects the initial {{{<interactive>:1:1}}} part of the headline, which now looks odd because normal and bold text are mixed.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13717Pattern synonym exhaustiveness checks don't play well with EmptyCase2020-09-02T10:19:21ZDavid FeuerPattern synonym exhaustiveness checks don't play well with EmptyCaseIn #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write
```hs
newtype Fin...In #8779, mpickering added a `COMPLETE` pragma to allow exhaustiveness checking for matches involving pattern synonyms. Unfortunately, there is still one piece missing: the interaction with `EmptyCase`. Suppose I write
```hs
newtype Fin (n :: Nat) = Fin Natural -- constructor not exported
pattern FZ :: () => n ~ 'S m => Fin n
pattern FS :: () => n ~ 'S m => Fin m -> Fin n
{-# COMPLETE FZ, FS #-}
```
I would very much like to be able to write
```hs
finZAbsurd :: Fin 'Z -> Void
finZAbsurd x = case x of
```
but this gives me a pattern coverage warning! That's certainly not what we want. I believe what we actually want is this:
> When checking empty case, check that *at least one* complete pattern set is impossible.
In this case, it would see two complete pattern sets: the built-in `{Fin}` and the user-decreed `{FZ, FS}`. Since neither `FZ` nor `FS` have matching types, we should conclude that the empty case is fine.8.10.1Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/13716Move CI to Jenkins2019-07-07T18:20:27ZBen GamariMove CI to JenkinsCurrently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired:
- job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches...Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired:
- job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built
- there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources
- periodic builds (e.g. nightlies) are not supported.
- it lacks a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off
- status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult
- common maintenance tasks are byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration.
- Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold.
Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins.
See [Ben's blog post (Aug 17)](https://ghc.haskell.org/trac/ghc/blog/jenkins-ci).
In the end we want,
- Builders (static or dynamically-provisioned, as appropriate) for
\* x86-64, i386 Linux
\* x86-64, i386 Windows
\* x86-64 Darwin
\* x86-64 OpenBSD
\* Cross compile from x86-64 to ARM
\* Native ARM
- Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others)
- Per-commit builds on all
- Nightly builds on all, including
\* Collection of binary distribution for user download
\* Update of `master` documentation mirror on downloads.haskell.org
\* Slow validation (including tests requiring Hackage packages)
\* nofib run on some platforms?
- Test-before-merge-to-masterhttps://gitlab.haskell.org/ghc/ghc/-/issues/13715test dynamic-paper for way profasm fails with Simplifier ticks exhausted2019-07-07T18:20:28Zgeorge.colpittstest dynamic-paper for way profasm fails with Simplifier ticks exhaustedon ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhaust...on ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone delta
1. ..
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad
it also fails with 1000 ticks
make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'
so there may be an infinite loop
<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":"test dynamic-paper for way profasm fails with Simplifier ticks exhausted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":["simplifier","ticks"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"on ghc 8.2.1-rc2 on a mac running the latest Xcode and os\r\n{{{\r\nmake TEST=dynamic-paper WAY=profasm \r\nfails with \r\nghc-stage2: panic! (the 'impossible' happened)\r\n\t (GHC version 8.2.0.20170507 for x86_64-apple-darwin):\r\n\t\tSimplifier ticks exhausted\r\n\t When trying UnfoldingDone delta\r\n...\r\nCall stack:\r\n\t CallStack (from HasCallStack):\r\n\t\tprettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable\r\n\t\tcallStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable\r\n\t\tpprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad\r\n\r\nit also fails with 1000 ticks\r\nmake TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'\r\nso there may be an infinite loop","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/13714Guard pages instead of Heap/Stack limit checks in Cmm2019-07-07T18:20:28ZvarosiGuard pages instead of Heap/Stack limit checks in CmmRecently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm](https://ghc.haskell.org/trac/ghc/browser/ghc/...Recently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm](https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm)). This is not cheap and introduce more branch mispredictions and instructions.
What you think if we use guard OS pages (that trigger exceptions when someone try to read/write on them) around Stack and Heap? Stack and Heap sizes should be aligned on page size (usually 4K) and with sizes that fits 4K pages. We could handle such exceptions so we could do GC if needed. This trick is usually found in some memory managers for finding out-of-bounds bugs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Guard pages instead of Heap/Stack limit checks in Cmm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Recently I have debugged a small program and I saw that there are a lot of Heap/Stack limit checks on function entrances ([https://ghc.haskell.org/trac/ghc/browser/ghc/rts/HeapStackCheck.cmm]). This is not cheap and introduce more branch mispredictions and instructions.\r\nWhat you think if we use guard OS pages (that trigger exceptions when someone try to read/write on them) around Stack and Heap? Stack and Heap sizes should be aligned on page size (usually 4K) and with sizes that fits 4K pages. We could handle such exceptions so we could do GC if needed. This trick is usually found in some memory managers for finding out-of-bounds bugs.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13713fdefer-type-errors makes missing import errors disappear2019-07-07T18:20:28ZNiklas Hambüchenmail@nh2.mefdefer-type-errors makes missing import errors disappearI have this code
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
import Data.Type.Equality ((:~:)(Refl))
import GHC.TypeLits
import qualified Numeric.LinearAlgebra as LA
import ...I have this code
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
import Data.Type.Equality ((:~:)(Refl))
import GHC.TypeLits
import qualified Numeric.LinearAlgebra as LA
import Numeric.LinearAlgebra.Static
toVec :: forall n . (KnownNat n) => LA.Vector Double -> R n
toVec vec = withVector vec $ \(v :: R n2) -> case sameNat (Proxy @n) (Proxy @n2) of
Just Refl -> v
Nothing -> error "wrong dimensions"
```
Notably I forgot to import `Proxy`.
Without `-fdefer-type-errors` I get this error:
```
➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs'
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted )
ghc-8.0.2-proxy-confusing-error.hs:12:60: error:
Data constructor not in scope: Proxy
ghc-8.0.2-proxy-confusing-error.hs:12:60: error:
* Cannot apply expression of type `t1'
to a visible type argument `n'
* In the first argument of `sameNat', namely `(Proxy @n)'
In the expression: sameNat (Proxy @n) (Proxy @n2)
In the expression:
case sameNat (Proxy @n) (Proxy @n2) of {
Just Refl -> v
Nothing -> error "wrong dimensions" }
Failed, modules loaded: none.
```
but with `-fdefer-type-errors` the `Data constructor not in scope: Proxy` is gone!
```
➤ nix-shell -p "haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs -fdefer-type-errors'
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted )
ghc-8.0.2-proxy-confusing-error.hs:12:60: error:
* Cannot apply expression of type `t1'
to a visible type argument `n'
* In the first argument of `sameNat', namely `(Proxy @n)'
In the expression: sameNat (Proxy @n) (Proxy @n2)
In the expression:
case sameNat (Proxy @n) (Proxy @n2) of {
Just Refl -> v
Nothing -> error "wrong dimensions" }
Failed, modules loaded: none.
```
This is probably related to #12529.
<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":"fdefer-type-errors makes missing import errors disappear","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":"I have this code\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeApplications #-}\r\n\r\n\r\nimport Data.Type.Equality ((:~:)(Refl))\r\nimport GHC.TypeLits\r\nimport qualified Numeric.LinearAlgebra as LA\r\nimport Numeric.LinearAlgebra.Static\r\n\r\n\r\ntoVec :: forall n . (KnownNat n) => LA.Vector Double -> R n\r\ntoVec vec = withVector vec $ \\(v :: R n2) -> case sameNat (Proxy @n) (Proxy @n2) of\r\n Just Refl -> v\r\n Nothing -> error \"wrong dimensions\"\r\n}}}\r\n\r\nNotably I forgot to import `Proxy`.\r\n\r\nWithout `-fdefer-type-errors` I get this error:\r\n\r\n{{{\r\n➤ nix-shell -p \"haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])\" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs'\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted )\r\n\r\nghc-8.0.2-proxy-confusing-error.hs:12:60: error:\r\n Data constructor not in scope: Proxy\r\n\r\nghc-8.0.2-proxy-confusing-error.hs:12:60: error:\r\n * Cannot apply expression of type `t1'\r\n to a visible type argument `n'\r\n * In the first argument of `sameNat', namely `(Proxy @n)'\r\n In the expression: sameNat (Proxy @n) (Proxy @n2)\r\n In the expression:\r\n case sameNat (Proxy @n) (Proxy @n2) of {\r\n Just Refl -> v\r\n Nothing -> error \"wrong dimensions\" }\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nbut with `-fdefer-type-errors` the `Data constructor not in scope: Proxy` is gone!\r\n\r\n{{{\r\n➤ nix-shell -p \"haskellPackages.ghcWithPackages (pkgs:[pkgs.hmatrix])\" --pure --run 'ghci ghc-8.0.2-proxy-confusing-error.hs -fdefer-type-errors'\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( ghc-8.0.2-proxy-confusing-error.hs, interpreted )\r\n\r\nghc-8.0.2-proxy-confusing-error.hs:12:60: error:\r\n * Cannot apply expression of type `t1'\r\n to a visible type argument `n'\r\n * In the first argument of `sameNat', namely `(Proxy @n)'\r\n In the expression: sameNat (Proxy @n) (Proxy @n2)\r\n In the expression:\r\n case sameNat (Proxy @n) (Proxy @n2) of {\r\n Just Refl -> v\r\n Nothing -> error \"wrong dimensions\" }\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\n\r\nThis is probably related to #12529.","type_of_failure":"OtherFailure","blocking":[]} -->