feat: extend CFG to all supported languages#283
Conversation
Add control flow graph support for Python, Go, Rust, Java, C#, Ruby,
and PHP. The core algorithm was already language-agnostic; this adds
per-language CFG_RULES mapping tree-sitter node types and refactors
processIf (3 else-if patterns), getStatements (blockNodes set),
processStatement (expression_statement unwrapping, unless/until), and
processSwitch/processTryCatch for cross-language flexibility. Adds
processInfiniteLoop for Rust's `loop {}`.
Also fixes C# language ID mismatch (`c_sharp` → `csharp`) in
COMPLEXITY_RULES, HALSTEAD_RULES, and COMMENT_PREFIXES, and corrects
`for_each_statement` → `foreach_statement` to match tree-sitter.
Impact: 8 functions changed, 11 affected
|
Claude finished @carlos-alm's task —— View job PR Review: Extend CFG to All Supported LanguagesConducting comprehensive review following the 4-phase methodology: Todo List
Phase 1: Root Cause Analysis ✅Problem Being Solved: The CFG (Control Flow Graph) functionality was previously limited to JavaScript/TypeScript/TSX only. This PR extends it to all 10 supported languages (Python, Go, Rust, Java, C#, Ruby, PHP) to provide consistent analysis capabilities across the entire codebase. Why This Approach: The approach is well-justified:
Risk Assessment: LOW RISK - This is pure feature expansion with extensive test coverage. No existing functionality is modified. Phase 2: Configuration Change Detection ✅No problematic configuration changes detected. The changes are:
These are genuine fixes, not workarounds to silence errors. Phase 3: Test Integrity ✅Excellent test coverage:
The test design follows established patterns and maintains high quality standards. Phase 4: Code Quality Review ⭐Strengths:
Minor concerns:
Security/Performance: No concerns. Pure AST processing with no external input or command execution. Root Cause AnalysisProblem Being Solved: Extend CFG functionality from JS/TS/TSX-only to all 10 supported languages, providing consistent control flow analysis across the entire codebase. Why This Approach: Declarative rule-based system allows each language to define its control flow constructs while reusing the core CFG algorithm. Also fixes real bugs in C# language ID and node type mismatches. Risk Assessment: LOW - Pure feature expansion with comprehensive test coverage. No existing functionality modified. Critical Concerns (if any)None identified. This is a well-implemented feature expansion with proper testing. Final Recommendation
Recommended next steps: After merge, verify |
Greptile SummarySuccessfully extends CFG support from JS/TS/TSX to all 10 supported languages (Python, Go, Rust, Java, C#, Ruby, PHP). Major changes:
The implementation is thorough and handles the nuances of each language's syntax tree structure correctly. Confidence Score: 5/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
Start[processIf: Handle if/else chain] --> CheckElif{rules.elifNode<br/>defined?}
CheckElif -->|Yes| PatternB[Pattern B: Siblings<br/>Python, Ruby, PHP]
CheckElif -->|No| CheckAlt{alternative<br/>node exists?}
PatternB --> ProcessSiblings[processElifSiblings<br/>iterate through children<br/>find elif/else nodes]
CheckAlt -->|No| NoElse[Add false edge<br/>to join block]
CheckAlt -->|Yes| CheckElseVia{elseViaAlternative<br/>AND not elseClause?}
CheckElseVia -->|Yes| PatternC[Pattern C: Direct<br/>Go, Java, C#]
CheckElseVia -->|No| CheckWrapper{alternative.type<br/>== elseClause?}
PatternC --> IsIfNode{alternative is<br/>if_statement?}
IsIfNode -->|Yes| RecurseC[Recurse processIf<br/>for else-if]
IsIfNode -->|No| ElseBlockC[Process else block]
CheckWrapper -->|Yes| PatternA[Pattern A: Wrapper<br/>JS/TS, Rust]
CheckWrapper -->|No| NoElse
PatternA --> CheckInner{inner child is<br/>if_statement?}
CheckInner -->|Yes| RecurseA[Recurse processIf<br/>for else-if]
CheckInner -->|No| ElseBlockA[Process else block]
ProcessSiblings --> Join[Return join block]
RecurseC --> Join
ElseBlockC --> Join
RecurseA --> Join
ElseBlockA --> Join
NoElse --> Join
Last reviewed commit: 2f3ac78 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
src/cfg.js
Outdated
| /** | ||
| * Process an if/else-if/else chain. | ||
| * Handles three patterns: | ||
| * A) Wrapper: alternative → else_clause → nested if or block (JS/TS, C#, Rust) |
There was a problem hiding this comment.
C# listed under Pattern A (Wrapper), but config has elseClause: null + elseViaAlternative: true, which routes it to Pattern C (Direct)
| * A) Wrapper: alternative → else_clause → nested if or block (JS/TS, C#, Rust) | |
| * A) Wrapper: alternative → else_clause → nested if or block (JS/TS, Rust) |
There was a problem hiding this comment.
Fixed in 2f3ac78 — moved C# from Pattern A to Pattern C in the comment to match the actual config (elseClause: null, elseViaAlternative: true).
Impact: 1 functions changed, 1 affected
|
Claude finished @carlos-alm's task —— View job PR Review: Extend CFG to All Supported LanguagesConducted comprehensive review following the 4-phase methodology: Todo List
Phase 1: Root Cause Analysis ✅Problem Being Solved: The CFG (Control Flow Graph) functionality was previously limited to JavaScript/TypeScript/TSX only. This PR extends it to all 10 supported languages (Python, Go, Rust, Java, C#, Ruby, PHP) to provide consistent analysis capabilities across the entire codebase. Why This Approach: The approach is well-justified:
Risk Assessment: LOW RISK - This is pure feature expansion with extensive test coverage. No existing functionality is modified. Phase 2: Configuration Change Detection ✅No problematic configuration changes detected. The changes are:
These are genuine fixes, not workarounds to silence errors. Phase 3: Test Integrity ✅Excellent test coverage:
The test design follows established patterns and maintains high quality standards. Phase 4: Code Quality Review ⭐Strengths:
Minor concerns:
Security/Performance: No concerns. Pure AST processing with no external input or command execution. Root Cause AnalysisProblem Being Solved: Extend CFG functionality from JS/TS/TSX-only to all 10 supported languages, providing consistent control flow analysis across the entire codebase. Why This Approach: Declarative rule-based system allows each language to define its control flow constructs while reusing the core CFG algorithm. Also fixes real bugs in C# language ID and node type mismatches. Risk Assessment: LOW - Pure feature expansion with comprehensive test coverage. No existing functionality modified. Critical Concerns (if any)None identified. This is a well-implemented feature expansion with proper testing. Final Recommendation
Recommended next steps: After merge, verify |
1 participant
Summary
c_sharp→csharpinCOMPLEXITY_RULES,HALSTEAD_RULES, andCOMMENT_PREFIXES(was silently broken since C# was added)for_each_statement→foreach_statementto match actual tree-sitter node typeChanges
src/cfg.jsCFG_RULES/CFG_LANG_IDSregistration,processIf3-pattern refactor,processInfiniteLoop,expression_statementunwrapping,blockNodesset ingetStatements, flexibleprocessSwitch/processTryCatchsrc/complexity.jsc_sharp→csharp(3 maps),for_each_statement→foreach_statement,elseViaAlternative: truefor C#tests/unit/cfg.test.jstests/unit/complexity.test.jsc_sharp→csharpin test assertionsTest plan
build --cfgon a multi-language project end-to-end