GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:18:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/311gmp's memory management2019-07-07T19:18:32Zas49gmp's memory managementI assume ghc allocates the lumps of gmp integers still
on ghc's heap, making it impossible (or very awkward)
to interface to C libraries that use gmp themselves. Is
there a chance that you could use the default memory
allocator for lumps...I assume ghc allocates the lumps of gmp integers still
on ghc's heap, making it impossible (or very awkward)
to interface to C libraries that use gmp themselves. Is
there a chance that you could use the default memory
allocator for lumps starting from ghc 6.4? That would
make my life much easier.
Thanks,
Axel.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/593Cache contents of package.conf in a binary file2019-07-07T19:17:43ZSimon MarlowCache contents of package.conf in a binary fileGHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in `~/.ghc`.
<details><summary>Trac metadata</summary>
| Trac ...GHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in `~/.ghc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cache contents of package.conf in a binary file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC takes about 0.1 secs to read package.conf each time it starts up. This could be improved by caching package.conf in binary format using GHC's binary serialiser, perhaps in {{{~/.ghc}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/714Inconsistency between handling functional dependencies in class and signature...2019-07-07T19:17:18Zclaus.reinke@talk21.comInconsistency between handling functional dependencies in class and signature constraintsthe user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantif...the user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantified type variable tvi must be reachable from type
suggesting that FDs are taken into account when considering reachability
but that only seems to work for signature, not for class constraints,
as the attached example shows. I wouldn't go so far as claiming this
as a bug, but it prevents an otherwise straightforward encoding of
ATS in FDs (where the superclass encodes the type function, see last
month's discussion on haskell-cafe).
\[grr, there isn't a button for attachment on this form, so I'll paste the code\]
```
{-# OPTIONS_GHC -fglasgow-exts #-}
class C a b | a -> b
class C a b => D a
f :: C a b => a
f = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"inconsistency between handling of class and signature constraints","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"the user's guide claims\r\n\r\n7.4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic. \r\n\r\nand we also have \r\n\r\n7.4.3.1 1. Each universally quantified type variable tvi must be reachable from type\r\nsuggesting that FDs are taken into account when considering reachability\r\n\r\nbut that only seems to work for signature, not for class constraints,\r\nas the attached example shows. I wouldn't go so far as claiming this\r\nas a bug, but it prevents an otherwise straightforward encoding of\r\nATS in FDs (where the superclass encodes the type function, see last\r\nmonth's discussion on haskell-cafe).\r\n\r\n[grr, there isn't a button for attachment on this form, so I'll paste the code]\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts #-}\r\nclass C a b | a -> b\r\nclass C a b => D a\r\nf :: C a b => a\r\nf = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/723The package database should be a directory of files instead of a single file2019-07-07T19:17:16ZSimon MarlowThe package database should be a directory of files instead of a single fileThis would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www...This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| 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":"The package database should be a directory of files instead of a single file","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.\r\n\r\nSee: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1259Accessing undefined value in DiffArray returns misleading error message2019-07-07T19:14:27ZguestAccessing undefined value in DiffArray returns misleading error message```
Prelude> :m + Data.Array.Diff
Prelude Data.Array.Diff> :t array
array :: (Ix i, IArray a e) => (i, i) -> [(i, e)] -> a i e
Prelude Data.Array.Diff> array (1,1) [] :: DiffArray Int Int
array (1,1) [(1,*** Exception: MArray: undefined ...```
Prelude> :m + Data.Array.Diff
Prelude Data.Array.Diff> :t array
array :: (Ix i, IArray a e) => (i, i) -> [(i, e)] -> a i e
Prelude Data.Array.Diff> array (1,1) [] :: DiffArray Int Int
array (1,1) [(1,*** Exception: MArray: undefined array element
```
Since DiffArray isn't a MArray(it implements IArray), this is misleading. It should either say IArray or better DiffArray: undefined array element.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1501Panic in RegisterAlloc2019-07-07T19:13:10ZguestPanic in RegisterAllocThe following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened...The following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened)
(GHC version 6.7.20070620 for i386-unknown-linux):
RegisterAlloc.joinToTargets
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in RegisterAlloc","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a panic when compiling with the NCG (i.e. with {{{-fasm}}}).\r\n\r\n{{{\r\nstg_ap_0_fast {\r\n bits32 y, x;\r\n c7: y = bits32[x];\r\n goto c7;\r\n}\r\n}}}\r\n\r\nThe panic is\r\n{{{\r\nghc-6.7.20070620: panic! (the 'impossible' happened)\r\n (GHC version 6.7.20070620 for i386-unknown-linux):\r\n RegisterAlloc.joinToTargets\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/1633Improve error message for kind mismatches2019-07-07T19:12:29ZguestImprove error message for kind mismatches```
ext :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext x = Handle $ \req -> do f <- ask
liftIO $ f x req
```
That's from HAppS/Protocols/HTTP.hs
While trying to bend my head around the ...```
ext :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext x = Handle $ \req -> do f <- ask
liftIO $ f x req
```
That's from HAppS/Protocols/HTTP.hs
While trying to bend my head around the involved types, feeling understanding already creeping somewhere, I, in a desperate attempt, copied the code into my source and changed it to
```
ext' :: Ev st Request res -> ServerPart (EvPar res st) Request Result
ext' x = Handle $ \req -> req
```
hoping to get a clean, expressive and enlightening type error,
I got this:
```
Kind mis-match
Expected kind `* -> *', but `Result' has kind `*'
In the type `ServerPart (EvPar res st) Request Result'
In the type `Ev st Request res
-> ServerPart (EvPar res st) Request Result'
In the type signature for `ext'':
ext' :: Ev st Request res
-> ServerPart (EvPar res st) Request Result
```
Which made me wonder, google and then groan, as I couldn't even figure out what the heck a kind-mismatch is or means, not to mention why ghc points me to the type instead of the code.
My request is for the documentation section "Error messages and their meaning" aka "RTF this if you got that". The terminology of some ghc errors is just begging for references to papers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Now where does this error come from","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\next :: Ev st Request res -> ServerPart (EvPar res st) Request Result\r\next x = Handle $ \\req -> do f <- ask\r\n liftIO $ f x req\r\n}}}\r\n\r\nThat's from HAppS/Protocols/HTTP.hs\r\n\r\nWhile trying to bend my head around the involved types, feeling understanding already creeping somewhere, I, in a desperate attempt, copied the code into my source and changed it to\r\n{{{\r\next' :: Ev st Request res -> ServerPart (EvPar res st) Request Result\r\next' x = Handle $ \\req -> req\r\n}}}\r\nhoping to get a clean, expressive and enlightening type error, \r\n\r\nI got this:\r\n{{{\r\n Kind mis-match\r\n Expected kind `* -> *', but `Result' has kind `*'\r\n In the type `ServerPart (EvPar res st) Request Result'\r\n In the type `Ev st Request res\r\n -> ServerPart (EvPar res st) Request Result'\r\n In the type signature for `ext'':\r\n ext' :: Ev st Request res\r\n -> ServerPart (EvPar res st) Request Result\r\n}}}\r\nWhich made me wonder, google and then groan, as I couldn't even figure out what the heck a kind-mismatch is or means, not to mention why ghc points me to the type instead of the code.\r\n\r\nMy request is for the documentation section \"Error messages and their meaning\" aka \"RTF this if you got that\". The terminology of some ghc errors is just begging for references to papers.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1653GHCi ':set' completion does not list all options2019-07-07T19:12:23ZStefan O'Rear <stefanor@cox.net>GHCi ':set' completion does not list all optionsIn particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
un...In particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
unrecognised flags: -XTyp
Prelude> :set -XTypeFamilies
Prelude> Leaving GHCi.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sorear |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi ':set' completion does not list all options","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sorear"],"type":"Bug","description":"In particular, the new -X options are missing:\r\n\r\n{{{\r\nstefan@stefans:/tmp$ ghci\r\nGHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :set -XTyp(TAB TAB, with no effect)\r\nunrecognised flags: -XTyp\r\nPrelude> :set -XTypeFamilies\r\nPrelude> Leaving GHCi.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1673Template Haskell support for type families2019-07-07T19:12:12Zg9ks157k@acme.softbase.orgTemplate Haskell support for type familiesWould it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------...Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for type families","status":"New","operating_system":"Linux","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"FeatureRequest","description":"Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1735unused binding changes program behaviour2019-07-07T19:11:57ZIan Lynagh <igloo@earth.li>unused binding changes program behaviourI'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:
```
#ifdef FOO
rigidTests :: Maybe (Maybe [YesNo])
rigidTests =
mkTest [Elem "No" []] (Just [No])
#endif
```
(mkTest has a type...I'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:
```
#ifdef FOO
rigidTests :: Maybe (Maybe [YesNo])
rigidTests =
mkTest [Elem "No" []] (Just [No])
#endif
```
(mkTest has a type signature, and all the datatypes are plain old Haskell 98) then the behaviour of the program changes:
Without the function:
```
$ tar -zxf unused_bind_bug.tar.gz
$ cd unused_bind_bug
$ ghc -cpp --make Main
[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )
[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )
[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )
[4 of 6] Compiling State ( State.hs, State.o )
[5 of 6] Compiling Xml ( Xml.hs, Xml.o )
[6 of 6] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
Nothing
```
With the function:
```
$ tar -zxf unused_bind_bug.tar.gz
$ cd unused_bind_bug
$ ghc -cpp -DFOO --make Main
[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )
[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )
[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )
[4 of 6] Compiling State ( State.hs, State.o )
[5 of 6] Compiling Xml ( Xml.hs, Xml.o )
[6 of 6] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ./Main
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.
```
I suspect that the stack overflow is caused by my
```
instance (Xml a, Xml [a]) => Xml [a] where
```
hack to get around #1470 (and if so, that bug is more important to me).
This is with
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.0.20070923
```
but I had the same problem with 6.6.1.
Standalone testcase attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8 |
| 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":"unused binding changes program behaviour","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm not 100% sure this is a bug, but it's certainly surprising. If I add an unused function to my module:\r\n{{{\r\n#ifdef FOO\r\nrigidTests :: Maybe (Maybe [YesNo])\r\nrigidTests =\r\n mkTest [Elem \"No\" []] (Just [No])\r\n#endif\r\n}}}\r\n(mkTest has a type signature, and all the datatypes are plain old Haskell 98) then the behaviour of the program changes:\r\n\r\nWithout the function:\r\n{{{\r\n$ tar -zxf unused_bind_bug.tar.gz\r\n$ cd unused_bind_bug\r\n$ ghc -cpp --make Main\r\n[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )\r\n[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )\r\n[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )\r\n[4 of 6] Compiling State ( State.hs, State.o )\r\n[5 of 6] Compiling Xml ( Xml.hs, Xml.o )\r\n[6 of 6] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main\r\nNothing\r\n}}}\r\n\r\nWith the function:\r\n{{{\r\n$ tar -zxf unused_bind_bug.tar.gz\r\n$ cd unused_bind_bug\r\n$ ghc -cpp -DFOO --make Main\r\n[1 of 6] Compiling SYBWC.Context ( SYBWC/Context.hs, SYBWC/Context.o )\r\n[2 of 6] Compiling SYBWC.Basics ( SYBWC/Basics.hs, SYBWC/Basics.o )\r\n[3 of 6] Compiling SYBWC.Instances ( SYBWC/Instances.hs, SYBWC/Instances.o )\r\n[4 of 6] Compiling State ( State.hs, State.o )\r\n[5 of 6] Compiling Xml ( Xml.hs, Xml.o )\r\n[6 of 6] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n$ ./Main\r\nStack space overflow: current size 8388608 bytes.\r\nUse `+RTS -Ksize' to increase it.\r\n}}}\r\n\r\nI suspect that the stack overflow is caused by my\r\n{{{\r\ninstance (Xml a, Xml [a]) => Xml [a] where\r\n}}}\r\nhack to get around #1470 (and if so, that bug is more important to me).\r\n\r\nThis is with\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.8.0.20070923\r\n}}}\r\nbut I had the same problem with 6.6.1.\r\n\r\nStandalone testcase attached.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1792-ddump-minimal-imports breaks qualified imports (import...as)2019-07-07T19:11:42Zguest-ddump-minimal-imports breaks qualified imports (import...as)When using the `-ddump-minimal-imports` option on a Haskell file, it breaks qualified imports.
Ie, suppose one has a line in a file thus:
```
import qualified Data.ByteString as B (putStr, readFile)
```
Using `-ddump-minimal-imports`...When using the `-ddump-minimal-imports` option on a Haskell file, it breaks qualified imports.
Ie, suppose one has a line in a file thus:
```
import qualified Data.ByteString as B (putStr, readFile)
```
Using `-ddump-minimal-imports` will give you something like this:
```
import Data.ByteString(B.putStr, B.readFile)
```
There are 3 things wrong here:
- `putStr` and `readFile` should not be renamed thus, as obviously `Data.ByteString` has nothing under those names
- `Data.ByteString` is no longer being imported under a different name, so all function uses relying on `B.putStr` etc. will break
- Finally, it's just ugly to have no spaces between the last letter of the module's name and the opening parenthesis.
I see this behavior under GHC 6.6.1, and asl of \#haskell tells me he duplicated the import problem using GHCi version 6.8.0.20071019.
--
gwern6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1811liberate case needs an independent threshold2019-07-07T19:11:38ZSimon Marlowliberate case needs an independent thresholdThe liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.
This accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when buildin...The liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.
This accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when building libraries for the distributions (it's already off in the default build, since the default `GhcLibHcOpts` uses `-O`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| 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":"liberate case causes code duplication","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The liberate-case pass (on with -O2) is causing code duplication in the definition of `hPutStr` in `GHC.IO`.\r\n\r\nThis accounts for 10% of the 25% increase in binary sizes I'm seeing in 6.8.1. We'll be using `-fno-liberate-case` when building libraries for the distributions (it's already off in the default build, since the default `GhcLibHcOpts` uses `-O`).","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1856Improve error message for mutally recursive modules2019-07-07T19:11:25ZguestImprove error message for mutally recursive modulesWhen I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where...When I am trying to compile the following modules:
```
File: Files.hs
module Files where
import SecMonad
File: Lattice.hs
module Lattice where
File: Ref.hs
module Ref where
import SecMonad
File: Screen.hs
module Screen where
import SecMonad
File: Sec.hs
module Sec where
import Lattice
File: SecLib.hs (OBSERVE HERE THAT THE NAME OF THE
MODULE IS NOT THE SAME AS THE FILE)
module SecMonad where
import Lattice
import Sec
import SecMonad
import Files
import Screen
import Ref
File: SecMonad.hs
module SecMonad where
import Lattice
import Sec
```
I got the message:
```
ale@localhost ~/Sec7 $ ghci SecLib.hs -fglasgow-exts
GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 4] Compiling Lattice ( Lattice.hs, interpreted )
[2 of 4] Compiling Sec ( Sec.hs, interpreted )
[3 of 4] Compiling SecIO ( SecIO.hs, interpreted )
Module imports form a cycle for modules:
main:Resources imports: Files Lattice
main:Files imports: SecMonad SecIO Lattice
main:SecMonad
imports: Resources Ref Screen Files SecMonad SecIO Sec Lattice
main:Ref imports: SecMonad SecIO Sec Lattice Data.IORef
main:Screen imports: SecMonad SecIO Lattice
Failed, modules loaded: SecIO, Lattice, Sec.
*SecIO>
```
I think that it would be of great help if the compiler can check if the names of the modules match the name of the files. It took me a while to discover the stupid mistake, and I believe that, when you have a large number of mobules, it might be difficult to find this bug. So, a simple check would help a lot in this situation.
That is it!6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1868Exception fails all exception predicates2019-07-07T19:11:21ZOrphiException fails all exception predicatesAttempting to operate on a file with an invalid filename (e.g., "C:\\C:\\") yields an "invalid parameter" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.
```
test :: IO x -> IO ()
te...Attempting to operate on a file with an invalid filename (e.g., "C:\\C:\\") yields an "invalid parameter" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.
```
test :: IO x -> IO ()
test a = do
catch (a >> return ()) examine
examine :: IOError -> IO ()
examine ioe = do
putStrLn $ "isAlreadyExistsError___" ++ show (isAlreadyExistsError ioe)
putStrLn $ "isDoesNotExistError " ++ show (isDoesNotExistError ioe)
putStrLn $ "isAlreadyInUseError____" ++ show (isAlreadyInUseError ioe)
putStrLn $ "isFullError " ++ show (isFullError ioe)
putStrLn $ "isEOFError_____________" ++ show (isEOFError ioe)
putStrLn $ "isIllegalOperation " ++ show (isIllegalOperation ioe)
putStrLn $ "isPermissionError______" ++ show (isPermissionError ioe)
putStrLn $ "isUserError " ++ show (isUserError ioe)
```
Now try, for example, `test (openFile "C:\\C:\\" ReadMode)`. All 8 predicates above return False. (However, if you do, say, `test (error "no")`, the `catch` function doesn't trap it at all because it's not an `IOError`.)
I was under the impression this is what the "illegal operation" type was for?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| 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":"Exception fails all exception predicates","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attempting to operate on a file with an invalid filename (e.g., \"C:\\C:\\\") yields an \"invalid parameter\" exception. This exception appears to be a kind of `IOError`, yet it fails all 8 exception predicates.\r\n\r\n{{{\r\ntest :: IO x -> IO ()\r\ntest a = do\r\n catch (a >> return ()) examine\r\n\r\nexamine :: IOError -> IO ()\r\nexamine ioe = do\r\n putStrLn $ \"isAlreadyExistsError___\" ++ show (isAlreadyExistsError ioe)\r\n putStrLn $ \"isDoesNotExistError \" ++ show (isDoesNotExistError ioe)\r\n putStrLn $ \"isAlreadyInUseError____\" ++ show (isAlreadyInUseError ioe)\r\n putStrLn $ \"isFullError \" ++ show (isFullError ioe)\r\n putStrLn $ \"isEOFError_____________\" ++ show (isEOFError ioe)\r\n putStrLn $ \"isIllegalOperation \" ++ show (isIllegalOperation ioe)\r\n putStrLn $ \"isPermissionError______\" ++ show (isPermissionError ioe)\r\n putStrLn $ \"isUserError \" ++ show (isUserError ioe)\r\n}}}\r\n\r\nNow try, for example, `test (openFile \"C:\\\\C:\\\\\" ReadMode)`. All 8 predicates above return False. (However, if you do, say, `test (error \"no\")`, the `catch` function doesn't trap it at all because it's not an `IOError`.)\r\n\r\nI was under the impression this is what the \"illegal operation\" type was for?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1886GHC API should preserve and provide access to comments2019-07-07T19:11:16Zclaus.reinke@talk21.comGHC API should preserve and provide access to commentsone class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsin...one class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsing and pretty-printing with the `GHC API` does not currently preserve the source (nor does it generate syntactically valid code..).
consider this simple test: we want to parse a module, then pretty-print it (we might want to adjust the layout, or switch between layout and explicit braces). applying the attached code to itself gives this result:
```
$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace -package ghc -e main API_Layout.hs
module API where
import DynFlags
import GHC
import PprTyThing
import System.Process
import System.IO
import Outputable
import Data.Maybe
instance Num () where
[]
[]
{ fromInteger = undefined }
mode = CompManager
compileToCoreFlag = False
writer >| cmd = runInteractiveCommand cmd >>= \ (i, o, e, p) -> writer i
cmd |> reader = runInteractiveCommand cmd >>= \ (i, o, e, p) -> reader o
ghcDir = "c:/fptools/ghc/compiler/stage2/ghc-inplace --print-libdir"
|>
(fmap dropLineEnds . hGetContents)
where
dropLineEnds = filter (not . (`elem` "\r\n"))
main = defaultErrorHandler defaultDynFlags
$ do s <- newSession . Just =<< ghcDir
flags <- getSessionDynFlags s
(flags, _) <- parseDynamicFlags flags ["-package ghc"]
GHC.defaultCleanupHandler flags
$ do setSessionDynFlags s (flags {hscTarget = HscInterpreted})
addTarget s =<< guessTarget "API_Layout.hs" Nothing
load s LoadAllTargets
prelude <- findModule s (mkModuleName "Prelude") Nothing
usermod <- findModule s (mkModuleName "API") Nothing
setContext s [usermod] [prelude]
Just cm <- checkModule s (mkModuleName "API") compileToCoreFlag
unqual <- getPrintUnqual s
printForUser stdout unqual $ ppr $ parsedSource cm
```
this has lost all comments, including pragmas, and is syntactically invalid!
one suggestion, to avoid upsetting the rest of `ghc`, would be to preserve the comments, with source locations, but to separate them from the main abstract syntax tree. there would also need to be a way to link ast fragments to comments, which might be slightly awkward. perhaps something like:
```
-- was there a comment just preceeding the current AST fragment?
commentsBefore :: AST -> Maybe String
-- was there a comment immediately following the current AST fragment?
commentsAfter :: AST -> Maybe String
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHC API should preserve and provide access to comments","status":"New","operating_system":"Unknown","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"one class of applications of the `GHC API` are program transformations (refactoring, source to source optimisation, partial evaluation, ..) and code layouters (pretty-print, 2html, syntax-colouring, ..). but, even ignoring layout, parsing and pretty-printing with the `GHC API` does not currently preserve the source (nor does it generate syntactically valid code..).\r\n\r\nconsider this simple test: we want to parse a module, then pretty-print it (we might want to adjust the layout, or switch between layout and explicit braces). applying the attached code to itself gives this result:\r\n{{{\r\n$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace -package ghc -e main API_Layout.hs\r\nmodule API where\r\nimport DynFlags\r\nimport GHC\r\nimport PprTyThing\r\nimport System.Process\r\nimport System.IO\r\nimport Outputable\r\nimport Data.Maybe\r\ninstance Num () where\r\n []\r\n []\r\n { fromInteger = undefined }\r\nmode = CompManager\r\ncompileToCoreFlag = False\r\nwriter >| cmd = runInteractiveCommand cmd >>= \\ (i, o, e, p) -> writer i\r\ncmd |> reader = runInteractiveCommand cmd >>= \\ (i, o, e, p) -> reader o\r\nghcDir = \"c:/fptools/ghc/compiler/stage2/ghc-inplace --print-libdir\"\r\n |>\r\n (fmap dropLineEnds . hGetContents)\r\n where\r\n dropLineEnds = filter (not . (`elem` \"\\r\\n\"))\r\nmain = defaultErrorHandler defaultDynFlags\r\n $ do s <- newSession . Just =<< ghcDir\r\n flags <- getSessionDynFlags s\r\n (flags, _) <- parseDynamicFlags flags [\"-package ghc\"]\r\n GHC.defaultCleanupHandler flags\r\n $ do setSessionDynFlags s (flags {hscTarget = HscInterpreted})\r\n addTarget s =<< guessTarget \"API_Layout.hs\" Nothing\r\n load s LoadAllTargets\r\n prelude <- findModule s (mkModuleName \"Prelude\") Nothing\r\n usermod <- findModule s (mkModuleName \"API\") Nothing\r\n setContext s [usermod] [prelude]\r\n Just cm <- checkModule s (mkModuleName \"API\") compileToCoreFlag\r\n unqual <- getPrintUnqual s\r\n printForUser stdout unqual $ ppr $ parsedSource cm\r\n\r\n}}}\r\nthis has lost all comments, including pragmas, and is syntactically invalid!\r\n\r\none suggestion, to avoid upsetting the rest of `ghc`, would be to preserve the comments, with source locations, but to separate them from the main abstract syntax tree. there would also need to be a way to link ast fragments to comments, which might be slightly awkward. perhaps something like:\r\n{{{\r\n-- was there a comment just preceeding the current AST fragment?\r\ncommentsBefore :: AST -> Maybe String\r\n-- was there a comment immediately following the current AST fragment?\r\ncommentsAfter :: AST -> Maybe String\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1954Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving2019-07-07T19:10:54ZmagnusIncorrect "Defined but not used" warning when using GeneralizedNewtypeDerivingWhen compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP...When compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP :: P a -> a
runP = runIdentity . unP
```
I get
```
Bug.hs:7:14: Warning: Defined but not used: data constructor `P'
```
although the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.
<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 | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect \"Defined but not used\" warning when using GeneralizedNewtypeDeriving","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":[""],"type":"Bug","description":"When compiling\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# OPTIONS_GHC -Wall -Werror #-}\r\nmodule Bug(P, runP) where\r\n\r\nimport Control.Monad.Identity(Identity, runIdentity)\r\n\r\nnewtype P a = P { unP :: Identity a } deriving Monad\r\n\r\nrunP :: P a -> a\r\nrunP = runIdentity . unP\r\n}}}\r\nI get \r\n{{{\r\nBug.hs:7:14: Warning: Defined but not used: data constructor `P'\r\n}}}\r\nalthough the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1969enormous compile times2019-07-07T19:10:50Zduncanenormous compile timesSome modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12...Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12 http://www.informatik.uni-freiburg.de/\~thiemann/haskell/WASH/
It is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.
It might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.
`WASH/HTML/HTMLPrelude.hs` is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).
All in all, WASH is an excellent stress test for GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"enormous compile times","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Task","description":"Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.\r\n\r\nHere is an example of a module that takes almost forever to compile. The {{{WASH/HTML/HTMLMonad98.hs}}} module from WASH-2.12 http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/\r\n\r\nIt is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.\r\n\r\nIt might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.\r\n\r\n{{{WASH/HTML/HTMLPrelude.hs}}} is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).\r\n\r\nAll in all, WASH is an excellent stress test for GHC.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://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 branchhttps://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/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 Marlow