GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-01-23T19:18:02Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15322`KnownNat` does not imply `Typeable` any more when used with plugin2020-01-23T19:18:02ZDmitrii Kovanikov`KnownNat` does not imply `Typeable` any more when used with pluginI have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeOperators #-}
{-# OPTIONS_GHC -fplugin...I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeOperators #-}
{-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-}
module Nats where
import Data.Proxy (Proxy (..))
import Data.Typeable (Typeable)
import GHC.TypeLits (KnownNat, type (+))
f :: forall n . (Typeable n, KnownNat n) => Proxy n -> ()
f _ = ()
f _ = f (Proxy :: Proxy (n + 1))
```
When I try to compile this code I observe the following error message:
```
• Could not deduce (Typeable (n + 1)) arising from a use of ‘f’
from the context: (Typeable n, KnownNat n)
bound by the type signature for:
f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat).
(Typeable n, KnownNat n) =>
Proxy n -> ()
at src/Nats.hs:13:1-57
• In the expression: f (Proxy :: Proxy (n + 1))
In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1))
|
15 | f _ = f (Proxy :: Proxy (n + 1))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug).
Originally reported at Github for `ghc-typelits-knownnat` package:
- https://github.com/clash-lang/ghc-typelits-knownnat/issues/21
`ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`.
<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":"`KnownNat` does not imply `Typeable` any more when used with plugin","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["typeable,knownnat"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n\r\n{-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-}\r\n\r\nmodule Nats where\r\n\r\nimport Data.Proxy (Proxy (..))\r\nimport Data.Typeable (Typeable)\r\nimport GHC.TypeLits (KnownNat, type (+))\r\n\r\nf :: forall n . (Typeable n, KnownNat n) => Proxy n -> ()\r\nf _ = ()\r\nf _ = f (Proxy :: Proxy (n + 1))\r\n}}}\r\n\r\nWhen I try to compile this code I observe the following error message:\r\n\r\n{{{\r\n • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’\r\n from the context: (Typeable n, KnownNat n)\r\n bound by the type signature for:\r\n f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat).\r\n (Typeable n, KnownNat n) =>\r\n Proxy n -> ()\r\n at src/Nats.hs:13:1-57\r\n • In the expression: f (Proxy :: Proxy (n + 1))\r\n In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1))\r\n |\r\n15 | f _ = f (Proxy :: Proxy (n + 1))\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n\r\n}}}\r\n\r\nThis code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug).\r\n\r\nOriginally reported at Github for `ghc-typelits-knownnat` package:\r\n\r\n* https://github.com/clash-lang/ghc-typelits-knownnat/issues/21\r\n\r\n`ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15320Save the types in the typechecked syntax tree2020-08-12T17:06:22ZnboldiSave the types in the typechecked syntax treeWhen working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).
I found that the lack of this semantic info...When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).
I found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help.
The type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly.
It could be implemented nicely by adding type information to the `X* GhcTc` type families.
I plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction.
<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":"Save the types in the typechecked syntax tree","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":"FeatureRequest","description":"When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).\r\n\r\nI found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help.\r\n\r\nThe type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly.\r\n\r\nIt could be implemented nicely by adding type information to the `X* GhcTc` type families.\r\n\r\nI plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15313Framework failures on windows with plugins2021-06-21T09:37:33ZSimon Peyton JonesFramework failures on windows with pluginsOn Windows, when the load is heavy (i.e. when doing a full `sh validate` I get a bunch of framework failures in the `plugins/` testsuite directory
```
Framework failures:
plugins/plugins07.run plugins07 [normal] (pre_cmd ...On Windows, when the load is heavy (i.e. when doing a full `sh validate` I get a bunch of framework failures in the `plugins/` testsuite directory
```
Framework failures:
plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2)
plugins/T10420.run T10420 [normal] (pre_cmd failed: 2)
plugins/T11244.run T11244 [normal] (pre_cmd failed: 2)
plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2)
plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2)
plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2)
```
I sent a full log to Tamar who said:
Thanks for the log, that does give a clue. The command fails with
```
setup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error:
...
rule-defining-plugin-0.1: cannot find any of
["libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib","HSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll"]
on library path (use --force to override)
make[2]: *** [Makefile:18: package.T10420] Error 1
```
so it's the `setup install` from https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/testsuite/tests/plugins/rule-defining-plugin/Makefile failing.
Unfortunately, all those tests run with -v0 which is annoying because now the verbosity of the testsuite doesn't control that of these tests. I'm not sure why these commands fail under heavy load though.
I'll need to dive into the source of ghc-pkg to figure out what's happening.
Notice that all the framework failures are these plugin tests which modify a package database. A wild guess is that `ghc-pkg` tries to take a lock on all package-databases or something when it's mutating one. But I'm not intimately familiar with the package store and this doesn't explain why it doesn't happen on Linux.
For now one solution I can propose is to create a ticket to track these and mark these tests as cpu multirace on Windows.
<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":"Framework failures on windows with plugins","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":"On Windows, when the load is heavy (i.e. when doing a full `sh validate` I get a bunch of framework failures in the `plugins/` testsuite directory\r\n{{{\r\nFramework failures:\r\n plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2)\r\n plugins/T10420.run T10420 [normal] (pre_cmd failed: 2)\r\n plugins/T11244.run T11244 [normal] (pre_cmd failed: 2)\r\n plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2)\r\n plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2)\r\n plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2)\r\n}}}\r\nI sent a full log to Tamar who said: \r\nThanks for the log, that does give a clue. The command fails with\r\n{{{\r\nsetup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error:\r\n...\r\nrule-defining-plugin-0.1: cannot find any of\r\n[\"libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a\",\"libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a\",\"libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so\",\"libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib\",\"HSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll\"]\r\non library path (use --force to override)\r\n\r\nmake[2]: *** [Makefile:18: package.T10420] Error 1\r\n}}}\r\nso it's the `setup install` from https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/testsuite/tests/plugins/rule-defining-plugin/Makefile failing.\r\n\r\nUnfortunately, all those tests run with -v0 which is annoying because now the verbosity of the testsuite doesn't control that of these tests. I'm not sure why these commands fail under heavy load though.\r\nI'll need to dive into the source of ghc-pkg to figure out what's happening. \r\n\r\nNotice that all the framework failures are these plugin tests which modify a package database. A wild guess is that `ghc-pkg` tries to take a lock on all package-databases or something when it's mutating one. But I'm not intimately familiar with the package store and this doesn't explain why it doesn't happen on Linux.\r\n\r\nFor now one solution I can propose is to create a ticket to track these and mark these tests as cpu multirace on Windows.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15312getChanContents exception behavior seems a bit odd2020-01-23T19:18:03ZDavid FeuergetChanContents exception behavior seems a bit oddI've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:
```hs
-- Bug.hs
import Control.Concurrent (forkIO, yield)
import Control.Concurrent.Chan
import Data.List (elem)
import Control.Exception
import C...I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:
```hs
-- Bug.hs
import Control.Concurrent (forkIO, yield)
import Control.Concurrent.Chan
import Data.List (elem)
import Control.Exception
import Control.Concurrent.MVar
data Ex = Ex deriving Show
instance Exception Ex
main = do
ch <- newChan
sync1 <- newEmptyMVar
sync2 <- newEmptyMVar
forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()}
yield
writeChan ch (-12)
cont <- getChanContents ch
tid <- forkIO $ do
evaluate (last cont)
putMVar sync2 ()
yield
throwTo tid Ex
print (elem (3*10^6) cont)
takeMVar sync1
tryTakeMVar sync2
```
When I run this single-threaded (`+RTS -N1`), it prints
```
Bug: Ex
Bug: Ex
```
One of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getChanContents exception behavior seems a bit odd","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off:\r\n\r\n{{{#!hs\r\n-- Bug.hs\r\nimport Control.Concurrent (forkIO, yield)\r\nimport Control.Concurrent.Chan\r\nimport Data.List (elem)\r\nimport Control.Exception\r\nimport Control.Concurrent.MVar\r\n\r\ndata Ex = Ex deriving Show\r\ninstance Exception Ex\r\n\r\nmain = do\r\n ch <- newChan\r\n sync1 <- newEmptyMVar\r\n sync2 <- newEmptyMVar\r\n forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()}\r\n yield\r\n writeChan ch (-12)\r\n cont <- getChanContents ch\r\n\r\n tid <- forkIO $ do\r\n evaluate (last cont)\r\n putMVar sync2 ()\r\n\r\n yield\r\n throwTo tid Ex\r\n\r\n\r\n print (elem (3*10^6) cont)\r\n takeMVar sync1\r\n tryTakeMVar sync2\r\n}}}\r\n\r\nWhen I run this single-threaded (`+RTS -N1`), it prints\r\n\r\n{{{\r\nBug: Ex\r\nBug: Ex\r\n}}}\r\n\r\nOne of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15309mkLHsOpTy is discarding API Annotations2020-01-23T19:18:02ZAlan ZimmermanmkLHsOpTy is discarding API AnnotationsFor
```hs
ft :: (->) a b
```
the `AnnRarrow` API annotation is discarded.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 ...For
```hs
ft :: (->) a b
```
the `AnnRarrow` API annotation is discarded.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"mkLHsOpTy is discarding API Annotations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For\r\n\r\n{{{#!hs\r\nft :: (->) a b\r\n}}}\r\n\r\nthe `AnnRarrow` API annotation is discarded.","type_of_failure":"OtherFailure","blocking":[]} -->Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15298Support spliced function names in type signatures in TH declaration quotes2024-03-04T20:10:03ZNathan CollinsSupport spliced function names in type signatures in TH declaration quotesThere doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work.
According to [this StackOverflow answer](https://stackoverflow.co...There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work.
According to [this StackOverflow answer](https://stackoverflow.com/a/32279198/470844), the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`.
```hs
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
fName :: Name
fName = mkName "f"
fTy :: TypeQ
fTy = [t| Int |]
fBody :: ExpQ
fBody = [e| 3 |]
-- | Not allowed:
--
-- @
-- error:
-- Invalid type signature: $fName :: ...
-- Should be of form <variable> :: <type>
-- @
--
-- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous
-- error.
fDecl1 :: DecsQ
fDecl1 = [d| $fName :: $fTy
$(varP fName) = $fBody |]
-- | Not allowed:
--
-- @
-- error:
-- Splices within declaration brackets not (yet) handled by Template Haskell
-- @
fDecl2 :: DecsQ
fDecl2 = [d| $((:[]) <$> sigD fName fTy)
$(varP fName) = $fBody |]
```
<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 | #11129 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support spliced function names in type signatures in TH declaration quotes","status":"New","operating_system":"","component":"Compiler","related":[11129],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work.\r\n\r\nAccording to [https://stackoverflow.com/a/32279198/470844 this StackOverflow answer], the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nimport Language.Haskell.TH\r\n\r\nfName :: Name\r\nfName = mkName \"f\"\r\n\r\nfTy :: TypeQ\r\nfTy = [t| Int |]\r\n\r\nfBody :: ExpQ\r\nfBody = [e| 3 |]\r\n\r\n-- | Not allowed:\r\n--\r\n-- @\r\n-- error:\r\n-- Invalid type signature: $fName :: ...\r\n-- Should be of form <variable> :: <type>\r\n-- @\r\n--\r\n-- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous\r\n-- error.\r\nfDecl1 :: DecsQ\r\nfDecl1 = [d| $fName :: $fTy\r\n $(varP fName) = $fBody |]\r\n\r\n-- | Not allowed:\r\n--\r\n-- @\r\n-- error:\r\n-- Splices within declaration brackets not (yet) handled by Template Haskell\r\n-- @\r\nfDecl2 :: DecsQ\r\nfDecl2 = [d| $((:[]) <$> sigD fName fTy)\r\n $(varP fName) = $fBody |]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15297Add support for insert, extract and broadcast SIMD instructions for native X8...2020-01-23T19:18:02ZJohn KyAdd support for insert, extract and broadcast SIMD instructions for native X86 codegen<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure ...<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":"Add support for insert, extract and broadcast SIMD instructions for native X86 codegen","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":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15295Haddock options should be concatenated2020-01-23T19:18:03ZSimon JakobiHaddock options should be concatenatedCurrently we have the following situation:
1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock-opts` are ignored
1. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered.
Instead all opt...Currently we have the following situation:
1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock-opts` are ignored
1. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered.
Instead all options should be concatenated (with `, `), with the CLI options at the end.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alexbiehl, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haddock options should be concatened","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["haddock"],"differentials":[],"test_case":"","architecture":"","cc":["alexbiehl","hvr"],"type":"Bug","description":"Currently we have the following situation:\r\n\r\n1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock-opts` are ignored\r\n2. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered.\r\n\r\nInstead all options should be concatenated (with `, `), with the CLI options at the end.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15291Incorrect SCC name parsing according to user manual2020-01-23T19:18:02ZÖmer Sinan AğacanIncorrect SCC name parsing according to user manualThe user manual says this about SCC names:
> The syntax of a cost centre annotation for expressions is
>
> {-\# SCC "name" \#-} \<expression\>
>
> where "name" is an arbitrary string, that will become the name of your cost centre as it ...The user manual says this about SCC names:
> The syntax of a cost centre annotation for expressions is
>
> {-\# SCC "name" \#-} \<expression\>
>
> where "name" is an arbitrary string, that will become the name of your cost centre as it appears in the profiling output, and \<expression\> is any Haskell expression.
However GHC is actually more strict about SCC strings, for example, it doesn't accept spaces:
```
$ cat test.hs
main = {-# SCC "test test" #-} return ()
$ ghc test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
test.hs:1:16: error: Spaces are not allowed in SCCs
|
1 | main = {-# SCC "test test" #-} return ()
| ^^^^^^^^^^^
```
It's also possible that GHC is right and user manual is wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect SCC name parsing according to user manual","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The user manual says this about SCC names:\r\n\r\n> The syntax of a cost centre annotation for expressions is\r\n> \r\n> {-# SCC \"name\" #-} <expression>\r\n> \r\n> where \"name\" is an arbitrary string, that will become the name of your cost centre as it appears in the profiling output, and <expression> is any Haskell expression.\r\n\r\nHowever GHC is actually more strict about SCC strings, for example, it doesn't accept spaces:\r\n\r\n{{{\r\n$ cat test.hs\r\nmain = {-# SCC \"test test\" #-} return ()\r\n\r\n$ ghc test.hs\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\n\r\ntest.hs:1:16: error: Spaces are not allowed in SCCs\r\n |\r\n1 | main = {-# SCC \"test test\" #-} return ()\r\n | ^^^^^^^^^^^\r\n}}}\r\n\r\nIt's also possible that GHC is right and user manual is wrong.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15283Locale issue in the testsuite2020-07-21T15:47:03ZSylvain HenryLocale issue in the testsuiteWith a French locale (LANG=fr_FR.utf-8), `make TEST=T14999` fails with:
```patch
End of assembler dump.
-Contents of the .debug_frame section:
+Contenu de la section .debug_frame :
00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ...With a French locale (LANG=fr_FR.utf-8), `make TEST=T14999` fails with:
```patch
End of assembler dump.
-Contents of the .debug_frame section:
+Contenu de la section .debug_frame :
00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16
LOC CFA rbp rsp ra
```
But it passes with `LANG=C make TEST=T14999`.
Should we enforce the locale for the whole testsuite or only for this test?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Locale issue in the testsuite","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"With a French locale (LANG=fr_FR.utf-8), `make TEST=T14999` fails with:\r\n\r\n{{{#!patch\r\n End of assembler dump.\r\n-Contents of the .debug_frame section:\r\n+Contenu de la section .debug_frame :\r\n 00000000 0000000000000014 ffffffff CIE \"\" cf=1 df=-8 ra=16\r\n LOC CFA rbp rsp ra \r\n}}}\r\n\r\nBut it passes with `LANG=C make TEST=T14999`.\r\n\r\nShould we enforce the locale for the whole testsuite or only for this test?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15272Handle implied flags more intuitively2021-08-13T13:15:06ZTobias Dammerstdammers@gmail.comHandle implied flags more intuitivelyMany flags in GHC imply other flags. For example, enabling `-fdefer-type-errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope-variables`:
```
GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help
Prelude> :set
opt...Many flags in GHC imply other flags. For example, enabling `-fdefer-type-errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope-variables`:
```
GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help
Prelude> :set
options currently set: none.
base language is: Haskell2010
with the following modifiers:
-XNoDatatypeContexts
-XNondecreasingIndentation
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fignore-optim-changes
-fignore-hpc-changes
-fimplicit-import-qualified
warning settings:
Prelude> :set -fdefer-type
-fdefer-type-errors -fdefer-typed-holes
Prelude> :set -fdefer-type-errors
Prelude> :set
options currently set: none.
base language is: Haskell2010
with the following modifiers:
-XNoDatatypeContexts
-XNondecreasingIndentation
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fdefer-type-errors
-fdefer-typed-holes
-fdefer-out-of-scope-variables
-fignore-optim-changes
-fignore-hpc-changes
-fimplicit-import-qualified
warning settings:
```
This is fine.
Disabling previously enabled flags does not disable the implied flags: `-fno-defer-type-errors` does not also set `-fno-defer-type-holes` and `-fno-defer-out-of-scope-variables`. This is also fine in principle; otherwise, setting `-fdefer-type-holes -fno-defer-type-errors` would do the unintuitive thing of setting neither flag.
But it does lead to unintuitive behavior when the implied flags have never been touched explicitly: setting `-fdefer-type-errors`, and then later `-fno-defer-type-errors`, leaves `-fdefer-type-holes` and `-fdefer-out-of-scope-variables` set, even though the user never asked for them:
```
Prelude> :set -fdefer-type-errors
Prelude> :set
options currently set: none.
base language is: Haskell2010
with the following modifiers:
-XNoDatatypeContexts
-XNondecreasingIndentation
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fdefer-type-errors
-fdefer-typed-holes
-fdefer-out-of-scope-variables
-fignore-optim-changes
-fignore-hpc-changes
-fimplicit-import-qualified
warning settings:
Prelude> :set -fno-defer-type-errors
Prelude> :set
options currently set: none.
base language is: Haskell2010
with the following modifiers:
-XNoDatatypeContexts
-XNondecreasingIndentation
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fdefer-typed-holes <- These two are
-fdefer-out-of-scope-variables <- unexpected!
-fignore-optim-changes
-fignore-hpc-changes
-fimplicit-import-qualified
warning settings:
```
So we have a conundrum: when unsetting a flag, we may or may not need to unset the options it implies - neither is always correct, so in order to figure out what to do, we need to know \*why\* the flag was set. But it's even worse: if we have a flag X, and two other flags A and B, both of which imply X, and we first set A and B, and then unset B, we would have to keep X set, because otherwise we would break A. But if we then also unset A, we would have to also unset X. Tracking which option implicitly enabled which other option, and correctly resolving that, seems like terribly messy business. So I propose a different solution:
1. Maintain one set of `DynFlags` that holds only those flags that were requested explicitly. Setting `-fdefer-type-errors` would only set `Opt_DeferTypeErrors` in this set, but none of the implied flags; and `-fno-defer-type-errors` would simply unset `Opt_DeferTypeErrors`.
1. Maintain another set of `DynFlags` that holds the effective flags: we can always calculate these based on the explicit flags. We could either do this on the fly, just before running the actual compilation / evaluation, or we could keep the data structure around and only update it when the explicit flags have changed.
This way, setting and unsetting flags will always do the right thing, and we don't throw away the information about which flags were set explicitly.
This is probably more relevant in GHCi, because in plain GHC, one would typically just set all the needed flags at once and then never change them again until the next run; but in GHCi, modifying compiler flags between evaluations is a common thing to do.
<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":"Handle implied flags more intuitively","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":"FeatureRequest","description":"Many flags in GHC imply other flags. For example, enabling `-fdefer-type-errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope-variables`:\r\n\r\n{{{\r\nGHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set\r\noptions currently set: none.\r\nbase language is: Haskell2010\r\nwith the following modifiers:\r\n -XNoDatatypeContexts\r\n -XNondecreasingIndentation\r\nGHCi-specific dynamic flag settings:\r\nother dynamic, non-language, flag settings:\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fimplicit-import-qualified\r\nwarning settings:\r\nPrelude> :set -fdefer-type\r\n-fdefer-type-errors -fdefer-typed-holes\r\nPrelude> :set -fdefer-type-errors\r\nPrelude> :set\r\noptions currently set: none.\r\nbase language is: Haskell2010\r\nwith the following modifiers:\r\n -XNoDatatypeContexts\r\n -XNondecreasingIndentation\r\nGHCi-specific dynamic flag settings:\r\nother dynamic, non-language, flag settings:\r\n -fdefer-type-errors\r\n -fdefer-typed-holes\r\n -fdefer-out-of-scope-variables\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fimplicit-import-qualified\r\nwarning settings:\r\n}}}\r\n\r\nThis is fine.\r\n\r\nDisabling previously enabled flags does not disable the implied flags: `-fno-defer-type-errors` does not also set `-fno-defer-type-holes` and `-fno-defer-out-of-scope-variables`. This is also fine in principle; otherwise, setting `-fdefer-type-holes -fno-defer-type-errors` would do the unintuitive thing of setting neither flag.\r\n\r\nBut it does lead to unintuitive behavior when the implied flags have never been touched explicitly: setting `-fdefer-type-errors`, and then later `-fno-defer-type-errors`, leaves `-fdefer-type-holes` and `-fdefer-out-of-scope-variables` set, even though the user never asked for them:\r\n\r\n{{{\r\nPrelude> :set -fdefer-type-errors\r\nPrelude> :set\r\noptions currently set: none.\r\nbase language is: Haskell2010\r\nwith the following modifiers:\r\n -XNoDatatypeContexts\r\n -XNondecreasingIndentation\r\nGHCi-specific dynamic flag settings:\r\nother dynamic, non-language, flag settings:\r\n -fdefer-type-errors\r\n -fdefer-typed-holes\r\n -fdefer-out-of-scope-variables\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fimplicit-import-qualified\r\nwarning settings:\r\nPrelude> :set -fno-defer-type-errors\r\nPrelude> :set\r\noptions currently set: none.\r\nbase language is: Haskell2010\r\nwith the following modifiers:\r\n -XNoDatatypeContexts\r\n -XNondecreasingIndentation\r\nGHCi-specific dynamic flag settings:\r\nother dynamic, non-language, flag settings:\r\n -fdefer-typed-holes <- These two are\r\n -fdefer-out-of-scope-variables <- unexpected!\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fimplicit-import-qualified\r\nwarning settings:\r\n}}}\r\n\r\nSo we have a conundrum: when unsetting a flag, we may or may not need to unset the options it implies - neither is always correct, so in order to figure out what to do, we need to know *why* the flag was set. But it's even worse: if we have a flag X, and two other flags A and B, both of which imply X, and we first set A and B, and then unset B, we would have to keep X set, because otherwise we would break A. But if we then also unset A, we would have to also unset X. Tracking which option implicitly enabled which other option, and correctly resolving that, seems like terribly messy business. So I propose a different solution:\r\n\r\n1. Maintain one set of `DynFlags` that holds only those flags that were requested explicitly. Setting `-fdefer-type-errors` would only set `Opt_DeferTypeErrors` in this set, but none of the implied flags; and `-fno-defer-type-errors` would simply unset `Opt_DeferTypeErrors`.\r\n2. Maintain another set of `DynFlags` that holds the effective flags: we can always calculate these based on the explicit flags. We could either do this on the fly, just before running the actual compilation / evaluation, or we could keep the data structure around and only update it when the explicit flags have changed.\r\n\r\nThis way, setting and unsetting flags will always do the right thing, and we don't throw away the information about which flags were set explicitly.\r\n\r\n\r\nThis is probably more relevant in GHCi, because in plain GHC, one would typically just set all the needed flags at once and then never change them again until the next run; but in GHCi, modifying compiler flags between evaluations is a common thing to do.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15270TH doesn't verify name types during conversion2020-01-23T19:20:24ZBen GamariTH doesn't verify name types during conversionAngerman reported that a use of the [\`deriveEq\`](http://hackage.haskell.org/package/deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1) splice is causing GHC to abort with an assertion failure:
```hs
zonkExpr env ...Angerman reported that a use of the [\`deriveEq\`](http://hackage.haskell.org/package/deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1) splice is causing GHC to abort with an assertion failure:
```hs
zonkExpr env (HsVar x (L l id))
= ASSERT2( isNothing (isDataConId_maybe id), ppr id )
return (HsVar x (L l (zonkIdOcc env id)))
```
I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message.https://gitlab.haskell.org/ghc/ghc/-/issues/15267Extend TVar/MVar to N capacity / Add primitive channel type2021-09-07T15:18:33ZwinterExtend TVar/MVar to N capacity / Add primitive channel typeThe current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channe...The current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channel, semaphore, resource pool, etc. For example current [semaphore's implementation](http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurrent.QSem.html#signalQSem) is not ideal due to the extensive usage of multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can be easily implemented with `BoundedChan ()`.
Currently we have various bound channel implementations, but these implementations are often not very efficient or too complex. For example the `BoundedChan` from [BoundedChan](http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control-Concurrent-BoundedChan.html) is based on an array of `MVar` s, thus consumes much more memory than a primitve channel which only have to record parked `StgTSO` s.
I'm thinking adding something like:
```
typedef struct {
StgHeader header;
struct StgMVarTSOQueue_ *head;
struct StgMVarTSOQueue_ *tail;
StgInt capacity; // the channel's capacity
StgInt read_index; // the reading end's index
StgInt write_index; // the writing end's index
StgClosure *payload[]; // payload array in continuous memory
} StgMChan;
```
I still can't work out all the details, but I'm confident something similar to this will work.https://gitlab.haskell.org/ghc/ghc/-/issues/15258Implement CMOV support.2021-11-20T11:36:59ZAndreas KlebingerImplement CMOV support.<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure |...<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":"Implement CMOV support.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["CodeGen"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"","type_of_failure":"OtherFailure","blocking":[]} -->Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/15257Broken symlinks in lndir build tree2020-01-23T19:20:23ZAdam GundryBroken symlinks in lndir build treeI routinely create separate build trees using lndir (per wiki:WorkingConventions/Git\#Creatingabuildtreewithlndir). However it seems this is currently broken by the code to copy `fs.{c,h}` to various places in `./configure` (see [D4416](...I routinely create separate build trees using lndir (per wiki:WorkingConventions/Git\#Creatingabuildtreewithlndir). However it seems this is currently broken by the code to copy `fs.{c,h}` to various places in `./configure` (see [D4416](https://phabricator.haskell.org/D4416)):
```
$ mkdir ghc-validate
$ cd ghc-validate
$ lndir ../ghc
$ ln -s ../ghc/.git
$ ./boot
[...]
$ ./configure
[...]
$ find . -name "fs.*" | xargs file
./rts/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c
./rts/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h
./utils/fs/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c
./utils/fs/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h
./utils/unlit/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c
./utils/unlit/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h
./utils/lndir/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c
./utils/lndir/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h
./libraries/base/include/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h
./libraries/base/cbits/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c
```
This can be fixed by manually correcting the symlinks, but it is a bit of pain, especially for `./validate`.
```
ln -fs ../../ghc/utils/fs/fs.c rts/fs.c
ln -fs ../../ghc/utils/fs/fs.h rts/fs.h
ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/include/fs.c
ln -fs ../../../../ghc/utils/fs/fs.h libraries/base/include/fs.h
ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/cbits/fs.c
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken symlinks in lndir build tree","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I routinely create separate build trees using lndir (per wiki:WorkingConventions/Git#Creatingabuildtreewithlndir). However it seems this is currently broken by the code to copy `fs.{c,h}` to various places in `./configure` (see Phab:D4416):\r\n\r\n{{{\r\n$ mkdir ghc-validate\r\n$ cd ghc-validate\r\n$ lndir ../ghc\r\n$ ln -s ../ghc/.git\r\n$ ./boot\r\n[...]\r\n$ ./configure\r\n[...]\r\n$ find . -name \"fs.*\" | xargs file\r\n./rts/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c\r\n./rts/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h\r\n./utils/fs/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c\r\n./utils/fs/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h\r\n./utils/unlit/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c\r\n./utils/unlit/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h\r\n./utils/lndir/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c\r\n./utils/lndir/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h\r\n./libraries/base/include/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h\r\n./libraries/base/cbits/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c\r\n}}}\r\nThis can be fixed by manually correcting the symlinks, but it is a bit of pain, especially for `./validate`.\r\n{{{\r\nln -fs ../../ghc/utils/fs/fs.c rts/fs.c\r\nln -fs ../../ghc/utils/fs/fs.h rts/fs.h\r\nln -fs ../../../../ghc/utils/fs/fs.c libraries/base/include/fs.c\r\nln -fs ../../../../ghc/utils/fs/fs.h libraries/base/include/fs.h\r\nln -fs ../../../../ghc/utils/fs/fs.c libraries/base/cbits/fs.c\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15256GHCi check .ghci permission on WSL(Linux on Windows)2019-07-07T18:13:36ZyongjoonGHCi check .ghci permission on WSL(Linux on Windows)GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would ...GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would skip .ghci permission check.
I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.
However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.
As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.
Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.
P.S.
Is there any bug-report place only for GHC-WSL? I couldn't find it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi check .ghci permission on WSL(Linux on Windows)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.\r\nYou can reproduce this problem from 8.2.2.~8.4.3 of GHC-WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl).\r\n\r\nI think GHCi of WSL would skip .ghci permission check.\r\n\r\nI used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.\r\n\r\nHowever, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.\r\nAs you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.\r\n\r\nTherefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.\r\n\r\nP.S.\r\nIs there any bug-report place only for GHC-WSL? I couldn't find it.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15253Add support for type-level integers2020-01-23T19:20:23ZchessaiAdd support for type-level integersSimilar to GHC.TypeNats, it would be nice to see something like the following:
```hs
newtype TypeInt (n :: Nat) = TypeInt Integer
class KnownInt (n :: k) where
intSing :: TypeInt n
intVal :: forall n proxy. KnownInt n => proxy n -> ...Similar to GHC.TypeNats, it would be nice to see something like the following:
```hs
newtype TypeInt (n :: Nat) = TypeInt Integer
class KnownInt (n :: k) where
intSing :: TypeInt n
intVal :: forall n proxy. KnownInt n => proxy n -> Integer
intVal _ = case intSing :: TypeInt n of
TypeInt x -> x
intVal' :: forall n. KnownInt n => Proxy# n -> Integer
intVal' _ = case intSing :: TypeInt n of
TypeInt x -> x
```
<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":"Add support for type-level integers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["base","compiler,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Similar to GHC.TypeNats, it would be nice to see something like the following:\r\n\r\n{{{#!hs\r\nnewtype TypeInt (n :: Nat) = TypeInt Integer\r\n\r\nclass KnownInt (n :: k) where\r\n intSing :: TypeInt n\r\n\r\nintVal :: forall n proxy. KnownInt n => proxy n -> Integer\r\nintVal _ = case intSing :: TypeInt n of\r\n TypeInt x -> x\r\n\r\nintVal' :: forall n. KnownInt n => Proxy# n -> Integer\r\nintVal' _ = case intSing :: TypeInt n of\r\n TypeInt x -> x\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15252syn_arg_wraps and syn_res_wrap are only populated after typechecking2022-09-19T19:52:04ZMatthew Pickeringsyn_arg_wraps and syn_res_wrap are only populated after typecheckingThe definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.
```
data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p ...The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.
```
data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p
, syn_arg_wraps :: [HsWrapper]
, syn_res_wrap :: HsWrapper }
```
<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":"syn_arg_wraps and syn_res_wrap are only populated after typechecking","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":"Bug","description":"The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.\r\n\r\n{{{\r\n data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p \r\n , syn_arg_wraps :: [HsWrapper] \r\n , syn_res_wrap :: HsWrapper } \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15251Add support for _mm_shuffle_pi8 intrinsic2020-01-23T19:19:12ZJohn KyAdd support for _mm_shuffle_pi8 intrinsic`!#c
__m64 _mm_shuffle_pi8 (__m64 a, __m64 b)
`
See:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/\#text=_mm_shuffle_pi8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----------...`!#c
__m64 _mm_shuffle_pi8 (__m64 a, __m64 b)
`
See:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/\#text=_mm_shuffle_pi8
<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":"Add support for _mm_shuffle_pi8 intrinsic","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":"{{{!#c\r\n__m64 _mm_shuffle_pi8 (__m64 a, __m64 b)\r\n}}}\r\n\r\nSee:\r\n\r\nhttps://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_shuffle_pi8","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15250Add support for _mm512_shuffle_epi8 intrinsic2020-01-23T19:19:12ZJohn KyAdd support for _mm512_shuffle_epi8 intrinsic```c
__m512i _mm512_shuffle_epi8 (__m512i a, __m512i b)
```
See:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/\#expand=765,3914,2929,4754,4757&text=_mm512_shuffle_epi8
<details><summary>Trac metadata</summary>
| Trac ...```c
__m512i _mm512_shuffle_epi8 (__m512i a, __m512i b)
```
See:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/\#expand=765,3914,2929,4754,4757&text=_mm512_shuffle_epi8
<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":"Add support for _mm512_shuffle_epi8 intrinsic","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":"{{{#!c\r\n__m512i _mm512_shuffle_epi8 (__m512i a, __m512i b)\r\n}}}\r\n\r\nSee:\r\n\r\nhttps://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=765,3914,2929,4754,4757&text=_mm512_shuffle_epi8","type_of_failure":"OtherFailure","blocking":[]} -->