View source for CA Library Implementation

You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page:
<center><small>[[User:Stefan/Code Analysis/Adding New Rules|&lt;&lt; 6. Adding New Rules]] |</small></center>
----
<br />

The code for Code Analysis is located at three different places in the ''EVE'' source:
# The framework—the by far largest part, with the rule checking, the rules, the control flow graph functionality, and more—is represented as a ''library'';
# The graphical user interface can be found in the ''interface'' cluster of ''EVE'';
# The command-line interface for code analysis is a single class in the ''tty'' cluster of ''EVE''.

== ''code_analysis'' library ==

The whole code analysis framework is located in the library ''code_analysis''.

=== Interface ===

In this section it is explained from a client view how to use the code analyzer. The code analyzer is represented by the class <e>CA_CODE_ANALYZER</e>, so a client must have or access an instance of this class. Before the analyzer can be launched all the classes that shall be analyzed must be added using one of the following features. If you use more than one of these commands then the added classes from all commands will be conjoined.
; <e>{CA_CODE_ANALYZER}.add_whole_system</e> : Adds all the classes that are part of the current system. Classes of referenced libraries will not be added. So, for example, if your system consists of the classes <e>MY_MAIN</e>, <e>MY_BOX</e>, and <e>MY_ITEM</e> then these three classes will be added to the list of classes to be analyzed.
; <e>.add_class (a_class: attached CONF_CLASS)</e> : Adds a single class.
; <e>.add_classes (a_classes: attached ITERABLE [attached CONF_CLASS])</e> : Adds a list of classes.
; <e>.add_cluster (a_cluster: attached CLUSTER_I)</e> : Adds all classes of a cluster (and all the classes of the sub-clusters recursively).
; <e>.add_group (a_group: attached CONF_GROUP)</e> : Adds all classes of a configuration group. An example of a configuration group is a ''library''.

