是否可以使用clang自动包含缺少的c ++头文件？

Question

My plan is using clang to parse code and find the type undefined , and then find the corresponding header file, finally insert #include"xxx" in the file. Does clang can accomplish this?

I think I should describe my problem in more detail, which can make it easier to solve. I have a big project, it cost a long time to complie. I find almost every cpp file include "common.h" which is consists of many header files. So I want to clear the header files in "common.h", and insert the necessary header file in each cpp. It's a very boring and time costing work. I wonder if any automatic method can help.

Answer 1

IDE（或自动化工具）可以分析编译结果并提供建议（例如xcode执行此操作），但并非所有人都希望在没有程序员意识的情况下自动修复代码。

Answer 2

I don't think clang in itself can figure out which header file contains what type declarations and come up with which include should be used.

You could certainly use clang to determine what types are needed in a particular translation unit (source code) and which types are provided by a headerfile, and be a little smarter than grep -r typename somedir /dev/null , but it wouldn't be MUCH better. As comments say, you could end up suggesting the wrong header file - just because a file contains a class or struct definition with the right name (and content if you are being more clever about it), doesn't mean that it is the one the original author intended to use.

The main problem would be that you have to index all the existing header files, or it would take quite a long time to parse everything for every source file available.

As I see it, the main difficulties are:

• not suggesting "the wrong solution". Particularly when there are multiple solutions (eg portable code that has a header for windows, another for mac, another for linux - picking the right one would not be possible from just reading the sources!)
• to sort out multiple definitions (and it's far from unusual for various header files to have #if x; typedef ab; #endif sequences, so you can often end up with multiple places that COULD define a type).
• dealing with code that needs #define to work correctly.
• to determine when the name is a simple typo, rather than a new headerfile needed. Eg std::sting blah = "blah"; does not mean you should try to find a std::sting type, but that the code needs to be fixed to std::string ... .
• Chains that are required. You need to add #include "foo.h" but since foo.h contains std::string (but no include for it), you also need to add #include <string> before foo.h is included.
• Types declared in macros... Could make for an interesting challenge... ;)

There is nothing technically stopping a solution that suggests header files that solve a particular compiler error [and, if desired, update the code to solve the problem - that's simply a matter of text file manipulation, which for this purpose isn't particularly difficult], but I think that most of the time, a user that is familiar with the project will do a much better job than this sort of solution.