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

CDT/Archive/designs/StaticAnalysis

< CDT‎ | Archive‎ | designs
Revision as of 22:30, 16 April 2009 by Elaskavaia.qnx.com (Talk | contribs) (New page: == 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 "checkers" which would perform real ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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...)

Typical 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.

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)

Back to the top