GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-06-09T09:15:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15650Add (or document if already exist) ability to derive custom typeclasses via s...2023-06-09T09:15:40ZDmitrii KovanikovAdd (or document if already exist) ability to derive custom typeclasses via source plugins## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using ...## Problem
Suppose, I have some custom typeclass `Foo` defined in some library `foo`:
```hs
class Foo a where
... some methods ...
```
I would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:
```hs
data Bar = Bar | Baz
deriving (Eq, Ord, Foo)
```
There're already two possible ways to derive instances of custom typeclasses:
1. `anyclass` deriving strategy (usually involves `Generic`)
1. `-XTemplateHaskell` solution.
But I would like to have source-plugin-based solution for this problem so I can just add `-fplugin=Foo.Plugin` and enjoy deriving capabilities.
## Advantage over existing approaches
Solution with `-XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/th-abstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:
```hs
{-# LANGUAGE TemplateHaskell #-}
data Bar = Bar | Baz
deriving (Eq, Ord)
deriveFoo ''Bar
```
Solution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like *parsing CLI arguments* but it's more important if you want to have efficient binary serialisation.
Also, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1-beta1 |
| 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 (or document if already exist) ability to derive custom typeclasses via source plugins","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1-beta1","keywords":["plugins,deriving,typeclass","source"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"== Problem\r\n\r\nSuppose, I have some custom typeclass `Foo` defined in some library `foo`:\r\n\r\n{{{#!hs\r\nclass Foo a where\r\n ... some methods ...\r\n}}}\r\n\r\nI would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.:\r\n\r\n{{{#!hs\r\ndata Bar = Bar | Baz\r\n deriving (Eq, Ord, Foo)\r\n}}}\r\n\r\nThere're already two possible ways to derive instances of custom typeclasses:\r\n\r\n1. `anyclass` deriving strategy (usually involves `Generic`)\r\n2. `-XTemplateHaskell` solution.\r\n\r\nBut I would like to have source-plugin-based solution for this problem so I can just add `-fplugin=Foo.Plugin` and enjoy deriving capabilities.\r\n\r\n== Advantage over existing approaches\r\n\r\nSolution with `-XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/th-abstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\ndata Bar = Bar | Baz\r\n deriving (Eq, Ord)\r\n\r\nderiveFoo ''Bar\r\n}}}\r\n\r\nSolution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like ''parsing CLI arguments'' but it's more important if you want to have efficient binary serialisation. \r\n\r\nAlso, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15564Plugin recompilation check panics with inline-java2019-07-07T18:04:07ZFacundo DomÃnguezPlugin recompilation check panics with inline-javaWhen building https://github.com/tweag/inline-java with the beta release of ghc 8.6.1, I'm getting a panic like the one in #15475.
```
stack --nix --no-terminal build --test --bench --no-run-tests --no-run-benchmarks
...
Log files have...When building https://github.com/tweag/inline-java with the beta release of ghc 8.6.1, I'm getting a panic like the one in #15475.
```
stack --nix --no-terminal build --test --bench --no-run-tests --no-run-benchmarks
...
Log files have been written to: /home/centos/inline-java/.stack-work/logs/
-- While building custom Setup.hs for package inline-java-0.8.4 using:
/home/centos/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.4.0.0_ghc-8.6.0.20180810 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0 build lib:inline-java test:spec --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: /home/centos/inline-java/.stack-work/logs/inline-java-0.8.4.log
Configuring inline-java-0.8.4...
Preprocessing library for inline-java-0.8.4..
Building library for inline-java-0.8.4..
[4 of 4] Compiling Language.Java.Inline.Plugin ( src/Language/Java/Inline/Plugin.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0/build/Language/Java/Inline/Plugin.o )
Preprocessing test suite 'spec' for inline-java-0.8.4..
Building test suite 'spec' for inline-java-0.8.4..
[1 of 3] Compiling Language.Java.InlineSpec ( tests/Language/Java/InlineSpec.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0/build/spec/spec-tmp/Language/Java/InlineSpec.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.0.20180810 for x86_64-unknown-linux):
mkPluginUsage: file not found
Language.Java.Inline.Plugin /nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib/libHSinline-java-0.8.4-JByd5xgK6QcDkJNlDDk6Qy-ghc8.6.0.20180810.so
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[centos@ip-172-31-4-204 inline-java]$ stack --nix --no-terminal exec -- env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib/openjdk/jre/lib/amd64/server/lib:/nix/store/rc9ksilfsx1pqya4lj8barzzywnvlncl-git-2.18.0/lib:/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib:/nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib
```
The fact that ghc tries to locate a library in {{/nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib}} to check for recompilation makes me think that this is an actual bug in GHC. But I would be happy to get some assistance to confirm this.
I tried disabling recompilation checking by defining the plugin as:
```
plugin :: Plugin
plugin = defaultPlugin
{ installCoreToDos = install
, pluginRecompile = purePlugin
}
```
but the error persists.
This is what my dependencies look like in stack.yaml:
```
packages:
- .
- jni
- jvm
- jvm-batching
- jvm-streaming
- examples/classpath
- location: singletons
extra-dep: true
- location: criterion
extra-dep: true
- location: polyparse-1.12
extra-dep: true
extra-deps:
- distributed-closure-0.3.5
- git: https://github.com/haskell/cabal
# commit: ac461b381104a39a349d7416ecf1399805c6d000
commit: fe10982db1f2fa7d828fc5f8ddaa5beedceaddec
subdirs:
- Cabal
# - git: https://github.com/goldfirere/singletons.git
# commit: 5f867ace69ab12fc98fa71df1cdf7985afa3cb91
- git: https://github.com/haskell/stm.git
commit: 4a1deb98fc95e55d8a6762a7dfec1a7dfa8b49b2
- git: https://github.com/goldfirere/th-desugar
commit: 0f0a45f7b1f290a6005e6d9d849247f8c3d35429
- git: https://github.com/simonmar/async.git
commit: 725ba4bb9679c5d9c7fe0e2d45fda4f470851d40
- git: https://github.com/erikd/vector-algorithms.git
commit: 89e87b374d94e8a0c90fc58079ea1343c3ffa7c9
- cpphs-1.20.8
```
I'll see to share my modifications to singletons, criterion and polyparse, if necessary. I just fixed some dependency bounds and added MonadFail instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1-beta1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, mboes |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugin recompilation check panics with inline-java","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1-beta1","keywords":["plugin","plugins,","recompilation"],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","mboes"],"type":"Bug","description":"When building https://github.com/tweag/inline-java with the beta release of ghc 8.6.1, I'm getting a panic like the one in #15475.\r\n\r\n{{{\r\nstack --nix --no-terminal build --test --bench --no-run-tests --no-run-benchmarks\r\n...\r\n\r\nLog files have been written to: /home/centos/inline-java/.stack-work/logs/\r\n\r\n-- While building custom Setup.hs for package inline-java-0.8.4 using:\r\n /home/centos/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.4.0.0_ghc-8.6.0.20180810 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0 build lib:inline-java test:spec --ghc-options \" -ddump-hi -ddump-to-file -fdiagnostics-color=always\"\r\n Process exited with code: ExitFailure 1\r\n Logs have been written to: /home/centos/inline-java/.stack-work/logs/inline-java-0.8.4.log\r\n\r\n Configuring inline-java-0.8.4...\r\n Preprocessing library for inline-java-0.8.4..\r\n Building library for inline-java-0.8.4..\r\n [4 of 4] Compiling Language.Java.Inline.Plugin ( src/Language/Java/Inline/Plugin.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0/build/Language/Java/Inline/Plugin.o )\r\n Preprocessing test suite 'spec' for inline-java-0.8.4..\r\n Building test suite 'spec' for inline-java-0.8.4..\r\n [1 of 3] Compiling Language.Java.InlineSpec ( tests/Language/Java/InlineSpec.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.0/build/spec/spec-tmp/Language/Java/InlineSpec.o )\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.0.20180810 for x86_64-unknown-linux):\r\n mkPluginUsage: file not found\r\n Language.Java.Inline.Plugin /nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib/libHSinline-java-0.8.4-JByd5xgK6QcDkJNlDDk6Qy-ghc8.6.0.20180810.so\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage\r\n \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n[centos@ip-172-31-4-204 inline-java]$ stack --nix --no-terminal exec -- env | grep LD_LIBRARY_PATH \r\nLD_LIBRARY_PATH=/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib/openjdk/jre/lib/amd64/server/lib:/nix/store/rc9ksilfsx1pqya4lj8barzzywnvlncl-git-2.18.0/lib:/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib:/nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib\r\n}}}\r\n\r\nThe fact that ghc tries to locate a library in {{/nix/store/5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib}} to check for recompilation makes me think that this is an actual bug in GHC. But I would be happy to get some assistance to confirm this.\r\n\r\nI tried disabling recompilation checking by defining the plugin as:\r\n{{{\r\nplugin :: Plugin\r\nplugin = defaultPlugin\r\n { installCoreToDos = install\r\n , pluginRecompile = purePlugin\r\n }\r\n}}}\r\nbut the error persists.\r\n\r\nThis is what my dependencies look like in stack.yaml:\r\n{{{\r\npackages:\r\n- .\r\n- jni\r\n- jvm\r\n- jvm-batching\r\n- jvm-streaming\r\n- examples/classpath\r\n- location: singletons\r\n extra-dep: true\r\n- location: criterion\r\n extra-dep: true\r\n- location: polyparse-1.12\r\n extra-dep: true\r\n \r\nextra-deps:\r\n- distributed-closure-0.3.5\r\n- git: https://github.com/haskell/cabal\r\n# commit: ac461b381104a39a349d7416ecf1399805c6d000\r\n commit: fe10982db1f2fa7d828fc5f8ddaa5beedceaddec\r\n subdirs:\r\n - Cabal\r\n# - git: https://github.com/goldfirere/singletons.git\r\n# commit: 5f867ace69ab12fc98fa71df1cdf7985afa3cb91\r\n- git: https://github.com/haskell/stm.git\r\n commit: 4a1deb98fc95e55d8a6762a7dfec1a7dfa8b49b2\r\n- git: https://github.com/goldfirere/th-desugar\r\n commit: 0f0a45f7b1f290a6005e6d9d849247f8c3d35429\r\n- git: https://github.com/simonmar/async.git\r\n commit: 725ba4bb9679c5d9c7fe0e2d45fda4f470851d40\r\n- git: https://github.com/erikd/vector-algorithms.git\r\n commit: 89e87b374d94e8a0c90fc58079ea1343c3ffa7c9\r\n- cpphs-1.20.8\r\n}}}\r\n\r\nI'll see to share my modifications to singletons, criterion and polyparse, if necessary. I just fixed some dependency bounds and added MonadFail instances.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15439Refactor `printMinimalImports` into two functions and reexport them2019-07-07T18:04:53ZDmitrii KovanikovRefactor `printMinimalImports` into two functions and reexport themCurrently the `printMinimalImports` function finds set of minimal imports and prints them into file.
- https://github.com/ghc/ghc/blob/0f5a63e3d763f18c683f076e0e96396166863f56/compiler/rename/RnNames.hs\#L1469
But it's more convenient ...Currently the `printMinimalImports` function finds set of minimal imports and prints them into file.
- https://github.com/ghc/ghc/blob/0f5a63e3d763f18c683f076e0e96396166863f56/compiler/rename/RnNames.hs\#L1469
But it's more convenient to have function that returns set of minimal imports that can later be used by external tools like source plugins without need to parse content of `.import` file. And without need to copy-paste existing function.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mpickering |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Refactor `printMinimalImports` into two functions and reexport them","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["imports,refactoring,source","plugins"],"differentials":[],"test_case":"","architecture":"","cc":["mpickering"],"type":"FeatureRequest","description":"Currently the `printMinimalImports` function finds set of minimal imports and prints them into file. \r\n\r\n* https://github.com/ghc/ghc/blob/0f5a63e3d763f18c683f076e0e96396166863f56/compiler/rename/RnNames.hs#L1469\r\n\r\nBut it's more convenient to have function that returns set of minimal imports that can later be used by external tools like source plugins without need to parse content of `.import` file. And without need to copy-paste existing function.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1vrom911vrom911https://gitlab.haskell.org/ghc/ghc/-/issues/15315Renamer plugins could run after each group has been renamed2021-06-21T09:36:49ZMatthew PickeringRenamer plugins could run after each group has been renamedIn discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings.
Currently, the interface for renamer plugins is q...In discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings.
Currently, the interface for renamer plugins is quite strange and they run just before typechecker plugins in the implementation.
<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":"Renamer plugins could run after each group has been renamed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings. \r\n\r\nCurrently, the interface for renamer plugins is quite strange and they run just before typechecker plugins in the implementation. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15234WARNING in hptSomeThingsBelowUs when using a source plugin2019-07-07T18:13:41ZMatthew PickeringWARNING in hptSomeThingsBelowUs when using a source pluginWhen using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date i...When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date interface files
```
I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup.
<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":"WARNING in hptSomeThingsBelowUs when using a source plugin","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["SourcePlugins,","plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.\r\n\r\n{{{\r\nWARNING in hptSomeThingsBelowUs\r\n missing module CoercePlugin\r\n Probable cause: out-of-date interface files\r\n}}}\r\n\r\nI don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15229Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc2019-07-07T18:13:42ZMatthew PickeringRun typeCheckResultAction and renamedResultAction in TcM rather than HscThe primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easie...The primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easier than constructing GhcTc.
See https://phabricator.haskell.org/D4792
<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":"Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The primary motivation for this is that this allows users to access\r\nthe warnings and error machinery present in TcM. However, it also allows\r\nusers to use TcM actions which means they can typecheck GhcPs which\r\ncould be significantly easier than constructing GhcTc.\r\n\r\nSee https://phabricator.haskell.org/D4792","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://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.1