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

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

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 {
  Foo();
};

#endif

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

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

 target_link_libraries(include-what-you-use
    LLVMX86AsmParser # MC, MCParser, Support, X86CodeGen, X86Desc, X86Info
...
    LLVMDemangle
    )

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
-DCLANG_ENABLE_BOOTSTRAP=On
-DCMAKE_BUILD_TYPE=MinSizeRel
-DCMAKE_CXX_FLAGS="-Wl,-rpath=${INSTALL_DIR}/lib/"
-DLLVM_TARGETS_TO_BUILD="X86"
-DLLVM_ENABLE_CXX1Y=On
-DLLVM_LINK_LLVM_DYLIB=On
-DLIBOMP_TSAN_SUPPORT=On
-DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_DIR}/${MY_LIBS}/${MY_VERSION}/

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

Shouldn't this just output a diagnostic like everything else? I mean it's a legitimate coding error that someone can make which would not cause a compile error (which is indeed how I found this assertion, I had a header file which inadvertently included itself).

// Foo.h
#ifndef FOO_H
#define FOO_H
#include "Foo.h"  // iwyu asserts, but any compiler will happily accept this.
#endif

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

Originally reported on Google Code with ID 64

Hi

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:
http://packages.debian.org/sid/amd64/libclang-dev/filelist

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

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

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?

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.

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.

Reporting typedef declarations doesn't make sense when typedef type isn't explicitly written (similar to #1079 and #1173).

Previously, ReportDeclUse was called for TypedefDecl when TypedefType is passed to ReportTypeUse. This change short-circuits that path. But an underlying type should still be reported if the typedef doesn't "provide" it. Hence, corresponding logic is moved into ReportTypeUse. So ReportDeclUse reports typedef declarations and ReportTypeUse reports typedef underlying types now.

@bolshakov-a Your CanIgnoreType call stuck in the back of my head, and I eventually got around to generalizing it. This seems to work well (as in: no tests fail).

If the approach makes sense to you, I'll try and cook up some test cases to lock this down.

Should fix: #1004 and #1110. For some reason all the other related problems no longer reproduce on master.#1178

Let me know what you think.

I have a header with custom streaming operators (std::ostream &operator<<(std::ostream &out, const Class &object);). IWYU suggests removing that header, resulting in compilation errors due to the undefined streaming operator.

Thanks for all your work on iwyu. I can't imagine sorting out my dependency messes without it :)

I've recently seen an issue where iwyu will suggest a forward-declaration instead of a #include for Dependency here:

// user/user.cpp
#include <dependency.h>
#include <typeindex>

auto useTypeIndexOfDependency(const Dependency &dependency) -> void {
  std::type_index type = typeid(dependency);
}

$ iwyu_tool -p build user/user.cpp

/home/matthew/Documents/iwyu/minimal-example/user/user.cpp should add these lines:
class Dependency;

/home/matthew/Documents/iwyu/minimal-example/user/user.cpp should remove these lines:
- #include <dependency.h>  // lines 1-1

The full include-list for /home/matthew/Documents/iwyu/minimal-example/user/user.cpp:
#include <typeindex>  // for type_index
class Dependency;
---

If I follow its suggestion, I get

[ 50%] Building CXX object user/CMakeFiles/user.dir/user.cpp.o
/home/matthew/Documents/iwyu/minimal-example/user/user.cpp: In function ‘void useTypeIndexOfDependency(const Dependency&)’:
/home/matthew/Documents/iwyu/minimal-example/user/user.cpp:5:33: error: invalid use of incomplete type ‘class Dependency’
    5 |   std::type_index type = typeid(dependency);
      |                                 ^~~~~~~~~~
/home/matthew/Documents/iwyu/minimal-example/user/user.cpp:2:7: note: forward declaration of ‘class Dependency’
    2 | class Dependency;
      |       ^~~~~~~~~~
make[2]: *** [user/CMakeFiles/user.dir/build.make:82: user/CMakeFiles/user.dir/user.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:134: user/CMakeFiles/user.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

I believe this is because you cannot apply typeid to an incomplete type.

I tested this with

$ include-what-you-use --version
include-what-you-use 0.15 based on Debian clang version 11.0.1-2

which is the current version on Debian Stable.

I've uploaded a full minimal example here.

I would be happy to spend some time to contribute a fix for this, if that would help. Equally, if there's any extra information that I can provide, then let me know.

But I wanted to check:

• do you also think it's an issue, or have I missed something?
• if you'd like me to work on a fix - where would be the best place to make this change in the code?

Thanks again for all your work on this tool.

Using type deduction, a function can define a local type and return it:

auto func() {
  struct X {};
  return X();
}

Before this change, IWYU would register X as a use for callers of func.

In certain situations (union inside lambda inside macro) this would lead to a forward-declare use trying to format a forward-declaration of the type local to the function in PrintForwardDeclare. This led to a crash since the lambda was unnamed, but there's really no point trying to forward-declare a type that is private to a function.

Generalize this so we ignore all uses of symbols declared inside a function. In order to get in contact with that symbol, we must already have access to the function, so the containing header must already be included.

Fixes issue: #795