GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:42:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8878Export runTcInteractive from TcRnDriver2019-07-07T18:42:59ZholzenspExport runTcInteractive from TcRnDriverFor people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single...For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes.
(patch to follow shortly)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Export runTcInteractive from TcRnDriver","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes.\r\n\r\n(patch to follow shortly)","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1holzenspholzensphttps://gitlab.haskell.org/ghc/ghc/-/issues/8841PatternSynonyms error gives wrong source locations2019-07-07T18:43:08ZIcelandjackPatternSynonyms error gives wrong source locationsUsing an example from the [GHC user's guide](http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax-extns.html) but omitting the argument to `Maybe`
```
{-# LANGUAGE PatternSynonyms #-}
data Type = App String [Type]
pattern...Using an example from the [GHC user's guide](http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax-extns.html) but omitting the argument to `Maybe`
```
{-# LANGUAGE PatternSynonyms #-}
data Type = App String [Type]
pattern Maybe = App "Maybe" [t]
```
gives the following error without the correct source locations
```
ghci> :load /tmp/failure.hs
[1 of 1] Compiling Main ( /tmp/failure.hs, interpreted )
/tmp/failure.hs:1:1:
Right-hand side of bidirectional pattern synonym cannot be used as an expression
App "Maybe" [t]
Failed, modules loaded: none.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PatternSynonyms error gives wrong source locations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using an example from the [http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax-extns.html GHC user's guide] but omitting the argument to `Maybe`\r\n\r\n{{{\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\ndata Type = App String [Type]\r\n\r\npattern Maybe = App \"Maybe\" [t]\r\n}}}\r\n\r\ngives the following error without the correct source locations\r\n\r\n{{{\r\nghci> :load /tmp/failure.hs \r\n[1 of 1] Compiling Main ( /tmp/failure.hs, interpreted )\r\n\r\n/tmp/failure.hs:1:1:\r\n Right-hand side of bidirectional pattern synonym cannot be used as an expression\r\n App \"Maybe\" [t]\r\nFailed, modules loaded: none.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8794Unresolved @ArSupportsAtFile@ on Solaris distribution.2019-07-07T18:43:25ZkgardasUnresolved @ArSupportsAtFile@ on Solaris distribution.While configuring ghc binary distribution on Solaris I've noted that settings file is not correctly generated:
```
$ cat settings
[("GCC extra via C opts", " -fwrapv"),
("C compiler command", "/usr/sfw/bin/gcc"),
("C compiler flags",...While configuring ghc binary distribution on Solaris I've noted that settings file is not correctly generated:
```
$ cat settings
[("GCC extra via C opts", " -fwrapv"),
("C compiler command", "/usr/sfw/bin/gcc"),
("C compiler flags", " "),
("ar command", "/usr/xpg4/bin/ar"),
("ar flags", "clqs"),
("ar supports at file", "@ArSupportsAtFile@"),
("touch command", "touch"),
("dllwrap command", "/bin/false"),
("windres command", "/bin/false"),
("perl command", "/usr/bin/perl"),
("target os", "OSSolaris2"),
("target arch", "ArchX86"),
("target word size", "4"),
("target has GNU nonexec stack", "True"),
("target has .ident directive", "True"),
("target has subsections via symbols", "False"),
("LLVM llc command", "llc"),
("LLVM opt command", "opt")
]
```
Looks like \@ArSupportsAtFile@ is not filled with the right value.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | InstallationFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Solaris |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Unresolved @ArSupportsAtFile@ on Solaris distribution.","status":"New","operating_system":"Solaris","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"While configuring ghc binary distribution on Solaris I've noted that settings file is not correctly generated:\r\n{{{\r\n$ cat settings \r\n[(\"GCC extra via C opts\", \" -fwrapv\"),\r\n (\"C compiler command\", \"/usr/sfw/bin/gcc\"),\r\n (\"C compiler flags\", \" \"),\r\n (\"ar command\", \"/usr/xpg4/bin/ar\"),\r\n (\"ar flags\", \"clqs\"),\r\n (\"ar supports at file\", \"@ArSupportsAtFile@\"),\r\n (\"touch command\", \"touch\"),\r\n (\"dllwrap command\", \"/bin/false\"),\r\n (\"windres command\", \"/bin/false\"),\r\n (\"perl command\", \"/usr/bin/perl\"),\r\n (\"target os\", \"OSSolaris2\"),\r\n (\"target arch\", \"ArchX86\"),\r\n (\"target word size\", \"4\"),\r\n (\"target has GNU nonexec stack\", \"True\"),\r\n (\"target has .ident directive\", \"True\"),\r\n (\"target has subsections via symbols\", \"False\"),\r\n (\"LLVM llc command\", \"llc\"),\r\n (\"LLVM opt command\", \"opt\")\r\n ]\r\n\r\n}}}\r\n\r\nLooks like @ArSupportsAtFile@ is not filled with the right value.","type_of_failure":"InstallationFailure","blocking":[]} -->7.8.1kgardaskgardashttps://gitlab.haskell.org/ghc/ghc/-/issues/8646Distinguish between update frames in rts/Printer.c2019-07-07T18:44:06ZTarraschDistinguish between update frames in rts/Printer.cWhen doing printf-debugging and using Printer.c, it would be nice to see exact kind of update frame. (See attached patch)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ...When doing printf-debugging and using Printer.c, it would be nice to see exact kind of update frame. (See attached patch)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Distinguish between update frames in rts/Printer.c","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"FeatureRequest","description":"When doing printf-debugging and using Printer.c, it would be nice to see exact kind of update frame. (See attached patch)","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8358Trivial comment fixup2019-07-07T18:45:24ZkrakrjakTrivial comment fixupWhile I was trying to build GHC HEAD today I ran across this minor inconsistency in the comments of the aclocal.m4 file. Attached is a patch to fix the version number in the comments.
<details><summary>Trac metadata</summary>
| Trac fi...While I was trying to build GHC HEAD today I ran across this minor inconsistency in the comments of the aclocal.m4 file. Attached is a patch to fix the version number in the comments.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Trivial comment fixup","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While I was trying to build GHC HEAD today I ran across this minor inconsistency in the comments of the aclocal.m4 file. Attached is a patch to fix the version number in the comments.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Austin Seipp <aseipp@pobox.com>Austin Seipp <aseipp@pobox.com>https://gitlab.haskell.org/ghc/ghc/-/issues/5070dph and new code generator don't play nicely with each other2019-07-07T18:57:01ZEdward Z. Yangdph and new code generator don't play nicely with each otherI'm looking at the current failure of DPH with the new code generator,
which is a bit different from what I've dealt with before. The bug appears
to be in the compiled libraries code, and I can tickle it with the
following minimized exam...I'm looking at the current failure of DPH with the new code generator,
which is a bit different from what I've dealt with before. The bug appears
to be in the compiled libraries code, and I can tickle it with the
following minimized example:
```
{-# LANGUAGE ParallelArrays #-}
{-# OPTIONS -fvectorise #-}
module PrimesVect where
import Data.Array.Parallel.Prelude
import qualified Prelude
f :: PArray Bool
f = toPArrayP f'
f' :: [:Bool:]
f' = [: True | _ <- singletonP True, g emptyP:]
g :: [:Bool:] -> Bool
g ps = andP [: True | _ <- ps:]
```
and a runner:
```
import qualified Data.Array.Parallel.PArray as P
import PrimesVect
main = print (P.toList f)
```
I expect to get \[True\], but instead I get:
```
dph-primespj-fast: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (0,1,0)
dph-primespj-fast: thread blocked indefinitely in an MVar operation
```
Now, in the situation that the library code is broken, I'd usually try to inline
all of the library code and then pare that down into something manageable. Unfortunately,
DPH is pretty closely tied to the compiler, so I don't see an easy way to do that.
So I'm not really sure how to go about debugging this.
Note that we can't work on this bug until #5065 is resolved, since these tests are currently failing for unrelated reasons.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | #5065 |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[5065],"summary":"dph and new code generator don't play nicely with each other","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm looking at the current failure of DPH with the new code generator,\r\nwhich is a bit different from what I've dealt with before. The bug appears\r\nto be in the compiled libraries code, and I can tickle it with the\r\nfollowing minimized example:\r\n\r\n{{{\r\n {-# LANGUAGE ParallelArrays #-}\r\n {-# OPTIONS -fvectorise #-}\r\n module PrimesVect where\r\n\r\n import Data.Array.Parallel.Prelude\r\n import qualified Prelude \r\n \r\n f :: PArray Bool \r\n f = toPArrayP f'\r\n\r\n f' :: [:Bool:]\r\n f' = [: True | _ <- singletonP True, g emptyP:]\r\n\r\n g :: [:Bool:] -> Bool\r\n g ps = andP [: True | _ <- ps:]\r\n}}}\r\n\r\nand a runner:\r\n\r\n{{{\r\n import qualified Data.Array.Parallel.PArray as P\r\n import PrimesVect\r\n\r\n main = print (P.toList f)\r\n}}}\r\n\r\nI expect to get [True], but instead I get:\r\n\r\n{{{\r\n dph-primespj-fast: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (0,1,0)\r\n dph-primespj-fast: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nNow, in the situation that the library code is broken, I'd usually try to inline\r\nall of the library code and then pare that down into something manageable. Unfortunately,\r\nDPH is pretty closely tied to the compiler, so I don't see an easy way to do that.\r\nSo I'm not really sure how to go about debugging this.\r\n\r\nNote that we can't work on this bug until #5065 is resolved, since these tests are currently failing for unrelated reasons.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1benlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/2507quotation characters in error messages2019-07-07T19:08:17ZIsaac Dupreequotation characters in error messages(wasn't there a ticket for this already?)
Currently identifiers etc. are quoted like this, with the "grave accent" and symmetric single-quote characters:
```
Ambiguous type variable `m' in the constraint:
`Monad m' arising fr...(wasn't there a ticket for this already?)
Currently identifiers etc. are quoted like this, with the "grave accent" and symmetric single-quote characters:
```
Ambiguous type variable `m' in the constraint:
`Monad m' arising from a use of `>>=' at gw.hs:6:47-71
```
This is not only an incorrect use of the "grave accent", but can be confusing when an identifier-name contains the prime symbol which is the same as the character used here to end the quote.
What should we do? Well, I just noticed that gcc-4.2.3 uses the Unicode begin-single-quote and end-single-quote characters for the purpose (and it actually looks quite nice on my terminal). If GCC was willing to do it, perhaps we should be too! To be precise, it uses them in my default locale, "en_US.UTF-8", which must have been the Ubuntu default that I didn't even remember I had. With `env LANG=C`, GCC emits ASCII single-quotes for both the begin and the end.
```
> cat errory.c
syntax error
> gcc errory.c
errory.c:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘error’
> env LANG=C gcc errory.c
errory.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'error'
```
I propose copying GCC's behavior (which might involve first looking into exactly what its behavior is in the general case).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"quotation characters in error messages","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"(wasn't there a ticket for this already?)\r\n\r\nCurrently identifiers etc. are quoted like this, with the \"grave accent\" and symmetric single-quote characters:\r\n{{{\r\n Ambiguous type variable `m' in the constraint:\r\n `Monad m' arising from a use of `>>=' at gw.hs:6:47-71\r\n}}}\r\n\r\nThis is not only an incorrect use of the \"grave accent\", but can be confusing when an identifier-name contains the prime symbol which is the same as the character used here to end the quote.\r\n\r\nWhat should we do? Well, I just noticed that gcc-4.2.3 uses the Unicode begin-single-quote and end-single-quote characters for the purpose (and it actually looks quite nice on my terminal). If GCC was willing to do it, perhaps we should be too! To be precise, it uses them in my default locale, \"en_US.UTF-8\", which must have been the Ubuntu default that I didn't even remember I had. With `env LANG=C`, GCC emits ASCII single-quotes for both the begin and the end.\r\n{{{\r\n> cat errory.c \r\nsyntax error\r\n> gcc errory.c \r\nerrory.c:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘error’\r\n> env LANG=C gcc errory.c \r\nerrory.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'error'\r\n}}}\r\n\r\nI propose copying GCC's behavior (which might involve first looking into exactly what its behavior is in the general case).","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1246<= operators get compiled worse than ==2019-07-07T19:14:30Zduncan<= operators get compiled worse than ==We'd like to define things like 'take' like this:
```
take :: Int -> [a] -> [a]
take n _ | n <= 0 = []
take _ [] = []
take n (x:xs) = x : take (n-1) xs
```
Which is just the natural implementation from the H98 spec. Unfortu...We'd like to define things like 'take' like this:
```
take :: Int -> [a] -> [a]
take n _ | n <= 0 = []
take _ [] = []
take n (x:xs) = x : take (n-1) xs
```
Which is just the natural implementation from the H98 spec. Unfortunately to make it run fast it has to be defined like so:
```
take :: Int -> [a] -> [a]
take n _ | n <= 0 = []
take n ls = take' n ls
where
take' :: Int -> [a] -> [a]
take' 0 _ = []
take' _ [] = []
take' n (x:xs) = x : take' (n-1) xs
```
The crucial difference is factoring out the i \<= 0 test so that it is done just once and then in the loop only matching against exactly 0.
Let's look at the STG:
First for the fast version:
```
==================== STG syntax: ====================
Take.$wtake' =
\r [ww_snF w_snH]
case ww_snF of ds_snM {
__DEFAULT ->
case w_snH of wild_so1 {
[] -> [] [];
: x_snL xs_snP ->
let {
sat_snR =
\u []
case -# [ds_snM 1] of sat_snO { __DEFAULT -> Take.$wtake' sat_snO xs_snP; };
} in : [x_snL sat_snR];
};
0 -> [] [];
};
Take.take =
\r [n_snV ds_so0]
case n_snV of wild_so2 {
GHC.Base.I# x_snY ->
case <=# [x_snY 0] of wild1_so3 {
GHC.Base.False -> Take.$wtake' x_snY ds_so0;
GHC.Base.True -> [] [];
};
};
```
So we see this gives us ` case _ of _ { __DEFAULT -> ...; 0 -> ...} `
where as the simple version gives us:
```
Take.$wtake =
\r [ww_sn1 w_sn3]
case <=# [ww_sn1 0] of wild_snl {
GHC.Base.False ->
case w_sn3 of wild1_snm {
[] -> [] [];
: x_sn7 xs_sna ->
let {
sat_snc =
\u []
case -# [ww_sn1 1] of sat_sn9 { __DEFAULT -> Take.$wtake sat_sn9 xs_sna; };
} in : [x_sn7 sat_snc];
};
GHC.Base.True -> [] [];
};
Take.take =
\r [w_sng w1_snk]
case w_sng of w2_snn { GHC.Base.I# ww_snj -> Take.$wtake ww_snj w1_snk; };
```
Now we get ` case n <=# 0# of { True -> ...; False -> ...} `. We might hope that this gives us equivalent code in the backend but sadly it doesn't, the simple version is slower.
We should be able to do better since at the cpu level calculating condition codes for == and \<= is the same cost, just different instructions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"<= operators get compiled worse than ==","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We'd like to define things like 'take' like this:\r\n\r\n{{{\r\ntake :: Int -> [a] -> [a]\r\ntake n _ | n <= 0 = []\r\ntake _ [] = []\r\ntake n (x:xs) = x : take (n-1) xs\r\n}}}\r\n\r\nWhich is just the natural implementation from the H98 spec. Unfortunately to make it run fast it has to be defined like so:\r\n\r\n{{{\r\ntake :: Int -> [a] -> [a]\r\ntake n _ | n <= 0 = []\r\ntake n ls = take' n ls\r\n where\r\n take' :: Int -> [a] -> [a]\r\n take' 0 _ = []\r\n take' _ [] = []\r\n take' n (x:xs) = x : take' (n-1) xs\r\n}}}\r\n\r\nThe crucial difference is factoring out the i <= 0 test so that it is done just once and then in the loop only matching against exactly 0.\r\n\r\nLet's look at the STG:\r\n\r\nFirst for the fast version:\r\n\r\n{{{\r\n==================== STG syntax: ====================\r\nTake.$wtake' =\r\n \\r [ww_snF w_snH]\r\n\tcase ww_snF of ds_snM {\r\n\t __DEFAULT ->\r\n\t case w_snH of wild_so1 {\r\n\t\t[] -> [] [];\r\n\t\t: x_snL xs_snP ->\r\n\t\t let {\r\n\t\t sat_snR =\r\n\t\t\t \\u []\r\n\t\t\t case -# [ds_snM 1] of sat_snO { __DEFAULT -> Take.$wtake' sat_snO xs_snP; };\r\n\t\t } in : [x_snL sat_snR];\r\n\t };\r\n\t 0 -> [] [];\r\n\t};\r\n\r\nTake.take =\r\n \\r [n_snV ds_so0]\r\n\tcase n_snV of wild_so2 {\r\n\t GHC.Base.I# x_snY ->\r\n\t case <=# [x_snY 0] of wild1_so3 {\r\n\t\tGHC.Base.False -> Take.$wtake' x_snY ds_so0;\r\n\t\tGHC.Base.True -> [] [];\r\n\t };\r\n\t};\r\n}}}\r\n\r\nSo we see this gives us {{{ case _ of _ { __DEFAULT -> ...; 0 -> ...} }}}\r\n\r\nwhere as the simple version gives us:\r\n\r\n{{{\r\nTake.$wtake =\r\n \\r [ww_sn1 w_sn3]\r\n\tcase <=# [ww_sn1 0] of wild_snl {\r\n\t GHC.Base.False ->\r\n\t case w_sn3 of wild1_snm {\r\n\t\t[] -> [] [];\r\n\t\t: x_sn7 xs_sna ->\r\n\t\t let {\r\n\t\t sat_snc =\r\n\t\t\t \\u []\r\n\t\t\t case -# [ww_sn1 1] of sat_sn9 { __DEFAULT -> Take.$wtake sat_sn9 xs_sna; };\r\n\t\t } in : [x_sn7 sat_snc];\r\n\t };\r\n\t GHC.Base.True -> [] [];\r\n\t};\r\n\r\nTake.take =\r\n \\r [w_sng w1_snk]\r\n\tcase w_sng of w2_snn { GHC.Base.I# ww_snj -> Take.$wtake ww_snj w1_snk; };\r\n}}}\r\n\r\nNow we get {{{ case n <=# 0# of { True -> ...; False -> ...} }}}. We might hope that this gives us equivalent code in the backend but sadly it doesn't, the simple version is slower.\r\n\r\nWe should be able to do better since at the cpu level calculating condition codes for == and <= is the same cost, just different instructions.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/693dynamic locking2019-07-07T19:17:24ZSimon Marlowdynamic lockingNow that the SMP and threaded runtimes are the same, there is some unnecessary locking going on in the single threaded case. For example, MVar operations now require an atomic memory operation, which can be quite slow. It might be a good...Now that the SMP and threaded runtimes are the same, there is some unnecessary locking going on in the single threaded case. For example, MVar operations now require an atomic memory operation, which can be quite slow. It might be a good idea to dynamically turn on these locks if we're running multi-threaded (ie. +RTS -N2 or greater). !ToDo: measure the difference.7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9658Prettyprint constraints in type signatures can omit necessary parentheses2019-07-07T18:39:37ZBlaisorbladePrettyprint constraints in type signatures can omit necessary parenthesesGHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the prog...GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix.
The example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning-syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs):
```hs
num = inj . Num
> :t num
num :: NUM :<: sup => Int -> sup (Full Int)
```
Adding the type annotation in gives:
```
src/Syntactic.hs:115:20: parse error on input `=>'
```
To fix the parse error, I need to add parentheses around the constraint:
```hs
num :: (NUM :<: sup) => Int -> sup (Full Int)
```
(Here this happens to be the wrong type signature, but that's orthogonal).
I imagine that's just because the constraint uses an operator (probably only possible with TypeOperators).
This happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3.
Misc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Prettyprint constraints in type signatures can omit necessary parentheses","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix.\r\n\r\nThe example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning-syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs):\r\n\r\n{{{#!hs\r\nnum = inj . Num\r\n\r\n> :t num\r\nnum :: NUM :<: sup => Int -> sup (Full Int)\r\n}}}\r\n\r\nAdding the type annotation in gives:\r\n\r\n{{{\r\nsrc/Syntactic.hs:115:20: parse error on input `=>'\r\n}}}\r\nTo fix the parse error, I need to add parentheses around the constraint:\r\n\r\n{{{#!hs\r\nnum :: (NUM :<: sup) => Int -> sup (Full Int)\r\n}}}\r\n(Here this happens to be the wrong type signature, but that's orthogonal).\r\n\r\nI imagine that's just because the constraint uses an operator (probably only possible with TypeOperators).\r\n\r\nThis happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3.\r\n\r\nMisc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9984Show, Read, Eq, Ord instances for Control.Applicative.Const2019-07-07T18:38:03ZFumiaki KinoshitaShow, Read, Eq, Ord instances for Control.Applicative.ConstAs mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => O...As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => Ord (Const a b)`
The absence of these instances makes debugging harder.
I suggest handcrafted Show/Read instances for neat representation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show, Read, Eq, Ord instances for Control.Applicative.Const","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:\r\n\r\n* `Show a => Show (Const a b)`\r\n* `Read a => Read (Const a b)`\r\n* `Eq a => Eq (Const a b)`\r\n* `Ord a => Ord (Const a b)`\r\n\r\nThe absence of these instances makes debugging harder.\r\n\r\nI suggest handcrafted Show/Read instances for neat representation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9807Only test for bug #9439 when llvm is installed2019-07-07T18:38:58ZihmccreeryOnly test for bug #9439 when llvm is installedWhen running `./configure` to build GHC, and `opt` is not found, the current output is:
> \<no location info\>:
> Warning: Couldn't figure out LLVM version!
> Make sure you have installed LLVM
> ghc: could not execute: opt
> failed to c...When running `./configure` to build GHC, and `opt` is not found, the current output is:
> \<no location info\>:
> Warning: Couldn't figure out LLVM version!
> Make sure you have installed LLVM
> ghc: could not execute: opt
> failed to compile
When I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like:
> checking for llvm... no
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | DocumentationBug |
| Priority | low |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clarify warning if LLVM is not found by configure","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When running `./configure` to build GHC, and `opt` is not found, the current output is:\r\n\r\n> <no location info>:\r\n> Warning: Couldn't figure out LLVM version!\r\n> Make sure you have installed LLVM\r\n> ghc: could not execute: opt\r\n> failed to compile\r\n\r\nWhen I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like:\r\n\r\n> checking for llvm... no","type_of_failure":"DocumentationBug","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9619HPC Code Coverage complains when two exactly the same mix files are on the path2019-07-07T18:39:47ZKasperHPC Code Coverage complains when two exactly the same mix files are on the pathCabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in modul...Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.
This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately.
Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC Code Coverage complains when two exactly the same mix files are on the path","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.\r\n\r\n\r\nThis issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. \r\n\r\nPriority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9449GHC.Prim documentation says "Safe Inferred"2019-07-07T18:40:21ZRichard Eisenbergrae@richarde.devGHC.Prim documentation says "Safe Inferred"The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` in...The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Prim documentation says \"Safe Inferred\"","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus.\r\n\r\nWhen testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/9317Add PolyKinds extension to Data.Monoid2019-07-07T18:40:55ZbernalexAdd PolyKinds extension to Data.MonoidPolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value ...PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add PolyKinds extension to Data.Monoid","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: <http://www.haskell.org/pipermail/libraries/2014-July/023261.html>.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9067Optimize clearNursery by short-circuiting when we get to currentNursery2019-07-07T18:42:04ZEdward Z. YangOptimize clearNursery by short-circuiting when we get to currentNurseryThis is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):
```
diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c
index 36776b9..0311042 100644
--- a/rts/sm/...This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):
```
diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c
index 36776b9..0311042 100644
--- a/rts/sm/Storage.c
+++ b/rts/sm/Storage.c
@@ -598,6 +598,11 @@ clearNursery (Capability *cap)
ASSERT(bd->gen_no == 0);
ASSERT(bd->gen == g0);
IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE));
+ if (bd == cap->r.rCurrentNursery) {
+ IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link)
+ ASSERT(bd->free == bd->start));
+ break;
+ }
}
}
}
```
This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimize clearNursery by short-circuiting when we get to currentNursery","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Task","description":"This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):\r\n\r\n{{{\r\ndiff --git a/rts/sm/Storage.c b/rts/sm/Storage.c\r\nindex 36776b9..0311042 100644\r\n--- a/rts/sm/Storage.c\r\n+++ b/rts/sm/Storage.c\r\n@@ -598,6 +598,11 @@ clearNursery (Capability *cap)\r\n ASSERT(bd->gen_no == 0);\r\n ASSERT(bd->gen == g0);\r\n IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE));\r\n+ if (bd == cap->r.rCurrentNursery) {\r\n+ IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link)\r\n+ ASSERT(bd->free == bd->start));\r\n+ break;\r\n+ }\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nThis is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9057Remove /usr/bin/… references2019-07-07T18:42:07ZMateusz KowalczykRemove /usr/bin/… referencesThe use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS.
A more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such ...The use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS.
A more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such shebangs to use env rather than direct reference.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove /usr/bin/… references","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS. \r\n\r\nA more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such shebangs to use env rather than direct reference.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8873/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.s...2019-07-07T18:43:00Zconfigurator/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directoryThe paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdriv...The paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory
```
I believe using `"$(dirname "$0")"` would be a portable solution that works under both cygwin and Linux versions of bash.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"The paths used in the {{{ghcii.sh}}} scripts to start {{{ghc --interactive}}}\r\n are incorrectly built using {{{\"$0\"/..}}}, which causes the message:\r\n\r\n{{{\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory\r\n}}}\r\n\r\nI believe using {{{\"$(dirname \"$0\")\"}}} would be a portable solution that works under both cygwin and Linux versions of bash.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8861Use commas to separate thousands when printing memory stats2019-07-07T18:43:03ZErlendHUse commas to separate thousands when printing memory statsIn GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.
It would be nicer i...In GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.
It would be nicer if this was printed as “1,200,000 bytes” instead of “1200000 bytes” as is the case now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use commas to separate thousands when printing memory stats","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"In GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.\r\nIt would be nicer if this was printed as “1,200,000 bytes” instead of “1200000 bytes” as is the case now.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8742Reuse scavenge_small_bitmap2019-07-07T18:43:41ZTarraschReuse scavenge_small_bitmapHi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ...Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reuse scavenge_small_bitmap","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Task","description":"Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1TarraschTarrasch