aengelke wrote: > Would it make more sense to make the CodeGenAction and emitBackendOutput more > flexible?
Maybe? emitBackendOutput (EmitAssemblyHelper) could call back into some new virtual method in BackendConsumer. This would leave the problem of inserting a new different (subclass of) BackendConsumer. But as a PluginASTAction cannot be a CodeGenAction, I would assume that at the very least the plugin action has to wrap all the virtual methods that CodeGenAction uses? This doesn't seem to be particularly viable, especially as some of the methods are protected. Duplicating CodeGenAction methods is also not a good option. > It would be great to enhance the existing clang plugin system rather than > adding a new plugin extension point. I generally agree, but... I spent a few days trying to come up with a PluginASTAction that achieves something similar... and gave up (=> this patch). (I've not much experience with Clang plugins, but the code is rather complicated and sparsely documented, which doesn't help, either.) > Do you mean that you will need to wrap clang's `BackendConsumer` into a > `MultiplexConsumer` and overwrite its `HandleTranslationUnit` swapping > `BackendConsumer::HandleTranslationUnit`'s `emitBackendOutput`? Ideally, I don't want to swap emitBackendOutput, because I don't want to duplicate that logic... https://github.com/llvm/llvm-project/pull/165257 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
