| 1 | ============= |
| 2 | Clang Plugins |
| 3 | ============= |
| 4 | |
| 5 | Clang Plugins make it possible to run extra user defined actions during a |
| 6 | compilation. This document will provide a basic walkthrough of how to write and |
| 7 | run a Clang Plugin. |
| 8 | |
| 9 | Introduction |
| 10 | ============ |
| 11 | |
| 12 | Clang Plugins run FrontendActions over code. See the :doc:`FrontendAction |
| 13 | tutorial <RAVFrontendAction>` on how to write a ``FrontendAction`` using the |
| 14 | ``RecursiveASTVisitor``. In this tutorial, we'll demonstrate how to write a |
| 15 | simple clang plugin. |
| 16 | |
| 17 | Writing a ``PluginASTAction`` |
| 18 | ============================= |
| 19 | |
| 20 | The main difference from writing normal ``FrontendActions`` is that you can |
| 21 | handle plugin command line options. The ``PluginASTAction`` base class declares |
| 22 | a ``ParseArgs`` method which you have to implement in your plugin. |
| 23 | |
| 24 | .. code-block:: c++ |
| 25 | |
| 26 | bool ParseArgs(const CompilerInstance &CI, |
| 27 | const std::vector<std::string>& args) { |
| 28 | for (unsigned i = 0, e = args.size(); i != e; ++i) { |
| 29 | if (args[i] == "-some-arg") { |
| 30 | // Handle the command line argument. |
| 31 | } |
| 32 | } |
| 33 | return true; |
| 34 | } |
| 35 | |
| 36 | Registering a plugin |
| 37 | ==================== |
| 38 | |
| 39 | A plugin is loaded from a dynamic library at runtime by the compiler. To |
| 40 | register a plugin in a library, use ``FrontendPluginRegistry::Add<>``: |
| 41 | |
| 42 | .. code-block:: c++ |
| 43 | |
| 44 | static FrontendPluginRegistry::Add<MyPlugin> X("my-plugin-name", "my plugin description"); |
| 45 | |
| 46 | Defining pragmas |
| 47 | ================ |
| 48 | |
| 49 | Plugins can also define pragmas by declaring a ``PragmaHandler`` and |
| 50 | registering it using ``PragmaHandlerRegistry::Add<>``: |
| 51 | |
| 52 | .. code-block:: c++ |
| 53 | |
| 54 | // Define a pragma handler for #pragma example_pragma |
| 55 | class ExamplePragmaHandler : public PragmaHandler { |
| 56 | public: |
| 57 | ExamplePragmaHandler() : PragmaHandler("example_pragma") { } |
| 58 | void HandlePragma(Preprocessor &PP, PragmaIntroducerKind Introducer, |
| 59 | Token &PragmaTok) { |
| 60 | // Handle the pragma |
| 61 | } |
| 62 | }; |
| 63 | |
| 64 | static PragmaHandlerRegistry::Add<ExamplePragmaHandler> Y("example_pragma","example pragma description"); |
| 65 | |
| 66 | Putting it all together |
| 67 | ======================= |
| 68 | |
| 69 | Let's look at an example plugin that prints top-level function names. This |
| 70 | example is checked into the clang repository; please take a look at |
| 71 | the `latest version of PrintFunctionNames.cpp |
| 72 | <https://github.com/llvm/llvm-project/blob/master/clang/examples/PrintFunctionNames/PrintFunctionNames.cpp>`_. |
| 73 | |
| 74 | Running the plugin |
| 75 | ================== |
| 76 | |
| 77 | |
| 78 | Using the cc1 command line |
| 79 | -------------------------- |
| 80 | |
| 81 | To run a plugin, the dynamic library containing the plugin registry must be |
| 82 | loaded via the `-load` command line option. This will load all plugins |
| 83 | that are registered, and you can select the plugins to run by specifying the |
| 84 | `-plugin` option. Additional parameters for the plugins can be passed with |
| 85 | `-plugin-arg-<plugin-name>`. |
| 86 | |
| 87 | Note that those options must reach clang's cc1 process. There are two |
| 88 | ways to do so: |
| 89 | |
| 90 | * Directly call the parsing process by using the `-cc1` option; this |
| 91 | has the downside of not configuring the default header search paths, so |
| 92 | you'll need to specify the full system path configuration on the command |
| 93 | line. |
| 94 | * Use clang as usual, but prefix all arguments to the cc1 process with |
| 95 | `-Xclang`. |
| 96 | |
| 97 | For example, to run the ``print-function-names`` plugin over a source file in |
| 98 | clang, first build the plugin, and then call clang with the plugin from the |
| 99 | source tree: |
| 100 | |
| 101 | .. code-block:: console |
| 102 | |
| 103 | $ export BD=/path/to/build/directory |
| 104 | $ (cd $BD && make PrintFunctionNames ) |
| 105 | $ clang++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS \ |
| 106 | -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE \ |
| 107 | -I$BD/tools/clang/include -Itools/clang/include -I$BD/include -Iinclude \ |
| 108 | tools/clang/tools/clang-check/ClangCheck.cpp -fsyntax-only \ |
| 109 | -Xclang -load -Xclang $BD/lib/PrintFunctionNames.so -Xclang \ |
| 110 | -plugin -Xclang print-fns |
| 111 | |
| 112 | Also see the print-function-name plugin example's |
| 113 | `README <https://github.com/llvm/llvm-project/blob/master/clang/examples/PrintFunctionNames/README.txt>`_ |
| 114 | |
| 115 | |
| 116 | Using the clang command line |
| 117 | ---------------------------- |
| 118 | |
| 119 | Using `-fplugin=plugin` on the clang command line passes the plugin |
| 120 | through as an argument to `-load` on the cc1 command line. If the plugin |
| 121 | class implements the ``getActionType`` method then the plugin is run |
| 122 | automatically. For example, to run the plugin automatically after the main AST |
| 123 | action (i.e. the same as using `-add-plugin`): |
| 124 | |
| 125 | .. code-block:: c++ |
| 126 | |
| 127 | // Automatically run the plugin after the main AST action |
| 128 | PluginASTAction::ActionType getActionType() override { |
| 129 | return AddAfterMainAction; |
| 130 | } |
| 131 | |