Re: [cdt-dev] Static Include Analysis (ReDHead)

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

Are you planning to contributing to CDT? Because if not we will have
to re-implement it, as part of Tomasz  project.

On Tue, May 25, 2010 at 10:32 AM, Lukas Felber <lfelber@xxxxxx> wrote:
> On Fri, 2010-05-21 at 17:08 +0200, Kos wrote:
>
>>
>> Let me ask you a question:
>> My primary focus in this idea is to relieve the programmer of the need
>> of manually adding includes (and forward declarations) while coding.
>> Is this also in the scope of your project?
>
> Nice that I'm not the only person working on those issues.
>
> Actually I was amazed to read you wiki-page and see how much of it
> matches many features I already have or intend to have. So the scope of
> my project matches pretty well with with your focus.
> Here some of the matches:
>  * Find indirect includes used ( called "directly include referenced
> files" in ReDHead)
>  * Find all files that needs to be included ( part of "organize
> includes" in ReDHead)
>  * Remove all unused
>
> include generation:
>  * (1) path to included file:
>  One can retrieve IIncludeReferences from the class ICProject. When
> generating includes I check on all of those an chose the shortest path
> (segment count of IPath class)
>  * (2) What to incude
>  ReDHead can decide if a forward declaration is enough and either
> include a file containing a forward declaration or the one containing
> the declaration.
>  * Library headers:
>  Right now I am working on a solution to see that <set> gets included
> instead of <bits/stl_set.h>. I also intend to provide a method to the
> user so he can define certain files as "public" headers which will cause
> ReDHead to include these file (set) instead of the one containing the
> concrete declaration (bits/stl_set.h).
>  * (3) Position to include
>  ReDhead can find proper include positions which consider (1) existing
> includes (2) conditional macros (containing includes) (3) include guards
> (4) position of first declaration in file.
>
>
> unused Includes:
>  * Finding unused includes works well and more or less fast (also on
> bigger projects) with the help of IIndex and some caching.
>  * When a declaration can be reached through several ways form the
> source file (through includes) ReDHead can chose in a smart way which
> one is the better to remove.
>
> * Marking on type (codan)
> Kirstin Weber mentioned that marking unused includes while typing would
> be nice. This is already implemented and works pretty well.
>
>  * Markus's comments
> The problems about the #undef and #pragma statements cannot be avoided
> which means there should probably never be auto-removal in CDT. instead,
> the user will have to decide it he wants to apply any proposals.
>
>
> Lukas
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>