GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:09:35Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2244load in GHCi doesn't work with UTF-8 filenames2019-07-07T19:09:35Zmalebriaload in GHCi doesn't work with UTF-8 filenamesWhen I try to load a file with a UTF-8 character, I got:
```
Prelude> :load Público/codigo/haskell/Hora.hs
<no location info>: can't find file: P�blico/codigo/haskell/Hora.hs
```
With the command line it goes fine:
```
malebria@quind...When I try to load a file with a UTF-8 character, I got:
```
Prelude> :load Público/codigo/haskell/Hora.hs
<no location info>: can't find file: P�blico/codigo/haskell/Hora.hs
```
With the command line it goes fine:
```
malebria@quindinho:~$ ghci Público/codigo/haskell/Hora.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Hora ( Público/codigo/haskell/Hora.hs, interpreted )
```7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/2239lack of improvement/reduction with TFs2019-07-07T19:09:36Zclaus.reinke@talk21.comlack of improvement/reduction with TFs```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}
data A = A
data B = B
class C a where c :: a -> Stri...```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}
data A = A
data B = B
class C a where c :: a -> String
instance C Bool where c _ = "Bool"
instance C Char where c _ = "Char"
-- via TFs
type family TF a
type instance TF A = Char
type instance TF B = Bool
tf :: forall a b. (b ~ TF a,C b) => a -> String
tf a = c (undefined:: b)
-- via FDs
class FD a b | a -> b
instance FD A Char
instance FD B Bool
fd :: forall a b. (FD a b,C b) => a -> String
fd a = c (undefined:: b)
```
for some reason, the TF version doesn't work as well as the FD version:
```
*Main> fd A
"Char"
*Main> fd B
"Bool"
*Main> tf A
<interactive>:1:0:
No instance for (C (TF A))
arising from a use of `tf' at <interactive>:1:0-3
Possible fix: add an instance declaration for (C (TF A))
In the expression: tf A
In the definition of `it': it = tf A
*Main> :t undefined :: (b~TF A)=>b
undefined :: (b~TF A)=>b :: TF A
*Main> :t undefined :: (FD A b)=>b
undefined :: (FD A b)=>b :: Char
```
this is with `GHCi, version 6.9.20080217`.
the result of the TF is "known", even if not used:
```
*Main> :t undefined :: (b~TF A,b~Char)=>b
undefined :: (b~TF A,b~Char)=>b :: TF A
*Main> :t undefined :: (b~TF A,b~Bool)=>b
<interactive>:1:0:
Couldn't match expected type `Bool' against inferred type `Char'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"lack of improvement/reduction with TFs","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":["FD","TF","vs"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\ndata A = A\r\ndata B = B\r\n\r\nclass C a where c :: a -> String\r\ninstance C Bool where c _ = \"Bool\"\r\ninstance C Char where c _ = \"Char\"\r\n\r\n-- via TFs\r\ntype family TF a\r\ntype instance TF A = Char\r\ntype instance TF B = Bool\r\n\r\ntf :: forall a b. (b ~ TF a,C b) => a -> String\r\ntf a = c (undefined:: b) \r\n\r\n-- via FDs\r\nclass FD a b | a -> b\r\ninstance FD A Char\r\ninstance FD B Bool\r\n\r\nfd :: forall a b. (FD a b,C b) => a -> String\r\nfd a = c (undefined:: b) \r\n}}}\r\nfor some reason, the TF version doesn't work as well as the FD version:\r\n{{{\r\n*Main> fd A\r\n\"Char\"\r\n*Main> fd B\r\n\"Bool\"\r\n*Main> tf A\r\n\r\n<interactive>:1:0:\r\n No instance for (C (TF A))\r\n arising from a use of `tf' at <interactive>:1:0-3\r\n Possible fix: add an instance declaration for (C (TF A))\r\n In the expression: tf A\r\n In the definition of `it': it = tf A\r\n*Main> :t undefined :: (b~TF A)=>b\r\nundefined :: (b~TF A)=>b :: TF A\r\n*Main> :t undefined :: (FD A b)=>b\r\nundefined :: (FD A b)=>b :: Char\r\n}}}\r\nthis is with `GHCi, version 6.9.20080217`.\r\n\r\nthe result of the TF is \"known\", even if not used:\r\n{{{\r\n*Main> :t undefined :: (b~TF A,b~Char)=>b\r\nundefined :: (b~TF A,b~Char)=>b :: TF A\r\n*Main> :t undefined :: (b~TF A,b~Bool)=>b\r\n\r\n<interactive>:1:0:\r\n Couldn't match expected type `Bool' against inferred type `Char'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2236Deep stacks make execution time go through the roof2019-07-07T19:09:36ZSimon Peyton JonesDeep stacks make execution time go through the roofIn the code below, switching from `mapM_` to `mapM` causes a 20x change in execution time. The code being executed is very very similar (try `-ddump-simpl`), and the number of bytes allocated is not dissimilar. But the GC time is dramati...In the code below, switching from `mapM_` to `mapM` causes a 20x change in execution time. The code being executed is very very similar (try `-ddump-simpl`), and the number of bytes allocated is not dissimilar. But the GC time is dramatically more (presumably because we are repeatedly scanning a very deep stack) and, more puzzlingly, the MUT time is much more too.
It all seems to be to do with the stack depth. Not only that, but I think the effect is non-linear: doubling n from 200k to 400k nearly quadruples runtime. Doubling again to 800k makes it say 'Killed'.
```
module Main(main) where
import System.IO
import System.IO (openFile, IOMode(..), hPutStr)
n = 200000::Int
main = main_fast
main_slow = do -- Use mapM
h <- openFile "bardump2" WriteMode
mapM (do_it h) testlst
main_fast = do -- Use mapM_
h <- openFile "bardump2" WriteMode
mapM_ (do_it h) testlst
do_it h x = hPutStr h "yes"
testlst = [1..n]
```
Thanks to Ben for identifying this. Below are some figures
```
--------------------------------------
main = main_fast, N= 300,000
251,371,168 bytes allocated in the heap
14,041,824 bytes copied during GC (scavenged)
1,504 bytes copied during GC (not scavenged)
8,413,184 bytes maximum residency (5 sample(s))
448 collections in generation 0 ( 2.00s)
5 collections in generation 1 ( 0.01s)
17 Mb total memory in use
INIT time 0.00s ( 0.00s elapsed)
MUT time 1.17s ( 1.18s elapsed)
GC time 2.01s ( 2.03s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 3.18s ( 3.22s elapsed)
%GC time 63.3% (63.1% elapsed)
Alloc rate 215,201,590 bytes per MUT second
Productivity 36.7% of total user, 36.2% of total elapsed
--------------------------------------
main = main_slow, N= 300,000
227,615,792 bytes allocated in the heap
49,224 bytes copied during GC (scavenged)
1,440 bytes copied during GC (not scavenged)
40,960 bytes maximum residency (1 sample(s))
435 collections in generation 0 ( 0.00s)
1 collections in generation 1 ( 0.00s)
1 Mb total memory in use
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.15s ( 0.15s elapsed)
GC time 0.00s ( 0.00s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.15s ( 0.16s elapsed)
%GC time 0.0% (1.8% elapsed)
Alloc rate 1,537,851,022 bytes per MUT second
Productivity 100.0% of total user, 95.4% of total elapsed
---------------------------------------------
Non-linear effect
n fast/slow Mut GC Tot
400k fast 0.19 0 0.2
slow 2.14 3.64 5.78
200k fast 0.09 0 0.09
slow 0.48 0.96 1.44
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | midfield@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Deep stacks make execution time go through the roof","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["midfield@gmail.com"],"type":"Bug","description":"In the code below, switching from `mapM_` to `mapM` causes a 20x change in execution time. The code being executed is very very similar (try `-ddump-simpl`), and the number of bytes allocated is not dissimilar. But the GC time is dramatically more (presumably because we are repeatedly scanning a very deep stack) and, more puzzlingly, the MUT time is much more too. \r\n\r\nIt all seems to be to do with the stack depth. Not only that, but I think the effect is non-linear: doubling n from 200k to 400k nearly quadruples runtime. Doubling again to 800k makes it say 'Killed'.\r\n\r\n{{{\r\nmodule Main(main) where\r\n\r\nimport System.IO\r\nimport System.IO (openFile, IOMode(..), hPutStr)\r\n\r\nn = 200000::Int\r\n\r\nmain = main_fast\r\n\r\n\r\nmain_slow = do\t-- Use mapM\r\n h <- openFile \"bardump2\" WriteMode\r\n mapM (do_it h) testlst\r\n\r\nmain_fast = do\t-- Use mapM_\r\n h <- openFile \"bardump2\" WriteMode\r\n mapM_ (do_it h) testlst\r\n\r\ndo_it h x = hPutStr h \"yes\"\r\n\r\ntestlst = [1..n]\r\n}}}\r\n\r\nThanks to Ben for identifying this. Below are some figures\r\n{{{\r\n--------------------------------------\r\n main = main_fast, N= 300,000\r\n\r\n251,371,168 bytes allocated in the heap\r\n 14,041,824 bytes copied during GC (scavenged)\r\n 1,504 bytes copied during GC (not scavenged)\r\n 8,413,184 bytes maximum residency (5 sample(s))\r\n\r\n 448 collections in generation 0 ( 2.00s)\r\n 5 collections in generation 1 ( 0.01s)\r\n\r\n 17 Mb total memory in use\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 1.17s ( 1.18s elapsed)\r\n GC time 2.01s ( 2.03s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 3.18s ( 3.22s elapsed)\r\n\r\n %GC time 63.3% (63.1% elapsed)\r\n\r\n Alloc rate 215,201,590 bytes per MUT second\r\n\r\n Productivity 36.7% of total user, 36.2% of total elapsed\r\n\r\n--------------------------------------\r\n main = main_slow, N= 300,000\r\n\r\n227,615,792 bytes allocated in the heap\r\n 49,224 bytes copied during GC (scavenged)\r\n 1,440 bytes copied during GC (not scavenged)\r\n 40,960 bytes maximum residency (1 sample(s))\r\n\r\n 435 collections in generation 0 ( 0.00s)\r\n 1 collections in generation 1 ( 0.00s)\r\n\r\n 1 Mb total memory in use\r\n\r\n INIT time 0.00s ( 0.00s elapsed)\r\n MUT time 0.15s ( 0.15s elapsed)\r\n GC time 0.00s ( 0.00s elapsed)\r\n EXIT time 0.00s ( 0.00s elapsed)\r\n Total time 0.15s ( 0.16s elapsed)\r\n\r\n %GC time 0.0% (1.8% elapsed)\r\n\r\n Alloc rate 1,537,851,022 bytes per MUT second\r\n\r\n Productivity 100.0% of total user, 95.4% of total elapsed\r\n\r\n---------------------------------------------\r\n Non-linear effect\r\n\r\nn fast/slow\tMut\tGC\tTot\r\n400k\tfast\t\t0.19\t0\t0.2\r\n\tslow\t\t2.14\t3.64\t5.78\r\n\r\n200k\tfast\t\t0.09\t0\t0.09\r\n\tslow\t\t0.48\t0.96\t1.44\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/2226duplicate samples in heap profiling (-hc) output on 6.8.22019-07-07T19:09:38Zclemensduplicate samples in heap profiling (-hc) output on 6.8.2I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summar...I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"duplicate samples in heap profiling (-hc) output on 6.8.2","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2225hackage library encoding-0.4 crashes ghc 6.8.22019-07-07T19:09:38Zguesthackage library encoding-0.4 crashes ghc 6.8.2This is on i386 ubuntu gutsy. Output of "runghc Setup.hs build" is:
```
encoding-0.4$ runghc Setup.hs build
Preprocessing library encoding-0.4...
Building encoding-0.4...
[ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data/Encodin...This is on i386 ubuntu gutsy. Output of "runghc Setup.hs build" is:
```
encoding-0.4$ runghc Setup.hs build
Preprocessing library encoding-0.4...
Building encoding-0.4...
[ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data/Encoding/Helper/Template.hs, dist/build/Data/Enco\
ding/Helper/Template.o )
[ 2 of 37] Compiling Data.Encoding.GB18030Data ( Data/Encoding/GB18030Data.hs, dist/build/Data/Encoding/GB1\
8030Data.o )
[ 3 of 37] Compiling Data.Encoding.Base ( Data/Encoding/Base.hs, dist/build/Data/Encoding/Base.o )
[ 4 of 37] Compiling Data.Encoding.GB18030 ( Data/Encoding/GB18030.hs, dist/build/Data/Encoding/GB18030.o )
[ 5 of 37] Compiling Data.Encoding.KOI8U ( Data/Encoding/KOI8U.hs, dist/build/Data/Encoding/KOI8U.o )
[ 6 of 37] Compiling Data.Encoding.KOI8R ( Data/Encoding/KOI8R.hs, dist/build/Data/Encoding/KOI8R.o )
[ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/Data/Encoding/CP1258.o )
Loading package base ... linking ... done.
Loading package pretty-1.0.0.0 ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package packedstring-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package bytestring-0.9.0.1 ... linking ... done.
ghc-6.8.2: internal error: loadObj: can't map `dist/build/Data/Encoding/Helper/Template.o'
(GHC version 6.8.2 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
encoding-0.4$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| 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":"hackage library encoding-0.4 crashes ghc 6.8.2","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This is on i386 ubuntu gutsy. Output of \"runghc Setup.hs build\" is:\r\n\r\n{{{\r\nencoding-0.4$ runghc Setup.hs build\r\nPreprocessing library encoding-0.4...\r\nBuilding encoding-0.4...\r\n[ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data/Encoding/Helper/Template.hs, dist/build/Data/Enco\\\r\nding/Helper/Template.o )\r\n[ 2 of 37] Compiling Data.Encoding.GB18030Data ( Data/Encoding/GB18030Data.hs, dist/build/Data/Encoding/GB1\\\r\n8030Data.o )\r\n[ 3 of 37] Compiling Data.Encoding.Base ( Data/Encoding/Base.hs, dist/build/Data/Encoding/Base.o )\r\n[ 4 of 37] Compiling Data.Encoding.GB18030 ( Data/Encoding/GB18030.hs, dist/build/Data/Encoding/GB18030.o )\r\n[ 5 of 37] Compiling Data.Encoding.KOI8U ( Data/Encoding/KOI8U.hs, dist/build/Data/Encoding/KOI8U.o )\r\n[ 6 of 37] Compiling Data.Encoding.KOI8R ( Data/Encoding/KOI8R.hs, dist/build/Data/Encoding/KOI8R.o )\r\n[ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/Data/Encoding/CP1258.o )\r\nLoading package base ... linking ... done.\r\nLoading package pretty-1.0.0.0 ... linking ... done.\r\nLoading package array-0.1.0.0 ... linking ... done.\r\nLoading package packedstring-0.1.0.0 ... linking ... done.\r\nLoading package containers-0.1.0.1 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package bytestring-0.9.0.1 ... linking ... done.\r\nghc-6.8.2: internal error: loadObj: can't map `dist/build/Data/Encoding/Helper/Template.o'\r\n (GHC version 6.8.2 for i386_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nencoding-0.4$ \r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/2208many .xml files for the User's Manual force xml-mode in emacs2019-07-07T19:09:42ZSamuel Bronsonmany .xml files for the User's Manual force xml-mode in emacsMany (all?) of the XML files for the User's Manual contain the following or similar:
```xml
<!-- Emacs stuff:
;;; Local Variables: ***
;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1...Many (all?) of the XML files for the User's Manual contain the following or similar:
```xml
<!-- Emacs stuff:
;;; Local Variables: ***
;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
;;; End: ***
-->
```
The "mode:" line, in particular (assuming the user hasn't disabled the feature) overrides the user's choice of mode for XML editing (when the filename ends in .xml or another common XML suffix, anyway). Since I use `nxml-mode`, not `xml-mode`, this bothers me.
A quick grep turns up:
```
cd /home/naesten/hacking/haskell/ghc-hashedrepo/docs/users_guide/
grep -n -e 'mode: xml' --recursive . /dev/null
./runghc.xml:39: ;;; mode: xml ***
./packages.xml:1271: ;;; mode: xml ***
./5-00-notes.xml:204: ;;; mode: xml ***
./using.xml:1848: ;;; mode: xml ***
./utils.xml:561: ;;; mode: xml ***
./glasgow_exts.xml:7546: ;;; mode: xml ***
./license.xml:63: ;;; mode: xml ***
./ug-book.xml.in:28: ;;; mode: xml ***
./bugs.xml:404: ;;; mode: xml ***
./6.0-notes.xml:316: ;;; mode: xml ***
./debugging.xml:624: ;;; mode: xml ***
./5-04-notes.xml:285: ;;; mode: xml ***
./win32-dlls.xml:633: ;;; mode: xml ***
./5-02-notes.xml:54: ;;; mode: xml ***
./ghci.xml:2827: ;;; mode: xml ***
./flags.xml:2341: ;;; mode: xml ***
./lang.xml:12: ;;; mode: xml ***
./separate_compilation.xml:1261: ;;; mode: xml ***
./runtime_control.xml:691: ;;; mode: xml ***
./intro.xml:304: ;;; mode: xml ***
./installing.xml:529: ;;; mode: xml ***
./ffi-chap.xml:523: ;;; mode: xml ***
./sooner.xml:542: ;;; mode: xml ***
./parallel.xml:176: ;;; mode: xml ***
./profiling.xml:1713: ;;; mode: xml ***
./ug-book.xml:28: ;;; mode: xml ***
./phases.xml:1071: ;;; mode: xml ***
./gone_wrong.xml:210: ;;; mode: xml ***
```
Of these, probably only the one in `ug-book.xml.in` is actually useful, since that file doesn't have a name ending in .xml.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"many .xml files for the User's Manual force xml-mode in emacs","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":["emacs"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Many (all?) of the XML files for the User's Manual contain the following or similar:\r\n\r\n{{{\r\n#!xml\r\n<!-- Emacs stuff:\r\n ;;; Local Variables: ***\r\n ;;; mode: xml ***\r\n ;;; sgml-parent-document: (\"users_guide.xml\" \"book\" \"chapter\" \"sect1\") ***\r\n ;;; End: ***\r\n -->\r\n}}}\r\n\r\nThe \"mode:\" line, in particular (assuming the user hasn't disabled the feature) overrides the user's choice of mode for XML editing (when the filename ends in .xml or another common XML suffix, anyway). Since I use {{{nxml-mode}}}, not {{{xml-mode}}}, this bothers me.\r\n\r\nA quick grep turns up:\r\n{{{\r\ncd /home/naesten/hacking/haskell/ghc-hashedrepo/docs/users_guide/\r\ngrep -n -e 'mode: xml' --recursive . /dev/null\r\n./runghc.xml:39: ;;; mode: xml ***\r\n./packages.xml:1271: ;;; mode: xml ***\r\n./5-00-notes.xml:204: ;;; mode: xml ***\r\n./using.xml:1848: ;;; mode: xml ***\r\n./utils.xml:561: ;;; mode: xml ***\r\n./glasgow_exts.xml:7546: ;;; mode: xml ***\r\n./license.xml:63: ;;; mode: xml ***\r\n./ug-book.xml.in:28: ;;; mode: xml ***\r\n./bugs.xml:404: ;;; mode: xml ***\r\n./6.0-notes.xml:316: ;;; mode: xml ***\r\n./debugging.xml:624: ;;; mode: xml ***\r\n./5-04-notes.xml:285: ;;; mode: xml ***\r\n./win32-dlls.xml:633: ;;; mode: xml ***\r\n./5-02-notes.xml:54: ;;; mode: xml ***\r\n./ghci.xml:2827: ;;; mode: xml ***\r\n./flags.xml:2341: ;;; mode: xml ***\r\n./lang.xml:12: ;;; mode: xml ***\r\n./separate_compilation.xml:1261: ;;; mode: xml ***\r\n./runtime_control.xml:691: ;;; mode: xml ***\r\n./intro.xml:304: ;;; mode: xml ***\r\n./installing.xml:529: ;;; mode: xml ***\r\n./ffi-chap.xml:523: ;;; mode: xml ***\r\n./sooner.xml:542: ;;; mode: xml ***\r\n./parallel.xml:176: ;;; mode: xml ***\r\n./profiling.xml:1713: ;;; mode: xml ***\r\n./ug-book.xml:28: ;;; mode: xml ***\r\n./phases.xml:1071: ;;; mode: xml ***\r\n./gone_wrong.xml:210: ;;; mode: xml ***\r\n}}}\r\n\r\nOf these, probably only the one in {{{ug-book.xml.in}}} is actually useful, since that file doesn't have a name ending in .xml.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2204Improve 'patterns not matched' warnings2019-09-30T21:35:06ZDeewiantImprove 'patterns not matched' warningsCompiling the following with `-fwarn-incomplete-patterns`:
```
module Asdf where
f :: String -> Int
f "0" = 0
g :: Int -> Int
g 0 = 0
```
Yields:
```
asdf.hs:4:0:
Warning: Pattern match(es) are non-exhaustive
In the...Compiling the following with `-fwarn-incomplete-patterns`:
```
module Asdf where
f :: String -> Int
f "0" = 0
g :: Int -> Int
g 0 = 0
```
Yields:
```
asdf.hs:4:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `f':
Patterns not matched:
[]
(GHC.Base.C# #x) : _ with #x `notElem` ['0']
(GHC.Base.C# '0') : (_ : _)
asdf.hs:7:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `g':
Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#]
```
Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Improve 'patterns not matched' warnings","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Compiling the following with `-fwarn-incomplete-patterns`:\r\n\r\n{{{\r\nmodule Asdf where\r\n\r\nf :: String -> Int\r\nf \"0\" = 0\r\n\r\ng :: Int -> Int\r\ng 0 = 0\r\n}}}\r\n\r\nYields:\r\n\r\n{{{\r\nasdf.hs:4:0:\r\n Warning: Pattern match(es) are non-exhaustive\r\n In the definition of `f':\r\n Patterns not matched:\r\n []\r\n (GHC.Base.C# #x) : _ with #x `notElem` ['0']\r\n (GHC.Base.C# '0') : (_ : _)\r\n\r\nasdf.hs:7:0:\r\n Warning: Pattern match(es) are non-exhaustive\r\n In the definition of `g':\r\n Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#]\r\n}}}\r\n\r\nLosing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2201"ghc-pkg --user describe '*'" fails with empty user db2019-07-07T19:09:44Zduncan"ghc-pkg --user describe '*'" fails with empty user dbWith ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user sp...With ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet).
So what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD.
I'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like "`ghc-pkg: cannot find package matching *`" because that will upset Cabal's parser.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| 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":"\"ghc-pkg --user describe '*'\" fails with empty user db","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With ghc 6.9 and later Cabal uses the new \"`ghc-pkg describe '*'`\" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet).\r\n\r\nSo what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD.\r\n\r\nI'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like \"{{{ghc-pkg: cannot find package matching *}}}\" because that will upset Cabal's parser.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/2197GHCi doesn't work when built with way=p2019-07-07T19:09:45ZSamuel BronsonGHCi doesn't work when built with way=pI don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...
```
naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc-inplace_p --interactive
GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help
ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries/ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'
Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim'
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2186unsafePerformIO prevents space leak?2019-07-07T19:09:48Zravi@bluespec.comunsafePerformIO prevents space leak?Sadly, I don't have a concrete testcase for this, but I've fixed this issue in the Bluespec compiler more than once, so I have a strong suspicion that there's a GHC bug (or lack of optimization) going on here.
The basic situation is tha...Sadly, I don't have a concrete testcase for this, but I've fixed this issue in the Bluespec compiler more than once, so I have a strong suspicion that there's a GHC bug (or lack of optimization) going on here.
The basic situation is that I have a deeply nested structures of IORefs (I once measured one particular instance as including chains over 300 IORefs deep). I want to walk this structure recursively (it does not contain loops) without mutating it to compute a property of this structure. Generally speaking I'm either looking to accumulate certain kinds of nodes or I'm looking to detect the presence or absence of a certain kind of node.
If I traverse this structure in the IO monad (using readIORef directly and recursing and combining using things like mapM and foldM) I see a huge space leak (which can be confirmed with profiling). If I take the same traversal and wrap up the readIORef inside an unsafePerformIO (and change mapM to map and the like) the space leak disappears. This surprised me because I thought it would be the sort of thing GHC could figure out.
I'm sorry I can't easily give you a testcase, but I hope I've included enough detail that you have a fighting chance of reproducing it. Please let me know if you have any questions.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"unsafePerformIO prevents space leak?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Sadly, I don't have a concrete testcase for this, but I've fixed this issue in the Bluespec compiler more than once, so I have a strong suspicion that there's a GHC bug (or lack of optimization) going on here.\r\n\r\nThe basic situation is that I have a deeply nested structures of IORefs (I once measured one particular instance as including chains over 300 IORefs deep). I want to walk this structure recursively (it does not contain loops) without mutating it to compute a property of this structure. Generally speaking I'm either looking to accumulate certain kinds of nodes or I'm looking to detect the presence or absence of a certain kind of node. \r\n\r\nIf I traverse this structure in the IO monad (using readIORef directly and recursing and combining using things like mapM and foldM) I see a huge space leak (which can be confirmed with profiling). If I take the same traversal and wrap up the readIORef inside an unsafePerformIO (and change mapM to map and the like) the space leak disappears. This surprised me because I thought it would be the sort of thing GHC could figure out. \r\n\r\nI'm sorry I can't easily give you a testcase, but I hope I've included enough detail that you have a fighting chance of reproducing it. Please let me know if you have any questions.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/2171Parallel program crashes2019-07-07T19:09:53ZfedParallel program crashesI wrote a parallel program for computing prime numbers (see code below).
Compiled it using
> ghc -threaded --make primes.hs
Then run
> primes 200000 200010 +RTS -N2 -sstderr
In 80% of runs the program crashes with segmentation fault ...I wrote a parallel program for computing prime numbers (see code below).
Compiled it using
> ghc -threaded --make primes.hs
Then run
> primes 200000 200010 +RTS -N2 -sstderr
In 80% of runs the program crashes with segmentation fault message. My operating system is Windows XP SP2. One time I saw a typical Windows red cross dialog box with access violation report as a result of the run.
But few times the program finished with correct result.
```
module Main where
import System.Environment
import Control.Parallel.Strategies
import Data.Maybe
chunkSize = 1000
threads = 2
maybePrimes :: [Maybe Integer]
maybePrimes = Just 2 : Just 3 : Just 5 : [ if isPrime x then (Just x) else Nothing | x <- candidates 7 11 ]
where
candidates a1 a2 = a1 : a2 : candidates (a1+6) (a2+6)
isPrime x = all ((0 /=) . (x `mod`)) $ takeWhile ((x>=).(^2)) primes
splitOnSubLists :: Int -> [a] -> [[a]]
splitOnSubLists n xs =
let
(begin, end) = splitAt n xs
in
begin : splitOnSubLists n end
maybePrimes2 :: [Maybe Integer]
maybePrimes2 = concat $ parBuffer (threads-1) rnf
$ splitOnSubLists chunkSize maybePrimes
primes :: [Integer]
primes = catMaybes maybePrimes2
main = do
args <- getArgs
(first, last) <- case args of
[] -> return (10, 19)
(x:[]) -> return (f, f+9) where f = read x
(x:y:_) -> return (read x, read y)
let p = drop (first-1) $ take last $ zip [1..] primes in
mapM (\(x,y) -> putStrLn (show x ++ " -> " ++ show y)) p
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Parallel program crashes","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":["condition","crash,","parallel,","race"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"I wrote a parallel program for computing prime numbers (see code below).\r\nCompiled it using\r\n ghc -threaded --make primes.hs\r\nThen run\r\n primes 200000 200010 +RTS -N2 -sstderr\r\nIn 80% of runs the program crashes with segmentation fault message. My operating system is Windows XP SP2. One time I saw a typical Windows red cross dialog box with access violation report as a result of the run.\r\nBut few times the program finished with correct result.\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Environment\r\nimport Control.Parallel.Strategies\r\nimport Data.Maybe\r\n\r\nchunkSize = 1000\r\nthreads = 2\r\n\r\nmaybePrimes :: [Maybe Integer]\r\nmaybePrimes = Just 2 : Just 3 : Just 5 : [ if isPrime x then (Just x) else Nothing | x <- candidates 7 11 ]\r\n where\r\n candidates a1 a2 = a1 : a2 : candidates (a1+6) (a2+6)\r\n isPrime x = all ((0 /=) . (x `mod`)) $ takeWhile ((x>=).(^2)) primes\r\n\r\nsplitOnSubLists :: Int -> [a] -> [[a]]\r\nsplitOnSubLists n xs =\r\n let\r\n (begin, end) = splitAt n xs\r\n in\r\n begin : splitOnSubLists n end\r\n\r\nmaybePrimes2 :: [Maybe Integer]\r\nmaybePrimes2 = concat $ parBuffer (threads-1) rnf \r\n $ splitOnSubLists chunkSize maybePrimes\r\n\r\nprimes :: [Integer]\r\nprimes = catMaybes maybePrimes2\r\n\r\nmain = do\r\n args <- getArgs\r\n\r\n (first, last) <- case args of\r\n [] -> return (10, 19)\r\n (x:[]) -> return (f, f+9) where f = read x\r\n (x:y:_) -> return (read x, read y)\r\n\r\n let p = drop (first-1) $ take last $ zip [1..] primes in\r\n mapM (\\(x,y) -> putStrLn (show x ++ \" -> \" ++ show y)) p\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/2161finaliser of a ForeignPtr called while references from unreachable threads exist2019-07-07T19:09:55Zaglfinaliser of a ForeignPtr called while references from unreachable threads existI believe that I've managed to distill a crash which has been driving
me crazy for a few days into a short enough test case (22 lines) that
it might be useful.
In short: the threaded RTS will call the finialiser of a ForeignPtr
while an...I believe that I've managed to distill a crash which has been driving
me crazy for a few days into a short enough test case (22 lines) that
it might be useful.
In short: the threaded RTS will call the finialiser of a ForeignPtr
while an exception handler still holds a reference to it:
```
% ghc -make fptest.hs cbits.c -threaded
[1 of 1] Compiling Main ( fptest.hs, fptest.o )
Linking fptest ...
% ./fptest
New object getting created: 66f010
Finaliser getting called for 66f010
Use called for 66f010
```
I'm hoping that this is useful to someone who knows the RTS.
Cheers,
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist","status":"New","operating_system":"Linux","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I believe that I've managed to distill a crash which has been driving\r\nme crazy for a few days into a short enough test case (22 lines) that\r\nit might be useful.\r\n\r\nIn short: the threaded RTS will call the finialiser of a ForeignPtr\r\nwhile an exception handler still holds a reference to it:\r\n\r\n{{{\r\n% ghc -make fptest.hs cbits.c -threaded\r\n[1 of 1] Compiling Main ( fptest.hs, fptest.o )\r\nLinking fptest ...\r\n% ./fptest\r\nNew object getting created: 66f010\r\nFinaliser getting called for 66f010\r\nUse called for 66f010\r\n\r\n}}}\r\n\r\nI'm hoping that this is useful to someone who knows the RTS.\r\n\r\nCheers,","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/2102Typeclass membership doesn't bring coercion superclass requirements into scope2019-07-07T19:10:12ZryaniTypeclass membership doesn't bring coercion superclass requirements into scope```
-- This works:
class C1 a where c1 :: a -> Int
class C1 a => C2 a where c2 :: a -> Int
test :: C2 a => a -> Int
test a = c1 a + c2 a
-- This doesn't work:
class (a ~ b) => E a b
cast :: E a b => a -> b
cast a = a
{- error:
tyfam.hs...```
-- This works:
class C1 a where c1 :: a -> Int
class C1 a => C2 a where c2 :: a -> Int
test :: C2 a => a -> Int
test a = c1 a + c2 a
-- This doesn't work:
class (a ~ b) => E a b
cast :: E a b => a -> b
cast a = a
{- error:
tyfam.hs:36:9:
Couldn't match expected type `b' against inferred type `a'
`b' is a rigid type variable bound by
the type signature for `cast' at tyfam.hs:35:14
`a' is a rigid type variable bound by
the type signature for `cast' at tyfam.hs:35:12
In the expression: a
In the definition of `cast': cast a = a
-}
```
I would expect that the requirement of membership in `E a b` would bring `(a ~ b)` into scope and allow `cast` to typecheck.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| 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":"Typeclass membership doesn't bring coercion superclass requirements into scope","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\n-- This works:\r\nclass C1 a where c1 :: a -> Int\r\nclass C1 a => C2 a where c2 :: a -> Int\r\ntest :: C2 a => a -> Int\r\ntest a = c1 a + c2 a\r\n\r\n-- This doesn't work:\r\nclass (a ~ b) => E a b\r\ncast :: E a b => a -> b\r\ncast a = a\r\n\r\n{- error:\r\ntyfam.hs:36:9:\r\n Couldn't match expected type `b' against inferred type `a'\r\n `b' is a rigid type variable bound by\r\n the type signature for `cast' at tyfam.hs:35:14\r\n `a' is a rigid type variable bound by\r\n the type signature for `cast' at tyfam.hs:35:12\r\n In the expression: a\r\n In the definition of `cast': cast a = a\r\n -}\r\n}}}\r\n\r\nI would expect that the requirement of membership in {{{E a b}}} would bring {{{(a ~ b)}}} into scope and allow {{{cast}}} to typecheck.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2078INLINE and strictness2019-07-07T19:10:18ZSimon Peyton JonesINLINE and strictnessConsider this code
```
module A where
{-# INLINE [0] foo #-}
{#- RULE foo (reverse xs) = xs #-}
foo xs = reverse $ xs
module B where
import A( foo )
g b ys = foo (case b of
True -> reverse ys
...Consider this code
```
module A where
{-# INLINE [0] foo #-}
{#- RULE foo (reverse xs) = xs #-}
foo xs = reverse $ xs
module B where
import A( foo )
g b ys = foo (case b of
True -> reverse ys
False -> ys)
h xs = map foo xs
```
At the moment the body of `foo` is not optimised at all, because it's going to be inlined. But that means that
- The `foo` executed by the `map` in `h` is very inefficient, because it actually calls `$` etc.
- The strictness analyser doesn't see that `foo` is strict, because again the `$` gets in the way. So the rule for `foo` does not match in the RHS of `g`. (If `foo` were strict, we'd push the call to `foo` inside the case branches.)
For both reasons it'd be better to
- Retain the original RHS of `foo` for inlining purposes
- But otherwise optimise `foo` normally, so that if it is not inlined, we get the efficient version, and so that strictness analysis does the right thing.
Hmm. Maybe INLINE should turn into a RULE, rather than (as now) a `Note` in Core?
Anyway, this ticket is to make sure I don't forget this point.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndp@cse.unsw.edu.au |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"INLINE and strictness","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ndp@cse.unsw.edu.au"],"type":"Bug","description":"Consider this code \r\n{{{\r\nmodule A where\r\n {-# INLINE [0] foo #-}\r\n {#- RULE foo (reverse xs) = xs #-}\r\n foo xs = reverse $ xs\r\n\r\nmodule B where\r\n import A( foo )\r\n g b ys = foo (case b of \r\n True -> reverse ys\r\n False -> ys)\r\n\r\n h xs = map foo xs\r\n}}}\r\nAt the moment the body of `foo` is not optimised at all, because it's going to be inlined. But that means that\r\n\r\n * The `foo` executed by the `map` in `h` is very inefficient, because it actually calls `$` etc.\r\n\r\n * The strictness analyser doesn't see that `foo` is strict, because again the `$` gets in the way. So the rule for `foo` does not match in the RHS of `g`. (If `foo` were strict, we'd push the call to `foo` inside the case branches.)\r\n\r\nFor both reasons it'd be better to \r\n * Retain the original RHS of `foo` for inlining purposes\r\n * But otherwise optimise `foo` normally, so that if it is not inlined, we get the efficient version, and so that strictness analysis does the right thing.\r\n\r\nHmm. Maybe INLINE should turn into a RULE, rather than (as now) a `Note` in Core?\r\n\r\nAnyway, this ticket is to make sure I don't forget this point.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2039Using GHC 6.8.2 as a library does not work well under Windows in GHCi2019-07-07T19:10:29ZPVerswyvelenUsing GHC 6.8.2 as a library does not work well under Windows in GHCiWhen executing the following code with GHCi 6.8.2 under Windows
```
----->8--------
import DynFlags
import GHC
main = defaultErrorHandler defaultDynFlags $ do
session <- newSession (Just "d:\\app\\ghc-6.8.2")
flags <- getSessionDy...When executing the following code with GHCi 6.8.2 under Windows
```
----->8--------
import DynFlags
import GHC
main = defaultErrorHandler defaultDynFlags $ do
session <- newSession (Just "d:\\app\\ghc-6.8.2")
flags <- getSessionDynFlags session
(flags, _) <- parseDynamicFlags flags []
GHC.defaultCleanupHandler flags $ do
setSessionDynFlags session flags{ hscTarget=HscInterpreted }
prelude <- findModule session (mkModuleName "Prelude") Nothing
setContext session [] [prelude]
runStmt session "let n = 2 + 2" RunToCompletion
runStmt session "n" RunToCompletion
----->8--------
```
You get the following error:
```
Loading package array-0.1.0.0 ... linking ... done.
Loading package packedstring-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.0 ... linking ... done.
Loading package process-1.0.0.0 ... linking ... done.
Loading package pretty-1.0.0.0 ... linking ... done.
Loading package hpc-0.5.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package Cabal-1.2.3.0 ... linking ... done.
Loading package random-1.0.0.0 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package bytestring-0.9.0.1 ... linking ... done.
Loading package Win32-2.1.1.0 ... linking ... done.
Loading package ghc-6.8.2 ... linking ... done.
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_forkOS_entry
whilst processing object file
d:/app/ghc-6.8.2/lib\base-3.0.1.0/HSbase-3.0.1.0.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
```
It works fine under Linux. It also works when using GHC --make under Windows, however I do get errors when using hs-plugins under Windows, which seems related.
I haven't tried with GHC 6.9 yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Using GHC 6.8.2 as a library does not work well under Windows in GHCi","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":["API","GHC","GHCi","duplicate","linker","runtime","symbol"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When executing the following code with GHCi 6.8.2 under Windows\r\n\r\n{{{\r\n----->8--------\r\nimport DynFlags\r\n\r\nimport GHC\r\n\r\nmain = defaultErrorHandler defaultDynFlags $ do\r\n session <- newSession (Just \"d:\\\\app\\\\ghc-6.8.2\")\r\n flags <- getSessionDynFlags session\r\n (flags, _) <- parseDynamicFlags flags []\r\n GHC.defaultCleanupHandler flags $ do\r\n setSessionDynFlags session flags{ hscTarget=HscInterpreted }\r\n prelude <- findModule session (mkModuleName \"Prelude\") Nothing\r\n setContext session [] [prelude]\r\n runStmt session \"let n = 2 + 2\" RunToCompletion \r\n runStmt session \"n\" RunToCompletion \r\n----->8--------\r\n}}}\r\n\r\n\r\nYou get the following error:\r\n\r\n\r\n{{{\r\nLoading package array-0.1.0.0 ... linking ... done.\r\nLoading package packedstring-0.1.0.0 ... linking ... done.\r\nLoading package containers-0.1.0.1 ... linking ... done.\r\nLoading package old-locale-1.0.0.0 ... linking ... done.\r\nLoading package old-time-1.0.0.0 ... linking ... done.\r\nLoading package filepath-1.1.0.0 ... linking ... done.\r\nLoading package directory-1.0.0.0 ... linking ... done.\r\nLoading package process-1.0.0.0 ... linking ... done.\r\nLoading package pretty-1.0.0.0 ... linking ... done.\r\nLoading package hpc-0.5.0.0 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package Cabal-1.2.3.0 ... linking ... done.\r\nLoading package random-1.0.0.0 ... linking ... done.\r\nLoading package haskell98 ... linking ... done.\r\nLoading package bytestring-0.9.0.1 ... linking ... done.\r\nLoading package Win32-2.1.1.0 ... linking ... done.\r\nLoading package ghc-6.8.2 ... linking ... done.\r\n\r\n\r\nGHCi runtime linker: fatal error: I found a duplicate definition for symbol\r\n _forkOS_entry\r\nwhilst processing object file\r\n d:/app/ghc-6.8.2/lib\\base-3.0.1.0/HSbase-3.0.1.0.o\r\nThis could be caused by:\r\n * Loading two different object files which export the same symbol\r\n * Specifying the same object file twice on the GHCi command line\r\n * An incorrect `package.conf' entry, causing some object to be\r\n loaded twice.\r\nGHCi cannot safely continue in this situation. Exiting now. Sorry.\r\n\r\n}}}\r\n\r\nIt works fine under Linux. It also works when using GHC --make under Windows, however I do get errors when using hs-plugins under Windows, which seems related.\r\n\r\nI haven't tried with GHC 6.9 yet. \r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/2012compiling via-C does not work on ppc2019-07-07T19:10:38ZChristian Maedercompiling via-C does not work on ppcbuilding ghc-6.8.2 on ppc Mac OS X 10.4 (Tiger) with "`SRC_HC_OPTS += -fvia-C`" (see #1845) yields:
```
../compiler/ghc-inplace -H16m -O -fvia-C -keep-tmp-files -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCInclud...building ghc-6.8.2 on ppc Mac OS X 10.4 (Tiger) with "`SRC_HC_OPTS += -fvia-C`" (see #1845) yields:
```
../compiler/ghc-inplace -H16m -O -fvia-C -keep-tmp-files -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o
/tmp/ghc24131_0/ghc24131_0.s:unknown:Undefined local symbol L___DISCARD__$stub
make[1]: *** [Apply.o] Error 1
make: *** [stage1] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compiling via-C does not work on ppc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"building ghc-6.8.2 on ppc Mac OS X 10.4 (Tiger) with \"`SRC_HC_OPTS += -fvia-C`\" (see #1845) yields: \r\n\r\n{{{\r\n../compiler/ghc-inplace -H16m -O -fvia-C -keep-tmp-files -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o\r\n/tmp/ghc24131_0/ghc24131_0.s:unknown:Undefined local symbol L___DISCARD__$stub\r\nmake[1]: *** [Apply.o] Error 1\r\nmake: *** [stage1] Error 1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/1987GHCi's config file in <AppData>\ghc folder on Windows2019-07-07T19:10:46ZfelixmarGHCi's config file in <AppData>\ghc folder on WindowsCurrently GHCi's config file must be put in the `<UserProfile>` folder on Windows. Attached patch changes this to the `<AppData>`\\ghci folder and reads the configuration file as `ghci.cfg` instead of `.ghci`.
<details><summary>Trac met...Currently GHCi's config file must be put in the `<UserProfile>` folder on Windows. Attached patch changes this to the `<AppData>`\\ghci folder and reads the configuration file as `ghci.cfg` instead of `.ghci`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHCi's config file in <AppData>\\ghci folder on Windows","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Currently GHCi's config file must be put in the {{{<UserProfile>}}} folder on Windows. Attached patch changes this to the {{{<AppData>}}}\\ghci folder and reads the configuration file as {{{ghci.cfg}}} instead of {{{.ghci}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1982Spurious "defined but not used" warnings for constructors of types deriving Read2019-07-07T19:10:47ZEelis-Spurious "defined but not used" warnings for constructors of types deriving ReadConsider the following code:
```
data D = D { ds :: String, db :: Bool }
deriving (Read, Show)
main :: IO ()
main = do
let s = "D { ds = \"oi\", db = True }"
print (ds (read s))
print (db (read s))
```
With -Wall...Consider the following code:
```
data D = D { ds :: String, db :: Bool }
deriving (Read, Show)
main :: IO ()
main = do
let s = "D { ds = \"oi\", db = True }"
print (ds (read s))
print (db (read s))
```
With -Wall, ghc emits the following warning:
```
Warning: Defined but not used: data constructor `D'
```
I think this warning is not justified, because the D constructor *is* used to parse s.
The testcase above was derived from a program where D held a bunch of configuration fields for the program, and s was read from configuration file.
I would think the fix should be a rule along the lines of: if a data type derives from Read, then all of its constructors and field names are considered used.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Spurious \"defined but not used\" warnings for constructors of types deriving Read","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{\r\n data D = D { ds :: String, db :: Bool }\r\n deriving (Read, Show)\r\n\r\n main :: IO ()\r\n main = do\r\n let s = \"D { ds = \\\"oi\\\", db = True }\"\r\n print (ds (read s))\r\n print (db (read s))\r\n}}}\r\n\r\nWith -Wall, ghc emits the following warning:\r\n\r\n{{{\r\n Warning: Defined but not used: data constructor `D'\r\n}}}\r\n\r\nI think this warning is not justified, because the D constructor ''is'' used to parse s.\r\n\r\nThe testcase above was derived from a program where D held a bunch of configuration fields for the program, and s was read from configuration file.\r\n\r\nI would think the fix should be a rule along the lines of: if a data type derives from Read, then all of its constructors and field names are considered used.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1977Adding small check in Linux installer2019-07-07T19:10:48ZTenerAdding small check in Linux installerHello
I'm not sure to which component the ghc installer belongs. The message I got today while installing new version of ghc was:
> Installation of ghc-6.8.2 was successful.
> To use, add /usr/local/bin to your PATH.
But it turned out...Hello
I'm not sure to which component the ghc installer belongs. The message I got today while installing new version of ghc was:
> Installation of ghc-6.8.2 was successful.
> To use, add /usr/local/bin to your PATH.
But it turned out that this dir was already in my PATH. I think this is just a minor check that could save some seconds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Adding small check in Linux installer","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":["installer,","path"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Hello\r\n\r\nI'm not sure to which component the ghc installer belongs. The message I got today while installing new version of ghc was:\r\n\r\n Installation of ghc-6.8.2 was successful.\r\n To use, add /usr/local/bin to your PATH.\r\n\r\nBut it turned out that this dir was already in my PATH. I think this is just a minor check that could save some seconds.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/1975GHC cc phase doesn't add -framework-path flags2019-07-07T19:10:48ZjudahGHC cc phase doesn't add -framework-path flagsWhen compiling a `C` file with `ghc`, framework search paths (`-framework-path`) are not passed to gcc. For example, compiling the test file `rl.c` with `GNUreadline.framework` stored in `$HOME/Library/Frameworks`:
```
$ cat rl.c
#incl...When compiling a `C` file with `ghc`, framework search paths (`-framework-path`) are not passed to gcc. For example, compiling the test file `rl.c` with `GNUreadline.framework` stored in `$HOME/Library/Frameworks`:
```
$ cat rl.c
#include <stdio.h>
#include <GNUreadline/readline/readline.h>
int main(void) {
char *line = readline("Enter a line: ");
if (line) printf("Line was:%s\n",line);
return 0;
}
$ gcc -F$HOME/Library/Frameworks -framework GNUreadline rl.c
$ ghc -framework-path $HOME/Library/Frameworks -framework GNUreadline rl.c
rl.c:2:43:
error: GNUreadline/readline/readline.h: No such file or directory
rl.c: In function 'main':
rl.c:5:0: warning: implicit declaration of function 'readline'
rl.c:5:0:
warning: initialization makes pointer from integer without a cast
```
This bug was found by Christian Maeder when creating a potential fix for #1395. Discussion in that task is revolving around making GHC add `$HOME/Library/Frameworks` automatically; but regardless of that task's resolution, we should fix the above behavior.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"GHC cc phase doesn't add -framework-path flags","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.8.3","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"judah"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"When compiling a `C` file with `ghc`, framework search paths (`-framework-path`) are not passed to gcc. For example, compiling the test file `rl.c` with `GNUreadline.framework` stored in `$HOME/Library/Frameworks`:\r\n{{{\r\n$ cat rl.c \r\n#include <stdio.h>\r\n#include <GNUreadline/readline/readline.h>\r\n\r\nint main(void) {\r\n char *line = readline(\"Enter a line: \");\r\n if (line) printf(\"Line was:%s\\n\",line);\r\n return 0;\r\n}\r\n$ gcc -F$HOME/Library/Frameworks -framework GNUreadline rl.c\r\n$ ghc -framework-path $HOME/Library/Frameworks -framework GNUreadline rl.c\r\n\r\nrl.c:2:43:\r\n error: GNUreadline/readline/readline.h: No such file or directory\r\nrl.c: In function 'main':\r\n\r\nrl.c:5:0: warning: implicit declaration of function 'readline'\r\n\r\nrl.c:5:0:\r\n warning: initialization makes pointer from integer without a cast\r\n}}}\r\n\r\nThis bug was found by Christian Maeder when creating a potential fix for #1395. Discussion in that task is revolving around making GHC add `$HOME/Library/Frameworks` automatically; but regardless of that task's resolution, we should fix the above behavior.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>