Has anyone explored/designed down this path? I've got some questions about a snag I hit.
Parsing seems fine (superficially) but the renamer fails. I'm re-using the global Rdr environment from the plugin's input ModGuts, so that free vars from the new syntax will reference other bindings in the original module and its imports. However, that environment is keyed on the uniques of FastStrings, ultimately raising "name not found" errors.
This happens because the global variable for the FastString Table is not being shared between the actual compiler and the new image of the GHC library that the plugin is using. One solution seems to be including the FastString Table in the "reinitializeGlobals" mechanism. This would require a GHC patch.
Questions:
1) Was the FastString Table intentionally left out of the reinitializeGlobals mechanism?
2) Are there similar obstacles lurking beyond this one that people know about? How incompatible is the invocation of front-end phases wrt the current plugin architecture?
My design assumes the HscEnv and ModGuts received by the plugin include enough information to reconstruct a meaningful TcGblEnv representing the original module. This seems to be at least nearly true. I am, however, not very well-versed with how imports are handled (EPS and such), so I don't know if the FastString Table issue is just the tip of the iceberg.