_is_top_level_const_qualified function

Whether a namespace-scope variable’s own TYPE (not a pointer/reference target) is const-qualified – i.e. “const T”/“T const”, not “const T*” (the pointer itself stays reassignable) or any reference type.

Confirmed 2026-09-06 via a real doxygen probe on a genuine bug: a namespace-scope const DiagnosticCode DIAG_SUCCESS = ...; (no static keyword) reports static="no" in real Doxygen XML – static there reflects only the literal C++ keyword, unrelated to const-qualification. C++’s own semantics don’t need static for this: a namespace-scope const variable already has internal linkage and a single, fixed compile-time value regardless of whether static is (redundantly) written too – so relying on static alone as the “is this a constant” signal (as _parse_constant_member’s caller previously did) silently misclassified this extremely common idiom as a mutable VariableModel. Pointer/reference types are deliberately excluded here (kept as plain variables, unchanged behavior) – “const T*” leaves the pointer itself reassignable, and a reference binding can’t meaningfully be “reassigned” either way, so const-qualification doesn’t carry the same “this name is a single fixed value” meaning for those shapes.

Deliberately does NOT recognize constexpr – Doxygen’s own <type> text for a constexpr declaration is "constexpr T", never expanding to “const” (confirmed via a real probe), so a plain token check here would never match it anyway. constexpr is checked separately, via Doxygen’s own constexpr="yes" memberdef attribute (see the caller) – also confirmed real via probe, and a much more reliable signal than trying to text-match “constexpr” as a token (which real corpus testing showed matters: native_cpp_backend.py’s equivalent check uses libclang’s Type.is_const_qualified(), which already returns True for an implicitly const-qualified constexpr variable regardless of the literal keyword used – without this same signal here, real LLVM/OpenCV headers full of inline constexpr double e = ...;-style globals classified as constants on native but stayed variables on the Doxygen side, a new asymmetry that didn’t exist before this fix).

Methods

_is_top_level_const_qualified

_is_top_level_const_qualified(type_text: Optional) -> bool

Whether a namespace-scope variable’s own TYPE (not a pointer/reference target) is const-qualified – i.e. “const T”/“T const”, not “const T*” (the pointer itself stays reassignable) or any reference type.

Confirmed 2026-09-06 via a real doxygen probe on a genuine bug: a namespace-scope const DiagnosticCode DIAG_SUCCESS = ...; (no static keyword) reports static="no" in real Doxygen XML – static there reflects only the literal C++ keyword, unrelated to const-qualification. C++’s own semantics don’t need static for this: a namespace-scope const variable already has internal linkage and a single, fixed compile-time value regardless of whether static is (redundantly) written too – so relying on static alone as the “is this a constant” signal (as _parse_constant_member’s caller previously did) silently misclassified this extremely common idiom as a mutable VariableModel. Pointer/reference types are deliberately excluded here (kept as plain variables, unchanged behavior) – “const T*” leaves the pointer itself reassignable, and a reference binding can’t meaningfully be “reassigned” either way, so const-qualification doesn’t carry the same “this name is a single fixed value” meaning for those shapes.

Deliberately does NOT recognize constexpr – Doxygen’s own <type> text for a constexpr declaration is "constexpr T", never expanding to “const” (confirmed via a real probe), so a plain token check here would never match it anyway. constexpr is checked separately, via Doxygen’s own constexpr="yes" memberdef attribute (see the caller) – also confirmed real via probe, and a much more reliable signal than trying to text-match “constexpr” as a token (which real corpus testing showed matters: native_cpp_backend.py’s equivalent check uses libclang’s Type.is_const_qualified(), which already returns True for an implicitly const-qualified constexpr variable regardless of the literal keyword used – without this same signal here, real LLVM/OpenCV headers full of inline constexpr double e = ...;-style globals classified as constants on native but stayed variables on the Doxygen side, a new asymmetry that didn’t exist before this fix).

Generated with Flude

Copyright © 2026