Generate linkables in the Eval plugin

[pepeiborra]

The intention is to move the codegen aspect of the Eval plugin away from the Interactive session and into the ghcide build graph. This should result in a much snappier user experience and hopefully also in a less flaky test suite.

The approach used is to redefine the NeedsCompilation rule adding a dependency on the GetEvalComments rule, so that whenever a module has -- >>> comments and it's open in the editor, the NeedsCompilation rule signals that a linkable is required. This should do what we need and, as far as I can see, has now downsides.

This is the first time that we redefine a build rule in a plugin, but I've been using this trick in sigma-ide for a while now and it's safe.

[wz1000]

Nice! I've been wanting to implement something like this for a while. However, I there are a few downsides if I understand this patch correctly:

1. Any comment matching the eval syntax is enough to force code generation for the file and all of its dependencies. This is a regression, as on current master the eval plugin will only compile stuff (and thus have an impact on HLS performance and memory) if it is actually invoked by the user.
   Am I correct in observing that this has the potential to regress performance for certain users? Namely those who

   1. have the eval plugin enabled
   2. have comments matching the eval syntax in their tree
   3. don't make use of the eval plugin very frequently

2. We run codegen for all builds, for every single modification - this is wasted work if the result of the codegen isn't going to be used by the eval plugin. I imagine the typical interaction would consist of many modifications, with a few invocations of the eval plugin sparsely distributed in between. So I think the ideal scenario would be building with codegen enabled only when the eval plugin is actually invoked.

[pepeiborra]

Nice! I've been wanting to implement something like this for a while. However, I there are a few downsides if I understand this patch correctly:

1. Any comment matching the eval syntax is enough to force code generation for the file and all of its dependencies. This is a regression, as on current master the eval plugin will only compile stuff (and thus have an impact on HLS performance and memory) if it is actually invoked by the user.
   Am I correct in observing that this has the potential to regress performance for certain users? Namely those who

   1. have the eval plugin enabled
   2. have comments matching the eval syntax in their tree
   3. don't make use of the eval plugin very frequently

2. We run codegen for all builds, for every single modification - this is wasted work if the result of the codegen isn't going to be used by the eval plugin. I imagine the typical interaction would consist of many modifications, with a few invocations of the eval plugin sparsely distributed in between. So I think the ideal scenario would be building with codegen enabled only when the eval plugin is actually invoked.

Yes, that's right, there are some tradeoffs. Hold on, I think I know what you have in mind...

[pepeiborra]

Check now, was this still the plan?

[pepeiborra]

I found a bunch of other issues while testing, will extract separate PRs.

[wz1000]

Very nice. I may finally start enabling the Eval plugin for daily use.

The reasoning for the custom newness check is a bit subtle though, I think it would make sense to document it properly.

[pepeiborra]

Very nice. I may finally start enabling the Eval plugin for daily use.

The reasoning for the custom newness check is a bit subtle though, I think it would make sense to document it properly.

You may want to try it and see that it works for you now