GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:34Zhttps://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/15885Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (outpu...2021-02-22T21:15:08ZShayan-NajdEnhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) typesOn our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [...On our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [a pattern synonym](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations) similar to the following:
```hs
pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a
pattern LL s m <- (decomposeSrcSpan -> (m , s))
where
LL s m = composeSrcSpan (m , s)
```
We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).
As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.
I believe we need to enhance COMPLETE pragmas to support such pattern synonyms.
This can be done either syntactically, or (preferably) type-directed.
For example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.
In the type-directed approach
a. the totality checker \*may\* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and
b. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by \@carter).
For example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"On our work on the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow new front-end AST for GHC] based on [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG], we would like to use [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations a pattern synonym] similar to the following:\r\n\r\n{{{#!hs\r\npattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a\r\npattern LL s m <- (decomposeSrcSpan -> (m , s))\r\n where\r\n LL s m = composeSrcSpan (m , s)\r\n}}}\r\n\r\nWe know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).\r\n\r\nAs far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.\r\nI believe we need to enhance COMPLETE pragmas to support such pattern synonyms.\r\n\r\nThis can be done either syntactically, or (preferably) type-directed.\r\n\r\nFor example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.\r\n\r\nIn the type-directed approach\r\na. the totality checker *may* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and\r\nb. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by @carter).\r\n\r\nFor example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15884Completeness of View Patterns With a Complete Set of Output Patterns2023-07-31T10:31:25ZShayan-NajdCompleteness of View Patterns With a Complete Set of Output PatternsFor example, the code
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ViewPatterns #-}
f :: Maybe a -> Bool
f (id->Nothing) = False
f (id->(Just _)) = True
```
mistakenly returns the warning
```
warning: [-Wincomplete-patterns]
Patt...For example, the code
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ViewPatterns #-}
f :: Maybe a -> Bool
f (id->Nothing) = False
f (id->(Just _)) = True
```
mistakenly returns the warning
```
warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘f’: Patterns not matched: _
|
4 | f (id->Nothing) = False
| ^^^^^^^^^^^^^^^^^^^^^^^^...
```
<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 | alanz, bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Completeness of View Patterns With a Complete Set of Output Patterns","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":["alanz","bgamari"],"type":"Bug","description":"For example, the code\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE ViewPatterns #-}\r\nf :: Maybe a -> Bool\r\nf (id->Nothing) = False\r\nf (id->(Just _)) = True\r\n}}}\r\n\r\nmistakenly returns the warning\r\n\r\n{{{\r\nwarning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘f’: Patterns not matched: _\r\n |\r\n4 | f (id->Nothing) = False\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^...\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15882:load in ghci should expose the entire namespace of a module2019-07-07T18:02:35ZEyalLotem:load in ghci should expose the entire namespace of a moduleWhen using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no ...When using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":load in ghci should expose the entire namespace of a module","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When using \"import\" in ghci, only exported names are available.\r\n\r\nWhen using :load, the use case is typically for \"toying around\" or testing a module. In that case, the export list restrictions are much less useful.\r\n \r\nThere is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary \"import\" namespace semantics are after all available too.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/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/15880GHC.Stats: Add info on amount of pinned memory2019-08-03T11:16:56ZNiklas Hambüchenmail@nh2.meGHC.Stats: Add info on amount of pinned memoryhttps://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amo...https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amount of memory in use by the RTS" (`gcdetails_mem_in_use_bytes`)
There currently doesn't seem to be a way to get the amount of pinned memory in use.
So some questions:
- Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?
- If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?
- If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?
In general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Stats: Add info on amount of pinned memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Task","description":"https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html\r\n\r\n`GHC.Stats`'s `GCDetails` tells us, separately, the amount of \r\n\r\n* total heap data (including large objects and compact data)\r\n* large ojects\r\n* compact data\r\n* \"Total amount of memory in use by the RTS\" (`gcdetails_mem_in_use_bytes`)\r\n\r\nThere currently doesn't seem to be a way to get the amount of pinned memory in use.\r\n\r\nSo some questions:\r\n\r\n* Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?\r\n* If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?\r\n* If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?\r\n\r\nIn general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/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/15878Unused data type with a "deriving" clause is falsely considered used2021-06-17T16:32:40ZEyalLotemUnused data type with a "deriving" clause is falsely considered usedmodule M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from in...module M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from instance declarations, it is necessarily unused in the program.
One potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the \*type\* is unused.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unused data type with a \"deriving\" clause is falsely considered used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"module M () where data Foo = Bar deriving (Eq)\r\n\r\nIf there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.\r\n\r\nEven if it is referenced, but only from instance declarations, it is necessarily unused in the program.\r\n\r\nOne potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the *type* is unused.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15876Function versioning instead of compilation flags...2019-07-07T18:02:36ZMichalGajdaFunction versioning instead of compilation flags...Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags....Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags.
Instead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/
This would allow us to write code like this:
{-\# target(avx512) \#-}
c_memchr = ...SIMD code...
{-\# !target(avx512) \#-}
c_memchr = ...current code...
We currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)
Ideally we could also use it to remove some of _flavoring_ in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | abhir00p, marlowsd@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Function versioning instead of compilation flags...","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["flavors,","simd,","speed"],"differentials":[],"test_case":"","architecture":"","cc":["abhir00p","marlowsd@gmail.com"],"type":"FeatureRequest","description":"Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).\r\n\r\nThis would require recompiling most of the libraries for new flags.\r\n\r\nInstead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/\r\n\r\nThis would allow us to write code like this:\r\n{-# target(avx512) #-}\r\nc_memchr = ...SIMD code...\r\n{-# !target(avx512) #-}\r\nc_memchr = ...current code...\r\n\r\nWe currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)\r\n\r\nIdeally we could also use it to remove some of _flavoring_ in the future.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/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/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/15866libiserv's version number is hard-coded2020-09-28T07:11:37ZRyan Scottlibiserv's version number is hard-codedI recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` d...I recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` directly in its `.cabal` file.
Needless to say, this is quite easy to forget to update. Let's let `autoconf` do the hard work for us and use `@ProjectVersionMunged@` instead.
<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":"libiserv's version number is hard-coded","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` directly in its `.cabal` file.\r\n\r\nNeedless to say, this is quite easy to forget to update. Let's let `autoconf` do the hard work for us and use `@ProjectVersionMunged@` instead.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15859Dependent quantification, GHC panic2019-07-07T18:02:41ZIcelandjackDependent quantification, GHC panicWhile exploring [Ryan's gist for term-level](https://gist.github.com/RyanGlScott/ded669b5ae3db1ce38c4b6021f144776) `f :: forall a -> a -> Type`.
```hs
{-# Language PolyKinds #-}
{-# Language TypeApplications #-}
{-# Language ...While exploring [Ryan's gist for term-level](https://gist.github.com/RyanGlScott/ded669b5ae3db1ce38c4b6021f144776) `f :: forall a -> a -> Type`.
```hs
{-# Language PolyKinds #-}
{-# Language TypeApplications #-}
{-# Language ImpredicativeTypes #-}
import Data.Kind
data A k :: k -> Type
f :: KindOf A
f a = undefined
type KindOf (a :: k) = k
a = f @Int
```
gives
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 630_bug.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 630_bug.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181029 for x86_64-unknown-linux):
ASSERT failed!
KindOf A
forall k -> k -> *
k_a1xQ[sk:0]
k_a1xQ[sk:0] -> *
k_a1xQ[sk:0]
[req]
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/TcExpr.hs:1336:94 in ghc:TcExpr
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<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":"Dependent quantification, GHC panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While exploring [https://gist.github.com/RyanGlScott/ded669b5ae3db1ce38c4b6021f144776 Ryan's gist for term-level] `f :: forall a -> a -> Type`.\r\n\r\n{{{#!hs\r\n{-# Language PolyKinds #-}\r\n{-# Language TypeApplications #-}\r\n{-# Language ImpredicativeTypes #-}\r\n\r\nimport Data.Kind\r\n\r\ndata A k :: k -> Type\r\n\r\nf :: KindOf A\r\nf a = undefined\r\n\r\ntype KindOf (a :: k) = k\r\n\r\na = f @Int\r\n}}}\r\n\r\ngives \r\n\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 630_bug.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 630_bug.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181029 for x86_64-unknown-linux):\r\n ASSERT failed!\r\n KindOf A\r\n forall k -> k -> *\r\n k_a1xQ[sk:0]\r\n k_a1xQ[sk:0] -> *\r\n k_a1xQ[sk:0]\r\n [req]\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/TcExpr.hs:1336:94 in ghc:TcExpr\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15780ghc-8.4.4 failed to build on armv7 and aarch642019-07-07T18:03:02ZJens Petersenghc-8.4.4 failed to build on armv7 and aarch64ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit).
https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522
They both fail in the same way:
```
"inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iinc...ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit).
https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522
They both fail in the same way:
```
"inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o
"inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.4 for aarch64-unknown-linux):
padLiveArgs -- i > regNum ??
CallStack (from HasCallStack):
error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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-8.4.4 failed to build on armv7 and aarch64","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit).\r\n\r\nhttps://koji.fedoraproject.org/koji/taskinfo?taskID=30284522\r\n\r\nThey both fail in the same way:\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for aarch64-unknown-linux):\r\n\tpadLiveArgs -- i > regNum ??\r\nCallStack (from HasCallStack):\r\n error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nmake[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15715problematic openFile with named pipes2019-07-07T18:03:19Zadpproblematic openFile with named pipes- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the proc...- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything).
- `writeFile` and `appendFile` works though.
- using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"problematic openFile with named pipes","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"- while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything).\r\n\r\n- `writeFile` and `appendFile` works though.\r\n\r\n- using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS\r\n","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15633Type-checker plugins aren't loaded in GHCi 8.6.12019-07-07T18:03:39ZOleg GrenrusType-checker plugins aren't loaded in GHCi 8.6.1Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f
However with GHC-8.6.1
The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907
76a233143f1ec940f342ce3ce3af...Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f
However with GHC-8.6.1
The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907
76a233143f1ec940f342ce3ce3afaf306923b392 (which seems to be the last commit in 8.6 branch atm)
the plugins aren't loaded.
```
% ghci-8.6.1 -fplugin=ThereIsNoPlugin
GHCi, version 8.6.0.20180907: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ogre/.ghci
λ>
```
starts a session without a warning. 8.4.3 however fails:
```
% ghci-8.4.3 -fplugin=ThereIsNoPlugin
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
<command line>: Could not find module ‘ThereIsNoPlugin’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1-beta1 |
| 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":"Type-checker plugins aren't loaded in 8.6.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1-beta1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f\r\n\r\nHowever with GHC-8.6.1\r\n\r\nThe Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907\r\n76a233143f1ec940f342ce3ce3afaf306923b392 (which seems to be the last commit in 8.6 branch atm)\r\n\r\nthe plugins aren't loaded.\r\n\r\n{{{\r\n% ghci-8.6.1 -fplugin=ThereIsNoPlugin\r\nGHCi, version 8.6.0.20180907: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/ogre/.ghci\r\nλ> \r\n}}}\r\n\r\nstarts a session without a warning. 8.4.3 however fails:\r\n\r\n{{{\r\n% ghci-8.4.3 -fplugin=ThereIsNoPlugin\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\n<command line>: Could not find module ‘ThereIsNoPlugin’\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15608Segfault in retainer profiling2019-07-07T18:03:45ZÖmer Sinan AğacanSegfault in retainer profilingTo reproduce, build ghc using "prof" flavor, then
```
$ ghc-stage2 --interactive +RTS -hr
GHCi, version 8.7.20180905: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/omer/rcbackup/.ghci
λ:1> sequence_ (repl...To reproduce, build ghc using "prof" flavor, then
```
$ ghc-stage2 --interactive +RTS -hr
GHCi, version 8.7.20180905: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/omer/rcbackup/.ghci
λ:1> sequence_ (replicate 100000000 (return ()))
zsh: segmentation fault (core dumped) ghc-stage2 --interactive +RTS -hr
```
If I use debug runtime in stage2 compiler I can't even run the repl:
```
haskell $ ghc-stage2 --interactive +RTS -hr
rr: Saving execution to trace directory `/home/omer/.local/share/rr/ghc-stage2-13'.
GHCi, version 8.7.20180906: http://www.haskell.org/ghc/ :? for help
zsh: segmentation fault ghc-stage2 --interactive +RTS -hr
```8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15529runtime bug when profiling retainers2020-01-31T00:04:41ZPhilipperuntime bug when profiling retainersI have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:
```
stack clean
stack build
stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-p...I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:
```
stack clean
stack build
stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling
stack exec vfix -- +RTS -hr -sstderr
```
After the compilation messages i get the following error:
```
vfix: internal error: Invalid object *c in pop()
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Command terminated by signal 6
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runtime bug when profiling retainers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:\r\n\r\n\r\n{{{\r\nstack clean\r\nstack build\r\nstack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling\r\nstack exec vfix -- +RTS -hr -sstderr\r\n}}}\r\n\r\nAfter the compilation messages i get the following error:\r\n\r\n\r\n{{{\r\nvfix: internal error: Invalid object *c in pop()\r\n (GHC version 8.4.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nCommand terminated by signal 6\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15404ghc-8.6 uninstallable on macos due to hard coded libgmp directory2019-07-07T18:05:04ZTrevor L. McDonellghc-8.6 uninstallable on macos due to hard coded libgmp directoryIt is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.
See the offending...It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.
See the offending `LC_LOAD_DYLIB` command here:
```
$ jtool -l libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT
Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal)
Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs)
Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal)
Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals)
Mem: 0x0004df760-0x0004e0f40 __TEXT.__const
Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info
LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA
Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs)
Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs)
Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs)
Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs)
Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const
Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data
Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill)
LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT
LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
LC 04: LC_DYLD_INFO
LC 05: LC_SYMTAB
Symbol table is at offset 0x6a5348 (6968136), 118090 entries
String table is at offset 0x873d78 (8863096), 3241616 bytes
LC 06: LC_DYSYMTAB
81438 local symbols at index 0
35948 external symbols at index 81438
704 undefined symbols at index 117386
No TOC
No modtab
1380 Indirect symbols at offset 0x8727e8
LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA
LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0
LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0
LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib
LC 11: LC_LOAD_DYLIB @rpath/libHSinteger-gmp-1.0.2.0-ghc8.6.0.20180714.dylib
LC 12: LC_LOAD_DYLIB @rpath/libHSghc-prim-0.5.3-ghc8.6.0.20180714.dylib
LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib
LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib
LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0
LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3
LC 17: LC_RPATH @loader_path/../rts
LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions
LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348)
```
The other offenders are `libHSbinary` and `libHSinteger-gmp`.
Without changing these load commands, you'll get the following error:
```
$ ./configure --prefix=...
$ make install
<snip>
dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib
Referenced from: ./libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
Reason: image not found
make[1]: *** [install_packages] Abort trap: 6
make: *** [install] Error 2
```
I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help.
I guess this is just a packaging problem, but figured you should be aware before the official release...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-8.6 uninstallable on macos due to hard coded libgmp directory","status":"New","operating_system":"","component":"None","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.\r\n\r\nSee the offending `LC_LOAD_DYLIB` command here:\r\n\r\n{{{\r\n$ jtool -l libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\nLC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT\r\n Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal)\r\n Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs)\r\n Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal)\r\n Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals)\r\n Mem: 0x0004df760-0x0004e0f40 __TEXT.__const\r\n Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info\r\nLC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA\r\n Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs)\r\n Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs)\r\n Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs)\r\n Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs)\r\n Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const\r\n Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data\r\n Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill)\r\nLC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT\r\nLC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\nLC 04: LC_DYLD_INFO\r\nLC 05: LC_SYMTAB\r\n Symbol table is at offset 0x6a5348 (6968136), 118090 entries\r\n String table is at offset 0x873d78 (8863096), 3241616 bytes\r\nLC 06: LC_DYSYMTAB\r\n 81438 local symbols at index 0\r\n 35948 external symbols at index 81438\r\n 704 undefined symbols at index 117386\r\n No TOC\r\n No modtab\r\n 1380 Indirect symbols at offset 0x8727e8\r\n\r\nLC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA\r\nLC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0\r\nLC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0\r\nLC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib\r\nLC 11: LC_LOAD_DYLIB @rpath/libHSinteger-gmp-1.0.2.0-ghc8.6.0.20180714.dylib\r\nLC 12: LC_LOAD_DYLIB @rpath/libHSghc-prim-0.5.3-ghc8.6.0.20180714.dylib\r\nLC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib\r\nLC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib\r\nLC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0\r\nLC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3\r\nLC 17: LC_RPATH @loader_path/../rts\r\nLC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions\r\nLC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348)\r\n}}}\r\n\r\nThe other offenders are `libHSbinary` and `libHSinteger-gmp`.\r\n\r\nWithout changing these load commands, you'll get the following error:\r\n\r\n{{{\r\n$ ./configure --prefix=...\r\n$ make install\r\n<snip>\r\ndyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib\r\n Referenced from: ./libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\n Reason: image not found\r\nmake[1]: *** [install_packages] Abort trap: 6\r\nmake: *** [install] Error 2\r\n}}}\r\n\r\nI tried passing the `--with-gmp-libraries` option to `configure`, but that did not help.\r\n\r\nI guess this is just a packaging problem, but figured you should be aware before the official release...","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/152711e1000000000 :: Double yields 0.0 instead of Infinity2019-07-07T18:13:30Zclaude1e1000000000 :: Double yields 0.0 instead of Infinity(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd...(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64):
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e100000000 :: Double
Infinity
(5.70 secs, 68,552 bytes)
Prelude> 1e1000000000 :: Double
0.0
(69.35 secs, 60,088 bytes)
```
Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases.
More precisely,
```
Prelude> 1e646457008 :: Double
Infinity
(40.80 secs, 64,272 bytes)
Prelude> 1e646457009 :: Double
0.0
(40.46 secs, 60,088 bytes)
```
Note:
```hs
(floor $ 2^31 / logBase 2 10 + 16) == 646457009
```
This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?).
Standalone test program:
```hs
main = do
print 1e646457008
print 1e646457009
```
Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help).
```
$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e646457008 :: Double
Infinity
(415.26 secs, 17,908 bytes)
Prelude> 1e646457009 :: Double
Infinity
(417.66 secs, 17,820 bytes)
Prelude> 1e746457298 :: Double
Infinity
(490.00 secs, 17,820 bytes)
Prelude> 1e1000000000 :: Double
GNU MP: Cannot allocate memory (size=419438600)
Aborted
$
```
`ghci-8.0.2` on Debian Buster amd64 exhibits the problem also.8.6.3Zhou FangyiZhou Fangyi