GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:00:30Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4114Add a flag to remove/delete intermediate files generated by GHC2019-07-07T19:00:30ZguestAdd a flag to remove/delete intermediate files generated by GHCSee for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or
http://www.haskell.org/pipermail/xmonad/2010-May/010180.html /
Currently GHC generates \*.o and \*.hi files for executables...See for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or
http://www.haskell.org/pipermail/xmonad/2010-May/010180.html /
Currently GHC generates \*.o and \*.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.
(And they may be worse than that. I occasionally see users in \#xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)
There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in \~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).
Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | gwern0@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add a flag to remove/delete intermediate files generated by GHC","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["gwern0@gmail.com"],"type":"FeatureRequest","description":"See for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or\r\nhttp://www.haskell.org/pipermail/xmonad/2010-May/010180.html / \r\n\r\nCurrently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.\r\n\r\n(And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)\r\n\r\nThere doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).\r\n\r\nOf course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1kaihakaihahttps://gitlab.haskell.org/ghc/ghc/-/issues/3384Add HsSyn prettyprinter tests2019-07-07T19:04:07ZIan Lynagh <igloo@earth.li>Add HsSyn prettyprinter testsAdd HsSyn prettyprinter tests. See #1966 for some discussion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Typ...Add HsSyn prettyprinter tests. See #1966 for some discussion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add HsSyn prettyprinter tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Add HsSyn prettyprinter tests. See #1966 for some discussion.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/1791heap overflow should generate an exception2022-01-25T09:55:21Zguestheap overflow should generate an exceptionHeap overflow should produce a `HeapOverflow` exception that can be caught, rather than shutting down the entire RTS immediately.
\[Original ticket description follows. The submitter happened to expose another bug, which was that heap o...Heap overflow should produce a `HeapOverflow` exception that can be caught, rather than shutting down the entire RTS immediately.
\[Original ticket description follows. The submitter happened to expose another bug, which was that heap overflow was not detected at all when a single allocation exceeded the maximum heap size. The program below now exits with a "Heap exhausted" message.\]
----
I want to use the -M option for the goals that are stated in the manual.
```
./TestProgram +RTS -M5m -RTS
```
Expected output:
```
Something like "out of heap space"
```
Actual result:
```
Machine going into a state where it swaps memory
```
This is the code for TestProgram:
```
import Control.Monad.ST
import Data.Array.ST
import Data.Array.MArray
import Data.Array.Base(unsafeNewArray_)
main = print (runST (do make_empty_table >> return ()))
make_empty_table:: ST s (STArray s (Int, Int) (Maybe ep))
make_empty_table =
unsafeNewArray_ ((1, 1), (16384, 16384))
```
This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015. 8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13832No parameter-validation in Control.Concurrent.setNumCapabilities2019-07-07T18:19:54ZAlistairWardNo parameter-validation in Control.Concurrent.setNumCapabilities```
> ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Control.Concurr...```
> ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Control.Concurrent.setNumCapabilities $ negate 1
malloc: failed on request for 18446744073709551104 bytes; message: moreCapabilities
```
The parameter is forwarded to the underlying C-function without validation, the runtime then crashes; no exception is thrown.
This behaviour also exists in ghc 8.0.28.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13791Document allowed syntax in WARNING and DEPRECATED pragmas2019-07-07T18:20:03ZphischuDocument allowed syntax in WARNING and DEPRECATED pragmasGHC accepts the following deprecation pragma:
```hs
{-# DEPRECATED f ["f is deprecated","use g instead"] #-}
f :: a -> a
f x = x
```
The deprecation message here is a list of strings. I didn't expect this to be allowed because [https:/...GHC accepts the following deprecation pragma:
```hs
{-# DEPRECATED f ["f is deprecated","use g instead"] #-}
f :: a -> a
f x = x
```
The deprecation message here is a list of strings. I didn't expect this to be allowed because [https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#warning-and-deprecated-pragmas](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#warning-and-deprecated-pragmas) only shows examples where the deprecation message is a single string.
Are there other forms of deprecation message allowed by GHC?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Document allowed syntax in WARNING and DEPRECATED pragmas","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC accepts the following deprecation pragma:\r\n\r\n{{{#!hs\r\n{-# DEPRECATED f [\"f is deprecated\",\"use g instead\"] #-}\r\nf :: a -> a\r\nf x = x\r\n}}}\r\n\r\nThe deprecation message here is a list of strings. I didn't expect this to be allowed because [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#warning-and-deprecated-pragmas] only shows examples where the deprecation message is a single string.\r\n\r\nAre there other forms of deprecation message allowed by GHC?","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13665Broken Link in GHC Docs for Custom compile-time errors2019-07-07T18:20:42ZatwupackBroken Link in GHC Docs for Custom compile-time errorsHello,
in the GHC documentation for custom compile-time errors is a link to the GHC.TypeLits module which is broken. It points to GHC.TypeList instead of GHC.TypeLits.
This is the case for 8.0.1, 8.0.2 and 8.2.1-rc1 as far as I have ch...Hello,
in the GHC documentation for custom compile-time errors is a link to the GHC.TypeLits module which is broken. It points to GHC.TypeList instead of GHC.TypeLits.
This is the case for 8.0.1, 8.0.2 and 8.2.1-rc1 as far as I have checked.
URL: https://downloads.haskell.org/\~ghc/8.2.1-rc1/docs/html/users_guide/glasgow_exts.html\#custom-compile-time-errors
André
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.2.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken Link in GHC Docs for Custom compile-time errors","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nin the GHC documentation for custom compile-time errors is a link to the GHC.TypeLits module which is broken. It points to GHC.TypeList instead of GHC.TypeLits.\r\n\r\nThis is the case for 8.0.1, 8.0.2 and 8.2.1-rc1 as far as I have checked.\r\n\r\nURL: https://downloads.haskell.org/~ghc/8.2.1-rc1/docs/html/users_guide/glasgow_exts.html#custom-compile-time-errors\r\n\r\nAndré\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13508Clarify Some Restrictions on Compact Regions2019-07-07T18:21:34ZAndrew MartinClarify Some Restrictions on Compact RegionsI've been reading over the docs for using compact regions here: [https://phabricator-files.haskell.org/file/data/uqmgx4accjldseyd34xj/PHID-FILE-3sihhhdhl4gaeszvphzb/Compact.hs](https://phabricator-files.haskell.org/file/data/uqmgx4accjld...I've been reading over the docs for using compact regions here: [https://phabricator-files.haskell.org/file/data/uqmgx4accjldseyd34xj/PHID-FILE-3sihhhdhl4gaeszvphzb/Compact.hs](https://phabricator-files.haskell.org/file/data/uqmgx4accjldseyd34xj/PHID-FILE-3sihhhdhl4gaeszvphzb/Compact.hs). I'm pretty excited about this feature, but there's one thing that the docs don't make totally clear. Can MutableByteArray\# be placed in a compact region? Near the top, the docs specifically say that "object\[s\] with mutable pointer fields" cannot be compacted, but that doesn't rule out `MutableByteArray#`. Later down, in the docs for `compact`, this restriction is broadened to any mutable data.
I would like to see the docs clarify this better. The existence of `resizeMutableByteArray#` makes me think that it should not possible, but I'd like to be sure. Thanks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | libraries/compact |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clarify Some Restrictions on Compact Regions","status":"New","operating_system":"","component":"libraries/compact","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've been reading over the docs for using compact regions here: [https://phabricator-files.haskell.org/file/data/uqmgx4accjldseyd34xj/PHID-FILE-3sihhhdhl4gaeszvphzb/Compact.hs]. I'm pretty excited about this feature, but there's one thing that the docs don't make totally clear. Can MutableByteArray# be placed in a compact region? Near the top, the docs specifically say that \"object[s] with mutable pointer fields\" cannot be compacted, but that doesn't rule out `MutableByteArray#`. Later down, in the docs for `compact`, this restriction is broadened to any mutable data.\r\n\r\nI would like to see the docs clarify this better. The existence of `resizeMutableByteArray#` makes me think that it should not possible, but I'd like to be sure. Thanks.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/13414shebang + literate haskell causes line numbering skew2019-07-07T18:21:59ZSergei Trofimovichshebang + literate haskell causes line numbering skewNoticed on doctest's Setup.lhs file. Minimal example:
```hs
#!/usr/bin/env runhaskell
> main = return ()
```
```
$ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup
[1 of 1] Compiling Main ( Setup.lhs, Setup.o )
Setup.lhs:...Noticed on doctest's Setup.lhs file. Minimal example:
```hs
#!/usr/bin/env runhaskell
> main = return ()
```
```
$ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup
[1 of 1] Compiling Main ( Setup.lhs, Setup.o )
Setup.lhs:1:3: warning: [-Wmissing-signatures]
Top-level binding with no type signature: main :: IO ()
|
1 | #!/usr/bin/env runhaskell
| ^^^^
```
Notice how it points 4 characters a line before **main**.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shebang + literate haskell causes line numbering skew","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Noticed on doctest's Setup.lhs file. Minimal example:\r\n{{{#!hs\r\n#!/usr/bin/env runhaskell\r\n> main = return ()\r\n}}}\r\n\r\n{{{\r\n$ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup\r\n[1 of 1] Compiling Main ( Setup.lhs, Setup.o )\r\n\r\nSetup.lhs:1:3: warning: [-Wmissing-signatures]\r\n Top-level binding with no type signature: main :: IO ()\r\n |\r\n1 | #!/usr/bin/env runhaskell\r\n | ^^^^\r\n}}}\r\n\r\nNotice how it points 4 characters a line before '''main'''.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13320Unfortunate compiler loop when creating type loop (with UndecidableInstances)2019-07-07T18:22:27ZPtivalUnfortunate compiler loop when creating type loop (with UndecidableInstances)I'm afraid this will simply be seen as "that's what happens when you use UndecidableInstances", but I might as well document this issue I had.
Trying to play with a "Trees that Grow" syntax, I encountered an issue when making a mistake,...I'm afraid this will simply be seen as "that's what happens when you use UndecidableInstances", but I might as well document this issue I had.
Trying to play with a "Trees that Grow" syntax, I encountered an issue when making a mistake, that can be boiled down to the following:
```hs
{-# language ConstraintKinds, FlexibleContexts, TypeFamilies, UndecidableInstances #-}
module Loop where
import GHC.Exts (Constraint)
import Test.QuickCheck
type family X_Var ξ
data TermX ξ = Var (X_Var ξ)
type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) )
--genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ)
genTerm 0 = Var <$> arbitrary
genTerm n = Var <$> genTerm (n - 1)
--instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where
--arbitrary = sized genTerm
```
This code will compile correctly, and generate:
```hs
genTerm :: (X_Var ξ ~ TermX ξ, Arbitrary (TermX ξ), Eq t, Num t) => t -> Gen (TermX ξ)
```
Which is correct (though, not the type I had intended, since my code had a mistake).
Now, if you uncomment the "instance" line only, the compiler will loop.
Adding the commented out type, of course, gives a type error where it's due.
I was just wondering whether this type of error fell within the "loops that should be caught by the compiler".8.2.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/13114UniqSet definition seems shady2019-07-07T18:23:35ZDavid FeuerUniqSet definition seems shadyCurrently,
```hs
type UniqSet a = UniqFM a
```
The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is
```hs
newtype ...Currently,
```hs
type UniqSet a = UniqFM a
```
The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is
```hs
newtype UniqSet a = US (UniqFM a)
```
Unfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"UniqSet definition seems shady","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently,\r\n\r\n{{{#!hs\r\ntype UniqSet a = UniqFM a\r\n}}}\r\n\r\nThe key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is\r\n\r\n{{{#!hs\r\nnewtype UniqSet a = US (UniqFM a)\r\n}}}\r\n\r\nUnfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/13079Fix typo in comment2019-07-07T18:23:48ZforkiFix typo in comment"threshold" is misspelled "threshhold" in `compiler/utils/Util.hs`."threshold" is misspelled "threshhold" in `compiler/utils/Util.hs`.8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13068GHC should not allow modules to define instances of abstract type classes2019-07-07T18:23:51ZEdward Z. YangGHC should not allow modules to define instances of abstract type classeshs-boot files permit a type class to be given "abstractly", in which case any implementation of the type class is permissible. But it does not reject instances defined for such a class.
```hs
-- A.hs-boot
module A where
class C a
-- B....hs-boot files permit a type class to be given "abstractly", in which case any implementation of the type class is permissible. But it does not reject instances defined for such a class.
```hs
-- A.hs-boot
module A where
class C a
-- B.hs
module B where
import {-# SOURCE #-} A
instance C Int where
-- A.hs
module A where
import B
class C a where
f :: a
-- Main.hs
import A
main = print (f :: Int)
```
I get this when I build with `--make`:
```
ezyang@sabre:~$ ghc-head --make C.hs -fforce-recomp
[1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot )
[2 of 4] Compiling B ( B.hs, B.o )
[3 of 4] Compiling A ( A.hs, A.o )
[4 of 4] Compiling Main ( C.hs, C.o )
Linking C ...
./B.o:(.data+0x0): undefined reference to `A_CZCC_con_info'
collect2: error: ld returned 1 exit status
```8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12851Regression: GHC doesn't show filepaths by default anymore2019-07-07T18:24:53ZHerbert Valerio Riedelhvr@gnu.orgRegression: GHC doesn't show filepaths by default anymoreSorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner.
I'm deliberately declaring this a regression since I consider this a bad default. And not f...Sorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner.
I'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-)
Don't get me wrong, I can see usefulness in the `-fno-show-source-paths` feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path *by default*, and I see no way to restore this as the default behaviour of GHC short of patching GHC.
```
[1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o)
```
First of all, if we drop filepaths, then please drop them completely, either I need more information about which `.hs` file was used as source, or I don't need it at all, so this ` (.hs -> .o)` suffix is just noise to me; not the least because the `-> .o` part carries almost no information for me. If the premise of `-fno-show-source-paths` is that we know how we called GHC and thereby know what is being compiled, showing `(.hs -> .o)` is pointless.
Morever, `-f(no-)show-source-paths` is a lie/misnomer, as it doesn't only control the \*source\* path display, but \*also\* the \*output\* path display!
Also, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work.
Finally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source-paths where tab-completing my way to the source path is too tedious.
This is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer.
So, in summary I propose to
- Make `-fshow-source-paths` the default again
- drop the `(.hs->.o)` suffix in `-fno-show-show-source-paths`
- consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe
- Have `-f(no-)show-source-paths` control the source-path display
- Have `-f(no-)show-output-paths` control the output-path display
> - As a compromise, consider `-fshow-source-paths -fno-show-output-paths` becoming the new default.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression: GHC doesn't show filepaths by default anymore","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["regression"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner.\r\n\r\nI'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-)\r\n\r\nDon't get me wrong, I can see usefulness in the `-fno-show-source-paths` feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path ''by default'', and I see no way to restore this as the default behaviour of GHC short of patching GHC.\r\n\r\n\r\n{{{\r\n [1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o)\r\n}}}\r\n\r\nFirst of all, if we drop filepaths, then please drop them completely, either I need more information about which `.hs` file was used as source, or I don't need it at all, so this ` (.hs -> .o)` suffix is just noise to me; not the least because the `-> .o` part carries almost no information for me. If the premise of `-fno-show-source-paths` is that we know how we called GHC and thereby know what is being compiled, showing `(.hs -> .o)` is pointless.\r\n\r\nMorever, `-f(no-)show-source-paths` is a lie/misnomer, as it doesn't only control the *source* path display, but *also* the *output* path display!\r\n\r\nAlso, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work.\r\n\r\nFinally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source-paths where tab-completing my way to the source path is too tedious.\r\n\r\nThis is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer.\r\n\r\nSo, in summary I propose to\r\n\r\n - Make `-fshow-source-paths` the default again\r\n - drop the `(.hs->.o)` suffix in `-fno-show-show-source-paths`\r\n - consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe\r\n - Have `-f(no-)show-source-paths` control the source-path display\r\n - Have `-f(no-)show-output-paths` control the output-path display\r\n - As a compromise, consider `-fshow-source-paths -fno-show-output-paths` becoming the new default.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12691Refine the behaviour of -dno-debug-output and -dtrace-level2019-07-07T18:25:33ZMatthew PickeringRefine the behaviour of -dno-debug-output and -dtrace-levelIt wasn't clear to me what these flags should do and what they should turn off.
From the user guide.
<table><tr><th>`-dno-debug-output`</th>
<td>Suppress any unsolicited debugging output. When GHC has been built with the DEBUG option i...It wasn't clear to me what these flags should do and what they should turn off.
From the user guide.
<table><tr><th>`-dno-debug-output`</th>
<td>Suppress any unsolicited debugging output. When GHC has been built with the DEBUG option it occasionally emits debug output of interest to developers. The extra output can confuse the testing framework and cause bogus test failures, so this flag is provided to turn it off.</td></tr>
<tr><th>`-dtrace-level`</th>
<td>Not present</td></tr></table>
`-dno-debug-output` currently suppresses the output of `-ddump-tc-trace` which is certainly not "unsolicited". It should be used, and is, in `Outputable` to suppress the output of `pprTrace`.
`dtrace-level` is used in a few places but always as if was a boolean flag. I don't really see what the point of it is. The only commit which mentions it is "8cdb98b9909561671ab4e61c90ebb12504478e4d" and I can't find the origin of the flag. I think we should just remove it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Refine the behaviour of -dno-debug-output and -dtrace-level","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It wasn't clear to me what these flags should do and what they should turn off.\r\n\r\nFrom the user guide.\r\n\r\n `-dno-debug-output`:: Suppress any unsolicited debugging output. When GHC has been built with the DEBUG option it occasionally emits debug output of interest to developers. The extra output can confuse the testing framework and cause bogus test failures, so this flag is provided to turn it off.\r\n\r\n `-dtrace-level`:: Not present\r\n\r\n`-dno-debug-output` currently suppresses the output of `-ddump-tc-trace` which is certainly not \"unsolicited\". It should be used, and is, in `Outputable` to suppress the output of `pprTrace`. \r\n\r\n`dtrace-level` is used in a few places but always as if was a boolean flag. I don't really see what the point of it is. The only commit which mentions it is \"8cdb98b9909561671ab4e61c90ebb12504478e4d\" and I can't find the origin of the flag. I think we should just remove it.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12617Make the interface of traceTc and traceRn the same2019-07-07T18:25:50ZMatthew PickeringMake the interface of traceTc and traceRn the sameIt always seemed strange to me that the interfaces for `traceTc` and `traceRn` were different.
```hs
traceTc :: String -> SDoc -> TcM ()
traceRn :: SDoc -> RnM ()
```
I personally prefer using the `traceTc` interface and have to look u...It always seemed strange to me that the interfaces for `traceTc` and `traceRn` were different.
```hs
traceTc :: String -> SDoc -> TcM ()
traceRn :: SDoc -> RnM ()
```
I personally prefer using the `traceTc` interface and have to look up each time which function uses which interface. It seems beneficial but annoying to make `traceRn` have the same interface to improve usability slightly.
Are there any objections if someone was to do this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make the interface of traceTc and traceRn the same","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It always seemed strange to me that the interfaces for `traceTc` and `traceRn` were different. \r\n\r\n{{{#!hs\r\ntraceTc :: String -> SDoc -> TcM ()\r\ntraceRn :: SDoc -> RnM ()\r\n}}}\r\n\r\nI personally prefer using the `traceTc` interface and have to look up each time which function uses which interface. It seems beneficial but annoying to make `traceRn` have the same interface to improve usability slightly.\r\n\r\nAre there any objections if someone was to do this?","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12429Pattern synonym parse error should recommend enabling extension2019-07-07T18:26:39ZagibianskyPattern synonym parse error should recommend enabling extensionCurrently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example:
```hs
module X where
import Data.Text (pattern Y)
x = 3
```
Yields, when compiled on GHC 7....Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example:
```hs
module X where
import Data.Text (pattern Y)
x = 3
```
Yields, when compiled on GHC 7.10,
```
test.hs:3:27: parse error on input "Y"
```
It would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pattern synonym parse error should recommend enabling extension","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["error","messages","pattern","synonym"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example:\r\n\r\n{{{#!hs\r\nmodule X where\r\nimport Data.Text (pattern Y)\r\nx = 3\r\n}}}\r\n\r\nYields, when compiled on GHC 7.10,\r\n{{{\r\ntest.hs:3:27: parse error on input \"Y\"\r\n}}}\r\n\r\nIt would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1ruperthorlickruperthorlickhttps://gitlab.haskell.org/ghc/ghc/-/issues/12382Rename clashing type variables more consistently2019-07-07T18:26:51ZJoachim Breitnermail@joachim-breitner.deRename clashing type variables more consistentlyThis is minor polishing, but polish is nice:
Consider
```
:t (id,id,id)
(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)
```
this looks as if the first `a` is in some way better or more important. What I’d like to see is
```
:t (id,id,id)
...This is minor polishing, but polish is nice:
Consider
```
:t (id,id,id)
(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)
```
this looks as if the first `a` is in some way better or more important. What I’d like to see is
```
:t (id,id,id)
(id,id,id) :: (a1 -> a2, a2 -> a2, a3 -> a3)
```
In other words: If two type variables clash and need to be renamed, then rename both (all) of them.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rename clasing type variables more consistently","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is minor polishing, but polish is nice:\r\n\r\nConsider\r\n{{{\r\n:t (id,id,id)\r\n(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)\r\n}}}\r\nthis looks as if the first `a` is in some way better or more important. What I’d like to see is \r\n{{{\r\n:t (id,id,id)\r\n(id,id,id) :: (a1 -> a2, a2 -> a2, a3 -> a3)\r\n}}}\r\n\r\nIn other words: If two type variables clash and need to be renamed, then rename both (all) of them.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/12379WARN pragma gives warning `warning: [-Wdeprecations]'2019-07-07T18:26:52ZZilin Chenzilin.chen@data61.csiro.auWARN pragma gives warning `warning: [-Wdeprecations]'Example:
```hs
-- Warn.hs
module Warn where
__todo :: String -> a
{-# WARNING __todo "TODO" #-}
__todo msg = error $ "TODO: " ++ msg
```
```hs
-- Main.hs
{- OPTIONS_GHC -Wall #-}
import Warn
inc :: Int -> Int
inc n | n >= 0 = n + ...Example:
```hs
-- Warn.hs
module Warn where
__todo :: String -> a
{-# WARNING __todo "TODO" #-}
__todo msg = error $ "TODO: " ++ msg
```
```hs
-- Main.hs
{- OPTIONS_GHC -Wall #-}
import Warn
inc :: Int -> Int
inc n | n >= 0 = n + 1
inc _ = __todo "what about negatives?"
```
When compile the files (or ghci), I get
```
UseWarn.hs:9:9: warning: [-Wdeprecations]
In the use of ‘__todo’ (imported from Warn): "TODO"
```
Should the flag be `-Wwarnings-deprecations`? And `-Wdeprecations` is not in the user guide, if it is a genuine flag.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | IncorrectWarning |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"WARN pragma gives warning `warning: [-Wdeprecations]'","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Example:\r\n\r\n{{{#!hs\r\n-- Warn.hs\r\n\r\nmodule Warn where\r\n\r\n__todo :: String -> a\r\n{-# WARNING __todo \"TODO\" #-}\r\n__todo msg = error $ \"TODO: \" ++ msg\r\n}}}\r\n\r\n{{{#!hs\r\n-- Main.hs\r\n\r\n{- OPTIONS_GHC -Wall #-}\r\n\r\nimport Warn\r\n\r\ninc :: Int -> Int\r\ninc n | n >= 0 = n + 1\r\ninc _ = __todo \"what about negatives?\"\r\n}}}\r\n\r\nWhen compile the files (or ghci), I get\r\n{{{\r\nUseWarn.hs:9:9: warning: [-Wdeprecations]\r\n In the use of ‘__todo’ (imported from Warn): \"TODO\"\r\n}}}\r\n\r\nShould the flag be `-Wwarnings-deprecations`? And `-Wdeprecations` is not in the user guide, if it is a genuine flag.","type_of_failure":"IncorrectWarning","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12368Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation2019-07-07T18:26:54ZJoachim Breitnermail@joachim-breitner.deDemand Analyzer: Cunnig plan not adhered to with aborting fixpoint interationNot sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.
This is about nested recursion, as in this example
```
f [] = []
f (x:xs) = let g [] = f xs
...Not sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.
This is about nested recursion, as in this example
```
f [] = []
f (x:xs) = let g [] = f xs
g (y:ys) = y+1 : g ys
in g (h x)
```
The “cunning plan” of fixpoint iteration (see Note \[Initialising strictness\]) says that in the first time an inner recursive definition is looked at, its strictness is assumed to be `b` (`botSig`), and from then on, its `idInformation` (presumably from the previous iteration or the outer recursive definition) is used. A flag (`virgin`) in the analysis environment is used to detect that.
The problem is that the fixpoint iteration code in `dmdFix` aborts after more than 10 iterations:
```
loop' n env pairs
| found_fixpoint
= (env', lazy_fv, pairs')
| n >= 10
= (env, lazy_fv, orig_pairs) -- Safe output
```
This means that if the iteration does not terminate, we will “not” attach a strictness signature to the inner binders (`g` in the example above), but rather leave the binders untouched.
Then, in the second iteration of finding a fixpoint for `f`, the `virgin` flag is `False`, and `idStrictness` is used, which in this case will simply be the default, namely `nopSig`.
I could not produce an example where it matters. And it might be that it simply does not matter, so I’m not sure what to do with this information.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ilya, osa1 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ilya","osa1"],"type":"Bug","description":"Not sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.\r\n\r\nThis is about nested recursion, as in this example\r\n{{{\r\n f [] = []\r\n f (x:xs) = let g [] = f xs\r\n g (y:ys) = y+1 : g ys\r\n in g (h x)\r\n}}}\r\nThe “cunning plan” of fixpoint iteration (see Note [Initialising strictness]) says that in the first time an inner recursive definition is looked at, its strictness is assumed to be `b` (`botSig`), and from then on, its `idInformation` (presumably from the previous iteration or the outer recursive definition) is used. A flag (`virgin`) in the analysis environment is used to detect that.\r\n\r\n\r\nThe problem is that the fixpoint iteration code in `dmdFix` aborts after more than 10 iterations:\r\n{{{\r\n loop' n env pairs\r\n | found_fixpoint\r\n = (env', lazy_fv, pairs')\r\n | n >= 10\r\n = (env, lazy_fv, orig_pairs) -- Safe output\r\n}}}\r\nThis means that if the iteration does not terminate, we will “not” attach a strictness signature to the inner binders (`g` in the example above), but rather leave the binders untouched.\r\n\r\nThen, in the second iteration of finding a fixpoint for `f`, the `virgin` flag is `False`, and `idStrictness` is used, which in this case will simply be the default, namely `nopSig`.\r\n\r\nI could not produce an example where it matters. And it might be that it simply does not matter, so I’m not sure what to do with this information.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12055Typechecker panic instead of proper error2019-07-07T18:27:49ZBen GamariTypechecker panic instead of proper errorConsider this modification of the testcase from #12021,
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGU...Consider this modification of the testcase from #12021,
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE TypeInType #-}
import GHC.Base ( Constraint, Type )
import GHC.Exts ( type (~~) )
type Cat k = k -> k -> Type
class Category (p :: Cat k) where
type Ob p :: k -> Constraint
class (Category (Dom f), Category (Cod f)) => Functor (f :: j -> k) where
type Dom f :: Cat j
type Cod f :: Cat k
functor :: forall a b.
Iso Constraint (:-) (:-)
(Ob (Dom f) a) (Ob (Dom f) b)
(Ob (Cod f) (f a)) (Ob (Cod f) (f b))
class (Functor f , Dom f ~ p, Cod f ~ q) =>
Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) | f -> p q
instance (Functor f , Dom f ~ p, Cod f ~ q) =>
Fun (p :: Cat j) (q :: Cat k) (f :: j -> k)
data Nat (p :: Cat j) (q :: Cat k) (f :: j -> k) (g :: j -> k)
type Iso k (c :: Cat k) (d :: Cat k) s t a b =
forall p. (Cod p ~~ Nat d (->)) => p a b -> p s t
data (p :: Constraint) :- (q :: Constraint)
```
With GHC 8.0.1 it fails with a compiler panic,
```
$ ghc Hi.hs -fprint-explicit-kinds
[1 of 1] Compiling Main ( Hi.hs, Hi.o )
Hi.hs:21:1: error:
• Non type-variable argument
in the constraint: Category j (Dom k j f)
(Use FlexibleContexts to permit this)
• In the context: (Category j (Dom k j f), Category k (Cod k j f))
While checking the super-classes of class ‘Functor’
In the class declaration for ‘Functor’
Hi.hs:29:20: error:
• GHC internal error: ‘Dom’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a2yi :-> Type variable ‘j’ = j,
a2yj :-> Type variable ‘p’ = p, a2yk :-> Type variable ‘k’ = k,
a2yl :-> Type variable ‘q’ = q, a2ym :-> Type variable ‘f’ = f,
r2xT :-> ATcTyCon Fun]
• In the first argument of ‘~’, namely ‘Dom f’
In the class declaration for ‘Fun’
```
If one adds the appropriate extensions (`FunctionalDependencies`, `FlexibleInstances`, and `FlexibleContexts`) GHC complains that the program fails to satisfy the coverage condition,
```
Hi.hs:31:10: error:
• Illegal instance declaration for ‘Fun k j p q f’
The coverage condition fails in class ‘Fun’
for functional dependency: ‘f -> p q’
Reason: lhs type ‘f’ does not determine rhs types ‘p’, ‘q’
Un-determined variables: p, q
Using UndecidableInstances might help
• In the instance declaration for
‘Fun (p :: Cat j) (q :: Cat k) (f :: j -> k)’
```8.2.1