Recompilation avoidance in GHC 9.4 conflicts with recompilation avoidance in HLS

[wz1000]

We added very fine grained recompilation avoidance to HLS in #2316. With that change, a module using TH is recompiled if the hash of the Core of any of the modules it uses in a splice changes.

However, we still use GHC's recompilation avoidance by way of the checkOldIface function, which handles all the other recompilation avoidance cases which don't involve Template Haskell.

GHC 9.4 also added a similar finer grained recompilation avoidance scheme, in that it will recompile a module using TH if the hash of the source of any modules it uses in a splice changes. This is weaker than what we have in HLS, and as such we may end up recompiling when we didn't need to before.

Possible solution: Filter out the UsageHomeModuleInterface entries added to usages by GHCs recompilation checker.

[michaelpj]

Should we be trying to improve GHC's recompilation avoidance so it's as good as ours and we can just rely on it?

[mouse07410]

Should we be trying to improve GHC's recompilation avoidance so it's as good as ours and we can just rely on it?

Yes - because right now HLS is almost unusable with GHC-9.4.4 and VS Code: whenever I try to apply a Quick Fix hint, the hint is not applied and HLS errors out on this very issue.

[michaelpj]

I think you're commenting on the wrong issue. This has nothing to do with code actions.

[mouse07410]

I think you're commenting on the wrong issue. This has nothing to do with code actions.

Possible - but that's where VSCcode plugin threw me upon hitting that problem. I think the problem was not code actions per se, but the internal error triggered by attempt to apply the action, presumably because it got entangled with "whether to recompile" thing. But I don't know. In fact, if you're sure this is barking up the wrong tree - please feel free to delete my (irrelevant) comments in this issue.

[fendor]

Fixed by #3452 afaict