Spurious recompilations when using a compiler plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Spurious recompilations when using a compiler plugin

Conal Elliott

It appears that use of GHC plugins causes client code to get needlessly recompiled. (See Trac issues 12567 and 7414.) It’s becoming more of a problem for usability of the plugin I’ve been developing, and I’m wondering what can be done. Some questions:

  • Is there any work in progress on fixing this situation?
  • Are there serious obstacles to fixing it?
  • Do plugin writers or users have any workarounds?

Other insights appreciated.

– Conal


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spurious recompilations when using a compiler plugin

Ben Gamari-2
Conal Elliott <[hidden email]> writes:

> It appears that use of GHC plugins causes client code to get needlessly
> recompiled. (See Trac issues 12567
> <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414
> <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a
> problem for usability of the plugin
> <http://conal.net/papers/compiling-to-categories> I’ve been developing, and
> I’m wondering what can be done. Some questions:
>
>    - Is there any work in progress on fixing this situation?
>    - Are there serious obstacles to fixing it?
>    - Do plugin writers or users have any workarounds?
>
I think the real question is what sort of interface do plugin authors
need?

I suspect there are a few distinct tasks here,

 * compute and record module implementation hashes in interface files

 * to include plugin implementation hashes in the recompilation check

 * to provide an interface allowing a plugin to compute a hash of its
   arguments which can be included into the recompilation check. One way
   of realising this would be to add a field like the following to Plugin,

       pluginHash :: [CommandLineOption] -> Maybe Fingerprint
           -- Nothing would denote "always rebuild"

   Would this help in your case?

This would allow us to fix the TH problem in #7277 and fix the plugins
problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
author is able to precisely define a hash).

None of this is terribly difficult and given Nick's recent work on his
row types plugin, it seems like it's getting more urgent.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spurious recompilations when using a compiler plugin

George Colpitts
is it possible that this is also connected to https://ghc.haskell.org/trac/ghc/ticket/13604 ?

On Tue, Sep 19, 2017 at 10:00 AM Ben Gamari <[hidden email]> wrote:
Conal Elliott <[hidden email]> writes:

> It appears that use of GHC plugins causes client code to get needlessly
> recompiled. (See Trac issues 12567
> <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414
> <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a
> problem for usability of the plugin
> <http://conal.net/papers/compiling-to-categories> I’ve been developing, and
> I’m wondering what can be done. Some questions:
>
>    - Is there any work in progress on fixing this situation?
>    - Are there serious obstacles to fixing it?
>    - Do plugin writers or users have any workarounds?
>
I think the real question is what sort of interface do plugin authors
need?

I suspect there are a few distinct tasks here,

 * compute and record module implementation hashes in interface files

 * to include plugin implementation hashes in the recompilation check

 * to provide an interface allowing a plugin to compute a hash of its
   arguments which can be included into the recompilation check. One way
   of realising this would be to add a field like the following to Plugin,

       pluginHash :: [CommandLineOption] -> Maybe Fingerprint
           -- Nothing would denote "always rebuild"

   Would this help in your case?

This would allow us to fix the TH problem in #7277 and fix the plugins
problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
author is able to precisely define a hash).

None of this is terribly difficult and given Nick's recent work on his
row types plugin, it seems like it's getting more urgent.

Cheers,

- Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Spurious recompilations when using a compiler plugin

Ben Gamari-2
George Colpitts <[hidden email]> writes:

> is it possible that this is also connected to
> https://ghc.haskell.org/trac/ghc/ticket/13604 ?
>
In that it pertains to the recompilation checker, yes. I've tried to
collect the recompilation checker bugs in play here under the
RecompilationCheck keyword in Trac. It would be great to get some eyes
on these issues as they are clearly causing real pain for some users.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment