GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:07:13Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2712Parallel GC scheduling problems2019-07-07T19:07:13ZSimon MarlowParallel GC scheduling problemsThe parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor...The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.
Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.
If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel GC scheduling problems","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.\r\n\r\nReally we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.\r\n\r\nIf this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2699broken pipe errors are too noisy2019-07-07T19:07:17ZBertram Felgenhauerbroken pipe errors are too noisyThe following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: re...The following program
```
main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
```
produces this output when piped through `head` on a shell:
```
# ./a.out | head -n 1
0
a.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)
#
```
The final error message is annoying. It would be nice if the RTS suppressed it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| 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":"broken pipe errors are too noisy","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program\r\n\r\n{{{\r\nmain = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs)\r\n}}}\r\n\r\nproduces this output when piped through {{{head}}} on a shell:\r\n\r\n{{{\r\n# ./a.out | head -n 1\r\n0\r\na.out: <stdout>: commitAndReleaseBuffer: resource vanished (Broken pipe)\r\n#\r\n}}}\r\n\r\nThe final error message is annoying. It would be nice if the RTS suppressed it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2689make maintainer-clean leaves generated files and directories2019-07-07T19:07:20Zclaus.reinke@talk21.commake maintainer-clean leaves generated files and directoriesBefore updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them.
For the purpose, I've got an alter...Before updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them.
For the purpose, I've got an alternative boringfile (attached) that just hides subrepos and stuff I don't suspect at the moment.
```
$ make maintainer-clean
$ cp .darcs-boring .darcs-boring.safe
$ cp .darcs-subrepos .darcs-boring
$ darcs cha --last=1
Sat Oct 4 18:53:51 GMT Daylight Time 2008 Ian Lynagh <igloo@earth.li>
* prep-bin-dist-mingw complains if it finds a bad version of windres
$ darcs wh -s
M ./.darcs-boring -211 +18
M ./darcs-all -2 +68
$ darcs wh -l >mystuff/leftovers.log
-- output attached
$ cp .darcs-boring.safe .darcs-boring
```
Perhaps this could be made into an automated test, so that leftovers don't keep piling up until someone trips over them (though you probably don't want the buildbots to clean their results away, in case you need to inspect them later)?
See also the related ticket on `make distclean`, #1693.
<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 maintainer-clean leaves generated files and directories","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":"Before updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them. \r\n\r\nFor the purpose, I've got an alternative boringfile (attached) that just hides subrepos and stuff I don't suspect at the moment.\r\n{{{\r\n$ make maintainer-clean\r\n\r\n$ cp .darcs-boring .darcs-boring.safe\r\n$ cp .darcs-subrepos .darcs-boring\r\n\r\n$ darcs cha --last=1\r\nSat Oct 4 18:53:51 GMT Daylight Time 2008 Ian Lynagh <igloo@earth.li>\r\n * prep-bin-dist-mingw complains if it finds a bad version of windres\r\n\r\n$ darcs wh -s\r\nM ./.darcs-boring -211 +18\r\nM ./darcs-all -2 +68\r\n\r\n$ darcs wh -l >mystuff/leftovers.log\r\n-- output attached\r\n\r\n$ cp .darcs-boring.safe .darcs-boring\r\n}}}\r\n\r\nPerhaps this could be made into an automated test, so that leftovers don't keep piling up until someone trips over them (though you probably don't want the buildbots to clean their results away, in case you need to inspect them later)?\r\n\r\nSee also the related ticket on `make distclean`, #1693.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2682Keep going after failed search for module in current directory2019-07-07T19:07:22ZajdKeep going after failed search for module in current directoryInside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAM...Inside a package's source directory after the package has been installed, if I type `ghci` and then `import MODNAME`, where MODNAME is a module in the package, GHCi throws an error: `module main:MODNAME is not loaded`, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.
<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":"Keep going after failed search for module in current directory","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":"Inside a package's source directory after the package has been installed, if I type {{{ghci}}} and then {{{import MODNAME}}}, where MODNAME is a module in the package, GHCi throws an error: {{{module main:MODNAME is not loaded}}}, even though MODNAME is part of the package (in its system-installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2677Detection of TF instance conflict depends on instance order2019-07-07T19:07:23ZreinerpDetection of TF instance conflict depends on instance orderWith 6.10 RC1, the following code compiles without complaint:
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A a = Bool
type instance A Int = Char
```
even though the overlapping instances "A...With 6.10 RC1, the following code compiles without complaint:
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A a = Bool
type instance A Int = Char
```
even though the overlapping instances "A a" and "A Int" conflict. Reordering the instances to
```
{-# OPTIONS -fglasgow-exts #-}
module OverlapTest where
type family A x
type instance A Int = Char
type instance A a = Bool
```
correctly doesn't compile, complaining about conflicting instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Detection of TF instance conflict depends on instance order","status":"New","operating_system":"Unknown/Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":["TF","conflict","instance"],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"With 6.10 RC1, the following code compiles without complaint:\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule OverlapTest where\r\n\r\ntype family A x\r\ntype instance A a = Bool\r\ntype instance A Int = Char\r\n}}}\r\neven though the overlapping instances \"A a\" and \"A Int\" conflict. Reordering the instances to\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule OverlapTest where\r\n\r\ntype family A x\r\ntype instance A Int = Char\r\ntype instance A a = Bool\r\n}}}\r\ncorrectly doesn't compile, complaining about conflicting instances.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2613configure should summarize important results at the end of its run2019-07-07T19:07:42Zclaus.reinke@talk21.comconfigure should summarize important results at the end of its run`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.
It would be useful if the most important points (which ghc/gcc/tools/.. are going ...`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.
It would be useful if the most important points (which ghc/gcc/tools/.. are going to be used; which features are disabled because of missing tools) were summarized at the end of the configure run.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.9 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"configure should summarize important results at the end of its run","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"`./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning.\r\n\r\nIt would be useful if the most important points (which ghc/gcc/tools/.. are going to be used; which features are disabled because of missing tools) were summarized at the end of the configure run.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2611print022 fails2019-07-07T19:07:42ZIan Lynagh <igloo@earth.li>print022 failsprint022 fails:
```
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------...print022 fails:
```
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"print022 fails","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"print022 fails:\r\n{{{\r\n-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23\r\n+test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchmnislaihmnislaihhttps://gitlab.haskell.org/ghc/ghc/-/issues/2608Direct support for unit tests in Cabal2019-07-07T19:07:43ZKari PahulaDirect support for unit tests in CabalI'm passing along Debian wishlist bug [\#458495](http://bugs.debian.org/458495) for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.
I didn...I'm passing along Debian wishlist bug [\#458495](http://bugs.debian.org/458495) for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.
I didn't look overly much if something like this has been already implemented. My apologies if this is just more noise.
----
It would be nice if there was a simple way to build and run tests for
Cabalized packages.
Cabal provides a "test" target, but by default it does nothing.
Furthermore, you can't really build test cases using the Cabal
infrastructure, since any executables that you list get installed.
Searching on Google for how to integrate a test suite into Cabal turns
up suggestions such as "make a system() call from runTests to
The attached patch adds two new flags to the build information for
executables and libraries:
```
* do-not-install: if set to True, keeps an executable that it's set on
from being installed. This is necessary to keep test suites from
ending up in $prefix/bin, but may be useful for other build-time
utilities.
* is-test: if set to True on an executable, the executable will be
invoked by the "test" target of the setup script. Note that this
doesn't attempt to be at all smart about building the executable(s);
it just blindly invokes the test command(s) and returns a failure if
any of them fail.
```
The patch should be fairly straightforward. The need to do suppression
of installing executables in compiler-specific code is a bit ugly;
this could maybe be cleaned up with an equivalent to withExe that drops
non-installed executables and by writing and using a similar routine for
libraries.
This also changes the API of Cabal: runTests now takes an integer as
its first argument, indicating the verbosity level provided as an
argument on the command-line. The Boolean that was passed before
didn't have any purpose I could see and was always False, so it
shouldn't be hard to adapt existing code to this change. On the other
hand, the API can be preserved by just hard-coding a verbosity level.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Direct support for unit tests in Cabal","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm passing along Debian wishlist bug [http://bugs.debian.org/458495 #458495] for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having.\r\n\r\nI didn't look overly much if something like this has been already implemented. My apologies if this is just more noise.\r\n\r\n----\r\nIt would be nice if there was a simple way to build and run tests for\r\nCabalized packages.\r\n\r\nCabal provides a \"test\" target, but by default it does nothing.\r\nFurthermore, you can't really build test cases using the Cabal\r\ninfrastructure, since any executables that you list get installed.\r\nSearching on Google for how to integrate a test suite into Cabal turns\r\nup suggestions such as \"make a system() call from runTests to \r\n\r\nThe attached patch adds two new flags to the build information for\r\nexecutables and libraries:\r\n\r\n{{{\r\n * do-not-install: if set to True, keeps an executable that it's set on\r\n from being installed. This is necessary to keep test suites from\r\n ending up in $prefix/bin, but may be useful for other build-time\r\n utilities.\r\n\r\n * is-test: if set to True on an executable, the executable will be\r\n invoked by the \"test\" target of the setup script. Note that this\r\n doesn't attempt to be at all smart about building the executable(s);\r\n it just blindly invokes the test command(s) and returns a failure if\r\n any of them fail.\r\n}}}\r\n\r\nThe patch should be fairly straightforward. The need to do suppression\r\nof installing executables in compiler-specific code is a bit ugly;\r\nthis could maybe be cleaned up with an equivalent to withExe that drops\r\nnon-installed executables and by writing and using a similar routine for\r\nlibraries.\r\n\r\nThis also changes the API of Cabal: runTests now takes an integer as\r\nits first argument, indicating the verbosity level provided as an\r\nargument on the command-line. The Boolean that was passed before\r\ndidn't have any purpose I could see and was always False, so it\r\nshouldn't be hard to adapt existing code to this change. On the other\r\nhand, the API can be preserved by just hard-coding a verbosity level.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2561Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_...2019-07-07T19:07:57ZIan Lynagh <igloo@earth.li>Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret)With this patch:
```
hunk ./compiler/parser/Lexer.x 535
+#if __GLASGOW_HASKELL__ >= 609
+ | ITstring !FastString
+#else
hunk ./compiler/parser/Lexer.x 539
+#endif
```
something goes wrong. The first sign, when validating, is that ...With this patch:
```
hunk ./compiler/parser/Lexer.x 535
+#if __GLASGOW_HASKELL__ >= 609
+ | ITstring !FastString
+#else
hunk ./compiler/parser/Lexer.x 539
+#endif
```
something goes wrong. The first sign, when validating, is that `timeout` is broken:
```
timeout: internal error: stg_ap_v_ret
(GHC version 6.9.20080902 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
If you use the python timeout program instead then you find a few tests fail, e.g.:
```
testsuite/tests/ghc-regress/codeGen/should_run$ '/home/ian/ghc/darcs/st2/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o cg052 cg052.hs -O -fasm -funbox-strict-fields
testsuite/tests/ghc-regress/codeGen/should_run$ ./cg052
ok
cg052: internal error: stg_ap_v_ret
(GHC version 6.9.20080902 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
zsh: abort ./cg052
```
I'm not sure what's going on, but it seems to be repeatable.
<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 | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Using \"ITstring !FastString\" in Lexer.x goes wrong (internal error: stg_ap_v_ret)","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With this patch:\r\n{{{\r\nhunk ./compiler/parser/Lexer.x 535\r\n+#if __GLASGOW_HASKELL__ >= 609\r\n+ | ITstring !FastString\r\n+#else\r\nhunk ./compiler/parser/Lexer.x 539\r\n+#endif\r\n}}}\r\nsomething goes wrong. The first sign, when validating, is that `timeout` is broken:\r\n{{{\r\ntimeout: internal error: stg_ap_v_ret\r\n (GHC version 6.9.20080902 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\nIf you use the python timeout program instead then you find a few tests fail, e.g.:\r\n{{{\r\ntestsuite/tests/ghc-regress/codeGen/should_run$ '/home/ian/ghc/darcs/st2/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o cg052 cg052.hs -O -fasm -funbox-strict-fields\r\ntestsuite/tests/ghc-regress/codeGen/should_run$ ./cg052 \r\nok\r\ncg052: internal error: stg_ap_v_ret\r\n (GHC version 6.9.20080902 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nzsh: abort ./cg052\r\n}}}\r\nI'm not sure what's going on, but it seems to be repeatable.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2500Unrecognised pragma complained about twice2019-07-07T19:08:18ZSimon Peyton JonesUnrecognised pragma complained about twice```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<details><summary>T...```
module Foo where
{-# FOO wibble #-}
f x = x
```
We get two complaints:
```
c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs
Foo.hs:3:0: Unrecognised pragma
Foo.hs:3:0: Unrecognised pragma
sh-2.04$
```
<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 | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Unrecognised pragma complained about twice","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\nmodule Foo where\r\n\r\n{-# FOO wibble #-}\r\nf x = x\r\n}}}\r\nWe get two complaints:\r\n{{{\r\nc:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\n\r\nFoo.hs:3:0: Unrecognised pragma\r\nsh-2.04$ \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2493implement proposed Qualified Operator syntax2019-07-07T19:08:20ZIsaac Dupreeimplement proposed Qualified Operator syntaxproposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for ...proposed for haskell', we like the idea, we should implement it.
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449
Need to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).
while searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"implement proposed Qualified Operator syntax","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"proposed for haskell', we like the idea, we should implement it.\r\n\r\nhttp://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators\r\n\r\nhttp://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449\r\n\r\nNeed to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing).\r\n\r\nwhile searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2443@EnableWin32DLLs@ in mk/config.mk2019-07-07T19:08:33Zrurban@EnableWin32DLLs@ in mk/config.mk```
@EnableWin32DLLs@ should be temp. disabled also.
[EnableWin32DLLs.patch
rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410
-DLLized=@EnableWin32DLLs@
+#temp. disabled. was @EnableWin32DLLs@
+DLLized=NO
``````
@EnableWin32DLLs@ should be temp. disabled also.
[EnableWin32DLLs.patch
rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410
-DLLized=@EnableWin32DLLs@
+#temp. disabled. was @EnableWin32DLLs@
+DLLized=NO
```6.12 branchrurbanrurbanhttps://gitlab.haskell.org/ghc/ghc/-/issues/2226duplicate samples in heap profiling (-hc) output on 6.8.22019-07-07T19:09:38Zclemensduplicate samples in heap profiling (-hc) output on 6.8.2I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summar...I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"duplicate samples in heap profiling (-hc) output on 6.8.2","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2211Installing latest GHC-6.8.2 stable: pwd with floating point exception2019-07-07T19:09:42ZguestInstalling latest GHC-6.8.2 stable: pwd with floating point exceptionI tried to install
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2
on Kubuntu. It was reported to be build properly:
> http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html
but I ...I tried to install
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2
on Kubuntu. It was reported to be build properly:
> http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html
but I get:
```
/tmp/ghc-6.8.2.20080410> ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Which we'll further canonicalise into: i386-unknown-linux
checking for path to top of build tree... configure: error: cannot determine current directory
```
From other reports I got to know that this might have to do with the custom 'pwd' of ghc installation. Indeed I get:
```
/tmp/ghc-6.8.2.20080410> ./utils/pwd/pwd
Floating point exception
```
<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 | ghc@henning-thielemann.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Installing latest GHC-6.8.2 stable: pwd with floating point exception","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ghc@henning-thielemann.de"],"type":"Bug","description":"I tried to install\r\n http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386-unknown-linux.tar.bz2\r\non Kubuntu. It was reported to be build properly:\r\n http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html\r\nbut I get:\r\n\r\n{{{\r\n/tmp/ghc-6.8.2.20080410> ./configure\r\nchecking build system type... i686-pc-linux-gnu\r\nchecking host system type... i686-pc-linux-gnu\r\nchecking target system type... i686-pc-linux-gnu\r\nWhich we'll further canonicalise into: i386-unknown-linux\r\nchecking for path to top of build tree... configure: error: cannot determine current directory\r\n}}}\r\n\r\nFrom other reports I got to know that this might have to do with the custom 'pwd' of ghc installation. Indeed I get:\r\n\r\n{{{\r\n/tmp/ghc-6.8.2.20080410> ./utils/pwd/pwd\r\nFloating point exception\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2210ghci gets into weird state if loading a module with a bad LANGUAGE pragma2019-07-07T19:09:42Zbosghci gets into weird state if loading a module with a bad LANGUAGE pragmaTry loading a module like this into `ghci`:
```
{-# LANGUAGE BreakMe #-}
```
This gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.
<details><summary>Trac metadata</summary>
| Trac fiel...Try loading a module like this into `ghci`:
```
{-# LANGUAGE BreakMe #-}
```
This gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghci gets into weird state if loading a module with a bad LANGUAGE pragma","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Try loading a module like this into `ghci`:\r\n\r\n{{{\r\n{-# LANGUAGE BreakMe #-}\r\n}}}\r\n\r\nThis gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2203TFs in class instances heads2019-07-07T19:09:44ZManuel M T ChakravartyTFs in class instances headsGanesh posted the following example on haskell-cafe:
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class B...Ganesh posted the following example on haskell-cafe:
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class Bar b where
bar :: b -> Int
instance Foo a => Bar (Either a (TheFoo a)) where
bar (Left a) = foo' a
bar (Right b) = foo' (foo b :: a)
instance Foo Int where
type TheFoo Int = Int
foo = id
foo' = id
val :: Either Int Int
val = Left 5
res :: Int
res = bar val
```
It fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`.
Moreover, the corrected code
```
{-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-}
module Test1a where
class Foo a where
type TheFoo a
foo :: TheFoo a -> a
foo' :: a -> Int
class Bar b where
bar :: b -> Int
instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where
bar (Left a) = foo' a
bar (Right b) = foo' (foo b :: a)
instance Foo Int where
type TheFoo Int = Int
foo = id
foo' = id
val :: Either Int Int
val = Left 5
res :: Int
res = bar val
```
requires `UndecidableInstances`, although it shouldn't.
We should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"TFs in class instances heads","status":"New","operating_system":"Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chak"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":["ganesh@earth.li"],"type":"Bug","description":"Ganesh posted the following example on haskell-cafe:\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-}\r\n\r\nmodule Test1a where\r\n\r\nclass Foo a where\r\n type TheFoo a\r\n foo :: TheFoo a -> a\r\n foo' :: a -> Int\r\n\r\nclass Bar b where\r\n bar :: b -> Int\r\n\r\ninstance Foo a => Bar (Either a (TheFoo a)) where\r\n bar (Left a) = foo' a\r\n bar (Right b) = foo' (foo b :: a)\r\n\r\ninstance Foo Int where\r\n type TheFoo Int = Int\r\n foo = id\r\n foo' = id\r\n\r\nval :: Either Int Int\r\nval = Left 5\r\n\r\nres :: Int\r\nres = bar val\r\n}}}\r\nIt fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`.\r\n\r\nMoreover, the corrected code\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-}\r\n\r\nmodule Test1a where\r\n\r\nclass Foo a where\r\n type TheFoo a\r\n foo :: TheFoo a -> a\r\n foo' :: a -> Int\r\n\r\nclass Bar b where\r\n bar :: b -> Int\r\n\r\ninstance (b ~ TheFoo a, Foo a) => Bar (Either a b) where\r\n bar (Left a) = foo' a\r\n bar (Right b) = foo' (foo b :: a)\r\n\r\ninstance Foo Int where\r\n type TheFoo Int = Int\r\n foo = id\r\n foo' = id\r\n\r\nval :: Either Int Int\r\nval = Left 5\r\n\r\nres :: Int\r\nres = bar val\r\n}}}\r\nrequires `UndecidableInstances`, although it shouldn't.\r\n\r\nWe should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchManuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/2197GHCi doesn't work when built with way=p2019-07-07T19:09:45ZSamuel BronsonGHCi doesn't work when built with way=pI don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...
```
naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc-inplace_p --interactive
GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help
ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries/ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'
Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim'
```6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2191A way to programmatically cause GHC to report the cost center stack associate...2019-07-07T19:09:47ZSamuel BronsonA way to programmatically cause GHC to report the cost center stack associated with a valueI find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this in...I find that I often wish I could ask GHC to tell me "where did \*that\* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:
reportCssFor :: a -\> b -\> b
I wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"A way to programmatically cause GHC to report the cost center stack associated with a value","status":"New","operating_system":"Unknown","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I find that I often wish I could ask GHC to tell me \"where did *that* value come from?\" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps:\r\n\r\nreportCssFor :: a -> b -> b\r\n\r\nI wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2089reading the package db is slow2019-07-07T19:10:16Zduncanreading the package db is slowWith a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.
I have a rather fast x86-64 machine and 160 registered packages. Here are some timings...With a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.
I have a rather fast x86-64 machine and 160 registered packages. Here are some timings:
```
$ time ghc-pkg list > /dev/null
user 0m1.164s
$ time ghc -c does-not-exist.c 2> /dev/null
real 0m0.612s
$ time hsc2hs does-exist.hsc --cflag=--version 2> /dev/null
user 0m0.572s
```
So since cabal configure involves running all of the above it starts to take a while:
```
$ time cabal configure
Configuring cabal-install-0.4.3...
real 0m2.241s
user 0m1.916s
```
The obvious solution is to use a binary cache of the package db containing the most commonly needed mappings like module name -\> package etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"reading the package db is slow","status":"New","operating_system":"Multiple","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up.\r\n\r\nI have a rather fast x86-64 machine and 160 registered packages. Here are some timings:\r\n\r\n{{{\r\n$ time ghc-pkg list > /dev/null\r\nuser 0m1.164s\r\n\r\n$ time ghc -c does-not-exist.c 2> /dev/null\r\nreal 0m0.612s\r\n\r\n$ time hsc2hs does-exist.hsc --cflag=--version 2> /dev/null\r\nuser 0m0.572s\r\n}}}\r\n\r\nSo since cabal configure involves running all of the above it starts to take a while:\r\n{{{\r\n$ time cabal configure\r\nConfiguring cabal-install-0.4.3...\r\nreal 0m2.241s\r\nuser 0m1.916s\r\n}}}\r\n\r\nThe obvious solution is to use a binary cache of the package db containing the most commonly needed mappings like module name -> package etc.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2006unreachable GADT pattern clauses show up as warnings with -Wall2019-09-30T21:34:56Zryaniunreachable GADT pattern clauses show up as warnings with -WallIn the following code, there is a line commented out. With it commented out, I get the following warning:
```
patternbug.hs:10:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `interpret': Patterns not mat...In the following code, there is a line commented out. With it commented out, I get the following warning:
```
patternbug.hs:10:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `interpret': Patterns not matched: EVar
```
With it uncommented, I get the following compiler error:
```
patternbug.hs:11:10:
Inaccessible case alternative: Can't match types `()' and `(a, vs)'
In the pattern: EVar
In the definition of `interpret':
interpret EVar = error "unreachable"
```
The exhaustive pattern-matching algorithm should ignore unreachable cases in its analysis.
```
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE GADTs #-}
module PatternBug where
data Expr a vs where
EPrim :: String -> a -> Expr a vs
EVar :: Expr a (a,vs)
interpret :: Expr a () -> a
interpret (EPrim _ a) = a
-- interpret EVar = error "unreachable"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ryani.spam@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unreachable GADT pattern clauses show up as warnings with -Wall","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ryani.spam@gmail.com"],"type":"Bug","description":"In the following code, there is a line commented out. With it commented out, I get the following warning:\r\n\r\n{{{\r\npatternbug.hs:10:0:\r\n Warning: Pattern match(es) are non-exhaustive\r\n\t In the definition of `interpret': Patterns not matched: EVar\r\n}}}\r\n\r\nWith it uncommented, I get the following compiler error:\r\n{{{\r\npatternbug.hs:11:10:\r\n Inaccessible case alternative: Can't match types `()' and `(a, vs)'\r\n In the pattern: EVar\r\n In the definition of `interpret':\r\n\tinterpret EVar = error \"unreachable\"\r\n}}}\r\n\r\nThe exhaustive pattern-matching algorithm should ignore unreachable cases in its analysis.\r\n\r\n{{{\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE GADTs #-}\r\nmodule PatternBug where\r\n\r\ndata Expr a vs where\r\n EPrim :: String -> a -> Expr a vs\r\n EVar :: Expr a (a,vs)\r\n\r\ninterpret :: Expr a () -> a\r\ninterpret (EPrim _ a) = a\r\n-- interpret EVar = error \"unreachable\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branch