A tool for use with clang to analyze #includes in C and C++ source files


Include What You Use

Build Status

For more in-depth documentation, see docs.

Instructions for Users

"Include what you use" means this: for every symbol (type, function, variable, or macro) that you use in foo.cc (or foo.cpp), either foo.cc or foo.h should include a .h file that exports the declaration of that symbol. (Similarly, for foo_test.cc, either foo_test.cc or foo.h should do the including.) Obviously symbols defined in foo.cc itself are excluded from this requirement.

This puts us in a state where every file includes the headers it needs to declare the symbols that it uses. When every file includes what it uses, then it is possible to edit any file and remove unused headers, without fear of accidentally breaking the upwards dependencies of that file. It also becomes easy to automatically track and update dependencies in the source code.


This is alpha quality software -- at best (as of July 2018). It was originally written to work specifically in the Google source tree, and may make assumptions, or have gaps, that are immediately and embarrassingly evident in other types of code.

While we work to get IWYU quality up, we will be stinting new features, and will prioritize reported bugs along with the many existing, known bugs. The best chance of getting a problem fixed is to submit a patch that fixes it (along with a test case that verifies the fix)!

How to Build

Include-what-you-use makes heavy use of Clang internals, and will occasionally break when Clang is updated. Usually such discrepancies are detected by build bot and fixed promptly.

The IWYU master branch follows Clang main branch.

We also have convenience tags and branches for released versions of Clang (called clang_<version>, e.g. clang_5.0). To build against a Clang release, check out the corresponding branch in IWYU before configuring the build. More details in the instructions below.

We assume you already have compiled LLVM and Clang libraries on your system, either via packages for your platform or built from source. You can use this mapping table to combine Clang and IWYU versions correctly:

Clang IWYU version IWYU branch
3.6 0.4 clang_3.6
3.7 0.5 clang_3.7
3.8 0.6 clang_3.8
3.9 0.7 clang_3.9
4.0 0.8 clang_4.0-r2
5.0 0.9 clang_5.0
6 0.10 clang_6.0
7 0.11 clang_7.0
8 0.12 clang_8.0
9 0.13 clang_9.0
10 0.14 clang_10
11 0.15 clang_11
... ... ...
main master

NOTE: If you use the Debian/Ubuntu packaging available from https://apt.llvm.org, you'll need the following packages installed:

  • llvm-<version>-dev
  • libclang-<version>-dev
  • clang-<version>

Packaging for other platforms will likely be subtly different.

To set up an environment for building:

  • Create a directory for IWYU development, e.g. iwyu

  • Clone the IWYU Git repo:

    iwyu$ git clone https://github.com/include-what-you-use/include-what-you-use.git
  • Presumably, you'll be building IWYU with a released version of LLVM and Clang, so check out the corresponding branch. For example, if you have Clang 6.0 installed, use the clang_6.0 branch. IWYU master tracks LLVM & Clang main:

    iwyu$ cd include-what-you-use
    iwyu/include-what-you-use$ git checkout clang_6.0
  • Create a build root and use CMake to generate a build system linked with LLVM/Clang prebuilts:

    # This example uses the Makefile generator, but anything should work.
    iwyu/include-what-you-use$ cd ..
    iwyu$ mkdir build && cd build
    # For IWYU 0.10/Clang 6 and earlier
    iwyu/build$ cmake -G "Unix Makefiles" -DIWYU_LLVM_ROOT_PATH=/usr/lib/llvm-6.0 ../include-what-you-use
    # For IWYU 0.11/Clang 7 and later
    iwyu/build$ cmake -G "Unix Makefiles" -DCMAKE_PREFIX_PATH=/usr/lib/llvm-7 ../include-what-you-use

    (substitute the llvm-6.0 or llvm-7 suffixes with the actual version compatible with your IWYU branch)

    or, if you have a local LLVM and Clang build tree, you can specify that as CMAKE_PREFIX_PATH for IWYU 0.11 and later:

    iwyu/build$ cmake -G "Unix Makefiles" -DCMAKE_PREFIX_PATH=~/llvm-project/build ../include-what-you-use
  • Once CMake has generated a build system, you can invoke it directly from build, e.g.

    iwyu/build$ make

Instructions for building Clang are available at https://clang.llvm.org/get_started.html.

How to Install

