Upgrade github/codeql dependency to 2.25.6 - #1199
Open
github-actions[bot] wants to merge 50 commits into
Open
github-actions[bot] wants to merge 50 commits into
github-actions[bot] wants to merge 50 commits into
Conversation
Floating point decimal support has been removed from CodeQL
C++: Accept test changes after github/codeql#21313.
This reverts commit 141d5be.
…1313 Revert "C++: Accept test changes after github/codeql#21313."
Update test expectations after switch to SoftFloat library in the extractor
Revert SoftFloat changes
This reverts commit b883139.
Reapply "Merge pull request #1042 from jketema/jketema/softfloat"
Update type alias class names
Two categories of false positive are addressed: 1. **Private pure virtual functions used via the NVI idiom** — `DynamicCallGraph::getTarget()` resolves a virtual call to the implementations that may actually *run*. A pure virtual function (`= 0`) has no body, so it is never a viable dispatch target and is therefore never returned by `getTarget()` — not even when it is unambiguously named by a call, as in the non-virtual interface (NVI) idiom where a public member calls a private pure virtual. It was consequently reported as unused even though a sibling member calls it. `functionIsCalled` now also counts the *statically named* callee (`FunctionCall.getTarget()`), which recovers exactly that case. This is deliberately narrower than excluding `PureVirtualFunction` from `LocalFunction` outright: a private pure virtual that is genuinely never called and never overridden is still reported. 2. **Private members of never-instantiated class templates** — when a class template is never instantiated with a concrete type anywhere in the analyzed compilation units, Clang never elaborates a body for its member functions, so `Call`/`FunctionCall` targets within that pattern's own text cannot be resolved by `DynamicCallGraph::getTarget()` or `VirtualDispatch`, even for calls between sibling members of the very same class (e.g. a public entry point calling a private helper). This is common for generic "plumbing" library code (CRTP-style wrappers and the like) that is only ever instantiated by downstream consumers outside the analyzed codebase. The new `hasNoVisibleInstantiation(fn)` predicate conservatively treats such private members as "used" (out of scope for this analysis) rather than reporting them as dead code — but only when *no* sibling member of the same class has any instantiation either, so genuinely dead private helpers in class templates that *are* instantiated elsewhere are still correctly reported. The sibling-instantiation check is factored into a `pragma[noinline]` predicate over the declaring `Class` rather than over the member `Function`. Inlined into the caller, the join orderer loses the fact that the class is functionally determined and materialises the full (member, sibling) cross product per class before projecting it away. On a large real-world database this cut the peak intermediate relation for that predicate from 4,831,818 tuples to 7,700 with identical results. Fixes #1168
`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. |
mbaluda
reviewed
Sep 24, 2026
| | test.c:27:10:27:14 | ... < ... | Controlling expression in loop statement has an invariant value. | | ||
| | test.c:37:3:37:6 | 1 | Controlling expression in conditional statement has an invariant value. | | ||
| | test.c:38:3:38:3 | 1 | Controlling expression in conditional statement has an invariant value. | | ||
| | test.c:45:10:45:26 | ... && ... | Controlling expression in loop statement has an invariant value. | |
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.