RULE-5-10-1: fix false positives for locals/parameters in permitted std specializations (e.g. std::hash)

[castler]

Problem

RULE-5-10-1 ("User-defined identifiers shall have an appropriate form") reports
Identifier 'X' is defined in reserved namespace. for ordinary, well-formed,
snake_case local variables and function parameters — e.g. value, result,
view, identifier, instance_identifier, skeleton_instance_identifier —
whenever they are 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():

namespace std
{
template <>
struct hash<score::mw::com::impl::ServiceIdentifierType>
{
    size_t operator()(const score::mw::com::impl::ServiceIdentifierType& value) const noexcept
    //                                                                     ^^^^^ flagged: "Identifier 'value' is defined in reserved namespace."
    {
        return std::hash<std::string_view>{}(value.ToHashString());
    }
};
}  // namespace std

[namespace.std]/[hash.requirements] explicitly permit a program to add a
template specialization for a standard library template (like std::hash) to
namespace std, provided the specialization depends on a user-defined type.
value here is not a new member of namespace std in the sense the rule is
trying to prevent — it is an ordinary parameter name scoped to the function
body, which merely happens to be lexically nested inside namespace std { ... }
because that is where the standard requires the specialization to be written.

Root cause

VariableDeclarationEntryIdentifier::getNamespace() (in
cpp/common/src/codingstandards/cpp/Identifiers.qll) delegated directly to
Variable.getNamespace():

override Namespace getNamespace() { result = variable.getNamespace() }

For a Parameter or LocalVariable, the upstream CodeQL C++ library defines
this predicate (in codeql/cpp-all/.../semmle/code/cpp/Declaration.qll) as the
namespace of the enclosing function:

Namespace getNamespace() {
  result = underlyingElement(this).(Q::Declaration).getNamespace()
  or
  exists(Parameter p | p = this and result = p.getFunction().getNamespace())
  or
  exists(LocalVariable v | v = this and result = v.getFunction().getNamespace())
}

That is a reasonable general notion of "namespace context" for other purposes,
but it is not what RULE-5-10-1 means by "is defined in reserved namespace". A
block-scope local variable or parameter is scoped to the body of its
enclosing function; it is not itself a member of that function's enclosing
namespace and 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. That is exactly the situation inside a permitted
std::hash<UserType> specialization body.

Fix

In VariableDeclarationEntryIdentifier, only report a namespace for variables
that are not a LocalScopeVariable (the common CodeQL superclass of
Parameter and LocalVariable):

override Namespace getNamespace() {
  not variable instanceof LocalScopeVariable and
  result = variable.getNamespace()
}

This is a narrow, semantically-motivated scope check — not a name- or
path-based exclusion (nothing matches on hash, std::hash, or any file
path). It only changes behaviour for parameters/locals whose enclosing
function happens to be declared in std/stdN/posix, which is rare outside
permitted specializations.

Crucially, this does not weaken the rule for genuine violations: any new
entity that actually introduces a name into namespace std/posix — a new
global variable, a new function, a new type, or the specialization name itself
— is still caught by VariableDeclarationEntryIdentifier (for namespace-scope
globals, whose namespace is not derived through the LocalScopeVariable
path), FunctionDeclarationEntryIdentifier, or TypeDeclarationEntryIdentifier
respectively, all of which are unaffected by this change.

Test

Added to cpp/misra/test/rules/RULE-5-10-1/test.cpp (appended, so no existing
.expected locations shift except for our own new lines):

• A std::hash<UserTypeForHash> specialization with a parameter value and a
  local result — both COMPLIANT.
• A genuinely new function declared directly in namespace std (not a
  specialization) — still NON_COMPLIANT, confirming the fix does not widen
  scope beyond block-scope locals/parameters.

Teeth test: reverted only Identifiers.qll to HEAD while keeping the new
test — it fails, reporting exactly the two spurious findings for value and
result (plus the expected new_std_function NON_COMPLIANT):

+| test.cpp:244:37:244:41 | value | Identifier 'value' is defined in reserved namespace. |
+| test.cpp:252:17:252:22 | result | Identifier 'result' is defined in reserved namespace. |
 | test.cpp:262:6:262:21 | new_std_function | Identifier 'new_std_function' is defined in reserved namespace. |

With the fix restored, codeql test run cpp/misra/test/rules/RULE-5-10-1/
PASSES. The shared library regression test
cpp/common/test/library/codingstandards/cpp/identifiers/IdentifiersTest.ql
also still PASSES unchanged.

Validation against a real codebase

Ran the fixed query (out-of-tree, --additional-packs pointing at this
checkout, --rerun, real release pack temporarily hidden to avoid shadowing)
against a whole-program CodeQL database for eclipse-score/communication
(//score/message_passing //score/mw/com):

	before	after
... is defined in reserved namespace.	66	0
... starts with underscore. (unrelated shape, out of scope for this fix)	1	1 (unchanged)

All 66 baseline findings were inspected by location; every single one is a
local variable or parameter inside the body of an explicit
std::hash<UserType>-style specialization (e.g. handle_type.h,
trace_point_key.h, service_identifier_type.h,
skeleton_instance_identifier.h, instance_specifier.h,
find_service_handle.cpp) — i.e. all 66 were genuine false positives of the
shape described above, and all are eliminated by this fix. The one remaining
finding (starts with underscore, on an unrelated _ parameter name) is a
different sub-check of the same query and is untouched by this change.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com