If you're building IWYU out-of-tree or installing pre-built binaries, you need to make sure it can find Clang built-in headers (stdarg.h and friends.)

Clang's default policy is to look in path/to/clang-executable/../lib/clang/<clang ver>/include. So if Clang 3.5.0 is installed in /usr/bin, it will search for built-ins in /usr/lib/clang/3.5.0/include.

Clang tools have the same policy by default, so in order for IWYU to analyze any non-trivial code, it needs to find Clang's built-ins in path/to/iwyu/../lib/clang/3.5.0/include where 3.5.0 is a stand-in for the version of Clang your IWYU was built against.

Note that some distributions/packages may have different defaults, you can use clang -print-resource-dir to find the base path of the built-in headers on your system.

So for IWYU to function correctly, you need to copy the Clang include directory to the expected location before running (similarly, use include-what-you-use -print-resource-dir to learn exactly where IWYU wants the headers).

This weirdness is tracked in issue 100, hopefully we can make this more transparent over time.

How to Run

The original design was built for Make, but a number of alternative run modes have come up over the years.

Plugging into Make

The easiest way to run IWYU over your codebase is to run

  make -k CXX=/path/to/llvm/Debug+Asserts/bin/include-what-you-use


  make -k CXX=/path/to/llvm/Release/bin/include-what-you-use

