Problem logging - provide means to report a problem (which would become a marker)

Marker Type - provide a market type for simple problems. Sophisticated checker can use their own marker types.

Common Categories - set of common Categories for problems, such as Java has, for example "Programming Errors", "Unused Code and Objects", "Security Violations"...

Checkers extension point - allows to contribute a checker by using extension point, which means different problems can be contributed by different plugins with potentially different vendors, but would have same user interface and look and feel.

Abstract classes for Checkers. For example class for C AST Visitor, which would use CDT C/C++ AST to find errors. Checker can also use other models and even just plain text files (to find swear words or something...)

Create a Checker

To create simple checker you would have to extend one of the framework classes, and add extension point where you specify a class name and describe a problem, such
as name, default severity, etc. Name would be visible on the Configuration page.

To create a checker:
1) Define a problem(s) that you checker is capable of finding, cross check existing checkers to see if it is already there, create a bug report describing your intention to implement it
2) Start coding:

create a plugin for your checkers or use org.eclipse.cdt.codan.checkers

create an extension point for org.eclipse.cdt.codan.core.checkers. Specify one or more problem your checker would create with name, id, default severity and enablement

note: severity of the problem is user defined. If you creating a frontend for command line static analysis tool (such as lint) which can have different severity for same error, you have to create an id per severity per problem type. For example for "Null pointer dereference" you create npd.error and npd.warning ids. User may define both of them as warnings for IDE.

create a class in selected plugin which implements IChecker interface. You can pick default abstract implementation such as AbstractIndexAstChecker, see examples in org.eclipse.cdt.codan.checkers.sample

create a tests for your checker, it is pretty easy to do with existing framework see StatementHasNoEffectCheckerTest class as example

Current code resides in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan

Deployment

Current this framework is not packaged with CDT. To include it in your CDT based tool you need
to manually export plugins located in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (can be done using export wizard)
and add them to your distribution.

Future work

User defined checker's preferences, for example if it checkers for policy violations on function name let user specify name pattern using UI

Build shared models other than AST with bindings, such as Control Graph, Data Flow Graph (this was done in ptp project, maybe just bring it over)