-
-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Eval plugin for GHC 9.4 #3391
Eval plugin for GHC 9.4 #3391
Conversation
Looks like Pepe's question never got answered (#3249 (comment)), but I'm okay with this anyway. Has conflicts now. |
What's the status of this? |
32a6ae3
to
0becd19
Compare
This is ready for review @pepeiborra |
2627c13
to
4541fef
Compare
Is there any way to check this in a test? Or a benchmark? Seems like an important property. |
I don't thin there is an easy way to do this. We can blacklist the |
Blacklisting the functions sounds good! |
2762851
to
13f09c8
Compare
13f09c8
to
f17707c
Compare
I have added an hlint rule and also fixed a regression that caused the eval plugin not to work due to #3414 landing. See the comment in the last commit for details. |
ed2980f
to
6a8d585
Compare
The plugin was implemented by calling "load" which circumvents all of HLSs caching mechanisms for interface files and linkables. Instead we should work like the other typechecking functions which get all the stuff we need using HLS rules and setup the HscEnv with all the state in the right places. The key part to this is setting up all the HPT modules with linkables if they are depenedencies of the module we are trying to run a function from. - ban load functions from GHC driver - Enable CI for hls-eval-plugin and fix a bug due to clearing of mi_globals
6a8d585
to
f012e04
Compare
Supersedes #3249 and depends on #3390