GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:04:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3268implement the Cabal ${pkgroot} spec extension2019-07-07T19:04:40Zduncanimplement the Cabal ${pkgroot} spec extensionSee the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are ...See the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).
The open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"implement the Cabal ${pkgroot} spec extension","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See the proposal for relative paths in installed package descriptions:\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2009-May/011772.html\r\n\r\nBasically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).\r\n\r\nThe open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3269Stop using PackedString in template-haskell; drop packedstring as a bootlib2019-07-07T19:04:40ZSimon MarlowStop using PackedString in template-haskell; drop packedstring as a bootlibThe `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.
The proposal is ...The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.
The proposal is that we
- make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change)
- change their representation from `PackedString` to `String`
- drop the `packedstring` library from the bootlibs that GHC ships with
Relevant discussions:
- [http://www.haskell.org/pipermail/libraries/2008-November/010960.html](http://www.haskell.org/pipermail/libraries/2008-November/010960.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stop using PackedString in template-haskell; drop packedstring as a bootlib","status":"New","operating_system":"","component":"None","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.\r\n\r\nThe proposal is that we\r\n\r\n * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change)\r\n\r\n * change their representation from `PackedString` to `String`\r\n\r\n * drop the `packedstring` library from the bootlibs that GHC ships with\r\n\r\nRelevant discussions:\r\n\r\n * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html]\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3270Stop using PackedString in template-haskell; drop packedstring as a bootlib2019-07-07T19:04:39ZSimon MarlowStop using PackedString in template-haskell; drop packedstring as a bootlibThe `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.
The proposal is ...The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.
The proposal is that we
- make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change)
- change their representation from `PackedString` to `String`
- drop the `packedstring` library from the bootlibs that GHC ships with
Relevant discussions:
- [http://www.haskell.org/pipermail/libraries/2008-November/010960.html](http://www.haskell.org/pipermail/libraries/2008-November/010960.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stop using PackedString in template-haskell; drop packedstring as a bootlib","status":"New","operating_system":"","component":"None","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`.\r\n\r\nThe proposal is that we\r\n\r\n * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change)\r\n\r\n * change their representation from `PackedString` to `String`\r\n\r\n * drop the `packedstring` library from the bootlibs that GHC ships with\r\n\r\nRelevant discussions:\r\n\r\n * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html]\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3271New methods for Data.Sequence2019-07-07T19:04:39ZLouisWassermanNew methods for Data.Sequence`Data.Sequence` is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than `Data.List`, even allowing for the constraint that sequences are finite.
Th...`Data.Sequence` is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than `Data.List`, even allowing for the constraint that sequences are finite.
The following methods cannot be efficiently implemented based on currently exported methods from `Data.Sequence`.
- `zipWith` and its variants. Note: it suffices to define `zipWith` alone.
- `replicate`. (This can be implemented in `O(log n)` time with node sharing.)
The following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves.
- `scanl`, `scanr`, and variants. This is relatively straightforward using methods borrowed from the `Traversable` instance.
- `tails` and `inits`. `tails` is equivalent to `scanr (<|) empty`; `inits` is similar.
- `takeWhile`, `dropWhile`, `span`, `break` (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use `splitAt`.
- `unfoldr` and `iterate`, though the latter would require a finite number of iterations to perform.
- `partition`. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New methods for Data.Sequence","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`Data.Sequence` is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than `Data.List`, even allowing for the constraint that sequences are finite.\r\n\r\nThe following methods cannot be efficiently implemented based on currently exported methods from `Data.Sequence`.\r\n\r\n * `zipWith` and its variants. Note: it suffices to define `zipWith` alone.\r\n * `replicate`. (This can be implemented in `O(log n)` time with node sharing.)\r\n\r\nThe following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves.\r\n\r\n * `scanl`, `scanr`, and variants. This is relatively straightforward using methods borrowed from the `Traversable` instance.\r\n * `tails` and `inits`. `tails` is equivalent to `scanr (<|) empty`; `inits` is similar.\r\n * `takeWhile`, `dropWhile`, `span`, `break` (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use `splitAt`.\r\n * `unfoldr` and `iterate`, though the latter would require a finite number of iterations to perform.\r\n * `partition`. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCLouisWassermanLouisWassermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/3272GHC panics when contexts are put late in function types2019-07-07T19:04:39ZdmwitGHC panics when contexts are put late in function typesHere's a simple transcript from ghci:
```
Prelude> :m + Data.List
Prelude Data.List> :t genericLength :: [a] -> Num b => b
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for x86_64-unknown-linux):
TcTyFuns.flattenType: u...Here's a simple transcript from ghci:
```
Prelude> :m + Data.List
Prelude Data.List> :t genericLength :: [a] -> Num b => b
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panics when contexts are put late in function types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's a simple transcript from ghci:\r\n{{{\r\nPrelude> :m + Data.List\r\nPrelude Data.List> :t genericLength :: [a] -> Num b => b\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for x86_64-unknown-linux):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3273memory leak due to optimisation2020-11-17T17:20:15Zsebfmemory leak due to optimisationShort summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space wi...Short summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).
I could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.
Full description:
This ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:
```
$ ghc -fforce-recomp --make original
[1 of 1] Compiling Main ( original.hs, original.o )
Linking original ...
$ ./original
^C <constant space usage>
$ ghc -v -dcore-lint -O -fforce-recomp --make original
Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3
Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf
Using package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf
hiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4
hiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1
hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0
hiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2
hiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2
hiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1
hiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2
hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1
hiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2
hiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92
hiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2
hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1
hiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3
hiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0
hiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5
hiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1
hiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4
hiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4
hiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3
hiding package binary-0.4.4 to avoid conflict with later version binary-0.5
hiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2
hiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0
hiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11
hiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1
hiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8
hiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4
hiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2
hiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3
hiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7
hiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4
hiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2
hiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0
hiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1
hiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4
hiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1
hiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2
hiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1
hiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1
hiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1
hiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2
hiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3
hiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0
hiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.0.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.0
wired-in package template-haskell mapped to template-haskell-2.3.0.0
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *original.hs
Stable obj: [Main]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Thu Jun 4 13:23:20 CEST 2009
ms_mod = main:Main,
ms_imps = [Control.Monad.Cont]
ms_srcimps = []
}]
compile: input file original.hs
Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( original.hs, original.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 753
*** Core Linted result of Desugar:
*** Simplify:
Result size = 290
*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:
Result size = 280
*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:
Result size = 280
*** Core Linted result of Simplify phase gentle done:
*** Specialise:
Result size = 331
*** Core Linted result of Specialise:
*** Float out (not lambdas, not constants):
Result size = 351
*** Core Linted result of Float out (not lambdas, not constants):
*** Float inwards:
Result size = 351
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 587
*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:
Result size = 390
*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 2 [main] done:
*** Simplify:
Result size = 287
*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:
Result size = 287
*** Core Linted result of Simplify phase 1 [main] done:
*** Simplify:
Result size = 330
*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:
Result size = 310
*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 0 [main] done:
*** Demand analysis:
Result size = 304
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size = 330
*** Core Linted result of Worker Wrapper binds:
*** GlomBinds:
*** Simplify:
Result size = 345
*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:
Result size = 345
*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:
*** Float out (not lambdas, constants):
Result size = 353
*** Core Linted result of Float out (not lambdas, constants):
*** Common sub-expression:
Result size = 352
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size = 352
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 353
*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:
Result size = 353
*** Core Linted result of Simplify phase 0 [final] done:
*** Tidy Core:
Result size = 353
*** Core Linted result of Tidy Core:
writeBinIface: 49 Names
writeBinIface: 98 dict entries
*** CorePrep:
Result size = 430
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o
*** Deleting temp files:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s
Upsweep completely successful.
*** Deleting temp files:
Deleting:
link: linkables are ...
LinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main
[DotO original.o]
Linking original ...
*** Linker:
gcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr
/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/
integer-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0
-lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple
--with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)
/usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7
-weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/
Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1
-L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm
-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem
link: done
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
$ ./original
^C <increasing space usage>
$ ghc -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <constant space>
13:50 memleak$ ghc -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing space usage>
```
I have checked with ghc-6.8.2 on "Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux" and with ghc-6.10.1 and 6.11.200903331 on "Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14\~1/RELEASE_I386 i386"
Here are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:
```
$ ghc -fno-full-laziness -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
```
The program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.
The program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why \*all\* occurrences of 'id' are necessary to cause the leak.
I think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sebf@informatik.uni-kiel.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"memory leak due to optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sebf@informatik.uni-kiel.de"],"type":"Bug","description":"Short summary:\r\n\r\nThe attached programs use lots of space when compiled with -O and run in constant space without -O.\r\ncondensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.\r\noriginal.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).\r\n\r\nI could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.\r\n\r\nFull description:\r\n\r\nThis ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:\r\n\r\n{{{\r\n$ ghc -fforce-recomp --make original\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\nLinking original ...\r\n\r\n$ ./original \r\n^C <constant space usage>\r\n\r\n$ ghc -v -dcore-lint -O -fforce-recomp --make original\r\nGlasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3\r\nUsing package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf\r\nUsing package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf\r\nhiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4\r\nhiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1\r\nhiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0\r\nhiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2\r\nhiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2\r\nhiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1\r\nhiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2\r\nhiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1\r\nhiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2\r\nhiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92\r\nhiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2\r\nhiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1\r\nhiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3\r\nhiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0\r\nhiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5\r\nhiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1\r\nhiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4\r\nhiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4\r\nhiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3\r\nhiding package binary-0.4.4 to avoid conflict with later version binary-0.5\r\nhiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2\r\nhiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0\r\nhiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11\r\nhiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1\r\nhiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8\r\nhiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4\r\nhiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2\r\nhiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3\r\nhiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7\r\nhiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4\r\nhiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2\r\nhiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0\r\nhiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1\r\nhiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4\r\nhiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1\r\nhiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2\r\nhiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1\r\nhiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1\r\nhiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1\r\nhiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2\r\nhiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3\r\nhiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0\r\nhiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.0\r\nwired-in package base mapped to base-4.0.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.0\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.0\r\nwired-in package dph-seq mapped to dph-seq-0.3\r\nwired-in package dph-par mapped to dph-par-0.3\r\nHsc static flags: -static\r\n*** Chasing dependencies:\r\nChasing modules from: *original.hs\r\nStable obj: [Main]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Thu Jun 4 13:23:20 CEST 2009\r\n ms_mod = main:Main,\r\n ms_imps = [Control.Monad.Cont]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file original.hs\r\nCreated temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 753\r\n*** Core Linted result of Desugar:\r\n*** Simplify:\r\n Result size = 290\r\n*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplify phase gentle done:\r\n*** Specialise:\r\n Result size = 331\r\n*** Core Linted result of Specialise:\r\n*** Float out (not lambdas, not constants):\r\n Result size = 351\r\n*** Core Linted result of Float out (not lambdas, not constants):\r\n*** Float inwards:\r\n Result size = 351\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 587\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:\r\n Result size = 390\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 2 [main] done:\r\n*** Simplify:\r\n Result size = 287\r\n*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:\r\n Result size = 287\r\n*** Core Linted result of Simplify phase 1 [main] done:\r\n*** Simplify:\r\n Result size = 330\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:\r\n Result size = 310\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 0 [main] done:\r\n*** Demand analysis:\r\n Result size = 304\r\n*** Core Linted result of Demand analysis:\r\n*** Worker Wrapper binds:\r\n Result size = 330\r\n*** Core Linted result of Worker Wrapper binds:\r\n*** GlomBinds:\r\n*** Simplify:\r\n Result size = 345\r\n*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:\r\n Result size = 345\r\n*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:\r\n*** Float out (not lambdas, constants):\r\n Result size = 353\r\n*** Core Linted result of Float out (not lambdas, constants):\r\n*** Common sub-expression:\r\n Result size = 352\r\n*** Core Linted result of Common sub-expression:\r\n*** Float inwards:\r\n Result size = 352\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 353\r\n*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:\r\n Result size = 353\r\n*** Core Linted result of Simplify phase 0 [final] done:\r\n*** Tidy Core:\r\n Result size = 353\r\n*** Core Linted result of Tidy Core:\r\nwriteBinIface: 49 Names\r\nwriteBinIface: 98 dict entries\r\n*** CorePrep:\r\n Result size = 430\r\n*** Core Linted result of CorePrep:\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** CodeOutput:\r\n*** Assembler:\r\ngcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o\r\n*** Deleting temp files:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\nlink: linkables are ...\r\nLinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main\r\n [DotO original.o]\r\nLinking original ...\r\n*** Linker:\r\ngcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr\r\n/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/\r\ninteger-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0\r\n -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info\r\n -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info \r\n-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first\r\nUsing built-in specs.\r\nTarget: i686-apple-darwin9\r\nConfigured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr\r\n --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/\r\n --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple\r\n --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9\r\nThread model: posix\r\ngcc version 4.0.1 (Apple Inc. build 5488)\r\n /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7\r\n -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info \r\n-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info\r\n -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/\r\nVersions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1\r\n -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm \r\n-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem\r\nlink: done\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n\r\n$ ./original \r\n^C <increasing space usage>\r\n\r\n$ ghc -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <constant space>\r\n\r\n13:50 memleak$ ghc -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing space usage>\r\n}}}\r\n\r\nI have checked with ghc-6.8.2 on \"Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux\" and with ghc-6.10.1 and 6.11.200903331 on \"Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386\"\r\n\r\nHere are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:\r\n\r\n{{{\r\n$ ghc -fno-full-laziness -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n}}}\r\n\r\nThe program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.\r\n\r\nThe program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why *all* occurrences of 'id' are necessary to cause the leak.\r\n\r\nI think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3274Add System.FilePath.Cygwin2019-07-07T19:04:38ZNeil MitchellAdd System.FilePath.CygwinI propose we add the module `System.FilePath.Cygwin` to the filepath library. This module would be based on `System.FilePath.Windows` but with `'/'` as the preferred path separator, rather than `'\\'` as for Windows. This module would ne...I propose we add the module `System.FilePath.Cygwin` to the filepath library. This module would be based on `System.FilePath.Windows` but with `'/'` as the preferred path separator, rather than `'\\'` as for Windows. This module would never be available as `System.FilePath`, and would always have to be imported specifically if wanted.
The desire for this module comes from working with the Cygwin shell, which supports Windows syntax but requires the alternative separator. I have been using such a module for a few months, and find it very useful.
There are no backward compatibility concerns, as it is a new separate module.
Discussion deadline: 18th June 2009.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add System.FilePath.Cygwin","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"I propose we add the module {{{System.FilePath.Cygwin}}} to the filepath library. This module would be based on {{{System.FilePath.Windows}}} but with {{{'/'}}} as the preferred path separator, rather than {{{'\\\\'}}} as for Windows. This module would never be available as {{{System.FilePath}}}, and would always have to be imported specifically if wanted.\r\n\r\nThe desire for this module comes from working with the Cygwin shell, which supports Windows syntax but requires the alternative separator. I have been using such a module for a few months, and find it very useful.\r\n\r\nThere are no backward compatibility concerns, as it is a new separate module.\r\n\r\nDiscussion deadline: 18th June 2009.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3275ghc: panic! (the 'impossible' happened)2019-07-07T19:04:38ZEricKowghc: panic! (the 'impossible' happened)I downloaded the beta of the Haskell Platform installer from http://hackage.haskell.org/platform/2009.2.0.1/haskell-platform-2009.2.0.1-beta1-i386.dmg
and when I tried to cabal install the HEAD version of darcs, I got this error message...I downloaded the beta of the Haskell Platform installer from http://hackage.haskell.org/platform/2009.2.0.1/haskell-platform-2009.2.0.1-beta1-i386.dmg
and when I tried to cabal install the HEAD version of darcs, I got this error message:
```
[ 57 of 134] Compiling Darcs.Repository.Prefs ( src/Darcs/Repository/Prefs.lhs, dist/build/Darcs/Repository/Prefs.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
cat_evals
base:GHC.Arr.Array{d ras}
[ww{v a2ZC6} [lid], ww1{v a2ZC7} [lid], ww2{v a2ZC8} [lid]]
[!, !, _, _]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Darcs repo version (last patch; see attached for context file):
```
Mon Jun 1 10:19:28 BST 2009 Petr Rockai <me@mornfall.net>
* Remove tentativelyMerge from Gorsvet, as it's unused and confusing.
```6.10.4https://gitlab.haskell.org/ghc/ghc/-/issues/3276FilePath.addTrailingPathSeparator "" = "/"2019-07-07T19:04:37ZduncanFilePath.addTrailingPathSeparator "" = "/"Since we often consider the filepath `""` to be synonymous with `"."`, then `addTrailingPathSeparator ""` should be "./" not "/".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -----------...Since we often consider the filepath `""` to be synonymous with `"."`, then `addTrailingPathSeparator ""` should be "./" not "/".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FilePath.addTrailingPathSeparator \"\" = \"/\"","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Since we often consider the filepath `\"\"` to be synonymous with `\".\"`, then `addTrailingPathSeparator \"\"` should be \"./\" not \"/\".","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3277ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName2019-07-07T19:04:37ZJohn Kyghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName```
joky@joky-vm-ubuntu:~/svn-work/test-tools/haskell$ ./quick.lhs ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-linux):
RnEnv.lookupImportedName AMP.secBoardId{v}
Please report this as a GHC bug: ...```
joky@joky-vm-ubuntu:~/svn-work/test-tools/haskell$ ./quick.lhs ghc-6.8.2: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-linux):
RnEnv.lookupImportedName AMP.secBoardId{v}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/3278Make lazy unlifted bindings an error2023-08-17T15:12:03ZIan Lynagh <igloo@earth.li>Make lazy unlifted bindings an errorRemove `Opt_WarnLazyUnliftedBindings`, and turn the `warnTc` into an `checkTc`.
Remove `-Werror` from test T2806.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- ...Remove `Opt_WarnLazyUnliftedBindings`, and turn the `warnTc` into an `checkTc`.
Remove `-Werror` from test T2806.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make lazy unlifted bindings an error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"6.14.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nRemove `Opt_WarnLazyUnliftedBindings`, and turn the `warnTc` into an `checkTc`.\r\n\r\nRemove `-Werror` from test T2806.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3279Segmentation fault in reactive program2019-07-07T19:04:36ZBaughnSegmentation fault in reactive programTrying to debug reactive, I triggered what appears to be a GHC bug. To clarify:
- Replacing "foo `unamb` bar `unamb` baz" with foldl1 unamb \[foo,bar,baz\] in one particular function causes a segmentation fault at runtime, in all possib...Trying to debug reactive, I triggered what appears to be a GHC bug. To clarify:
- Replacing "foo `unamb` bar `unamb` baz" with foldl1 unamb \[foo,bar,baz\] in one particular function causes a segmentation fault at runtime, in all possible permutations of -threaded/nonthreaded and GHC 6.10.3/6.11. Further, a number of different changes do the same, quite unpredictably.
The hackage version of reactive does not exhibit this bug. I've attached a quite minimal patch to it that causes this, as well as a test program to trigger it.
I've been trying to debug this myself, with very little success. No level of core-lint or debug checks causes this code to trigger assertions instead of outright segfaults.
Incidentally, lazysmallcheck-0.3, a dependency of reactive, does not compile against 6.11 due to a name change in the Data.Generics interface. I've uploaded a fixed version to http://brage.info/\~svein/lsc.tar.gz.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Segmentation fault in reactive program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to debug reactive, I triggered what appears to be a GHC bug. To clarify:\r\n\r\n- Replacing \"foo `unamb` bar `unamb` baz\" with foldl1 unamb [foo,bar,baz] in one particular function causes a segmentation fault at runtime, in all possible permutations of -threaded/nonthreaded and GHC 6.10.3/6.11. Further, a number of different changes do the same, quite unpredictably.\r\n\r\nThe hackage version of reactive does not exhibit this bug. I've attached a quite minimal patch to it that causes this, as well as a test program to trigger it.\r\n\r\nI've been trying to debug this myself, with very little success. No level of core-lint or debug checks causes this code to trigger assertions instead of outright segfaults.\r\n\r\nIncidentally, lazysmallcheck-0.3, a dependency of reactive, does not compile against 6.11 due to a name change in the Data.Generics interface. I've uploaded a fixed version to http://brage.info/~svein/lsc.tar.gz.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.4Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3280The order of arguments to the function passed to nubBy got swapped somehow2019-07-07T19:04:36ZguestThe order of arguments to the function passed to nubBy got swapped somehowAccording to the Report:
```
nubBy :: (a -> a -> Bool) -> [a] -> [a]
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs)
```
Hence, we should have that
```
nubBy (<) (1:2:[])
= 1 :...According to the Report:
```
nubBy :: (a -> a -> Bool) -> [a] -> [a]
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs)
```
Hence, we should have that
```
nubBy (<) (1:2:[])
= 1 : nubBy (<) (filter (\y -> not (1 < y)) (2:[]))
= 1 : nubBy (<) []
= 1 : []
```
However in ghc-6.10.3:
```
Prelude Data.List> nubBy (<) [1,2]
[1,2]
```
The order of the parameters to the function which is passed to nubBy is \*important\* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour.
Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list.
- Cale
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | cgibbard@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The order of arguments to the function passed to nubBy got swapped somehow","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["cgibbard@gmail.com"],"type":"Bug","description":"According to the Report:\r\n{{{\r\n nubBy :: (a -> a -> Bool) -> [a] -> [a]\r\n nubBy eq [] = []\r\n nubBy eq (x:xs) = x : nubBy eq (filter (\\y -> not (eq x y)) xs)\r\n}}}\r\nHence, we should have that\r\n{{{\r\nnubBy (<) (1:2:[])\r\n= 1 : nubBy (<) (filter (\\y -> not (1 < y)) (2:[]))\r\n= 1 : nubBy (<) []\r\n= 1 : []\r\n}}}\r\nHowever in ghc-6.10.3:\r\n{{{\r\nPrelude Data.List> nubBy (<) [1,2]\r\n[1,2]\r\n}}}\r\nThe order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour.\r\n\r\nMoreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. \r\n\r\n - Cale","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3281The order of arguments to the function passed to nubBy got swapped somehow2021-11-02T09:27:33ZguestThe order of arguments to the function passed to nubBy got swapped somehowAccording to the Report:
```
nubBy :: (a -> a -> Bool) -> [a] -> [a]
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs)
```
Hence, we should have that
```
nubBy (<) (1:2:[])
= 1 :...According to the Report:
```
nubBy :: (a -> a -> Bool) -> [a] -> [a]
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs)
```
Hence, we should have that
```
nubBy (<) (1:2:[])
= 1 : nubBy (<) (filter (\y -> not (1 < y)) (2:[]))
= 1 : nubBy (<) []
= 1 : []
```
However in ghc-6.10.3:
```
Prelude Data.List> nubBy (<) [1,2]
[1,2]
```
The order of the parameters to the function which is passed to nubBy is \*important\* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour.
Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list.
- Cale
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | cgibbard@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The order of arguments to the function passed to nubBy got swapped somehow","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["cgibbard@gmail.com"],"type":"Bug","description":"According to the Report:\r\n{{{\r\n nubBy :: (a -> a -> Bool) -> [a] -> [a]\r\n nubBy eq [] = []\r\n nubBy eq (x:xs) = x : nubBy eq (filter (\\y -> not (eq x y)) xs)\r\n}}}\r\nHence, we should have that\r\n{{{\r\nnubBy (<) (1:2:[])\r\n= 1 : nubBy (<) (filter (\\y -> not (1 < y)) (2:[]))\r\n= 1 : nubBy (<) []\r\n= 1 : []\r\n}}}\r\nHowever in ghc-6.10.3:\r\n{{{\r\nPrelude Data.List> nubBy (<) [1,2]\r\n[1,2]\r\n}}}\r\nThe order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour.\r\n\r\nMoreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. \r\n\r\n - Cale","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3284ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out ...2019-07-07T19:04:35Zmpiechotkaghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph```
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/...```
Linking dist/build/SymmetricTest/SymmetricTest ...
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
(Crypto 4.1.0)https://gitlab.haskell.org/ghc/ghc/-/issues/3285"PAP object entered" on executable with profiling2019-07-07T19:04:35Zdarchon"PAP object entered" on executable with profilingWe're developing a tool that translates System Fc (GHC Core) to VHDL, and thus make use of the GHC API. When I try running my compiled executable with profiling support. I get the following error:
```
$ clash
library IEEE;
use IEEE.std_...We're developing a tool that translates System Fc (GHC Core) to VHDL, and thus make use of the GHC API. When I try running my compiled executable with profiling support. I get the following error:
```
$ clash
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
package types is
clash: internal error: PAP object entered!
(GHC version 6.10.3 for i386_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
When I run my executable without profiling support compiled in, I do not get the above error, and the program translates a piece of Haskell to VHDL just fine.
This is the command I use to compile my executable with profiling support, it should also give some insight into which libraries we use:
```
ghc -package ghc -package transformers -package ForSyDe -package prettyclass
-package data-accessor -package ghc-paths -package data-accessor-template
-package tfp -package tfvec HsValueMap.hs CoreShow.hs FlattenTypes.hs
VHDLTypes.hs TranslatorTypes.hs GhcTools.hs HsTools.hs CoreTools.hs Flatten.hs
Pretty.hs VHDL.hs Translator.hs -o clash -fforce-recomp --make -osuf p_o
-hisuf p_hi -prof -auto -auto-all -dcore-lint
```
I have no idea what might cause this problem. If you could give some hints on how to debug this problem, I might be able to give a more useful bug report. Also, I can supply the necessary files on request so that you can reproduce this error. You can contact me on: \<christiaan.baaij\@gmail.com\>
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"PAP object entered\" on executable with profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We're developing a tool that translates System Fc (GHC Core) to VHDL, and thus make use of the GHC API. When I try running my compiled executable with profiling support. I get the following error:\r\n{{{\r\n$ clash\r\nlibrary IEEE;\r\nuse IEEE.std_logic_1164.all;\r\nuse IEEE.numeric_std.all;\r\n\r\n\r\npackage types is\r\n\r\nclash: internal error: PAP object entered!\r\n (GHC version 6.10.3 for i386_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n\r\nWhen I run my executable without profiling support compiled in, I do not get the above error, and the program translates a piece of Haskell to VHDL just fine.\r\n\r\nThis is the command I use to compile my executable with profiling support, it should also give some insight into which libraries we use:\r\n{{{\r\nghc -package ghc -package transformers -package ForSyDe -package prettyclass \r\n-package data-accessor -package ghc-paths -package data-accessor-template \r\n-package tfp -package tfvec HsValueMap.hs CoreShow.hs FlattenTypes.hs \r\nVHDLTypes.hs TranslatorTypes.hs GhcTools.hs HsTools.hs CoreTools.hs Flatten.hs \r\nPretty.hs VHDL.hs Translator.hs -o clash -fforce-recomp --make -osuf p_o \r\n-hisuf p_hi -prof -auto -auto-all -dcore-lint\r\n}}}\r\n\r\nI have no idea what might cause this problem. If you could give some hints on how to debug this problem, I might be able to give a more useful bug report. Also, I can supply the necessary files on request so that you can reproduce this error. You can contact me on: <christiaan.baaij@gmail.com>","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3286junk `naughty x86_64 register' after expression2019-07-07T19:04:34ZIan Lynagh <igloo@earth.li>junk `naughty x86_64 register' after expressionThis is a cut-down version of the `hmm` and `logfloat` packages on hackage. On amd64/Linux, the 6.10 branch can build this, but the HEAD fails with:
```
$ ghc -fforce-recomp -O --make A.hs
[1 of 2] Compiling B ( B.hs, B.o...This is a cut-down version of the `hmm` and `logfloat` packages on hackage. On amd64/Linux, the 6.10 branch can build this, but the HEAD fails with:
```
$ ghc -fforce-recomp -O --make A.hs
[1 of 2] Compiling B ( B.hs, B.o )
[2 of 2] Compiling A ( A.hs, A.o )
/tmp/ghc29040_0/ghc29040_0.s: Assembler messages:
/tmp/ghc29040_0/ghc29040_0.s:393:0:
Error: junk `naughty x86_64 register' after expression
```
`A.hs`:
```
module A (train) where
import qualified Data.Map as M
import Data.List (groupBy, foldl')
import Data.Maybe (fromMaybe, fromJust)
import Data.Function (on)
import B
type Prob = LogFloat
learn_states :: (Ord state) => [(observation, state)] -> M.Map state Prob
learn_states xs = histogram $ map snd xs
learn_observations :: (Ord state, Ord observation) =>
M.Map state Prob
-> [(observation, state)]
-> M.Map (observation, state) Prob
learn_observations state_prob = M.mapWithKey f . histogram
where f (_, state) prob = prob / (fromJust $ M.lookup state state_prob)
histogram :: (Ord a) => [a] -> M.Map a Prob
histogram xs = let hist = foldl' undefined M.empty xs in
M.map (/ M.fold (+) 0 hist) hist
train :: (Ord observation, Ord state) =>
[(observation, state)]
-> (observation -> [Prob])
train sample = model
where
states = learn_states sample
state_list = M.keys states
observations = learn_observations states sample
observation_probs = fromMaybe (fill state_list []) . (flip M.lookup $
M.fromList $ map (\ (e, xs) -> (e, fill state_list xs)) $
map (\ xs -> (fst $ head xs, map snd xs)) $
groupBy ((==) `on` fst)
[(observation, (state, prob))
| ((observation, state), prob) <- M.toAscList observations])
model = observation_probs
fill :: Eq state => [state] -> [(state, Prob)] -> [Prob]
fill = undefined
```
`B.hs`:
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module B (LogFloat) where
newtype LogFloat = LogFloat Double
deriving (Eq, Ord, Num, Show)
instance Fractional LogFloat where
(/) (LogFloat x) (LogFloat y)
| x == 1
&& y == 1 = error "(/)"
| otherwise = LogFloat (x-y)
fromRational = LogFloat . fromRational
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"junk `naughty x86_64 register' after expression","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a cut-down version of the `hmm` and `logfloat` packages on hackage. On amd64/Linux, the 6.10 branch can build this, but the HEAD fails with:\r\n{{{\r\n$ ghc -fforce-recomp -O --make A.hs\r\n[1 of 2] Compiling B ( B.hs, B.o )\r\n[2 of 2] Compiling A ( A.hs, A.o )\r\n/tmp/ghc29040_0/ghc29040_0.s: Assembler messages:\r\n\r\n/tmp/ghc29040_0/ghc29040_0.s:393:0:\r\n Error: junk `naughty x86_64 register' after expression\r\n}}}\r\n\r\n`A.hs`:\r\n{{{\r\nmodule A (train) where\r\n\r\nimport qualified Data.Map as M\r\nimport Data.List (groupBy, foldl')\r\nimport Data.Maybe (fromMaybe, fromJust)\r\nimport Data.Function (on)\r\nimport B\r\n\r\ntype Prob = LogFloat\r\n\r\nlearn_states :: (Ord state) => [(observation, state)] -> M.Map state Prob\r\nlearn_states xs = histogram $ map snd xs\r\n\r\nlearn_observations :: (Ord state, Ord observation) =>\r\n M.Map state Prob\r\n -> [(observation, state)]\r\n -> M.Map (observation, state) Prob\r\nlearn_observations state_prob = M.mapWithKey f . histogram\r\n where f (_, state) prob = prob / (fromJust $ M.lookup state state_prob)\r\n\r\nhistogram :: (Ord a) => [a] -> M.Map a Prob\r\nhistogram xs = let hist = foldl' undefined M.empty xs in\r\n M.map (/ M.fold (+) 0 hist) hist\r\n\r\ntrain :: (Ord observation, Ord state) =>\r\n [(observation, state)]\r\n -> (observation -> [Prob])\r\ntrain sample = model\r\n where\r\n states = learn_states sample\r\n state_list = M.keys states\r\n\r\n observations = learn_observations states sample\r\n observation_probs = fromMaybe (fill state_list []) . (flip M.lookup $\r\n M.fromList $ map (\\ (e, xs) -> (e, fill state_list xs)) $\r\n map (\\ xs -> (fst $ head xs, map snd xs)) $\r\n groupBy ((==) `on` fst)\r\n [(observation, (state, prob))\r\n | ((observation, state), prob) <- M.toAscList observations])\r\n\r\n model = observation_probs\r\n\r\n fill :: Eq state => [state] -> [(state, Prob)] -> [Prob]\r\n fill = undefined\r\n}}}\r\n\r\n`B.hs`:\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n\r\nmodule B (LogFloat) where\r\n\r\nnewtype LogFloat = LogFloat Double\r\n deriving (Eq, Ord, Num, Show)\r\n\r\ninstance Fractional LogFloat where\r\n (/) (LogFloat x) (LogFloat y)\r\n | x == 1\r\n && y == 1 = error \"(/)\"\r\n | otherwise = LogFloat (x-y)\r\n fromRational = LogFloat . fromRational\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3287Malformed LANGUAGE pragma causes GHC panic2019-07-07T19:04:34ZcaittMalformed LANGUAGE pragma causes GHC panicHi, I tried to compile file starting with {-\# LANGUAGE -XExistentialQuantification \#-}
which is of course wrong, but GHC should handle this more gracefully than
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-un...Hi, I tried to compile file starting with {-\# LANGUAGE -XExistentialQuantification \#-}
which is of course wrong, but GHC should handle this more gracefully than
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for i386-unknown-linux):
> getOptions'.parseLanguage(2) went past eof token
The 6.8.2 version surprisingly works better:
test.hs:1:0: cannot parse LANGUAGE pragma
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Malformed LANGUAGE pragma causes GHC panic","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi, I tried to compile file starting with {-# LANGUAGE -XExistentialQuantification #-}\r\nwhich is of course wrong, but GHC should handle this more gracefully than\r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for i386-unknown-linux):\r\n getOptions'.parseLanguage(2) went past eof token\r\n\r\nThe 6.8.2 version surprisingly works better:\r\n\r\ntest.hs:1:0: cannot parse LANGUAGE pragma\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3288GC assertion failure in reactive program2019-07-07T19:04:34ZBaughnGC assertion failure in reactive programIn the same vein as [bug \#3279](http://hackage.haskell.org/trac/ghc/ticket/3279), this time I've triggered an assertion failure in the GC by adding Debug.Trace.trace expressions.
The exact same failure occurs in both 6.10.3 and 6.11, a...In the same vein as [bug \#3279](http://hackage.haskell.org/trac/ghc/ticket/3279), this time I've triggered an assertion failure in the GC by adding Debug.Trace.trace expressions.
The exact same failure occurs in both 6.10.3 and 6.11, apparently completely deterministically.
A darcs patch to add the crash to reactive, and a program to trigger it, are both attached.
Expected output:
```
svein@eris ~ $ ./crash
<Imp NoBound 2.0,1.0>
<Imp NoBound 2.5,2.0>
<Imp NoBound 3.2,3.0>
<Imp NoBound 3.7,4.0>
"never-never"
crash: internal error: scavenge_one: strange object 28
(GHC version 6.11.20090605 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GC assertion failure in reactive program","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the same vein as [http://hackage.haskell.org/trac/ghc/ticket/3279 bug #3279], this time I've triggered an assertion failure in the GC by adding Debug.Trace.trace expressions.\r\n\r\nThe exact same failure occurs in both 6.10.3 and 6.11, apparently completely deterministically.\r\n\r\nA darcs patch to add the crash to reactive, and a program to trigger it, are both attached.\r\n\r\nExpected output:\r\n{{{\r\nsvein@eris ~ $ ./crash\r\n<Imp NoBound 2.0,1.0>\r\n<Imp NoBound 2.5,2.0>\r\n<Imp NoBound 3.2,3.0>\r\n<Imp NoBound 3.7,4.0>\r\n\"never-never\"\r\ncrash: internal error: scavenge_one: strange object 28\r\n (GHC version 6.11.20090605 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3289make -j3 (or make -j30) occasionally fails on 6.112019-07-07T19:04:34Zgbeshersmake -j3 (or make -j30) occasionally fails on 6.11I've seen this a handful of times since the new build system was pushed.
I'm using exclusively x86_64 systems. The error message is
```
/usr/bin/ld: cannot find libraries/base/dist-install/build/GHC/Enum_split/Enum__1.p_o
```
Turning o...I've seen this a handful of times since the new build system was pushed.
I'm using exclusively x86_64 systems. The error message is
```
/usr/bin/ld: cannot find libraries/base/dist-install/build/GHC/Enum_split/Enum__1.p_o
```
Turning on make's debug information makes it clear that some process, I presume split,
is not completing before linking occurs.
Simply restarting the make completes the build most times (I think only once has
a second error occurred and I'm not 100% that I had made no modifications).
This happens on a dual-core debian system and an 8-core RHEL5.3 or Fedora-11 system.
If you need make's debug output send email to gbeshers at gmail dot com, but I am
hoping just adding a dependency will work.
6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3290Add Functor, Applicative, Monad, and Monoid instances for ParseResult2019-07-07T19:04:33ZYitzGaleAdd Functor, Applicative, Monad, and Monoid instances for ParseResultIn the haskell-src package, add the following instances to !ParseResult:
```
instance Functor ParseResult
instance Applicative ParseResult
instance Monad ParseResult
instance Monoid m => Monoid (ParseResult m)
```
This makes it more co...In the haskell-src package, add the following instances to !ParseResult:
```
instance Functor ParseResult
instance Applicative ParseResult
instance Monad ParseResult
instance Monoid m => Monoid (ParseResult m)
```
This makes it more convenient to traverse and modify
a syntax tree that is the result of the parser.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Functor, Applicative, Monad, and Monoid instances for ParseResult","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":["haskell-src"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the haskell-src package, add the following instances to !ParseResult:\r\n\r\n{{{\r\ninstance Functor ParseResult\r\ninstance Applicative ParseResult\r\ninstance Monad ParseResult\r\ninstance Monoid m => Monoid (ParseResult m)\r\n}}}\r\n\r\nThis makes it more convenient to traverse and modify\r\na syntax tree that is the result of the parser.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3291"Thread blocked indefinitely" kills the program despite being caught2019-07-07T19:04:33Zbatterseapower"Thread blocked indefinitely" kills the program despite being caughtPerhaps this is just me misunderstanding the semantics of exceptions, but the following program:
```
import Test.HUnit.Lang
import Control.Concurrent.STM
import Control.Exception
import Control.Concurrent
import Control.Concurrent.MVa...Perhaps this is just me misunderstanding the semantics of exceptions, but the following program:
```
import Test.HUnit.Lang
import Control.Concurrent.STM
import Control.Exception
import Control.Concurrent
import Control.Concurrent.MVar
main = do
mv <- newEmptyMVar
forkIO $ do
r <- performTestCase (atomically retry)
print "Yeaahh!"
print r
evaluate r
putMVar mv r
print "Cool, let's see what we get"
r <- takeMVar mv
print r
print "Am I printed?"
```
Should in my opinion, when run, print "Am I printed". This is because the "Thread blocked indefinitely" exception is caught by HUnit. However, this happens instead:
```
mbolingbroke@mb566 ~/Junk
$ ./Repro
"Cool, let's see what we get"
"Yeaahh!"
Just (False,"thread blocked indefinitely")
Repro: thread blocked indefinitely
```
NB: I get the expected behaviour if I run it within GHCi, but not if I compile the program.
This is causing problems for test-framework (see http://bsp.lighthouseapp.com/projects/15661-hs-test-framework/tickets/1-exits-immediately-on-thread-blocked-indefinitely-exception\#ticket-1-2)https://gitlab.haskell.org/ghc/ghc/-/issues/3292Add an 'ignore' function to Control.Monad2019-07-07T19:04:33ZguestAdd an 'ignore' function to Control.MonadSee http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880
In short, add a 'ignore :: m a -\> m ()' function to Control.Monad. This lets us do things like 'forkIO $ ignore stuff', as opposed to throwing around all sorts ...See http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880
In short, add a 'ignore :: m a -\> m ()' function to Control.Monad. This lets us do things like 'forkIO $ ignore stuff', as opposed to throwing around all sorts of '\>\> return ()'.
This function could be widely used by many libraries & apps, and has been repeatedly invented and suggested (see the thread). So far no one has said a word against it.
```
- -- | Convenience function. This is particularly good for 'forkIO' and 'forM_',
-- as they demand return types of 'IO ()', but most interesting IO functions
-- don't return void. So one can wrap them with 'ignore' (essentially a call to 'unit').
ignore :: Functor f => f a -> f ()
ignore = fmap (const ())
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | gwern0@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add an 'ignore' function to Control.Monad","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["gwern0@gmail.com"],"type":"Bug","description":"See http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880\r\n\r\nIn short, add a 'ignore :: m a -> m ()' function to Control.Monad. This lets us do things like 'forkIO $ ignore stuff', as opposed to throwing around all sorts of '>> return ()'.\r\n\r\nThis function could be widely used by many libraries & apps, and has been repeatedly invented and suggested (see the thread). So far no one has said a word against it.\r\n\r\n{{{\r\n- -- | Convenience function. This is particularly good for 'forkIO' and 'forM_',\r\n-- as they demand return types of 'IO ()', but most interesting IO functions\r\n-- don't return void. So one can wrap them with 'ignore' (essentially a call to 'unit').\r\nignore :: Functor f => f a -> f ()\r\nignore = fmap (const ())\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3293Implement shiftLInteger and shiftRInteger2019-07-07T19:04:33ZIan Lynagh <igloo@earth.li>Implement shiftLInteger and shiftRIntegerCurrently `shift` for `Integer` (in `Data.Bits`) is defined in terms of `(*)`, `div` and `^`.
Instead, `integer-*` should export `shiftLInteger` and `shiftRInteger`, which can be more efficient.
We should do this after the builtin-prim...Currently `shift` for `Integer` (in `Data.Bits`) is defined in terms of `(*)`, `div` and `^`.
Instead, `integer-*` should export `shiftLInteger` and `shiftRInteger`, which can be more efficient.
We should do this after the builtin-primop/FFI-imported-primop stuff is worked out, so that we can use a suitable GMP function for it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement shiftLInteger and shiftRInteger","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently `shift` for `Integer` (in `Data.Bits`) is defined in terms of `(*)`, `div` and `^`.\r\n\r\nInstead, `integer-*` should export `shiftLInteger` and `shiftRInteger`, which can be more efficient.\r\n\r\nWe should do this after the builtin-primop/FFI-imported-primop stuff is worked out, so that we can use a suitable GMP function for it.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3294Large compilation time/memory consumption2020-10-07T02:35:10ZpumpkinLarge compilation time/memory consumptionWhen compiling the attached test case in the following way:
```
airpumpkin:integer-benchmark pumpkin$ time ghc -O2 --make -o big Big.hs
[1 of 1] Compiling Main ( Big.hs, Big.o )
Linking big ...
real 1m29.336s
user 1m18.300s...When compiling the attached test case in the following way:
```
airpumpkin:integer-benchmark pumpkin$ time ghc -O2 --make -o big Big.hs
[1 of 1] Compiling Main ( Big.hs, Big.o )
Linking big ...
real 1m29.336s
user 1m18.300s
sys 0m6.816s
```
You can see it takes a while to compile, and uses 640 MB of RAM during compilation.7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3295Null deref by threaded runtime scheduler2019-07-07T19:04:32ZA1kmmNull deref by threaded runtime schedulerUsing ghc and runtime built from HEAD on Tuesday (although this has been an issue on older builds I tried as well), the ghc runtime crashes on a null deref.
The system is a 24-processor Intel Xeon 2.66 GHz shared memory system running L...Using ghc and runtime built from HEAD on Tuesday (although this has been an issue on older builds I tried as well), the ghc runtime crashes on a null deref.
The system is a 24-processor Intel Xeon 2.66 GHz shared memory system running Linux 2.6.16.60-0.34-smp in 64 bit mode (from SUSE 10 SP2).
This only happens when the program is compiled with -threaded (threaded runtime), but doesn't happen with the threaded debug runtime.
It also only happens when +RTS -N2 or a greater number of threads is passed to the runtime. It doesn't happen when -g1 is passed to turn off distributed garbage collection.
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1241594176 (LWP 20751)]
0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x994370) at rts/Schedule.c:672
672 return (waiting_for_gc ||
(gdb) list
667 // - another thread is initiating a GC
668 // - another Task is returning from a foreign call
669 // - the thread at the head of the run queue cannot be run
670 // by this Task (it is bound to another Task, or it is unbound
671 // and this task it bound).
672 return (waiting_for_gc ||
673 cap->returning_tasks_hd != NULL ||
674 (!emptyRunQueue(cap) && (task->tso == NULL
675 ? cap->run_queue_hd->bound != NULL
676 : cap->run_queue_hd->bound != task)));
(gdb) print cap
$1 = (Capability *) 0x0
(gdb) print *task
$2 = {id = 1241594176, cap = 0x0, stopped = 7160552, suspended_tso = 0x0, tso = 0x7fccc4, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0,
__total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e340, __nwaiters = 10033872, __broadcast_seq = 0},
__size = "\001\000\000\000\000\000\000\000\001", '\0' <repeats 23 times>, "@�\204\000\000\000\000\000�\032\231\000\000\000\000", __align = 1}, lock = {__data = {
__lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 22668, __spins = 0, __list = {__prev = 0x5793, __next = 0x85afd}},
__size = "\000\000\000\000\001", '\0' <repeats 11 times>, "\214X\000\000\000\000\000\000\223W\000\000\000\000\000\000�Z\b\000\000\000\000", __align = 4294967296},
wakeup = 547420, elapsedtimestart = 202, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x994370, next = 0x0, return_link = 0x0,
all_link = 0x0, prev_stack = 0x9945c0}
(gdb) info threads
* 21 Thread 1241594176 (LWP 20751) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x994370) at rts/Schedule.c:672
20 Thread 1233201472 (LWP 20750) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b4930) at rts/Schedule.c:672
19 Thread 1224808768 (LWP 20749) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b2df0) at rts/Schedule.c:672
18 Thread 1216416064 (LWP 20748) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b12b0) at rts/Schedule.c:672
17 Thread 1208023360 (LWP 20747) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9af770) at rts/Schedule.c:672
16 Thread 1199630656 (LWP 20746) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9adc30) at rts/Schedule.c:672
15 Thread 1191237952 (LWP 20745) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9ac0f0) at rts/Schedule.c:672
14 Thread 1182845248 (LWP 20744) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9aa5b0) at rts/Schedule.c:672
13 Thread 1174452544 (LWP 20743) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a8a70) at rts/Schedule.c:672
12 Thread 1166059840 (LWP 20742) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a6f30) at rts/Schedule.c:672
11 Thread 1157667136 (LWP 20741) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a53f0) at rts/Schedule.c:672
10 Thread 1149274432 (LWP 20740) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a38b0) at rts/Schedule.c:672
9 Thread 1140881728 (LWP 20739) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a1d70) at rts/Schedule.c:672
8 Thread 1132489024 (LWP 20738) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a0230) at rts/Schedule.c:672
7 Thread 1124096320 (LWP 20737) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99e6f0) at rts/Schedule.c:672
6 Thread 1115703616 (LWP 20736) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99cbb0) at rts/Schedule.c:672
5 Thread 1107310912 (LWP 20735) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99b070) at rts/Schedule.c:672
4 Thread 1098918208 (LWP 20734) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x999530) at rts/Schedule.c:672
3 Thread 1090525504 (LWP 20733) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9979f0) at rts/Schedule.c:672
2 Thread 1082132800 (LWP 20732) 0x00002aae2fa22548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
1 Thread 46927615298704 (LWP 20729) 0x00002aae2fa20553 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
```
The values of \*task and the thread in which the crash occurs is not always consistent, but the stacktrace is. For example, another crash...
```
(gdb) bt
#0 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b4930) at rts/Schedule.c:672
#1 0x0000000000673205 in workerStart (task=0x9915e0) at rts/Schedule.c:2033
#2 0x00002aae0cd1a143 in start_thread () from /lib64/libpthread.so.0
#3 0x00002aae0ceee8cd in clone () from /lib64/libc.so.6
#4 0x0000000000000000 in ?? ()
(gdb) print *task
$6 = {id = 1233201472, cap = 0x0, stopped = 11791697, suspended_tso = 0x0, tso = 0x25ed0f1, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0,
__total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e800, __nwaiters = 10033872, __broadcast_seq = 0},
__size = "\001\000\000\000\000\000\000\000\001", '\0' <repeats 24 times>, "�\204\000\000\000\000\000�\032\231\000\000\000\000", __align = 1}, lock = {__data = {__lock = 0,
__count = 1, __owner = 0, __nusers = 0, __kind = 875, __spins = 0, __list = {__prev = 0x33a, __next = 0x2da2b}},
__size = "\000\000\000\000\001", '\0' <repeats 11 times>, "k\003\000\000\000\000\000\000:\003\000\000\000\000\000\000+�\002\000\000\000\000", __align = 4294967296},
wakeup = 186902, elapsedtimestart = 24, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x9b4930, next = 0x0, return_link = 0x0,
all_link = 0x0, prev_stack = 0x9b4b80}
(gdb) info threads
22 Thread 1249986880 (LWP 20846) 0x00002aae0cd20548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
21 Thread 1241594176 (LWP 20845) 0x00002aae0cd1e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 20 Thread 1233201472 (LWP 20844) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b4930) at rts/Schedule.c:672
19 Thread 1224808768 (LWP 20843) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b2df0) at rts/Schedule.c:672
18 Thread 1216416064 (LWP 20842) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9b12b0) at rts/Schedule.c:672
17 Thread 1208023360 (LWP 20841) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9af770) at rts/Schedule.c:672
16 Thread 1199630656 (LWP 20840) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9adc30) at rts/Schedule.c:672
15 Thread 1191237952 (LWP 20839) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9ac0f0) at rts/Schedule.c:672
14 Thread 1182845248 (LWP 20838) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9aa5b0) at rts/Schedule.c:672
13 Thread 1174452544 (LWP 20837) gcWorkerThread (cap=<value optimized out>) at includes/SpinLock.h:45
12 Thread 1166059840 (LWP 20836) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a6f30) at rts/Schedule.c:672
11 Thread 1157667136 (LWP 20835) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a53f0) at rts/Schedule.c:672
10 Thread 1149274432 (LWP 20834) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a38b0) at rts/Schedule.c:672
9 Thread 1140881728 (LWP 20833) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a1d70) at rts/Schedule.c:672
8 Thread 1132489024 (LWP 20832) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9a0230) at rts/Schedule.c:672
7 Thread 1124096320 (LWP 20831) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99e6f0) at rts/Schedule.c:672
6 Thread 1115703616 (LWP 20830) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99cbb0) at rts/Schedule.c:672
5 Thread 1107310912 (LWP 20829) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x99b070) at rts/Schedule.c:672
4 Thread 1098918208 (LWP 20827) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x999530) at rts/Schedule.c:672
3 Thread 1090525504 (LWP 20826) 0x000000000067262c in schedule (initialCapability=<value optimized out>, task=0x9979f0) at rts/Schedule.c:672
2 Thread 1082132800 (LWP 20825) 0x00002aae0cee86e2 in select () from /lib64/libc.so.6
1 Thread 46927031233680 (LWP 20824) 0x00002aae0cd1c2ef in pthread_mutex_lock () from /lib64/libpthread.so.0
```
valgrind memcheck does not report any errors prior to the NULL deref:
```
==20983== Thread 2:
==20983== Invalid read of size 8
==20983== at 0x67262C: schedule (Schedule.c:672)
==20983== by 0x673204: workerStart (Schedule.c:2033)
==20983== by 0x58E4142: start_thread (in /lib64/libpthread-2.4.so)
==20983== by 0x5AB78CC: clone (in /lib64/libc-2.4.so)
==20983== Address 0x1d0 is not stack'd, malloc'd or (recently) free'd
==20983==
==20983== Process terminating with default action of signal 11 (SIGSEGV)
```
valgrind helgrind reports numerous possible data race conditions, including one between schedule and GarbageCollect just prior to the crash:
```
==21106== Possible data race during read of size 8 at 0x5ccc300 by thread #5
==21106== at 0x672612: schedule (Schedule.c:367)
==21106== by 0x673204: workerStart (Schedule.c:2033)
==21106== by 0x4A24A1E: mythread_wrapper (hg_intercepts.c:194)
==21106== by 0x58E7142: start_thread (in /lib64/libpthread-2.4.so)
==21106== by 0x5ABA8CC: clone (in /lib64/libc-2.4.so)
==21106== This conflicts with a previous write of size 8 by thread #1
==21106== at 0x679B8D: GarbageCollect (SpinLock.h:55)
==21106== by 0x6712D0: scheduleDoGC (Schedule.c:1522)
==21106== by 0x672C77: schedule (Schedule.c:621)
==21106== by 0x66FF84: real_main (RtsMain.c:68)
==21106== by 0x67009D: hs_main (RtsMain.c:117)
==21106== by 0x5A17183: (below main) (in /lib64/libc-2.4.so)
```
I am still working on whether I can make a small program to reproduce this.6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3296mention also -RTS after stack overflow2019-07-07T19:04:32ZChristian Maedermention also -RTS after stack overflowa stack overflow is shown as follows:
```
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.
```
Maybe the usage message...a stack overflow is shown as follows:
```
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.
```
Maybe the usage message for the RTS option can be improved wrt putting this option last or using -RTS
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mention also -RTS after stack overflow","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"a stack overflow is shown as follows:\r\n\r\n{{{\r\nStack space overflow: current size 8388608 bytes. \r\nUse `+RTS -Ksize' to increase it. \r\n}}}\r\n\r\nMaybe the usage message for the RTS option can be improved wrt putting this option last or using -RTS ","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3297Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a r...2019-07-07T19:04:31ZhesselinkCompiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type)On the following code sample the compiler panics with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20090403 for i386-unknown-linux):
TcTyFuns.flattenType: synonym family in a rank-n type
```
I found this when work...On the following code sample the compiler panics with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20090403 for i386-unknown-linux):
TcTyFuns.flattenType: synonym family in a rank-n type
```
I found this when working on some code when I made a mistake; the code should not type check, but should probably not crash the compiler either. I simplified the code to:
```
{-# LANGUAGE TypeFamilies
, KindSignatures
, RankNTypes
#-}
type family PF a :: (* -> *) -> * -> *
class Ix a where
type Es a :: * -> *
from :: a -> PF a (Es a) a
crash :: (forall n. Es a n) -> a
crash = from
```
It seems similar to #3101, but that one was about data types. A similar example also seems to be in #1897, but this bug doesn't seem to fit that ticket's description.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On the following code sample the compiler panics with:\r\n\r\n{{{\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 6.11.20090403 for i386-unknown-linux):\r\n\tTcTyFuns.flattenType: synonym family in a rank-n type\r\n}}}\r\n\r\nI found this when working on some code when I made a mistake; the code should not type check, but should probably not crash the compiler either. I simplified the code to:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies\r\n , KindSignatures\r\n , RankNTypes\r\n #-}\r\n\r\ntype family PF a :: (* -> *) -> * -> *\r\n\r\nclass Ix a where\r\n type Es a :: * -> *\r\n from :: a -> PF a (Es a) a\r\n\r\ncrash :: (forall n. Es a n) -> a\r\ncrash = from\r\n}}}\r\n\r\nIt seems similar to #3101, but that one was about data types. A similar example also seems to be in #1897, but this bug doesn't seem to fit that ticket's description.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/3298Add swap to Data.Tuple2019-07-07T19:04:31Zr6Add swap to Data.TupleI think swap is a widely accepted name for the function. There is only the question of strictness. I suggest swap for the lazy version and swap' for the strict version
swap \~(a,b) = (b,a)
swap' (a,b) = (b,a)
<details><summary>Trac me...I think swap is a widely accepted name for the function. There is only the question of strictness. I suggest swap for the lazy version and swap' for the strict version
swap \~(a,b) = (b,a)
swap' (a,b) = (b,a)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add swap to Data.Tuple","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think swap is a widely accepted name for the function. There is only the question of strictness. I suggest swap for the lazy version and swap' for the strict version\r\n\r\nswap ~(a,b) = (b,a)\r\n\r\nswap' (a,b) = (b,a)","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3299Error building HEAD on OS X: missing gmp.h2019-07-07T19:04:31ZjudahError building HEAD on OS X: missing gmp.hI got a fresh tree from darcs of ghc+libraries, ran `./configure` and `make`. Make failed with the following error:
```
"inplace/bin/mkdependC" -f libraries/integer-gmp/dist-install/build/.depend-v.tmp -- -O -g -O2 -Ilibraries/integ...I got a fresh tree from darcs of ghc+libraries, ran `./configure` and `make`. Make failed with the following error:
```
"inplace/bin/mkdependC" -f libraries/integer-gmp/dist-install/build/.depend-v.tmp -- -O -g -O2 -Ilibraries/integer-gmp/. -I/Users/judah/Programming/dontbackup/ghc/includes -I/Users/judah/Programming/dontbackup/ghc/libffi/build/include -- libraries/integer-gmp/cbits/float.c || ( "rm" -f libraries/integer-gmp/dist-install/build/.depend-v; exit 1 )
libraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory
libraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory
```
Actually, this error did not cause the build to stop, but it was the earliest that I could find in the log (attached).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Error building HEAD on OS X: missing gmp.h","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got a fresh tree from darcs of ghc+libraries, ran `./configure` and `make`. Make failed with the following error:\r\n{{{\r\n\"inplace/bin/mkdependC\" -f libraries/integer-gmp/dist-install/build/.depend-v.tmp -- -O -g -O2 -Ilibraries/integer-gmp/. -I/Users/judah/Programming/dontbackup/ghc/includes -I/Users/judah/Programming/dontbackup/ghc/libffi/build/include -- libraries/integer-gmp/cbits/float.c || ( \"rm\" -f libraries/integer-gmp/dist-install/build/.depend-v; exit 1 )\r\nlibraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory\r\nlibraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory\r\n}}}\r\n\r\nActually, this error did not cause the build to stop, but it was the earliest that I could find in the log (attached). ","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3300System.IO and System.Directory functions not Unicode-aware under Windows2019-07-07T19:04:31ZshuSystem.IO and System.Directory functions not Unicode-aware under WindowsUnder Windows, System.Directory.getDirectoryContents seems to apply encoding conversions on filenames at the syscall level.
I have several files with Japanese names, but my default program locale is English. Unicode-aware applications (...Under Windows, System.Directory.getDirectoryContents seems to apply encoding conversions on filenames at the syscall level.
I have several files with Japanese names, but my default program locale is English. Unicode-aware applications (that is, most modern Windows programs) have no problems with this. Calling getDirectoryContents on a folder with Japanese names, however, returns strings consisted of question marks "???".
If I switch the default program locale to, say, Japanese, then the files are returned in ShiftJIS, but I lose information such as accented Latin characters.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Directory.getDirectoryContents not unicode-aware under Windows","status":"New","operating_system":"Unknown/Multiple","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Under Windows, System.Directory.getDirectoryContents seems to apply encoding conversions on filenames at the syscall level.\r\n\r\nI have several files with Japanese names, but my default program locale is English. Unicode-aware applications (that is, most modern Windows programs) have no problems with this. Calling getDirectoryContents on a folder with Japanese names, however, returns strings consisted of question marks \"???\".\r\n\r\nIf I switch the default program locale to, say, Japanese, then the files are returned in ShiftJIS, but I lose information such as accented Latin characters.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3301Update Haskeline2021-11-02T09:27:33ZcjsUpdate HaskelineGHC 6.10.3 switched from readline/editline to [Haskeline](http://trac.haskell.org/haskeline) as the command-line editor in ghci. Unfortunately, this lost a lot of the vi-mode editing functionality, as the version of Haskeline ghci uses h...GHC 6.10.3 switched from readline/editline to [Haskeline](http://trac.haskell.org/haskeline) as the command-line editor in ghci. Unfortunately, this lost a lot of the vi-mode editing functionality, as the version of Haskeline ghci uses had very limited support for vi mode.
This support has been improving quickly in Haskeline's trunk, thanks to vi-mode users using the release and submitting bug reports. When the next version of GHC is released, a new release of Haskeline with all of these updates should be cut, and incorporated into GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | MergeReq |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Update Haskeline","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"MergeReq","description":"GHC 6.10.3 switched from readline/editline to [http://trac.haskell.org/haskeline Haskeline] as the command-line editor in ghci. Unfortunately, this lost a lot of the vi-mode editing functionality, as the version of Haskeline ghci uses had very limited support for vi mode.\r\n\r\nThis support has been improving quickly in Haskeline's trunk, thanks to vi-mode users using the release and submitting bug reports. When the next version of GHC is released, a new release of Haskeline with all of these updates should be cut, and incorporated into GHC.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3302Where-clause environments for GHCi2019-07-07T19:04:30ZcjsWhere-clause environments for GHCiOften in ghci I'd like to interactively debug and play with functions in the `where` clause of a top-level definition. Currently, this requires one to change the code, lifting the definitions in question to the top level and adding appro...Often in ghci I'd like to interactively debug and play with functions in the `where` clause of a top-level definition. Currently, this requires one to change the code, lifting the definitions in question to the top level and adding appropriate parameters.
Given a definition such as
```
top :: Int -> Int
top x = mult 4 - mult 3 + mult 2
where
mult n = x * n
```
it would be nice to type something such as `:environment top 2` to put me in an envrionment where `mult` is available and `mult 4` will evaluate to `8`. (Obviously this becomes more useful with more complex definitions.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Where-clause environments for GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Often in ghci I'd like to interactively debug and play with functions in the `where` clause of a top-level definition. Currently, this requires one to change the code, lifting the definitions in question to the top level and adding appropriate parameters.\r\n\r\nGiven a definition such as\r\n{{{\r\ntop :: Int -> Int\r\ntop x = mult 4 - mult 3 + mult 2\r\n where\r\n mult n = x * n\r\n}}}\r\nit would be nice to type something such as `:environment top 2` to put me in an envrionment where `mult` is available and `mult 4` will evaluate to `8`. (Obviously this becomes more useful with more complex definitions.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3303Allow multi-line deprecation messages.2019-07-07T19:04:30ZduncanAllow multi-line deprecation messages.Sometimes one line just isn't enough. There's two related issues, pretty source code and pretty warning messages.
It is a bit annoying when a `DEPRECATED` pragma stretches on past 80-100 columns or whatever. Does the ordinary multi-line...Sometimes one line just isn't enough. There's two related issues, pretty source code and pretty warning messages.
It is a bit annoying when a `DEPRECATED` pragma stretches on past 80-100 columns or whatever. Does the ordinary multi-line Haskell string syntax work in this situation? Even if it does it's not useful in practice due to the cpp-incompatibility, and because it's a pragma, we cannot use the normal `++` trick.
The other is presenting multi-line error messages to the user. Sometimes we want to present more info, like not just what the alternative is but for example when the alternative was added and when the deprecated thing will be removed.
In Cabal for example we've got ugly hack:
```
{-# DEPRECATED defaultUserHooks
"Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2\n compatibility in which case you must stick with defaultUserHooks" #-}
```
Yes it's really that wide :-)
Reformatted:
```
{-# DEPRECATED defaultUserHooks
"Use simpleUserHooks or autoconfUserHooks, unless you \
need Cabal-1.2\n compatibility in which \
case you must stick with defaultUserHooks" #-}
```
Note the silly `"\n "` to make the multi-line message line up ok in current ghc versions.
To allow embedded '\\n' more sensibly, it just needs a slight tweak in the rendering. Split the message into lines and then use `hsep` or equivalent. That way we get correct indenting for free.
I'm not sure how long single-line messages get printed, but Cabal solves this problem for its error messages by re-wrapping text, though it also respects embedded newlines (to force line breaks or paragraph breaks).
```
-- | Wraps text to the default line width. Existing newlines are preserved.
wrapText :: String -> String
wrapText = unlines
. concatMap (map unwords
. wrapLine 79
. words)
. lines
-- | Wraps a list of words to a list of lines of words of a particular width.
wrapLine :: Int -> [String] -> [[String]]
wrapLine width = wrap 0 []
where wrap :: Int -> [String] -> [String] -> [[String]]
wrap 0 [] (w:ws)
| length w + 1 > width
= wrap (length w) [w] ws
wrap col line (w:ws)
| col + length w + 1 > width
= reverse line : wrap 0 [] (w:ws)
wrap col line (w:ws)
= let col' = col + length w + 1
in wrap col' (w:line) ws
wrap _ [] [] = []
wrap _ line [] = [reverse line]
```
There's also a more sophisticated version of this using the `Doc` type in the gtk2hs code gen utils. It has a parameter for the line width and handles prefix text on the first line.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Allow multi-line deprecation messages.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sometimes one line just isn't enough. There's two related issues, pretty source code and pretty warning messages.\r\n\r\nIt is a bit annoying when a `DEPRECATED` pragma stretches on past 80-100 columns or whatever. Does the ordinary multi-line Haskell string syntax work in this situation? Even if it does it's not useful in practice due to the cpp-incompatibility, and because it's a pragma, we cannot use the normal `++` trick.\r\n\r\nThe other is presenting multi-line error messages to the user. Sometimes we want to present more info, like not just what the alternative is but for example when the alternative was added and when the deprecated thing will be removed.\r\n\r\nIn Cabal for example we've got ugly hack:\r\n{{{\r\n{-# DEPRECATED defaultUserHooks\r\n \"Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2\\n compatibility in which case you must stick with defaultUserHooks\" #-}\r\n}}}\r\n\r\nYes it's really that wide :-)\r\n\r\nReformatted:\r\n{{{\r\n{-# DEPRECATED defaultUserHooks\r\n \"Use simpleUserHooks or autoconfUserHooks, unless you \\\r\n need Cabal-1.2\\n compatibility in which \\\r\n case you must stick with defaultUserHooks\" #-}\r\n}}}\r\n\r\nNote the silly `\"\\n \"` to make the multi-line message line up ok in current ghc versions.\r\n\r\nTo allow embedded '\\n' more sensibly, it just needs a slight tweak in the rendering. Split the message into lines and then use `hsep` or equivalent. That way we get correct indenting for free.\r\n\r\nI'm not sure how long single-line messages get printed, but Cabal solves this problem for its error messages by re-wrapping text, though it also respects embedded newlines (to force line breaks or paragraph breaks).\r\n\r\n{{{\r\n-- | Wraps text to the default line width. Existing newlines are preserved.\r\nwrapText :: String -> String\r\nwrapText = unlines\r\n . concatMap (map unwords\r\n . wrapLine 79\r\n . words)\r\n . lines\r\n\r\n-- | Wraps a list of words to a list of lines of words of a particular width.\r\nwrapLine :: Int -> [String] -> [[String]]\r\nwrapLine width = wrap 0 []\r\n where wrap :: Int -> [String] -> [String] -> [[String]]\r\n wrap 0 [] (w:ws)\r\n | length w + 1 > width\r\n = wrap (length w) [w] ws\r\n wrap col line (w:ws)\r\n | col + length w + 1 > width\r\n = reverse line : wrap 0 [] (w:ws)\r\n wrap col line (w:ws)\r\n = let col' = col + length w + 1\r\n in wrap col' (w:line) ws\r\n wrap _ [] [] = []\r\n wrap _ line [] = [reverse line]\r\n}}}\r\n\r\nThere's also a more sophisticated version of this using the `Doc` type in the gtk2hs code gen utils. It has a parameter for the line width and handles prefix text on the first line.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3304define gcd 0 0 = 02019-07-07T19:04:30Zstevecdefine gcd 0 0 = 0Please make any comments on the libraries list by Tuesday 15th September 2009.
A suggestion to change 'gcd 0 0' from\[\[BR\]\]
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"\[\[BR\]\]
to\[\[BR\]\]
gcd 0 0 = 0
The proposal has been...Please make any comments on the libraries list by Tuesday 15th September 2009.
A suggestion to change 'gcd 0 0' from\[\[BR\]\]
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"\[\[BR\]\]
to\[\[BR\]\]
gcd 0 0 = 0
The proposal has been discussed on haskell-cafe\@haskell.org
http://www.haskell.org/pipermail/haskell-cafe/2009-May/060788.html
and there was a lot of support for the suggested change.
Current code:
libraries/base/GHC/Real.lhs
```
-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@
-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,
-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ raises a runtime error.
gcd :: (Integral a) => a -> a -> a
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y = gcd' (abs x) (abs y)
where gcd' a 0 = a
gcd' a b = gcd' b (a `rem` b)
```
Suggested code:
```
-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@
-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,
-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ is defined to be 0.
gcd :: (Integral a) => a -> a -> a
gcd x y = gcd' (abs x) (abs y)
where gcd' a 0 = a
gcd' a b = gcd' b (a `rem` b)
```
\[Note: I tried following the instructions at
http://www.haskell.org/haskellwiki/Library_submissions
to create a darcs patch. I successfully downloaded a copy of HEAD, but was unable to create a patch:
$ darcs record libraries/base/GHC/Real.lhs
Recording changes in "libraries/base/GHC/Real.lhs":
No changes in selected files or directories!
I would claim that the instructions are insufficient for a darcs beginner.
\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | libraries@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"define gcd 0 0 = 0","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["libraries@haskell.org"],"type":"Bug","description":"Please make any comments on the libraries list by Tuesday 15th September 2009. \r\n\r\nA suggestion to change 'gcd 0 0' from[[BR]]\r\ngcd 0 0 = error \"Prelude.gcd: gcd 0 0 is undefined\"[[BR]]\r\nto[[BR]]\r\ngcd 0 0 = 0\r\n\r\nThe proposal has been discussed on haskell-cafe@haskell.org\r\nhttp://www.haskell.org/pipermail/haskell-cafe/2009-May/060788.html\r\nand there was a lot of support for the suggested change.\r\n\r\nCurrent code:\r\nlibraries/base/GHC/Real.lhs \r\n\r\n{{{\r\n-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@\r\n-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,\r\n-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ raises a runtime error.\r\ngcd :: (Integral a) => a -> a -> a\r\ngcd 0 0 = error \"Prelude.gcd: gcd 0 0 is undefined\"\r\ngcd x y = gcd' (abs x) (abs y)\r\n where gcd' a 0 = a\r\n gcd' a b = gcd' b (a `rem` b)\r\n}}}\r\nSuggested code:\r\n{{{\r\n-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@\r\n-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,\r\n-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ is defined to be 0.\r\ngcd :: (Integral a) => a -> a -> a\r\ngcd x y = gcd' (abs x) (abs y)\r\n where gcd' a 0 = a\r\n gcd' a b = gcd' b (a `rem` b)\r\n}}}\r\n\r\n[Note: I tried following the instructions at\r\nhttp://www.haskell.org/haskellwiki/Library_submissions\r\nto create a darcs patch. I successfully downloaded a copy of HEAD, but was unable to create a patch:\r\n\r\n$ darcs record libraries/base/GHC/Real.lhs \r\nRecording changes in \"libraries/base/GHC/Real.lhs\":\r\n\r\nNo changes in selected files or directories!\r\n\r\nI would claim that the instructions are insufficient for a darcs beginner.\r\n]","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3305panic message "impossible happened" loadobj: failed loading SOE packages and ...2019-07-07T19:04:30Zdon vinnedgepanic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhsghc v. 6.10 error trying to run main1 in SOE.Animation.lhs package. No similar problem with ghc-6.8, which functions properly.
I have had this error with a cabal installed upgrade of SOE to the GL, gtk graphics libraries and with anothe...ghc v. 6.10 error trying to run main1 in SOE.Animation.lhs package. No similar problem with ghc-6.8, which functions properly.
I have had this error with a cabal installed upgrade of SOE to the GL, gtk graphics libraries and with another installation where I installed the SOE-2007.zip file to a folder and used ghc to compile each file individually.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic message \"impossible happened\" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc v. 6.10 error trying to run main1 in SOE.Animation.lhs package. No similar problem with ghc-6.8, which functions properly. \r\n\r\nI have had this error with a cabal installed upgrade of SOE to the GL, gtk graphics libraries and with another installation where I installed the SOE-2007.zip file to a folder and used ghc to compile each file individually.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3306Improve syntax for GADT + records2019-07-07T19:04:29ZSimon Peyton JonesImprove syntax for GADT + recordsThis [email thread](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017391.html) raised the question of defining data constructors that
- use GADT syntax
- and record syntax
- and have class constraints
This combinatio...This [email thread](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017391.html) raised the question of defining data constructors that
- use GADT syntax
- and record syntax
- and have class constraints
This combination isn't supported in GHC 6.10, but it's annoying that it isn't. The problem is just coming up with a plausible syntax. Probably the most plausible possibilities are
```
(A) data RecContTest a where
Show a => C { showable :: a } :: RecContTest a
(B) data RecContTest a where
C :: Show a => { showable :: a } -> RecContTest a
```
The latter (B) looks best to me. I dislike (A) because part of the type (the "Show a =\>") occurs before the constructor name C, and part appears after. On the other hand, (B) has something that looks vaguely like a type
```
{ x::ty, y::ty } -> ty
```
but that's not really valid type syntax. (Mind you, the ! marks in a constructor signature aren't part of valid types either, so maybe it's not so bad to have a special form in constructor declarations.)
But if we were going to adopt (B), then even when there is no class context we should really say
```
(B) data RecTest a where
B :: { arg :: a } -> RecTest a
```
rather than the current syntax which is
```
(A) data RecTest a where
B { arg :: a } :: RecTest a
```
\[Note the different placement of the double colon and arrow in (B).\]
My take on this
- (B) looks nicer, but it would represent a breaking change
- But perhaps not many people use record-style syntax + GADT-style syntax
- And better to make breaking changes sooner than later
Question for everyone:
- are (A) and (B) the only choices?
- do you agree (B) is best
There are some replies on the above email thread. Please add further opinions as comments to this ticket.6.12.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3307System.IO and System.Directory functions not Unicode-aware under Unix2019-07-07T19:04:29ZYitzGaleSystem.IO and System.Directory functions not Unicode-aware under UnixUnder Unix, file paths are represented as raw bytes in a String.
That is not user-friendly, because a String is supposed to be
decoded Unicode, and it is conventional in Unix to view those
raw bytes as encoded according to the current lo...Under Unix, file paths are represented as raw bytes in a String.
That is not user-friendly, because a String is supposed to be
decoded Unicode, and it is conventional in Unix to view those
raw bytes as encoded according to the current locale. In addition,
this is not consistent with Windows, where file paths are
natively Unicode and represented as such in the String.
(Well, they will be consistently once #3300 is completed.)
On the other hand, this raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.)
The following cases ought to work consistently for all file operations
in System.IO and System.Directory:
- A !FilePath from getArgs
- A !FilePath from getDirectoryContents
- A !FilePath in Unicode from a String literal,
- A !FilePath read from a Handle and decoded into Unicode
See discussion in the thread http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.IO and System.Directory functions not Unicode-aware under Unix","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["directory","unicode"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Under Unix, file paths are represented as raw bytes in a String.\r\nThat is not user-friendly, because a String is supposed to be\r\ndecoded Unicode, and it is conventional in Unix to view those\r\nraw bytes as encoded according to the current locale. In addition,\r\nthis is not consistent with Windows, where file paths are\r\nnatively Unicode and represented as such in the String.\r\n(Well, they will be consistently once #3300 is completed.)\r\n\r\nOn the other hand, this raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.)\r\n\r\nThe following cases ought to work consistently for all file operations\r\nin System.IO and System.Directory:\r\n\r\n * A !FilePath from getArgs\r\n * A !FilePath from getDirectoryContents\r\n * A !FilePath in Unicode from a String literal,\r\n * A !FilePath read from a Handle and decoded into Unicode\r\n\r\nSee discussion in the thread http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3308getArgs should return Unicode on Windows2019-07-07T19:04:29ZYitzGalegetArgs should return Unicode on WindowsThis is what is expected, and it is needed for file
paths read from the command-line to work (once
#3300 is completed).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --...This is what is expected, and it is needed for file
paths read from the command-line to work (once
#3300 is completed).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getArgs should return Unicode on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["unicode"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is what is expected, and it is needed for file\r\npaths read from the command-line to work (once\r\n#3300 is completed).","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3309getArgs should return Unicode on Unix2019-07-07T19:04:28ZYitzGalegetArgs should return Unicode on UnixThe raw bytes of args should be decoded according to the current locale.
An additional function should be added:
```
getArgsBytes :: IO [Word8]
```
to provide access to the raw bytes.
This change needs to be coordinated with #3007 so...The raw bytes of args should be decoded according to the current locale.
An additional function should be added:
```
getArgsBytes :: IO [Word8]
```
to provide access to the raw bytes.
This change needs to be coordinated with #3007 so that it will still
work to read a file name from the command line args and use it
to access a file.
This change should also be made on Windows: #3008
See the discussion at http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getArgs should return Unicode on Unix","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["unicode"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The raw bytes of args should be decoded according to the current locale.\r\n\r\nAn additional function should be added:\r\n{{{\r\ngetArgsBytes :: IO [Word8]\r\n}}}\r\nto provide access to the raw bytes.\r\n\r\nThis change needs to be coordinated with #3007 so that it will still\r\nwork to read a file name from the command line args and use it\r\nto access a file.\r\n\r\nThis change should also be made on Windows: #3008\r\n\r\nSee the discussion at http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1batterseapowerbatterseapowerhttps://gitlab.haskell.org/ghc/ghc/-/issues/3310`show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar`2019-07-07T19:04:28Zenolan`show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar``show BlockedIndefinitely` and `show BlockedOnDeadMVar` should, IMO, evaluate to inequal strings that reflect the difference in cause of the exception. Them being equal is confusing for programmers trying to find the source of their cras...`show BlockedIndefinitely` and `show BlockedOnDeadMVar` should, IMO, evaluate to inequal strings that reflect the difference in cause of the exception. Them being equal is confusing for programmers trying to find the source of their crashes when the exception is printed to console.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar`","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"`show BlockedIndefinitely` and `show BlockedOnDeadMVar` should, IMO, evaluate to inequal strings that reflect the difference in cause of the exception. Them being equal is confusing for programmers trying to find the source of their crashes when the exception is printed to console.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3311web page direct me to a tarball that can't build2019-07-07T19:04:27Zzookoweb page direct me to a tarball that can't buildI started here: http://hackage.haskell.org/trac/ghc/wiki/Building . Then I followed the link to "Getting the sources" and read the "Source distributions" section of this page: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheS...I started here: http://hackage.haskell.org/trac/ghc/wiki/Building . Then I followed the link to "Getting the sources" and read the "Source distributions" section of this page: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources , then followed the link to http://www.haskell.org/ghc/download.html and then downloaded a tarball named http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090617-src.tar.bz2 . This tarball doesn't have all the ingredients necessary to follow the instructions on the first page (wiki/Building). Some kind passerby took pity on me and directed me to download this tarball instead: http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2 . That one worked better. Perhaps the "Source distributions" section of http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources should point to that one instead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"web page direct me to a tarball that can't build","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I started here: http://hackage.haskell.org/trac/ghc/wiki/Building . Then I followed the link to \"Getting the sources\" and read the \"Source distributions\" section of this page: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources , then followed the link to http://www.haskell.org/ghc/download.html and then downloaded a tarball named http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090617-src.tar.bz2 . This tarball doesn't have all the ingredients necessary to follow the instructions on the first page (wiki/Building). Some kind passerby took pity on me and directed me to download this tarball instead: http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2 . That one worked better. Perhaps the \"Source distributions\" section of http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources should point to that one instead.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3312no darcs and no VERSION file2019-07-07T19:04:27Zzookono darcs and no VERSION fileTrying to port ghc to OpenBSD/sparc64 so that I can build darcs there so that I can use darcs, I got this tarball:
http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2
And then started following the instructions ...Trying to port ghc to OpenBSD/sparc64 so that I can build darcs there so that I can use darcs, I got this tarball:
http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2
And then started following the instructions on http://hackage.haskell.org/trac/ghc/wiki/Building/Porting . The `./configure --enable-hc-boot` step failed with:
```
configure: error: failed to detect version date: check that darcs is in your path
```
`find . -name '*VERSION*'` turned up no hits, so I guess that the `VERSION` file is being accidentally omitted from the tarball.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"no darcs and no VERSION file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to port ghc to OpenBSD/sparc64 so that I can build darcs there so that I can use darcs, I got this tarball:\r\n\r\nhttp://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2\r\n\r\nAnd then started following the instructions on http://hackage.haskell.org/trac/ghc/wiki/Building/Porting . The {{{./configure --enable-hc-boot}}} step failed with: \r\n\r\n{{{\r\nconfigure: error: failed to detect version date: check that darcs is in your path\r\n}}}\r\n\r\n{{{find . -name '*VERSION*'}}} turned up no hits, so I guess that the {{{VERSION}}} file is being accidentally omitted from the tarball.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3313Uncertain bug report (panic!)2019-07-07T19:04:27ZsemanticprecisionUncertain bug report (panic!)Hi,
I really have no clue what happened; ghc panic!'d without much info, as far as I can tell. I've attached the files I've been working with.
In attempting `:l imageloader` in ghc, a panic! is achieved. That's about the extent of it. ...Hi,
I really have no clue what happened; ghc panic!'d without much info, as far as I can tell. I've attached the files I've been working with.
In attempting `:l imageloader` in ghc, a panic! is achieved. That's about the extent of it. Everything was working fine (well, wan't compiling, but I ripped out the guts and was piecing it back together; but still, no crashing) until I changed the cast on line 26 of ImageLoader.hs.
(I'm a Haskell n00b, hence the overtly inefficient and poorly-formatted code)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Uncertain bug report (panic!)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nI really have no clue what happened; ghc panic!'d without much info, as far as I can tell. I've attached the files I've been working with.\r\n\r\nIn attempting `:l imageloader` in ghc, a panic! is achieved. That's about the extent of it. Everything was working fine (well, wan't compiling, but I ripped out the guts and was piecing it back together; but still, no crashing) until I changed the cast on line 26 of ImageLoader.hs.\r\n\r\n(I'm a Haskell n00b, hence the overtly inefficient and poorly-formatted code)","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3314Add compilation date to +RTS --info2019-07-07T19:04:27ZOrphiAdd compilation date to +RTS --infoI don't know how hard this would be, but it would be nice to add a timestamp in +RTS --info to show the date/time when the program was compiled.
Additionally, it would be nice to be able to get at this programmatically - System.Info wou...I don't know how hard this would be, but it would be nice to add a timestamp in +RTS --info to show the date/time when the program was compiled.
Additionally, it would be nice to be able to get at this programmatically - System.Info would seem a logical place. (Presumably if the program is interpreted rather than compiled, the "compilation time" would be the current time.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add compilation date to +RTS --info","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I don't know how hard this would be, but it would be nice to add a timestamp in +RTS --info to show the date/time when the program was compiled.\r\n\r\nAdditionally, it would be nice to be able to get at this programmatically - System.Info would seem a logical place. (Presumably if the program is interpreted rather than compiled, the \"compilation time\" would be the current time.)","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Evgenii AkentevEvgenii Akentevhttps://gitlab.haskell.org/ghc/ghc/-/issues/3315Add generalised "lookup" function2019-07-07T19:04:26ZskorpanAdd generalised "lookup" functionI think it would be very nice to have a default implementation of a generalised `lookup` function, such as `lookupWith`. The code I'm currently using is very simple and straight-forward:
```
lookupWith :: (a -> Bool) -> [(a, b)] -> Mayb...I think it would be very nice to have a default implementation of a generalised `lookup` function, such as `lookupWith`. The code I'm currently using is very simple and straight-forward:
```
lookupWith :: (a -> Bool) -> [(a, b)] -> Maybe b
lookupWith _ [] = Nothing
lookupWith p ((x, y):xs) | p x = Just y
| otherwise = lookupWith p xs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add generalised \"lookup\" function","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I think it would be very nice to have a default implementation of a generalised `lookup` function, such as `lookupWith`. The code I'm currently using is very simple and straight-forward:\r\n\r\n{{{\r\nlookupWith :: (a -> Bool) -> [(a, b)] -> Maybe b\r\nlookupWith _ [] = Nothing\r\nlookupWith p ((x, y):xs) | p x = Just y\r\n | otherwise = lookupWith p xs\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3316Deadlock in non-threaded RTS with hPutBuf2019-07-07T19:04:26ZganeshDeadlock in non-threaded RTS with hPutBufUsing the non-threaded RTS, the attached program works fine in 6.8.2, but deadlocks in 6.8.3 and later GHCs (including 6.10.3 and 6.11.20090618).
The program forks (runInteractiveProcess) two copies of cat, then forks off two separate t...Using the non-threaded RTS, the attached program works fine in 6.8.2, but deadlocks in 6.8.3 and later GHCs (including 6.10.3 and 6.11.20090618).
The program forks (runInteractiveProcess) two copies of cat, then forks off two separate threads (forkIO) to write a large buffer to stdin of each copy, and also lazily reads the outputs of each copy of cat, forcing the results with an equality test.
From strace, it looks like 6.8.2 is correctly selecting on multiple FDs at once (though just 3, rather than all 4, which I don't understand), whereas 6.8.3 doesn't and hence ends up in a deadlock when the pipe it wants to use blocks while some other pipe is actually ready.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deadlock in non-threaded RTS with hPutBuf","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using the non-threaded RTS, the attached program works fine in 6.8.2, but deadlocks in 6.8.3 and later GHCs (including 6.10.3 and 6.11.20090618).\r\n\r\nThe program forks (runInteractiveProcess) two copies of cat, then forks off two separate threads (forkIO) to write a large buffer to stdin of each copy, and also lazily reads the outputs of each copy of cat, forcing the results with an equality test.\r\n\r\nFrom strace, it looks like 6.8.2 is correctly selecting on multiple FDs at once (though just 3, rather than all 4, which I don't understand), whereas 6.8.3 doesn't and hence ends up in a deadlock when the pipe it wants to use blocks while some other pipe is actually ready.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3317Ctrl-C is not received during a call to runProcess2019-07-07T19:04:26ZjudahCtrl-C is not received during a call to runProcessThe following program runs `cat` as an external process, and tries to kill it if an exception such as ctrl-c is received.
```
module Main where
import System.Process
import Control.Exception (finally)
main = do
pid <- runProcess "...The following program runs `cat` as an external process, and tries to kill it if an exception such as ctrl-c is received.
```
module Main where
import System.Process
import Control.Exception (finally)
main = do
pid <- runProcess "cat" [] Nothing Nothing Nothing Nothing Nothing
waitForProcess pid `finally` do
putStrLn "killing"
terminateProcess pid
print "Done!"
```
With ghc-6.8.3, the subprocess is killed when ctrl-c is pressed. However, with ghc-6.10.3 the program acts oddly:
```
$ ./raw
^C^C
$ cat: stdin: Input/output error
```
The first time that ctrl-c is pressed, it is ignored. The second time, it kills the program (without calling the handler set by `finally`) but the cat program is still running.
I ran into this bug because it makes custom Cabal `Setup.hs` scripts unkillable by ctrl-c.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ctrl-C is not received during a call to runProcess","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program runs `cat` as an external process, and tries to kill it if an exception such as ctrl-c is received.\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Process\r\nimport Control.Exception (finally)\r\n\r\nmain = do\r\n pid <- runProcess \"cat\" [] Nothing Nothing Nothing Nothing Nothing\r\n waitForProcess pid `finally` do\r\n putStrLn \"killing\"\r\n terminateProcess pid\r\n print \"Done!\"\r\n}}}\r\nWith ghc-6.8.3, the subprocess is killed when ctrl-c is pressed. However, with ghc-6.10.3 the program acts oddly:\r\n\r\n{{{\r\n$ ./raw \r\n^C^C\r\n$ cat: stdin: Input/output error\r\n\r\n}}}\r\n\r\nThe first time that ctrl-c is pressed, it is ignored. The second time, it kills the program (without calling the handler set by `finally`) but the cat program is still running.\r\n\r\nI ran into this bug because it makes custom Cabal `Setup.hs` scripts unkillable by ctrl-c.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.4Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3318Export System.Process.syncProcess2019-07-07T19:04:26ZskorpanExport System.Process.syncProcessI don't see any reason as to why `syncProcess` is not exported from `System.Process`. It is only made available through `system` and `rawSystem`, which is not enough for running a synchronous process with redirected `stdout`, `stderr` an...I don't see any reason as to why `syncProcess` is not exported from `System.Process`. It is only made available through `system` and `rawSystem`, which is not enough for running a synchronous process with redirected `stdout`, `stderr` and `stdin`. Therefore, I propose that `syncProcess` is exported.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Export System.Process.syncProcess","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I don't see any reason as to why `syncProcess` is not exported from `System.Process`. It is only made available through `system` and `rawSystem`, which is not enough for running a synchronous process with redirected `stdout`, `stderr` and `stdin`. Therefore, I propose that `syncProcess` is exported.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3319Template Haskell generates invalid code for import foreign address declaration2019-07-07T19:04:26ZawsonTemplate Haskell generates invalid code for import foreign address declarationFor example, splicing `ForeignD (ImportF CCall Unsafe "&" (mkName "foo") (AppT (ConT ''Ptr) (ConT ''())))` GHC generates code equivalent to `foreign import ccall unsafe "foo" foo :: Ptr ()` but not `foreign import ccall unsafe "&" foo ::...For example, splicing `ForeignD (ImportF CCall Unsafe "&" (mkName "foo") (AppT (ConT ''Ptr) (ConT ''())))` GHC generates code equivalent to `foreign import ccall unsafe "foo" foo :: Ptr ()` but not `foreign import ccall unsafe "&" foo :: Ptr ()`.
-ddump-splices shows something like `foreign import ccall unsafe "static & &foo" foo :: Ptr ()`. GHC can splice this (and produce bogus code) but can not compile this code literally, generating invalid assembler name `_&foo` for `foo`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell generates invalid code for import foreign address declaration","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For example, splicing {{{ForeignD (ImportF CCall Unsafe \"&\" (mkName \"foo\") (AppT (ConT ''Ptr) (ConT ''())))}}} GHC generates code equivalent to {{{foreign import ccall unsafe \"foo\" foo :: Ptr ()}}} but not {{{foreign import ccall unsafe \"&\" foo :: Ptr ()}}}.\r\n\r\n-ddump-splices shows something like {{{foreign import ccall unsafe \"static & &foo\" foo :: Ptr ()}}}. GHC can splice this (and produce bogus code) but can not compile this code literally, generating invalid assembler name {{{_&foo}}} for {{{foo}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3320Parallel program crashes using GHC 6.11 under OS X2019-07-07T19:04:25ZsebfParallel program crashes using GHC 6.11 under OS XThe attached program dies with a bus error when compiled `-threaded` with GHC 6.11 under OS X on an Intel Mac Book Core 2 Duo and run with `-N3`. Using `-N1` or `-N2` works fine.
It also works when using GHC 6.10.3 under OS X or GHC 6.1...The attached program dies with a bus error when compiled `-threaded` with GHC 6.11 under OS X on an Intel Mac Book Core 2 Duo and run with `-N3`. Using `-N1` or `-N2` works fine.
It also works when using GHC 6.10.3 under OS X or GHC 6.11 under Linux.
```
$ ~/Applications/ghc/bin/ghc -v -fforce-recomp --make -threaded idfs
Glasgow Haskell Compiler, Version 6.11.20090618, for Haskell 98, stage 2 booted by GHC version 6.10.3
Using package config file: /Users/sebf/Applications/ghc/lib/ghc-6.11.20090618/package.conf
Using package config file: /Users/sebf/.ghc/i386-darwin-6.11.20090618/package.conf
hiding package base-3.0.3.0 to avoid conflict with later version base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package template-haskell mapped to template-haskell-2.4.0.0
wired-in package dph-seq mapped to dph-seq-0.4.0
wired-in package dph-par mapped to dph-par-0.4.0
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *idfs.hs
Stable obj: [Main]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Mon Jun 22 14:56:13 CEST 2009
ms_mod = main:Main,
ms_imps = [import Control.Parallel.Strategies (using, seqList, r0),
import Control.Parallel (par)]
ms_srcimps = []
}]
compile: input file idfs.hs
Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( idfs.hs, idfs.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 512
*** Simplifier Phase gentle:
Result size = 297
Result size = 297
*** Specialise:
Result size = 297
*** Float inwards:
Result size = 297
*** Simplifier Phase 2 [main]:
Result size = 421
Result size = 364
Result size = 295
Result size = 287
Result size = 287
*** Simplifier Phase 1 [main]:
Result size = 251
Result size = 251
*** Simplifier Phase 0 [main]:
Result size = 372
Result size = 323
Result size = 316
*** Demand analysis:
Result size = 316
*** Worker Wrapper binds:
Result size = 351
*** GlomBinds:
*** Simplifier Phase 0 [post-worker-wrapper]:
Result size = 344
Result size = 325
*** Common sub-expression:
Result size = 324
*** Float inwards:
Result size = 324
*** Simplifier Phase 0 [final]:
Result size = 325
Result size = 325
*** Tidy Core:
Result size = 325
*** CorePrep:
Result size = 408
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s -o idfs.o -DDONT_WANT_WIN32_DLL_SUPPORT
*** Deleting temp files:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s
Upsweep completely successful.
*** Deleting temp files:
Deleting:
link: linkables are ...
LinkableM (Mon Jun 22 15:12:56 CEST 2009) main:Main
[DotO idfs.o]
Linking idfs ...
*** Linker:
gcc -v -o idfs -DDONT_WANT_WIN32_DLL_SUPPORT idfs.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -Wl,-search_paths_first -read_only_relocs warning -lHSffi -framework GMP -lpthread
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)
/usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7 -read_only_relocs warning -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -o idfs -lcrt1.10.5.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../.. idfs.o -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -search_paths_first -lHSffi -framework GMP -lpthread -lgcc_s.10.5 -lgcc -lSystem
link: done
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0
$ ./idfs
500
$ ./idfs +RTS -N1
500
$ ./idfs +RTS -N2
500
$ ./idfs +RTS -N3
Bus error
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sebf@informatik.uni-kiel.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel program crashes using GHC 6.11 under OS X","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sebf@informatik.uni-kiel.de"],"type":"Bug","description":"The attached program dies with a bus error when compiled {{{-threaded}}} with GHC 6.11 under OS X on an Intel Mac Book Core 2 Duo and run with {{{-N3}}}. Using {{{-N1}}} or {{{-N2}}} works fine.\r\n\r\nIt also works when using GHC 6.10.3 under OS X or GHC 6.11 under Linux.\r\n\r\n{{{\r\n$ ~/Applications/ghc/bin/ghc -v -fforce-recomp --make -threaded idfs\r\nGlasgow Haskell Compiler, Version 6.11.20090618, for Haskell 98, stage 2 booted by GHC version 6.10.3\r\nUsing package config file: /Users/sebf/Applications/ghc/lib/ghc-6.11.20090618/package.conf\r\nUsing package config file: /Users/sebf/.ghc/i386-darwin-6.11.20090618/package.conf\r\nhiding package base-3.0.3.0 to avoid conflict with later version base-4.1.0.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.0\r\nwired-in package base mapped to base-4.1.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package template-haskell mapped to template-haskell-2.4.0.0\r\nwired-in package dph-seq mapped to dph-seq-0.4.0\r\nwired-in package dph-par mapped to dph-par-0.4.0\r\nHsc static flags: -static\r\n*** Chasing dependencies:\r\nChasing modules from: *idfs.hs\r\nStable obj: [Main]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Mon Jun 22 14:56:13 CEST 2009\r\n ms_mod = main:Main,\r\n ms_imps = [import Control.Parallel.Strategies (using, seqList, r0),\r\n import Control.Parallel (par)]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file idfs.hs\r\nCreated temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( idfs.hs, idfs.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 512\r\n*** Simplifier Phase gentle:\r\n Result size = 297\r\n Result size = 297\r\n*** Specialise:\r\n Result size = 297\r\n*** Float inwards:\r\n Result size = 297\r\n*** Simplifier Phase 2 [main]:\r\n Result size = 421\r\n Result size = 364\r\n Result size = 295\r\n Result size = 287\r\n Result size = 287\r\n*** Simplifier Phase 1 [main]:\r\n Result size = 251\r\n Result size = 251\r\n*** Simplifier Phase 0 [main]:\r\n Result size = 372\r\n Result size = 323\r\n Result size = 316\r\n*** Demand analysis:\r\n Result size = 316\r\n*** Worker Wrapper binds:\r\n Result size = 351\r\n*** GlomBinds:\r\n*** Simplifier Phase 0 [post-worker-wrapper]:\r\n Result size = 344\r\n Result size = 325\r\n*** Common sub-expression:\r\n Result size = 324\r\n*** Float inwards:\r\n Result size = 324\r\n*** Simplifier Phase 0 [final]:\r\n Result size = 325\r\n Result size = 325\r\n*** Tidy Core:\r\n Result size = 325\r\n*** CorePrep:\r\n Result size = 408\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** CodeOutput:\r\n*** Assembler:\r\ngcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s -o idfs.o -DDONT_WANT_WIN32_DLL_SUPPORT\r\n*** Deleting temp files:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\nlink: linkables are ...\r\nLinkableM (Mon Jun 22 15:12:56 CEST 2009) main:Main\r\n [DotO idfs.o]\r\nLinking idfs ...\r\n*** Linker:\r\ngcc -v -o idfs -DDONT_WANT_WIN32_DLL_SUPPORT idfs.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -Wl,-search_paths_first -read_only_relocs warning -lHSffi -framework GMP -lpthread\r\nUsing built-in specs.\r\nTarget: i686-apple-darwin9\r\nConfigured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9\r\nThread model: posix\r\ngcc version 4.0.1 (Apple Inc. build 5488)\r\n /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7 -read_only_relocs warning -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -o idfs -lcrt1.10.5.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../.. idfs.o -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -search_paths_first -lHSffi -framework GMP -lpthread -lgcc_s.10.5 -lgcc -lSystem\r\nlink: done\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0\r\n\r\n$ ./idfs \r\n500\r\n\r\n$ ./idfs +RTS -N1\r\n500\r\n\r\n$ ./idfs +RTS -N2\r\n500\r\n\r\n$ ./idfs +RTS -N3\r\nBus error\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3321-fhpc assumes original sources relative to the current directory2019-07-07T19:04:25Zduncan-fhpc assumes original sources relative to the current directoryFor the most part, ghc can be invoked in a manner that is independent of the current directory by suitable use of `-i` options.
With `-fhpc` it appears that the hpc bits always look in the current directory to find original source files...For the most part, ghc can be invoked in a manner that is independent of the current directory by suitable use of `-i` options.
With `-fhpc` it appears that the hpc bits always look in the current directory to find original source files.
Consider the following file layout:
```
Codec/Compression/Zlib/Stream.hsc
dist/build/Codec/Compression/Zlib/Stream.hs
examples/gunzip.hs
```
Now if we `cd` to `examples` and run:
```
ghc --make gunzip.hs -lz -i../ -i../dist/build
```
then it works fine. It finds `Codec/Compression/Zlib/Stream.hs` in `../dist/build` and it never bothers to look for the original source of course.
Now in `-fhpc` mode it has to also find the original sources so that it can match things back to them. However just adding -fhpc to the above command fails:
```
ghc --make gunzip.hs -lz -i../ -i../dist/build -fhpc
[1 of 4] Compiling Codec.Compression.Zlib.Stream ( ../dist/build/Codec/Compression/Zlib/Stream.hs, ../dist/build/Codec/Compression/Zlib/Stream.o )
Codec/Compression/Zlib/Stream.hsc: getModificationTime: does not exist (No such file or directory)
```
So it's clearly not looking in the directory given by `-i..` for the original sources. Also, the failure mode is a bit unfriendly.
Cabal sometimes takes advantage of the fact that ghc can be invoked in a manner that is independent of the current directory, and we would like to add hpc support into Cabal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fhpc assumes original sources relative to the current directory","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the most part, ghc can be invoked in a manner that is independent of the current directory by suitable use of `-i` options.\r\n\r\nWith `-fhpc` it appears that the hpc bits always look in the current directory to find original source files.\r\n\r\nConsider the following file layout:\r\n{{{\r\nCodec/Compression/Zlib/Stream.hsc\r\ndist/build/Codec/Compression/Zlib/Stream.hs\r\nexamples/gunzip.hs\r\n}}}\r\n\r\nNow if we `cd` to `examples` and run:\r\n{{{\r\nghc --make gunzip.hs -lz -i../ -i../dist/build\r\n}}}\r\nthen it works fine. It finds `Codec/Compression/Zlib/Stream.hs` in `../dist/build` and it never bothers to look for the original source of course.\r\n\r\nNow in `-fhpc` mode it has to also find the original sources so that it can match things back to them. However just adding -fhpc to the above command fails:\r\n{{{\r\nghc --make gunzip.hs -lz -i../ -i../dist/build -fhpc\r\n[1 of 4] Compiling Codec.Compression.Zlib.Stream ( ../dist/build/Codec/Compression/Zlib/Stream.hs, ../dist/build/Codec/Compression/Zlib/Stream.o )\r\nCodec/Compression/Zlib/Stream.hsc: getModificationTime: does not exist (No such file or directory)\r\n}}}\r\n\r\nSo it's clearly not looking in the directory given by `-i..` for the original sources. Also, the failure mode is a bit unfriendly.\r\n\r\nCabal sometimes takes advantage of the fact that ghc can be invoked in a manner that is independent of the current directory, and we would like to add hpc support into Cabal.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3322Tag base libraries2019-07-07T19:04:25ZYitzGaleTag base librariesPlease tag the base libraries, so that we can darcs get --partial and submit
patches with sane context.
Thanks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------...Please tag the base libraries, so that we can darcs get --partial and submit
patches with sane context.
Thanks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Tag base libraries","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Please tag the base libraries, so that we can darcs get --partial and submit\r\npatches with sane context.\r\n\r\nThanks.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3323panic: funArgTy2019-07-07T19:04:25ZSimon Marlowpanic: funArgTyThe following module crashes GHC 6.11.20090615:
```
module V where
import GHC.IO.Handle.Types
import GHC.IO.Handle.Internals
f :: Handle -> IO ()
f hdl = withHandle_ "" hdl $ \h -> return h{haDevice=undefined}
```
results:
```
$ ghc...The following module crashes GHC 6.11.20090615:
```
module V where
import GHC.IO.Handle.Types
import GHC.IO.Handle.Internals
f :: Handle -> IO ()
f hdl = withHandle_ "" hdl $ \h -> return h{haDevice=undefined}
```
results:
```
$ ghc-testing2 --make V.hs
[1 of 1] Compiling V ( V.hs, V.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 6.11.20090615 for x86_64-unknown-linux):
funArgTy ghc-prim:GHC.Unit.(){(w) tc 40}
```
It imports some internals of the IO library; I tried to reproduce it with a completely standalone module, but failed. The field `haDevice` of `Handle__` has existential type - normally GHC rejects a record update when the field has existential type, but does not in this case, I'm not sure why.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic: funArgTy","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following module crashes GHC 6.11.20090615:\r\n\r\n{{{\r\nmodule V where\r\n\r\nimport GHC.IO.Handle.Types\r\nimport GHC.IO.Handle.Internals\r\n\r\nf :: Handle -> IO ()\r\nf hdl = withHandle_ \"\" hdl $ \\h -> return h{haDevice=undefined}\r\n}}}\r\n\r\nresults:\r\n\r\n{{{\r\n$ ghc-testing2 --make V.hs\r\n[1 of 1] Compiling V ( V.hs, V.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 6.11.20090615 for x86_64-unknown-linux):\r\n funArgTy ghc-prim:GHC.Unit.(){(w) tc 40}\r\n}}}\r\n\r\nIt imports some internals of the IO library; I tried to reproduce it with a completely standalone module, but failed. The field `haDevice` of `Handle__` has existential type - normally GHC rejects a record update when the field has existential type, but does not in this case, I'm not sure why.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3324Add Foldable and Traversable instances for ((,) a)2019-07-07T19:04:24ZYitzGaleAdd Foldable and Traversable instances for ((,) a)These instances are pretty obvious, and no
more or less trivial than the existing instances
for Prelude types. I have found them to be
useful.
Since we are touching these modules anyway,
I am attaching two additional minor patches to th...These instances are pretty obvious, and no
more or less trivial than the existing instances
for Prelude types. I have found them to be
useful.
Since we are touching these modules anyway,
I am attaching two additional minor patches to this
proposal.
One is to add a few additional explicit method
implementations in the Foldable and Traversable
instances for Prelude types. These might sometimes
be slightly more efficient, and they better match
the strictness and style of the existing explicit method
implementations.
The other is to fix the documentation for the functions
fmapDefault and foldMapDefault in Data.Traversable.
Contrary to what is stated, these cannot be used
as methods in superclasses, since the superclasses
must already exist before these functions can be
defined. Instead, I have paraphrased what
is stated in the documentation above: that the
corresponding superclass methods should be
equivalent to these.
Discussion period: two weeks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Foldable and Traversable instances for ((,) a)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"These instances are pretty obvious, and no\r\nmore or less trivial than the existing instances\r\nfor Prelude types. I have found them to be\r\nuseful.\r\n\r\nSince we are touching these modules anyway,\r\nI am attaching two additional minor patches to this\r\nproposal.\r\n\r\nOne is to add a few additional explicit method\r\nimplementations in the Foldable and Traversable\r\ninstances for Prelude types. These might sometimes\r\nbe slightly more efficient, and they better match\r\nthe strictness and style of the existing explicit method\r\nimplementations.\r\n\r\nThe other is to fix the documentation for the functions\r\nfmapDefault and foldMapDefault in Data.Traversable.\r\nContrary to what is stated, these cannot be used\r\nas methods in superclasses, since the superclasses\r\nmust already exist before these functions can be\r\ndefined. Instead, I have paraphrased what\r\nis stated in the documentation above: that the\r\ncorresponding superclass methods should be\r\nequivalent to these.\r\n\r\nDiscussion period: two weeks.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3325ghci debugger sometime doesn't notice that Integers are Integers2019-07-07T19:04:24ZIan Lynagh <igloo@earth.li>ghci debugger sometime doesn't notice that Integers are IntegersThe ghci debugger sometime doesn't notice that Integers are Integers.
For example:
```
--- ./ghci.debugger/scripts/2740.stdout.normalised 2009-06-23 12:52:07.000000000 +0100
+++ ./ghci.debugger/scripts/2740.run.stdout.normalised 2009...The ghci debugger sometime doesn't notice that Integers are Integers.
For example:
```
--- ./ghci.debugger/scripts/2740.stdout.normalised 2009-06-23 12:52:07.000000000 +0100
+++ ./ghci.debugger/scripts/2740.run.stdout.normalised 2009-06-23 12:52:07.000000000 +0100
@@ -6,5 +6,5 @@
y :: a = _
x = (_t1::a)
y = (_t2::a)
-x = 1
-y = 2
+x = GHC.Integer.GMP.Internals.S# 1
+y = GHC.Integer.GMP.Internals.S# 2
*** unexpected failure for 2740(ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci debugger sometime doesn't notice that Integers are Integers","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The ghci debugger sometime doesn't notice that Integers are Integers.\r\n\r\nFor example:\r\n{{{\r\n--- ./ghci.debugger/scripts/2740.stdout.normalised 2009-06-23 12:52:07.000000000 +0100\r\n+++ ./ghci.debugger/scripts/2740.run.stdout.normalised 2009-06-23 12:52:07.000000000 +0100\r\n@@ -6,5 +6,5 @@\r\n y :: a = _\r\n x = (_t1::a)\r\n y = (_t2::a)\r\n-x = 1\r\n-y = 2\r\n+x = GHC.Integer.GMP.Internals.S# 1\r\n+y = GHC.Integer.GMP.Internals.S# 2\r\n*** unexpected failure for 2740(ghci)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3326the recompilation checker should take CPP flags into account2019-07-07T19:04:24Zbkomuvesthe recompilation checker should take CPP flags into accountThe C preprocessor can be used (or maybe abused) to provide different configurations of the same program. I often build programs with a command like
`ghc --make -DOPTION1 -DOPTION3 main.hs`
Now if I try to rebuild with different CPP fl...The C preprocessor can be used (or maybe abused) to provide different configurations of the same program. I often build programs with a command like
`ghc --make -DOPTION1 -DOPTION3 main.hs`
Now if I try to rebuild with different CPP flags, ghc won't recompile anything, since no source file changed (however, they become different after the CPP pass).
Ticket #437 is loosely related.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"the recompilation checker should take CPP flags into account","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The C preprocessor can be used (or maybe abused) to provide different configurations of the same program. I often build programs with a command like\r\n\r\n{{{ghc --make -DOPTION1 -DOPTION3 main.hs}}}\r\n\r\nNow if I try to rebuild with different CPP flags, ghc won't recompile anything, since no source file changed (however, they become different after the CPP pass).\r\n\r\nTicket #437 is loosely related. ","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3327Cannot paste into ghci on windows2019-07-07T19:04:24ZbomlCannot paste into ghci on windowsOnly the first character of the string that one tries to paste into the console actually gets pasted.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versi...Only the first character of the string that one tries to paste into the console actually gets pasted.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot paste into ghci on windows","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Only the first character of the string that one tries to paste into the console actually gets pasted.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.4https://gitlab.haskell.org/ghc/ghc/-/issues/3328base's FD.hs defines and exports setNonBlockingMode on Windows hosts2019-07-07T19:04:24Zshubase's FD.hs defines and exports setNonBlockingMode on Windows hosts1. 11 currently does not compile under Windows due to `setNonBlockingMode` in base/GHC/IO/FD.hs.
I'm not sure what the behavior of it should be on Windows, perhaps identity on `fd`:
```
setNonBlockingMode :: FD -> Bool -> IO FD
#ifndef...1. 11 currently does not compile under Windows due to `setNonBlockingMode` in base/GHC/IO/FD.hs.
I'm not sure what the behavior of it should be on Windows, perhaps identity on `fd`:
```
setNonBlockingMode :: FD -> Bool -> IO FD
#ifndef mingw32_HOST_OS
setNonBlockingMode fd set = do
setNonBlockingFD (fdFD fd) set
return fd{ fdIsNonBlocking = fromEnum set }
#else
setNonBlockingMode fd _ = return fd
#endif
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"base's FD.hs defines exports setNonBlockingMode on Windows hosts","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"6.11 currently does not compile under Windows due to `setNonBlockingMode` in base/GHC/IO/FD.hs.\r\n\r\nI'm not sure what the behavior of it should be on Windows, perhaps identity on `fd`:\r\n\r\n{{{\r\nsetNonBlockingMode :: FD -> Bool -> IO FD\r\n#ifndef mingw32_HOST_OS\r\nsetNonBlockingMode fd set = do \r\n setNonBlockingFD (fdFD fd) set\r\n return fd{ fdIsNonBlocking = fromEnum set }\r\n#else\r\nsetNonBlockingMode fd _ = return fd\r\n#endif\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3329Errors Building 6.10.3 on NetBSD 4.02019-07-07T19:04:23ZcjsErrors Building 6.10.3 on NetBSD 4.0Trying to build 6.10.3 using 6.8.2 on an amd64 NetBSD 4.0, I ran into several problems.
1. `./configure --with-gmp-includes=/usr/pkg/include --with-gmp-libraries=/usr/pkg/lib` did not work; the build system could not find gmp.h. Changin...Trying to build 6.10.3 using 6.8.2 on an amd64 NetBSD 4.0, I ran into several problems.
1. `./configure --with-gmp-includes=/usr/pkg/include --with-gmp-libraries=/usr/pkg/lib` did not work; the build system could not find gmp.h. Changing libraries/Makefile to give the cabal setup command `--extra-include-dirs=/usr/pkg/include --extra-lib-dirs=/usr/pkg/lib` let it find the include file, but it still couldn't find the library. I finally had to symlink `/usr/lib/libgmp.so.3` to `/usr/pkg/lib/libgmp.so.3` to get it to compile and link.
1. It seems that the installPackage package triggers some thread issues:
```
gmake -C installPackage with-stage-2
gmake[3]: Entering directory `/usr/local/ghc/src/ghc-6.10.3/utils/installPackage'
/usr/local/ghc/src/ghc-6.10.3/libraries/cabal-bin /usr/pkg/bin/ghc /usr/local/ghc/src/ghc-6.10.3/libraries/bootstrapping.conf 1.6.0.3 configure --distpref dist-install \
--prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \
--with-compiler=/usr/local/ghc/src/ghc-6.10.3/ghc/stage2-inplace/ghc --with-hc-pkg=/usr/local/ghc/src/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc-pkg --package-db /usr/local/ghc/src/ghc-6.10.3/stage3.package.conf \
--libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --hsc2hs-option=-I/usr/pkg/include --configure-option='--with-gmp-includes=/usr/pkg/include' --configure-option='--with-gmp-libraries=/usr/pkg/lib' --configure-option=--with-cc="gcc" --with-hsc2hs=/usr/local/ghc/src/ghc-6.10.3/utils/hsc2hs/install-inplace/bin/hsc2hs \
--constraint="Cabal == 1.6.0.3"
Configuring installPackage-1.0...
ghc: Error detected by libpthread: Invalid mutex.
Detected by file "/u/production/nbsd/instance/nbsd/src-4/lib/libpthread/pthread_mutex.c", line 334, function "pthread_mutex_unlock".
See pthread(3) for information.
gmake[3]: *** [with-stage-2] Error 134
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Errors Building 6.10.3 on NetBSD 4.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to build 6.10.3 using 6.8.2 on an amd64 NetBSD 4.0, I ran into several problems.\r\n\r\n1. `./configure --with-gmp-includes=/usr/pkg/include --with-gmp-libraries=/usr/pkg/lib` did not work; the build system could not find gmp.h. Changing libraries/Makefile to give the cabal setup command `--extra-include-dirs=/usr/pkg/include --extra-lib-dirs=/usr/pkg/lib` let it find the include file, but it still couldn't find the library. I finally had to symlink `/usr/lib/libgmp.so.3` to `/usr/pkg/lib/libgmp.so.3` to get it to compile and link.\r\n\r\n2. It seems that the installPackage package triggers some thread issues:\r\n{{{\r\ngmake -C installPackage with-stage-2\r\ngmake[3]: Entering directory `/usr/local/ghc/src/ghc-6.10.3/utils/installPackage'\r\n/usr/local/ghc/src/ghc-6.10.3/libraries/cabal-bin /usr/pkg/bin/ghc /usr/local/ghc/src/ghc-6.10.3/libraries/bootstrapping.conf 1.6.0.3 configure --distpref dist-install \\\r\n --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \\\r\n --with-compiler=/usr/local/ghc/src/ghc-6.10.3/ghc/stage2-inplace/ghc --with-hc-pkg=/usr/local/ghc/src/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc-pkg --package-db /usr/local/ghc/src/ghc-6.10.3/stage3.package.conf \\\r\n --libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --hsc2hs-option=-I/usr/pkg/include --configure-option='--with-gmp-includes=/usr/pkg/include' --configure-option='--with-gmp-libraries=/usr/pkg/lib' --configure-option=--with-cc=\"gcc\" --with-hsc2hs=/usr/local/ghc/src/ghc-6.10.3/utils/hsc2hs/install-inplace/bin/hsc2hs \\\r\n --constraint=\"Cabal == 1.6.0.3\"\r\nConfiguring installPackage-1.0...\r\nghc: Error detected by libpthread: Invalid mutex.\r\nDetected by file \"/u/production/nbsd/instance/nbsd/src-4/lib/libpthread/pthread_mutex.c\", line 334, function \"pthread_mutex_unlock\".\r\nSee pthread(3) for information.\r\ngmake[3]: *** [with-stage-2] Error 134\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3330Type checker hangs2019-07-07T19:04:23ZMartijnVanSteenbergenType checker hangsThe following module causes `ghc --make` and `ghci` to hang. `-ddump-tc-trace` produces output indefinitely.
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE FlexibleContexts #-}
import Generics.MultiRec
import Control.Monad.Writer
data AnyF s...The following module causes `ghc --make` and `ghci` to hang. `-ddump-tc-trace` produces output indefinitely.
```
{-# LANGUAGE GADTs #-}
{-# LANGUAGE FlexibleContexts #-}
import Generics.MultiRec
import Control.Monad.Writer
data AnyF s f where
AnyF :: s ix -> f ix -> AnyF s f
children :: HFunctor s (PF s) => s ix -> (PF s) r ix -> [AnyF s r]
children p x = execWriter (hmapM p collect x) where
collect :: (HFunctor s (PF s)) => s ix -> r ix -> Writer [AnyF s r] (r ix)
collect w x = tell [AnyF w x] >> return x
```
Module `Generics.MultiRec` is from Hackage package `multirec-0.4`.
The code contains a type error: if arguments `p` and `collect` are swapped the code compiles fine.
I haven't tried making this example any smaller.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Type checker hangs","status":"New","operating_system":"Unknown/Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The following module causes `ghc --make` and `ghci` to hang. `-ddump-tc-trace` produces output indefinitely.\r\n\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n\r\nimport Generics.MultiRec\r\nimport Control.Monad.Writer\r\n\r\ndata AnyF s f where\r\n AnyF :: s ix -> f ix -> AnyF s f\r\n\r\nchildren :: HFunctor s (PF s) => s ix -> (PF s) r ix -> [AnyF s r]\r\nchildren p x = execWriter (hmapM p collect x) where\r\n collect :: (HFunctor s (PF s)) => s ix -> r ix -> Writer [AnyF s r] (r ix)\r\n collect w x = tell [AnyF w x] >> return x\r\n}}}\r\n\r\nModule `Generics.MultiRec` is from Hackage package `multirec-0.4`.\r\n\r\nThe code contains a type error: if arguments `p` and `collect` are swapped the code compiles fine.\r\n\r\nI haven't tried making this example any smaller.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/3331control-monad-queue performance regression2019-07-07T19:04:23ZLeon P Smithleon.p.smith@gmail.comcontrol-monad-queue performance regression```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC...```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"control-monad-queue performance regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cabal unpack control-monad-queue\r\n$ cd control-monad-queue-0.0.9.1/tests\r\n$ ghc --make -O2 Time.hs -i..\r\n$ ./Time allison 34 20\r\n$ ./Time corec1 34 20\r\n$ ./Time corec2 34 20\r\n}}}\r\n\r\nRuns anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3332take n (take m list) returns [] for some m.2019-07-07T19:04:22Zfcameltake n (take m list) returns [] for some m.See the example below. I think the second output should be \[1\], too.
I also tried ghc and runghc, and the results were the same.
```
ghci> take 1 (take (10^11) [1..])
[1]
it :: [Integer]
ghci> take 1 (take (10^12) [1..])
[]
it :: [Int...See the example below. I think the second output should be \[1\], too.
I also tried ghc and runghc, and the results were the same.
```
ghci> take 1 (take (10^11) [1..])
[1]
it :: [Integer]
ghci> take 1 (take (10^12) [1..])
[]
it :: [Integer]
ghci> take 1 (take (10^13) [1..])
[1]
it :: [Integer]
```
<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":"take n (take m list) returns [] for some m.","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":"See the example below. I think the second output should be [1], too.\r\nI also tried ghc and runghc, and the results were the same.\r\n\r\n{{{\r\nghci> take 1 (take (10^11) [1..])\r\n[1]\r\nit :: [Integer]\r\nghci> take 1 (take (10^12) [1..])\r\n[]\r\nit :: [Integer]\r\nghci> take 1 (take (10^13) [1..])\r\n[1]\r\nit :: [Integer]\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3333GHCi doesn't load weak symbols2019-07-07T19:04:22Zred5_2@hotmail.comGHCi doesn't load weak symbolsGHCi fails to load modules with weak symbols. The compiler, in contrast, has no trouble with them. The attached Cabal package demonstrates the problem. After building and installing:
```
:Prelude> :m +WeakTest
Prelude WeakTest> weak_tes...GHCi fails to load modules with weak symbols. The compiler, in contrast, has no trouble with them. The attached Cabal package demonstrates the problem. After building and installing:
```
:Prelude> :m +WeakTest
Prelude WeakTest> weak_test 0
Loading package WeakTest-0 ... linking ... <interactive>: /home/heatsink/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown symbol `weak_test'
```
I encountered this problem while trying to build a package that contains C++ code. Because GCC generates weak symbols when compiling C++, libraries that contain C++ code will not work in GHCi. (Granted, this is not the only problem with mixing C++ and Haskell.)8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3334Strange closure type error on macports GHC 6.10.12019-07-07T19:04:21ZcrutcherStrange closure type error on macports GHC 6.10.1user 0m2.453s
sys 0m0.396s
crutcher-mac:\~/haskell crutcher$ time ./cell +RTS -N2
cell: internal error: evacuate: strange closure type 63559
(GHC version 6.10.1 for i386_apple_darwin)
> Please report this as a GHC bug: http://www.has...user 0m2.453s
sys 0m0.396s
crutcher-mac:\~/haskell crutcher$ time ./cell +RTS -N2
cell: internal error: evacuate: strange closure type 63559
(GHC version 6.10.1 for i386_apple_darwin)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
real 0m1.258s
user 0m1.459s
sys 0m0.203s
crutcher-mac:\~/haskell crutcher$ ls
Cell.hi Cell.hs Cell.o cell rwh.4.hs
crutcher-mac:\~/haskell crutcher$ rm Cell.hi Cell.o cell
crutcher-mac:\~/haskell crutcher$ ghc -O2 Cell.hs -o cell --make -threaded
\[1 of 1\] Compiling Main ( Cell.hs, Cell.o )
Linking cell ...
crutcher-mac:\~/haskell crutcher$ time ./cell +RTS -N2
cell: internal error: evacuate: strange closure type 34063
(GHC version 6.10.1 for i386_apple_darwin)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
real 0m0.730s
user 0m0.826s
sys 0m0.122s
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Strange closure type error on macports GHC 6.10.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nuser 0m2.453s\r\nsys 0m0.396s\r\ncrutcher-mac:~/haskell crutcher$ time ./cell +RTS -N2 \r\ncell: internal error: evacuate: strange closure type 63559\r\n (GHC version 6.10.1 for i386_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n\r\nreal 0m1.258s\r\nuser 0m1.459s\r\nsys 0m0.203s\r\ncrutcher-mac:~/haskell crutcher$ ls\r\nCell.hi Cell.hs Cell.o cell rwh.4.hs\r\ncrutcher-mac:~/haskell crutcher$ rm Cell.hi Cell.o cell\r\ncrutcher-mac:~/haskell crutcher$ ghc -O2 Cell.hs -o cell --make -threaded\r\n[1 of 1] Compiling Main ( Cell.hs, Cell.o )\r\nLinking cell ...\r\ncrutcher-mac:~/haskell crutcher$ time ./cell +RTS -N2 \r\ncell: internal error: evacuate: strange closure type 34063\r\n (GHC version 6.10.1 for i386_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nreal 0m0.730s\r\nuser 0m0.826s\r\nsys 0m0.122s","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3335make some Applicative functions into methods, and split off Data.Functor2019-07-07T19:04:21ZRoss Patersonr.paterson@city.ac.ukmake some Applicative functions into methods, and split off Data.FunctorThe following functions
```
(<$) :: Functor f => a -> f b -> f a
(*>) :: Applicative f => f a -> f b -> f b
(<*) :: Applicative f => f a -> f b -> f a
some :: Alternative f => f a -> f [a]
many :: Alternative f => f a -> f [a]
```
a...The following functions
```
(<$) :: Functor f => a -> f b -> f a
(*>) :: Applicative f => f a -> f b -> f b
(<*) :: Applicative f => f a -> f b -> f a
some :: Alternative f => f a -> f [a]
many :: Alternative f => f a -> f [a]
```
are moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions.
Although (\<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (\<$\>). These are also re-exported by Control.Applicative.
Discussion on libraries\@haskell.org to 20th July 2009.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make some Applicative functions into methods, and split off Data.Functor","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following functions\r\n{{{\r\n(<$) :: Functor f => a -> f b -> f a \r\n(*>) :: Applicative f => f a -> f b -> f b \r\n(<*) :: Applicative f => f a -> f b -> f a \r\nsome :: Alternative f => f a -> f [a]\r\nmany :: Alternative f => f a -> f [a]\r\n}}}\r\nare moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions.\r\n\r\nAlthough (<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (<$>). These are also re-exported by Control.Applicative.\r\n\r\nDiscussion on libraries@haskell.org to 20th July 2009.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3336Following gcc behaviour with regards to calling conventions on x86_642019-07-07T19:04:21ZJeffersonHeardFollowing gcc behaviour with regards to calling conventions on x86_64http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx
Right now, if anything other than ccall is given to ghc on x86_64 architectures, ghc errors out with the complaint that the calling convention is not supported on this architect...http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx
Right now, if anything other than ccall is given to ghc on x86_64 architectures, ghc errors out with the complaint that the calling convention is not supported on this architecture. gcc on the other hand, handles this situation gracefully, ignoring the calling convention attribute. My thought is that ghc should do this as well.
Currently, I get this:
```
TerraHS/TerraLib/TePoint.hs:121:0:
calling convention not supported on this architecture: stdcall
When checking declaration:
foreign import stdcall unsafe "static &c_tepoint_setobjectid" tepoint_setobjectid
:: TePointPtr -> CString -> IO ()
```
I think I should instead get a warning saying that the calling convention is being ignored.https://gitlab.haskell.org/ghc/ghc/-/issues/3337Proposal: expose Unicode and newline translation from System.IO2019-07-07T19:04:21ZSimon MarlowProposal: expose Unicode and newline translation from System.IOFor the proposed new additions, see:
- [System.IO (Unicode encoding/decoding)](http://www.haskell.org/~simonmar/base/System-IO.html#23)
- [System.IO (Newline conversion)](http://www.haskell.org/~simonmar/base/System-IO.html#25)
Patch, ...For the proposed new additions, see:
- [System.IO (Unicode encoding/decoding)](http://www.haskell.org/~simonmar/base/System-IO.html#23)
- [System.IO (Newline conversion)](http://www.haskell.org/~simonmar/base/System-IO.html#25)
Patch, and Haddocks for the base package, attached.
Discussion period: 2 weeks (14 July).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: expose Unicode and newline translation from System.IO","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the proposed new additions, see:\r\n\r\n * [http://www.haskell.org/~simonmar/base/System-IO.html#23 System.IO (Unicode encoding/decoding)]\r\n * [http://www.haskell.org/~simonmar/base/System-IO.html#25 System.IO (Newline conversion)]\r\n\r\nPatch, and Haddocks for the base package, attached.\r\n\r\nDiscussion period: 2 weeks (14 July).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3338Revert to old key bindings in ghci2019-07-07T19:04:21ZRaevelRevert to old key bindings in ghciAs of GHC 6.10.3, ghci uses Haskeline. Some of the key bindings that previously existed are no longer bound. For instance, C-p/C-n were previously bound to the same keys as up/down arrow respectively.
I have only tested this on Mac OS X...As of GHC 6.10.3, ghci uses Haskeline. Some of the key bindings that previously existed are no longer bound. For instance, C-p/C-n were previously bound to the same keys as up/down arrow respectively.
I have only tested this on Mac OS X 10.5, but I assume it is an issue for all OS's.
I would like C-p/C-n to be bound like they were previously.
The following lines in .haskeline do what I request:
bind: ctrl-p up
bind: ctrl-n down
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Revert to old key bindings in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As of GHC 6.10.3, ghci uses Haskeline. Some of the key bindings that previously existed are no longer bound. For instance, C-p/C-n were previously bound to the same keys as up/down arrow respectively.\r\n\r\nI have only tested this on Mac OS X 10.5, but I assume it is an issue for all OS's.\r\n\r\nI would like C-p/C-n to be bound like they were previously.\r\n\r\nThe following lines in .haskeline do what I request:\r\n\r\nbind: ctrl-p up\r\nbind: ctrl-n down\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3339Data.Monoid: Add (<>) as a synonym for mappend2019-07-07T19:04:20ZbosData.Monoid: Add (<>) as a synonym for mappendThis proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the `Data.Monoid` module, `(+>)` and `(<+)`, corresponding to different uses of `mappend`. These should not be methods of the `Monoid` ty...This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the `Data.Monoid` module, `(+>)` and `(<+)`, corresponding to different uses of `mappend`. These should not be methods of the `Monoid` typeclass, but top-level functions.
I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together.
```
(+>) :: (Monoid a) => a -> a -> a
a +> b = a `mappend` b
(<+) :: (Monoid a) => a -> a -> a
a <+ b = b `mappend` a
infixl 4 +>
infixl 4 <+
```
Proposed deadline: two weeks.
If this looks reasonable, I'll attach darcs patches.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Monoid: Add (+>) as a synonym for mappend","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the `Data.Monoid` module, `(+>)` and `(<+)`, corresponding to different uses of `mappend`. These should not be methods of the `Monoid` typeclass, but top-level functions.\r\n\r\nI hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together.\r\n\r\n{{{\r\n(+>) :: (Monoid a) => a -> a -> a\r\na +> b = a `mappend` b\r\n\r\n(<+) :: (Monoid a) => a -> a -> a\r\na <+ b = b `mappend` a\r\n\r\ninfixl 4 +>\r\ninfixl 4 <+\r\n}}}\r\n\r\nProposed deadline: two weeks.\r\n\r\nIf this looks reasonable, I'll attach darcs patches.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3340Better defaults for parallel GC settings2019-07-07T19:04:20ZSimon MarlowBetter defaults for parallel GC settingsThe parallel GC settings should default to something sensible in 6.12.1. Check that we don't introduce any performance regressions with the default settings compared to 6.10.4.
<details><summary>Trac metadata</summary>
| Trac field ...The parallel GC settings should default to something sensible in 6.12.1. Check that we don't introduce any performance regressions with the default settings compared to 6.10.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Better defaults for parallel GC settings","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The parallel GC settings should default to something sensible in 6.12.1. Check that we don't introduce any performance regressions with the default settings compared to 6.10.4.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3341encoding errors could be handled better2019-07-07T19:04:20Zjudahjencoding errors could be handled betterWith the new Unicode I/O library, using the following program (`badchar.hs`):
```
import System.IO
main = do
hSetBuffering stdin NoBuffering
getChar >> print
```
If the terminal's LANG is utf-8 but a latin-1 non-ASCII character...With the new Unicode I/O library, using the following program (`badchar.hs`):
```
import System.IO
main = do
hSetBuffering stdin NoBuffering
getChar >> print
```
If the terminal's LANG is utf-8 but a latin-1 non-ASCII character is
typed, then the terminal hangs and doesn't throw an error until three
more bytes are entered. Since `NoBuffering` is set, I'd expect the program to
immediately perform error handling rather than waiting for more input.
Furthermore, if the end of input is reached then the invalid byte is accepted without error. For example, in a utf-8 terminal:
```
dhcp-19-155:tmp judah$ ghc -e "putStrLn \"\\249\"" | ./badchar
'\249'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"encoding errors could be handled better","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the new Unicode I/O library, using the following program (`badchar.hs`):\r\n{{{\r\nimport System.IO\r\nmain = do\r\n hSetBuffering stdin NoBuffering\r\n getChar >> print\r\n}}}\r\nIf the terminal's LANG is utf-8 but a latin-1 non-ASCII character is\r\ntyped, then the terminal hangs and doesn't throw an error until three\r\nmore bytes are entered. Since `NoBuffering` is set, I'd expect the program to\r\nimmediately perform error handling rather than waiting for more input.\r\n\r\nFurthermore, if the end of input is reached then the invalid byte is accepted without error. For example, in a utf-8 terminal:\r\n{{{\r\ndhcp-19-155:tmp judah$ ghc -e \"putStrLn \\\"\\\\249\\\"\" | ./badchar\r\n'\\249'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3342splitTyConApp panic when using view patterns2019-07-07T19:04:19ZguestsplitTyConApp panic when using view patternsHere is a sample program that makes ghci panic with the following message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
splitTyConApp t_ag8{tv} [tau]
```
The code uses view patterns.
```
...Here is a sample program that makes ghci panic with the following message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
splitTyConApp t_ag8{tv} [tau]
```
The code uses view patterns.
```
module Bug where
data F = FT String [F]
data G = GX F F | GY
spec :: F -> G
spec (FT "X" [t1, t2]) = GX t1 t2
spec _ = GY
walk (spec -> GX _ t2) = walk t2
walk t@(FT _ _) = t
```
You can reach me at cklin\@cs.pdx.edu
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"splitTyConApp panic when using view patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a sample program that makes ghci panic with the following message:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-unknown-linux):\r\n\tsplitTyConApp t_ag8{tv} [tau]\r\n}}}\r\n\r\nThe code uses view patterns.\r\n\r\n{{{\r\nmodule Bug where\r\n\r\ndata F = FT String [F]\r\ndata G = GX F F | GY\r\n\r\nspec :: F -> G\r\nspec (FT \"X\" [t1, t2]) = GX t1 t2\r\nspec _ = GY\r\n\r\nwalk (spec -> GX _ t2) = walk t2\r\nwalk t@(FT _ _) = t\r\n}}}\r\n\r\nYou can reach me at cklin@cs.pdx.edu","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3343make 2 doesn't seem to work as documented2019-07-07T19:04:19ZManuel M T Chakravartymake 2 doesn't seem to work as documented[Theguidetothenewbuildsystem](building/using) claims, under the heading "Rebuilding the GHC binary after making changes", that `make 2` "is like make stage=2, except that it omits the dependency-building phase." However, it seems to incl...[Theguidetothenewbuildsystem](building/using) claims, under the heading "Rebuilding the GHC binary after making changes", that `make 2` "is like make stage=2, except that it omits the dependency-building phase." However, it seems to include the dependency-building and also fails with an error:
```
echo "utils/haddock_dist_depfile_EXISTS = YES" >> utils/haddock/dist/build/.depend
for dir in utils/haddock/dist/build/./ utils/haddock/dist/build/Haddock/ utils/haddock/dist/build/Haddock/Backends/
utils/haddock/dist/build/Haddock/GHC/ utils/haddock/dist/build/Haddock/Interface/
utils/haddock/dist/build/Haddock/Utils/; do if test ! -d $dir; then mkdir -p $dir; fi done
make[1]: *** No rule to make target `2'. Stop.
make: *** [2] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make 2 doesn't seem to work as documented","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"[wiki:Building/Using The guide to the new build system] claims, under the heading \"Rebuilding the GHC binary after making changes\", that `make 2` \"is like make stage=2, except that it omits the dependency-building phase.\" However, it seems to include the dependency-building and also fails with an error:\r\n{{{\r\necho \"utils/haddock_dist_depfile_EXISTS = YES\" >> utils/haddock/dist/build/.depend\r\nfor dir in utils/haddock/dist/build/./ utils/haddock/dist/build/Haddock/ utils/haddock/dist/build/Haddock/Backends/\r\nutils/haddock/dist/build/Haddock/GHC/ utils/haddock/dist/build/Haddock/Interface/\r\nutils/haddock/dist/build/Haddock/Utils/; do if test ! -d $dir; then mkdir -p $dir; fi done\r\nmake[1]: *** No rule to make target `2'. Stop.\r\nmake: *** [2] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3344request earlier and more perspicuous detection of tab characters in compiler/...2019-07-07T19:04:19Znr@eecs.harvard.edurequest earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.inIt turns out that if there is a tab character in `compiler/ghc.cabal.in` then the build fails in a way that I at least found hard to diagnose. Since the configure script builds `compiler/ghc.cabal` from `compiler/ghc.cabal.in`, life woul...It turns out that if there is a tab character in `compiler/ghc.cabal.in` then the build fails in a way that I at least found hard to diagnose. Since the configure script builds `compiler/ghc.cabal` from `compiler/ghc.cabal.in`, life would be a lot simpler if the build fell over at that point with an error saying that tab characters are forbidden in that file.
Since I believe the tab character is a tool of Satan, I would not dream of suggesting that the configure script run expand(1) over the offending file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It turns out that if there is a tab character in {{{compiler/ghc.cabal.in}}} then the build fails in a way that I at least found hard to diagnose. Since the configure script builds {{{compiler/ghc.cabal}}} from {{{compiler/ghc.cabal.in}}}, life would be a lot simpler if the build fell over at that point with an error saying that tab characters are forbidden in that file.\r\n\r\nSince I believe the tab character is a tool of Satan, I would not dream of suggesting that the configure script run expand(1) over the offending file.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3345Support reading .a files in GHCi to reclaim some disk space2019-07-07T19:04:18ZbatterseapowerSupport reading .a files in GHCi to reclaim some disk spaceCurrently, Cabal builds two code files for every libary it installs:
```
mbolingbroke@mb566 ~/.cabal/lib/vector-space-0.5.6/ghc-6.10.1
$ ls
.
..
Data
HSvector-space-0.5.6.o
libHSvector-space-0.5.6.a
```
The .a is a straight concatenati...Currently, Cabal builds two code files for every libary it installs:
```
mbolingbroke@mb566 ~/.cabal/lib/vector-space-0.5.6/ghc-6.10.1
$ ls
.
..
Data
HSvector-space-0.5.6.o
libHSvector-space-0.5.6.a
```
The .a is a straight concatenation of the .o files that got built. The .o is the result of lding together all the .o files (and so has inter-object references already resolved) but is actually only used by GHCi.
If GHCi could support loading .a files then Cabal wouldn't have to build this extra .o file and we could cut the size of installed libraries almost in half.
(Or perhaps GHC could link against the .o rather than the .a, and then Cabal could stop building the .a, instead?)
```
[12:32] BSP_: does cabal build both .o and .a's for a library purely because ghci isn't capable of reading the .a format and loading each .o individually?
[12:33] BSP_: it seems a bit wasteful to have two copies of the code installed for each library...
[12:35] dcoutts: BSP_: that's correct
[12:35] dcoutts: in theory it's not that hard
[12:35] dcoutts: there's no real need for ghci to read the .a index, just link in everything
[12:36] arjanb left the chat room. ("bbl")
[12:36] dcoutts: the .a format is trivial
[12:36] • dcoutts has a parser
[12:36] dcoutts: and generator for that matter
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support reading .a files in GHCi to reclaim some disk space","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, Cabal builds two code files for every libary it installs:\r\n\r\n{{{\r\nmbolingbroke@mb566 ~/.cabal/lib/vector-space-0.5.6/ghc-6.10.1\r\n$ ls\r\n.\r\n..\r\nData\r\nHSvector-space-0.5.6.o\r\nlibHSvector-space-0.5.6.a\r\n}}}\r\n\r\nThe .a is a straight concatenation of the .o files that got built. The .o is the result of lding together all the .o files (and so has inter-object references already resolved) but is actually only used by GHCi.\r\n\r\nIf GHCi could support loading .a files then Cabal wouldn't have to build this extra .o file and we could cut the size of installed libraries almost in half.\r\n\r\n(Or perhaps GHC could link against the .o rather than the .a, and then Cabal could stop building the .a, instead?)\r\n\r\n{{{\r\n[12:32] BSP_: does cabal build both .o and .a's for a library purely because ghci isn't capable of reading the .a format and loading each .o individually?\r\n[12:33] BSP_: it seems a bit wasteful to have two copies of the code installed for each library...\r\n[12:35] dcoutts: BSP_: that's correct\r\n[12:35] dcoutts: in theory it's not that hard\r\n[12:35] dcoutts: there's no real need for ghci to read the .a index, just link in everything\r\n[12:36] arjanb left the chat room. (\"bbl\")\r\n[12:36] dcoutts: the .a format is trivial\r\n[12:36] • dcoutts has a parser\r\n[12:36] dcoutts: and generator for that matter\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3346Strange and incorrect type error when using rewrite rules with type families2019-07-07T19:04:18ZdreixelStrange and incorrect type error when using rewrite rules with type familiesThe following code
```
{-# OPTIONS_GHC -fglasgow-exts -O1 #-}
module Main where
{-# RULES "rule1" forall x. to (from x) = x #-}
{-# RULES "rule2" forall x. from (to x) = x #-}
class EP a where
type Result a
from :: a -> Resul...The following code
```
{-# OPTIONS_GHC -fglasgow-exts -O1 #-}
module Main where
{-# RULES "rule1" forall x. to (from x) = x #-}
{-# RULES "rule2" forall x. from (to x) = x #-}
class EP a where
type Result a
from :: a -> Result a
to :: Result a -> a
```
gives the compilation error with GHC 6.11.20090703:
```
Couldn't match expected type `Result a'
against inferred type `Result a'
NB: `Result' is a type function, and may not be injective
In the first argument of `to', namely `(from x)'
In the expression: to (from x)
When checking the transformation rule "rule1"
```
I don't understand this error. rule2 seems unproblematic, though.
The similar code with functional dependencies
```
{-# RULES "rule3" forall x. to' (from' x) = x #-}
{-# RULES "rule4" forall x. from' (to' x) = x #-}
class EP' a b | a -> b where
from' :: a -> b
to' :: b -> a
```
raises no errors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Strange and incorrect type error when using rewrite rules with type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code\r\n\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts -O1 #-}\r\n\r\nmodule Main where\r\n\r\n{-# RULES \"rule1\" forall x. to (from x) = x #-}\r\n{-# RULES \"rule2\" forall x. from (to x) = x #-}\r\n\r\nclass EP a where\r\n type Result a\r\n from :: a -> Result a\r\n to :: Result a -> a\r\n}}}\r\n\r\ngives the compilation error with GHC 6.11.20090703:\r\n{{{\r\n Couldn't match expected type `Result a'\r\n against inferred type `Result a'\r\n NB: `Result' is a type function, and may not be injective\r\n In the first argument of `to', namely `(from x)'\r\n In the expression: to (from x)\r\n When checking the transformation rule \"rule1\"\r\n}}}\r\n\r\nI don't understand this error. rule2 seems unproblematic, though.\r\n\r\nThe similar code with functional dependencies\r\n\r\n{{{\r\n{-# RULES \"rule3\" forall x. to' (from' x) = x #-}\r\n{-# RULES \"rule4\" forall x. from' (to' x) = x #-}\r\n\r\nclass EP' a b | a -> b where\r\n from' :: a -> b\r\n to' :: b -> a\r\n}}}\r\n\r\nraises no errors.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3347Add flag to prevent generation of import libraries on Windows2019-07-07T19:04:18ZbatterseapowerAdd flag to prevent generation of import libraries on WindowsThe import libraries generated when you use the -shared option to generate a library can be very big. For example, when using it to build the edit-distance library from Hackage (v0.1.2) I observed a DLL size of 2.7Mb and an import librar...The import libraries generated when you use the -shared option to generate a library can be very big. For example, when using it to build the edit-distance library from Hackage (v0.1.2) I observed a DLL size of 2.7Mb and an import library size of 2.2Mb. (See also http://www.nabble.com/--out-implib-when-linking-shared-libraries-tt23561017.html)
Due to these size concerns, it may be desirable to disable the generation of the import library altogether in cases where the user only wants to use dynamic linking. The attached patch adds a new flag, -fno-shared-implib, that does just that.
NB: after experimentation I have found that there are at least two ways to reduce the size of the generated import library:
- Use pexports from mingw-utils to generate a .def file from the generated .dll, and then use lib /def:\<deffile\> to generate an import library from that. (NB: may be an issue with underscores added/removed in exported names - I haven't checked this). This generated a 825kb import library in my experiment above.
- Unpack the .dll.a generated by the binutils ld and link the contents together. This should be equally functional as an import library, but it reduces the disk space requirements to a similar level as the other option (815kb in my test).
The basic root of the problem is that the import libraries generated by GNU dlltool / ld are pretty bloated compared to those from the Microsoft toolchain. However, even the MS toolchain can't do much better than 30% of the size of the code, because Haskell code just exports tons of symbols (\~3200 in my test, which of course includes not only the library but the RTS, base library etc). This should be ameliorated by the implementation of shared libraries on Windows.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------ |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | batterseapower@hotmail.com, ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add flag to prevent generation of import libraries on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["batterseapower@hotmail.com","ndmitchell@gmail.com"],"type":"FeatureRequest","description":"The import libraries generated when you use the -shared option to generate a library can be very big. For example, when using it to build the edit-distance library from Hackage (v0.1.2) I observed a DLL size of 2.7Mb and an import library size of 2.2Mb. (See also http://www.nabble.com/--out-implib-when-linking-shared-libraries-tt23561017.html)\r\n\r\nDue to these size concerns, it may be desirable to disable the generation of the import library altogether in cases where the user only wants to use dynamic linking. The attached patch adds a new flag, -fno-shared-implib, that does just that.\r\n\r\nNB: after experimentation I have found that there are at least two ways to reduce the size of the generated import library:\r\n\r\n * Use pexports from mingw-utils to generate a .def file from the generated .dll, and then use lib /def:<deffile> to generate an import library from that. (NB: may be an issue with underscores added/removed in exported names - I haven't checked this). This generated a 825kb import library in my experiment above.\r\n\r\n * Unpack the .dll.a generated by the binutils ld and link the contents together. This should be equally functional as an import library, but it reduces the disk space requirements to a similar level as the other option (815kb in my test).\r\n\r\nThe basic root of the problem is that the import libraries generated by GNU dlltool / ld are pretty bloated compared to those from the Microsoft toolchain. However, even the MS toolchain can't do much better than 30% of the size of the code, because Haskell code just exports tons of symbols (~3200 in my test, which of course includes not only the library but the RTS, base library etc). This should be ameliorated by the implementation of shared libraries on Windows.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3348crash in gc with > 2 generations2019-07-07T19:04:18Zdynamic-windcrash in gc with > 2 generationsusing ghci from binary distribution built w/mingw
command line arguments +RTS -G3
enter:
> let n=\[1..10000000\]
> last n
sometimes hereafter ghc crashes in various fashions, e.g. "evacuate: unknown closure type: 0"
reproducing the cra...using ghci from binary distribution built w/mingw
command line arguments +RTS -G3
enter:
> let n=\[1..10000000\]
> last n
sometimes hereafter ghc crashes in various fashions, e.g. "evacuate: unknown closure type: 0"
reproducing the crash may require several attempts
seems like only 2 spaced gc works ok?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"crash in gc with > 2 generations","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"using ghci from binary distribution built w/mingw\r\ncommand line arguments +RTS -G3\r\nenter:\r\n> let n=[1..10000000]\r\n> last n\r\nsometimes hereafter ghc crashes in various fashions, e.g. \"evacuate: unknown closure type: 0\"\r\nreproducing the crash may require several attempts\r\nseems like only 2 spaced gc works ok?","type_of_failure":"OtherFailure","blocking":[]} -->6.10.4Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3349poor responsiveness of ghci2019-07-07T19:04:17Zdynamic-windpoor responsiveness of ghciWith lots of garbage created during an interactive session, pauses for gc become very noticeable and processor usage of GHC is very high. Line-editor of GHCi (thanks to Haskelline I think) loses keypresses when several keys are hit quick...With lots of garbage created during an interactive session, pauses for gc become very noticeable and processor usage of GHC is very high. Line-editor of GHCi (thanks to Haskelline I think) loses keypresses when several keys are hit quickly after a pause.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"poor responsiveness of ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With lots of garbage created during an interactive session, pauses for gc become very noticeable and processor usage of GHC is very high. Line-editor of GHCi (thanks to Haskelline I think) loses keypresses when several keys are hit quickly after a pause.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3350GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts2019-07-07T19:04:17ZindilGHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPortsExecuted "sudo port install ghc". Began installing version 6.10.3. Got this error:
```
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp
collect2: ld returned 1 exit status
linking dist-stage1/build/Fingerprint_...Executed "sudo port install ghc". Began installing version 6.10.3. Got this error:
```
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp
collect2: ld returned 1 exit status
linking dist-stage1/build/Fingerprint_hsc_make.o failed
command was: /usr/bin/gcc -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.6 -lHSunix_cbits -ldl -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/hpc/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.6 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/extensible-exceptions/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/Cabal/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/filepath/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.6 -lHSbase_cbits -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.6 -lm -lgmp -ldl dist-stage1/build/Fingerprint_hsc_make.o -o dist-stage1/build/Fingerprint_hsc_make
make[1]: *** [boot.stage.1] Error 1
make: *** [stage1] Error 1
```
I checked, and gmp is installed. I tried uninstalling it, cleaning it, and reinstalling it, and I also tried cleaning ghc, but I get the same error when trying to install ghc again.6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3352Data.Word should define instances of Random for each type2019-07-07T19:04:17ZKari PahulaData.Word should define instances of Random for each typeI'm forwarding Debian bug http://bugs.debian.org/533022 for your consideration.
----
Data.Word defines signed and unsigned integer types for various bit
sizes. It would help if Data.Word made each type an instance of Random.
Per http://w...I'm forwarding Debian bug http://bugs.debian.org/533022 for your consideration.
----
Data.Word defines signed and unsigned integer types for various bit
sizes. It would help if Data.Word made each type an instance of Random.
Per http://www.haskell.org/haskellwiki/Orphan_instance , such an
instance should appear either in System.Random or Data.Word, and it
makes more sense to do the latter.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Word should define instances of Random for each type","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm forwarding Debian bug http://bugs.debian.org/533022 for your consideration.\r\n----\r\nData.Word defines signed and unsigned integer types for various bit\r\nsizes. It would help if Data.Word made each type an instance of Random.\r\nPer http://www.haskell.org/haskellwiki/Orphan_instance , such an\r\ninstance should appear either in System.Random or Data.Word, and it\r\nmakes more sense to do the latter.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->rrnewtonrrnewtonhttps://gitlab.haskell.org/ghc/ghc/-/issues/3354binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)2019-07-07T19:04:16Zbkomuvesbinaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is
```
dyld: lazy symbol binding failed: Symbol not found: _pthread_cond...It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is
```
dyld: lazy symbol binding failed: Symbol not found: _pthread_cond_init$UNIX2003
Referenced from: <the executable>
Expected in: /usr/lib/libSystem.B.dylib
```
I believe that the primary reasons for this is that the runtime system is linked against the 10.5 system libraries, which are not ABI compatible with the 10.4 system libraries.
Apple provides both 10.4 and 10.5 SDKs with 10.5, along with compiler and linker options for those who want to build backward-compatible binaries. I tried to pass these options to the linker, which results in the error message
```
Undefined symbols:
"_strerror$UNIX2003", referenced from:
_newThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
_setThreadLocalVar in libHSrts_thr.a(OSThreads.thr_o)
_freeThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
_my_mmap in libHSrts_thr.a(OSMem.thr_o)
_rtsSysErrorMsgFn in libHSrts_thr.a(RtsMessages.thr_o)
"_fputs$UNIX2003", referenced from:
_heapCensus in libHSrts_thr.a(ProfHeap.thr_o)
"_read$UNIX2003", referenced from:
___hscore_PrelHandle_read in libHSbase-4.0.0.0.a(PrelIOUtils.o)
"_fcntl$UNIX2003", referenced from:
_resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
_resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
_setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
_setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
"_pthread_cond_init$UNIX2003", referenced from:
_initCondition in libHSrts_thr.a(OSThreads.thr_o)
"_open$UNIX2003", referenced from:
___hscore_open in libHSbase-4.0.0.0.a(PrelIOUtils.o)
"_kill$UNIX2003", referenced from:
_shutdownHaskellAndSignal in libHSrts_thr.a(RtsStartup.thr_o)
"_select$UNIX2003", referenced from:
_fdReady in libHSbase-4.0.0.0.a(inputReady.o)
"_write$UNIX2003", referenced from:
_ioManagerWakeup in libHSrts_thr.a(Signals.thr_o)
_ioManagerDie in libHSrts_thr.a(Signals.thr_o)
_generic_handler in libHSrts_thr.a(Signals.thr_o)
___hscore_PrelHandle_write in libHSbase-4.0.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found
```
It would be nice if GHC on OS X shipped with two version of the runtime (and the base library?), and had compiler flags to build compatible binaries. This could be also a problem in the future, with the next OS X versions.
See also this thread: http://lists.apple.com/archives/Darwin-dev/2007/Nov/msg00109.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is\r\n\r\n{{{\r\ndyld: lazy symbol binding failed: Symbol not found: _pthread_cond_init$UNIX2003\r\n Referenced from: <the executable>\r\n Expected in: /usr/lib/libSystem.B.dylib\r\n}}}\r\n\r\nI believe that the primary reasons for this is that the runtime system is linked against the 10.5 system libraries, which are not ABI compatible with the 10.4 system libraries.\r\n\r\nApple provides both 10.4 and 10.5 SDKs with 10.5, along with compiler and linker options for those who want to build backward-compatible binaries. I tried to pass these options to the linker, which results in the error message\r\n\r\n{{{\r\nUndefined symbols:\r\n \"_strerror$UNIX2003\", referenced from:\r\n _newThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)\r\n _setThreadLocalVar in libHSrts_thr.a(OSThreads.thr_o)\r\n _freeThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)\r\n _my_mmap in libHSrts_thr.a(OSMem.thr_o)\r\n _rtsSysErrorMsgFn in libHSrts_thr.a(RtsMessages.thr_o)\r\n \"_fputs$UNIX2003\", referenced from:\r\n _heapCensus in libHSrts_thr.a(ProfHeap.thr_o)\r\n \"_read$UNIX2003\", referenced from:\r\n ___hscore_PrelHandle_read in libHSbase-4.0.0.0.a(PrelIOUtils.o)\r\n \"_fcntl$UNIX2003\", referenced from:\r\n _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)\r\n _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)\r\n _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)\r\n _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)\r\n \"_pthread_cond_init$UNIX2003\", referenced from:\r\n _initCondition in libHSrts_thr.a(OSThreads.thr_o)\r\n \"_open$UNIX2003\", referenced from:\r\n ___hscore_open in libHSbase-4.0.0.0.a(PrelIOUtils.o)\r\n \"_kill$UNIX2003\", referenced from:\r\n _shutdownHaskellAndSignal in libHSrts_thr.a(RtsStartup.thr_o)\r\n \"_select$UNIX2003\", referenced from:\r\n _fdReady in libHSbase-4.0.0.0.a(inputReady.o)\r\n \"_write$UNIX2003\", referenced from:\r\n _ioManagerWakeup in libHSrts_thr.a(Signals.thr_o)\r\n _ioManagerDie in libHSrts_thr.a(Signals.thr_o)\r\n _generic_handler in libHSrts_thr.a(Signals.thr_o)\r\n ___hscore_PrelHandle_write in libHSbase-4.0.0.0.a(PrelIOUtils.o)\r\nld: symbol(s) not found\r\n}}}\r\n\r\nIt would be nice if GHC on OS X shipped with two version of the runtime (and the base library?), and had compiler flags to build compatible binaries. This could be also a problem in the future, with the next OS X versions.\r\n\r\nSee also this thread: http://lists.apple.com/archives/Darwin-dev/2007/Nov/msg00109.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3356{-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax2019-07-07T19:04:15ZSamuel Bronson{-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntaxI want to get the current record syntax demoted to an extension in Haskell'. This would be more likely to happen if disallowing it was supported by GHC, so I want to see GHC support this with:
```
{-# LANGUAGE NoTraditionalRecordSyntax ...I want to get the current record syntax demoted to an extension in Haskell'. This would be more likely to happen if disallowing it was supported by GHC, so I want to see GHC support this with:
```
{-# LANGUAGE NoTraditionalRecordSyntax #-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"{-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I want to get the current record syntax demoted to an extension in Haskell'. This would be more likely to happen if disallowing it was supported by GHC, so I want to see GHC support this with:\r\n\r\n{{{\r\n{-# LANGUAGE NoTraditionalRecordSyntax #-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/3357ghc panic2019-07-07T19:04:15Zkimwallmarkghc panicI ran "ghci 67.hs" from the command line, and got the following crash. 67.hs is a 21K file that references no other modules.
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... don...I ran "ghci 67.hs" from the command line, and got the following crash. 67.hs is a 21K file that references no other modules.
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( 67.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran \"ghci 67.hs\" from the command line, and got the following crash. 67.hs is a 21K file that references no other modules.\r\n\r\n{{{\r\nGHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( 67.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-apple-darwin):\r\n\tlinkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3358ghc panic2019-07-07T19:04:15Zkimwallmarkghc panicRunning "ghci 67.hs" from the command line caused the following crash. 67.hs is a \~21K file that doesn't reference any other modules.
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linki...Running "ghci 67.hs" from the command line caused the following crash. 67.hs is a \~21K file that doesn't reference any other modules.
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( 67.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running \"ghci 67.hs\" from the command line caused the following crash. 67.hs is a ~21K file that doesn't reference any other modules.\r\n\r\n{{{\r\nGHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( 67.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-apple-darwin):\r\n\tlinkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3359Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.32019-07-07T19:04:15ZAshley YakeleyBuild failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3```
[glastonbury:~/Projects/GHC/ghc]$ make
===--- updating makefiles phase 0
make -r --no-print-directory -f ghc.mk phase=0 just-makefiles
===--- updating makefiles phase 1
make -r --no-print-directory -f ghc.mk phase=1 just-makefiles
==...```
[glastonbury:~/Projects/GHC/ghc]$ make
===--- updating makefiles phase 0
make -r --no-print-directory -f ghc.mk phase=0 just-makefiles
===--- updating makefiles phase 1
make -r --no-print-directory -f ghc.mk phase=1 just-makefiles
===--- updating makefiles phase 2
make -r --no-print-directory -f ghc.mk phase=2 just-makefiles
compiler/ghc.mk:432: compiler/stage1/build/.depend-v: No such file or directory
"inplace/bin/mkdirhier" compiler/stage1/build
"rm" -f compiler/stage1/build/.depend-v.tmp
touch compiler/stage1/build/.depend-v.tmp
"inplace/bin/mkdependC" -f compiler/stage1/build/.depend-v.tmp -- -O -g -O2 -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -isystem/usr/local/lib/ghc-6.10.3/bytestring-0.9.1.4/include -isystem/usr/local/lib/ghc-6.10.3/process-1.0.1.1/include -isystem/usr/local/lib/ghc-6.10.3/directory-1.0.0.3/include -isystem/usr/local/lib/ghc-6.10.3/unix-2.3.2.0/include -isystem/usr/local/lib/ghc-6.10.3/old-time-1.0.0.2/include -isystem/usr/local/lib/ghc-6.10.3/base-4.1.0.0/include -isystem/usr/local/lib/ghc-6.10.3/include -isystemPAPI_INCLUDE_DIR -- compiler/parser/cutils.c compiler/utils/md5.c
sed -e "s|compiler/\([^ :]*o[ :]\)|compiler/stage1/build/\1|g" -e "s|/home/ashley/Projects/GHC/ghc/||" <compiler/stage1/build/.depend-v.tmp >compiler/stage1/build/.depend-v
"/usr/local/bin/ghc" -M -include-pkg-deps -dep-makefile compiler/stage1/build/.depend-v -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.11 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.2 -package array-0.2.0.0 -package base-4.1.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.1 -package directory-1.0.0.3 -package filepath-1.1.0.2 -package haskell98-1.0.1.0 -package hpc-0.5.0.3 -package old-time-1.0.0.2 -package process-1.0.1.1 -package unix-2.3.2.0 -#include cutils.h -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PprBase.hs compiler/nativeGen/PIC.hs compiler/nativeGen/Platform.hs compiler/nativeGen/Alpha/Regs.hs compiler/nativeGen/Alpha/RegInfo.hs compiler/nativeGen/Alpha/Instr.hs compiler/nativeGen/Alpha/CodeGen.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/RegPlate.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CCall.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/NewDemand.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBrokenBlock.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmCPS.hs compiler/cmm/CmmCPSGen.hs compiler/cmm/CmmCPSZ.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElimZ.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmCvt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmLiveZ.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmProcPointZ.hs compiler/cmm/CmmSpillReload.hs compiler/cmm/CmmStackLayout.hs compiler/cmm/CmmTx.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmZipUtil.hs compiler/cmm/DFMonad.hs compiler/cmm/Dataflow.hs compiler/cmm/MkZipCfg.hs compiler/cmm/MkZipCfgCmm.hs compiler/cmm/OptimizationFuel.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmZ.hs compiler/cmm/StackColor.hs compiler/cmm/StackPlacements.hs compiler/cmm/ZipCfg.hs compiler/cmm/ZipCfgCmmRep.hs compiler/cmm/ZipCfgExtras.hs compiler/cmm/ZipDataflow.hs compiler/codeGen/Bitmap.hs compiler/codeGen/CgBindery.lhs compiler/codeGen/CgCallConv.hs compiler/codeGen/CgCase.lhs compiler/codeGen/CgClosure.lhs compiler/codeGen/CgCon.lhs compiler/codeGen/CgExpr.lhs compiler/codeGen/CgForeignCall.hs compiler/codeGen/CgHeapery.lhs compiler/codeGen/CgHpc.hs compiler/codeGen/CgInfoTbls.hs compiler/codeGen/CgLetNoEscape.lhs compiler/codeGen/CgMonad.lhs compiler/codeGen/CgParallel.hs compiler/codeGen/CgPrimOp.hs compiler/codeGen/CgProf.hs compiler/codeGen/CgStackery.lhs compiler/codeGen/CgTailCall.lhs compiler/codeGen/CgTicky.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmGran.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/ClosureInfo.lhs compiler/codeGen/CodeGen.lhs compiler/codeGen/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/ExternalCore.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/MkExternalCore.lhs compiler/coreSyn/PprCore.lhs compiler/coreSyn/PprExternalCore.lhs compiler/cprAnalysis/CprAnalyse.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/main/Annotations.lhs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/main/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.lhs compiler/main/HscStats.lhs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/ParsePkgConf.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/StaticFlagParser.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockLex.hs compiler/parser/HaddockParse.hs compiler/parser/HaddockUtils.hs compiler/parser/LexCore.hs compiler/parser/Lexer.hs compiler/parser/Parser.hs compiler/parser/ParserCore.hs compiler/parser/ParserCoreUtils.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnHsSyn.lhs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SRT.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/stranal/DmdAnal.lhs compiler/stranal/SaAbsInt.lhs compiler/stranal/SaLib.lhs compiler/stranal/StrictAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcTyFuns.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcUnify.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/types/FunDeps.lhs compiler/types/Generics.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/Interval.hs compiler/utils/LazyUniqFM.lhs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/vectorise/VectBuiltIn.hs compiler/vectorise/VectCore.hs compiler/vectorise/VectMonad.hs compiler/vectorise/VectType.hs compiler/vectorise/VectUtils.hs compiler/vectorise/Vectorise.hs
compiler/cmm/CmmParse.hs:30:7:
Could not find module `MachOp':
it is a member of the hidden package `ghc-6.10.3'
Use -v to see a list of the files searched for.
make[1]: *** [compiler/stage1/build/.depend-v] Error 1
make[1]: *** Deleting file `compiler/stage1/build/.depend-v'
make: *** [all] Error 2
```
```
[glastonbury:~/Projects/GHC/ghc]$ uname -a
Linux glastonbury 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux
[glastonbury:~/Projects/GHC/ghc]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.3
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Build failed: \"Could not find module `MachOp'\" on 64bit Linux w/ GHC 6.10.3","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n[glastonbury:~/Projects/GHC/ghc]$ make\r\n===--- updating makefiles phase 0\r\nmake -r --no-print-directory -f ghc.mk phase=0 just-makefiles\r\n===--- updating makefiles phase 1\r\nmake -r --no-print-directory -f ghc.mk phase=1 just-makefiles\r\n===--- updating makefiles phase 2\r\nmake -r --no-print-directory -f ghc.mk phase=2 just-makefiles\r\ncompiler/ghc.mk:432: compiler/stage1/build/.depend-v: No such file or directory\r\n\"inplace/bin/mkdirhier\" compiler/stage1/build\r\n\"rm\" -f compiler/stage1/build/.depend-v.tmp\r\ntouch compiler/stage1/build/.depend-v.tmp\r\n\"inplace/bin/mkdependC\" -f compiler/stage1/build/.depend-v.tmp -- -O -g -O2 -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -isystem/usr/local/lib/ghc-6.10.3/bytestring-0.9.1.4/include -isystem/usr/local/lib/ghc-6.10.3/process-1.0.1.1/include -isystem/usr/local/lib/ghc-6.10.3/directory-1.0.0.3/include -isystem/usr/local/lib/ghc-6.10.3/unix-2.3.2.0/include -isystem/usr/local/lib/ghc-6.10.3/old-time-1.0.0.2/include -isystem/usr/local/lib/ghc-6.10.3/base-4.1.0.0/include -isystem/usr/local/lib/ghc-6.10.3/include -isystemPAPI_INCLUDE_DIR -- compiler/parser/cutils.c compiler/utils/md5.c \r\nsed -e \"s|compiler/\\([^ :]*o[ :]\\)|compiler/stage1/build/\\1|g\" -e \"s|/home/ashley/Projects/GHC/ghc/||\" <compiler/stage1/build/.depend-v.tmp >compiler/stage1/build/.depend-v\r\n\"/usr/local/bin/ghc\" -M -include-pkg-deps -dep-makefile compiler/stage1/build/.depend-v -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.11 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.2 -package array-0.2.0.0 -package base-4.1.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.1 -package directory-1.0.0.3 -package filepath-1.1.0.2 -package haskell98-1.0.1.0 -package hpc-0.5.0.3 -package old-time-1.0.0.2 -package process-1.0.1.1 -package unix-2.3.2.0 -#include cutils.h -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PprBase.hs compiler/nativeGen/PIC.hs compiler/nativeGen/Platform.hs compiler/nativeGen/Alpha/Regs.hs compiler/nativeGen/Alpha/RegInfo.hs compiler/nativeGen/Alpha/Instr.hs compiler/nativeGen/Alpha/CodeGen.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/RegPlate.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CCall.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/NewDemand.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBrokenBlock.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmCPS.hs compiler/cmm/CmmCPSGen.hs compiler/cmm/CmmCPSZ.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElimZ.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmCvt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmLiveZ.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmProcPointZ.hs compiler/cmm/CmmSpillReload.hs compiler/cmm/CmmStackLayout.hs compiler/cmm/CmmTx.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmZipUtil.hs compiler/cmm/DFMonad.hs compiler/cmm/Dataflow.hs compiler/cmm/MkZipCfg.hs compiler/cmm/MkZipCfgCmm.hs compiler/cmm/OptimizationFuel.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmZ.hs compiler/cmm/StackColor.hs compiler/cmm/StackPlacements.hs compiler/cmm/ZipCfg.hs compiler/cmm/ZipCfgCmmRep.hs compiler/cmm/ZipCfgExtras.hs compiler/cmm/ZipDataflow.hs compiler/codeGen/Bitmap.hs compiler/codeGen/CgBindery.lhs compiler/codeGen/CgCallConv.hs compiler/codeGen/CgCase.lhs compiler/codeGen/CgClosure.lhs compiler/codeGen/CgCon.lhs compiler/codeGen/CgExpr.lhs compiler/codeGen/CgForeignCall.hs compiler/codeGen/CgHeapery.lhs compiler/codeGen/CgHpc.hs compiler/codeGen/CgInfoTbls.hs compiler/codeGen/CgLetNoEscape.lhs compiler/codeGen/CgMonad.lhs compiler/codeGen/CgParallel.hs compiler/codeGen/CgPrimOp.hs compiler/codeGen/CgProf.hs compiler/codeGen/CgStackery.lhs compiler/codeGen/CgTailCall.lhs compiler/codeGen/CgTicky.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmGran.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/ClosureInfo.lhs compiler/codeGen/CodeGen.lhs compiler/codeGen/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/ExternalCore.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/MkExternalCore.lhs compiler/coreSyn/PprCore.lhs compiler/coreSyn/PprExternalCore.lhs compiler/cprAnalysis/CprAnalyse.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/main/Annotations.lhs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/main/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.lhs compiler/main/HscStats.lhs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/ParsePkgConf.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/StaticFlagParser.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockLex.hs compiler/parser/HaddockParse.hs compiler/parser/HaddockUtils.hs compiler/parser/LexCore.hs compiler/parser/Lexer.hs compiler/parser/Parser.hs compiler/parser/ParserCore.hs compiler/parser/ParserCoreUtils.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnHsSyn.lhs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SRT.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/stranal/DmdAnal.lhs compiler/stranal/SaAbsInt.lhs compiler/stranal/SaLib.lhs compiler/stranal/StrictAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcTyFuns.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcUnify.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/types/FunDeps.lhs compiler/types/Generics.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/Interval.hs compiler/utils/LazyUniqFM.lhs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/vectorise/VectBuiltIn.hs compiler/vectorise/VectCore.hs compiler/vectorise/VectMonad.hs compiler/vectorise/VectType.hs compiler/vectorise/VectUtils.hs compiler/vectorise/Vectorise.hs\r\n\r\ncompiler/cmm/CmmParse.hs:30:7:\r\n Could not find module `MachOp':\r\n it is a member of the hidden package `ghc-6.10.3'\r\n Use -v to see a list of the files searched for.\r\nmake[1]: *** [compiler/stage1/build/.depend-v] Error 1\r\nmake[1]: *** Deleting file `compiler/stage1/build/.depend-v'\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\n{{{\r\n[glastonbury:~/Projects/GHC/ghc]$ uname -a\r\nLinux glastonbury 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux\r\n[glastonbury:~/Projects/GHC/ghc]$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.3\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3360Add profiling support to GHCi2019-07-07T19:04:14ZSamuel BronsonAdd profiling support to GHCiIt would be nice if GHCi could be run with profiling on. In \[comment:#2197:13 comment 13\] of ticket #2197, simonmar said:
> There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpr...It would be nice if GHCi could be run with profiling on. In \[comment:#2197:13 comment 13\] of ticket #2197, simonmar said:
> There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build.
This would, of course, also allow profiling of GHC or Haddock dealing with Template Haskell code, as well as any ghc-api clients that somehow end up invoking the bytecode interpreter.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add profiling support to GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be nice if GHCi could be run with profiling on. In [comment:#2197:13 comment 13] of ticket #2197, simonmar said:\r\n\r\n> There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build.\r\n\r\nThis would, of course, also allow profiling of GHC or Haddock dealing with Template Haskell code, as well as any ghc-api clients that somehow end up invoking the bytecode interpreter.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3361GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int2019-07-07T19:04:14ZtemotoGHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit IntReloading xmonad configuration i get ugly X window with this text:
Error detected while loading xmonad configuration file: /home/temoto/.xmonad/xmonad.hs
on the commandline:
> Warning: -no-recomp is deprecated: Use -fforce-recomp inst...Reloading xmonad configuration i get ugly X window with this text:
Error detected while loading xmonad configuration file: /home/temoto/.xmonad/xmonad.hs
on the commandline:
> Warning: -no-recomp is deprecated: Use -fforce-recomp instead
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
> Prelude.chr: bad argument
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Please check the file for errors.
Running 32bit Ubuntu Karmic on custom 64bit capable kernel. The error is 100% reproducable, in fact i get it on every xmonad config reload. I can send any additional information, if that helps. The error started to appear after i upgraded Ubuntu jaunty to unstable karmic (so really lots of packages changed, i can't trace point of failure more precisely).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"impossible happened","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reloading xmonad configuration i get ugly X window with this text:\r\nError detected while loading xmonad configuration file: /home/temoto/.xmonad/xmonad.hs\r\n\r\non the commandline:\r\n Warning: -no-recomp is deprecated: Use -fforce-recomp instead\r\nBinary: Int64 truncated to fit in 32 bit Int\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-unknown-linux):\r\n Prelude.chr: bad argument\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nPlease check the file for errors.\r\n\r\n\r\nRunning 32bit Ubuntu Karmic on custom 64bit capable kernel. The error is 100% reproducable, in fact i get it on every xmonad config reload. I can send any additional information, if that helps. The error started to appear after i upgraded Ubuntu jaunty to unstable karmic (so really lots of packages changed, i can't trace point of failure more precisely).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3362Adding a newtype EndoCategory to Control.Category2019-07-07T19:04:13Zr6Adding a newtype EndoCategory to Control.CategoryI suggest adding a wrapper to make `(a x x)` a `Monoid` for any `Category` `a` and type `x`. This would be added to `Control.Category`.
```
newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x }
instance (Category a) => M...I suggest adding a wrapper to make `(a x x)` a `Monoid` for any `Category` `a` and type `x`. This would be added to `Control.Category`.
```
newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x }
instance (Category a) => Monoid (EndoCategory a x) where
mempty = EndoCategory id
mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Adding a newtype EndoCategory to Control.Category","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I suggest adding a wrapper to make {{{(a x x)}}} a {{{Monoid}}} for any {{{Category}}} {{{a}}} and type {{{x}}}. This would be added to {{{Control.Category}}}.\r\n\r\n{{{\r\nnewtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x }\r\n\r\ninstance (Category a) => Monoid (EndoCategory a x) where\r\n mempty = EndoCategory id\r\n mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3363ghc: panic installing darcs-beta2019-07-07T19:04:13Zdimavsghc: panic installing darcs-betaI've just tried to install darcs using *cabal install darcs-beta*, and somewhere in the middle I've got
```
[ 57 of 136] Compiling Darcs.Repository.Prefs ( src/Darcs/Repository/Prefs.lhs, dist/build/Darcs/Repository/Prefs.o )
ghc: panic...I've just tried to install darcs using *cabal install darcs-beta*, and somewhere in the middle I've got
```
[ 57 of 136] Compiling Darcs.Repository.Prefs ( src/Darcs/Repository/Prefs.lhs, dist/build/Darcs/Repository/Prefs.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-apple-darwin):
cat_evals
base:GHC.Arr.Array{d ras}
[ww{v a305N} [lid], ww1{v a305O} [lid], ww2{v a305P} [lid]]
[!, !, _, _]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
darcs-beta-2.2.98.2 failed during the building phase. The exception was:
exit: ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic installing darcs-beta","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've just tried to install darcs using ''cabal install darcs-beta'', and somewhere in the middle I've got\r\n\r\n{{{\r\n[ 57 of 136] Compiling Darcs.Repository.Prefs ( src/Darcs/Repository/Prefs.lhs, dist/build/Darcs/Repository/Prefs.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-apple-darwin):\r\n\tcat_evals\r\n base:GHC.Arr.Array{d ras}\r\n [ww{v a305N} [lid], ww1{v a305O} [lid], ww2{v a305P} [lid]]\r\n [!, !, _, _]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Error: some packages failed to install:\r\ndarcs-beta-2.2.98.2 failed during the building phase. The exception was:\r\nexit: ExitFailure 1\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3364calling "ghc -H" panics2019-07-07T19:04:13Zbaldocalling "ghc -H" panicsCalling with only the argument "`-H`" GHC panics:
```
# ghci -H
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux...Calling with only the argument "`-H`" GHC panics:
```
# ghci -H
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
Static flags have not been initialised!
Please call GHC.newSession or GHC.parseStaticFlags early enough.
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Same for `ghci -H`.
The version I'm using is GHC 6.10.3-1 from Arch Linux's repository. Details about how ghc has been build can be found on http://repos.archlinux.org/viewvc.cgi/ghc/repos/extra-i686/?pathrev=38707
Hope this helps. ;)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"calling \"ghc -H\" panics","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Calling with only the argument \"`-H`\" GHC panics:\r\n\r\n{{{\r\n# ghci -H\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-unknown-linux):\r\n\tghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for i386-unknown-linux):\r\n\tStatic flags have not been initialised!\r\n Please call GHC.newSession or GHC.parseStaticFlags early enough.\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nSame for `ghci -H`.\r\n\r\nThe version I'm using is GHC 6.10.3-1 from Arch Linux's repository. Details about how ghc has been build can be found on http://repos.archlinux.org/viewvc.cgi/ghc/repos/extra-i686/?pathrev=38707\r\n\r\nHope this helps. ;)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3365Bug in GHCi, 'impossible' happened2019-07-07T19:04:12ZguestBug in GHCi, 'impossible' happenedI have just created file with following contents:
```
import List;
l = sort ["MARY","PATRICIA", ...]
```
I have got this list from http://projecteuler.net/project/names.txt.
Then i saved this code into the file "22.hs" and started it...I have just created file with following contents:
```
import List;
l = sort ["MARY","PATRICIA", ...]
```
I have got this list from http://projecteuler.net/project/names.txt.
Then i saved this code into the file "22.hs" and started it with "ghci 22.hs" command.
Then i got the following output:
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( 22.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for x86_64-unknown-linux):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
Leaving GHCi.
```
I am running Arch Linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in GHCi, 'impossible' happened","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have just created file with following contents:\r\n\r\n{{{\r\nimport List;\r\n\r\nl = sort [\"MARY\",\"PATRICIA\", ...]\r\n}}}\r\n\r\nI have got this list from http://projecteuler.net/project/names.txt.\r\n\r\nThen i saved this code into the file \"22.hs\" and started it with \"ghci 22.hs\" command.\r\n\r\nThen i got the following output:\r\n{{{\r\nGHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( 22.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for x86_64-unknown-linux):\r\n\tlinkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\nLeaving GHCi.\r\n}}}\r\nI am running Arch Linux.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3366Bug in GHCi, 'impossible' happened2019-07-07T19:04:12ZguestBug in GHCi, 'impossible' happenedI have just created file with following contents:
```
import List;
l = sort ["MARY","PATRICIA", ...]
```
I have got this list from http://projecteuler.net/project/names.txt.
Then i saved this code into the file "22.hs" and started it...I have just created file with following contents:
```
import List;
l = sort ["MARY","PATRICIA", ...]
```
I have got this list from http://projecteuler.net/project/names.txt.
Then i saved this code into the file "22.hs" and started it with "ghci 22.hs" command.
Then i got the following output:
```
GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( 22.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for x86_64-unknown-linux):
linkBCO: >= 64k insns in BCO
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
Leaving GHCi.
```
I am running Arch Linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in GHCi, 'impossible' happened","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have just created file with following contents:\r\n\r\n{{{\r\nimport List;\r\n\r\nl = sort [\"MARY\",\"PATRICIA\", ...]\r\n}}}\r\n\r\nI have got this list from http://projecteuler.net/project/names.txt.\r\n\r\nThen i saved this code into the file \"22.hs\" and started it with \"ghci 22.hs\" command.\r\n\r\nThen i got the following output:\r\n{{{\r\nGHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( 22.hs, interpreted )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.3 for x86_64-unknown-linux):\r\n\tlinkBCO: >= 64k insns in BCO\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\nLeaving GHCi.\r\n}}}\r\nI am running Arch Linux.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3367syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof...2019-07-07T19:04:12ZAndrew U. Franksyntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof tokenthe following program is sufficient to produce this error:
```
{-# LANGUAGE MultiParamTypeClasses -}
module GZsvn.WDIRops (WDIR (..))
where
```
the culprit is the missing \# at the end of the prama.
message:
```
ghc:...the following program is sufficient to produce this error:
```
{-# LANGUAGE MultiParamTypeClasses -}
module GZsvn.WDIRops (WDIR (..))
where
```
the culprit is the missing \# at the end of the prama.
message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-linux):
getOptions'.parseLanguage(1) went past eof token
```
i could not find the same error already reported, but other problems with LANGUAGE pragma syntax.https://gitlab.haskell.org/ghc/ghc/-/issues/3368Deriving Foldable doesn't work2021-11-02T09:27:33ZcmcqDeriving Foldable doesn't workI was trying out the Foldable deriving in GHC HEAD (see ticket #2953). fold gave a stack space overflow. -ddump-deriv shows that the wrong foldr is being used:
```
{ GHC.Base.foldr f_aat z_aav (Main.Nil) = z_aav,
```
This is easy to ...I was trying out the Foldable deriving in GHC HEAD (see ticket #2953). fold gave a stack space overflow. -ddump-deriv shows that the wrong foldr is being used:
```
{ GHC.Base.foldr f_aat z_aav (Main.Nil) = z_aav,
```
This is easy to fix but isn't it strange that there's no compile error?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Deriving Foldable doesn't work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was trying out the Foldable deriving in GHC HEAD (see ticket #2953). fold gave a stack space overflow. -ddump-deriv shows that the wrong foldr is being used:\r\n{{{\r\n { GHC.Base.foldr f_aat z_aav (Main.Nil) = z_aav,\r\n}}}\r\n\r\nThis is easy to fix but isn't it strange that there's no compile error?","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3369Deadlock sending stdin to a process which does not read it2019-07-07T19:04:11ZSimon MichaelDeadlock sending stdin to a process which does not read itThis code writes some standard input to a command and collects the output:
> (ih,oh,eh,ph) ← runInteractiveCommand cmd
> forkIO $ hPutStr ih i' -- separate thread in case cmd does not read stdin
> out ← hGetContents oh
> err ← hGetConte...This code writes some standard input to a command and collects the output:
> (ih,oh,eh,ph) ← runInteractiveCommand cmd
> forkIO $ hPutStr ih i' -- separate thread in case cmd does not read stdin
> out ← hGetContents oh
> err ← hGetContents eh
> exit ← waitForProcess ph
But if cmd does not read from stdin, using ghc 6.10.3 or 6.8.2 on a mac (with or without -threaded), it seems to hang at waitForProcess. (I tried to work around this by adding forkIO at Heffalump's suggestion, but no difference. With ghc 6.10.3 on a gnu/linux machine, it works as intended.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deadlock sending stdin to a process which does not read it","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code writes some standard input to a command and collects the output:\r\n\r\n (ih,oh,eh,ph) ← runInteractiveCommand cmd\r\n forkIO $ hPutStr ih i' -- separate thread in case cmd does not read stdin \r\n out ← hGetContents oh\r\n err ← hGetContents eh\r\n exit ← waitForProcess ph\r\n\r\nBut if cmd does not read from stdin, using ghc 6.10.3 or 6.8.2 on a mac (with or without -threaded), it seems to hang at waitForProcess. (I tried to work around this by adding forkIO at Heffalump's suggestion, but no difference. With ghc 6.10.3 on a gnu/linux machine, it works as intended.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3370Put DiffArray in its own diffarray package2019-07-07T19:04:11ZIan Lynagh <igloo@earth.li>Put DiffArray in its own diffarray package!DiffArray currently has serious performance problems (see #2727), and is not currently being actively maintained. However, as part of the corelib `array` it gives the impression that it is a "blessed" library.
I propose that we split !...!DiffArray currently has serious performance problems (see #2727), and is not currently being actively maintained. However, as part of the corelib `array` it gives the impression that it is a "blessed" library.
I propose that we split !DiffArray off into its own `diffarray` package. This also has the advantage that it can then be maintained by a separate maintainer, if someone is interested, and it will be decoupled from GHC's major release schedule.
Deadline: 26 July (2 weeks).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Put DiffArray in its own diffarray package","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n!DiffArray currently has serious performance problems (see #2727), and is not currently being actively maintained. However, as part of the corelib `array` it gives the impression that it is a \"blessed\" library.\r\n\r\nI propose that we split !DiffArray off into its own `diffarray` package. This also has the advantage that it can then be maintained by a separate maintainer, if someone is interested, and it will be decoupled from GHC's major release schedule.\r\n\r\nDeadline: 26 July (2 weeks).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->⊥Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3371Spurious "Defined but not used" when using record wildcards2019-07-07T19:04:11ZBaughnSpurious "Defined but not used" when using record wildcardsCode such as
```
{-# LANGUAGE RecordWildCards #-}
module Test(bar) where
data Foo = Foo { a, b :: Int } deriving(Eq)
bar Foo{..} = print a
```
produces "defined but not used" warnings for both a and b, when compiled with -Wall.
The ...Code such as
```
{-# LANGUAGE RecordWildCards #-}
module Test(bar) where
data Foo = Foo { a, b :: Int } deriving(Eq)
bar Foo{..} = print a
```
produces "defined but not used" warnings for both a and b, when compiled with -Wall.
The expected output is that either only a warning for b is given, or none is given.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Spurious \"Defined but not used\" when using record wildcards","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Code such as\r\n{{{\r\n{-# LANGUAGE RecordWildCards #-}\r\nmodule Test(bar) where\r\n\r\ndata Foo = Foo { a, b :: Int } deriving(Eq)\r\n\r\nbar Foo{..} = print a\r\n}}}\r\nproduces \"defined but not used\" warnings for both a and b, when compiled with -Wall.\r\n\r\nThe expected output is that either only a warning for b is given, or none is given.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3374Profiling libraries are not installed2019-07-07T19:04:10Zscsibug@imap.ccProfiling libraries are not installedWhen building GHC from source, profiling libraries are created as requested, but are not installed.
I followed the README's instructions, doing "sh boot; ./configure; make; make install". No custom build.mk was used.
Attempting to comp...When building GHC from source, profiling libraries are created as requested, but are not installed.
I followed the README's instructions, doing "sh boot; ./configure; make; make install". No custom build.mk was used.
Attempting to compile programs with the "-prof" option fails, with a message like:
Could not find module `System.Random':
Perhaps you haven't installed the profiling libraries for package `random-1.0.0.1'?
> Use -v to see a list of the files searched for.
When using the inplace/bin/ghc-stage2 compiler, instead of the installed version, profiled applications can be built without error.
Running "make show VALUE=GhcLibWays" in the build directory confirms that it is set to "v p". Inspection of the library directory confirms that "_p.a" library files exist.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Profiling libraries are not installed","status":"New","operating_system":"MacOS X","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When building GHC from source, profiling libraries are created as requested, but are not installed.\r\n\r\nI followed the README's instructions, doing \"sh boot; ./configure; make; make install\". No custom build.mk was used.\r\n\r\nAttempting to compile programs with the \"-prof\" option fails, with a message like: \r\n\r\n Could not find module `System.Random':\r\n Perhaps you haven't installed the profiling libraries for package `random-1.0.0.1'?\r\n Use -v to see a list of the files searched for.\r\n\r\nWhen using the inplace/bin/ghc-stage2 compiler, instead of the installed version, profiled applications can be built without error.\r\n\r\nRunning \"make show VALUE=GhcLibWays\" in the build directory confirms that it is set to \"v p\". Inspection of the library directory confirms that \"_p.a\" library files exist.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1