Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "CDT/Archive/designs/StaticAnalysis"

< CDT‎ | Archive‎ | designs
(Goal)
(Run from Command Line)
(44 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== Goal ==
+
== Project Goal ==
  
To create a light-weight [http://en.wikipedia.org/wiki/Static_code_analysis static analysis] framework in CDT that allows to easily plug in
+
Code Name: "Codan" - stands for CODe ANalysis.  Codan was first introduced in [[CDT/User/NewIn70#Code_Analysis | CDT 7.0]].
"checkers" which would perform real analysis on the code to find common defects, violation of policies, etc.
+
  
Intended users of the "Codan" framework:
+
Codan is a light-weight [http://en.wikipedia.org/wiki/Static_code_analysis static analysis] framework in [[CDT]] that allows to easily plug in "checkers" which perform real time analysis on the code to find common defects, violation of policies, etc.
* <b>Tool Vendors</b>
+
** To create plugins containing end-user checkers and templates
+
* <b>Software Architects, Process Enforcement</b>
+
** To create customized new checkers, based on templates (no programming involved)
+
** To create problems profiles
+
* <b>Developer, Tester, Code Inspector</b>
+
** To check for errors as you type and have a quick way to fix them, during development
+
** To find bugs, security violations, API violations, coding standard violations during code inspection and before code run
+
  
 +
Intended users of the "Codan" framework:
  
Idea is to create a common components and API that are shared between static analysis tools for C/C++, such as:
+
*'''Tool Vendors'''
*User Interface to control the Problems enablement and parameters
+
**To create plugins containing end-user checkers and templates
*Different launch modes (as you type, on demand, as a builder)
+
**To integrate command line static analysis tools into CDT using common front-end
*An eclipse View to display additional problem information (such as extra backtrace or more complex problem parameters)
+
*'''Software Architects, Process Enforcement'''
*A Generic Marker type for problems with extra fields
+
**To create customized new checkers, based on templates (no programming involved)
*API to run log the problems
+
**To create problem profiles
*Base classes for checkers
+
*'''Developer, Tester, Code Inspector'''
*Sample checkers
+
**To check for errors as you type and have a quick way to fix them, during development
 +
**To find bugs, security violations, API violations, coding standard violations during code inspection and before code execution
 +
 
 +
<br> Framework contains common components and APIs that are shared between static analysis tools for C/C++, such as:  
 +
 
 +
*User Interface to control the Problems enablement and parameters  
 +
*Different launch modes (as you type, on demand, as a builder)  
 +
*An eclipse View to display additional problem information (such as extra backtraces or more complex problem parameters)  
 +
*A Generic Marker type for problems with extra fields  
 +
*API to log the problems  
 +
*Base classes for checkers  
 
*JUnit testing framework
 
*JUnit testing framework
 +
*Checker examples
 +
*Control Flow Graph of the code
 +
*API to access C/C++ AST and Scanner info is available for checker developers (not part of this plugin but part of CDT core)
 +
*Example for Quick Fixes (and some helper classes)
 +
*Common scope filters for checker
  
== Glossary ==
+
Requirements for [[CDT/designs/StaticAnalysis/GSoC|Google Summer of Code]] Students
  
;Problem: any reportable item, such as error, warning, violation of any sort, and even search result
+
== User Experience  ==
;Checker: program that finds problems
+
=== Run ===
;False Positive: problem reported by checker which user considers as incorrect report (false)
+
Code Analysis can be invoked in one of the following ways:  
;False Negative: problem missed by checker which is a real problem of this type
+
  
== User Experience ==
+
*Select a "Run Code Analysis" command from Navigator context menu (file, directory, project or combination)
  
Code Analysis can be invoked in the one of the following ways:
+
[[Image:Codan RunCodan.png]]  
* Select a "Run Code Analysis" command from Navigator context menu (file, directory, project or combination)
+
[[Image:Codan RunCodan.png]]
+
* Enable "Run on Build" in Project preferences "C/C++ Code Analysis->Build", in this case it would be run with Incremental and Full Build
+
[[Image:Codan RunOnBuild.png]]
+
  
User can control Severity and Enablement of Problems on Workspace level or on Project level.
+
*Enable "Run on Build" in Project preferences "C/C++ Code Analysis-&gt;Build", in this case it would be run with Incremental and Full Build
  
[[Image:Codan ProjectProperties.png]]
+
[[Image:Codan RunOnBuild.png]]  
  
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.
+
* As you type (in the editor)
  
[[Image:Codan_ProblemsView.png]]
+
[[Image:RunAsYouType.png]]
  
== Examples of possible Problems ==
+
* On file Save
 +
 
 +
=== View ===
 +
If Problems are found, they would be displayed in the Problems view. Each problem would have a specific type, which can be grouped by or filtered out by the view controls.
 +
 
 +
[[Image:Codan ProblemsView.png]]
 +
 
 +
Problem Details view can show extra information about a problem, it is customizable (by plugins) to show any external links or extra information about a problem which is not available in Problems view. By default it shows full file to path, full message and description of a problem.
 +
 
 +
[[Image:Problem_details_view.png]]
 +
 
 +
=== Customize ===
 +
User can control Severity and Enablement of Problems on Workspace level or on Project level.
 +
 
 +
[[Image:Codan ProjectProperties.png]]
 +
 
 +
Many problems are customizable, you can set extra options for checkers and/or set a scope.
 +
 
 +
[[Image:Customize.png]]
 +
 
 +
[[Image:Scope.png]]
 +
 
 +
=== Run from Command Line  ===
 +
 
 +
It is possible to run codan validation on command line as eclipse application
 +
eclipse -noSplash -application org.eclipse.cdt.codan.core.application -data <workspace> -consoleLog -verbose -all
 +
 
 +
Usage: [options] <project1> <project2> ...
 +
Options:
 +
  -all - run on all projects in workspace
 +
  -verbose - print verbose build information
 +
 
 +
Note: on windows run eclipsec instead
 +
 
 +
If you want to run it as part of automated build you also need to
 +
* a) create workspace prio to this command
 +
* b) import all projects you need into workspace
 +
* c) make sure all projects are indexed
 +
 
 +
All of the above is possible to do from command line using another cdt application "org.eclipse.cdt.managedbuilder.core.headlessbuild" using -import or -importAll option
 +
 
 +
== Examples of possible Problems ==
 +
 
 +
*Assignment in condition
  
* Assignment in condition
 
 
   if (a=b) { ... }
 
   if (a=b) { ... }
* Statement has not effect  
+
 
 +
*Statement has not effect
 +
 
 
   a+b;
 
   a+b;
* Function name does not meet policy rules (should start with lowercase letter)
+
 
 +
*Function name does not meet policy rules (should start with a lowercase letter)
 +
 
 
   void My_function() {}
 
   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 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 ==
+
Please edit this page for problem ideas: [[CDT/designs/StaticAnalysis/CheckerIdeas|Ideas]]
  
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
+
== For Developers ==
as name, default severity, etc. Name would be visible on the Configuration page.
+
=== Create a Checker  ===
  
To create a checker:
+
To create a simple checker you have to extend one of the framework classes, and add extension points where you specify a class name and describe a problem that checker finds, which includes name, message, default severity, etc. Name of the problem would be visible on the Configuration page.  
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) as separate eclipse projects
+
* 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 ==
+
To create a checker:
  
This is example of extension point:
+
#Define a problem(s) that your 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
 +
#Start coding:
 +
#*check out all plugins from codan git repo (use cdt checkout instructions) as separate eclipse projects (see below for git link)
 +
#*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 that your checker can detect with name, id, default severity and enablement
 +
#*note: severity of the problem is user defined. If you are creating a frontend for a 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. Users may define both of them as warnings for IDE.
 +
#*create a class in selected plugin which extends one of the AbstractChecker classes, such as AbstractIndexAstChecker, see examples in org.eclipse.cdt.codan.internal.checkers
 +
#*create a tests for your checker, it is pretty easy to do with existing framework see StatementHasNoEffectCheckerTest class as an example
 +
#Commit the code into local git repo, with comment starting with "Bug XXXXX: ...." Where XXXXX is the bug number, also comment must have gerrit change id and sign off (see more details in how to contribute cdt page)
 +
#Push change to gerrit server for review
  
   <extension
+
=== Extension Point  ===
         point="org.eclipse.cdt.codan.core.checkers">
+
 
       <checker
+
This is example of extension point:
 +
 
 +
   &lt;extension
 +
         point="org.eclipse.cdt.codan.core.checkers"&gt;
 +
       &lt;checker
 
             class="org.eclipse.cdt.codan.checkers.sample.AssignmentInConditionChecker"
 
             class="org.eclipse.cdt.codan.checkers.sample.AssignmentInConditionChecker"
 
             id="org.eclipse.cdt.codan.checkers.checker1"
 
             id="org.eclipse.cdt.codan.checkers.checker1"
             name="Assignment in condition">
+
             name="Assignment in condition"&gt;
         <problem
+
         &lt;problem
 
             defaultSeverity="Warning"
 
             defaultSeverity="Warning"
 
             id="org.eclipse.cdt.codan.checkers.sample.assignment_in_condition"
 
             id="org.eclipse.cdt.codan.checkers.sample.assignment_in_condition"
             name="Assignment in condition">
+
             name="Assignment in condition"&gt;
         </problem>
+
         &lt;/problem&gt;
       </checker>
+
       &lt;/checker&gt;
   </extension>
+
   &lt;/extension&gt;
  
== API ==
+
=== API ===
  
API would contain:
+
API contains:  
* 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
+
*Interfaces such as IProblem, IProblemCategory, IChecker, etc
 +
*Interface to call Problem Logging - provides means to report a problem (which would become a marker)
 +
*Interface to query status of problem enablement (for optimization purposes)
 +
*Abstract classes for Checkers (such as AbstractIndexAstChecker). For example class for C AST Visitor, which would use CDT C/C++ AST to find errors. Checkers can also use other models and even just plain text files (to find swear words or something...)
 +
*Programmatic access to a launch the analysis
 +
*Problem profile change listener - this allows for example to save problems enablement to a file to use in external make integrations
  
== Deployment ==
+
Non API Framework Parts:
  
Current this framework is not packaged with CDT. To include it in your CDT based tool you need
+
*Builder - framework would register a project builder for "Code Analysis". This builder can be used by all checkers and can be turn on/off by user, which allows to perform checks while building (or not)
to manually export plugins located in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (can be done using export wizard)
+
*Run On demand - provides a command to run "Code Analysis" on demand on selected files or set of resources
and add them to your distribution.
+
*Problem configuration - provides workspace level and project level problem configuration that allows to turn problems on and off, and change severity between standard problem severity
 +
*Marker Type - provide a market type for simple problems. Sophisticated checkers 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.
  
== Future work ==
+
=== Deployment  ===
  
* User defined checker's preferences, for example if it checkers for policy violations on function name let user specify name pattern using UI
+
Currently, this framework is packaged with CDT version 7.0+
* 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)
+
Also can work with 6.0, to include it in your CDT 6.0 based tool you need to manually import plugins  and add them to your distribution. The branch called "cdt_7_0" is backwards-compatible to CDT 6.0, "HEAD" is not.
* Some common code to support Quick Fix for the problems
+
* Common scope filters for checkers (excluded/included files)
+
  
