Refactor ir module: split large module into dedicated files

[coderabbitai]

Problem

The ir module exceeds the 400-line guideline, making it harder to navigate and maintain.

Proposed Solution

Split the module into dedicated files for better organization:

• Graph structures
• Cycle detection logic
• Helper functions

This would improve code clarity and make the codebase easier to navigate.

Context

• Identified during code review in PR Clean workflow cache before build #69
• Comment: Clean workflow cache before build #69 (comment)
• Issue: Refactor ir module: split large module into dedicated files #72

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the issue criticality (critical, high, medium or low), based on risk of the issue impacting the user and the anticipated blast radius.

Once a decision has been made, apply the appropriate label.

If the issue is documentation ONLY (i.e., no code changes needed), apply the documentation label in addition to the appropriate criticality label.

Please also provide an impact of the required changes.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the ir module file(s) in the codebase
echo "=== Searching for ir module files ==="
fd -t f "ir" --extension py

echo -e "\n=== Searching for files containing 'ir' in name ==="
fd -t f -g "*ir*" --extension py

echo -e "\n=== Checking if there's a dedicated ir directory ==="
fd -t d "ir"

echo -e "\n=== Looking for any Python files that might contain IR-related code ==="
rg -l --type py "class.*IR|def.*ir_|IR_|_ir_" | head -10

Length of output: 776

---

🏁 Script executed:

#!/bin/bash
# Get overall codebase structure
echo "=== Repository structure ==="
find . -type f -name "*.py" | head -20

echo -e "\n=== Directory structure ==="
ls -la

echo -e "\n=== Looking for source directories ==="
find . -type d -name "src" -o -name "lib" -o -name "netsuke" | head -10

echo -e "\n=== All Python files in the repository ==="
fd -t f -e py | head -20

echo -e "\n=== Search for any mention of 'ir' in Python files (case insensitive) ==="
rg -i "ir" --type py -C 2 | head -30

Length of output: 2350

---

🏁 Script executed:

#!/bin/bash
# Search for Rust files and the ir module
echo "=== All Rust source files ==="
fd -t f -e rs | head -20

echo -e "\n=== Contents of src directory ==="
ls -la src/

echo -e "\n=== Looking for ir module or ir-related files ==="
fd -t f -g "*ir*" -e rs

echo -e "\n=== Searching for 'mod ir' or 'pub mod ir' declarations ==="
rg -n "mod ir" --type rust -C 2

echo -e "\n=== Searching for any mention of 'ir' in Rust files ==="
rg -n "\bir\b" --type rust | head -20

Length of output: 3502

---

🏁 Script executed:

#!/bin/bash
# Check the line count and structure of the ir.rs file
echo "=== Line count of src/ir.rs ==="
wc -l src/ir.rs

echo -e "\n=== File size and details ==="
ls -lh src/ir.rs

echo -e "\n=== Structure analysis - top 50 lines to see imports, structs, enums ==="
head -50 src/ir.rs

echo -e "\n=== Count of functions, structs, enums, and impl blocks ==="
echo "Functions:"
rg -c "^pub fn|^fn" src/ir.rs

echo "Structs:"
rg -c "^pub struct|^struct" src/ir.rs

echo "Enums:"
rg -c "^pub enum|^enum" src/ir.rs

echo "Impl blocks:"
rg -c "^impl" src/ir.rs

echo -e "\n=== Overview of major code blocks ==="
rg -n "^(pub )?(struct|enum|fn|impl)" src/ir.rs

Length of output: 3226

---

@leynos The issue is still relevant. I've examined the current state of the ir module:

Current State Analysis

The src/ir.rs file currently has 431 lines, which still exceeds the 400-line guideline. The module has grown rather than been refactored since the issue was created.

Issue Relevance: ✅ STILL RELEVANT

No refactoring has been done. The file remains a single large module containing:

• 3 structs (BuildGraph, Action, BuildEdge)
• 2 enums (IrGenError, VisitState)
• 11 functions (including cycle detection and helper functions)
• 1 impl block

Criticality Assessment: LOW

• Risk to users: Minimal - this is an internal code organization issue
• Blast radius: Low - affects maintainability, not functionality
• Impact: Developer productivity and code navigation, not user-facing features

Impact of Required Changes

Effort: Medium refactoring task requiring:

1. Graph structures → separate file (BuildGraph, BuildEdge)
2. Cycle detection → dedicated module (find_cycle, canonicalize_cycle, etc.)
3. Helper functions → utilities module
4. Error types → errors module

Benefits:

• Improved code navigation and maintainability
• Clearer separation of concerns
• Easier testing of individual components
• Better adherence to coding guidelines

Risk: Low - internal refactoring with existing comprehensive test coverage (tests/ir_tests.rs, tests/ir_from_manifest_tests.rs)

The issue requires code changes only (not documentation), so no additional documentation label is needed.

---

🏁 Script executed:

#!/bin/bash
# Apply the low criticality label to the issue
gh issue edit 72 --add-label "low"

Length of output: 78

---

Perfect! I've successfully applied the low criticality label to issue #72. The assessment is complete and the issue has been properly categorized based on its impact on maintainability rather than user-facing functionality.

The 431-line ir.rs module clearly exceeds the 400-line guideline and would benefit from the proposed refactoring into dedicated files for graph structures, cycle detection logic, and helper functions. While this is a low-priority maintainability improvement rather than a critical bug, it will enhance code organization and developer experience once addressed.