Upgrade github/codeql dependency to 2.25.6 - #1199
Open
github-actions[bot] wants to merge 167 commits into
Open
github-actions[bot] wants to merge 167 commits into
github-actions[bot] wants to merge 167 commits into
Conversation
Update expected test results after frontend update
Update MISRA queries and tests after merging location tables
C++: accept new test results after QL changes
Observe that `sizeof(...)` might not occur as a dataflow node if it has a parent node with a concrete value. That value will be a dataflow node instead. Hence, the query has be changed to check for expressions where `sizeof(...)` is a child of an expression with a concrete value.
Note that we now properly report the offending cast instead of the expression that is being cast.
As it is the dataflow used by `asctime` that is relevant, and not the pointer, use the indirect expression.
Convert a number of queries to use the new dataflow library
Update expected test results for MSC33-C
These use the new dataflow library
Since the new dataflow library uses use-use dataflow and not def-use dataflow, we now need to check for definitions. Note that these queries can probably be improved by using a dataflow configuration - possibly limited to the local context of a function by including `DataFlow::FeatureEqualSourceSinkCallContext`
`InappropriateBitwiseOrShiftOperands.ql` reported operations that do not use the built-in bitwise or shift operators, most notably the stream insertion and extraction operators, e.g. `stream << value`. The operand checks used `not MisraCpp23BuiltInTypes::isUnsignedType(type)`. That predicate takes a `NumericType`, so it does not hold for a type that has no MISRA numeric type at all, and negating it makes the check vacuously true for every such type. Class types and the unresolved dependent types of uninstantiated template bodies were therefore reported as non-compliant operands. The checks now use `MisraCpp23BuiltInTypes::isSignedType(type)` instead, which only holds for an operand that has a MISRA numeric type and is signed. This does not introduce false negatives for dependent operands, because the template instantiations, in which the operand types are known, are still reported. Operands of character type, of a non-standard integral type, and of an unscoped enumeration type without a fixed underlying type are consequently no longer reported, because none of them has a MISRA numeric type. Unscoped enumerations without a fixed underlying type are covered by RULE-10-2-3. Fixes #1177
…zations
RULE-5-10-1 (poorly-formed identifier) flagged ordinary, well-formed,
snake_case local variables and function parameters (e.g. `value`,
`result`, `view`, `instance_identifier`) with "Identifier 'X' is
defined in reserved namespace." whenever they were declared inside the
body of an explicit template specialization that C++ explicitly
permits users to add to namespace `std`, most commonly
`std::hash<UserType>::operator()`. On the eclipse-score/communication
codebase this produced 66 findings, all inside `std::hash<UserType>`-
style specializations in headers such as handle_type.h,
trace_point_key.h and service_identifier_type.h.
Root cause: `VariableDeclarationEntryIdentifier::getNamespace()` used
`Variable.getNamespace()` directly. For a `Parameter` or
`LocalVariable`, the upstream CodeQL C++ library defines this as the
namespace of the *enclosing function* (see
`codeql/cpp-all/.../Declaration.qll`), which is a reasonable general
notion of "namespace context" but is not what RULE-5-10-1 means by "is
defined in reserved namespace". A block-scope local or parameter is
scoped to the body of its enclosing function; it is not itself a
member of that function's enclosing namespace and therefore cannot
introduce a new name into (or "pollute") a reserved namespace such as
`std`, regardless of which namespace the enclosing function happens to
be declared in. This is exactly the situation for the body of a
permitted `std::hash<UserType>` specialization: the parameter and local
names are ordinary user-chosen identifiers that merely happen to be
lexically nested inside `namespace std { ... }` because the standard
requires the specialization to be written there.
Fix: in `VariableDeclarationEntryIdentifier`, only report a namespace
for variables that are not `LocalScopeVariable` (i.e. not a `Parameter`
or `LocalVariable`). This is a narrow, semantically-motivated scope
check, not a name- or path-based exclusion: any genuinely new
namespace-scope or class-scope member added directly to `std` (a new
global, function, type, or the specialization itself) is still checked
independently via `FunctionDeclarationEntryIdentifier` /
`TypeDeclarationEntryIdentifier`, and remains flagged. A new
NON_COMPLIANT test case (a function declared directly in `namespace
std`) confirms this is unaffected.
Added a regression test reproducing the `std::hash<UserType>`
specialization shape with a parameter and a local both named after
the FP pattern (COMPLIANT), and confirmed with the "teeth" test that
reverting only `Identifiers.qll` while keeping the new test makes it
fail with exactly the two spurious findings. The existing RULE-5-10-1
test suite and the shared Identifiers library test continue to pass.
Validated against the real eclipse-score/communication CodeQL database
(`//score/message_passing //score/mw/com`): "is defined in reserved
namespace" findings for this shape dropped from 66 to 0, while the
one, unrelated "starts with underscore" finding in the same rule is
unchanged. All 66 baseline findings were manually confirmed to be
locals/parameters inside `std::hash<UserType>`-style specializations,
i.e. genuine false positives.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Updated CodeQL workflow to use caching
Updated caching strategy for CodeQL to use a new path and key format.
…eference NoImplicitBoolConversion.ql flagged two systematic false-positive shapes: 1. Conversions whose source expression type could not be resolved to a concrete type (UnknownType). This occurs only in template-dependent contexts the extractor cannot resolve, e.g. a `constexpr bool` variable template initialized from another dependent variable template such as `std::conjunction_v<...>`, or a `noexcept(...)` specifier built the same way. 2. Reference-dereference conversions (`bool&`/`bool&&` -> `bool`). `getUnspecifiedType()` resolves typedefs/specifiers but does not strip reference qualification, so a `bool&`/`bool&&` is not recognised as already being `bool`. This is most commonly synthesized by the compiler for structured binding decomposition (`auto [a, b] = pair_or_tuple_expr;` where `b` is `bool`), which is not a real conversion since the referenced value is already a `bool`. This mirrors the same root-cause pattern already fixed for the sibling rule RULE-7-0-1 in 6f872c7 ("Fix RULE-7-0-1 false positives for bool-to- reference bindings"), applied here to the reverse conversion direction.
…k feedback (#1195) * Add passing/failing tests for IncludeGuardsNotUsed exclusion behavior
MichaelRFairhurst
force-pushed
the
codeql/upgrade-to-2.25.6
branch
from
September 19, 2026 20:21
d92a0b7 to
cdb5c16
Compare
Collaborator
|
/test-performance |
Author
|
🏁 Beep Boop! Performance testing for this PR has been initiated. Please check back later for results. Note that the query package generation step must complete before testing will start so it might be a minute. |
|
🏁 Beep Boop! Performance testing complete! See below for performance of the last 3 runs vs your PR. Times are based on predicate performance. You can find full graphs and stats in the PR that was created for this test in the release engineering repo. 🏁 Below are the slowest predicates for the last 2 releases vs this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR upgrades the CodeQL CLI version to 2.25.6.
CodeQL dependency upgrade checklist:
github/codeqltest cases succeed.github/codeql-coding-standardsrepository.