GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:26:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12549Panic on ":t datatypeName"2019-07-07T18:26:09ZjohnleoPanic on ":t datatypeName"Reproduction:
```
GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/leo/.ghci
Prelude> :m + GHC.Generics
:m + GHC.Generics
Prelude GHC.Generics> :t datatypeName
:t datatypeName
gh...Reproduction:
```
GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/leo/.ghci
Prelude> :m + GHC.Generics
:m + GHC.Generics
Prelude GHC.Generics> :t datatypeName
:t datatypeName
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160826 for x86_64-apple-darwin):
ASSERT failed!
CallStack (from HasCallStack):
assertPprPanic, called at compiler/types/TyCoRep.hs:2094:44 in ghc:TyCoRep
checkValidSubst, called at compiler/types/TyCoRep.hs:2122:17 in ghc:TyCoRep
substTy, called at compiler/typecheck/TcMType.hs:793:24 in ghc:TcMType
in_scope InScope {k1_a1X8}
tenv [a1X0 :-> k1_a1X8[tau:3]]
cenv []
tys [k_a1X4[tau:3] → (k1_a1X0 → *) → k1_a1X0 → ★]
cos []
needInScope [a1X4 :-> k_a1X4[tau:3]]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.2.1johnleojohnleohttps://gitlab.haskell.org/ghc/ghc/-/issues/12548Exported pattern synonyms does not mark top-level bindings in RHS as used2019-07-07T18:26:09ZpkmxExported pattern synonyms does not mark top-level bindings in RHS as used```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo (pattern P) where
x :: Int
x = 0
pattern P :: Int
pattern P <- _ where
P = x
```
gives:
```
Foo.hs:6:1: warning: [-Wunused-top-binds]
Defined but not used: ‘x’
```
<deta...```hs
{-# LANGUAGE PatternSynonyms #-}
module Foo (pattern P) where
x :: Int
x = 0
pattern P :: Int
pattern P <- _ where
P = x
```
gives:
```
Foo.hs:6:1: warning: [-Wunused-top-binds]
Defined but not used: ‘x’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Exported pattern synonyms does not mark top-level bindings in RHS as used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["PatternSynonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\nmodule Foo (pattern P) where\r\n\r\nx :: Int\r\nx = 0\r\n\r\npattern P :: Int\r\npattern P <- _ where\r\n P = x\r\n}}}\r\n\r\ngives:\r\n\r\n{{{\r\nFoo.hs:6:1: warning: [-Wunused-top-binds]\r\n Defined but not used: ‘x’\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12546GeneralizedNewtypeDeriving produces error messages with incorrect kind signat...2019-07-07T18:26:09ZAlexis KingGeneralizedNewtypeDeriving produces error messages with incorrect kind signaturesGiven the following program:
```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleInstances #-}
import Control.Monad.Reader
newtype AppM a = AppM (ReaderT Int IO a)
deriving (Functor, Applicative, Monad, Monad...Given the following program:
```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE FlexibleInstances #-}
import Control.Monad.Reader
newtype AppM a = AppM (ReaderT Int IO a)
deriving (Functor, Applicative, Monad, MonadReader)
```
The `MonadReader` deriving declaration should be `MonadReader Int`. GHC produces the following error message:
```
• Expecting one more argument to ‘MonadReader’
Expected kind ‘* -> Constraint’,
but ‘MonadReader’ has kind ‘* -> (* -> *) -> Constraint’
• In the newtype declaration for ‘AppM’
```
This error message is confusing to me. The kind of `MonadReader` is `* -> (* -> *) -> Constraint`, as the error message states, which makes sense. However, the error message states that it expects kind `* -> Constraint`, despite the fact that `MonadReader Int` is actually of kind `(* -> *) -> Constraint`.
,,(This description is adapted from [this Stack Overflow question](http://stackoverflow.com/q/39172590/465378).),,8.0.2mniipmniiphttps://gitlab.haskell.org/ghc/ghc/-/issues/12545Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists ...2019-07-07T18:26:09Zmikhail.vorozhtsovCompilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:
```
$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rgh...After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:
```
$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>>
real 0m20.160s
user 0m19.937s
sys 0m0.197s
$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>>
real 2m10.195s
user 2m9.773s
sys 0m0.400s
```
Both versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well.
It is worth mentioning that turning off optimization makes the problem disappear:
```
$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs
<<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>>
real 0m3.593s
user 0m3.507s
sys 0m0.073s
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine:\r\n\r\n{{{\r\n$ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>>\r\n\r\nreal\t0m20.160s\r\nuser\t0m19.937s\r\nsys\t0m0.197s\r\n$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>>\r\n\r\nreal\t2m10.195s\r\nuser\t2m9.773s\r\nsys\t0m0.400s\r\n}}}\r\n\r\nBoth versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well.\r\n\r\nIt is worth mentioning that turning off optimization makes the problem disappear:\r\n{{{\r\n$ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs \r\n<<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>>\r\n\r\nreal\t0m3.593s\r\nuser\t0m3.507s\r\nsys\t0m0.073s\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12544Improved warning for redundant-constraints2019-07-07T18:26:10ZEric CrockettImproved warning for redundant-constraintsCurrently,
```
foo :: (Num a, Integral a) => a -> a
foo = id
```
produces the warning
```
Main.hs:1:1: warning: [-Wredundant-constraints]
• Redundant constraints: (Num a, Integral a)
• In the type signature for:
foo...Currently,
```
foo :: (Num a, Integral a) => a -> a
foo = id
```
produces the warning
```
Main.hs:1:1: warning: [-Wredundant-constraints]
• Redundant constraints: (Num a, Integral a)
• In the type signature for:
foo :: (Num a, Integral a) => a -> a
```
Since GHC can detect there is a redundancy, it would be nice it also told me which constraint was redundant. In #9939, I suggested that the warning include something to the effect of `(Num a) is implied by (Integral a)`. Lets make this as easy for the user as possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"Improved warning for redundant-constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, \r\n\r\n{{{\r\nfoo :: (Num a, Integral a) => a -> a\r\nfoo = id\r\n}}}\r\n\r\nproduces the warning\r\n\r\n{{{\r\nMain.hs:1:1: warning: [-Wredundant-constraints]\r\n • Redundant constraints: (Num a, Integral a)\r\n • In the type signature for:\r\n foo :: (Num a, Integral a) => a -> a\r\n}}}\r\n\r\nSince GHC can detect there is a redundancy, it would be nice it also told me which constraint was redundant. In #9939, I suggested that the warning include something to the effect of `(Num a) is implied by (Integral a)`. Lets make this as easy for the user as possible.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12539Possible typo causes Stack and Cabal installs to fail2019-07-07T18:26:10ZConorIAPossible typo causes Stack and Cabal installs to failHi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc.
However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC.
...Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc.
However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC.
The gist of the error thrown when using wither Cabal or Stack is:
```
<no location info>:
Warning: Couldn't figure out linker information!
Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc.
gcc: error: unrecognized command line option '-nopie'; did you mean '-no-pie'?
)
```
I am not sure where the error is, as I am really a non-expert. But the gcc linking option is "-no-pie", so if there is indeed an option "-nopie" being passed, it seems like it is a typo.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Possible typo causes Stack and Cabal installs to fail","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc. \r\n\r\nHowever, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC. \r\n\r\nThe gist of the error thrown when using wither Cabal or Stack is: \r\n\r\n{{{\r\n<no location info>:\r\nWarning: Couldn't figure out linker information!\r\nMake sure you're using GNU ld, GNU gold or the built in OS X linker, etc.\r\ngcc: error: unrecognized command line option '-nopie'; did you mean '-no-pie'?\r\n)\r\n}}}\r\n\r\nI am not sure where the error is, as I am really a non-expert. But the gcc linking option is \"-no-pie\", so if there is indeed an option \"-nopie\" being passed, it seems like it is a typo. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12538Incorrect usage of overlapping instances and data families sends GHC into loop2019-07-07T18:26:11ZpkmxIncorrect usage of overlapping instances and data families sends GHC into loopSorry for the lack of descriptive title as I can't nail down the source of the bug. This is the minimal example to trigger the loop:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{...Sorry for the lack of descriptive title as I can't nail down the source of the bug. This is the minimal example to trigger the loop:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module Main where
data Tagged t a = Tagged a
type family Tag a where
Tag (Tagged t a) = Tagged t a
Tag a = Tagged Int a
class (r ~ Tag a) => TagImpl a r | a -> r where
tag :: a -> r
instance {-# OVERLAPPING #-} (r ~ Tag (Tagged t a)) => TagImpl (Tagged t a) r where
tag = id
#ifdef WRONG
instance {-# OVERLAPPING #-} (r ~ Tagged t a, r ~ Tag a) => TagImpl a r where
#else
instance {-# OVERLAPPING #-} (r ~ Tagged Int a, r ~ Tag a) => TagImpl a r where
#endif
tag = Tagged @Int
data family DF x
data instance DF (Tagged t a) = DF (Tagged t a)
class ToDF a b | a -> b where
df :: a -> b
#ifdef WRONG
instance (TagImpl a a', b ~ DF a') => ToDF a b where
#else
instance (TagImpl a (Tagged t a'), b ~ DF (Tagged t a')) => ToDF a b where
#endif
df = DF . tag
main :: IO ()
main = pure ()
```
When compiled with `-DWRONG`, it causes GHC (both 8.0.1 and HEAD\@20160823) to loop:
```
$ ghc --version && ghc -fno-code Main.hs -DWRONG
The Glorious Glasgow Haskell Compilation System, version 8.1.20160823
[1 of 1] Compiling Main ( Main.hs, nothing )
(loops indefinitely...)
```https://gitlab.haskell.org/ghc/ghc/-/issues/12537Parallel cabal builds Segmentation Fault on PowerPC 64-bit2019-07-07T18:26:11ZmichelmnoParallel cabal builds Segmentation Fault on PowerPC 64-bitas detailed in attached log below the initial failure is a reported Segmentation Fault
and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith
<details><summary>Trac metadata</summary>
| Trac field ...as detailed in attached log below the initial failure is a reported Segmentation Fault
and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-openGL build Segmentation Fault for openSUSE ppc64le","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"as detailed in attached log below the initial failure is a reported Segmentation Fault\r\nand if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12536Clarify commentary surrounding unboxed tuples and kind invariant2019-07-07T18:26:11ZBen GamariClarify commentary surrounding unboxed tuples and kind invariant[ticket:12115\#comment:121013](https://gitlab.haskell.org//ghc/ghc/issues/12115#note_121013) notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?
<details><summary>Trac metadat...[ticket:12115\#comment:121013](https://gitlab.haskell.org//ghc/ghc/issues/12115#note_121013) notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Clarify commentary surrounding unboxed tuples and kind invariant","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ticket:12115#comment:8 notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look?","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/12534GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects2019-07-07T18:26:11ZRyan ScottGHC 8.0 accepts recursive kind signature that GHC 7.10 rejectsGHC 7.10 rejects this datatype:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
```
```
$ /opt/ghc/7.10.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5...GHC 7.10 rejects this datatype:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
```
```
$ /opt/ghc/7.10.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:1:
Kind variable also used as type variable: ‘a’
In the data type declaration for ‘T’
```
But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`:
```hs
data T a (a :: a)
```
Results in this error:
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:8: error:
Conflicting definitions for ‘a’
Bound at: Bug.hs:5:8
Bug.hs:5:11
Bug.hs:5:16: error:
Type variable ‘a’ used in a kind.
Did you mean to use TypeInType?
the data type declaration for ‘T’
```
But with this modification:
```hs
data T (a :: a) a
```
You won't get an error message about `a` being used as both a kind and type:
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:5:9: error:
Conflicting definitions for ‘a’
Bound at: Bug.hs:5:9
Bug.hs:5:17
```
To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
data T (a :: a)
class C x
instance C (T (a :: a))
```
```
$ /opt/ghc/8.0.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:16: error:
Variable ‘a’ used as both a kind and a type
Did you intend to use TypeInType?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 7.10 rejects this datatype:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\ndata T (a :: a)\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/7.10.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:1:\r\n Kind variable also used as type variable: ‘a’\r\n In the data type declaration for ‘T’\r\n}}}\r\n\r\nBut GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`:\r\n\r\n{{{#!hs\r\ndata T a (a :: a)\r\n}}}\r\n\r\nResults in this error:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:8: error:\r\n Conflicting definitions for ‘a’\r\n Bound at: Bug.hs:5:8\r\n Bug.hs:5:11\r\n\r\nBug.hs:5:16: error:\r\n Type variable ‘a’ used in a kind.\r\n Did you mean to use TypeInType?\r\n the data type declaration for ‘T’\r\n}}}\r\n\r\nBut with this modification:\r\n\r\n{{{#!hs\r\ndata T (a :: a) a\r\n}}}\r\n\r\nYou won't get an error message about `a` being used as both a kind and type:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:5:9: error:\r\n Conflicting definitions for ‘a’\r\n Bound at: Bug.hs:5:9\r\n Bug.hs:5:17\r\n}}}\r\n\r\nTo make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\ndata T (a :: a)\r\n\r\nclass C x\r\ninstance C (T (a :: a))\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:8:16: error:\r\n Variable ‘a’ used as both a kind and a type\r\n Did you intend to use TypeInType?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/12533Internal error using redundant forall with default signature2019-07-07T18:26:12ZDavid FeuerInternal error using redundant forall with default signature```hs
{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}
class Foo x where
foo :: forall a . x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
GHC (7.8.3 and 8.0.1) c...```hs
{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}
class Foo x where
foo :: forall a . x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
GHC (7.8.3 and 8.0.1) chokes on the above with the message
```
Buggy.hs:7:19: error:
• GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [aoY :-> Type variable ‘x’ = x,
ap0 :-> Type variable ‘a’ = a,
ap1 :-> Identifier[x::x a, <NotTopLevel>]]
• In the first argument of ‘x’, namely ‘a’
In the type signature:
go :: x a
In an equation for ‘foo’:
foo x
= go
where
go :: x a
go = undefined
```
If I remove the redundant `forall` it works fine:
```hs
class Foo x where
foo :: x a -> x a
default foo :: forall a . x a -> x a
foo x = go
where go :: x a
go = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Internal error using redundant forall with default signature","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-}\r\n\r\nclass Foo x where\r\n foo :: forall a . x a -> x a\r\n default foo :: forall a . x a -> x a\r\n foo x = go\r\n where go :: x a\r\n go = undefined\r\n}}}\r\n\r\nGHC (7.8.3 and 8.0.1) chokes on the above with the message\r\n\r\n{{{\r\nBuggy.hs:7:19: error:\r\n • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [aoY :-> Type variable ‘x’ = x,\r\n ap0 :-> Type variable ‘a’ = a,\r\n ap1 :-> Identifier[x::x a, <NotTopLevel>]]\r\n • In the first argument of ‘x’, namely ‘a’\r\n In the type signature:\r\n go :: x a\r\n In an equation for ‘foo’:\r\n foo x\r\n = go\r\n where\r\n go :: x a\r\n go = undefined\r\n}}}\r\n\r\nIf I remove the redundant `forall` it works fine:\r\n\r\n{{{#!hs\r\nclass Foo x where\r\n foo :: x a -> x a\r\n default foo :: forall a . x a -> x a\r\n foo x = go\r\n where go :: x a\r\n go = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12532Remove sum and tuple names from knownKeyNames2019-07-07T18:26:12ZBen GamariRemove sum and tuple names from knownKeyNamesAs noted in [ticket:12415\#comment:123565](https://gitlab.haskell.org//ghc/ghc/issues/12415#note_123565) there are a large number of names inhabiting `knownKeyNames` and therefore the original name cache due to tuples and sums. It should...As noted in [ticket:12415\#comment:123565](https://gitlab.haskell.org//ghc/ghc/issues/12415#note_123565) there are a large number of names inhabiting `knownKeyNames` and therefore the original name cache due to tuples and sums. It shouldn't be so hard to remove these and handle them in an ad-hoc manner:
- original name cache lookups (e.g. finding out the `Name` associated with an `OccName`) can been handled by parsing the `OccName`'s string
- looking up the `Name` associated with a `Unique` (which is needed in `BinIface` during interface file deserialization) can be done with a set of static functions.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove sum and tuple names from knownKeyNames","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":"As noted in ticket:12415#comment:5 there are a large number of names inhabiting `knownKeyNames` and therefore the original name cache due to tuples and sums. It shouldn't be so hard to remove these and handle them in an ad-hoc manner:\r\n\r\n * original name cache lookups (e.g. finding out the `Name` associated with an `OccName`) can been handled by parsing the `OccName`'s string\r\n * looking up the `Name` associated with a `Unique` (which is needed in `BinIface` during interface file deserialization) can be done with a set of static functions.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12531Holes should be representation-polymorphic2019-07-07T18:26:12ZmniipHoles should be representation-polymorphicI often use holes while writing long expressions out in GHCi in order to let the typechecker assist me with type inference.
Sometimes though I find myself in a situation where I want to use holes near unlifted types and that results in ...I often use holes while writing long expressions out in GHCi in order to let the typechecker assist me with type inference.
Sometimes though I find myself in a situation where I want to use holes near unlifted types and that results in kind check messages obscuring the holes or having hole errors not show up at all:
```hs
> I# (_ +# 1#)
<interactive>:5:5: error:
• Couldn't match a lifted type with an unlifted type
When matching the kind of ‘Int#’
• In the first argument of ‘(+#)’, namely ‘_’
In the first argument of ‘I#’, namely ‘(_ +# 1#)’
In the expression: I# (_ +# 1#)
<interactive>:5:5: error:
• Found hole: _ :: Int#
• In the first argument of ‘(+#)’, namely ‘_’
In the first argument of ‘I#’, namely ‘(_ +# 1#)’
In the expression: I# (_ +# 1#)
• Relevant bindings include it :: Int (bound at <interactive>:5:1)
```
(Don't be deceived, the type of `_` there is actually `Int# |> (TYPE U(hole:{a1qG}, 'IntRep, 'PtrRepLifted)_N)_N`)
Perhaps the type of `_` should be `forall r (a :: TYPE r). a` or even `forall k (a :: k). a` instead?
This might lead to issues with `-fdefer-typed-holes` but maybe we could at first disallow deferred unlifted-kinded holes? But in theory a hole is just a call to `error` which is representation-polymorphic already.8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12530Template Haskell support for TypeApplications2019-07-07T18:26:13ZRyan ScottTemplate Haskell support for TypeApplicationsOne more TH trick I'd like to have up my sleeve. Patch coming soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 ...One more TH trick I'd like to have up my sleeve. Patch coming soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for TypeApplications","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"One more TH trick I'd like to have up my sleeve. Patch coming soon.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12529Error message: visible type application of constructor/variable that is not i...2019-09-18T07:20:37ZIcelandjackError message: visible type application of constructor/variable that is not in scopeIf I use an identifier not in scope:
```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p
<interactive>:1:1: error: Variable not in scope: p
Prelude> P
<interactive>:2:1: error: Data con...If I use an identifier not in scope:
```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p
<interactive>:1:1: error: Variable not in scope: p
Prelude> P
<interactive>:2:1: error: Data constructor not in scope: P
```
Using visible type application:
```
$ ghci -ignore-dot-ghci -XTypeApplications
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> p @Int
<interactive>:1:1: error:
• Cannot apply expression of type ‘t0’
to a visible type argument ‘Int’
• In the expression: p @Int
In an equation for ‘it’: it = p @Int
Prelude> P @Int
<interactive>:2:1: error:
• Cannot apply expression of type ‘t0’
to a visible type argument ‘Int’
• In the expression: P @Int
In an equation for ‘it’: it = P @Int
```
I would prefer these error messages to be the same as the first two: thoughts?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Error message: visible type application of constructor/variable that is not in scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I use an identifier not in scope:\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> p\r\n\r\n<interactive>:1:1: error: Variable not in scope: p\r\nPrelude> P\r\n\r\n<interactive>:2:1: error: Data constructor not in scope: P\r\n}}}\r\n\r\nUsing visible type application:\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci -XTypeApplications\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> p @Int\r\n\r\n<interactive>:1:1: error:\r\n • Cannot apply expression of type ‘t0’\r\n to a visible type argument ‘Int’\r\n • In the expression: p @Int\r\n In an equation for ‘it’: it = p @Int\r\nPrelude> P @Int\r\n\r\n<interactive>:2:1: error:\r\n • Cannot apply expression of type ‘t0’\r\n to a visible type argument ‘Int’\r\n • In the expression: P @Int\r\n In an equation for ‘it’: it = P @Int\r\n}}}\r\n\r\nI would prefer these error messages to be the same as the first two: thoughts?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12528ghc: panic! while compiling2019-07-07T18:26:14ZAmedeo Molnárghc: panic! while compilingWhile building one of my projects, GHC crashes with the following message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Block
[]
Please report this as a GHC bug: http://ww...While building one of my projects, GHC crashes with the following message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Block
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The project I'm trying to build can be found at https://github.com/nek0/eidolon.
The file it crashes at is called `Foundation.hs`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"ghc: panic! while cimpiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While building one of my projects, GHC crashes with the following message:\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tfind_tycon\r\n Block\r\n []\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe project I'm trying to build can be found at https://github.com/nek0/eidolon.\r\nThe file it crashes at is called `Foundation.hs`","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12526regression in type inference with respect to type families2019-07-07T18:26:14ZLemmingregression in type inference with respect to type familiesThe following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/s...The following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/synthesizer/llvm/ I get the following error:
```
src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:296:23: error:
• Couldn't match type ‘Synthesizer.Causal.Class.ProcessOf t0’
with ‘CausalP.T (SampleRate Real, ())’
Expected type: CausalP.T
(SampleRate Real, ())
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)),
(Serial.Value
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Real,
VectorValue))
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)))
Actual type: Synthesizer.Causal.Class.ProcessOf
t0
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)),
(Serial.Value
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float,
Serial.Value
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float))
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)))
The type variable ‘t0’ is ambiguous
• In the first argument of ‘($&)’, namely ‘osci’
In the second argument of ‘liftA2’, namely
‘(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))’
In the expression:
liftA2
Stereo.cons
(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))
(osci $& shapeCtrl &|& (negate expo &|& fmap Stereo.right freqs))
• Relevant bindings include
osci :: Synthesizer.Causal.Class.ProcessOf
t0
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)),
(Serial.Value
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float,
Serial.Value
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float))
(Serial.T
(LLVM.Value
(LLVM.Vector
(TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)
Float)))
(bound at src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:294:19)
```
The type for `t0` should be known and then the type checker should be able to check that `ProcessOf t0` equals `CausalP.T`. It did so in earlier versions but now fails on that part.
I still have to reduce that example, but for now I want to alert you that there seems to be a regression in the type inference.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"regression in type inference with respect to type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/synthesizer/llvm/ I get the following error:\r\n{{{\r\nsrc/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:296:23: error:\r\n • Couldn't match type ‘Synthesizer.Causal.Class.ProcessOf t0’\r\n with ‘CausalP.T (SampleRate Real, ())’\r\n Expected type: CausalP.T\r\n (SampleRate Real, ())\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)),\r\n (Serial.Value\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Real,\r\n VectorValue))\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)))\r\n Actual type: Synthesizer.Causal.Class.ProcessOf\r\n t0\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)),\r\n (Serial.Value\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float,\r\n Serial.Value\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float))\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)))\r\n The type variable ‘t0’ is ambiguous\r\n • In the first argument of ‘($&)’, namely ‘osci’\r\n In the second argument of ‘liftA2’, namely\r\n ‘(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))’\r\n In the expression:\r\n liftA2\r\n Stereo.cons\r\n (osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))\r\n (osci $& shapeCtrl &|& (negate expo &|& fmap Stereo.right freqs))\r\n • Relevant bindings include\r\n osci :: Synthesizer.Causal.Class.ProcessOf\r\n t0\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)),\r\n (Serial.Value\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float,\r\n Serial.Value\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float))\r\n (Serial.T\r\n (LLVM.Value\r\n (LLVM.Vector\r\n (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc)\r\n Float)))\r\n (bound at src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:294:19)\r\n}}}\r\nThe type for `t0` should be known and then the type checker should be able to check that `ProcessOf t0` equals `CausalP.T`. It did so in earlier versions but now fails on that part.\r\nI still have to reduce that example, but for now I want to alert you that there seems to be a regression in the type inference.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12525Internal identifiers creeping into :show bindings2019-07-07T18:26:14ZmniipInternal identifiers creeping into :show bindingsWhen binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :...When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help
> :show bindings
> x = ()
> :show bindings
<b>$trModule :: GHC.Types.Module = _</b>
x :: () = _
> class Foo a
> :show bindings
x :: () = _
class Foo a
<b>$tcFoo :: GHC.Types.TyCon = _
$tc'C:Foo :: GHC.Types.TyCon = _
$trModule :: GHC.Types.Module = _</b>
</pre>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal identifiers creeping into :show bindings","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When binding variables the \"new\" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.\r\n\r\n{{{#!html\r\n<pre class=\"wiki\">\r\nGHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help\r\n> :show bindings\r\n> x = ()\r\n> :show bindings\r\n<b>$trModule :: GHC.Types.Module = _</b>\r\nx :: () = _\r\n> class Foo a\r\n> :show bindings\r\nx :: () = _\r\nclass Foo a\r\n<b>$tcFoo :: GHC.Types.TyCon = _\r\n$tc'C:Foo :: GHC.Types.TyCon = _\r\n$trModule :: GHC.Types.Module = _</b>\r\n</pre>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/12524RFC: Allow prefixing result evaluated at GHCi prompt2019-07-07T18:26:15ZIcelandjackRFC: Allow prefixing result evaluated at GHCi promptSimilar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of
```
:set prompt " ghci> "
:set prompt-cont " ghci| "
:set resul...Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of
```
:set prompt " ghci> "
:set prompt-cont " ghci| "
:set result " "
```
the desired outcome would be `↓` as indented code for IRC, also reddit code format:
```
ghci> 1 + 2 + 3
6
ghci> reverse "hello"
"olleh"
```
----
The other case came from [this tweet](https://twitter.com/rightfold/status/767301255140179968)
```
:set prompt ""
:set result "-- "
```
```
1 + 2 + 3
-- 6
reverse "hello"
-- "olleh"
```
This can be copied/pasted back to a separate GHCi session where the result is ignored.
----
I haven't seen this feature in any other repl, I'm not sure if this would see much use.
This wouldn't work with IO actions without some magic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RFC: Allow prefixing result evaluated at GHCi prompt","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of\r\n\r\n{{{\r\n:set prompt \" ghci> \"\r\n:set prompt-cont \" ghci| \"\r\n:set result \" \"\r\n}}}\r\n\r\nthe desired outcome would be `↓` as indented code for IRC, also reddit code format: \r\n{{{\r\n ghci> 1 + 2 + 3\r\n 6\r\n ghci> reverse \"hello\"\r\n \"olleh\"\r\n}}}\r\n\r\n----\r\n\r\nThe other case came from [https://twitter.com/rightfold/status/767301255140179968 this tweet]\r\n\r\n{{{\r\n:set prompt \"\"\r\n:set result \"-- \"\r\n}}}\r\n\r\n{{{\r\n1 + 2 + 3\r\n-- 6\r\nreverse \"hello\"\r\n-- \"olleh\"\r\n}}}\r\n\r\nThis can be copied/pasted back to a separate GHCi session where the result is ignored. \r\n\r\n----\r\n\r\nI haven't seen this feature in any other repl, I'm not sure if this would see much use.\r\n\r\nThis wouldn't work with IO actions without some magic.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12523Constructor info tables generated by GHCi don't return tagged pointers2019-07-07T18:26:15ZmniipConstructor info tables generated by GHCi don't return tagged pointersIf we have in a file:
```hs
data X = X String
unX (X s) = s
```
And then load the file in ghci with `-fobject-code` and
```
> data Y = Y String
> unX (Unsafe.Coerce.unsafeCoerce (Y "foo"))
"Segmentation fault (core dumped)
```
Even t...If we have in a file:
```hs
data X = X String
unX (X s) = s
```
And then load the file in ghci with `-fobject-code` and
```
> data Y = Y String
> unX (Unsafe.Coerce.unsafeCoerce (Y "foo"))
"Segmentation fault (core dumped)
```
Even though we are shooting ourselves in the foot there, the constructors `X` and `Y` are represented identically internally, so the code is supposed to work. And it does work if we either move `unX` into ghci'd code, or `Y` into compiled code.
After a legthy debugging session with \@rwbarton over IRC, we've identified the culprit of this. As \[\[Commentary/Rts/HaskellExecution/PointerTagging\]\] states, "In the continuation of an algebraic case, R1 is assumed tagged". And all compiled constructors tag the pointer when entered, e.g:
```
Dump of assembler code for function ghczmprim_GHCziTypes_False_static_info:
0x00007fffef8dd018 <+0>: 48 ff c3 inc %rbx
0x00007fffef8dd01b <+3>: ff 65 00 jmpq *0x0(%rbp)
Dump of assembler code for function base_GHCziBase_Just_static_info:
0x00007ffff03eb780 <+0>: 48 83 c3 02 add $0x2,%rbx
0x00007ffff03eb784 <+4>: ff 65 00 jmpq *0x0(%rbp)
Dump of assembler code for function ghczmprim_GHCziTypes_GT_static_info:
0x00007fffef8dd1f8 <+0>: 48 83 c3 03 add $0x3,%rbx
0x00007fffef8dd1fc <+4>: ff 65 00 jmpq *0x0(%rbp)
Dump of assembler code for function base_GHCziRTSziFlags_HeapByClosureType_static_info:
0x00007ffff057e768 <+0>: 48 ff c3 inc %rbx // more than 7 constructors so all tags are '1'
0x00007ffff057e76b <+3>: ff 65 00 jmpq *0x0(%rbp)
```
Whereas all ghci-bound data constructors share the `stg_interp_constr_entry` entry code (with an optional trampoline leading there):
```
Dump of assembler code from 0x7ffff7ff3080 to 0x7ffff7ff3090:
=> 0x00007ffff7ff3080: jmpq *0x2(%rip) # 0x7ffff7ff3088
0x00007ffff7ff3088: 0x00007fffef4c9388
Dump of assembler code for function stg_interp_constr_entry:
0x00007fffef4c9388 <+0>: ff 65 00 jmpq *0x0(%rbp)
```
Relevant code: source:libraries/ghci/GHCi/InfoTable.hsc\#L32
So in the end, compiled code relies on the assumption that the pointer is tagged, and ghci constructors produce untagged pointers. Even though it is currently impossible to have compiled code pattern match on a ghci constructor, I think this shouldn't happen.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constructor info tables generated by GHCi don't return tagged pointers","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If we have in a file:\r\n{{{#!hs\r\ndata X = X String\r\nunX (X s) = s\r\n}}}\r\nAnd then load the file in ghci with `-fobject-code` and\r\n{{{\r\n> data Y = Y String\r\n> unX (Unsafe.Coerce.unsafeCoerce (Y \"foo\"))\r\n\"Segmentation fault (core dumped)\r\n}}}\r\n\r\nEven though we are shooting ourselves in the foot there, the constructors `X` and `Y` are represented identically internally, so the code is supposed to work. And it does work if we either move `unX` into ghci'd code, or `Y` into compiled code.\r\n\r\nAfter a legthy debugging session with @rwbarton over IRC, we've identified the culprit of this. As [[Commentary/Rts/HaskellExecution/PointerTagging]] states, \"In the continuation of an algebraic case, R1 is assumed tagged\". And all compiled constructors tag the pointer when entered, e.g:\r\n{{{\r\nDump of assembler code for function ghczmprim_GHCziTypes_False_static_info:\r\n 0x00007fffef8dd018 <+0>:\t48 ff c3\tinc %rbx\r\n 0x00007fffef8dd01b <+3>:\tff 65 00\tjmpq *0x0(%rbp)\r\nDump of assembler code for function base_GHCziBase_Just_static_info:\r\n 0x00007ffff03eb780 <+0>:\t48 83 c3 02\tadd $0x2,%rbx\r\n 0x00007ffff03eb784 <+4>:\tff 65 00\tjmpq *0x0(%rbp)\r\nDump of assembler code for function ghczmprim_GHCziTypes_GT_static_info:\r\n 0x00007fffef8dd1f8 <+0>:\t48 83 c3 03\tadd $0x3,%rbx\r\n 0x00007fffef8dd1fc <+4>:\tff 65 00\tjmpq *0x0(%rbp)\r\nDump of assembler code for function base_GHCziRTSziFlags_HeapByClosureType_static_info:\r\n 0x00007ffff057e768 <+0>:\t48 ff c3\tinc %rbx // more than 7 constructors so all tags are '1'\r\n 0x00007ffff057e76b <+3>:\tff 65 00\tjmpq *0x0(%rbp)\r\n}}}\r\n\r\nWhereas all ghci-bound data constructors share the `stg_interp_constr_entry` entry code (with an optional trampoline leading there):\r\n{{{\r\nDump of assembler code from 0x7ffff7ff3080 to 0x7ffff7ff3090:\r\n=> 0x00007ffff7ff3080:\tjmpq *0x2(%rip) # 0x7ffff7ff3088\r\n 0x00007ffff7ff3088:\t0x00007fffef4c9388\r\nDump of assembler code for function stg_interp_constr_entry:\r\n 0x00007fffef4c9388 <+0>:\tff 65 00\tjmpq *0x0(%rbp)\r\n}}}\r\n\r\nRelevant code: source:libraries/ghci/GHCi/InfoTable.hsc#L32\r\n\r\nSo in the end, compiled code relies on the assumption that the pointer is tagged, and ghci constructors produce untagged pointers. Even though it is currently impossible to have compiled code pattern match on a ghci constructor, I think this shouldn't happen.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2mniipmniip