Fix recompilation checking of pure plugins

Authored by DanielG on Nov 4 2018, 5:52 PM.



Previously when switching from using a Plugin with
RecompMaybe/ForceRecompile in pluginRecompile to a Plugin with
NoForceRecompile GHC would never even consider recompiling.

However the previously active plugin could have modified the
compilation output so we should recompile.

Test Plan


Diff Detail

rGHC Glasgow Haskell Compiler
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
DanielG created this revision.Nov 4 2018, 5:52 PM
DanielG added inline comments.Nov 4 2018, 6:01 PM

Since I'm mostly interested in the behaviour of plugins in the GHC API / GHCi I had to add a way to reset the currently active plugins. Lower case names aren't valid haskell module names, right? So using a lower case word as a keyword here should be fine.

If you guys thing this is OK I can add some docs for this option.


I sure hope the GHC tests have echo in their PATH on werid platforms like WinDOS :)


All the other plugin tests seem to have this predicate but if I enable it the test doesn't actually run if I do make TEST=T15858. Anybody have any idea what's going on there?

I'm quite confused; I would have thought that the change in the module's Usages would have been sufficient to trigger a recompilation. @mpickering, do you know what is going on here?

mpickering requested changes to this revision.Nov 8 2018, 4:02 PM

Looks plausible but I need to understand what Ben meant in his comment above before understanding the logic in detail.

Also the change to addPluginModuleName is definitely not desirable, please change that.


No, please don't do this. Add a new function called clearPlugins which does it.


Aren't the other plugin tests specified in a makefile rather than as a ghci script? Why did you choose this?



This revision now requires changes to proceed.Nov 8 2018, 4:02 PM
DanielG added a comment.EditedNov 8 2018, 4:34 PM
This comment has been deleted.

This is just a quick hack, I was going to rename the function later actually.

I'm more talking about whether it's ok to reuse the -fplugin option with a =clear argument (to keep it consistent with -package-db) instead of adding a new option.


It's just the specific case I'm interested in. See my StaticPlugin patch.

I started writing this test when I still didn't know if this was GHCi specific or not and it turns out GHCi has an additional caching layer that never recompiles when plugin fingerprints change (but that's a seperate bug report) unless you use -fobject-code.

I can port this to regular GHC in the makefile if you like, this was just easier for me to produce since I was already working on testing out plugin recomp in GHCi.

DanielG updated this revision to Diff 18878.Nov 25 2018, 9:49 AM

Add -fclear-plugins (incl. docs) instead of overloading the -fplugin option.

DanielG updated this revision to Diff 18880.Nov 25 2018, 9:53 AM
DanielG marked 3 inline comments as done.

Fix typo


Actually I was thinking of cabal-install's --package-db option that has this =clear argument behaviour. GHC has seperate options for that elsewhere so I'm doing that now instead.

DanielG marked 2 inline comments as done.Nov 25 2018, 9:54 AM
bgamari accepted this revision.Dec 11 2018, 5:36 PM
bgamari added inline comments.

I will take care of this.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 12 2018, 10:27 PM
This revision was automatically updated to reflect the committed changes.