Extend CapturedEnv to include function parameters used in loop conditions,
enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`.
Phase 245C changes:
- function_scope_capture.rs: Add collect_names_in_loop_parts() helper
- function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic
- function_scope_capture.rs: Add 4 new comprehensive tests
Test fix:
- expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support
(validation happens during lowering in MethodCallLowerer)
Problem solved: "Variable not found: s" errors in loop conditions
Test results: 924/924 PASS (+13 from baseline 911)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Clarifies that LoopScopeShape has two complementary construction paths
for different contexts (AST-based vs LoopForm-based).
## Analysis
After investigating, discovered these builders serve **different purposes**:
1. **AST-based** (`patterns/loop_scope_shape_builder.rs`):
- Builds from AST during MIR generation
- Extracts body_locals from ASTNode::Local declarations
- Used in Pattern 1-4 lowerers
2. **LoopForm-based** (`loop_scope_shape/builder.rs`):
- Builds from LoopForm during JoinIR lowering
- Analyzes LoopFormIntake snapshots
- Used in generic_case_a and pattern routing
These are NOT duplicates - they're complementary paths!
## Changes
1. **Cross-Reference Documentation**:
- `patterns/loop_scope_shape_builder.rs`: Added Phase 183-3 section
- `loop_scope_shape/builder.rs`: Added Phase 183-3 section
- Both now reference each other for clarity
2. **LoopScopeShape Struct Documentation**:
- Added "Phase 183-3: Construction Paths" section
- Documents two construction paths and their contexts
- Explains when to use each builder
3. **Clarified Responsibilities**:
- AST-based: For MIR building phase
- LoopForm-based: For JoinIR lowering phase
- Both maintain consistent field initialization
## Benefits
- **Clear separation**: Documented different contexts for each builder
- **Maintainability**: Future developers understand which builder to use
- **No code changes**: Pure documentation improvement
- **Cross-references**: Easy navigation between related modules
## Testing
✅ All loop_scope_shape tests pass (24 tests)
✅ No behavioral changes
✅ Documentation-only refactoring
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Wire LoopUpdateSummary box into real code paths:
- Add `update_summary: Option<LoopUpdateSummary>` field to LoopFeatures
- Add `detect_with_updates()` method to CaseALoweringShape
- Uses UpdateKind (CounterLike/AccumulationLike) for classification
- Single CounterLike carrier → StringExamination
- AccumulationLike present → ArrayAccumulation or IterationWithAccumulation
- Update loop_to_join.rs to use detect_with_updates()
- Update deprecated detect() to use detect_with_updates() internally
- Set update_summary: None in AST-based feature extraction
Carrier name heuristics now encapsulated in LoopUpdateSummary box.
No regression: 15/16 loop smoke tests pass (1 failure is pre-existing).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add detect_with_carrier_name() to improve CaseALoweringShape detection
accuracy by using carrier variable names as a heuristic.
Since LoopUpdateAnalyzer operates at AST level (not accessible from MIR),
use carrier naming conventions instead:
- Typical index names (i, e, idx, pos, start, end) → StringExamination
- Other names (result, items, defs) → ArrayAccumulation
This reduces Generic fallback cases for single-carrier loops.
Changes:
- case_a_lowering_shape.rs: Add detect_with_carrier_name(), is_typical_index_name()
- loop_to_join.rs: Extract progress_carrier name, call new detection function
Phase 170-C-2 can add MIR-based update pattern analysis for higher accuracy.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Clarify design principle: CaseALoweringShape does NOT look at function names.
Input must be LoopFeatures/LoopPatternKind only (structure-based detection).
Changes:
- Add detect_from_features(LoopFeatures, carrier_count, has_progress_carrier)
- Deprecate detect(LoopScopeShape) with backward-compat wrapper
- Case-A now rejects loops with `has_continue` (only break is allowed)
- Document Phase 170-B future work (loop body AST analysis)
Design Principle:
> "CaseALoweringShape は 関数名を見ない。LoopFeatures/LoopPatternKind だけを入力にする"
This ensures generic routing works for ANY structurally matching loop.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
