CodePeer 20 Release Notes

We present here a few highlights of the new features in CodePeer 20. You can access the complete list here.

Improved GNAT Studio Integration

The CodePeer team is continuously working to tightly integrate the evolving CodePeer technology with AdaCore’s flagship IDE, GNAT Studio (formerly known as GPS, or GNAT Programming Studio).

These improvements refine the user experience for seasoned users and lowers the barrier of entry for new users. Some of these improvements include:

Improved Tooltip Integration

Tooltips have been introduced to many CodePeer menus and Code Review contexts to aid users through their analysis and triage workflows.

Simply hover the mouse over relevant information in GNAT Studio to see helpful messages, such as, tooltip integration with CodePeer analysis setup windows:

_images/level_tooltip.png

And consolidated analysis information for CodePeer findings:

_images/value_tooltip.png

Improved Pretty Printing of Integer and Floating-Point Ranges

The annotation syntax used to display Integer and Floating-Point ranges has been updated to increase the readability of computed values. The updates to this syntax can be found in the Annotation Syntax section of the User’s Guide.

Improved Highlighting of Manual Reviews

CodePeer messages that have been reviewed by users now have a review icon of a different color indicating the state of the last review: Grey is used for Uncategorized messages, Purple corresponds to a status of “Pending”, Blue corresponds to “Not a bug” and Red to “Bug” status.

The associated tooltip also includes the review status information, and the text of the messages reviewed as “Not a bug” is displayed with a different font color.

_images/highlight_manual_review.png

Improved Workflow for Manual Review of Multiple Messages

When manually reviewing multiple CodePeer messages at once, the dialog now displays information about the history of all messages reviewed, similarly to what is done when reviewing a single message.

_images/multiple_msg_review.png

Custom Review Tags

Users can now define their own custom review status to manually triage CodePeer messages. Details on this can be found in the CodePeer User’s Guide section on Custom Review Status.

Reduction of False Positives

A typical occurrence with Static Analysis tools is the potential for a finding to be a False Positive - meaning that it indicates a potential error, when in fact no error exists. These typically occur when the Static Analysis tool doesn’t have enough information to correctly analyze a section of code with a complete context.

A benefit of Ada, when it comes to static analysis, is it’s increased syntactic expressiveness, which can give static analysis tools, like CodePeer, a greater understanding of the logical context behind a set of expressions or decisions. This helps CodePeer minimize its rate of false positives.

As the CodePeer technology evolves, a primary directive is to maintain, and continue to lower the false positive rate, increasing the accuracy and effectiveness of the analysis. Recent improvements include:

Better Analysis of Formal Parameters When Address is Evaluated

In the past, CodePeer would sometimes deduce incorrect conclusions about a formal parameter of a subprogram whose Address attribute is referenced. For example, an out-mode parameter, which is initialized by passing its address to some other subprogram, might have been incorrectly flagged as having not been initialized. Consider the following code snippet:

1 procedure Foo (X : out Integer) is
2    F : Float
3      with Address => X'Address;
4 begin
5    F := 123.45;
6 end;

CodePeer would typically output a false positive message such as:

foo.adb:1:1: high: validity check: out parameter X is uninitialized here

Now, CodePeer’s analysis in such situations is more conservative. This results in fewer high-severity false positive messages and brings CodePeer’s treatment of formal parameters into line with CodePeer’s longstanding treatment of other objects (e.g., local variables) in analogous cases.

Improved Documentation on Accessibility_Level

The notation X’Accessibility_Level from CodePeer’s output is now documented in the CodePeer User Guide.

Filtering is also improved to capture more cases of possible false positives about accessibility level when using -messages min/normal.

Consideration of Non-Local Variables Updatable by Unknown Calls

Consider the following code snippet:

 1type Int_Ptr is access all Integer;
 2
 3G : Int_Ptr;
 4
 5procedure Unknown_Call
 6  with Import, Convention => Ada;
 7
 8procedure Test is
 9begin
10   G := null;
11   Unknown_Call;
12   pragma Assert (G.all = 5);
13end Test;

In this example, when CodePeer analyzes the procedure Test it will assume that the library level variable, or “Global”, G was possibly updated by the unknown call Unknown_Call.

This means that CodePeer now generates presumptions about the value of these “Global” variables after the call, avoiding possible high severity false positive warnings which would be generated when CodePeer assumes that these variables cannot be modified by the call.

New Pragma Annotate Feature Available

The pragma Annotate / Modified can be used to tell CodePeer to assume that (at the point where the pragma is placed) a given object is fully initialized and that nothing else should be assumed about the value of that object; any previous deductions CodePeer may have made about the value of the object at the point of the pragma is discarded.

 1procedure Foo (Count : in out Natural) is
 2begin
 3   Global_Variable_2 := 0;
 4   Update_Global_Variable_2;
 5   -- Suppose that Global_Variable_2 is updated by the preceding call,
 6   -- but for some reason CodePeer fails to realize that and
 7   -- therefore incorrectly assumes that Global_Variable_2 still has the
 8   -- value zero after the call.
 9   pragma Annotate (CodePeer, Modified, Global_Variable_2);
10   -- Because of the pragma, the assignment to Count will not be
11   -- incorrectly identified as dead code.
12   if Global_Variable_2 /= 0 then
13      Count := Count + 1;
14   end if;
15end Foo;

This pragma is intended to be used to work around situations where CodePeer becomes confused about the value of a variable at a point in the program and consequently generates incorrect messages.

Reproducible Runs on Level 3 Analysis

When running CodePeer at level 3, the CodePeer engine will now choose the same partition sizing, independently of the memory available on the machine. This change, coupled with the previously introduced “steps” limit, provides reproducible runs when switching from one machine to another.

The default is to create partitions for up to 4GB of memory. This can be overridden via the new switch -partition-memory-limit.