ghc-mod
ghc-mod copied to clipboard
Support object code generation as this is required for some (new) language extentions
If I try to use TemplateHaskell
and StaticPointers
in the same project the I get the following error:
The static form is not supported in interpreted mode.
Please use -fobject-code
There are other tickets that document this situation pretty well, unfortunately using -g -O0
or -g -fobject-code
does not work in this situation :(
We should probably detect all the relevant combinations of language flags and turn on object code generation for those that need it, like we do with NoLink/LinkInMemory and TH already. Though we'll have to be careful with where we put the output files since right now we just get the directories cabal uses through cabal-helper. I'm not sure if it's a good idea to overwrite those output files since that might interfere with cabal build
working properly if something goes wrong in ghc-mod, which would be very surprising to the user.
What's the status on this? Is there a known workaround?
Not yet but I think it would be very easy to fix. The code for checking if we need to enable byte-code generation is here (https://github.com/DanielG/ghc-mod/blob/master/core/Language/Haskell/GhcMod/Target.hs#L495). I think fixing this would basically amount to adding || StaticPointers `xopt` df
. I'd be happy to accept a PR that does this.
I just now tried that and it didn't work. I even tried setting:
needsHscInterpreted = const True
and it still says
The static form is not supported in interpreted mode.Please use -fobject-code.
Oh, I had it backwards. It works when I change it to
const False
Hmm OK. So that means it works with -fno-code (HscNothing) mode but not with HscInterpreted. That's going to cause problems when any of the other things that need HscInterpreted are also enabled in a module :/
I wonder though, does StaticPoints even work in ghci? If it throws up with HscInterpreted it ought to not so in that case one could argue the underlying issue really is a GHC problem.