GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:04:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15504-XStrict doesn't prevent warnings from -Wunbanged-strict-patterns2019-07-07T18:04:27ZChaiTRex-XStrict doesn't prevent warnings from -Wunbanged-strict-patternsI'm using:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.3
```
I was under the impression that [-XStrict](https://ghc.haskell.org/trac/ghc/wiki/StrictPragma#Strict) automatically included outermost ba...I'm using:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.3
```
I was under the impression that [-XStrict](https://ghc.haskell.org/trac/ghc/wiki/StrictPragma#Strict) automatically included outermost bang patterns, but either that isn't always the case or [-Wunbanged-strict-patterns](https://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wunbanged-strict-patterns) doesn't know that `-XStrict` did its job correctly:
```hs
{-# OPTIONS_GHC -Wunbanged-strict-patterns #-}
{-# LANGUAGE BangPatterns, MagicHash, Strict, UnboxedTuples #-}
module Example where
import GHC.Exts (Int(I#), quotRemInt#)
lastDigit :: Int -> Int
lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10#
in I# r
```
compiles with a warning:
```
[1 of 1] Compiling Example ( Example.hs, Example.o )
Example.hs:9:24: warning: [-Wunbanged-strict-patterns]
Pattern bindings containing unlifted types should use
an outermost bang pattern:
(# q, r #) = quotRemInt# x 10#
|
9 | lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10#
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
<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":"-XStrict doesn't prevent warnings from -Wunbanged-strict-patterns","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'm using:\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.4.3\r\n}}}\r\n\r\nI was under the impression that [https://ghc.haskell.org/trac/ghc/wiki/StrictPragma#Strict -XStrict] automatically included outermost bang patterns, but either that isn't always the case or [https://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc-flag--Wunbanged-strict-patterns -Wunbanged-strict-patterns] doesn't know that `-XStrict` did its job correctly:\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wunbanged-strict-patterns #-}\r\n{-# LANGUAGE BangPatterns, MagicHash, Strict, UnboxedTuples #-}\r\n\r\nmodule Example where\r\n\r\nimport GHC.Exts (Int(I#), quotRemInt#)\r\n\r\nlastDigit :: Int -> Int\r\nlastDigit (I# x) = let (# q, r #) = quotRemInt# x 10#\r\n in I# r\r\n}}}\r\n\r\ncompiles with a warning:\r\n\r\n{{{\r\n[1 of 1] Compiling Example ( Example.hs, Example.o )\r\n\r\nExample.hs:9:24: warning: [-Wunbanged-strict-patterns]\r\n Pattern bindings containing unlifted types should use\r\n an outermost bang pattern:\r\n (# q, r #) = quotRemInt# x 10#\r\n |\r\n9 | lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10#\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15502-ddump-splices truncates Integer literals to Int literals2019-07-14T05:09:54ZChaiTRex-ddump-splices truncates Integer literals to Int literalsI trusted that the splice results shown by `-ddump-splices` were correct. They weren't, which caused me to waste a lot of time debugging my Template Haskell expressions when they were already correct.
```
$ ghc --version
The Glorious Gl...I trusted that the splice results shown by `-ddump-splices` were correct. They weren't, which caused me to waste a lot of time debugging my Template Haskell expressions when they were already correct.
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.3
```
## Example program
```hs
{-# OPTIONS_GHC -ddump-splices #-}
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Language.Haskell.TH.Syntax (Lift(lift))
main = print ( $( lift (toInteger (maxBound :: Int) + 1) )
, $( lift (minBound :: Int) )
)
```
## Output of `runghc`
Note that the output of the program on the bottom line below is correct. The two splice results shown by `-ddump-splices` incorrectly match each other:
```
Example.hs:8:19-56: Splicing expression
lift (toInteger (maxBound :: Int) + 1) ======> -9223372036854775808
Example.hs:9:19-40: Splicing expression
lift (minBound :: Int) ======> (-9223372036854775808)
(9223372036854775808,-9223372036854775808)
```
<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":"-ddump-splices truncates Integer literals to Int literals","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 trusted that the splice results shown by `-ddump-splices` were correct. They weren't, which caused me to waste a lot of time debugging my Template Haskell expressions when they were already correct.\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.4.3\r\n}}}\r\n\r\n== Example program ==\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule Main where\r\n\r\nimport Language.Haskell.TH.Syntax (Lift(lift))\r\n\r\nmain = print ( $( lift (toInteger (maxBound :: Int) + 1) )\r\n , $( lift (minBound :: Int) )\r\n )\r\n}}}\r\n\r\n== Output of `runghc` ==\r\n\r\nNote that the output of the program on the bottom line below is correct. The two splice results shown by `-ddump-splices` incorrectly match each other:\r\n\r\n{{{\r\nExample.hs:8:19-56: Splicing expression\r\n lift (toInteger (maxBound :: Int) + 1) ======> -9223372036854775808\r\nExample.hs:9:19-40: Splicing expression\r\n lift (minBound :: Int) ======> (-9223372036854775808)\r\n(9223372036854775808,-9223372036854775808)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15500internal error: Unable to commit 1048576 bytes of memory. Deepseq2019-08-08T06:42:52Zalxdbinternal error: Unable to commit 1048576 bytes of memory. Deepseqthe following code is a (nearly) minimal working example that causes the aforementioned internal error.
```hs
module Main where
import Control.DeepSeq
myfunc :: Int -> Int
myfunc x = sum . take x $ [0..]
logiter :: (NFData ...the following code is a (nearly) minimal working example that causes the aforementioned internal error.
```hs
module Main where
import Control.DeepSeq
myfunc :: Int -> Int
myfunc x = sum . take x $ [0..]
logiter :: (NFData a) => Int -> (a -> a) -> a -> IO a
logiter iter f x
| iter >= 0 = do
let y = f x
deepseq y print $ "iter " ++ show iter
if iter == 0 then return y else logiter (iter - 1) f y
| otherwise = error "no negative iter!"
main :: IO ()
main = do
print "start"
print . show $ myfunc 2000000
print "done"
print "start"
res <- logiter 5 myfunc 2000000
print "done"
print . show $ res
```
Perhaps this is an issue with deepseq, however it the message does say to come and report the bug, so that's what I'm doing.
<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":"internal error: Unable to commit 1048576 bytes of memory. Deepseq","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["deepseq","memory"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the following code is a (nearly) minimal working example that causes the aforementioned internal error.\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport Control.DeepSeq\r\n\r\nmyfunc :: Int -> Int\r\nmyfunc x = sum . take x $ [0..]\r\n\r\nlogiter :: (NFData a) => Int -> (a -> a) -> a -> IO a\r\nlogiter iter f x\r\n | iter >= 0 = do\r\n let y = f x\r\n deepseq y print $ \"iter \" ++ show iter\r\n if iter == 0 then return y else logiter (iter - 1) f y\r\n | otherwise = error \"no negative iter!\"\r\n\r\nmain :: IO ()\r\nmain = do\r\n print \"start\"\r\n print . show $ myfunc 2000000\r\n print \"done\"\r\n print \"start\"\r\n res <- logiter 5 myfunc 2000000\r\n print \"done\"\r\n print . show $ res\r\n\r\n}}}\r\n\r\nPerhaps this is an issue with deepseq, however it the message does say to come and report the bug, so that's what I'm doing.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15498HPC: do notation marks () as non-covered2019-07-07T18:04:29Ztom-bopHPC: do notation marks () as non-coveredWith this Main.hs, the "()" in "pure ()" is marked by HPC as a non-covered expression:
```hs
foo :: IO ()
foo = do
_ <- putStrLn "Unimportant string"
pure ()
main :: IO ()
main = do
foo
putStrLn "Unimportant #2"
```
Repro:...With this Main.hs, the "()" in "pure ()" is marked by HPC as a non-covered expression:
```hs
foo :: IO ()
foo = do
_ <- putStrLn "Unimportant string"
pure ()
main :: IO ()
main = do
foo
putStrLn "Unimportant #2"
```
Repro:
> - `ghc -fhpc Main.hs`
> - `./Main`
> - `hpc markup Main.tix`
This is an admittedly small issue, but it can be valuable for a project to aspire to 100% code coverage and false negatives prevent us from getting there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC: do notation marks () as non-covered","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With this Main.hs, the \"()\" in \"pure ()\" is marked by HPC as a non-covered expression:\r\n\r\n{{{#!hs\r\nfoo :: IO ()\r\nfoo = do\r\n _ <- putStrLn \"Unimportant string\"\r\n pure ()\r\n\r\nmain :: IO ()\r\nmain = do\r\n foo\r\n putStrLn \"Unimportant #2\"\r\n}}}\r\n\r\nRepro:\r\n - `ghc -fhpc Main.hs`\r\n - `./Main`\r\n - `hpc markup Main.tix`\r\n\r\nThis is an admittedly small issue, but it can be valuable for a project to aspire to 100% code coverage and false negatives prevent us from getting there.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15496if a variable that isn't in scope is used and main is not defined ghc freaks out2019-07-07T18:04:29ZkuhnsBif a variable that isn't in scope is used and main is not defined ghc freaks out--y = 5::Double
f::Double -\>Double
f x = x+y
--main = print 5
produces:
ghc: panic! (the 'impossible' happened)
> (GHC version 8.0.2 for x86_64-unknown-linux):
initTc: unsolved constraints
> WC {wc_insol = \[W\] y_axB :: t_axA\...--y = 5::Double
f::Double -\>Double
f x = x+y
--main = print 5
produces:
ghc: panic! (the 'impossible' happened)
> (GHC version 8.0.2 for x86_64-unknown-linux):
initTc: unsolved constraints
> WC {wc_insol = \[W\] y_axB :: t_axA\[tau:1\] (CHoleCan: y)}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
un-commenting either line 1 or 4 causes ghc to identify the other problem correctly
<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":"if a variable that isn't in scope is used and main is not defined ghc freaks out","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":"--y = 5::Double\r\n\r\nf::Double ->Double\r\n\r\nf x = x+y\r\n\r\n--main = print 5\r\n\r\nproduces:\r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n\tinitTc: unsolved constraints\r\n WC {wc_insol = [W] y_axB :: t_axA[tau:1] (CHoleCan: y)}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nun-commenting either line 1 or 4 causes ghc to identify the other problem correctly","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15494Cannot install GHC through stack on NixOS2021-04-01T11:25:27ZStefanovCannot install GHC through stack on NixOSstack setup gives me this error:
```
# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.
# For some reason, this means the DLLs end ...stack setup gives me this error:
```
# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.
# For some reason, this means the DLLs end up non-executable, which means
# executables that use them just segfault.
Error: Error encountered while installing GHC with
make install
run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/
```
Possibly a domain-specific problem,caused by NixOS's file management.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15493Elide empty dictionaries2021-10-04T13:56:07ZmnoonanElide empty dictionariesSuppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use...Suppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use sites, calls to `f` will be replaced with calls to an inner function that skips the typeclass dictionary. But can I count on this optimization always working?
Would it possible to get a guarantee that the `C =>` constraint will have no run-time overhead, by dropping it entirely from the generated Core? Or is there a subtlety that prevents this from being sound?
For context, I would like to implicitly pass compile-time evidence that various properties hold (e.g. such-and-such a list is non-empty), while retaining a guarantee that the evidence will have no run-time cost. Like this:
```
newtype Named a name = Named a
class Fact p
-- Ideally, we'd have a guarantee that the following function
-- compiles to exactly the same code as `Prelude.head`
head :: Fact (IsCons xs) => ([a] `Named` xs) -> a
head xs = Prelude.head (coerce xs)
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15492Plugin recompilation check fails when profiling is enabled2019-07-07T18:04:30ZMatthew PickeringPlugin recompilation check fails when profiling is enabledWhen compiling with profiling enabled and using a plugin, GHC will panic as follows:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: no dylibs
GraphMod
Call...When compiling with profiling enabled and using a plugin, GHC will panic as follows:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: no dylibs
GraphMod
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage
```
Investigating determines that the following paths are being inspected:
```
/nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod-plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
/nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so
```
None of which exist.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugin recompilation check fails when profiling is enabled","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":"When compiling with profiling enabled and using a plugin, GHC will panic as follows:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.1.20180803 for x86_64-unknown-linux):\r\n mkPluginUsage: no dylibs\r\n GraphMod\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage\r\n}}}\r\n\r\nInvestigating determines that the following paths are being inspected:\r\n\r\n{{{\r\n/nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod-plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n\r\n/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n\r\n/nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so\r\n}}}\r\n\r\nNone of which exist.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15491No control over synopsis in Library Documentation2019-07-07T18:04:30Zh001No control over synopsis in Library DocumentationYou can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.
<details><summary>Trac metadata</summary>
| Trac field | Value...You can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No control over synopsis in Library Documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15490Can Template Haskell and RULES be combined?2019-07-07T18:04:30ZChaiTRexCan Template Haskell and RULES be combined?It would be nice if there was something like this:
```hs
{-# RULES
"(literal*)" forall n.
(n*) = $( makeOptimizedMultiplication [|| n ||] ) #-}
```
where `makeOptimizedMultiplication` is a Template Haskell function that, if...It would be nice if there was something like this:
```hs
{-# RULES
"(literal*)" forall n.
(n*) = $( makeOptimizedMultiplication [|| n ||] ) #-}
```
where `makeOptimizedMultiplication` is a Template Haskell function that, if `n` is an integer literal, produces an optimized multiplication function for that literal. However, that code above gives a `VarE` corresponding to the `n` in the quoter rather than the AST of the `n` that's actually being matched by the rewrite rule, so I can't get a `LitE` that way.
This sort of thing would come in very handy for a large fixed-width integer type, because I don't think GHC and LLVM will know that standard fixed-width integer optimizations apply to it. For example, with a `Word65536` type, multiplying blindly at runtime by the literal `1099511627777` requires a lot of extra work. At the very least, all 65536 bits of that literal have to be read and dealt with pretty blindly.
However, at compile time, the compiler can take the time to figure out that `(1099511627777*)` can be replaced with the much, much lighter `(\x -> shiftL x 40 + x)` (and not only that, but if `Word65536`s are stored in a byte array, 1 byte evenly divides the shift amount of 40 bits, which can be exploited to speed things up greatly). With appropriate `RULES` and Template Haskell functions, the compiler gains the ability to apply lots of fixed-width integer optimizations.
Since the above sort of code doesn't work, is there some other way to do this that I don't know about? If not, can the feature be added?
----
The only downside I can think of is that the user of the `Word65536` type might not knowingly be expecting Template Haskell to be at work since they didn't use any splices or quoters and might not have even included `{-# LANGUAGE TemplateHaskell #-}` in their code, so perhaps some easy method of consenting to the application of TH-based rewrites might be in order.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can Template Haskell and RULES be combined?","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":"FeatureRequest","description":"It would be nice if there was something like this:\r\n\r\n{{{#!hs\r\n{-# RULES\r\n \"(literal*)\" forall n.\r\n (n*) = $( makeOptimizedMultiplication [|| n ||] ) #-}\r\n}}}\r\n\r\nwhere `makeOptimizedMultiplication` is a Template Haskell function that, if `n` is an integer literal, produces an optimized multiplication function for that literal. However, that code above gives a `VarE` corresponding to the `n` in the quoter rather than the AST of the `n` that's actually being matched by the rewrite rule, so I can't get a `LitE` that way.\r\n\r\nThis sort of thing would come in very handy for a large fixed-width integer type, because I don't think GHC and LLVM will know that standard fixed-width integer optimizations apply to it. For example, with a `Word65536` type, multiplying blindly at runtime by the literal `1099511627777` requires a lot of extra work. At the very least, all 65536 bits of that literal have to be read and dealt with pretty blindly.\r\n\r\nHowever, at compile time, the compiler can take the time to figure out that `(1099511627777*)` can be replaced with the much, much lighter `(\\x -> shiftL x 40 + x)` (and not only that, but if `Word65536`s are stored in a byte array, 1 byte evenly divides the shift amount of 40 bits, which can be exploited to speed things up greatly). With appropriate `RULES` and Template Haskell functions, the compiler gains the ability to apply lots of fixed-width integer optimizations.\r\n\r\nSince the above sort of code doesn't work, is there some other way to do this that I don't know about? If not, can the feature be added?\r\n\r\n----\r\n\r\nThe only downside I can think of is that the user of the `Word65536` type might not knowingly be expecting Template Haskell to be at work since they didn't use any splices or quoters and might not have even included `{-# LANGUAGE TemplateHaskell #-}` in their code, so perhaps some easy method of consenting to the application of TH-based rewrites might be in order.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15487"Ambiguos occurrence" error message uses strange qualification2019-07-07T18:04:31Zwaldmann@imn.htwk-leipzig.de"Ambiguos occurrence" error message uses strange qualificationThe following text produces an error message that I find somewhat confusing. This issue is just about the wording of the message.
```hs
module A (null) where { }
module B where { import qualified A ; null = 42 ; main = null }
```
when ...The following text produces an error message that I find somewhat confusing. This issue is just about the wording of the message.
```hs
module A (null) where { }
module B where { import qualified A ; null = 42 ; main = null }
```
when I load `B` in ghci, I get
```
B.hs:1:58: error:
Ambiguous occurrence ‘null’
It could refer to either ‘A.null’,
imported from ‘Prelude’ at B.hs:1:8
(and originally defined in ‘Data.Foldable’)
or ‘B.null’, defined at B.hs:1:39
```
I think ".. could refer to A.null" looks strange.
I would expect `Prelude.null` here, which I do get when I remove "import qualified A" from the text of `B`.
<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":"\"Ambiguos occurrence\" error message uses strange qualification","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":"The following text produces an error message that I find somewhat confusing. This issue is just about the wording of the message.\r\n\r\n{{{#!hs\r\nmodule A (null) where { }\r\nmodule B where { import qualified A ; null = 42 ; main = null }\r\n}}}\r\nwhen I load `B` in ghci, I get\r\n{{{\r\nB.hs:1:58: error:\r\n Ambiguous occurrence ‘null’\r\n It could refer to either ‘A.null’,\r\n imported from ‘Prelude’ at B.hs:1:8\r\n (and originally defined in ‘Data.Foldable’)\r\n or ‘B.null’, defined at B.hs:1:39\r\n}}}\r\nI think \".. could refer to A.null\" looks strange.\r\nI would expect `Prelude.null` here, which I do get when I remove \"import qualified A\" from the text of `B`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15486primops.txt.pp still has support for WORD_SIZE_IN_BITS < 322019-07-07T18:04:31ZChaiTRexprimops.txt.pp still has support for WORD_SIZE_IN_BITS < 32Was support for `WORD_SIZE_IN_BITS < 32` dropped? According to [this GHC commit](https://github.com/ghc/ghc/commit/b38f08350d5c0efaa613f2f6c67dad5366aac271), it appears that that support was dropped about seven years ago. Also, `find -ty...Was support for `WORD_SIZE_IN_BITS < 32` dropped? According to [this GHC commit](https://github.com/ghc/ghc/commit/b38f08350d5c0efaa613f2f6c67dad5366aac271), it appears that that support was dropped about seven years ago. Also, `find -type f | xargs -n 5 egrep 'WORD_SIZE_IN_BITS\s*<\s*32'` only finds mention of it in `primops.txt.pp`.
If support for that was dropped, [the current version of compiler/prelude/primops.txt.pp](https://github.com/ghc/ghc/blob/9897f6783a58265d5eaef5fb06f04320c7737e87/compiler/prelude/primops.txt.pp) has dead code and misleading documentation (that's apparently propagated to [GHC.Prim documentation](https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html)) that might cause programmers to expend unnecessary effort supporting `WORD_SIZE_IN_BITS < 32` in their own code.
The following documentation describes a situation that can no longer happen and continues on incorrectly past these two paragraphs:
> Haskell98 specifies that signed integers (type `Int` must contain at least 30 bits. GHC always implements `Int` using the primitive type `Int#`, whose size equals the `MachDeps.h` constant `WORD_SIZE_IN_BITS`.
>
> This is normally set based on the `config.h` parameter `SIZEOF_HSWORD`, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, **but 30 or 31-bit code can be exported as an external core file for use in other back ends**.
The following is dead code. Further, `INT32` and `WORD32` throughout the document should be replaced with `Int#` and `Word#`:
```c
#if WORD_SIZE_IN_BITS < 32
#define INT32 Int32#
#define WORD32 Word32#
#else
#define INT32 Int#
#define WORD32 Word#
#endif
```
Also, all code inclusively between `#if WORD_SIZE_IN_BITS < 32` lines and their matching `#endif`s can be eliminated.
----
On the other hand, if `WORD_SIZE_IN_BITS < 32` **is** still supported, there are a lot of cases wherein a 64-bit version of an instruction uses `INT64` or `WORD64` in its type signature, but the 32-bit version uses `Int#` or `Word#`, which robs programmers of the ability to use speedy hardware instructions on full untagged `Int32#`s or `Word32#`s. Also, the `Double#` decoder to two `Word#`s for the mantissa assumes that the `Word#`s can hold a full 32 bits according to its documentation. There are some other problems that I've forgotten as well.
<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 | tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32","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":["tibbe"],"type":"Bug","description":"Was support for `WORD_SIZE_IN_BITS < 32` dropped? According to [https://github.com/ghc/ghc/commit/b38f08350d5c0efaa613f2f6c67dad5366aac271 this GHC commit], it appears that that support was dropped about seven years ago. Also, `find -type f | xargs -n 5 egrep 'WORD_SIZE_IN_BITS\\s*<\\s*32'` only finds mention of it in `primops.txt.pp`.\r\n\r\nIf support for that was dropped, [https://github.com/ghc/ghc/blob/9897f6783a58265d5eaef5fb06f04320c7737e87/compiler/prelude/primops.txt.pp the current version of compiler/prelude/primops.txt.pp] has dead code and misleading documentation (that's apparently propagated to [https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html GHC.Prim documentation]) that might cause programmers to expend unnecessary effort supporting `WORD_SIZE_IN_BITS < 32` in their own code.\r\n\r\nThe following documentation describes a situation that can no longer happen and continues on incorrectly past these two paragraphs:\r\n\r\n>Haskell98 specifies that signed integers (type `Int` must contain at least 30 bits. GHC always implements `Int` using the primitive type `Int#`, whose size equals the `MachDeps.h` constant `WORD_SIZE_IN_BITS`.\r\n>\r\n>This is normally set based on the `config.h` parameter `SIZEOF_HSWORD`, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, '''but 30 or 31-bit code can be exported as an external core file for use in other back ends'''.\r\n\r\nThe following is dead code. Further, `INT32` and `WORD32` throughout the document should be replaced with `Int#` and `Word#`:\r\n\r\n{{{#!c\r\n#if WORD_SIZE_IN_BITS < 32\r\n#define INT32 Int32#\r\n#define WORD32 Word32#\r\n#else\r\n#define INT32 Int#\r\n#define WORD32 Word#\r\n#endif\r\n}}}\r\n\r\nAlso, all code inclusively between `#if WORD_SIZE_IN_BITS < 32` lines and their matching `#endif`s can be eliminated.\r\n\r\n----\r\n\r\nOn the other hand, if `WORD_SIZE_IN_BITS < 32` '''is''' still supported, there are a lot of cases wherein a 64-bit version of an instruction uses `INT64` or `WORD64` in its type signature, but the 32-bit version uses `Int#` or `Word#`, which robs programmers of the ability to use speedy hardware instructions on full untagged `Int32#`s or `Word32#`s. Also, the `Double#` decoder to two `Word#`s for the mantissa assumes that the `Word#`s can hold a full 32 bits according to its documentation. There are some other problems that I've forgotten as well.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15485GHC uses 300% CPU when calling into blocking C call2023-12-01T13:50:01ZoconnoreGHC uses 300% CPU when calling into blocking C callHello,
I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:
```hs
lockPwd f = bracket main recover (\_ -> f)
where
mode = unionFileModes ownerReadMode ownerWriteMode
...Hello,
I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:
```hs
lockPwd f = bracket main recover (\_ -> f)
where
mode = unionFileModes ownerReadMode ownerWriteMode
main = do
fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags
putStrLn "waiting to set lock"
waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0)
putStrLn "got lock"
return fd
recover = flip setLock (Unlock, AbsoluteSeek, 0, 0)
```
When I run it, my fans go wild, and CPU usage hits 300%.
/u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/
> Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket.
Maybe an argument could be made that this waitToSetLock call should be converted to be [interruptible](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#interruptible-foreign-calls), but it also seems like I should be able to make my haskell program block patiently if I want it to.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| 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":"GHC uses 300% CPU when calling into blocking C call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nI'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this:\r\n\r\n{{{#!hs\r\nlockPwd f = bracket main recover (\\_ -> f)\r\n where\r\n mode = unionFileModes ownerReadMode ownerWriteMode\r\n main = do\r\n fd <- openFd \"/etc/.pwd.lock\" WriteOnly (Just mode) defaultFileFlags\r\n putStrLn \"waiting to set lock\"\r\n waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0)\r\n putStrLn \"got lock\"\r\n return fd\r\n recover = flip setLock (Unlock, AbsoluteSeek, 0, 0)\r\n}}}\r\n\r\nWhen I run it, my fans go wild, and CPU usage hits 300%.\r\n\r\n/u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/\r\n\r\n> Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is \"descheduled\" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket.\r\n\r\nMaybe an argument could be made that this waitToSetLock call should be converted to be [[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#interruptible-foreign-calls|interruptible]], but it also seems like I should be able to make my haskell program block patiently if I want it to. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15482the_gc_thread variable from GC.c is not aligned to 642019-07-07T18:04:32ZGleb Popovthe_gc_thread variable from GC.c is not aligned to 64When compiling GHC with clang and -march=native flag, the compiler emits vmovaps instruction with unaligned operand for this code:
```
* thread #1, name = 'ghc-pkg', stop reason = signal SIGBUS: hardware error
frame #0: 0x0000000804...When compiling GHC with clang and -march=native flag, the compiler emits vmovaps instruction with unaligned operand for this code:
```
* thread #1, name = 'ghc-pkg', stop reason = signal SIGBUS: hardware error
frame #0: 0x0000000804e476c6 libHSrts-ghc8.0.2.so`initGcThreads [inlined] new_gc_thread(n=0) at GC.c:818
815 ws->todo_q = newWSDeque(128);
816 ws->todo_overflow = NULL;
817 ws->n_todo_overflow = 0;
-> 818 ws->todo_large_objects = NULL;
819
820 ws->part_list = NULL;
821 ws->n_part_blocks = 0;
```
Research done by another FreeBSD developer suggested that this is due
```
StgWord8 the_gc_thread[sizeof(gc_thread) + 64 * sizeof(gen_workspace)];
```
not being aligned to 64 bytes, because struct gc_thread have no alignment specifier.
Detailed information can be found in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226059
<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":"the_gc_thread variable from GC.c is not aligned to 64","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":"When compiling GHC with clang and -march=native flag, the compiler emits vmovaps instruction with unaligned operand for this code:\r\n\r\n\r\n{{{\r\n* thread #1, name = 'ghc-pkg', stop reason = signal SIGBUS: hardware error\r\n frame #0: 0x0000000804e476c6 libHSrts-ghc8.0.2.so`initGcThreads [inlined] new_gc_thread(n=0) at GC.c:818\r\n 815 ws->todo_q = newWSDeque(128);\r\n 816 ws->todo_overflow = NULL;\r\n 817 ws->n_todo_overflow = 0;\r\n-> 818 ws->todo_large_objects = NULL;\r\n 819 \r\n 820 ws->part_list = NULL;\r\n 821 ws->n_part_blocks = 0;\r\n}}}\r\n\r\n\r\nResearch done by another FreeBSD developer suggested that this is due\r\n\r\n{{{\r\n\r\nStgWord8 the_gc_thread[sizeof(gc_thread) + 64 * sizeof(gen_workspace)];\r\n}}}\r\n\r\n\r\nnot being aligned to 64 bytes, because struct gc_thread have no alignment specifier.\r\n\r\nDetailed information can be found in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226059","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15475Plugin recompilation check still panics2019-07-07T18:04:34ZMatthew PickeringPlugin recompilation check still panicsI get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch.
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPlugin...I get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch.
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1.20180803 for x86_64-unknown-linux):
mkPluginUsage: file not found
LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
My example is nixified and not very minimal but I can provide it tomorrow if that would help.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugin recompilation check still panics","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 get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch. \r\n\r\n{{{\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.1.20180803 for x86_64-unknown-linux):\r\n\tmkPluginUsage: file not found\r\n LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nMy example is nixified and not very minimal but I can provide it tomorrow if that would help.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15473GHC 8.6+ loops infinitely on an UndecidableInstances error message2019-07-07T18:04:35ZRyan ScottGHC 8.6+ loops infinitely on an UndecidableInstances error messageThis regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:
``...This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
-- {-# LANGUAGE UndecidableInstances #-}
module Bug where
type family Undefined :: k where {}
type family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where
LetInterleave xs t ts is y z = Undefined y z
```
You'll get this far:
```
$ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error:
• Variables ‘a, a’ occur more often
in the type family application
```
Before GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.)
Interestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.6+ loops infinitely on an UndecidableInstances error message","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n-- {-# LANGUAGE UndecidableInstances #-}\r\nmodule Bug where\r\n\r\ntype family Undefined :: k where {}\r\n\r\ntype family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where\r\n LetInterleave xs t ts is y z = Undefined y z\r\n}}}\r\n\r\nYou'll get this far:\r\n\r\n{{{\r\n$ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:11:3: error:\r\n • Variables ‘a, a’ occur more often\r\n in the type family application\r\n}}}\r\n\r\nBefore GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.)\r\n\r\nInterestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15469Validation doesn't play nicely on a shared computer2019-07-07T18:04:36ZRichard Eisenbergrae@richarde.devValidation doesn't play nicely on a shared computerIn my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite ...In my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite are library tests. These end up in a `libraries` directory, accessed with prefixes like `../../libraries/xyz`. That is, the `libraries` directory ends up to be `/tmp/libraries`. The problem is that I share this Linux server with my students, who are also attempting to run validation. After the occasional cleanout of `/tmp`, whoever validates first creates the `/tmp/libraries` directory and then owns that directory -- anyone else who tries to validate gets permission errors until the next cleanout of `tmp`.
Even with the presumably quick fix of changing the permissions on `libraries`, the very use of that folder means that two people cannot validate simultaneously on the same machine.
Can we fix this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Validation doesn't play nicely on a shared computer","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite are library tests. These end up in a `libraries` directory, accessed with prefixes like `../../libraries/xyz`. That is, the `libraries` directory ends up to be `/tmp/libraries`. The problem is that I share this Linux server with my students, who are also attempting to run validation. After the occasional cleanout of `/tmp`, whoever validates first creates the `/tmp/libraries` directory and then owns that directory -- anyone else who tries to validate gets permission errors until the next cleanout of `tmp`.\r\n\r\nEven with the presumably quick fix of changing the permissions on `libraries`, the very use of that folder means that two people cannot validate simultaneously on the same machine.\r\n\r\nCan we fix this?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/15458Misleading error message on mising BangPatterns extension2019-07-07T18:04:46ZSergey VinokurovMisleading error message on mising BangPatterns extensionFor following program I'm getting an unexpected error message.
```hs
foo :: Int -> Int
foo = bar
where
bar :: Int -> Int
bar !i = i
```
```
$ ghc -o Test Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Test.h...For following program I'm getting an unexpected error message.
```hs
foo :: Int -> Int
foo = bar
where
bar :: Int -> Int
bar !i = i
```
```
$ ghc -o Test Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Test.hs:4:5: error:
The type signature for ‘bar’ lacks an accompanying binding
|
4 | bar :: Int -> Int
| ^^^
```
Enabling `-XBangPatterns` fixes the issue but I wanted the compiler to suggest me to enable it:
```
$ ghc -XBangPatterns -o Test Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Test.hs:1:1: error:
The IO action ‘main’ is not defined in module ‘Main’
|
1 | foo :: Int -> Int
| ^
```
<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":"Misleading error message on mising BangPatterns extension","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":"For following program I'm getting an unexpected error message.\r\n\r\n{{{#!hs\r\nfoo :: Int -> Int\r\nfoo = bar\r\n where\r\n bar :: Int -> Int\r\n bar !i = i\r\n}}}\r\n\r\n{{{\r\n$ ghc -o Test Test.hs\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\n\r\nTest.hs:4:5: error:\r\n The type signature for ‘bar’ lacks an accompanying binding\r\n |\r\n4 | bar :: Int -> Int\r\n | ^^^\r\n}}}\r\n\r\nEnabling `-XBangPatterns` fixes the issue but I wanted the compiler to suggest me to enable it:\r\n{{{\r\n$ ghc -XBangPatterns -o Test Test.hs\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\n\r\nTest.hs:1:1: error:\r\n The IO action ‘main’ is not defined in module ‘Main’\r\n |\r\n1 | foo :: Int -> Int\r\n | ^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15456(ImplicitParams) Allow ? in binding patterns2019-07-07T18:04:49ZWelperooni(ImplicitParams) Allow ? in binding patternsThis is mostly useful when dealing with ImplicitParams. Suppose "foo" takes an implicit parameter "?msg"
```hs
-- Invalid, parse error in pattern ?msg
bar ?msg = foo
\?msg -> foo
-- With -XViewPatterns, same issue
bar ( ... -> ?msg) = ...This is mostly useful when dealing with ImplicitParams. Suppose "foo" takes an implicit parameter "?msg"
```hs
-- Invalid, parse error in pattern ?msg
bar ?msg = foo
\?msg -> foo
-- With -XViewPatterns, same issue
bar ( ... -> ?msg) = foo
```
Instead, you are forced to create a local let binding
```hs
bar msg = let ?msg = msg in foo
\msg -> let ?msg = msg in foo
bar ( ... -> msg) = let ?msg = msg in foo
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"(ImplicitParams) Allow ? in binding patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["ImplicitParams"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is mostly useful when dealing with ImplicitParams. Suppose \"foo\" takes an implicit parameter \"?msg\"\r\n{{{#!hs\r\n-- Invalid, parse error in pattern ?msg\r\nbar ?msg = foo\r\n\\?msg -> foo\r\n\r\n-- With -XViewPatterns, same issue\r\nbar ( ... -> ?msg) = foo\r\n}}}\r\n\r\nInstead, you are forced to create a local let binding\r\n{{{#!hs\r\nbar msg = let ?msg = msg in foo\r\n\\msg -> let ?msg = msg in foo\r\n\r\nbar ( ... -> msg) = let ?msg = msg in foo\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15453Bug in opt_trans_rule in OptCoercion2019-07-07T18:04:49ZNingning XieBug in opt_trans_rule in OptCoercionThe ForAllCo case in the definition of opt_trans_rule in OptCoercion is not right:
```hs
push_trans tv1 eta1 r1 tv2 eta2 r2
= fireTransRule "EtaAllTy" co1 co2 $
mkForAllCo tv1 (opt_trans is eta1 eta2) (opt_trans is' r1 r2')
...The ForAllCo case in the definition of opt_trans_rule in OptCoercion is not right:
```hs
push_trans tv1 eta1 r1 tv2 eta2 r2
= fireTransRule "EtaAllTy" co1 co2 $
mkForAllCo tv1 (opt_trans is eta1 eta2) (opt_trans is' r1 r2')
where
is' = is `extendInScopeSet` tv1
r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded!
```
Given `co1;co2`, where
```hs
co1 = \/ tv1 : eta1. r1
co2 = \/ tv2 : eta2. r2
```
We would like optimize the transitivity coercion. I think what we want is
```hs
\/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1])
```
Namely it should be
```hs
r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2
```
If there is any program that could hit the bug it would be better, as we can add it to test cases.
<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":"Bug in opt_trans_rule in OptCoercion","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":"The ForAllCo case in the definition of opt_trans_rule in OptCoercion is not right:\r\n\r\n{{{#!hs\r\n push_trans tv1 eta1 r1 tv2 eta2 r2\r\n = fireTransRule \"EtaAllTy\" co1 co2 $\r\n mkForAllCo tv1 (opt_trans is eta1 eta2) (opt_trans is' r1 r2')\r\n where\r\n is' = is `extendInScopeSet` tv1\r\n r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded!\r\n}}}\r\n\r\nGiven {{{co1;co2}}}, where\r\n\r\n{{{#!hs\r\n co1 = \\/ tv1 : eta1. r1\r\n co2 = \\/ tv2 : eta2. r2\r\n}}}\r\n\r\nWe would like optimize the transitivity coercion. I think what we want is\r\n\r\n{{{#!hs\r\n\\/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1])\r\n}}}\r\n\r\nNamely it should be\r\n\r\n{{{#!hs\r\nr2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2\r\n}}}\r\n\r\nIf there is any program that could hit the bug it would be better, as we can add it to test cases.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ningning XieNingning Xie