Include-what-you-use: Clang tool to analyze includes in C and C++ source files

I wrote a tool to do this in 10 minutes just several days ago. It iterates over a file, and removes one #include at a time (while keeping all the other headers in place), and each time builds a file. For any successful build, it reports that header.

I used this to prune unnecessary includes throughout the TXR project.

There are some obvious false positives, like includes wrapped in #if/#ifdef and also certain system headers which look unnecessary on one system, but are actually required on others (due to the mess that is called POSIX).

After I applied some of the header removals, I pushed the changes to git and went through all the supported platforms to validate the changes. Almost every platform had some problem which resulted in some header having to be put back: MinGW, Cygwin, Solaris, Mac OS X. For instance, Mac OS is a stickler for needing to declare the kill() function. On other platforms, it also shows up elsewhere, perhaps unistd. On glibc, you get va_list if you include . Some platforms guard against this; they use some internal typedef name instead of va_list for vfprintf, so you must include for va_list. Various problems of this type. So just because a tool tells you, "hey this compiles without just fine", that of course means "well, on this system".

   #!/usr/local/bin/txr
   @(next :args)
   @file.c
   @(next `@file.c`)
   @(collect)
   @  (some)
   @lines
   @  (and)
   @    (line linenum)
   #include @header
   @  (end)
   @(end)
   @(require (boundp 'linenum))
   @(do (rename-path `@file.c` `@file.c.bak`))
   @(try)
   @  (do (each ((rem-line linenum)
                 (rem-hdr header))
            (with-stream (s (open-file `@file.c` "w"))
              (tprint (partition* lines (pred rem-line)) s))
            (ignerr (remove-path `opt/@file.o`))
            (when (zerop (sh `make opt/@file.o > /dev/null 2>&1`))
              (put-line `@file.c:@{rem-line}: can remove @{rem-hdr}`))))
   @(finally)
   @  (do (rename-path `@file.c.bak` `@file.c`))
   @(end)

The output is in a form that looks like compiler diagnostics. I can stick it in errors.err and run "vim -q".

This simple tool works in conjunction with the project rule that that headers don't include other headers. The .c files include everything they need in the right order. But the inclusions are added by hand by copy and paste, which can pull in something that isn't actually needed.

You have to iterate the tool. If you remove some header which isn't needed, a second pass can then determine that yet another header isn't needed, because it was only needed by that which was just removed. The iteration isn't worth building into the code.

With CMake it is possible to run the tool as part of the normal build process [1]. Not as nice as first class compiler support, but still quite helpful as part of day to day development, I find.

[1] http://stackoverflow.com/questions/30951492/how-to-use-the-t...

Make yourself familiar with the sanitizer tools from gcc and clang (asan, ubsan, tsan, msam). They can help you find many types of bugs.

The main feature that I miss from CLion is the ability to refactor. In CLion you can rename a class, and all of its usages, declarations, etc. will be renamed.

The most useful thing CLion can do is change the signature of a function, and its corresponding implementation and header declarations will be changed. So, you can rename a parameter and its declaration and implementation will be renamed for you, or you can delete a parameter, or change the type of a parameter, and CLion will change all its usages/definitions/declarations for you. All of this effects across all files in your project, so if you're in a .cpp file and you change the function signature, its declaration in the corresponding .h file will change as well.

(I believe you can do all of this in Eclipse as well)

Sadly I have yet to see a vim/emacs configuration that gets anywhere near the level of Eclipse/CLion.