C/C++ #include not mapped as IMPORTS edges — expected or a bug?

Version

codebase-memory-mcp 0.9.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

I indexed a mixed C++/Kotlin/Python project using codebase-memory-mcp v0.9.0 on Windows.

Kotlin/Python files get IMPORTS edges correctly
C++ files — none of the #include directives produce IMPORTS edges in the graph
Example: main.cpp #includes NodeController.h, but the graph only shows IMPORTS from main.cpp to NodeController.cpp (Module node), not to the header file. Most C++ .cpp and .h files end up with zero incoming edges.

Query:

MATCH (f:File) WHERE NOT EXISTS { (f)<-[:IMPORTS|CALLS|CONTAINS_FILE|DEFINES|USAGE]-() } RETURN count(f)
Returns 194 out of 214 total files, even though most of those are actively used via #include in the build system.

My setup:

Platform: Windows (amd64)
Binary: codebase-memory-mcp v0.9.0 (windows-amd64, static binary)
Project type: PlatformIO (C++/Arduino) + Android (Kotlin) + Python backend
Index mode: full, CBM_WORKERS=1 (no crashes, status: "indexed")

Is missing C/C++ #include → IMPORTS mapping a known limitation?
Are C/C++ #include dependencies tracked under a different edge type that I'm missing?
Is there a workaround or pending fix for this?
Thanks!

Reproduction

none

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

4028 nodes / 15847 edges / 214 files

Confirmations

I searched existing issues and this is not a duplicate.
My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

Thanks for the detailed C/C++ import report. Triage: treating this as a C/C++ import extraction bug rather than expected behavior. Header includes are real dependency edges for impact analysis, and the current graph shape makes many active files look disconnected. Added to 0.9.1-rc; the fix should include a small C/C++ fixture for include-to-header IMPORTS edges and avoid confusing header targets with same-named module/source nodes.

fix: resolve C/C++ includes to header file targets by matching stems

Root cause found — it's deeper than missing edge extraction, and your zero-inbound number now makes complete sense.

cbm_pipeline_fqn_compute strips file extensions when deriving qualified names, so a header and its same-stem source collide on both derived QNs:

NodeController.h → module proj.NodeController, file proj.NodeController.__file__
NodeController.cpp → module proj.NodeController, file proj.NodeController.__file__

Node upserts match by qualified name, so the header's File node is merged into the source's — the header ends up with no node of its own in the graph at all. Your #include "NodeController.h" IS extracted and resolved, but it lands on the shared module node (named after the .cpp), which is exactly what you observed. Every header with a same-stem sibling is invisible; that's the bulk of your 194/214.

Reproduced on your exact shape (main.cpp + NodeController.h/.cpp): the header has zero nodes and zero possible inbound edges. #1052 adds the reproduce-first test that stays RED until fixed.

Fix plan: headers get their own File-node identity and #include edges target it. One constraint makes this a careful change rather than a quick one: the module-QN unification between header and source is load-bearing for C/C++ call resolution (declaration↔definition joins), so only the File identity may split. It also touches the same code paths as #995 (in review), so it lands right after that to keep full and incremental builds consistent. Both are on the 0.9.1-rc milestone.

Thanks for the zero-inbound Cypher query — it's a genuinely useful detector for this class.

Merge pull request #1052 from DeusData/repro/964-header-qn-collision

test(repro): RED reproduction for DeusData#964 header QN collision

@Sinjan-Debnath

Reopening for the remaining half. PR #983 (merged in 4c60111, @Sinjan-Debnath) fixed the include resolution: #include "X.h" now targets the X Class node instead of the wrong same-stem .cpp module — verified. Shipping in v0.9.1.

Still open: the header File-node collision. A header with a same-stem .cpp sibling (NodeController.h + NodeController.cpp) still gets no File node of its own — cbm_pipeline_fqn_compute strips the extension, so header and source collide on the File QN and the header's node is merged into the .cpp's. (Standalone headers with no .cpp sibling do get their own File node, confirming this is a collision, not by-design.) The reproduce-first guard for this is tests/repro/repro_issue964.c (RED). I'll take this follow-up — it touches FQN computation and the two File-node creation sites (full + incremental), and needed #995 to land first (now merged).

fix(fqn): preserve full filename in File-node QNs so sibling files do…

Navigation Menu

Repository navigation

C/C++ #include not mapped as IMPORTS edges — expected or a bug? #964

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

C/C++ #include not mapped as IMPORTS edges — expected or a bug? #964

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Activity

DeusData commented on Jul 8, 2026

DeusData commented on Jul 12, 2026

DeusData commented on Jul 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions