Skip to content

fix #18556: avoid crash on nested void proc result assignment - #25986

Open
nimamasl114514 wants to merge 1 commit into
nim-lang:develfrom
nimamasl114514:fix-18556
Open

fix #18556: avoid crash on nested void proc result assignment#25986
nimamasl114514 wants to merge 1 commit into
nim-lang:develfrom
nimamasl114514:fix-18556

Conversation

@nimamasl114514

Copy link
Copy Markdown
Contributor

Summary

  • Type-incorrect nested proc with
    esult = expr\ caused compiler internal error crash instead of a friendly type error.
  • Root cause: when
    esult\ inside a nested void proc was captured via closure and referred to the outer proc's
    esultSym, \semAsgn\ assumed it belonged to the current proc and hit \internalAssert(c.p.resultSym != nil)\ on the void proc which has no
    esultSym.

Fix

Only run the return-type inference path when the result sym actually belongs to the current proc owner:

\
im
if lhs.sym.owner == c.p.owner and
c.p.owner.kind != skMacro and resultTypeIsInferrable(lhs.sym.typ):
\\

Repro

\
im
proc p(): auto =
result = proc(): auto =
result = 42 # type error: should be friendly, not crash
\\

Before: \internalError\ crash at \compiler/semexprs.nim:2125.
After: \ ype mismatch: p(): void\ friendly error.

Testing

  • Original issue repro now emits friendly type error instead of crash
  • koch boot rebuild succeeds

Fixes #18556.

When 'result' inside a nested void proc is captured via closure and
refers to the outer proc's resultSym, semAsgn assumed it belonged to
the current proc and hit internalAssert(c.p.resultSym != nil) on the
void proc which has no resultSym.

Only run the return-type inference path when the result sym actually
belongs to the current proc owner.
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.

Badly Typed Nested Procs Cause Compiler Crash

1 participant