fix(p4): math関数算術 & variadic min/max を正答化 (closes #21; refs #22,#43) by opaopa6969 · Pull Request #34 · opaopa6969/tinyexpression

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969 · 2026-06-25T12:33:09Z

概要

P4_AST_EVALUATOR で abs(-3)+pow(2,3) が StackOverflow→誤値、min(3,5,1)/max(3,5,1,9) が cross-check により 誤legacy値(3/5)で上書き されていた問題を修正。

根因は unlaxer-dsl の生成マッパーが算術コンテキストの関数項を脱落させていたこと（unlaxer-parser #43 / PR #44 で根治）。本PRは unlaxer-dsl 3.0.5 を採用し、widメンされた BinaryExpr オペランド型に評価器を追従させ、cross-check を是正する。

変更

P4TypedAstEvaluator: evalBinaryAsNumber がオペランドを evalOperandAsNumber でディスパッチ（BinaryExprはスパイン継続、AbsExpr/PowExpr/IfExpr等は eval）。source-snippet経路は ExpressionExpr を unwrap してから BinaryExpr ガードに入れ、abs(-3)+pow(2,3) の無限再帰(StackOverflow)を解消。
P4DefaultJavaCodeEmitter/P4TypedJavaCodeEmitter: renderOperand で同様にディスパッチ。
AstDeclarationRuntime: 宣言式の主式を source-aware な P4TypedAstEvaluator で評価（$price+2 がreflection経路に落ちて setter値を返していた回帰を修正）。
AstEvaluatorCalculator: 数値 cross-check が正しいP4結果を壊れたlegacy(variadic min/max・boolean優先順位)で上書きしないよう、P4を信頼し差分は観測markerのみ記録 (cross-check が正しいP4結果を壊れたlegacyで上書きする (variadic min/max・boolean優先順位・関数項脱落) #21)。

検証

abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, 宣言式 $price+2=5 — 全て p4-typed で正答。パリティ/コーパス各スイート緑、回帰ゼロ。

⚠️ マージ前提

unlaxer-dsl 3.0.5 の公開が必要（依存）。unlaxer-parser PR #44 をマージ＆ Maven Central へ 3.0.5 をデプロイ後でないと、本PRのCIは依存解決に失敗します。

未対応（#22 残）

.in() 意味バグ(常時true)、ダブルクォート+ドットメソッド parse、メソッド引数スコープ。#43 case3(variadic mapper rest-capture, 無害) も将来。

🤖 Generated with Claude Code

…#21; refs #22, #43) Adopts unlaxer-dsl 3.0.5, whose generated mapper now maps a function/conditional factor operand to its real AST node instead of dropping it. Adapts the P4 evaluators to the widened BinaryExpr operand type (base AST interface) and fixes the cross-check: - P4TypedAstEvaluator: evalBinaryAsNumber dispatches each operand via evalOperandAsNumber (BinaryExpr stays on the spine; AbsExpr/PowExpr/IfExpr/… go through eval), and the source-snippet path unwraps ExpressionExpr before its BinaryExpr guard to stop the infinite recursion that StackOverflowed on "abs(-3)+pow(2,3)". - P4DefaultJavaCodeEmitter / P4TypedJavaCodeEmitter: renderOperand dispatches operands to the same effect for the Java-code backends. - AstDeclarationRuntime: evaluate a declaration's main expression with the source-aware P4TypedAstEvaluator so "$price+2" stays on the typed path (was falling to the reflection evaluator and returning the setter value). - AstEvaluatorCalculator: the numeric cross-check no longer discards a correct P4-typed result for the buggy legacy token-AST (variadic min/max, boolean precedence). Now that P4-typed math is correct it keeps the P4 result and only records the divergence (#21). Verified: abs(-3)+pow(2,3)=11, min(3,5,1)=1, max(3,5,1,9)=9, sqrt(4)*5=10, declaration "$price+2"=5 — all P4-typed; parity/corpus suites green, no regressions. Resolves the #22 javacode-math gap; the remaining #22 items (.in semantics, double-quote dot methods, method-arg scope) are not addressed here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e-text splitter Now that the mapper maps StringComparisonExpr.left/right to the correct operand nodes (unlaxer-dsl 3.0.5, findDescendants rule-level fix), evalStringComparisonExpr evaluates node.left()/node.right() directly instead of re-splitting the source formula at the top-level ==/!= by hand. Removes the hand-rolled char-scanning workaround that this obsoletes: tryExtractStringComparisonFromSourceFormula / splitTopLevelStringComparison / matchesComparisonOperator / resolveStringComparisonSide / tryEvaluateStringSourceSnippet and the StringComparisonSource record (~130 lines). The combinator-generated AST is the single source of truth; consumers no longer reparse the source string. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… from AST (#35) The post-#44 mapper maps every arithmetic operand to a real AST node (mapAssocOperandToBinaryExpr), so BinaryExpr.left()/op()/right() is now a faithful tree. The source-text re-parse shadows that preceded the AST walk were therefore dead compensation: - P4TypedAstEvaluator: remove tryEvaluateStructuredBinaryNode / tryEvaluateStructuredBinarySourceSnippet / hasStructuredNumericAlternative - P4TypedJavaCodeEmitter / P4DefaultJavaCodeEmitter: remove renderStructuredBinaryNode / renderStructuredBinarySourceSnippet / hasStructuredNumericAlternative evalBinaryExpr / evalBinaryAsNumber now go straight to the AST walk. The slice path keeps renderNumericSourceSnippet for now (separate #35 cycle). Verified: full suite 630 tests, baseline gate green (no new failures), legacy-fallback observations 171->170. -120 LOC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Both AstEvaluatorCalculatorTest#testTypeInference and P4AstEvaluatorCalculatorTest#testTypeInference pass consistently across three full runs after the 3.0.5 mapper fix + numeric-leaf cycle. The baseline gate flagged them as FIXED; tightening it so a future regression in type inference fails CI again. Only the double-parens-ternary parse case (exponential backtracking) remains known-failing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

opaopa6969and others added 2 commits June 25, 2026 21:32

This was referenced Jun 25, 2026
refactor: ソース文字列再パースworkaround層をAST直接利用へ真っ当化 (~180箇所/17ファイル) #35
Closed
handoff: P4 fallback=0 セッション (2026-06-25) — #43根治/#21/string比較、残作業と再開手順 #36
Closed

opaopa6969and others added 2 commits June 26, 2026 00:47

opaopa6969 merged commit d7bcb26 into masterJun 25, 2026
1 of 2 checks passed

opaopa6969 mentioned this pull request Jun 26, 2026
handoff: P4 fallback=0 セッション (2026-06-26) — #43 codegen根治継続 / #32 第2段 string-concat fold widening の再開手順 #40
Closed

Conversation

opaopa6969 commented Jun 25, 2026

概要

変更

検証

⚠️ マージ前提

未対応（#22 残）

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

opaopa6969 commented Jun 25, 2026

概要

変更

検証

⚠️ マージ前提

未対応（#22 残）

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

opaopa6969 commented Jun 25, 2026

概要

変更

検証

⚠️ マージ前提

未対応（#22 残）

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

opaopa6969 commented Jun 25, 2026

概要

変更

検証

⚠️ マージ前提

未対応（#22 残）

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

opaopa6969 commented Jun 25, 2026

概要

変更

検証

⚠️ マージ前提

未対応（#22 残）

Uh oh!

Uh oh!

Reviewers

Assignees

Labels