FreeBSD Manual Pages
INCLUDE-WHAT-YOU-USE(1) User Commands INCLUDE-WHAT-YOU-USE(1) NAME include-what-you-use - analyze includes in C and C++ source files. SYNOPSIS include-what-you-use [-Xiwyu option]... [clang-options] file DESCRIPTION "Include what you use" means this: for every symbol (type, function, variable, or macro) that you use in foo.cpp, either foo.cpp or foo.h should include a header file that exports the declaration of that sym- bol. include-what-you-use is a tool to analyze includes of source files to find "include-what-you-use" violations, and suggest fixes for them. The main goal of include-what-you-use is to remove superfluous in- cludes. It does this both by figuring out what includes are not actu- ally needed for this file (for both source and header files), and by replacing includes with forward declarations when possible. OPTIONS Options for include-what-you-use have to be preceded with -Xiwyu. All other options are interpreted as clang(1) compiler options. --check_also=glob Print "include-what-you-use"-violation info for all files match- ing the given glob pattern (in addition to the default of re- porting for the input source file and associated header files). This flag may be specified multiple times to specify multiple glob patterns. --comment_style=verbosity Controls the style and verbosity of "why" comments at the end of suggested includes. Options for verbosity are: none No "why" comments. short "Why" comments include symbol names, but no namespaces. This is the default. long "Why" comments include symbol names with namespaces. --cxx17ns Use C++17 nested namespaces when suggesting additions of forward declarations. --error[=N] Exit with error code N (defaults to 1 if omitted) if there are "include-what-you-use" violations. --error_always[=N] Exit with error code N (defaults to 1 if omitted) whether there are "include-what-you-use" violations or not (for use with make(1)). --experimental=flag[,flag]* Enable experimental feature. These feature may change or be re- moved without any notice. The flags for current experimental features are: clang_mappings Use Clang libTooling standard library symbol mappings in- stead of internal mappings. This potentially replaces the internal mappings in the future, but is currently experi- mental while the issues are being evaluated. --export_mappings=dirpath Export all IWYU internal mappings as files in dirpath. --keep=glob Always keep the includes matched by glob. This flag may be used multiple times to specify more than one glob pattern. --mapping_file=filename Use the given mapping file. --max_line_length Maximum line length for includes. Note that this only affects the comments and their alignment, the maximum line length can still be exceeded with long filenames (default: 80). --no_comments Do not add comments after includes about which symbols the header was required for. --no_internal_mappings Do not use the internal mappings. --no_fwd_decls Do not use forward declarations, and instead always include the required header. --pch_in_code Mark the first include in a translation unit as a precompiled header. Use --pch_in_code to prevent removal of necessary PCH includes. Although clang(1) forces PCHs to be listed as prefix headers, the PCH-in-code pattern can be used with gcc(1). --prefix_header_includes=value Controls how includes and forward declarations involving prefix headers should be handled. Prefix headers are files included via the command-line option -include. This option specifies what to do if a prefix header makes includes or forward declara- tions obsolete. The following values are allowed: add New includes are added. This is the default. keep No new includes are added, existing ones are kept intact. remove No new includes are added, existing ones are removed. --quoted_includes_first When sorting includes, place quoted includes first. --regex=dialect Use the specified regex dialect for matching in IWYU: llvm Fast and simple extended regular expressions. This is the default. ecmascript Slower but more full-featured regular expressions with support for lookaround assertions, etc. --transitive_includes_only Do not suggest that a file should add foo.h unless foo.h is al- ready visible in the file's transitive includes. --update_comments Print full include list with comments, even if there are no "in- clude-what-you-use" violations. --verbose=level Set verbosity. At the highest level, this will dump the AST of the source file and explain all decisions. EXIT STATUS By default include-what-you-use exits with zero exit code unless there's a critical error, but --error or --error_always can be used to customize the exit code depending on invoker expectations. For an ex- ample see below. MAPPING FILES Sometimes headers are not meant to be included directly, and sometimes headers are guaranteed to include other headers. Since this is hard to tell from the source code alone, these relationships have to be pro- vided via mapping files or pragma comments. A mapping file consists of a comma-separated list of rules enclosed by square brackets []. A rule can be any of the following: { "include": [header, header] } Declares that instead of the first header the second can be used. A header can appear on the left-hand side in multiple rules, meaning that any of the right-hand side headers can be used instead. { "symbol": [symbol, header] } Declares that to use a symbol, a certain header should be in- cluded. { "ref": mapping-file } Includes the contents of another mapping-file. The descriptions of headers and symbols are as follows: header := "include-spec", "visibility" Describes a header file. The include-spec specifies the header file and visibility specifies whether the header is public or private. Private headers are not allowed to be included di- rectly. So every private header file should appear on the left- hand side of a mapping at least once. The visibility of a header file has to be the same for all rules it appears in! include-spec := <system-header-file> | \"project-header-file\" How the header is #included in a source file. Quotation marks need to be escaped. symbol := "symbol-name", "visibility" Describes a symbol, for example a type, function or macro. The visibility is ignored, by convention private is used. Lines starting with # are treated as comments. PRAGMA COMMENTS Pragma comments provide information about the relations between source and header files and allow to whitelist or blacklist #includes and for- ward declarations. All arguments should be enclosed in quotation marks. // IWYU pragma: keep Used after #include directives or forward declarations it en- sures that they won't be removed. // IWYU pragma: begin_keep, // IWYU pragma: end_keep Has the same effect as the previous pragma comment, but applies to a range of #includes and forward declarations instead of a single line. // IWYU pragma: export Used after an #include directive or forward declaration it indi- cates that the current file is considered to be a provider of any symbol from the included file or declaration. // IWYU pragma: begin_exports, // IWYU pragma: end_exports Has the same effect as the previous pragma comment, but applies to a range of #includes or forward declarations instead of a single line. // IWYU pragma: private[, include header] Indicates that the current file is considered private, and (op- tionally) that any symbol will be provided by header. // IWYU pragma: no_include header States that header should not be suggested for inclusion. // IWYU pragma: no_forward_declare symbol States that symbol should not be forward-declared. // IWYU pragma: friend regex Used in a private header, this indicates that all files matching regex are allowed to #include it. // IWYU pragma: associated Used in a source file after an #include directive, this marks the header as associated to the source file. This is required if source and header filename differ in more than their ending. Includes from an associated header are assumed in the source file. // IWYU pragma: always_keep Indicates that includes of the current file should never be re- moved from includers. FILES /usr/share/include-what-you-use Directory containing the standard mapping files. BUGS See the issue tracker <https://github.com/include-what-you-use/include- what-you-use/issues> on GitHub. EXAMPLE It is possible to put include-what-you-use in place of your compiler to process all source files known to your build system make -k CC=include-what-you-use CFLAGS="-Xiwyu --error_always" make -k CXX=include-what-you-use CXXFLAGS="-Xiwyu --error_always" With -Xiwyu --error_always the program always exits with an error code, so the build system knows that it didn't build an object file. Hence the need for -k. It only analyzes source files built by make(1) along with their corresponding header files. If a project has a header file with no corresponding source file, include-what-you-use will ignore it unless you use the --check_also option to add it for analysis together with a source file. CMake has built-in support for include-what-you-use as of version 3.3. With the CMAKE_CXX_INCLUDE_WHAT_YOU_USE option, CMake runs it on every source file after compilation: cmake -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE="include-what-you-use <args>" .. The option is supported for both C and C++, so use CMAKE_C_IN- CLUDE_WHAT_YOU_USE for C code. SEE ALSO clang(1), make(1) include-what-you-use 2025-04-05 INCLUDE-WHAT-YOU-USE(1)
NAME | SYNOPSIS | DESCRIPTION | OPTIONS | EXIT STATUS | MAPPING FILES | PRAGMA COMMENTS | FILES | BUGS | EXAMPLE | SEE ALSO
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=include-what-you-use&sektion=1&manpath=FreeBSD+Ports+15.0.quarterly>