GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:03:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15666Dependent type synonym in recursive type family causes GHC to panic2019-07-07T18:03:32ZtydeuDependent type synonym in recursive type family causes GHC to panic# Background
I had written the following code in Haskell (GHC):
```hs
{-# LANGUAGE
NoImplicitPrelude,
TypeInType, PolyKinds, DataKinds,
ScopedTypeVariables,
TypeFamilies,
UndecidableInstances
#-}
import Data.Kind(Type)
dat...# Background
I had written the following code in Haskell (GHC):
```hs
{-# LANGUAGE
NoImplicitPrelude,
TypeInType, PolyKinds, DataKinds,
ScopedTypeVariables,
TypeFamilies,
UndecidableInstances
#-}
import Data.Kind(Type)
data PolyType k (t :: k)
type Wrap (t :: k) = PolyType k t
type Unwrap pt = (GetType pt :: GetKind pt)
type family GetKind (pt :: Type) :: Type where
GetKind (PolyType k t) = k
type family GetType (pt :: Type) :: k where
GetType (PolyType k t) = t
```
The intention of this code is to allow me to wrap a type of an arbitrary kind
into a type (namely `PolyType`) of a single kind (namely `Type`) and then
reverse the process (i.e. unwrap it) later.
# Problem
I wanted to define a function that would recursively operate on a composite type like so:
```hs
data Composite :: a -> b -> Type
type family RecursiveWrap expr where
RecursiveWrap (Composite a b) =
Wrap (Composite (Unwrap (RecursiveWrap a)) (Unwrap (RecursiveWrap b)))
RecursiveWrap x = Wrap x
```
However, the above definition causes GHC to panic:
```
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-mingw32):
cyclic evaluation in fixIO
```
# Ideas
If we inline the the `Unwrap` synoynm into the defintion of the type family
above like so:
```hs
type family RecursiveWrap expr where
RecursiveWrap (Composite a b) =
Wrap (Composite
(GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a))
(GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a))
)
RecursiveWrap x = Wrap x
```
GHC instead simply produces an error:
```
* Type constructor `RecursiveWrap' cannot be used here
(it is defined and used in the same recursive group)
* In the first argument of `GetKind', namely `(RecursiveWrap a)'
In the kind `GetKind (RecursiveWrap a)'
In the first argument of `Composite', namely
`(GetType (RecursiveWrap a) :: GetKind (RecursiveWrap a))'
```
As such, I suspect this has to do with the recursive type family appearing in
the kind signature when the `Unwrap` type synonym is expanded.
However, it strikes me as odd that even the above code errors. Since with the
`UndecidableInstances` extension turned on, I think that I should be able to
write recursive type families like the above. Especially given that the above
family would not loop indefinitely and thus be reducible.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15603ref6 example from StaticPointers documentation doesn't type check2021-11-25T17:04:14ZMatthew Pickeringref6 example from StaticPointers documentation doesn't type checkThe [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers) for `StaticPointers` contains the following example.
```
ref6 y = let x = 1 in st...The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers) for `StaticPointers` contains the following example.
```
ref6 y = let x = 1 in static x
```
but this doesn't get accepted by the type checker.
```
sp.hs:27:23: error:
• ‘x’ is used in a static form but it is not closed because it
has a non-closed type because it contains the
type variables: ‘p_a7KP’
• In the expression: static x
In the expression: let x = 1 in static x
In an equation for ‘ref6’: ref6 y = let x = 1 in static x
|
27 | ref6 y = let x = 1 in static x
| ^^^^^^^
```
I tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ref6 example from StaticPointers documentation doesn't type check","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers documentation] for `StaticPointers` contains the following example.\r\n\r\n{{{\r\nref6 y = let x = 1 in static x\r\n}}}\r\n\r\nbut this doesn't get accepted by the type checker.\r\n\r\n{{{\r\nsp.hs:27:23: error:\r\n • ‘x’ is used in a static form but it is not closed because it\r\n has a non-closed type because it contains the\r\n type variables: ‘p_a7KP’\r\n • In the expression: static x\r\n In the expression: let x = 1 in static x\r\n In an equation for ‘ref6’: ref6 y = let x = 1 in static x\r\n |\r\n27 | ref6 y = let x = 1 in static x\r\n | ^^^^^^^\r\n}}}\r\n\r\nI tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15563Typo in the documentation for Numeric.Natural.2019-07-07T18:04:07ZAndrés Sicard-RamírezTypo in the documentation for Numeric.Natural.The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html) for `Numeric.Natural` says
```
>>> 2^20 :: Natural
1267650600228229401496703205376
```
Please replace the `20` by `100...The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html) for `Numeric.Natural` says
```
>>> 2^20 :: Natural
1267650600228229401496703205376
```
Please replace the `20` by `100`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in the documentation for Numeric.Natural.","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0/Numeric-Natural.html documentation] for `Numeric.Natural` says\r\n\r\n{{{\r\n>>> 2^20 :: Natural\r\n1267650600228229401496703205376\r\n}}}\r\n\r\nPlease replace the `20` by `100`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15540GHCi does not follow the XDG Base Directory Specification2021-04-01T11:23:17ZRichard SzibeleGHCi does not follow the XDG Base Directory SpecificationHello,
GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.
It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if ...Hello,
GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.
It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set.
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 8.0.2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does not follow the XDG Base Directory Specification","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nGHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.\r\n\r\nIt creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set.\r\n\r\n$ ghci --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.2","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15528Match is missing a Data instance2019-07-07T18:04:18ZMatthew PickeringMatch is missing a Data instanceIf I try to use `showAstData` on a `Match` then GHC complains that there is no
Data instance.
```
No instance for (Data (Expr.Match p (Expr.LHsExpr p)))
```
It seems that all the constituent parts of `Match` have a `Data` instance so `...If I try to use `showAstData` on a `Match` then GHC complains that there is no
Data instance.
```
No instance for (Data (Expr.Match p (Expr.LHsExpr p)))
```
It seems that all the constituent parts of `Match` have a `Data` instance so `Match` should as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"Match is missing a Data instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"If I try to use `showAstData` on a `Match` then GHC complains that there is no\r\nData instance.\r\n\r\n{{{\r\nNo instance for (Data (Expr.Match p (Expr.LHsExpr p)))\r\n}}}\r\n\r\nIt seems that all the constituent parts of `Match` have a `Data` instance so `Match` should as well.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15228Remove use of showSDocUnsafe in extending_ghc.rst2019-07-07T18:13:42ZMatthew PickeringRemove use of showSDocUnsafe in extending_ghc.rstThere are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all wit...There are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all with `showSDoc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"Remove use of showSDocUnsafe in extending_ghc.rst","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all with `showSDoc`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15180Make Control.Exception.throw levity polymorphic2019-07-07T18:13:54ZAndrew MartinMake Control.Exception.throw levity polymorphicThe `error` function has a levity-polymorphic type. I propose that the same be done for `throw`. I just encountered a situation where I needed this, and instead of calling `throw x`, I had to call `raise# (toException x)` because `throw`...The `error` function has a levity-polymorphic type. I propose that the same be done for `throw`. I just encountered a situation where I needed this, and instead of calling `throw x`, I had to call `raise# (toException x)` because `throw` is unnecessarily restrictive.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"Make Control.Exception.throw levity polymorphic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["LevityPolymorphism"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The `error` function has a levity-polymorphic type. I propose that the same be done for `throw`. I just encountered a situation where I needed this, and instead of calling `throw x`, I had to call `raise# (toException x)` because `throw` is unnecessarily restrictive.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15134enumFrom... aren't really documented.2019-07-07T18:14:07ZDavid FeuerenumFrom... aren't really documented.The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------...The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"enumFrom... aren't really documented.","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/15123mg_arg_tys in MatchGroup should be a PostTc field2019-07-07T18:14:10ZMatthew Pickeringmg_arg_tys in MatchGroup should be a PostTc fieldIt appears that `mg_arg_tys` is only populated after typechecking but the type does not indicate this.
Instead of
```
mg_arg_tys :: [PostTc p Type]
```
the type should be
```
mg_arg_tys :: PostTc p [Type]
```
All that needs doing is...It appears that `mg_arg_tys` is only populated after typechecking but the type does not indicate this.
Instead of
```
mg_arg_tys :: [PostTc p Type]
```
the type should be
```
mg_arg_tys :: PostTc p [Type]
```
All that needs doing is modifying this type in compiler/HsSyn/HsExpr.hs and then fixing the resulting compiler errors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"mg_arg_tys in MatchGroup should be a PostTc field","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It appears that `mg_arg_tys` is only populated after typechecking but the type does not indicate this. \r\n\r\nInstead of\r\n\r\n{{{\r\nmg_arg_tys :: [PostTc p Type]\r\n}}}\r\n\r\nthe type should be\r\n\r\n{{{\r\nmg_arg_tys :: PostTc p [Type]\r\n}}}\r\n\r\nAll that needs doing is modifying this type in compiler/HsSyn/HsExpr.hs and then fixing the resulting compiler errors. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15088Test T3234 is fragile2019-07-07T18:14:18ZMatthew PickeringTest T3234 is fragileThe test for T3234 is quite fragile as it compares the whole output of `-ddump-simpl-stats`. #3234 should be consulted and then the test modified so that only the relevant part is extracted and compared.
<details><summary>Trac metadata<...The test for T3234 is quite fragile as it compares the whole output of `-ddump-simpl-stats`. #3234 should be consulted and then the test modified so that only the relevant part is extracted and compared.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"Test T3234 is fragile","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The test for T3234 is quite fragile as it compares the whole output of `-ddump-simpl-stats`. #3234 should be consulted and then the test modified so that only the relevant part is extracted and compared. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15055ghci - improve error on hidden package2019-07-07T18:14:31ZAlexander Kjeldaasghci - improve error on hidden packageA user boldly types:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
```
The above error ...A user boldly types:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
```
The above error message is rather useless for a newcomer to ghci. After lots of googling, the user figures that `:set -v -package package-foo` seems to solve it.
The original error should be:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
Try :set -package package-foo to make it visible.
```
Or something like that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci - improve error on hidden package","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A user boldly types:\r\n\r\n{{{\r\n> import Data.Foo\r\n\r\n<no location info>: error:\r\n Could not find module ‘Data.Foo’\r\n It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.\r\n}}}\r\n\r\nThe above error message is rather useless for a newcomer to ghci. After lots of googling, the user figures that `:set -v -package package-foo` seems to solve it.\r\n\r\nThe original error should be:\r\n\r\n{{{\r\n> import Data.Foo\r\n\r\n<no location info>: error:\r\n Could not find module ‘Data.Foo’\r\n It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.\r\nTry :set -package package-foo to make it visible.\r\n}}}\r\n\r\nOr something like that.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Chaitanya Koparkarckoparkar@gmail.comChaitanya Koparkarckoparkar@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14886Add max GC pause to GHC.Stats/-t --machine-readable2019-07-07T18:15:11ZMateusz KowalczykAdd max GC pause to GHC.Stats/-t --machine-readableSometimes we're interested in latency of our programs. Often the upper highest percentiles are by garbage collector pauses due to stop-the-world implementation.
It seems that currently the only way to see the highest pause is to use the...Sometimes we're interested in latency of our programs. Often the upper highest percentiles are by garbage collector pauses due to stop-the-world implementation.
It seems that currently the only way to see the highest pause is to use the `-s` flag or alternatively `-S`. This is problematic in two scenarios:
1. You don't have a human at the monitor parsing the `-s` output.
1. You are unable to get the maximum pause statistic programmatically inside the program itself.
We do have `-t -machine-readable` which is nearly what I'd want but missing the actual pause information. Either that should include all the extra info from `-s` or `-s` should have machine-readable output format too.
There is the `-S` option which will print garbage collections as they happen. We could parse and manually track the highest pause time but it requires an external process and a parser. If you want to get that information back into the process then you have to do even more work.
`GHC.Stats` is of no help. It does not track or expose pause values. Even the "last GC info" APIs don't provide this (and they are not a solution anyway as you can only get info on last GC).
I would therefore like to request two similar features:
- Add relevant information from `-s` to `-t` machine readable output or add machine readable format option to `-s`.
- Add maximum pause information to GHC.Stats interface.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add max GC pause to GHC.Stats/-t --machine-readable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Sometimes we're interested in latency of our programs. Often the upper highest percentiles are by garbage collector pauses due to stop-the-world implementation.\r\n\r\nIt seems that currently the only way to see the highest pause is to use the {{{-s}}} flag or alternatively {{{-S}}}. This is problematic in two scenarios:\r\n\r\n1. You don't have a human at the monitor parsing the {{{-s}}} output.\r\n2. You are unable to get the maximum pause statistic programmatically inside the program itself.\r\n\r\nWe do have {{{-t -machine-readable}}} which is nearly what I'd want but missing the actual pause information. Either that should include all the extra info from {{{-s}}} or {{{-s}}} should have machine-readable output format too.\r\n\r\nThere is the {{{-S}}} option which will print garbage collections as they happen. We could parse and manually track the highest pause time but it requires an external process and a parser. If you want to get that information back into the process then you have to do even more work.\r\n\r\n{{{GHC.Stats}}} is of no help. It does not track or expose pause values. Even the \"last GC info\" APIs don't provide this (and they are not a solution anyway as you can only get info on last GC).\r\n\r\nI would therefore like to request two similar features:\r\n\r\n* Add relevant information from {{{-s}}} to {{{-t}}} machine readable output or add machine readable format option to {{{-s}}}.\r\n* Add maximum pause information to GHC.Stats interface.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14872Hex Literals in GHC Core2019-07-07T18:15:14ZAndrew MartinHex Literals in GHC CoreSometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:
```
detectNull :: Word...Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:
```
detectNull :: Word -> Word
detectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero
detectArtifact :: Word -> Word -> Word
detectArtifact x artifact = detectNull (applyArtifact x artifact)
applyArtifact :: Word -> Word -> Word
applyArtifact = xor
repeatHexZeroOne :: Word
repeatHexZeroOne = div maxBound 255
repeatHexEightZero :: Word
repeatHexEightZero = 128 * (div maxBound 255 :: Word)
```
Once everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hex Literals in GHC Core","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:\r\n\r\n{{{\r\ndetectNull :: Word -> Word\r\ndetectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero\r\n\r\ndetectArtifact :: Word -> Word -> Word\r\ndetectArtifact x artifact = detectNull (applyArtifact x artifact)\r\n\r\napplyArtifact :: Word -> Word -> Word\r\napplyArtifact = xor\r\n\r\nrepeatHexZeroOne :: Word\r\nrepeatHexZeroOne = div maxBound 255\r\n\r\nrepeatHexEightZero :: Word\r\nrepeatHexEightZero = 128 * (div maxBound 255 :: Word)\r\n}}}\r\n\r\nOnce everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Andrew MartinAndrew Martinhttps://gitlab.haskell.org/ghc/ghc/-/issues/14761Incorrect diagnostic for UNPACK/missing strictness2019-07-07T18:15:44ZdminuosoIncorrect diagnostic for UNPACK/missing strictness```hs
data A = A { a :: {-# UNPACK #-} Maybe Int}
```
```
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Temp.hs:1:19: error:
• Unexpected strictness annotation: {-# UNPACK #-}Maybe
• In the type ‘{-# UNPACK #-}Maybe I...```hs
data A = A { a :: {-# UNPACK #-} Maybe Int}
```
```
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Temp.hs:1:19: error:
• Unexpected strictness annotation: {-# UNPACK #-}Maybe
• In the type ‘{-# UNPACK #-}Maybe Int’
In the definition of data constructor ‘A’
In the data declaration for ‘A’
|
1 | data A = A { a :: {-# UNPACK #-} Maybe Int}
|
```
The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite.
A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect diagnostic for UNPACK/missing strictness","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\ndata A = A { a :: {-# UNPACK #-} Maybe Int}\r\n}}}\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( Temp.hs, Temp.o )\r\n\r\nTemp.hs:1:19: error:\r\n • Unexpected strictness annotation: {-# UNPACK #-}Maybe\r\n • In the type ‘{-# UNPACK #-}Maybe Int’\r\n In the definition of data constructor ‘A’\r\n In the data declaration for ‘A’\r\n |\r\n1 | data A = A { a :: {-# UNPACK #-} Maybe Int}\r\n |\r\n}}}\r\n\r\nThe diagnostic is incorrect because it complains about an \"unexpected strictness annotation\" although the error is the opposite.\r\n\r\nA quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14544doCorePass has at least one missing case2019-07-07T18:16:34ZMatthew PickeringdoCorePass has at least one missing caseThere is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or ...There is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"doCorePass has at least one missing case","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14343bad pretty-printing of types with promoted data types2022-11-20T11:46:11Zlspitznerbad pretty-printing of types with promoted data types```
> :set -XDataKinds
> :set -XPolyKinds
> data Proxy k = Proxy
> _ :: Proxy '[ 'True ]
error:
Found hole: _ :: Proxy '['True]
> _ :: Proxy '['True]
error:
Invalid type signature: _ :: ...
Should be of form <variab...```
> :set -XDataKinds
> :set -XPolyKinds
> data Proxy k = Proxy
> _ :: Proxy '[ 'True ]
error:
Found hole: _ :: Proxy '['True]
> _ :: Proxy '['True]
error:
Invalid type signature: _ :: ...
Should be of form <variable> :: <type>
```
Alternatively, this could be attributed to the parser/lexer doing an insufficient job there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bad pretty-printing of types with promoted data types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> :set -XDataKinds\r\n> :set -XPolyKinds\r\n> data Proxy k = Proxy\r\n> _ :: Proxy '[ 'True ]\r\nerror:\r\n Found hole: _ :: Proxy '['True]\r\n> _ :: Proxy '['True]\r\nerror:\r\n Invalid type signature: _ :: ...\r\n Should be of form <variable> :: <type>\r\n}}}\r\n\r\nAlternatively, this could be attributed to the parser/lexer doing an insufficient job there.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Andreas HerrmannAndreas Herrmannhttps://gitlab.haskell.org/ghc/ghc/-/issues/13896Use response file to invoke hsc2hs2019-07-07T18:19:36ZBen GamariUse response file to invoke hsc2hsWe already use response files when invoking Haddock due to Windows command line length limitations. It [seems](https://github.com/haskell/cabal/issues/3122#issuecomment-311489312) that we also need to do the same with `hsc2hs`.
<details...We already use response files when invoking Haddock due to Windows command line length limitations. It [seems](https://github.com/haskell/cabal/issues/3122#issuecomment-311489312) that we also need to do the same with `hsc2hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use response file to invoke hsc2hs","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We already use response files when invoking Haddock due to Windows command line length limitations. It [[https://github.com/haskell/cabal/issues/3122#issuecomment-311489312|seems]] that we also need to do the same with `hsc2hs`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Chaitanya Koparkarckoparkar@gmail.comChaitanya Koparkarckoparkar@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/13892Add some benchmarks to nofib from Andras Kovac's Eff benchmarks2019-07-07T18:19:37ZMatthew PickeringAdd some benchmarks to nofib from Andras Kovac's Eff benchmarksAndras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the...Andras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the examples already in there.
https://github.com/AndrasKovacs/misc-stuff/tree/master/haskell/Eff
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michalt |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add some benchmarks to nofib from Andras Kovac's Eff benchmarks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["michalt"],"type":"Task","description":"Andras has a bunch of different benchmarks for different effect handler code which stresses the optimiser in interesting ways. It would be good to add some of these benchmarks to nofib as they are likely quite different from a lot of the examples already in there. \r\n\r\nhttps://github.com/AndrasKovacs/misc-stuff/tree/master/haskell/Eff","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/13833Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleIns...2019-07-07T18:19:54ZHjulleInstances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances.Yes I know, `0` and `"B"` are not technically type constructors, but it's as close as you can get for the kinds Nat and Symbol.
Test cases:
```hs
{-# LANGUAGE DataKinds, KindSignatures #-}
import GHC.TypeLits (Nat, Symbol)
class A (n...Yes I know, `0` and `"B"` are not technically type constructors, but it's as close as you can get for the kinds Nat and Symbol.
Test cases:
```hs
{-# LANGUAGE DataKinds, KindSignatures #-}
import GHC.TypeLits (Nat, Symbol)
class A (n::Nat)
instance A 0
class B (s::Symbol)
instance B "B"
```
Result:
```
A.hs:6:10: error:
• Illegal instance declaration for ‘A 0’
(All instance types must be of the form (T a1 ... an)
where a1 ... an are *distinct type variables*,
and each type variable appears at most once in the instance head.
Use FlexibleInstances if you want to disable this.)
• In the instance declaration for ‘A 0’
A.hs:9:10: error:
• Illegal instance declaration for ‘B "B"’
(All instance types must be of the form (T a1 ... an)
where a1 ... an are *distinct type variables*,
and each type variable appears at most once in the instance head.
Use FlexibleInstances if you want to disable this.)
• In the instance declaration for ‘B "B"’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| 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":"Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances.","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":"Yes I know, `0` and `\"B\"` are not technically type constructors, but it's as close as you can get for the kinds Nat and Symbol.\r\n\r\nTest cases:\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds, KindSignatures #-}\r\n\r\nimport GHC.TypeLits (Nat, Symbol)\r\n\r\nclass A (n::Nat)\r\ninstance A 0\r\n\r\nclass B (s::Symbol)\r\ninstance B \"B\"\r\n\r\n}}}\r\nResult:\r\n{{{\r\nA.hs:6:10: error:\r\n • Illegal instance declaration for ‘A 0’\r\n (All instance types must be of the form (T a1 ... an)\r\n where a1 ... an are *distinct type variables*,\r\n and each type variable appears at most once in the instance head.\r\n Use FlexibleInstances if you want to disable this.)\r\n • In the instance declaration for ‘A 0’\r\n\r\nA.hs:9:10: error:\r\n • Illegal instance declaration for ‘B \"B\"’\r\n (All instance types must be of the form (T a1 ... an)\r\n where a1 ... an are *distinct type variables*,\r\n and each type variable appears at most once in the instance head.\r\n Use FlexibleInstances if you want to disable this.)\r\n • In the instance declaration for ‘B \"B\"’\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/13776-ddump-splices produces unnecessarily qualified names for tuple and list types2019-07-07T18:20:07ZRyan Scott-ddump-splices produces unnecessarily qualified names for tuple and list typesIf you compile this:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Language.Haskell.TH
f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int)
f = (1,2)
g :: $(conT ''[] `appT` conT ...If you compile this:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Language.Haskell.TH
f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int)
f = (1,2)
g :: $(conT ''[] `appT` conT ''Int)
g = []
```
You'll get some unsavory output:
```
Bug.hs:10:8-34: Splicing type
conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int
Bug.hs:7:8-53: Splicing type
conT ''(,) `appT` conT ''Int `appT` conT ''Int
======>
GHC.Tuple.(,) Int Int
```
It's unsavory because if you actually try to use the spliced output in Haskell code:
```hs
module Bug2 where
f :: GHC.Tuple.(,) Int Int
f = (1,2)
g :: GHC.Types.[] Int
g = []
```
Then it won't parse.
Expressions have the same problem:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug3 where
import Language.Haskell.TH
f :: (Int, Int)
f = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1))
g :: [Int]
g = $(conE '[])
```
```
Bug3.hs:8:7-65: Splicing expression
conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)
======>
(GHC.Tuple.(,) 1) 1
Bug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[]
```
And patterns:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug4 where
import Language.Haskell.TH
f :: (Int, Int) -> ()
f $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = ()
g :: [Int] -> ()
g $(conP '[] []) = ()
```
```
Bug4.hs:8:5-52: Splicing pattern
conP '(,) [litP (integerL 1), litP (integerL 1)]
======>
GHC.Tuple.(,) 1 1
Bug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-ddump-splices produces unnecessarily qualified names for tuple and list types","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you compile this:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\nimport Language.Haskell.TH\r\n\r\nf :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int)\r\nf = (1,2)\r\n\r\ng :: $(conT ''[] `appT` conT ''Int)\r\ng = []\r\n}}}\r\n\r\nYou'll get some unsavory output:\r\n\r\n{{{\r\nBug.hs:10:8-34: Splicing type\r\n conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int\r\nBug.hs:7:8-53: Splicing type\r\n conT ''(,) `appT` conT ''Int `appT` conT ''Int\r\n ======>\r\n GHC.Tuple.(,) Int Int\r\n}}}\r\n\r\nIt's unsavory because if you actually try to use the spliced output in Haskell code:\r\n\r\n{{{#!hs\r\nmodule Bug2 where\r\n\r\nf :: GHC.Tuple.(,) Int Int\r\nf = (1,2)\r\n\r\ng :: GHC.Types.[] Int\r\ng = []\r\n}}}\r\n\r\nThen it won't parse.\r\n\r\nExpressions have the same problem:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug3 where\r\n\r\nimport Language.Haskell.TH\r\n\r\nf :: (Int, Int)\r\nf = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1))\r\n\r\ng :: [Int]\r\ng = $(conE '[])\r\n}}}\r\n\r\n{{{\r\nBug3.hs:8:7-65: Splicing expression\r\n conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)\r\n ======>\r\n (GHC.Tuple.(,) 1) 1\r\nBug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[]\r\n}}}\r\n\r\nAnd patterns:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug4 where\r\n\r\nimport Language.Haskell.TH\r\n\r\nf :: (Int, Int) -> ()\r\nf $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = ()\r\n\r\ng :: [Int] -> ()\r\ng $(conP '[] []) = ()\r\n}}}\r\n\r\n{{{\r\nBug4.hs:8:5-52: Splicing pattern\r\n conP '(,) [litP (integerL 1), litP (integerL 1)]\r\n ======>\r\n GHC.Tuple.(,) 1 1\r\nBug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1mrkgnaomrkgnao