Page MenuHomePhabricator

Make it possible for AST plugins to enable themselves by default

Authored by john.brawn on Mar 8 2016, 5:35 AM.



Currently when an AST plugin is loaded it must then be enabled by passing -plugin pluginname or -add-plugin pluginname to the -cc1 command line. This patch adds a method to PluginASTAction which allows it to declare that the action happens before, instead of, or after the main AST action, plus the relevant changes to make the plugin action happen at that time automatically.

Note: patch was written before I noticed D15729, and probably needs adjusting to work with that.

Diff Detail


Event Timeline

john.brawn updated this revision to Diff 50037.Mar 8 2016, 5:35 AM
john.brawn retitled this revision from to Make it possible for AST plugins to enable themselves by default.
john.brawn updated this object.
john.brawn added reviewers: klimek, kfunk, milianw, rsmith.
john.brawn set the repository for this revision to rL LLVM.
john.brawn added a subscriber: cfe-commits.

+benjamin, who has done work in the area

Looking at D15729 I think there's no conflict between what this patch is doing and what that patch is doing. If a plugin returns AddBeforeMainAction or AddAfterMainAction then when ASTUnit in libclang loads that plugin it should get automatically added in FrontendAction::CreateWrappedASTConsumer, which is what I would expect should happen. There's a question of whether lines 199-210 of ExecuteCompilerInvocation.cpp should get moved into the CompilerInstance::loadPlugins function that D15729 adds and I think the answer there is no - looking at ASTUnit it doesn't seem to use getFrontendOpts().ProgramAction at all, so there's no point setting it based on a plugin.

bkramer accepted this revision.Mar 15 2016, 3:37 AM
bkramer edited edge metadata.

This looks fine to me.

This revision is now accepted and ready to land.Mar 15 2016, 3:37 AM
This revision was automatically updated to reflect the committed changes.