GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-09-25T18:57:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7414plugins always trigger recompilation2021-09-25T18:57:15Zjwlatoplugins always trigger recompilationWhen compiling code with a ghc plugin, e.g. **ghc -O -fplugin SomePlugin Main.hs**, recompilation is triggered for every module. This can make plugins difficult to use in environments with many modules shared between executables.
Since ...When compiling code with a ghc plugin, e.g. **ghc -O -fplugin SomePlugin Main.hs**, recompilation is triggered for every module. This can make plugins difficult to use in environments with many modules shared between executables.
Since a plugin is a GHC library, I would like to propose that plugin arguments and interface hashes be included in the dependencies for compiled modules, in a similar way to how compiler flags are already included. This would enable ghc to avoid recompilation of modules when using plugins, provided that the plugin and plugin options haven't changed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.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":"plugins always trigger recompilation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":["plugin,","recompilation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When compiling code with a ghc plugin, e.g. '''ghc -O -fplugin SomePlugin Main.hs''', recompilation is triggered for every module. This can make plugins difficult to use in environments with many modules shared between executables.\r\n\r\nSince a plugin is a GHC library, I would like to propose that plugin arguments and interface hashes be included in the dependencies for compiled modules, in a similar way to how compiler flags are already included. This would enable ghc to avoid recompilation of modules when using plugins, provided that the plugin and plugin options haven't changed.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15195Merge -XPolyKinds with -XTypeInType2019-07-07T18:13:50ZRichard Eisenbergrae@richarde.devMerge -XPolyKinds with -XTypeInTypeAs described in [this accepted proposal](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...As described in [this accepted proposal](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Merge -XPolyKinds with -XTypeInType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As described in [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst this accepted proposal].","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/15178Implement DerivingVia2019-07-07T18:13:55ZRyan ScottImplement DerivingViaThe `DerivingVia` GHC proposal [has been accepted](https://github.com/ghc-proposals/ghc-proposals/pull/120). This ticket serves as a reminder to get the corresponding patch into GHC.
<details><summary>Trac metadata</summary>
| Trac fie...The `DerivingVia` GHC proposal [has been accepted](https://github.com/ghc-proposals/ghc-proposals/pull/120). This ticket serves as a reminder to get the corresponding patch into GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Iceland_jack, kosmikus |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement DerivingVia","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":["Iceland_jack","kosmikus"],"type":"FeatureRequest","description":"The `DerivingVia` GHC proposal [https://github.com/ghc-proposals/ghc-proposals/pull/120 has been accepted]. This ticket serves as a reminder to get the corresponding patch into GHC.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/14761Incorrect diagnostic for UNPACK/missing strictness2019-07-07T18:15:44ZdminuosoIncorrect diagnostic for UNPACK/missing strictness```hs
data A = A { a :: {-# UNPACK #-} Maybe Int}
```
```
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Temp.hs:1:19: error:
• Unexpected strictness annotation: {-# UNPACK #-}Maybe
• In the type ‘{-# UNPACK #-}Maybe I...```hs
data A = A { a :: {-# UNPACK #-} Maybe Int}
```
```
[1 of 1] Compiling Main ( Temp.hs, Temp.o )
Temp.hs:1:19: error:
• Unexpected strictness annotation: {-# UNPACK #-}Maybe
• In the type ‘{-# UNPACK #-}Maybe Int’
In the definition of data constructor ‘A’
In the data declaration for ‘A’
|
1 | data A = A { a :: {-# UNPACK #-} Maybe Int}
|
```
The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite.
A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect diagnostic for UNPACK/missing strictness","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\ndata A = A { a :: {-# UNPACK #-} Maybe Int}\r\n}}}\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( Temp.hs, Temp.o )\r\n\r\nTemp.hs:1:19: error:\r\n • Unexpected strictness annotation: {-# UNPACK #-}Maybe\r\n • In the type ‘{-# UNPACK #-}Maybe Int’\r\n In the definition of data constructor ‘A’\r\n In the data declaration for ‘A’\r\n |\r\n1 | data A = A { a :: {-# UNPACK #-} Maybe Int}\r\n |\r\n}}}\r\n\r\nThe diagnostic is incorrect because it complains about an \"unexpected strictness annotation\" although the error is the opposite.\r\n\r\nA quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14709Extend the plugin mechanism to access program representation2019-07-07T18:15:55ZlazacExtend the plugin mechanism to access program representationThis would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what co...This would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what configuration, because the normal build procedure could be invoked by the user with plugin flags specifying what tools to invoke.
The plan is described in more details at [Extended Plugins Proposal](https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ulysses4ever |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Extend the plugin mechanism to access program representation","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ulysses4ever"],"type":"FeatureRequest","description":"This would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what configuration, because the normal build procedure could be invoked by the user with plugin flags specifying what tools to invoke.\r\n\r\nThe plan is described in more details at [https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Extended Plugins Proposal]","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14473Implement Underscores in Numeric Literals Proposal (NumericUnderscores extens...2019-07-07T18:16:53ZTakenobu TaniImplement Underscores in Numeric Literals Proposal (NumericUnderscores extension)Implement Underscores in Numeric Literals Proposal.
GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves ...Implement Underscores in Numeric Literals Proposal.
GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals.
This proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled.
Underscores (`_`) in numeric literals are simply ignored.
The specification of the feature is available here:\\\\
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009-numeric-underscores.rst
For a discussion:\\\\
https://github.com/ghc-proposals/ghc-proposals/pull/76
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Implement Underscores in Numeric Literals Proposal.\r\n\r\nGHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals.\r\n\r\nThis proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled.\r\nUnderscores (`_`) in numeric literals are simply ignored.\r\n\r\nThe specification of the feature is available here:\\\\\r\nhttps://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009-numeric-underscores.rst\r\n\r\nFor a discussion:\\\\\r\nhttps://github.com/ghc-proposals/ghc-proposals/pull/76","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Takenobu TaniTakenobu Tanihttps://gitlab.haskell.org/ghc/ghc/-/issues/14324Consider deprecating STM invariant mechanism2019-07-07T18:17:28ZBen GamariConsider deprecating STM invariant mechanismfryguybob and I were recently discussing the STM invariant mechanism (e.g. `Control.Monad.STM.check`). This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that...fryguybob and I were recently discussing the STM invariant mechanism (e.g. `Control.Monad.STM.check`). This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that the implementation currently takes so many locks that it very likely prevents these odd interleavings from occurring.
In addition,
- the implementation doesn't handle nested STM invariants correctly (#7930)
- the locking behavior of the implementation was, until very recently, utterly wrong (#14310)
- the feature introduces quite a bit of complexity in the RTS
- the interface has essentially no users, as evidenced by a Hackage search and the fact that #14310 went unnoticed for years
All of this raises the question: Is the STM invariants feature really where we want to spend our complexity budget? Perhaps it is time for this feature to quietly pass (after an appropriate deprecation period, of course).8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10843Allow do blocks without dollar signs as arguments2019-07-07T18:33:33ZagibianskyAllow do blocks without dollar signs as argumentsI would like the following to be valid Haskell code:
```hs
main = when True do
putStrLn "Hello!"
```
Instead of requiring a dollar sign before the "do". This would parse as
```hs
main = when True (do
putStrLn "Hello!")
```
Simila...I would like the following to be valid Haskell code:
```hs
main = when True do
putStrLn "Hello!"
```
Instead of requiring a dollar sign before the "do". This would parse as
```hs
main = when True (do
putStrLn "Hello!")
```
Similarly, allow lambdas in the same way
```hs
main = forM values \value ->
print value
```
parses as
```hs
main = forM values (\value ->
print value)
```
One possible question: does this also do the same thing for LambdaCase? I think that since people expect lambda case to just be a simple desugaring it should also work, so then
```hs
main = forM values \case
Just x -> print x
Nothing -> print y
```
parses as
```hs
main = forM values (\case
Just x -> print x
Nothing -> print y)
```
Wiki page: [ArgumentDo](argument-do)8.6.1takano-akiotakano-akiohttps://gitlab.haskell.org/ghc/ghc/-/issues/9793Some as-patterns could be accepted in pattern synonyms2019-07-07T18:39:01ZGergő ÉrdiSome as-patterns could be accepted in pattern synonymsCurrently all as-patterns are rejected in pattern synonym definitions, to avoid situations like
```
pattern P x y <- x@(y:_)
```
since there's no valid reason to be able to then write something like
```
f [True] False = ...
```
this ...Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like
```
pattern P x y <- x@(y:_)
```
since there's no valid reason to be able to then write something like
```
f [True] False = ...
```
this would just lead to confusion.
However, I think we could accept as-patterns where the body of the as-pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK:
```
pattern P x <- x@(y:_)
```
since it's exactly equivalent to
```
pattern P x <- x@(_:_)
```
which I don't think is as confusing as the other example.
I haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent:
```
pattern P1 x = [x@(y:_)]
pattern P2 x <- [x@(y:_)]
where
P2 x = [x]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Some as-patterns could be accepted in pattern synonyms","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"cactus"},"version":"7.8.3","keywords":["pattern","synonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like\r\n\r\n\r\n{{{\r\npattern P x y <- x@(y:_)\r\n}}}\r\n\r\nsince there's no valid reason to be able to then write something like\r\n\r\n{{{\r\nf [True] False = ...\r\n}}}\r\n\r\nthis would just lead to confusion.\r\n\r\nHowever, I think we could accept as-patterns where the body of the as-pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK:\r\n\r\n{{{\r\npattern P x <- x@(y:_)\r\n}}}\r\n\r\nsince it's exactly equivalent to\r\n\r\n{{{\r\npattern P x <- x@(_:_)\r\n}}}\r\n\r\nwhich I don't think is as confusing as the other example.\r\n\r\nI haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent:\r\n\r\n{{{\r\npattern P1 x = [x@(y:_)]\r\npattern P2 x <- [x@(y:_)]\r\n where\r\n P2 x = [x]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/3427control what sort of entity a deprecated pragma applies to2021-08-05T14:20:07ZIan Lynagh <igloo@earth.li>control what sort of entity a deprecated pragma applies toOriginally reported as part of #3303.
----
It's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider:
```
data Foo = Foo ...
```
This is a very common idiom. But now we want...Originally reported as part of #3303.
----
It's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider:
```
data Foo = Foo ...
```
This is a very common idiom. But now we want to switch to smart constructors
```
foo :: ... -> Foo
```
and eventually stop exporting the constructor Foo. But we cannot specify just the constructor, only both. According to the [user guide](http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma) the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor.
How about
```
{-# DEPRECATED constructor Foo "use `foo' instead" #-}
```
and while we're at it, might as well have
```
{-# DEPRECATED type Foo "..." #-}
```
leaving the unqualified case meaning both as it does now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"control what sort of entity a deprecated pragma applies to","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originally reported as part of #3303.\r\n\r\n----\r\n\r\nIt's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider:\r\n{{{\r\ndata Foo = Foo ...\r\n}}}\r\nThis is a very common idiom. But now we want to switch to smart constructors\r\n{{{\r\nfoo :: ... -> Foo\r\n}}}\r\nand eventually stop exporting the constructor Foo. But we cannot specify just the constructor, only both. According to the [http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma user guide] the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor.\r\n\r\nHow about\r\n{{{\r\n{-# DEPRECATED constructor Foo \"use `foo' instead\" #-}\r\n}}}\r\nand while we're at it, might as well have\r\n{{{\r\n{-# DEPRECATED type Foo \"...\" #-}\r\n}}}\r\nleaving the unqualified case meaning both as it does now.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Alex DAlex Dhttps://gitlab.haskell.org/ghc/ghc/-/issues/2893Implement "Quantified constraints" proposal2019-07-07T19:06:23ZPorgesImplement "Quantified constraints" proposalSee: [Quantifiedconstraintswikipage](quantified-constraints)See: [Quantifiedconstraintswikipage](quantified-constraints)8.6.1