Implement "Statements" package

[jeongsoolee09]

Description

please enter the description of your change here

Change request type

• Release or process automation (GitHub workflows, internal scripts)
• Internal documentation
• External documentation
• Query files (.ql, .qll, .qls or unit tests)
• External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• No rules added
• Queries have been added for the following rules:
  • rule number here
• Queries have been modified for the following rules:
  • rule number here

Release change checklist

A change note (development_handbook.md#change-notes) is required for any pull request which modifies:

• The structure or layout of the release artifacts.
• The evaluation performance (memory, execution time) of an existing query.
• The results of an existing query in any circumstance.

If you are only adding new rule queries, a change note is not required.

Author: Is a change note required?

• Yes
• No

🚨🚨🚨
Reviewer: Confirm that format of shared queries (not the .qll file, the
.ql file that imports it) is valid by running them within VS Code.

• Confirmed

Reviewer: Confirm that either a change note is not required or the change note is required and has been added.

• Confirmed

Query development review checklist

For PRs that add new queries or modify existing queries, the following checklist should be completed by both the author and reviewer:

Author

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

Reviewer

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

[MichaelRFairhurst]

This is really coming along and looking really good!!

[MichaelRFairhurst]

Simple comment formatting, unnecessary split

[MichaelRFairhurst]

Likely want to test that this works for a int * const x:

void f(int * const x) {
    (*x)++;
}

int main() {
    for (int i = 0; i < 10; ++i) {
        f(&i);
        std::cout << i << std::endl;
    }
}

I believe what will happen is that int * const x will be a DerivedType of type SpecifiedType with a const specifier. A SpecifiedType is not instanceof PointerType or instanceof ReferenceType and so this predicate will not hold, even though the value of i is modifiable within f.

You may also have problems with typedefs, such as typedef int *int_ptr_t for the same reason.

The solution here I believe will be to call .getUnderlyingType(). Another option frequently used for this is .stripSpecifiers(). Each of these will remove the const and resolve the typedef. I think .stripSpecifiers() may remove the const in const int*, though, which would make it unsuitable here.

[MichaelRFairhurst]

Should this say a reference is taken?

[MichaelRFairhurst]

I would attach these two doc block comments together so that we don't lose the connection if adding code or reordering predicates etc.

[MichaelRFairhurst]

You can use AssignAddOrSubExpr and .getLoopStep()!

[MichaelRFairhurst]

Consider moving this into codingstandards.cpp.Loops

[MichaelRFairhurst]

Consider taking this class, and AssignAddOrSubExpr and AddOrSubThenAssignExpr and moving them to a file such as cpp/common/src/codingstandards/cpp/ast/Increment.qll.

I'd decouple it from loops, for instance, rename getLoopStep to getIncremented or something like that.

[MichaelRFairhurst]

You may want to add not assignmentRhs.isInUnevaluatedContext() for safety.

That would prevent reporting cases like sizeof(g(&i)) or decltype(g(&i)).

[MichaelRFairhurst]

Two missed cases here:

• Mixing signed/unsigned types, they may have the same size but they'll hold different ranges.
• The type and runtime value may lead to different conclusions.

I think you may be able to get away with upperBound(loopCounter) < upperBound(loopBound). That would handle signedness, constants (like x < 10ull), and dynamic ranges (like unsigned long long bound = 10; ... x < bound).

[MichaelRFairhurst]

A thought on simplifying these names.

Maybe instead of naming them loopVariablePassedAs... you can rename them to passedAsNonConstReference/passedAsNonConstPointer and remove the ForStmt argument.

Then at the call sites you can change

loopVariablePassedAsArgumentToNonConstReferenceParameter(loop, va)
// becomes
exists(VariableAccess other |
  passedAsNonConstReference(other) and
  other.getVariable() = loop.getBound().(VariableAccess).getVariable() and
  other.getEnclosingStmt().getParent*() = loop.getStmt()
)