CodePeer 20 Release Notes¶
We present here a few highlights of the new features in CodePeer 20. You can access the complete list here.
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:
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:
And consolidated analysis information for CodePeer findings:
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.
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.
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.
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:
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 2 3 4 5 6
procedure Foo (X : out Integer) is F : Float with Address => X'Address; begin F := 123.45; 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.
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.
Consider the following code snippet:
1 2 3 4 5 6 7 8 9 10 11 12 13
type Int_Ptr is access all Integer; G : Int_Ptr; procedure Unknown_Call with Import, Convention => Ada; procedure Test is begin G := null; Unknown_Call; pragma Assert (G.all = 5); end 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
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.
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
procedure Foo (Count : in out Natural) is begin Global_Variable_2 := 0; Update_Global_Variable_2; -- Suppose that Global_Variable_2 is updated by the preceding call, -- but for some reason CodePeer fails to realize that and -- therefore incorrectly assumes that Global_Variable_2 still has the -- value zero after the call. pragma Annotate (CodePeer, Modified, Global_Variable_2); -- Because of the pragma, the assignment to Count will not be -- incorrectly identified as dead code. if Global_Variable_2 /= 0 then Count := Count + 1; end if; end 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.
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.