GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:00:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16339Cannot put (.) or (!) type operators into an export list2019-07-07T18:00:27ZRyan ScottCannot put (.) or (!) type operators into an export listThanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:
```hs
type (f . g) x = f (g x)
type x ! f = f x
```
However, I was surprised to discover that it's not possible to put them in an exp...Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:
```hs
type (f . g) x = f (g x)
type x ! f = f x
```
However, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse:
```
{-# LANGUAGE TypeOperators #-}
module Bug (type (.), type (!)) where
type (f . g) x = f (g x)
type x ! f = f x
```
```
$ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs
GHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
Bug.hs:2:19: error: parse error on input ‘.’
|
2 | module Bug (type (.), type (!)) where
| ^
```
This problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place:
```hs
{-# LANGUAGE TypeOperators #-}
module Works (type (&)) where
type (f & g) x = f (g x)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | int-index |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot put (.) or (!) into an export list","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["int-index"],"type":"Bug","description":"Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:\r\n\r\n{{{#!hs\r\ntype (f . g) x = f (g x)\r\ntype x ! f = f x\r\n}}}\r\n\r\nHowever, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse:\r\n\r\n{{{\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Bug (type (.), type (!)) where\r\n\r\ntype (f . g) x = f (g x)\r\ntype x ! f = f x\r\n}}}\r\n{{{\r\n$ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs\r\nGHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n\r\nBug.hs:2:19: error: parse error on input ‘.’\r\n |\r\n2 | module Bug (type (.), type (!)) where\r\n | ^\r\n}}}\r\n\r\nThis problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Works (type (&)) where\r\n\r\ntype (f & g) x = f (g x)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16311Suggest -XExistentialQuantification for 'forall' in data declarations2019-07-07T18:00:34ZVladislav ZavialovSuggest -XExistentialQuantification for 'forall' in data declarations[D5180](https://phabricator.haskell.org/D5180) introduced a slight regression to the error messages. In this code
```hs
data T = forall a. MkT a
```
GHC used to complain
```
rnfail053.hs:5:10:
Not a data constructor: ‘forall’
...[D5180](https://phabricator.haskell.org/D5180) introduced a slight regression to the error messages. In this code
```hs
data T = forall a. MkT a
```
GHC used to complain
```
rnfail053.hs:5:10:
Not a data constructor: ‘forall’
Perhaps you intended to use ExistentialQuantification
```
but then the message has become
```
rnfail053.hs:5:18: error:
Illegal symbol '.' in type
Perhaps you intended to use RankNTypes or a similar language
extension to enable explicit-forall syntax: forall <tvs>. <type>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Suggest -XExistentialQuantification for 'forall' in data declarations","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Phab:D5180 introduced a slight regression to the error messages. In this code\r\n\r\n{{{#!hs\r\ndata T = forall a. MkT a\r\n}}}\r\n\r\nGHC used to complain\r\n\r\n{{{\r\nrnfail053.hs:5:10:\r\n Not a data constructor: ‘forall’\r\n Perhaps you intended to use ExistentialQuantification\r\n}}}\r\n\r\nbut then the message has become\r\n\r\n{{{\r\nrnfail053.hs:5:18: error:\r\n Illegal symbol '.' in type\r\n Perhaps you intended to use RankNTypes or a similar language\r\n extension to enable explicit-forall syntax: forall <tvs>. <type>\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16309Flag to instruct GHC not to use an environment file2019-07-07T18:00:35ZRichard Eisenbergrae@richarde.devFlag to instruct GHC not to use an environment fileAs the [user manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-environments) documents, GHC looks for environment files in the current directory to tell it what packages to look for. There seem...As the [user manual](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-environments) documents, GHC looks for environment files in the current directory to tell it what packages to look for. There seems to be no way to disable this behavior (short of deleting or renaming the environment file). This causes trouble for me, as I expect `ghci` to mean the same thing no matter where I say it.
Can we add a flag (perhaps `-no-package-env`) that tells GHC not to look for an environment file? Note that specifying a dummy package environment file doesn't work because we can't suppress the implicit `-hide-all-packages` that is triggered whenever using a package environment.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.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":"Flag to instruct GHC not to use an environment file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-environments user manual] document, GHC looks for environment files in the current directory to tell it what packages to look for. There seems to be no way to disable this behavior (short of deleting or renaming the environment file). This causes trouble for me, as I expect `ghci` to mean the same thing no matter where I say it.\r\n\r\nCan we add a flag (perhaps `-no-package-env`) that tells GHC not to look for an environment file? Note that specifying a dummy package environment file doesn't work because we can't suppress the implicit `-hide-all-packages` that is triggered whenever using a package environment.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16120Hadrian should use cabal build-tools installed Alex and Happy if necessary2019-07-07T18:01:23ZadamHadrian should use cabal build-tools installed Alex and Happy if necessaryhadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with `-c`
(Migrated from https://github.com/snowleopard/hadrian/issues/706)
<details><summary>Trac metadata<...hadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with `-c`
(Migrated from https://github.com/snowleopard/hadrian/issues/706)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian should use cabal build-tools installed Alex and Happy if necessary","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["snowleopard"],"type":"FeatureRequest","description":"hadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with {{{-c}}}\r\n\r\n(Migrated from https://github.com/snowleopard/hadrian/issues/706)","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15995Make Control.Concurrent.QSem a newtype2019-07-07T18:02:07ZchessaiMake Control.Concurrent.QSem a newtype```hs
data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()]))
```
I think this should be a newtype. The strictness annotations on the outter `MVar` could just be at each site where pattern matching on the `QSem`.
<details><summary>Trac me...```hs
data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()]))
```
I think this should be a newtype. The strictness annotations on the outter `MVar` could just be at each site where pattern matching on the `QSem`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make Control.Concurrent.QSem a newtype","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{#!hs\r\ndata QSem = QSem !(MVar (Int, [MVar ()], [MVar ()]))\r\n}}}\r\n\r\nI think this should be a newtype. The strictness annotations on the outter `MVar` could just be at each site where pattern matching on the `QSem`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15961TH 'Lift' instance for 'NonEmpty'2019-07-07T18:02:16Zfr33domloverTH 'Lift' instance for 'NonEmpty'I was using `deriving Lift` on a data type and the `DeriveLift` extension:
```hs
import Data.List.NonEmpty
import Language.Haskell.TH
data T = T (NonEmpty String) Int deriving Lift
```
and I noticed I couldn't get an automatic instanc...I was using `deriving Lift` on a data type and the `DeriveLift` extension:
```hs
import Data.List.NonEmpty
import Language.Haskell.TH
data T = T (NonEmpty String) Int deriving Lift
```
and I noticed I couldn't get an automatic instance because `NonEmpty` doesn't have a `Lift` instance. I'm wondering if an instance can be added to the `template-haskell` package (or elsewhere if that isn't the right place? I'm assuming it is because `NonEmpty` is in `base` now)
Since `NonEmpty` has a `Data` instance, I suppose the following would be enough?
```hs
instance Data a => Lift (NonEmpty a)
```
And without using `Data` it could be:
```hs
nonemptyConName :: Name
nonemptyConName = mkNameG DataName "base" "Data.List.NonEmpty" ":|"
instance Lift a => Lift (NonEmpty a) where
lift (x :| xs) = do
x' <- lift x
xs' <- traverse lift xs
return $ ConE nonemptyConName `AppE` x' `AppE` xs'
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15949Hadrian needs more convenient build target names2019-07-07T18:02:19ZBen GamariHadrian needs more convenient build target namesWith the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to k...With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.
I suggest we introduce a set of convenience targets to make this easier. For instance one could run:
```
$ hadrian stage1:lib:ghc
```
to build the stage1 `ghc` library or
```
$ hadrian stage2:exe:hp2ps
```
to build `hp2ps`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian needs more convenient build target names","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"FeatureRequest","description":"With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.\r\n\r\nI suggest we introduce a set of convenience targets to make this easier. For instance one could run:\r\n{{{\r\n$ hadrian stage1:lib:ghc\r\n}}}\r\nto build the stage1 `ghc` library or\r\n{{{\r\n$ hadrian stage2:exe:hp2ps\r\n}}}\r\nto build `hp2ps`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15930Add @since-annotations to the Foldable methods2019-07-07T18:02:24ZSimon JakobiAdd @since-annotations to the Foldable methodsMethods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------...Methods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| 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":"Add @since-annotations to the Foldable methods","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Methods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15826Allow registering (Source)Plugins through the GHC API2019-07-07T18:02:49ZDanielGAllow registering (Source)Plugins through the GHC APIOne might expect to be able to load plugins through the GHC API by doing something like:
```
runGHC $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }
```
bu...One might expect to be able to load plugins through the GHC API by doing something like:
```
runGHC $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }
```
but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK.
While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| 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":"Allow using (Source)Plugins through the GHC API","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"One might expect to be able to load plugins through the GHC API by doing something like:\r\n\r\n{{{\r\nrunGHC $ do\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }\r\n}}}\r\n\r\nbut this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK.\r\n\r\nWhile in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1DanielGDanielGhttps://gitlab.haskell.org/ghc/ghc/-/issues/15798Flag to warn when deriving strategy is not explicitly specified2019-10-06T15:28:31ZAndrew MartinFlag to warn when deriving strategy is not explicitly specifiedIn my code, I aim to always specify deriving strategies. I would like to add a flag `-fwarn-unspecified-deriving` that would cause a warning to be emitted when someone wrote this:
```
newtype Foo = Foo Int
deriving (Show)
```
The use...In my code, I aim to always specify deriving strategies. I would like to add a flag `-fwarn-unspecified-deriving` that would cause a warning to be emitted when someone wrote this:
```
newtype Foo = Foo Int
deriving (Show)
```
The user would be required to instead write:
```
newtype Foo = Foo Int
deriving newtype (Show)
```
Or they could use `stock` if that was the behavior they wanted. This flag would be off by default.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Flag to warn when deriving strategy is not explicitly specified","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In my code, I aim to always specify deriving strategies. I would like to add a flag `-fwarn-unspecified-deriving` that would cause a warning to be emitted when someone wrote this:\r\n\r\n{{{\r\nnewtype Foo = Foo Int\r\n deriving (Show)\r\n}}}\r\n\r\nThe user would be required to instead write:\r\n\r\n{{{\r\nnewtype Foo = Foo Int\r\n deriving newtype (Show)\r\n}}}\r\n\r\nOr they could use `stock` if that was the behavior they wanted. This flag would be off by default.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15559fromJust has no HasCallStack2019-08-08T08:08:58ZJoachim Breitnermail@joachim-breitner.defromJust has no HasCallStackThe function `Data.Maybe.fromJust` does not have a `HasCallStack` constraint. I wonder why – is that intentional, or did just nobody bother yet?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --...The function `Data.Maybe.fromJust` does not have a `HasCallStack` constraint. I wonder why – is that intentional, or did just nobody bother yet?
<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":"fromJust has no HasCallStack","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":[""],"type":"FeatureRequest","description":"The function `Data.Maybe.fromJust` does not have a `HasCallStack` constraint. I wonder why – is that intentional, or did just nobody bother yet?","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15371Eventlog framework outputs environment variables which may cause a security i...2019-07-07T18:12:56ZMitsutoshi AoeEventlog framework outputs environment variables which may cause a security issueThe eventlog framework currently writes all environment variables to the eventlog file. This may cause a security issue as some external tools expect user to set credentials in environment variables. It's possible for the user to publish...The eventlog framework currently writes all environment variables to the eventlog file. This may cause a security issue as some external tools expect user to set credentials in environment variables. It's possible for the user to publish an eventlog which contains credentials without knowing it.
In general it's not a good idea to set credentials in environment variables but I think GHC should stop writing environment variables to the eventlog implicitly and this feature should be opt-in.
I'm not sure if this feature is widely used or if we can just drop it. If it's used to some extent maybe we can provide a function that does this job in a library.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15319Configurable/overridable settings file2023-07-17T18:00:29ZMathieu BoespflugConfigurable/overridable settings fileGHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries...GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C.
The problem is that I can't override \*everything\*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file.
What I'd like is something like:
```
$ ghc -settings /path/to/settings/file
```
that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler.
<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":"Configurable/overridable settings file","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":"GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C.\r\n\r\nThe problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file.\r\n\r\nWhat I'd like is something like:\r\n{{{\r\n$ ghc -settings /path/to/settings/file\r\n}}}\r\n\r\nthat subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15261Show -with-rtsopts options in runtime's --info2019-07-07T18:13:35ZÖmer Sinan AğacanShow -with-rtsopts options in runtime's --infoAs far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can ...As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.
- Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that".
<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":"Show -with-rtsopts options in runtime's --info","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":"As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:\r\n\r\n- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.\r\n- Sometimes we instruct users saying \"compile with this and run with that\". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say \"look at the info, you should see this and that\".","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15189Avoid word "transformer" in the documentation of ST2019-07-07T18:13:52ZArtem PelenitsynAvoid word "transformer" in the documentation of STI'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.
Some time ago, as a novice, I struggled to get the difference between three monad-related concepts:
1. The State monad.
1. The Sta...I'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.
Some time ago, as a novice, I struggled to get the difference between three monad-related concepts:
1. The State monad.
1. The StateT monad transformer.
1. The ST monad.
Current [documentation for ST](http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad-ST.html) says that "ST" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper "Lazy Functional State Threads", I find this confusing after the adoption of term "(monad) transformer" due to 1995 paper "Functional Programming with Overloading and Higher-Order Polymorphism". Note that ST paper predates MT one.
At the same time, the 1994 paper itself (in the title) and some current tutorials, [like the one at HaskelWiki](https://wiki.haskell.org/Monad/ST), use the word "thread" to describe what's going on, avoiding discussion of spelling of ST.
As the bottom line, I think, it would be helpful, especially for a novice, to avoid the word "transformer" in the documentation of ST module.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Avoid word \"transformer\" in the documentation of ST","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why.\r\n\r\nSome time ago, as a novice, I struggled to get the difference between three monad-related concepts:\r\n\r\n1. The State monad.\r\n2. The StateT monad transformer.\r\n3. The ST monad.\r\n\r\nCurrent [http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad-ST.html documentation for ST] says that \"ST\" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper \"Lazy Functional State Threads\", I find this confusing after the adoption of term \"(monad) transformer\" due to 1995 paper \"Functional Programming with Overloading and Higher-Order Polymorphism\". Note that ST paper predates MT one. \r\n\r\nAt the same time, the 1994 paper itself (in the title) and some current tutorials, [https://wiki.haskell.org/Monad/ST like the one at HaskelWiki], use the word \"thread\" to describe what's going on, avoiding discussion of spelling of ST. \r\n\r\nAs the bottom line, I think, it would be helpful, especially for a novice, to avoid the word \"transformer\" in the documentation of ST module.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/15050ScopedTypeVariables could allow more programs2020-08-19T17:35:02ZJoachim Breitnermail@joachim-breitner.deScopedTypeVariables could allow more programsConsider
```
data P a = P
data T1 a where
MkT1 :: forall a. P a -> T1 a
MkT2 :: forall a. P a -> T1 (a,a)
MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a
MkT4 :: for...Consider
```
data P a = P
data T1 a where
MkT1 :: forall a. P a -> T1 a
MkT2 :: forall a. P a -> T1 (a,a)
MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a
MkT4 :: forall a b. P a -> P b -> T1 a
MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a
```
I can write this function
```
foo :: T1 (Int, Int) -> ()
foo (MkT1 (P::P (Int,Int))) = ()
foo (MkT2 (P::P x)) = (() :: x ~ Int => ())
foo (MkT3 P (P::P Int)) = ()
foo (MkT4 P (P::P b)) = ()
foo (MkT5 P (P::P b) (P::P b)) = ()
```
but this these two equations fail
```
foo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ())
foo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ())
```
I am especially surprised by the second one, given that the very similar equation with `MkT2` works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ScopedTypeVariables could allow more programs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Consider\r\n{{{\r\ndata P a = P\r\ndata T1 a where\r\n MkT1 :: forall a. P a -> T1 a\r\n MkT2 :: forall a. P a -> T1 (a,a)\r\n MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a\r\n MkT4 :: forall a b. P a -> P b -> T1 a\r\n MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a\r\n}}}\r\n\r\nI can write this function\r\n{{{\r\nfoo :: T1 (Int, Int) -> ()\r\nfoo (MkT1 (P::P (Int,Int))) = ()\r\nfoo (MkT2 (P::P x)) = (() :: x ~ Int => ())\r\nfoo (MkT3 P (P::P Int)) = ()\r\nfoo (MkT4 P (P::P b)) = ()\r\nfoo (MkT5 P (P::P b) (P::P b)) = ()\r\n}}}\r\nbut this these two equations fail\r\n{{{\r\nfoo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ())\r\nfoo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ())\r\n}}}\r\n\r\nI am especially surprised by the second one, given that the very similar equation with `MkT2` works.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14298Let Template Haskell dynamically add something with which to link2019-07-07T18:17:34ZAlec TheriaultLet Template Haskell dynamically add something with which to linkAs of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking them, and then cleaning up any other files.
This makes package...As of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking them, and then cleaning up any other files.
This makes packages like `inline-c` ([https://hackage.haskell.org/package/inline-c](https://hackage.haskell.org/package/inline-c)) possible, where you can write C snippets in quasiquotes and these can interact with your Haskell code. The user doesn't need to pass extra options to GHC (except to enable the right language extensions), and they don't have to see any of the intermediate generated artifacts.
Unfortunately, that breaks down for non C compiler languages. It would be nice for TH to also support directly adding something to pass to the linker, since then one could
- use TH's `runIO` to generate libraries or object files by calling out to whatever other compilers
- add those via TH
- have GHC statically link against the content (from the second bullet point)
I'm not sure what the API for this could be, but maybe
1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type
1. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi m`8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/13256Warn on out-of-range literals in pattern matches too2019-07-07T18:22:43ZrwbartonWarn on out-of-range literals in pattern matches tooWe have these nice warnings for numeric literal expressions that are out of range of their type:
```
Prelude> 100000000000000000000000000000000 :: Int
<interactive>:1:1: warning: [-Woverflowed-literals]
Literal 10000000000000000000...We have these nice warnings for numeric literal expressions that are out of range of their type:
```
Prelude> 100000000000000000000000000000000 :: Int
<interactive>:1:1: warning: [-Woverflowed-literals]
Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807
```
but nothing for numeric patterns:
```
Prelude> (\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int
<interactive>:3:8: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In a case alternative:
Patterns not matched:
p where p is not one of {100000000000000000000000000000000}
*** Exception: <interactive>:3:8-64: Non-exhaustive patterns in case
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warn on out-of-range literals in pattern matches too","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We have these nice warnings for numeric literal expressions that are out of range of their type:\r\n{{{\r\nPrelude> 100000000000000000000000000000000 :: Int\r\n\r\n<interactive>:1:1: warning: [-Woverflowed-literals]\r\n Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807\r\n}}}\r\nbut nothing for numeric patterns:\r\n{{{\r\nPrelude> (\\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int\r\n\r\n<interactive>:3:8: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative:\r\n Patterns not matched:\r\n p where p is not one of {100000000000000000000000000000000}\r\n*** Exception: <interactive>:3:8-64: Non-exhaustive patterns in case\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/12045Visible kind application2019-07-07T18:27:52ZIcelandjackVisible kind applicationI've wanted this for a while
```
ghci> :kind (:~:)
(:~:) :: k -> k -> Type
```
```
ghci> :kind (:~:) @(Type -> Type)
(:~:) @(Type -> Type) :: (Type -> Type) -> (Type -> Type) -> Type
ghci> :kind (:~:) @(Type -> Type) []
(:~:) @(Type -...I've wanted this for a while
```
ghci> :kind (:~:)
(:~:) :: k -> k -> Type
```
```
ghci> :kind (:~:) @(Type -> Type)
(:~:) @(Type -> Type) :: (Type -> Type) -> (Type -> Type) -> Type
ghci> :kind (:~:) @(Type -> Type) []
(:~:) @(Type -> Type) [] :: (Type -> Type) -> Type
ghci> :kind (:~:) @(Type -> Type) [] Maybe
(:~:) @(Type -> Type) [] Maybe :: Type
```
Working like
```
ghci> type Same k (a::k) (b::k) = a :~: b
ghci> :kind Same
Same :: forall k -> k -> k -> *
```
```
ghci> :kind Same (Type -> Type)
Same (Type -> Type) :: (Type -> Type) -> (Type -> Type) -> *
ghci> :kind Same (Type -> Type) []
Same (Type -> Type) [] :: (Type -> Type) -> *
ghci> :kind Same (Type -> Type) [] Maybe
Same (Type -> Type) [] Maybe :: *
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Visible kind application","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["TypeApplications","TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I've wanted this for a while\r\n\r\n{{{\r\nghci> :kind (:~:)\r\n(:~:) :: k -> k -> Type\r\n}}}\r\n\r\n{{{\r\nghci> :kind (:~:) @(Type -> Type)\r\n(:~:) @(Type -> Type) :: (Type -> Type) -> (Type -> Type) -> Type\r\n\r\nghci> :kind (:~:) @(Type -> Type) []\r\n(:~:) @(Type -> Type) [] :: (Type -> Type) -> Type\r\n\r\nghci> :kind (:~:) @(Type -> Type) [] Maybe\r\n(:~:) @(Type -> Type) [] Maybe :: Type\r\n}}}\r\n\r\nWorking like\r\n\r\n{{{\r\nghci> type Same k (a::k) (b::k) = a :~: b\r\nghci> :kind Same\r\nSame :: forall k -> k -> k -> *\r\n}}}\r\n\r\n{{{\r\nghci> :kind Same (Type -> Type)\r\nSame (Type -> Type) :: (Type -> Type) -> (Type -> Type) -> *\r\nghci> :kind Same (Type -> Type) []\r\nSame (Type -> Type) [] :: (Type -> Type) -> *\r\nghci> :kind Same (Type -> Type) [] Maybe\r\nSame (Type -> Type) [] Maybe :: *\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1My NguyenMy Nguyenhttps://gitlab.haskell.org/ghc/ghc/-/issues/11335Add instance (Ix a, Read a, Read b) => Read (UArray a b)2019-07-07T18:30:53ZrwbartonAdd instance (Ix a, Read a, Read b) => Read (UArray a b)`Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...`Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add instance (Ix a, Read a, Read b) => Read (UArray a b)","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["array"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"`Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1