fix(extract): a C-family function's return type keeps its pointer and qualifiers

[DeusData]

No C or C++ function in any index had a pointer return type. Distilled from #1245 (Andrew Hundt, the extract_defs.c half of c51e5cb; the mcp.c and token-reduction parts are not taken).

The defect

For C-family functions return_type was the text of the declaration's type node alone. In these grammars the *, & and && live on the declarator and cv-qualifiers are sibling nodes, so

const char *get_name(void)        published   char
robj **lookupKeys(...)            published   robj
Text &operator=(const Text &)     published   Text

The C/C++ resolver's return-type parser already strips a leading const/volatile and handles trailing *, &, && — branches that were unreachable for functions, so every Foo *f() was registered as returning Foo by value.

The fix

c_declared_return_type() renders the declared type at both sites (functions and methods) for C, C++, CUDA, GLSL, HLSL, ISPC, Slang and Objective-C — the list resolve_func_name_c_family uses:

<leading cv-qualifiers, source order> <base type, verbatim><one space><markers, outermost first>

so const char *, char **, Text &, Text &&, Text *&, volatile unsigned long *; a pointer-level qualifier follows its star (char *const *); east-const char const * normalises to const char *. With no qualifier and no marker the old text is returned unchanged. It measures, then writes into one exact-size arena allocation; the declarator walk is a plain child chain, no recursion. def.return_types is untouched.

Two deliberate differences from the upstream hunk. Upstream copied every type_qualifier node, which in these grammars includes constexpr, _Noreturn, mutable and __extension__ — constexpr int f() would have become constexpr int. Only const, volatile, restrict, __restrict, __restrict__ and _Atomic are kept, and both cases are asserted unchanged. And the walk stops at the first declarator that is neither pointer nor reference, so int (*f(void))(int) stays int rather than becoming a wrong int *.

RED → GREEN

RED with production reverted and the final tests kept:

c_function_return_type_preserves_pointer_and_qualifier    FAIL "char" != "const char *"
cpp_method_return_type_preserves_pointer_and_qualifier    FAIL "char" != "const char *"

c_function_return_type_plain_unchanged is the control and passes before and after. GREEN on today's main: extraction 374, c_lsp 762, pipeline 286, lang_contract 41; memory-core linter unchanged.

Effect on real code — Redis, production binaries, old against new

39,132 nodes in both. 1,442 Function nodes change, in return_type only: void → void * (270), char → const char * (101), unsigned char → unsigned char * (91), char → char * (81), robj → robj * (57), … Functions with a * in return_type: 0 → 1,440. With one worker the complete edge set apart from SEMANTICALLY_RELATED is byte-identical old against new across six runs — CALLS, USAGE, WRITES, IMPORTS and the rest do not move. SEMANTICALLY_RELATED goes 350 → 325 because that pass tokenises the return-type string into its type vector.

One thing measured rather than assumed: with several workers, which dict.h Redis' src/dict.c imports depends on worker merge order. That was main's defect, not this change's, and it is what #2227 fixed.