== Source & Bugs ==
+
Framework only
 +
* org.eclipse.cdt.codan-feature
 +
* org.eclipse.cdt.codan.core
 +
* org.eclipse.cdt.codan.core.cxx
 +
* org.eclipse.cdt.codan.ui
 +
* org.eclipse.cdt.codan.ui.cxx
  
Source located at
+
Checkers
[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/?root=Tools_Project dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan]
+
* org.eclipse.cdt.codan.checkers
 +
* org.eclipse.cdt.codan.checkers.ui (ui support for specific checkers, such as quick fixes)
  
Send questions to cdt-dev list:
+
Testing & Examples
https://dev.eclipse.org/mailman/listinfo/cdt-dev
+
* org.eclipse.cdt.codan.core.test
   
+
* org.eclipse.cdt.codan.examples
 +
* org.eclipse.cdt.codan.ui.cfgview (control flow graph viewer)
 +
 
 +
=== Future work  ===
 +
 
 +
*User defined checker's preferences, for example if it checks for policy violations on function name let user specify name pattern using UI
 +
** partially done
 +
*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)
 +
** control graph is done for C (no exception support for c++)
 +
*Some common code to support Quick Fix for the problems
 +
** there is some common code now
 +
*Other static analysis application can become part of the project, such as: searchers, metrics, software models, etc
 +
*Support for problem profiles, for example "security profile" or "code inspection profile".
 +
*User should be able enable/disable checkers per launch type, i.e. checkers enabled "as you type" vs "with build". For example checkers that finds compilation problems are good as you type but not when you running actual compiler.
 +
** partially implemented
 +
 
 +
=== Source  ===
 +
 
 +
Source located at
 +
 
 +
*http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/codan
 +
 
 +
API for C/C++ AST:
 +
 
 +
*http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.cdt.doc.isv/reference/api/overview-summary.html
 +
 
 +
Send questions to cdt-dev list:  
 +
 
 +
*https://dev.eclipse.org/mailman/listinfo/cdt-dev
 +
 
 +
=== Presentations ===
 +
EclipseCon 2011
 +
* Example plugin [[Image:Mychecker.zip]]
 +
* Presentation [https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=1UNayw6WbckeiBLb2psf0xsyGmFf9dApwoB2BbaipU0-8c-fu3bxzCz9eSt9Q&hl=en Codan: a C/C++ Static Analysis Framework for CDT]
 +
 
 +
== Bugs ==
 
Send bugs to  
 
Send bugs to  
*Project: Tools->CDT
+
 
*Component: [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT&component=cdt-source-nav cdt-source-nav]
+
*Project: Tools-&gt;CDT  
*Prefix: [code analysis]
+
*Component: [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT&component=cdt-codan cdt-codan]  
 +
