Hi, thanks for building such an amazing project! I've been testing CodeGraph for AI code exploration and the performance improvements over traditional RAG and grep/glob loops are incredible.
I am currently exploring its applicability in the Automotive software domain, specifically for AUTOSAR architecture codebases. While CodeGraph's C/C++ support via compile_commands.json (for resolving -I and -isystem includes) works great for standard C/C++ , production AUTOSAR projects present two unique challenges for AST-based parsing:
-
Heavy Macro Encapsulation (Syntax Parsing Issue):
AUTOSAR strictly uses macros for almost all function and variable declarations to achieve hardware abstraction. A typical function looks like this:
FUNC(void, AUTOMOTIVE_CODE) MyRunnable_Function(VAR(uint8, AUTOMOTIVE_VAR) Parameter1)
Since tree-sitter-c does not perform a full C pre-processing pass , it often fails to parse these as function/method nodes or flags them as ERROR nodes, meaning these core logical entities never make it into the SQLite knowledge graph.
-
RTE (Run-Time Environment) Isolation (Call Graph Issue):
In AUTOSAR, software components (SWCs) do not call each other directly. All cross-component communication goes through generated RTE APIs (e.g., Rte_Call_Port_Operation()), and the actual topology is defined in system description files (.arxml). This breaks static call graphs.
Based on CodeGraph's architecture, I have a few questions on how we might bridge these gaps:
Pre-processing Hook: Is there a recommended way to intercept the extraction pipeline and feed pre-processed C code (e.g., the output of gcc -E) into CodeGraph? This would allow tree-sitter to digest the expanded, standard C syntax instead of the AUTOSAR macros.
Custom Language/Grammar: I noticed the recent addition of the "cookbook for adding a new language extractor". Would it be viable to fork tree-sitter-c, add the AUTOSAR keywords to the grammar, and inject a custom tree-sitter-autosar.wasm into the project?
ARXML Synthesizer for Dynamic Dispatch: I saw that CodeGraph recently added dynamic-dispatch flow synthesis for things like Spring @Autowired, React Native bridges, and EventEmitters. Would the architecture support building a custom synthesizer that parses .arxml files to connect the RTE interface calls, thereby building an end-to-end trace across isolated components?
Local Workarounds / Extensibility: If official support for these automotive patterns isn't on the near-term roadmap, are there any recommended workarounds we could implement on our end? For example, is there a way to inject a custom TypeScript plugin/extractor or pre-processing script locally without having to maintain a hard fork of the entire CodeGraph repository?
Thanks for your time and any pointers you can provide!
Hi, thanks for building such an amazing project! I've been testing CodeGraph for AI code exploration and the performance improvements over traditional RAG and grep/glob loops are incredible.
I am currently exploring its applicability in the Automotive software domain, specifically for AUTOSAR architecture codebases. While CodeGraph's C/C++ support via compile_commands.json (for resolving -I and -isystem includes) works great for standard C/C++ , production AUTOSAR projects present two unique challenges for AST-based parsing:
Heavy Macro Encapsulation (Syntax Parsing Issue):
AUTOSAR strictly uses macros for almost all function and variable declarations to achieve hardware abstraction. A typical function looks like this:
FUNC(void, AUTOMOTIVE_CODE) MyRunnable_Function(VAR(uint8, AUTOMOTIVE_VAR) Parameter1)
Since tree-sitter-c does not perform a full C pre-processing pass , it often fails to parse these as function/method nodes or flags them as ERROR nodes, meaning these core logical entities never make it into the SQLite knowledge graph.
RTE (Run-Time Environment) Isolation (Call Graph Issue):
In AUTOSAR, software components (SWCs) do not call each other directly. All cross-component communication goes through generated RTE APIs (e.g., Rte_Call_Port_Operation()), and the actual topology is defined in system description files (.arxml). This breaks static call graphs.
Based on CodeGraph's architecture, I have a few questions on how we might bridge these gaps:
Pre-processing Hook: Is there a recommended way to intercept the extraction pipeline and feed pre-processed C code (e.g., the output of gcc -E) into CodeGraph? This would allow tree-sitter to digest the expanded, standard C syntax instead of the AUTOSAR macros.
Custom Language/Grammar: I noticed the recent addition of the "cookbook for adding a new language extractor". Would it be viable to fork tree-sitter-c, add the AUTOSAR keywords to the grammar, and inject a custom tree-sitter-autosar.wasm into the project?
ARXML Synthesizer for Dynamic Dispatch: I saw that CodeGraph recently added dynamic-dispatch flow synthesis for things like Spring @Autowired, React Native bridges, and EventEmitters. Would the architecture support building a custom synthesizer that parses .arxml files to connect the RTE interface calls, thereby building an end-to-end trace across isolated components?
Local Workarounds / Extensibility: If official support for these automotive patterns isn't on the near-term roadmap, are there any recommended workarounds we could implement on our end? For example, is there a way to inject a custom TypeScript plugin/extractor or pre-processing script locally without having to maintain a hard fork of the entire CodeGraph repository?
Thanks for your time and any pointers you can provide!