Repository navigation
Description
Summary
The C++ parser records a parse_partial gap for valid function-like macro invocations when a macro argument is a type token rather than an ordinary expression. This is systematic rather than an isolated source-file problem.
The strongest signal is argument syntax:
| First macro argument form | Flagged invocations |
|---|---|
| Built-in type | 43 / 45 |
| Pointer type | 17 / 17 |
| Named type | 1 / 38 |
In an anonymized scan of a private C++ corpus, 61 invocations of this allocation-macro shape were inside persisted parse_partial ranges across 37 files. Sixty were additional occurrences beyond the initially reported case. No private filenames, paths, identifiers, or source excerpts are included here.
Verified synthetic reproduction
The following code is synthetic and contains no code or identifiers from the affected private corpus:
#include <cstddef>
#include <cstdlib>
#define SYNTH_ALLOC_ARRAY(Type, Count) \
((Type*)std::malloc(sizeof(Type) * (Count)))
struct Buffer {
char* data;
std::size_t size;
};
void initialize(Buffer& buffer) {
buffer.data = SYNTH_ALLOC_ARRAY(char, buffer.size);
}Reproduction steps
- Save the snippet as
repro.cppin an otherwise empty directory. - Index the directory in fast mode:
index_repository({"repo_path":"/path/to/synthetic-repro","mode":"fast","name":"synthetic-macro-type-repro","persistence":false})
- Query the persisted coverage signal:
index_status({"project":"synthetic-macro-type-repro"})
Actual result
The reproduction was verified against codebase-memory-mcp dev. Indexing succeeds, but coverage reports:
{
"parse_partial": {
"files": [
{
"path": "repro.cpp",
"error_ranges": "13-13"
}
],
"count": 1
}
}The flagged line is the otherwise valid macro invocation in initialize.
Expected result
parse_partial.countis zero.- The surrounding function and assignment remain available in the graph.
- Function-like macro arguments that are type-token sequences do not need to be interpreted as ordinary C++ expressions before macro expansion.
Likely cause
Without macro-aware handling, the invocation resembles an ordinary function call. In an ordinary call argument list, char is a type keyword and is not a valid expression. Pointer-type arguments introduce an additional * token that is also invalid in that position. Plain named types are lexically identifiers and therefore usually survive the expression grammar, which explains the observed distribution.
The macro expansion itself is valid C++: the type token is used in a cast and in sizeof.
Suggested fix direction
Treat arguments of unexpanded function-like macros as token sequences, or add tolerant recovery for macro invocations in expression positions, rather than requiring each argument to parse as a normal expression. A regression test based on the synthetic snippet should assert that indexing succeeds without a parse_partial entry for repro.cpp.
Activity
DeusData commentedon Jul 14, 2026
Thanks for reducing the private-corpus observation to a shareable synthetic C++ case. This is triaged as a normal-priority 0.9.1-rc parsing bug. A regression should cover built-in, pointer, and named type arguments and verify that valid macro invocations no longer create parse_partial gaps without broadening the grammar incorrectly.
Merge pull request #1135 from DeusData/fix/1071-cpp-macro-type-arg
fix(extract): don't flag in-body function-like macro calls as parse gaps
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…
fix(coverage): stop walking the source per error region in the #1071 …
fix(coverage): narrow parse-error ranges with the preprocessed parse (D…