Skip to content

Retire dispatch with erroneous operands - #10819

Merged
rtfeldman merged 6 commits into
mainfrom
issue-10765-static-dispatch-error-recovery
Aug 17, 2026
Merged

Retire dispatch with erroneous operands#10819
rtfeldman merged 6 commits into
mainfrom
issue-10765-static-dispatch-error-recovery

Conversation

@rtfeldman

@rtfeldman rtfeldman commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

An erroneous call operand could leave callable unification suppressed after the receiver's constraint set had already selected a different callable, causing checked-artifact publication to panic. This consumes the checker's exact erroneous-expression record to retire source calls before constraint introduction; required iterator topology plans instead carry explicitly rejected callable shapes. Independently valid sibling dispatch remains intact. Fixes #10765.

@rtfeldman
rtfeldman marked this pull request as ready for review August 17, 2026 01:09
@rtfeldman
rtfeldman merged commit b9ca140 into main Aug 17, 2026
21 checks passed
@rtfeldman
rtfeldman deleted the issue-10765-static-dispatch-error-recovery branch August 17, 2026 01:10
@greptile-apps

greptile-apps Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR prevents erroneous call operands from contributing invalid static-dispatch constraints while preserving valid sibling dispatch.

  • Adds a per-expression record for operand checks whose resulting value type contains an error.
  • Retires affected calls, operators, interpolation, equality, and method dispatch before introducing constraints.
  • Records explicitly rejected iter and next callable shapes for erroneous iterator loops so required topology remains publishable.
  • Adds issue Panic: constraint-resolved dispatch callable was not the scheme-pristine constraint fn type #10765 compile regressions and updates affected snapshots and design documentation.

Confidence Score: 5/5

The PR appears safe to merge; no concrete blocking or independently actionable non-blocking issue was identified.

The new error record is consumed before dispatch constraints are introduced, and required iterator plans retain publishable callable shapes whose rejection is explicitly converted to checked-error resolution downstream.

Important Files Changed

Filename Overview
src/check/Check.zig Introduces exact erroneous-operand tracking, call retirement, and rejected iterator dispatch plans; investigated downstream consumers consistently honor the new recovery state.
src/compile/test/issue_10765_test.zig Adds regression coverage for operand ordering, nested dispatch, iterator recovery, and recursive calls affected by issue #10765.
design.md Documents the operand-retirement invariant and the special rejected-plan behavior required by iterator loops.
src/compile/mod.zig Registers the new issue #10765 regression suite with the compile tests.
test/snapshots/static_dispatch/plus_operator_vs_method.md Updates checked output to reflect retirement of an erroneous operator expression while preserving its annotated type.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Check operand expression] --> B{Checked value contains error?}
    B -- No --> C[Introduce dispatch constraint]
    B -- Yes --> D[Record erroneous operand identity]
    D --> E{Parent requires iterator topology?}
    E -- No --> F[Retire parent call-like expression]
    E -- Yes --> G[Create rejected iter and next callable shapes]
    F --> H[Publish explicit runtime error]
    G --> I[Record topology plan]
    I --> J[Resolve iterator calls as checked_error]
Loading

Reviews (1): Last reviewed commit: "Update error retirement snapshots" | Re-trigger Greptile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Panic: constraint-resolved dispatch callable was not the scheme-pristine constraint fn type

1 participant