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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
