| # Overview |
| |
| Clang Tools are standalone command line (and potentially GUI) tools |
| designed for use by C++ developers who are already using and enjoying |
| Clang as their compiler. These tools provide developer-oriented |
| functionality such as fast syntax checking, automatic formatting, |
| refactoring, etc. |
| |
| Only a couple of the most basic and fundamental tools are kept in the |
| primary Clang tree. The rest of the tools are kept in a separate |
| directory tree, [clang-tools-extra](https://github.com/llvm/llvm-project/tree/main/clang-tools-extra). |
| |
| This document describes a high-level overview of the organization of |
| Clang Tools within the project as well as giving an introduction to some |
| of the more important tools. However, it should be noted that this |
| document is currently focused on Clang and Clang Tool developers, not on |
| end users of these tools. |
| |
| ## Clang Tools Organization |
| |
| Clang Tools are CLI or GUI programs that are intended to be directly |
| used by C++ developers. That is they are *not* primarily for use by |
| Clang developers, although they are hopefully useful to C++ developers |
| who happen to work on Clang, and we try to actively dogfood their |
| functionality. They are developed in three components: the underlying |
| infrastructure for building a standalone tool based on Clang, core |
| shared logic used by many different tools in the form of refactoring and |
| rewriting libraries, and the tools themselves. |
| |
| The underlying infrastructure for Clang Tools is the |
| {doc}`LibTooling <LibTooling>` platform. See its documentation for much |
| more detailed information about how this infrastructure works. The |
| common refactoring and rewriting toolkit-style library is also part of |
| LibTooling organizationally. |
| |
| A few Clang Tools are developed along side the core Clang libraries as |
| examples and test cases of fundamental functionality. However, most of |
| the tools are developed in a side repository to provide easy separation |
| from the core libraries. We intentionally do not support public |
| libraries in the side repository, as we want to carefully review and |
| find good APIs for libraries as they are lifted out of a few tools and |
| into the core Clang library set. |
| |
| Regardless of which repository Clang Tools' code resides in, the |
| development process and practices for all Clang Tools are exactly those |
| of Clang itself. They are entirely within the Clang *project*, |
| regardless of the version control scheme. |
| |
| ## Core Clang Tools |
| |
| The core set of Clang tools that are within the main repository are |
| tools that very specifically complement, and allow use and testing of |
| *Clang* specific functionality. |
| |
| ### `clang-check` |
| |
| {doc}`ClangCheck` combines the LibTooling framework for running a |
| Clang tool with the basic Clang diagnostics by syntax checking specific files |
| in a fast, command line interface. It can also accept flags to re-display the |
| diagnostics in different formats with different flags, suitable for use driving |
| an IDE or editor. Furthermore, it can be used in fixit-mode to directly apply |
| fixit-hints offered by clang. See {doc}`HowToSetupToolingForLLVM` for |
| instructions on how to setup and use `clang-check`. |
| |
| ### `clang-format` |
| |
| Clang-format is both a {doc}`library <LibFormat>` and a {doc}`stand-alone tool |
| <ClangFormat>` with the goal of automatically reformatting C++ source files |
| according to configurable style guides. To do so, clang-format uses Clang's |
| `Lexer` to transform an input file into a token stream and then changes all |
| the whitespace around those tokens. The goal is for clang-format to serve both |
| as a user tool (ideally with powerful IDE integrations) and as part of other |
| refactoring tools, e.g. to do a reformatting of all the lines changed during a |
| renaming. |
| |
| ## Extra Clang Tools |
| |
| As various categories of Clang Tools are added to the extra repository, |
| they'll be tracked here. The focus of this documentation is on the scope |
| and features of the tools for other tool developers; each tool should |
| provide its own user-focused documentation. |
| |
| ### `Clang-Doc` |
| |
| [Clang-Doc](https://clang.llvm.org/extra/clang-doc.html) is a tool for |
| generating C and C++ documentation from source code and comments. |
| |
| ### `Clang-Include-Fixer` |
| |
| [Clang-Include-Fixer](https://clang.llvm.org/extra/clang-include-fixer.html) |
| is a tool to automate the addition of missing `#include` directives in a C++ |
| file. It adds missing namespace qualifiers to unidentified symbols when |
| necessary and also removes unused headers. |
| |
| ### `Clang-Tidy` |
| |
| [Clang-Tidy](https://clang.llvm.org/extra/clang-tidy/) is a Clang-based C++ |
| linter tool. It provides an extensible framework for building compiler-based |
| static analyses detecting and fixing bug-prone patterns, performance, |
| portability and maintainability issues. It also has checks for modernizing code |
| to newer language standards. |
| |
| ### `Clangd` |
| |
| [Clangd](https://clangd.llvm.org/) is a language server that can work with |
| many editors via a plugin. It understands your C++ code and adds smart |
| features to your editor: code completion, compile errors, go-to-definition and |
| more. |
| |
| ### `Modularize` |
| |
| [Modularize](https://clang.llvm.org/extra/modularize.html) is a standalone |
| tool that checks whether a set of headers provides the consistent definitions |
| required to use modules. |
| |
| ### `pp-trace` |
| |
| [pp-trace](https://clang.llvm.org/extra/pp-trace.html) is a standalone tool |
| that traces preprocessor activity. It’s also used as a test of Clang’s |
| `PPCallbacks` interface. |
| |
| ## Ideas for new Tools |
| |
| - C++ cast conversion tool. Will convert C-style casts (`(type) value`) to |
| appropriate C++ cast (`static_cast`, `const_cast` or |
| `reinterpret_cast`). |
| |
| - Non-member `begin()` and `end()` conversion tool. Will convert |
| `foo.begin()` into `begin(foo)` and similarly for `end()`, where |
| `foo` is a standard container. We could also detect similar patterns for |
| arrays. |
| |
| - `tr1` removal tool. Will migrate source code from using TR1 library |
| features to C++11 library. For example: |
| |
| ```c++ |
| #include <tr1/unordered_map> |
| int main() |
| { |
| std::tr1::unordered_map <int, int> ma; |
| std::cout << ma.size () << std::endl; |
| return 0; |
| } |
| ``` |
| |
| should be rewritten to: |
| |
| ```c++ |
| #include <unordered_map> |
| int main() |
| { |
| std::unordered_map <int, int> ma; |
| std::cout << ma.size () << std::endl; |
| return 0; |
| } |
| ``` |
| |
| - A tool to remove `auto`. Will convert `auto` to an explicit type or add |
| comments with deduced types. The motivation is that there are developers |
| that don't want to use `auto` because they are afraid that they might lose |
| control over their code. |
| |
| - C++14: less verbose operator function objects ([N3421](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm)). |
| For example: |
| |
| ```c++ |
| sort(v.begin(), v.end(), greater<ValueType>()); |
| ``` |
| |
| should be rewritten to: |
| |
| ```c++ |
| sort(v.begin(), v.end(), greater<>()); |
| ``` |
| |