Fix non-converging generic parameter inference loop (A3)#216
Merged
Conversation
Two defects fed each other in resolveGenericParamsFromFunctionCall: - optional/multi-args params past the call operands were counted as progress every round without being marked processed, inflating totalProcessed past the == termination check - the origin of the "loop detected" +100 guard. They are now marked processed and counted once. - that double-counting was also load-bearing: for signatures like reduce2<T, V = T>(..., initial?: V) a callback param typed by a defaulted type param can never resolve inside the loop (defaults zip after it), and only the inflated count let the loop exit. A no-progress round now breaks out instead of erroring, letting the default zipping and the existing completeness check decide. The +100 guard is now defensive-only (each param counted at most once). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Root-causes and fixes A3 from
docs/MLIRGen-refactoring-review.md— the// TODO: find out the issuebehind the arbitrary+100"loop detected." guard inresolveGenericParamsFromFunctionCall.Two defects fed each other:
callOpsCountdidprocessed++each iteration without being markedprocessed, sototalProcessedinflated by that count per round and could step right over the==termination check — spinning the loop into the +100 guard. They are now markedprocessedand counted exactly once.reduce2<T, V = T>(this: T[], func: (v: V, t: T) => V, initial?: V), the callback param can never resolve inside the loop —Vonly gets its value from the default zipping that runs after it — and only the inflated count let the loop terminate. With honest counting, a zero-progress round nowbreaks out of the loop instead of erroring immediately, letting the default zipping and the existing completeness check (typeParamsWithArgs.size() < typeParams.size()→ the same "not all types could be inferred" message) decide whether inference actually failed.Net effect: each param is counted at most once, the loop terminates by equality or by no-progress, and the +100 guard is now defensive-only (documented as such). One deliberate semantic refinement: a program whose type params are fully resolved despite an unresolvable-in-loop param now proceeds (previously it errored) — that is the
reduce2shape, which the old code only accepted by accident of the double-count.Test plan
01lambdasfailing in compile + JIT) and drove the two-part fix — the final design is validated against the real corpus, not just theoryapply2<T, R>(f, v, tag?)→42) verified🤖 Generated with Claude Code