[cfe-dev] questions on the LLVM coding standards

[Bertjan Broeksema]

Marshall Clow wrote:

> On Nov 16, 2010, at 2:24 PM, Chris Lattner wrote:
>> On Nov 15, 2010, at 5:25 PM, Zhanyong Wan (λx.x x) wrote:
>>> While reading the LLVM coding standards
>>> (http://llvm.org/docs/CodingStandards.html), I have some questions:
> 
> [ snip ]
> 
>>> 2. It advises to #include as little as possible.  In particular,
>>> "Don't do it unless you have to, especially in header files."  And
>>> later it says "you can include them either directly or indirectly
>>> (through another header file)."  I'm worried that this may lead
>>> dependencies on other headers' implementation details.
>> 
>> Yes, this is a possible issue, but since LLVM is a relatively
>> self-contained ecosystem, any issues that arise from this can be
>> addressed by fixing the clients of the headers.
>> 
>> This is in direct contrast to the apparent situation at Google, where
>> they prefer "include what you use".  That approach is taken because it is
>> difficult or expensive to find and update all the clients.
> 
> I've been playing with libclang, and trying to adapt c-index-test to make
> an include file tester.
> 
> The idea would be twofold:
> 1) Generate a "tree" of includes, so you can see the path where file gets
> included from. The existing code in c-index-test gives a different view,
> showing where each file is included from. 2) Some way of detecting
> "unused" included files, so that they can be removed.
> 
> I'm waiting anixously for the video of Craig Silverstein's talk from the
> developer meeting to see what he's already done.
> 
> Is this something that either
> a) has been done already
> or	b) other people would be interested in?

Yes, I am. I'm working on a C++ project analyzer [1] and also like to add 
things like this at some point. Another thing I wanted to implement using 
this information extracted by clang and related to this is, 
buildcost/buildimpact analysis as described in this paper:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.164.587&rep=rep1&type=pdf

Related work I did, based on the KDevelop IDE/C++ parsing framework can be 
found here [2] and here [3], but I found that framework in the end not clean 
enough, limited in its capabilities and not such a wide acceptance as clang.

Cheers,

Bertjan

[1] http://www.gitorious.org/cpp-dependency-analyzer/
[2] http://www.gitorious.org/kdevcpptools/kdevcpptools
[3] http://bertjan.broeksemaatjes.nl/files/ClassicThesis.pdf