Hello GCC developers, I am exploring the cp-demangle non-recursive refactoring idea as a potential Google Summer of Code 2026 project, and wanted to ask a few technical questions to make sure I am understanding the code and problem space correctly.
I have been reading through cp-demangle.h and cp-demangle.c to get familiar with the structure. From what I can see, recursion is primarily driven through mutual recursion across functions such as: cplus_demangle_mangled_name d_encoding d_name d_bare_function_type d_type d_expression d_nested_name and template argument handling Even though d_info tracks recursion_level explicitly, most of the parser state and resume points appear to be implicit in the C call stack and local variables. My current understanding is that the main challenge in removing recursion would be to externalize this control flow into explicit heap-allocated frames that capture per-call state and allow the demangler to be driven by an explicit work stack or state machine. Before I go too far in this direction, I wanted to ask: - Are these the main recursion hotspots that tend to cause deep or unbounded recursion in practice? - Are there specific functions or grammar productions that are known to be especially problematic? - Does this general approach (explicit frames plus iterative dispatcher) match what maintainers would expect for this project? For background, I have experience working on low-level C and C++ systems code and refactoring implicit control flow into explicit state machines (for example in Linux-kernel-adjacent projects and runtime code). I am very interested in compilers and tooling infrastructure, and would like to make sure I am approaching this in a way that aligns with GCC expectations. Any pointers or guidance would be very helpful. Thank you for your time. Best regards, Ashwani Kamal GitHub: https://github.com/sneaky-potato
