Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDT/Archive/designs/StaticAnalysis"
(→Source & Bugs) |
(→Create a Checker) |
||
Line 58: | Line 58: | ||
To create a checker: | 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: | ||
* check out all plugins from dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (use cdt checkout instructions) | * check out all plugins from dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (use cdt checkout instructions) | ||
* create a plugin for your checkers or use org.eclipse.cdt.codan.checkers | * create a plugin for your checkers or use org.eclipse.cdt.codan.checkers | ||
Line 63: | Line 65: | ||
* 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. | * 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 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 | ||
+ | 3) Create a patch and attach to your bug | ||
== Extension Point == | == Extension Point == |
Revision as of 18:21, 23 September 2009
Contents
Goal
To create a light-weight static analysis framework in CDT that allows to easily plug in "checkers" which would perform real analysis on the code to find common defects, violation of policies, etc.
Glossary
- Problem
- any reportable item, such as error, warning, violation of any sort, and even search result
- Checker
- program that finds problems
- False Positive
- problem reported by checker which user considers as incorrect report (false)
- False Negative
- problem missed by checker which is a real problem of this type
User Experience
Code Analysis can be invoked in the one of the following ways:
- Select a "Run Code Analysis" command from Navigator context menu (file, directory, project or combination)
- Enable "Run on Build" in Project preferences "C/C++ Code Analysis->Build", in this case it would be run with Incremental and Full Build
User can control Severity and Enablement of Problems on Workspace level or on Project level.
If Problems are found they would be displayed in the Problems view and has specific type, which can be grouped by or filtered out by the view controls.
Examples of possible Problems
- Assignment in condition
if (a=b) { ... }
- Statement has not effect
a+b;
- Function name does not meet policy rules (should start with lowercase letter)
void My_function() {}
- Unused #include
#include <stdio.h> int main() { return 1; }
- Malloc called without sizeof consideration
int * arr = (int *)malloc(20); // should be malloc(20*sizeof(int))
Framework Parts
- Builder - register builder for "Code Analysis". This builder can be used by all checkers and can be turn on/off by user, which allow to perform checks while building (or not)
- Run On demand - provide a command to run "Code Analysis" on demand on selected file or set of resources
- Problem configuration - provide workspace level and project level problem configuration that allows to turn problems on and off, and change severity between standard problem severities
- Problem logging - provide an utility that allow easily to record 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 - allow to contribute a checker by using extension point, which mean 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:
- check out all plugins from dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (use cdt checkout instructions)
- 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
3) Create a patch and attach to your bug
Extension Point
This is example of extension point:
<extension point="org.eclipse.cdt.codan.core.checkers"> <checker class="org.eclipse.cdt.codan.checkers.sample.AssignmentInConditionChecker" id="org.eclipse.cdt.codan.checkers.checker1" name="Assignment in condition"> <problem defaultSeverity="Warning" id="org.eclipse.cdt.codan.checkers.sample.assignment_in_condition" name="Assignment in condition"> </problem> </checker> </extension>
API
API would contain:
- Interfaces such as IProblem, IProblemCategory, IChecker, etc
- Abstract class for checkers such as AbstractIndexAstChecker
- Interface to call Report Logging
- Interface to query status of problem enablement (for optimization purposes)
Current code resides in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan
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)
- Some common code to support Quick Fix for the problems
- Common scope filters for checkers (excluded/included files)
Source & Bugs
Source located at
dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan
Send questions to cdt-dev list:
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Send bugs to
- Project: Tools->CDT
- Component: cdt-source-nav
- Prefix: [code analysis]