*Prefix: [fp] for false positive, [fn] for false negative, [checker] for new checker
 +
*List of current [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;component=cdt-codan;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;product=CDT;classification=Tools open bugs]

Revision as of 11:07, 14 December 2015

Project Goal

Code Name: "Codan" - stands for CODe ANalysis. Codan was first introduced in CDT 7.0.

Codan is a light-weight static analysis framework in CDT that allows to easily plug in "checkers" which perform real time analysis on the code to find common defects, violation of policies, etc.

Intended users of the "Codan" framework:

  • Tool Vendors
    • To create plugins containing end-user checkers and templates
    • To integrate command line static analysis tools into CDT using common front-end
  • Software Architects, Process Enforcement
    • To create customized new checkers, based on templates (no programming involved)
    • To create problem profiles
  • Developer, Tester, Code Inspector
    • To check for errors as you type and have a quick way to fix them, during development
    • To find bugs, security violations, API violations, coding standard violations during code inspection and before code execution


Framework contains common components and APIs that are shared between static analysis tools for C/C++, such as:

  • User Interface to control the Problems enablement and parameters
  • Different launch modes (as you type, on demand, as a builder)
  • An eclipse View to display additional problem information (such as extra backtraces or more complex problem parameters)
  • A Generic Marker type for problems with extra fields
  • API to log the problems
  • Base classes for checkers
  • JUnit testing framework
  • Checker examples
  • Control Flow Graph of the code
  • API to access C/C++ AST and Scanner info is available for checker developers (not part of this plugin but part of CDT core)
  • Example for Quick Fixes (and some helper classes)
  • Common scope filters for checker

Requirements for Google Summer of Code Students

User Experience

Run

Code Analysis can be invoked in one of the following ways:

  • Select a "Run Code Analysis" command from Navigator context menu (file, directory, project or combination)

Codan RunCodan.png

  • Enable "Run on Build" in Project preferences "C/C++ Code Analysis->Build", in this case it would be run with Incremental and Full Build

Codan RunOnBuild.png

  • As you type (in the editor)

RunAsYouType.png

  • On file Save

View

If Problems are found, they would be displayed in the Problems view. Each problem would have a specific type, which can be grouped by or filtered out by the view controls.

Codan ProblemsView.png

Problem Details view can show extra information about a problem, it is customizable (by plugins) to show any external links or extra information about a problem which is not available in Problems view. By default it shows full file to path, full message and description of a problem.

Problem details view.png

Customize

User can control Severity and Enablement of Problems on Workspace level or on Project level.

Codan ProjectProperties.png

Many problems are customizable, you can set extra options for checkers and/or set a scope.

Customize.png

Scope.png

Run from Command Line

It is possible to run codan validation on command line as eclipse application eclipse -noSplash -application org.eclipse.cdt.codan.core.application -data <workspace> -consoleLog -verbose -all

Usage: [options] <project1> <project2> ...
Options:
 -all - run on all projects in workspace
 -verbose - print verbose build information 

Note: on windows run eclipsec instead