Here are other features which can be called before starting to analyze:
; <e>{CA_CODE_ANALYZER}.clear_classes_to_analyze</e> : Removes all classes that have been added to the list of classes to analyze.
; <e>.add_completed_action (a_action: attached PROCEDURE [ANY, TUPLE [ITERABLE [TUPLE [detachable EXCEPTION, CLASS_C]]]])</e> : Adds <e>`a_action'</e> to the list of procedures that will be called when analysis has completed. The procedures have one argument, a list of exceptions (with the corresponding class). In the case an exception is thrown during analysis the exception is caught by the code analyzer and is added to this list. In the graphical user interface such exceptions would show up as errors at the top of the list of rule violations.
; <e>.add_output_action (a_action: attached PROCEDURE [ANY, TUPLE [READABLE_STRING_GENERAL]])</e> : Adds <e>`a_action'</e> to the procedures that are called for outputting the status. The final results (rule violations) are not given to these procedures. These output actions are used by the command-line mode and by the status bar in the GUI.
; <e>.is_rule_checkable (a_rule: attached CA_RULE): BOOLEAN</e> : Tells whether <e>`a_rule'</e> will be checked based on the current preferences and based on the current checking scope (whole system or custom set of classes).

Then, to start analyzing simply call <e>{CA_CODE_ANALYZER}.analyze</e>.

=== Rule checking ===

In the GUI we want to be able to continue to work while the code analyzer is running. Analyzing larger sets of classes (such as whole libraries) can take from several seconds to several minutes. For this reason the code analyzer uses an ''asynchronous task'', <e>{CA_RULE_CHECKING_TASK}</e>. In <e>{CA_CODE_ANALYZER}.analyze</e> this task (<e>l_task</e>) is invoked as follows:

==== In <e>{CA_CODE_ANALYZER}.analyze</e>: ====

<e>
create l_task.make (l_rules_checker, l_rules_to_check, classes_to_analyze, agent analysis_completed)
l_task.set_output_actions (output_actions)
rota.run_task (l_task)
</e>

<e>{CA_RULE_CHECKING_TASK}</e> essentially runs the whole analysis. Like all other conformants to <e>{ROTA_TASK_I}</e> this class executes a series of ''steps'' between which the user interface gets some time to process its events. In <e>{CA_RULE_CHECKING_TASK}</e> each step analyses one class. This means that a class is checked by ''all'' the rules for violations. The following code does that:

==== From <e>{CA_RULE_CHECKING_TASK}</e>: ====

<e>
step
    -- <Precursor>
  do
    if has_next_step then
        -- Gather type information
      type_recorder.clear
      type_recorder.analyze_class (classes.item)
      context.set_node_types (type_recorder.node_types)
      context.set_checking_class (classes.item)

      across rules as l_rules loop
          -- If rule is non-standard then it will not be checked by l_rules_checker.
          -- We will have the rule check the current class here:
        if
          l_rules.item.is_enabled.value
          and then attached {CA_CFG_RULE} l_rules.item as l_cfg_rule
        then
          l_cfg_rule.check_class (classes.item)
        end
      end

        -- Status output.
      if output_actions /= Void then
        output_actions.call ([ca_messages.analyzing_class (classes.item.name)])
      end

      rules_checker.run_on_class (classes.item)

      classes.forth
      has_next_step := not classes.after
      if not has_next_step then
        completed_action.call ([exceptions])
      end
    end
  rescue
      -- Instant error output.
    if output_actions /= Void then
      output_actions.call ([ca_messages.error_on_class (classes.item.name)])
    end
    exceptions.extend ([exception_manager.last_exception, classes.item])
      -- Jump to the next class.
    classes.forth
    has_next_step := not classes.after
    if not has_next_step then
      completed_action.call ([exceptions])
    end
    retry
  end
</e>

<e>type_recorder</e> is of type <e>{CA_AST_TYPE_RECORDER}</e>. It uses a functionality of the Eiffel compiler to determine the type of some AST nodes in the current class. The AST itself (as provided by the Eiffel compiler) does not contain any type information. <e>context</e> has type <e>{CA_ANALYSIS_CONTEXT}</e> and contains any side-information such as the previously mentioned types and the current class. The rules were given this context before so that they can access it when needed.

The <e>across</e> loop only checks ''control flow graph rules''. All the ''standard'' rules are checked by the line <e>rules_checker.run_on_class (classes.item)</e>. <e>rules_checker</e> has type <e>{CA_ALL_RULES_CHECKER}</e>. This is the class where each rule must register the AST nodes the rule visits. <e>run_on_class</e> iterates over the AST and calls all the actions that were registered by the standard rules. So this is the way all rules are used to check the current class. <e>step</e> is executed repeatedly until there are no classes left to analyze.

In the <e>rescue</e> clause all possible exceptions are caught and recorded. In case of such an exception it then proceeds to the next class.

== Graphical User Interface ==

The classes of the graphical user interface of the code analyzer are all located in the ''interface'' cluster of ''EVE'', in the subfolder ''graphical > tools > code_analysis''. Here is a short overview of what the single classes do:

; <e>{ES_CODE_ANALYSIS_TOOL}</e> : Represents the code analysis GUI tool. Contains the tool title and icon, otherwise not much interesting stuff.
; <e>{ES_CODE_ANALYSIS_TOOL_PANEL}</e> : The graphical panel for the code analysis tool. It contains buttons, labels, the rule violations table view, and other user interface elements.
; <e>{ES_CODE_ANALYSIS_COMMAND}</e> : The command to launch the code analyzer. It can be added to toolbars and menus. It can be executed using stones. This class also handles the caching.
; <e>{ES_CODE_ANALYSIS_BENCH_HELPER}</e> : A helper class for the integration of the code analysis tool. It contains shared instances of <e>{CA_CODE_ANALYZER}</e> and <e>{ES_CODE_ANALYSIS_COMMAND}</e>, which are used by the GUI.
; <e>{ES_CA_SHOW_PREFERENCES_COMMAND}</e> : The command is used by the ''Preferences'' button in the panel.
; <e>{ES_CA_FIX_EXECUTOR}</e> : This class [[User:Stefan/Code Analysis/Using Analysis Results#Fixing Rule Violations|fixes]] a rule violation that has been found by the code analysis tool.


=== Caching ===

== Command-line Interface ==

The whole command-line functionality of the code analyzer is located in the class <e>{EWB_CODE_ANALYSIS}</e>. It is located in the ''tty'' cluster of ''EVE''. <e>{EWB_CODE_ANALYSIS}</e> is invoked by <e>{ES}</e>, the root class for the ''batch'' (command-line) version of EiffelStudio. In <e>{ES}</e>, the invocation looks as follows:

<e>
elseif option.is_equal ("-code-analysis") then
  l_at_args := arguments_in_range (current_option + 1, argument_count)
  current_option := argument_count + 1
  create {EWB_CODE_ANALYSIS} command.make_with_arguments (l_at_args)
</e>

Any command-line arguments after ''-code-analysis'' are passed on to <e>{EWB_CODE_ANALYSIS}</e>. This class, in its creation procedure, processes the arguments as described in [[User:Stefan/Code_Analysis/Command Line Usage|Command Line Usage]]. Classes that were passed as command-line arguments are added to the analyzer. Then the actual execution happens in the procedure <e>execute</e>. <e>EWB_CODE_ANALYSIS</e> of course uses the ''code_analysis'' library and the previously described interface of <e>CA_CODE_ANALYZER</e>. After analysis a list of rule violations is output to the command-line. In the code it looks like this:

<e>
across l_code_analyzer.rule_violations as l_vlist loop
  if not l_vlist.item.is_empty then
    l_has_violations := True
      -- Always sort the rule violations by the class they are referring to.
    output_window.add (ca_messages.cmd_class + l_vlist.key.name + "':%N")

      -- See `{CA_RULE_VIOLATION}.is_less' for information on the sorting.
    across l_vlist.item as ic loop
      l_rule_name := ic.item.rule.title
      l_rule_id := ic.item.rule.id
      if attached ic.item.location as l_loc then
        l_line := ic.item.location.line.out
        l_col := ic.item.location.column.out
        output_window.add ("  (" + l_line + ":" + l_col + "): "
          + l_rule_name + " (" + l_rule_id + "): ")
      else -- No location attached. Print without location.
        output_window.add ("  "	+ l_rule_name + " (" + l_rule_id + "): ")
      end
      ic.item.format_violation_description (output_window)
      output_window.add ("%N")
    end
  end
end

if not l_has_violations then output_window.add (ca_messages.no_issues + "%N") end
</e>
Return to CA Library Implementation.
Retrieved from "https://dev.eiffel.com/CA_Library_Implementation"
View source for CA Library Implementation

Navigation

Development

Wiki

Search

Tools
