Re: [cdt-dev] [GSoC] Static Analysis Checkers for C/C++

[Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>]

What do you prefer to do? These are a lot of ideas and plan for the
next 5 years :)
You have to pick something what is more interesting for you. I
personally prefer framework improvements.
Btw "when checker should run" I kind of did it already although it is
ugly - you can select checker launch scope for each checker from "run
on build, run as you type, run on demand, etc".
Also I think it is nice to have "token" implementation of 3rd party
integration, so it can be re-used for custom integrations. Open source
lint one would be good (does it exist for mingw?)

2011/4/27 Tomasz Wesołowski <kosashi@xxxxxxxxx>:
> Hello again!
> I'm happy to be accepted for GSoC this year. Last year I had a great time
> working for Eclipse CDT under the mentorship of Alena Laskavaia; I hope that
> this year we'll achieve even more!
> My GSoC topic for this year is Static Analysis Checkers for C/C++. I have
> previously tinkered with refactoring and the editor, so I'm positive that
> I'll spend some time in that areas too.
> Let us talk about what is there to be done:
> 1) Checkers. This includes:
>   a. integration with existing tools (Lint, cppcheck?, ...).
> We can't bundle them with Eclipse, so by integration I understand providing
> functionality (to be packaged with Codan, possibly as plug-ins) which would
> allow to configure and integrate them easily so that they can be used in the
> same way as native Codan checkers.
> Note that some of them (like cppcheck) have their own Eclipse plug-ins
> already (cppcheclipse), some of them may be maintained, some not; for any
> such case it might or might not be feasible to consider integrating such a
> plug-in into Codan to benefit from its architecture (i.e. settings).
>   b. creation of checkers which find things which will cause a compiler
> error
> Such checkers may be considered of limited use, but yet some of those are
> worth implementing so that they are highlighted during typing and can be
> quick-fixed instantly, as a typing aid (for example detecting unimplemented
> virtual methods or invalid implicit casts).
>   c. creation of custom checkers of possible bugs
> Which is exactly the same thing as the industry-standard tools do. There's
> plenty of possibilities here, especially since we already have the AST and a
> lot of semantic utils, but this also asks for an important decision: how
> much functionality already present in freely available tools do we want to
> write ourselves from scratch?
> 2) Codan architecture
> I believe we can also find some issues with Codan to address. An example is
> the problem of determining when a checker should be ran - considering both
> custom checkers (written on the CDT AST) and external checkers (bridges for
> additional software), we can distinguish light checkers safe to use when
> typing, heavier checkers to be ran i.e. on file save and heaviest,
> time-consuming checks to be done only manually, or possibly before a build.
> I believe that there should be a way to specify such setting on a
> per-checker basis and possibly even let the user change this as a
> preference.
> There are also some issues regarding the error markers themselves; whether
> they shall persist or be only visible when an editor is open? (Probably
> depends on the checker). There is the issue of markers highlighting errors
> in one translation unit but depending on code from others; can such checkers
> operate during typing, and still behave correctly if there are unsaved
> changes in many editors? Also if "during-typing markers" persist after an
> editor is closed, how a marker should be updated/removed if code in another
> translation unit changes, removing the problem in a closed file?
> Also I remember some minor issues with the appearance of problem annotations
> and pop-ups and the possibility (or lack of thereof) to perform a quick fix
> on some annotations when there are more of them on the same line.
> Some of the above issues might already been resolved, but others probably
> will still need some thought.
>
> I'm looking forward to hearing your thoughts!
> Best regards,
> -- Tomasz Wesołowski