If you want to run it as part of automated build you also need to

  • a) create workspace prio to this command
  • b) import all projects you need into workspace
  • c) make sure all projects are indexed

All of the above is possible to do from command line using another cdt application "org.eclipse.cdt.managedbuilder.core.headlessbuild" using -import or -importAll option

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 a lowercase letter)
 void My_function() {}


Please edit this page for problem ideas: Ideas

For Developers

Create a Checker

To create a simple checker you have to extend one of the framework classes, and add extension points where you specify a class name and describe a problem that checker finds, which includes name, message, default severity, etc. Name of the problem would be visible on the Configuration page.

To create a checker:

  1. Define a problem(s) that your 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 codan git repo (use cdt checkout instructions) as separate eclipse projects (see below for git link)
    • 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 that your checker can detect with name, id, default severity and enablement
    • note: severity of the problem is user defined. If you are creating a frontend for a 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. Users may define both of them as warnings for IDE.
    • create a class in selected plugin which extends one of the AbstractChecker classes, such as AbstractIndexAstChecker, see examples in org.eclipse.cdt.codan.internal.checkers
    • create a tests for your checker, it is pretty easy to do with existing framework see StatementHasNoEffectCheckerTest class as an example
  3. Commit the code into local git repo, with comment starting with "Bug XXXXX: ...." Where XXXXX is the bug number, also comment must have gerrit change id and sign off (see more details in how to contribute cdt page)
  4. Push change to gerrit server for review

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 contains:

  • Interfaces such as IProblem, IProblemCategory, IChecker, etc
  • Interface to call Problem Logging - provides means to report a problem (which would become a marker)
  • Interface to query status of problem enablement (for optimization purposes)
  • Abstract classes for Checkers (such as AbstractIndexAstChecker). For example class for C AST Visitor, which would use CDT C/C++ AST to find errors. Checkers can also use other models and even just plain text files (to find swear words or something...)
  • Programmatic access to a launch the analysis
  • Problem profile change listener - this allows for example to save problems enablement to a file to use in external make integrations

Non API Framework Parts:

  • Builder - framework would register a project builder for "Code Analysis". This builder can be used by all checkers and can be turn on/off by user, which allows to perform checks while building (or not)
  • Run On demand - provides a command to run "Code Analysis" on demand on selected files or set of resources
  • Problem configuration - provides workspace level and project level problem configuration that allows to turn problems on and off, and change severity between standard problem severity
  • Marker Type - provide a market type for simple problems. Sophisticated checkers 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.

Deployment

Currently, this framework is packaged with CDT version 7.0+ Also can work with 6.0, to include it in your CDT 6.0 based tool you need to manually import plugins and add them to your distribution. The branch called "cdt_7_0" is backwards-compatible to CDT 6.0, "HEAD" is not.

Framework only

  • org.eclipse.cdt.codan-feature
  • org.eclipse.cdt.codan.core
  • org.eclipse.cdt.codan.core.cxx
  • org.eclipse.cdt.codan.ui
  • org.eclipse.cdt.codan.ui.cxx

Checkers

  • org.eclipse.cdt.codan.checkers
  • org.eclipse.cdt.codan.checkers.ui (ui support for specific checkers, such as quick fixes)

Testing & Examples

  • org.eclipse.cdt.codan.core.test
  • org.eclipse.cdt.codan.examples
  • org.eclipse.cdt.codan.ui.cfgview (control flow graph viewer)

Future work

  • User defined checker's preferences, for example if it checks for policy violations on function name let user specify name pattern using UI
    • partially done
  • 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)
    • control graph is done for C (no exception support for c++)
  • Some common code to support Quick Fix for the problems
    • there is some common code now
  • Other static analysis application can become part of the project, such as: searchers, metrics, software models, etc
  • Support for problem profiles, for example "security profile" or "code inspection profile".
  • User should be able enable/disable checkers per launch type, i.e. checkers enabled "as you type" vs "with build". For example checkers that finds compilation problems are good as you type but not when you running actual compiler.
    • partially implemented

Source

Source located at

API for C/C++ AST:

Send questions to cdt-dev list:

Presentations

EclipseCon 2011

Bugs

Send bugs to

  • Project: Tools->CDT
  • Component: cdt-codan
  • Prefix: [fp] for false positive, [fn] for false negative, [checker] for new checker
  • List of current open bugs

Back to the top