GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-03-16T19:47:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15544Non-deterministic segmentation fault in cryptohash-sha256 testsuite2022-03-16T19:47:50ZBen GamariNon-deterministic segmentation fault in cryptohash-sha256 testsuite```
$ cabal get cryptohash-sha256-0.11.101.0
$ cd cryptohash-sha256-0.11.101.0
$ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer="*:base,*:stm,*:tasty" test:test-sha256 -- -j 8 --quickcheck-tests 9999
```
Eventually the program w...```
$ cabal get cryptohash-sha256-0.11.101.0
$ cd cryptohash-sha256-0.11.101.0
$ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer="*:base,*:stm,*:tasty" test:test-sha256 -- -j 8 --quickcheck-tests 9999
```
Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15542DuplicateRecordFields not honored within a data family?2022-09-01T19:25:51ZmichalrusDuplicateRecordFields not honored within a data family?I’m observing some weird behavior, which is probably closely related to issue #15149.
The following minimized code does not compile on 8.2.1, 8.2.2, but it does compile on 8.4.3.
However, in my original (non-free) codebase, this is rev...I’m observing some weird behavior, which is probably closely related to issue #15149.
The following minimized code does not compile on 8.2.1, 8.2.2, but it does compile on 8.4.3.
However, in my original (non-free) codebase, this is reversed: 8.2.2 compiles it just fine, and 8.4.3 fails with both errors per usage location at the same time:
```
src/.../Docs.hs:123:11: error:
• Constructor ‘X'Y’ does not have the required strict field(s): z
...
src/.../Docs.hs:123:11: error:
• Constructor ‘X'Y’ does not have field ‘z’
```
I noticed, after updating the codebase’s compiler to 8.4.3.
If the `z` field is renamed and unique, it compiles correctly.
How can I go about debugging/minimizing this?
This is the minimized code that works the other way round (OK on 8.4.3, fails on 8.2.2):
```hs
{-# LANGUAGE DuplicateRecordFields #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE StrictData #-}
module Main where
data AB = A | B
class SomeClass (ab :: AB) where
data SomeData ab
instance SomeClass 'A where
data SomeData 'A = SomeData'A{someField :: Int} deriving Show
instance SomeClass 'B where
data SomeData 'B = SomeData'B{someField :: Int}
main :: IO ()
main = print SomeData'A{someField = 5}
```
<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":"DuplicateRecordFields not honored within a data family?","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":"I’m observing some weird behavior, which is probably closely related to issue #15149.\r\n\r\nThe following minimized code does not compile on 8.2.1, 8.2.2, but it does compile on 8.4.3.\r\n\r\nHowever, in my original (non-free) codebase, this is reversed: 8.2.2 compiles it just fine, and 8.4.3 fails with both errors per usage location at the same time:\r\n\r\n{{{\r\nsrc/.../Docs.hs:123:11: error:\r\n • Constructor ‘X'Y’ does not have the required strict field(s): z\r\n\r\n...\r\n\r\nsrc/.../Docs.hs:123:11: error:\r\n • Constructor ‘X'Y’ does not have field ‘z’\r\n}}}\r\n\r\nI noticed, after updating the codebase’s compiler to 8.4.3.\r\n\r\nIf the `z` field is renamed and unique, it compiles correctly.\r\n\r\nHow can I go about debugging/minimizing this?\r\n\r\nThis is the minimized code that works the other way round (OK on 8.4.3, fails on 8.2.2):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DuplicateRecordFields #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE StrictData #-}\r\n\r\nmodule Main where\r\n\r\ndata AB = A | B\r\n\r\nclass SomeClass (ab :: AB) where\r\n data SomeData ab\r\n\r\ninstance SomeClass 'A where\r\n data SomeData 'A = SomeData'A{someField :: Int} deriving Show\r\n\r\ninstance SomeClass 'B where\r\n data SomeData 'B = SomeData'B{someField :: Int}\r\n\r\nmain :: IO ()\r\nmain = print SomeData'A{someField = 5}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15541package environment files and the GHC API2023-03-21T12:06:34Zlspitznerpackage environment files and the GHC APIThe GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for th...The GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"package environment files and the GHC API","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["environment","package"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC API respects package environment files, which is not documented and was not announced.\r\n\r\nI consider this to be at least a severe documentation bug.\r\n\r\nAfaik this goes back to ghc-8.0.\r\n\r\n#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.","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/15539Regression since 7.10.3, "variable not in scope" errors sometimes get buried ...2019-07-07T18:04:14ZWizekRegression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors.Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion:
https://github.com/ndmitchell/ghcid/issues/159
Here is a small reproducible example:
```hs
module Main where
foo :: String
foo = sho...Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion:
https://github.com/ndmitchell/ghcid/issues/159
Here is a small reproducible example:
```hs
module Main where
foo :: String
foo = show a
where a = baz
bar :: Int
bar = 1
main = putStrLn foo
```
GHC 8.0.x and above will say
```
src/Main.hs:4:7: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘show’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance (Show a, Show b) => Show (Either a b)
-- Defined in ‘Data.Either’
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
...plus 23 others
...plus 212 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the expression: show a
In an equation for ‘foo’:
foo
= show a
where
a = baz
|
4 | foo = show a
| ^^^^^^
src/Main.hs:5:13: error:
• Variable not in scope: baz
• Perhaps you meant ‘bar’ (line 8)
|
5 | where a = baz
| ^^^
```
It's much more useful and much less noisy what 7.10.3 reports:
```
src/Main.hs:5:13:
Not in scope: ‘baz’
Perhaps you meant ‘bar’ (line 8)
```
So a desired output would be something like this for a later GHC release:
```
src/Main.hs:5:13: error:
• Variable not in scope: baz
• Perhaps you meant ‘bar’ (line 8)
|
5 | where a = baz
| ^^^
```
Or if someone is adamant about keeping the other errors even when there are out of scope variables present, then at least can we please reorder them such that the much more relevant out-of-scope errors are at the top?
```
src/Main.hs:5:13: error:
• Variable not in scope: baz
• Perhaps you meant ‘bar’ (line 8)
|
5 | where a = baz
| ^^^
src/Main.hs:4:7: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘show’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance (Show a, Show b) => Show (Either a b)
-- Defined in ‘Data.Either’
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
...plus 23 others
...plus 212 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the expression: show a
In an equation for ‘foo’:
foo
= show a
where
a = baz
|
4 | foo = show a
| ^^^^^^
```
I might even be up for fixing this if there is agreement on the next steps to be taken. (Though I've never contributed to GHC before, on the surface this doesn't seem hard to fix.)
What do you think?
<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 | ntdmitchel |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression since 7.10.3, \"variable not in scope\" errors sometimes get buried under a sea of much less relevant errors.","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":["ntdmitchel"],"type":"Bug","description":"Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion:\r\n\r\nhttps://github.com/ndmitchell/ghcid/issues/159\r\n\r\nHere is a small reproducible example:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nfoo :: String\r\nfoo = show a\r\n where a = baz\r\n\r\nbar :: Int\r\nbar = 1\r\n\r\nmain = putStrLn foo\r\n}}}\r\n\r\nGHC 8.0.x and above will say\r\n\r\n{{{\r\nsrc/Main.hs:4:7: error:\r\n • Ambiguous type variable ‘a0’ arising from a use of ‘show’\r\n prevents the constraint ‘(Show a0)’ from being solved.\r\n Probable fix: use a type annotation to specify what ‘a0’ should be.\r\n These potential instances exist:\r\n instance (Show a, Show b) => Show (Either a b)\r\n -- Defined in ‘Data.Either’\r\n instance Show Ordering -- Defined in ‘GHC.Show’\r\n instance Show Integer -- Defined in ‘GHC.Show’\r\n ...plus 23 others\r\n ...plus 212 instances involving out-of-scope types\r\n (use -fprint-potential-instances to see them all)\r\n • In the expression: show a\r\n In an equation for ‘foo’:\r\n foo\r\n = show a\r\n where\r\n a = baz\r\n |\r\n4 | foo = show a\r\n | ^^^^^^\r\nsrc/Main.hs:5:13: error:\r\n • Variable not in scope: baz\r\n • Perhaps you meant ‘bar’ (line 8)\r\n |\r\n5 | where a = baz\r\n | ^^^\r\n}}}\r\n\r\nIt's much more useful and much less noisy what 7.10.3 reports:\r\n\r\n{{{\r\nsrc/Main.hs:5:13:\r\n Not in scope: ‘baz’\r\n Perhaps you meant ‘bar’ (line 8)\r\n}}}\r\n\r\nSo a desired output would be something like this for a later GHC release:\r\n\r\n{{{\r\nsrc/Main.hs:5:13: error:\r\n • Variable not in scope: baz\r\n • Perhaps you meant ‘bar’ (line 8)\r\n |\r\n5 | where a = baz\r\n | ^^^\r\n}}}\r\n\r\nOr if someone is adamant about keeping the other errors even when there are out of scope variables present, then at least can we please reorder them such that the much more relevant out-of-scope errors are at the top?\r\n\r\n{{{\r\nsrc/Main.hs:5:13: error:\r\n • Variable not in scope: baz\r\n • Perhaps you meant ‘bar’ (line 8)\r\n |\r\n5 | where a = baz\r\n | ^^^\r\nsrc/Main.hs:4:7: error:\r\n • Ambiguous type variable ‘a0’ arising from a use of ‘show’\r\n prevents the constraint ‘(Show a0)’ from being solved.\r\n Probable fix: use a type annotation to specify what ‘a0’ should be.\r\n These potential instances exist:\r\n instance (Show a, Show b) => Show (Either a b)\r\n -- Defined in ‘Data.Either’\r\n instance Show Ordering -- Defined in ‘GHC.Show’\r\n instance Show Integer -- Defined in ‘GHC.Show’\r\n ...plus 23 others\r\n ...plus 212 instances involving out-of-scope types\r\n (use -fprint-potential-instances to see them all)\r\n • In the expression: show a\r\n In an equation for ‘foo’:\r\n foo\r\n = show a\r\n where\r\n a = baz\r\n |\r\n4 | foo = show a\r\n | ^^^^^^\r\n}}}\r\n\r\nI might even be up for fixing this if there is agreement on the next steps to be taken. (Though I've never contributed to GHC before, on the surface this doesn't seem hard to fix.)\r\n\r\nWhat do you think?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15538GHC boot script can't handle Git remote not named origin2021-01-19T16:52:54ZChaiTRexGHC boot script can't handle Git remote not named origin## Problem
I ran the following to get the sources for GHC to build them:
```
git clone -o ghc --recursive http://git.haskell.org/ghc.git
```
Note especially the `-o ghc` part, which uses the Git remote name `ghc` instead of the defaul...## Problem
I ran the following to get the sources for GHC to build them:
```
git clone -o ghc --recursive http://git.haskell.org/ghc.git
```
Note especially the `-o ghc` part, which uses the Git remote name `ghc` instead of the default `origin`. When a custom remote name is used, `./boot` fails:
```
$ ./boot
Traceback (most recent call last):
File "./boot", line 193, in <module>
check_for_url_rewrites()
File "./boot", line 29, in check_for_url_rewrites
subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \
File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
File "/usr/lib/python3.5/subprocess.py", line 708, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1
$ git config remote.origin.url
$ echo $?
1
```
## Solution
`git config remote.origin.url` can be used first. Whenever `git config remote.origin.url` fails, a `git rev-parse` command (thanks to freenode/\#git/_ikke_ for it) can be used to get the remote name and branch that would be pushed to:
```
$ git rev-parse --symbolic-full-name --abbrev-ref @{upstream}
ghc/coercible
$ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//'
ghc
$ git config "remote.$( git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//' ).url"
http://git.haskell.org/ghc.git
```
## Workaround
Rename the remote to `origin`:
```
$ git remote rename "$( git config branch.master.remote )" origin
$ ./boot
Creating libraries/mtl/ghc.mk
Creating libraries/unix/ghc.mk
Creating libraries/text/ghc.mk
⋮
```8.6.1ChaiTRexChaiTRexhttps://gitlab.haskell.org/ghc/ghc/-/issues/15537Panic when building Crucible2019-07-07T18:04:15ZLangston BarrettPanic when building CrucibleI've encountered a panic, which GHC has asked me to report:
```
[19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o )
<no location info>: error:
...I've encountered a panic, which GHC has asked me to report:
```
[19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o )
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
isUnliftedType
r_a4Zsg :: TYPE rep_a4Zsf
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This was when compiling [crucible-llvm](https://github.com/GaloisInc/crucible/tree/master/crucible-llvm) revision 186mfb7wlz with GHC 8.4.3.
I'm building in Nix with a sandbox, so this should be easily reproducible. The Nix files are available here: https://github.com/siddharthist/galois-haskell-nix/tree/ghc-bug. Just run nix-build -A haskellPackages.crucible-llvm.
<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":"Panic when building Crucible","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":"I've encountered a panic, which GHC has asked me to report:\r\n{{{\r\n[19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o )\r\n\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n isUnliftedType\r\n r_a4Zsg :: TYPE rep_a4Zsf\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\nThis was when compiling [https://github.com/GaloisInc/crucible/tree/master/crucible-llvm crucible-llvm] revision 186mfb7wlz with GHC 8.4.3.\r\n\r\nI'm building in Nix with a sandbox, so this should be easily reproducible. The Nix files are available here: https://github.com/siddharthist/galois-haskell-nix/tree/ghc-bug. Just run nix-build -A haskellPackages.crucible-llvm.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15536Unify unlifted pointer equality primitives2021-09-07T15:51:16ZDavid FeuerUnify unlifted pointer equality primitivesWe have a bunch of different primops to test pointer equality between various unlifted pointer types (`MutableArray#`, `MutVar#`, etc.). Now that we have the necessary type machinery, I believe we should be able to get away with just one...We have a bunch of different primops to test pointer equality between various unlifted pointer types (`MutableArray#`, `MutVar#`, etc.). Now that we have the necessary type machinery, I believe we should be able to get away with just one:
```hs
unliftedPtrEquality#
:: forall (a :: TYPE 'UnliftedRep).
a -> a -> Int#
```
All the rest can then be defined as regular functions in `GHC.Exts` or some such.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| 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":"Unify unlifted pointer equality primitives","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We have a bunch of different primops to test pointer equality between various unlifted pointer types (`MutableArray#`, `MutVar#`, etc.). Now that we have the necessary type machinery, I believe we should be able to get away with just one:\r\n\r\n{{{#!hs\r\nunliftedPtrEquality#\r\n :: forall (a :: TYPE 'UnliftedRep).\r\n a -> a -> Int#\r\n}}}\r\n\r\nAll the rest can then be defined as regular functions in `GHC.Exts` or some such.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15535Expose the StableName constructor2019-07-07T18:04:16ZDavid FeuerExpose the StableName constructorA `StableName` is just a wrapper around `StableName#`, but we don't reveal that anywhere. That means that user code needs to use `unsafeCoerce` to convert between `StableName` and `StableName#`, which seems terrible.
<details><summary>T...A `StableName` is just a wrapper around `StableName#`, but we don't reveal that anywhere. That means that user code needs to use `unsafeCoerce` to convert between `StableName` and `StableName#`, which seems terrible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Expose the StableName constructor","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"A `StableName` is just a wrapper around `StableName#`, but we don't reveal that anywhere. That means that user code needs to use `unsafeCoerce` to convert between `StableName` and `StableName#`, which seems terrible.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15533Access the number of bits in the target machine's Int type at compile time2021-11-05T17:03:02ZChaiTRexAccess the number of bits in the target machine's Int type at compile timeI'm not sure of the current progress on GHC cross-compiling user programs, but I think a small addition might need to be made somewhere in the modules included with `ghc`.
If I'm reading the documentation correctly, [GHC.ByteOrder.targe...I'm not sure of the current progress on GHC cross-compiling user programs, but I think a small addition might need to be made somewhere in the modules included with `ghc`.
If I'm reading the documentation correctly, [GHC.ByteOrder.targetByteOrder](https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-ByteOrder.html#v:targetByteOrder) will let us know the endianness of the target machine even if the compiling machine has a different endianness. I assume that this allows Template Haskell to, at compile time, generate proper code specifically for the target based on that fact.
I can't find any way of finding out the bit size of an `Int` (specifically the exact value of `(finiteBitSize (undefined :: Int)`) on the target platform, and it would be nice if that were added in a way that's convenient to access in general and by Template Haskell at compile time, similar to `GHC.ByteOrder.targetByteOrder`.
----
I've looked into it a little bit and found that [the GHC API will tell you the word size of the target in bytes with platformWordSize](https://github.com/ghc/ghc/blob/master/compiler/utils/Platform.hs#L31-L33) (also on [Hackage](https://hackage.haskell.org/package/ghc-8.4.3/docs/Platform.html#v:platformWordSize)):
`lineno=25 id=b marks=31-33
-- | Contains enough information for the native code generator to emit
-- code for this platform.
data Platform
= Platform {
platformArch :: Arch,
platformOS :: OS,
-- Word size in bytes (i.e. normally 4 or 8,
-- for 32bit and 64bit platforms respectively)
platformWordSize :: {-# UNPACK #-} !Int,
platformUnregisterised :: Bool,
platformHasGnuNonexecStack :: Bool,
platformHasIdentDirective :: Bool,
platformHasSubsectionsViaSymbols :: Bool,
platformIsCrossCompiling :: Bool
}
deriving (Read, Show, Eq)
`
The problem is that this doesn't account for possible tag bits reducing the size *in bits* of `Int` to something less than the given `platformWordSize`.
Recently, [support for WORD_SIZE_IN_BITS \< 32 was dropped](https://ghc.haskell.org/trac/ghc/ticket/15486), so tag bits aren't a problem on 32-bit platforms anymore, but they might be on 64-bit platforms.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15531CApiFFI generates bad prototypes for pointers of `Foreign.C` types2022-07-21T02:51:22ZHerbert Valerio Riedelhvr@gnu.orgCApiFFI generates bad prototypes for pointers of `Foreign.C` typesConsider the example
```hs
{-# LANGUAGE CApiFFI #-}
module Foo where
import Foreign.Ptr
import Foreign.C
foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char
foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO ...Consider the example
```hs
{-# LANGUAGE CApiFFI #-}
module Foo where
import Foreign.Ptr
import Foreign.C
foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char
foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char)
foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr (Ptr Char))
foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar
foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr CChar)
foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO (Ptr (Ptr CChar))
foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO ()
foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr CULong -> Ptr CSize -> IO ()
```
which creates various wrappers; this generates the C wrapper
```c
#define IN_STG_CODE 0
#include "Rts.h"
#include "Stg.h"
#ifdef __cplusplus
extern "C" {
#endif
#include "foo.h"
void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, a4, a5, a6, a7, a8, a9);}
#include "foo.h"
void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);}
#include "foo.h"
void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);}
#include "foo.h"
void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);}
#include "foo.h"
HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);}
#include "foo.h"
HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);}
#include "foo.h"
HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);}
#include "foo.h"
HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);}
#ifdef __cplusplus
}
#endif
```
Specifically, the wrappers for `c_fn5`, `c_fn6` and `c_fn8` are wrong.
This is quite a serious bug as it renders `CApiFFI` unusable for matching with C prototypes, as modern C compilers will refuse to coerce a pointer `void**` into an argument to a function expecting a `char**`. One concrete example is e.g.
```hs
-- int getfilecon(const char *path, char **con);
foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: CString -> Ptr CString -> IO CInt
```
which even though properly declared (NB: `type CString = Ptr CChar`), when compiled would fail because of this bug:
```
tmpdir/ghc31009_0/ghc_2.c: In function ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’:
tmpdir/ghc31009_0/ghc_2.c:8:92: error:
warning: passing argument 2 of ‘getfilecon’ from incompatible pointer type [-Wincompatible-pointer-types]
HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);}
^
|
8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);}
| ^
In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error:
/usr/include/selinux/selinux.h:101:12: error:
note: expected ‘char **’ but argument is of type ‘void **’
extern int getfilecon(const char *path, char ** con);
^
|
101 | extern int getfilecon(const char *path, char ** con);
| ^
```9.0.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15530Type applications in patterns2020-03-05T14:14:48ZJoachim Breitnermail@joachim-breitner.deType applications in patternsThe Type applications in pattern proposal was accepted:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0031-type-applications-in-patterns.rst
This ticket tracks its implementation.
I am tempted to give it a shot, ...The Type applications in pattern proposal was accepted:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0031-type-applications-in-patterns.rst
This ticket tracks its implementation.
I am tempted to give it a shot, to learn more about the type checker.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| 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":"Type applications in patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The Type applications in pattern proposal was accepted:\r\nhttps://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0031-type-applications-in-patterns.rst\r\n\r\nThis ticket tracks its implementation.\r\n\r\nI am tempted to give it a shot, to learn more about the type checker.","type_of_failure":"OtherFailure","blocking":[]} -->My NguyenMy Nguyenhttps://gitlab.haskell.org/ghc/ghc/-/issues/15529runtime bug when profiling retainers2020-01-31T00:04:41ZPhilipperuntime bug when profiling retainersI have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:
```
stack clean
stack build
stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-p...I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:
```
stack clean
stack build
stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling
stack exec vfix -- +RTS -hr -sstderr
```
After the compilation messages i get the following error:
```
vfix: internal error: Invalid object *c in pop()
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Command terminated by signal 6
```
<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":"runtime bug when profiling retainers","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":"I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands:\r\n\r\n\r\n{{{\r\nstack clean\r\nstack build\r\nstack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling\r\nstack exec vfix -- +RTS -hr -sstderr\r\n}}}\r\n\r\nAfter the compilation messages i get the following error:\r\n\r\n\r\n{{{\r\nvfix: internal error: Invalid object *c in pop()\r\n (GHC version 8.4.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nCommand terminated by signal 6\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://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/15527TypeApplications error message doesn't parenthesize infix name2019-07-07T18:04:18ZRyan ScottTypeApplications error message doesn't parenthesize infix nameIf you compile the following program:
```hs
module Bug where
f :: (Int -> Int) -> (Int -> Int) -> (Int -> Int)
f = (.) @Int
```
You'll get this error:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs,...If you compile the following program:
```hs
module Bug where
f :: (Int -> Int) -> (Int -> Int) -> (Int -> Int)
f = (.) @Int
```
You'll get this error:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:4:6: error:
Pattern syntax in expression context: .@Int
Did you mean to enable TypeApplications?
|
4 | f = (.) @Int
| ^^^^^^^^
```
I was taken aback by this strange `.@` thing before I realized what was actually going on: the error message simply forgot to parenthesize `.`. This is `ppr_expr`'s fault, since it calls `ppr` on an `RdrName` instead of `pprPrefixOcc`. Patch incoming.
<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":"TypeApplications error message doesn't parenthesize infix name","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you compile the following program:\r\n\r\n{{{#!hs\r\nmodule Bug where\r\n\r\nf :: (Int -> Int) -> (Int -> Int) -> (Int -> Int)\r\nf = (.) @Int\r\n}}}\r\n\r\nYou'll get this error:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:4:6: error:\r\n Pattern syntax in expression context: .@Int\r\n Did you mean to enable TypeApplications?\r\n |\r\n4 | f = (.) @Int\r\n | ^^^^^^^^\r\n}}}\r\n\r\nI was taken aback by this strange `.@` thing before I realized what was actually going on: the error message simply forgot to parenthesize `.`. This is `ppr_expr`'s fault, since it calls `ppr` on an `RdrName` instead of `pprPrefixOcc`. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15526Explain or remove mystery import in Unsafe.Coerce2019-07-07T18:04:18ZDavid FeuerExplain or remove mystery import in Unsafe.Coerce`Unsafe.Coerce` has the line
```hs
import GHC.Integer () -- for build ordering
```
It is not at all clear to me why build ordering demands that `GHC.Integer` be compiled before `Unsafe.Coerce` when the latter uses no numeric literals, ...`Unsafe.Coerce` has the line
```hs
import GHC.Integer () -- for build ordering
```
It is not at all clear to me why build ordering demands that `GHC.Integer` be compiled before `Unsafe.Coerce` when the latter uses no numeric literals, no arithmetic, and no numeric types. If there's a real reason for this, the comment should be expanded. Otherwise, the import should be removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explain or remove mystery import in Unsafe.Coerce","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`Unsafe.Coerce` has the line\r\n\r\n{{{#!hs\r\nimport GHC.Integer () -- for build ordering\r\n}}}\r\n\r\nIt is not at all clear to me why build ordering demands that `GHC.Integer` be compiled before `Unsafe.Coerce` when the latter uses no numeric literals, no arithmetic, and no numeric types. If there's a real reason for this, the comment should be expanded. Otherwise, the import should be removed.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15525Unicode 8.0 and later characters are invariably lexical errors2019-07-07T18:04:18ZChaiTRexUnicode 8.0 and later characters are invariably lexical errorsI've tried a few added alphabet characters and emojis from various Unicode versions. It seems like Unicode 7.0 works fine. It seems like characters from Unicode 8.0 and later are lexical errors.
For example, with the Unicode 10.0 [T. re...I've tried a few added alphabet characters and emojis from various Unicode versions. It seems like Unicode 7.0 works fine. It seems like characters from Unicode 8.0 and later are lexical errors.
For example, with the Unicode 10.0 [T. rex emoji](https://emojipedia.org/t-rex/), there are three lexical errors below:
```hs
module NoTRex where
tRex :: String
tRex = "🦖"
🦖 :: String
🦖 = "🦖"
```
produces:
```
[1 of 1] Compiling NoTRex ( NoTRex.hs, NoTRex.o )
NoTRex.hs:4:9: error:
lexical error in string/character literal at character '\129430'
|
4 | tRex = "🦖"
| ^
```
If that's removed, the name of the function `🦖` is also shown to be a lexical error.
Also, pasting the fourth line into GHCi pastes only the characters before the first `🦖`, like the `🦖` and everything afterward weren't pasted in.
----
System information:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.3
$ lsb_release -ds
Ubuntu 16.04.5 LTS
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unicode 8.0 and later characters are invariably lexical errors","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried a few added alphabet characters and emojis from various Unicode versions. It seems like Unicode 7.0 works fine. It seems like characters from Unicode 8.0 and later are lexical errors.\r\n\r\nFor example, with the Unicode 10.0 [https://emojipedia.org/t-rex/ T. rex emoji], there are three lexical errors below:\r\n\r\n{{{#!hs\r\nmodule NoTRex where\r\n\r\ntRex :: String\r\ntRex = \"🦖\"\r\n\r\n🦖 :: String\r\n🦖 = \"🦖\"\r\n}}}\r\n\r\nproduces:\r\n\r\n{{{\r\n[1 of 1] Compiling NoTRex ( NoTRex.hs, NoTRex.o )\r\n\r\nNoTRex.hs:4:9: error:\r\n lexical error in string/character literal at character '\\129430'\r\n |\r\n4 | tRex = \"🦖\"\r\n | ^\r\n}}}\r\n\r\nIf that's removed, the name of the function `🦖` is also shown to be a lexical error.\r\n\r\nAlso, pasting the fourth line into GHCi pastes only the characters before the first `🦖`, like the `🦖` and everything afterward weren't pasted in.\r\n\r\n----\r\n\r\nSystem information:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.4.3\r\n\r\n$ lsb_release -ds\r\nUbuntu 16.04.5 LTS \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15523GHC Panic on malformed newtype and StrictData2023-04-26T17:43:47ZrdnettoGHC Panic on malformed newtype and StrictDataThe following source causes a panic:
```hs
{-# LANGUAGE StrictData #-}
module Main where
newtype Duration = Foo
data Literal = LitDuration Duration
```
Result:
```
[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/...The following source causes a panic:
```hs
{-# LANGUAGE StrictData #-}
module Main where
newtype Duration = Foo
data Literal = LitDuration Duration
```
Result:
```
[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
mkNewTyConRhs
Foo []
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
If we remove the StrictData pragma, then we get a syntax error as expected:
```
/home/reuben/tcalc/src/Main.hs:3:20: error:
• The constructor of a newtype must have exactly one field
but ‘Foo’ has none
• In the definition of data constructor ‘Foo’
In the newtype declaration for ‘Duration’
|
3 | newtype Duration = Foo
| ^^^
```
I was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected.
A test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch).
<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":"GHC Panic on malformed newtype and StrictData","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 following source causes a panic:\r\n{{{#!hs\r\n{-# LANGUAGE StrictData #-}\r\n\r\nmodule Main where\r\n\r\nnewtype Duration = Foo\r\ndata Literal = LitDuration Duration\r\n}}}\r\n\r\nResult:\r\n{{{\r\n[1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n mkNewTyConRhs\r\n Foo []\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nIf we remove the StrictData pragma, then we get a syntax error as expected:\r\n{{{\r\n/home/reuben/tcalc/src/Main.hs:3:20: error:\r\n • The constructor of a newtype must have exactly one field\r\n but ‘Foo’ has none\r\n • In the definition of data constructor ‘Foo’\r\n In the newtype declaration for ‘Duration’\r\n |\r\n3 | newtype Duration = Foo\r\n | ^^^\r\n}}}\r\n\r\nI was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected.\r\n\r\nA test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15520Invalid warning Defined but not used2019-07-07T18:04:19ZRik van der KleijInvalid warning Defined but not usedThis code gives warning:
Defined but not used: data constructor ‘:+++’
```hs
data U = Text :+++ Text
x :: U
x = "ss" :+++ "ss"
```
Also In prefix notation .
<details><summary>Trac metadata</summary>
| Trac field | Value...This code gives warning:
Defined but not used: data constructor ‘:+++’
```hs
data U = Text :+++ Text
x :: U
x = "ss" :+++ "ss"
```
Also In prefix notation .
<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":"Invalid warning Defined but not used","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":"This code gives warning: \r\n Defined but not used: data constructor ‘:+++’\r\n\r\n{{{#!hs\r\ndata U = Text :+++ Text\r\n\r\nx :: U\r\nx = \"ss\" :+++ \"ss\"\r\n}}}\r\n\r\nAlso In prefix notation .","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15519Minor code refactoring leads to drastic performance degradation2021-01-23T12:12:06Zdanilo2Minor code refactoring leads to drastic performance degradationHi!
I've just observed an important performance problem. This code:
```
test0 :: Text -> Result
test0 src = let
s1 = token 't'
s2 = token 'e'
s3 = token 's'
s4 = token 't'
p = many $! s1 <> s2 <> s3 <> s4
in run...Hi!
I've just observed an important performance problem. This code:
```
test0 :: Text -> Result
test0 src = let
s1 = token 't'
s2 = token 'e'
s3 = token 's'
s4 = token 't'
p = many $! s1 <> s2 <> s3 <> s4
in runTokenParser p src
{-# NOINLINE test0 #-}
```
runs over 10 times faster than this one:
```
testGrammar1 :: Grammar Char
testGrammar1 = let
s1 = token 't'
s2 = token 'e'
s3 = token 's'
s4 = token 't'
in many $! s1 <> s2 <> s3 <> s4
{-# INLINE testGrammar1 #-}
test1 :: Text -> Result
test1 = runTokenParser testGrammar1
{-# NOINLINE test1 #-}
```
I've also observed another thing here, namely the former code runs also over 10 times faster than this code:
```
test2 :: Text -> Result
test2 src = let
s1 = token 't'
s2 = token 'e'
s3 = token 's'
s4 = token 't'
p = X $! many $! s1 <> s2 <> s3 <> s4
in runTokenParser p src
{-# NOINLINE test2 #-}
```
The only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`.
I've created sample project for it here: https://github.com/wdanilo/ghc-bug-peg-optimization/blob/master/src/Main.hs
In order to run it execute `stack build --exec test`.
The results are:
```
benchmarking test0
time 420.0 μs (417.6 μs .. 422.9 μs)
1.000 R² (0.999 R² .. 1.000 R²)
mean 421.0 μs (419.2 μs .. 425.3 μs)
std dev 9.286 μs (4.239 μs .. 15.30 μs)
variance introduced by outliers: 14% (moderately inflated)
benchmarking test1
time 6.069 ms (6.022 ms .. 6.123 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 6.065 ms (6.037 ms .. 6.117 ms)
std dev 114.5 μs (74.30 μs .. 183.4 μs)
benchmarking test2
time 6.070 ms (6.007 ms .. 6.137 ms)
0.999 R² (0.998 R² .. 1.000 R²)
mean 6.067 ms (6.039 ms .. 6.129 ms)
std dev 123.0 μs (63.88 μs .. 220.1 μs)
benchmarking native
time 428.0 μs (421.5 μs .. 437.4 μs)
0.998 R² (0.995 R² .. 1.000 R²)
mean 427.1 μs (424.1 μs .. 434.7 μs)
std dev 15.18 μs (5.678 μs .. 26.26 μs)
variance introduced by outliers: 29% (moderately inflated)
```
Where "native" is just standard `Text.takeWhile ...`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Minor code refactoring leads to drastic performance degradation","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":"Hi!\r\nI've just observed an important performance problem. This code:\r\n\r\n{{{\r\ntest0 :: Text -> Result\r\ntest0 src = let\r\n s1 = token 't'\r\n s2 = token 'e'\r\n s3 = token 's'\r\n s4 = token 't'\r\n p = many $! s1 <> s2 <> s3 <> s4\r\n in runTokenParser p src\r\n{-# NOINLINE test0 #-}\r\n}}}\r\n\r\nruns over 10 times faster than this one:\r\n\r\n{{{\r\ntestGrammar1 :: Grammar Char\r\ntestGrammar1 = let\r\n s1 = token 't'\r\n s2 = token 'e'\r\n s3 = token 's'\r\n s4 = token 't'\r\n in many $! s1 <> s2 <> s3 <> s4\r\n{-# INLINE testGrammar1 #-}\r\n\r\ntest1 :: Text -> Result\r\ntest1 = runTokenParser testGrammar1\r\n{-# NOINLINE test1 #-}\r\n}}}\r\n\r\nI've also observed another thing here, namely the former code runs also over 10 times faster than this code: \r\n\r\n{{{\r\ntest2 :: Text -> Result\r\ntest2 src = let\r\n s1 = token 't'\r\n s2 = token 'e'\r\n s3 = token 's'\r\n s4 = token 't'\r\n p = X $! many $! s1 <> s2 <> s3 <> s4\r\n in runTokenParser p src\r\n{-# NOINLINE test2 #-}\r\n}}}\r\n\r\nThe only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`.\r\n\r\nI've created sample project for it here: https://github.com/wdanilo/ghc-bug-peg-optimization/blob/master/src/Main.hs\r\n\r\nIn order to run it execute `stack build --exec test`.\r\n\r\nThe results are:\r\n\r\n{{{\r\nbenchmarking test0\r\ntime 420.0 μs (417.6 μs .. 422.9 μs)\r\n 1.000 R² (0.999 R² .. 1.000 R²)\r\nmean 421.0 μs (419.2 μs .. 425.3 μs)\r\nstd dev 9.286 μs (4.239 μs .. 15.30 μs)\r\nvariance introduced by outliers: 14% (moderately inflated)\r\n\r\nbenchmarking test1\r\ntime 6.069 ms (6.022 ms .. 6.123 ms)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 6.065 ms (6.037 ms .. 6.117 ms)\r\nstd dev 114.5 μs (74.30 μs .. 183.4 μs)\r\n\r\nbenchmarking test2\r\ntime 6.070 ms (6.007 ms .. 6.137 ms)\r\n 0.999 R² (0.998 R² .. 1.000 R²)\r\nmean 6.067 ms (6.039 ms .. 6.129 ms)\r\nstd dev 123.0 μs (63.88 μs .. 220.1 μs)\r\n\r\nbenchmarking native\r\ntime 428.0 μs (421.5 μs .. 437.4 μs)\r\n 0.998 R² (0.995 R² .. 1.000 R²)\r\nmean 427.1 μs (424.1 μs .. 434.7 μs)\r\nstd dev 15.18 μs (5.678 μs .. 26.26 μs)\r\nvariance introduced by outliers: 29% (moderately inflated)\r\n}}}\r\n\r\nWhere \"native\" is just standard `Text.takeWhile ...`.","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1