(include-what-you-use always exits with an error code, so the build system knows it didn't build a .o file. Hence the need for -k.)

Include-what-you-use only analyzes .cc (or .cpp) files built by make, along with their corresponding .h files. If your project has a .h file with no corresponding .cc file, IWYU will ignore it unless you use the --check_also switch to add it for analysis together with a .cc file.

Using with CMake

CMake has grown native support for IWYU as of version 3.3. See their documentation for CMake-side details.

The CMAKE_CXX_INCLUDE_WHAT_YOU_USE option enables a mode where CMake first compiles a source file, and then runs IWYU on it.

Use it like this:

  mkdir build && cd build
  CC="clang" CXX="clang++" cmake -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE="path/to/iwyu;-Xiwyu;any;-Xiwyu;iwyu;-Xiwyu;args" ...

or, on Windows systems:

  mkdir build && cd build
  cmake -DCMAKE_CXX_COMPILER="%VCINSTALLDIR%/bin/cl.exe" -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE="path/to/iwyu;-Xiwyu;any;-Xiwyu;iwyu;-Xiwyu;args" -G Ninja ...

The option appears to be separately supported for both C and C++, so use CMAKE_C_INCLUDE_WHAT_YOU_USE for C code.

Note that with Microsoft's Visual C++ compiler, IWYU needs the --driver-mode=cl argument to understand the MSVC options from CMake.

Using with a compilation database

The iwyu_tool.py script predates the native CMake support, and works off the compilation database format. For example, CMake generates such a database named compile_commands.json with the CMAKE_EXPORT_COMPILE_COMMANDS option enabled.

The script's command-line syntax is designed to mimic Clang's LibTooling, but they are otherwise unrelated. It can be used like this:

  mkdir build && cd build
  CC="clang" CXX="clang++" cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ...
  iwyu_tool.py -p .

or, on Windows systems:

  mkdir build && cd build
  python iwyu_tool.py -p .

Unless a source filename is provided, all files in the project will be analyzed.

See iwyu_tool.py --help for more options.

Applying fixes

We also include a tool that automatically fixes up your source files based on the IWYU recommendations. This is also alpha-quality software! Here's how to use it (requires python):

  make -k CXX=/path/to/llvm/Debug+Asserts/bin/include-what-you-use 2> /tmp/iwyu.out
  python fix_includes.py < /tmp/iwyu.out

If you don't like the way fix_includes.py munges your #include lines, you can control its behavior via flags. fix_includes.py --help will give a full list, but these are some common ones:

  • -b: Put blank lines between system and Google includes
  • --nocomments: Don't add the 'why' comments next to includes

How to Correct IWYU Mistakes

  • If fix_includes.py has removed an #include you actually need, add it back in with the comment '// IWYU pragma: keep' at the end of the #include line. Note that the comment is case-sensitive.
  • If fix_includes.py has added an #include you don't need, just take it out. We hope to come up with a more permanent way of fixing later.
  • If fix_includes.py has wrongly added or removed a forward-declare, just fix it up manually.
  • If fix_includes.py has suggested a private header file (such as <bits/stl_vector.h>) instead of the proper public header file (<vector>), you can fix this by inserting a specially crafted comment near top of the private file (assuming you can write to it): '// IWYU pragma: private, include "the/public/file.h"'.

Current IWYU pragmas are described in IWYUPragmas.

  • Precompiled-headers support with --prefix_header_includes?

    Precompiled-headers support with --prefix_header_includes?

    Originally reported on Google Code with ID 126

    I am trying to figure out if there is any support for precompiled headers with iwyu.
    The only thing I found is to provide the precompiled header to clang with -include
    and --prefix_header_includes with to iwyu. However the results are not what I expected.
    For the test I am attaching, the command line reads like this:
    F:\tests\build\bin\Release\include-what-you-use.exe F:\tests\iwyutest\iwyutest\iwyutest.cpp
    -w -MD -I"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include" -IF:\tests\iwyutest
    -IF:\tests\iwyutest\iwyutest -DWIN32 -DNDEBUG -D_CONSOLE -D_UNICODE -include F:\tests\iwyutest\iwyutest\stdafx.h
    -Xiwyu --prefix_header_includes=remove
    And the result is this:
    F:/tests/iwyutest/iwyutest/iwyutest.cpp should add these lines:
    #include "tchar.h"                      // for _TCHAR, _tmain
    F:/tests/iwyutest/iwyutest/iwyutest.cpp should remove these lines:
    - #include "stdafx.h"  // lines 4-4
    The full include-list for F:/tests/iwyutest/iwyutest/iwyutest.cpp:
    #include "tchar.h"                      // for _TCHAR, _tmain
    Both suggestions seem incorrect right?
    1) #include "tchar.h" should not be necessary because it's already included in stdafx.h
    2) stdafx.h is needed because this is a precompiled header (although I can understand
    that if there is no real support for this it can complain about it)
    Am I doing something wrong here?

    Reported by dpunset on 2014-04-10 14:58:55

    - _Attachment: [iwyutest.rar](https://storage.googleapis.com/google-code-attachments/include-what-you-use/issue-126/comment-0/iwyutest.rar)_ Type-Defect Priority-Medium 
    opened by vsapsai 58
  • Assertion failed: class_decl &&

    Assertion failed: class_decl && "TemplateSpecializationType is not a TplSpecDecl?"

    Originally reported on Google Code with ID 150

    I'm trying to use iwyu with http://github.com/mapbox/mapbox-gl-native on OS X 10.9.
    I compiled iwyu against a clang 3.4.2 final stable.
    I'm running this command:
    CXX="include-what-you-use -Xiwyu --verbose=3 -isystem\"`xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1\""
    make linux
    and the first command gyp generates is
      include-what-you-use -Xiwyu --verbose=3 -isystem"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1"
    '-DNDEBUG' -I../../include -I../Release/obj/gen/include  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
    -fasm-blocks -mpascal-strings -O3 -mmacosx-version-min=10.9 -arch x86_64 -std=c++11
    -stdlib=libc++ -fvisibility-inlines-hidden -Wall -Wextra -I/usr/local/Cellar/libpng/1.6.10/include/libpng16
    -I/usr/local/include -I/Users/kkaefer/Code/gl/native/mapnik-packaging/osx/out/build-cpp11-libcpp-universal/include
    -MMD -MF ../Release/.deps/../Release/obj.target/llmr-x86/src/clipper/clipper.o.d.raw
     -c -o ../Release/obj.target/llmr-x86/src/clipper/clipper.o ../../src/clipper/clipper.cpp
    which fails with
    /Users/kkaefer/Code/include-what-you-use/iwyu.cc:3081: Assertion failed: class_decl
    && "TemplateSpecializationType is not a TplSpecDecl?"
    make[1]: *** [../Release/obj.target/llmr-x86/src/clipper/clipper.o] Abort trap: 6

    Reported by [email protected] on 2014-06-17 14:38:03

    Type-Defect Priority-Medium Cxx11 
    opened by vsapsai 43
  • Absolute for relative path replacement

    Absolute for relative path replacement

    Originally reported on Google Code with ID 5

    When the compile line refers to a source file by its absolute name iwyu suggests that
    the includes be changed to absolute:
    jason$ cat Foo.h
    #ifndef _FOO_H_
    #define _FOO_H_
    class Foo {
    jason$ cat Foo.cpp
    #include "Foo.h"
    Foo::Foo() {}
    jason$ include-what-you-use /Users/jason/Desktop/iwyu/Foo.cpp
    /Users/jason/Desktop/iwyu/Foo.cpp should add these lines:
    #include </Users/jason/Desktop/iwyu/Foo.h>  // for Foo
    /Users/jason/Desktop/iwyu/Foo.cpp should remove these lines:
    - #include "Foo.h"  // lines 1-1
    The full include-list for /Users/jason/Desktop/iwyu/Foo.cpp:
    #include </Users/jason/Desktop/iwyu/Foo.h>  // for Foo
    However when referring to the source file by relative name the output is as expected:
    jason$ ~/Sources/llvm/build/bin/include-what-you-use Foo.cpp
    (Foo.cpp has correct #includes/fwd-decls)

    Reported by jason.haslam on 2011-02-07 07:24:43

    Type-Defect Priority-Medium 
    opened by vsapsai 42
  • In-tree build is not working (inconsistency in registered CommandLine or core dumped)

    In-tree build is not working (inconsistency in registered CommandLine or core dumped)

    When building IWYU in tree with either clang 4.0.1 or clang 5.0, the compilation succeed but I do end up with an unusable executable:

    $ include-what-you-use
    : CommandLine Error: Option 'asan-instrument-assembly' registered more than once!
    LLVM ERROR: inconsistency in registered CommandLine options

    I seek the issue a little bit and found some LLVM bug reference (https://reviews.llvm.org/rL240104) speaking of double link to some LLVM static lib. I did examine the link line for IWYU and discover a lot of duplicates. In fact all LLVM libs where duplicated on the command line.

    I commented out the

        LLVMX86AsmParser # MC, MCParser, Support, X86CodeGen, X86Desc, X86Info

    in IWYU CMakeLists.txt and I end up with an apparently working iwyu:

    $ include-what-you-use
    error: no input files
    error: unable to handle compilation, expected exactly one compiler job in ''
    $ include-what-you-use --version
    include-what-you-use 0.9 (git:576e80f) based on clang version 5.0.0 (tags/RELEASE_500/final)

    However on a "real" call using compilation database generated by CMake on my project (which correctly builds with either clang 4.0.1 or clang 5.0.0) I get core dumped.

    My LLVM+Clang+IWYU build uses CMake + Ninja with the following parameters:

    MY_LIBS=clang MY_VERSION=5.0 INSTALL_DIR=/local/clang cmake .. -G Ninja

    What should I do to get a working IWYU in-tree build?

    opened by TheErk 41
  • Also add include in same directory

    Also add include in same directory

    This fixes a bug where absolute paths are unnecessarily used for a header resulting even in inclusion of unwanted headers as described in #272

    The problem arises, as the directory of the file, which is implicitely added to the search path, is not honored. See #271 for this.

    This supersedes the patch(es) in #5 and should also close those issues. This solution is better, than adding the main-files directory to the search path, as this does not add it globally which can cause problems if headers are checked, which might not be in the same directory as the main-file.

    • [x] All tests run successfully
    • [x] Fix verified by testing the test-case from #271 manually
    • [x] Remove IndirectSubfolderClass from direct_subfolder.h
    • [x] Rebase and remove DEVTOOLS_MAINTENANCE_ from tests
    opened by Flamefire 39
  • Allow build outside of clang source tree

    Allow build outside of clang source tree

    Originally reported on Google Code with ID 64

    I would like to package your work into Debian. However, the fact that include-what-you-use
    needs the clang source tree greatly complexifies the build process.
    It would be nice if you could update your work to build against clang headers and libs.
    Here is a list of headers provided by the libclang-dev package in Debian and Ubuntu:

    Reported by sylvestre.ledru on 2011-12-11 16:50:44

    Priority-Medium Type-Enhancement 
    opened by vsapsai 37
  • Unused templates are ignored on Windows

    Unused templates are ignored on Windows

    Originally reported on Google Code with ID 129

    Steps to reproduce:
    1. Run IWYU on Windows on a file
        #include "tests/cxx/direct.h"
        template <typename T> void foo() {
          IndirectClass ic;
    Actual result:
    IWYU recommends to remove #include "tests/cxx/direct.h".
    Expected result:
    IWYU should recommend to remove #include "tests/cxx/direct.h" and to add #include "tests/cxx/indirect.h".

    Reported by vsapsai on 2014-04-24 16:03:06

    Type-Defect Priority-Medium 
    opened by vsapsai 36
  • Avoid reporting type for

    Avoid reporting type for "autocast" for function definition

    A function may just transmit passed-by-reference parameter to somewhere. Requirement to explicitly write forward declaration in the same file (.cpp-file) to avoid #include suggestion is impractical when that type is already fwd-declared in the corresponding header.

    I'm not sure about this change. Autocast to parameter of defined function still makes sense when the function definition is in header:

    inline void ProcessString(const StringWrapper& sw)
      stringProcessor.process(sw); // passed by reference

    Maybe, to check whether the function is inline? Or there may be some better heuristics?

    opened by bolshakov-a 31
  • Treat explicit instantiations as full uses

    Treat explicit instantiations as full uses

    Modify IsFowardDecl() to check that the decl is not an explicit template instantiation (declaration or definition) This check is also in its own function, IsExplicitInstantiation(), for convenience.

    opened by jru 31
  • Install clang resources

    Install clang resources

    This is a potential fix for the years-old #100.

    The key problem in that issue is that iwyu needs to know at runtime where the clang resource headers are. If it is built in tree or installed into the same tree as llvm, that just works, but for out-of-tree use cases fail. I'm adding two solutions to this:

    1. ask the out-of-tree clang at build-time where it's resource headers are, remember and use that location at runtime.
    2. add an override to this default. This is mainly relevant when installing iwyu on a system or when you're shipping your own headers for some reason. On top of this, headers can optionally be bundled with the installation to make this work without clang present.
    opened by pfaffe 30
  • Plain cmake

    Plain cmake

    It looks like Debian packaging for Clang is fixed now, so simplify CMakeLists.txt and documentation.

    This PR is mostly to see if Travis picks up the change and builds correctly.

    opened by kimgr 30
  • `<tuple>` suggested for `std::array` - confused by `<map>`

    `` suggested for `std::array` - confused by ``

    #include <array>
    #include <cstddef>
    #include <string>
    #include <map> // removing this will get rid of the messages
    #include <utility>
    template<std::size_t N>
    static void f(const std::array<std::pair<std::string, std::string>, N>&)
        std::map<int, int> m; // added so <map> is not unused
    test.cpp should add these lines:
    #include <tuple>    // for array
    test.cpp should remove these lines:
    - #include <array>  // lines 1-1
    The full include-list for test.cpp:
    #include <cstddef>  // for size_t
    #include <map>      // for map
    #include <string>   // for string
    #include <tuple>    // for array
    #include <utility>  // for pair

    I am using include-what-you-use 0.18 based on Debian clang version 14.0.6-2.

    opened by firewave 0
  • IWYU wants to remove includes for types that are needed in template default values

    IWYU wants to remove includes for types that are needed in template default values

    Here's an example:

    #include "BaseClass.h"
    template<typename TheSizeType>
    struct TSizeLargerThan4
    	static inline constexpr bool TheValue = sizeof(TheSizeType) > 4;
    template <typename TheType, bool bIsSizeLarger = TSizeLargerThan4<TheType>::TheValue>
    struct TGetCastType2
    	static inline constexpr bool SizeValue = bIsSizeLarger;
    void myfunc()
    	auto v = TGetCastType2<BaseClass>::SizeValue;

    In the above code IWYU wants to turn BaseClass into a forward declaration (but it is needed for the sizeof())

    Trying to figure out where this code lives but again, happy for pointers.

    opened by honkstar1 22
  • Implicit cast through Ctor(T&&) removes include that is needed

    Implicit cast through Ctor(T&&) removes include that is needed


    ---BaseClass.h--- class BaseClass {};


    #include "BaseClass.h"
    class SubClass : public BaseClass {};


    #include "SubClass.h"
    template <typename T>
    struct TObjectPtr2
    	template <typename U> TObjectPtr2(U&& Object) : ObjectPtr(Object) {}
    	T* ObjectPtr;
    struct TestClass
    	TObjectPtr2<BaseClass> Foo;
    	TestClass(SubClass* InFoo) : Foo(InFoo) {}

    Above code does not work.. it strips out #include of SubClass.h (even though it is needed for the cast in TestClass ctor)

    If I change "U&& Object" to "U* Object" in TObjectPtr2 ctor it works fine.

    I have attached verbosed logging of working and broken (they might not match the above names but is the exact same scenario). Will debug this tomorrow but is happy for pointers (no pun intended :-))

    Broken.txt Working.txt

    Thanks, Henrik

    opened by honkstar1 4
  • More

    More ".." in include path than folders in additional include dir (which is not absolute)

    I've run into a problem where our response file contains relative paths and an include is looking like this "../../Foo.h"

    When LLVM returns the string from clang::FileEntry::getName() it returns a combined relative include dir and include.

    So in my case I have a relative include path "MyFolder"

    The returned path from LLVM is "MyFolder/../../Foo.h"

    This is then sent in to NormalizeFilePath (inside iwyu_path_util.cc) which tries to normalize this using llvm::sys::path::remove_dots.

    The result ends up being wrong since there are more ".." than there are folders to remove.

    I now bit the bullet and updated all the 34000 response files in our solution to all have absolute paths which solved my situation (they are generated so I didn't manually go through those files :-)). I wanted to report this since it was not obvious what went wrong (it silently failed and output got wrong)..

    Thanks, Henrik

    opened by honkstar1 1
  • inconsistent source of `size_t`

    inconsistent source of `size_t`


    #include "test.h"
    #include <cstring>
    static void f()
        size_t pos;
        std::strchr((const char*)NULL, 'i');


    #ifndef testH
    #define testH
    #include <cstddef>
    #include <cstring>
    void flags() {
        std::size_t pos;
        std::strchr((const char*)NULL, 'i');
    test.h should add these lines:
    test.h should remove these lines:
    - #include <cstddef>  // lines 4-4
    The full include-list for test.h:
    #include <cstring>  // for strchr, NULL, size_t
    test.cpp should add these lines:
    #include <cstddef>  // for NULL, size_t
    test.cpp should remove these lines:
    The full include-list for test.cpp:
    #include "test.h"
    #include <cstddef>  // for NULL, size_t
    #include <cstring>  // for strchr
    opened by firewave 4
  • 0.19(Nov 2, 2022)

    Compatible with Clang 15.

    • [iwyu] New --comment_style option to control verbosity of 'why' comments
    • [iwyu] New --regex option to select regex dialect
    • [iwyu] Add support for regex replacement in mappings
    • [iwyu] Add begin_keep/end_keep pragmas for protecting ranges of includes or forward-declares
    • [iwyu] Fix several crasher bugs for unusual inputs
    • [iwyu] More exhaustive handling of type aliases and enums
    • [iwyu] Recognize IWYU pragmas in CRLF source files
    • [iwyu] Respect configured toolchain on macOS (and overrides via -nostdinc++ + -isystem)
    • [fix_includes] Recognize namespace alias declarations
    • [mappings] Improve mappings for POSIX and libc headers
    • [cmake] Build now requires a C++17 compiler (as does LLVM)
    • [cmake] Support LLVM external project build (see README)

    ... and many other changes

    Source code(tar.gz)
    Source code(zip)
  • 0.18(Mar 31, 2022)

    • [iwyu] Fix crash on C++20 consteval expressions
    • [iwyu] Use more conventional exit codes (breaking change!)
    • [iwyu_tool] Fix deprecation warning for python3
    • [iwyu] Fix crash on va_list on AArch64
    • [iwyu] Improved support for using declarations based on new Clang design

    Note the breaking change for exit codes; IWYU now always returns zero by default. See the README or help text for more information about compatibility overrides.

    Source code(tar.gz)
    Source code(zip)
  • 0.17(Dec 5, 2021)

    • [iwyu] Improve support for various C++ features (builtins, CTAD, specializations, type aliases)
    • [iwyu] Fix crash on invalid code
    • [iwyu] Remove hard dependency on x86 LLVM target
    • [mappings] Improve mappings for GNU libc
    • [iwyu_tool] More concise output for clang output format
    Source code(tar.gz)
    Source code(zip)
  • 0.16(May 25, 2021)

    • [iwyu_tool] Accept --load/-l argument for load limiting
    • [iwyu_tool] Signal success/failure with exit code
    • [mappings] Harmonize mapping generators
    • [mappings] Add mapping generator for CPython
    • [mappings] Improve mappings for libstdc++ and Boost
    • [cmake] Add explicit C++14 compiler flag
    • ... and many internal improvements
    Source code(tar.gz)
    Source code(zip)
  • 0.15(Nov 21, 2020)

    • [iwyu] Fix crash due to undefined behavior in AST traversal
    • [iwyu] Improve handling of operator new including C++17 features
    • [iwyu] Improve handling of templates
    • [iwyu_tool] Remove known compiler wrappers from the command list
    • [mappings] Improve Qt mapping generator
    • [mappings] Improve boost mappings
    • [mappings] Improve built-in mappings for <time.h>
    • [mappings] Add built-in mappings for max_align_t, ptrdiff_t, and wchar_t
    • [cmake] Support shared LLVM/Clang libraries and other improvements
    Source code(tar.gz)
    Source code(zip)
  • 0.14(May 17, 2020)

    • [iwyu] Report non-builtin enum base types
    • [iwyu] Disable forward-declares for decls in inline namespaces
    • [iwyu] Make C structs forward-declarable again
    • [iwyu] Always keep Qt .moc includes
    • [iwyu] Include binary type traits in analysis (e.g. __is_convertible_to)
    • [iwyu_tool] Fail fast if include-what-you-use is not found
    • [iwyu_tool] Print all diagnostic ouptut to stderr
    • [fix_includes] Improve file extension detection
    • Add man page for include-what-you-use
    Source code(tar.gz)
    Source code(zip)
  • 0.13(May 17, 2020)

    • [iwyu] Improved handling of relative includes in mappings and pragmas
    • [iwyu] Path normalization now collapses ..
    • [iwyu] Improve --no_fwd_decls not to remove required forward declarations
    • [iwyu] Improved handling of builtin templates
    • [iwyu] Don't mark forward declarations final
    • [iwyu] Tolerate using declarations in precompiled header
    • [mappings] Add script to generate Qt mappings, and new mappings for Qt 5.11
    • [iwyu_tool] Use directory from compilation database if available
    • Numerous documentation and build improvements
    Source code(tar.gz)
    Source code(zip)
  • clang_8.0(Apr 14, 2019)

    • [iwyu] New command-line option: --keep to mirror IWYU pragma: keep
    • [iwyu] New command-line option: --cxx17ns to suggest compact C++17 nested namespaces
    • [iwyu] Improve --no_fwd_decls to optimize for minimal number of redeclarations
    • [iwyu] Improved mappings for POSIX types and let mappings apply to builtins as well
    • [iwyu] More principled handling of explicit template instantiations
    • [iwyu_tool] Breaking change: extra args are no longer automatically prefixed with -Xiwyu (so you can use them for Clang args too)
    • [iwyu_tool] Better Windows support
    • [fix_includes] Better handling of template forward-decls
    Source code(tar.gz)
    Source code(zip)
  • 0.11(Dec 8, 2018)

    • [iwyu] Improved recognition of template and specialization uses
    • [iwyu] Improved CMake build system, see docs for build instructions
    • [mappings] Improved mappings for Boost, Intel intrinsics and libstdc++
    • [iwyu_tool] Several bug fixes and improvements
    • [iwyu_tool] Add --basedir argument to interpret IWYU output from another source tree
    • [fix_includes] Handle namespaces better
    • [fix_includes] Add --only_re switch to filter affected files
    • [fix_includes] Add --reorder/--noreorder switch to toggle reordering of includes
    Source code(tar.gz)
    Source code(zip)
  • clang_6.0(Apr 29, 2018)

  • clang_5.0(Feb 4, 2018)

Qt-oriented static code analyzer based on the Clang framework

WARNING: master is the development branch. Please use the v1.10 branch. clazy v1.11 clazy is a compiler plugin which allows clang to understand Qt sem

KDE GitHub Mirror 547 Nov 7, 2022
ELF static analysis and injection framework that parse, manipulate and camouflage ELF files.

elfspirit elfspirit is a useful program that parse, manipulate and camouflage ELF files. It provides a variety of functions, including adding or delet

null 16 Nov 10, 2022
CMetrics measures size and complexity for C files

C metrics package ================= INSTALL ------- see INSTALL file USAGE ----- cmetrics [-h] [-f] [-p] [-n] target_dir positional arguments:

Metrics Grimoire 63 Sep 27, 2022
Tool to check C++ #include dependencies (dependency graphs created in .dot format)

Read Me for Dependency Checker Copyright (C) 2012-2017, TomTom International BV. All rights reserved. The tool cpp-dependencies creates #include depen

TomTom 672 Nov 20, 2022
A static analysis tool that helps security researchers scan a list of Windows kernel drivers for common vulnerability patterns in drivers (CVE makers!)

Driver Analyzer A static analysis tool that helps security researchers scan a list of Windows kernel drivers for common vulnerability patterns in driv

BehroozAbbassi 44 Sep 3, 2022
A static analyzer for Java, C, C++, and Objective-C

Infer Infer is a static analysis tool for Java, C++, Objective-C, and C. Infer is written in OCaml. Installation Read our Getting Started page for det

Facebook 13.7k Nov 24, 2022
Analysis of Argon and Xenon Collision data to test Bardeen-Cooper-Schrieffer Approximation

Univeristy of North Carolina Wilmington Analysis of Argon and Xenon Collision data to test Bardeen-Cooper-Schrieffer Approximation. Argon Data Tree Fi

William Jarratt 0 Aug 25, 2022
Flint++ is cross-platform, zero-dependency port of flint, a lint program for C++ developed and used at Facebook.

Flint++ A Cross Platform Port of Facebook's C++ Linter Flint++ is cross-platform, zero-dependency port of flint, a lint program for C++ developed and

Joss Whittle 256 Oct 17, 2022
A tool for use with clang to analyze #includes in C and C++ source files

Include What You Use For more in-depth documentation, see docs. Instructions for Users "Include what you use" means this: for every symbol (type, func

null 3.1k Nov 22, 2022
A distribution of the cFS that includes the cfe-eds-framework which includes NASA's core Flight Executive(cFE) and CCSDS Electronic Data Sheets(EDS) support.

core Flight System(cFS) Application Toolkit(cFSAT) - Beta Release A distribution of the cFS that includes the cfe-eds-framework which includes NASA's

OpenSatKit 13 Jul 3, 2022
Strings Analyze tool for all platforms

Strings Analyze Inspired by @UnrealSecurity Strings Analyze Strings Analyze is a tool for all platform to analyze string dumps from process' memory or

Austin 3 Oct 11, 2021
Bear is a tool that generates a compilation database for clang tooling.

ʕ·ᴥ·ʔ Build EAR Bear is a tool that generates a compilation database for clang tooling. The JSON compilation database is used in the clang project to

László Nagy 3.1k Nov 19, 2022
Clang build analysis tool using -ftime-trace

Clang Build Analyzer Clang C/C++ build analysis tool when using Clang 9+ -ftime-trace. The -ftime-trace compiler flag (see blog post or Clang 9 releas

Aras Pranckevičius 702 Nov 16, 2022
A program and toolset to analyze iDevice USB sessions

A program and toolset to analyze iDevice USB sessions

T2 Development Team 24 Nov 12, 2022
Development of a system which can capture and analyze transmitted data on a USB wire.

FPGA based USB protocol analyser Development of a system which can capture and analyze transmitted data on a

Harsha Sandirigama 0 Apr 3, 2022
Calleree helps to analyze Ruby's caller-callee relationships.

Calleree Calleree helps to analyze Ruby's caller-callee relationships. Note that this tool consumes memory and introduces additional overhead because

Koichi Sasada 18 Oct 3, 2022
Analyze patches in a process for investigation or repairment purposes.

HookHunter Analyze patches in a process for investigation or repairment purposes. Details HookHunter is a multi-purpose Windows tool that can search a

null 192 Nov 13, 2022
Binary Ninja plugin & workflow to help analyze Objective-C code

Objective Ninja Objective Ninja is a Binary Ninja plugin to assist in reverse engineering Objective-C code. Beware, Objective Ninja is still in very e

Jon Palmisciano 80 Aug 16, 2022
Analyze precision

analyze-precision Analyze fix-point precision for unary functions This program allows, for a given unary function, to explore the relations between th

Yann Orlarey 2 May 3, 2022