fix: use the correct calling convention when over-applying a closure in lean_apply_m - #14969
Draft
Kha wants to merge 1 commit into
Draft
fix: use the correct calling convention when over-applying a closure in lean_apply_m#14969Kha wants to merge 1 commit into
lean_apply_m#14969Kha wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
toolchain-available
|
Mathlib CI status (docs):
|
Collaborator
|
Reference manual CI status:
|
…in `lean_apply_m` This PR fixes a crash when more than 16 arguments are applied at once to a closure whose arity is at most 16. Deeply nested monad stacks can produce such applications, and the result was memory corruption rather than a clean call. `lean_apply_m` handles applications of more than 16 arguments. Its over-application branch invoked the closure through `FNN`, which passes arguments as an array. That convention is only correct for closures whose arity exceeds `LEAN_CLOSURE_MAX_ARGS`; below that the generated code takes its arguments separately, so the callee received the argument array in its first parameter and register garbage in the rest. The fixed-arity `lean_apply_N` functions already guard this, `lean_apply_15` even asserting `arity > 16` immediately before its `FNN` call. The over-application branch now applies the first `arity - fixed` arguments via `lean_apply_n`, which dispatches on the count and consumes the closure, and continues with the remainder.
Kha
force-pushed
the
runtime-apply-m-fix
branch
from
August 29, 2026 19:50
ae5d019 to
df1b1f0
Compare
github-actions
Bot
added
the
mathlib4-nightly-available
leanprover-bot
added
the
builds-manual
mathlib-lean-pr-testing
Bot
added
the
builds-mathlib
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
2 participants
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.
This PR fixes a crash when more than 16 arguments are applied at once to a closure whose arity is at most 16. Deeply nested monad stacks can produce such applications, and the result was memory corruption rather than a clean call.
lean_apply_mhandles applications of more than 16 arguments. Its over-application branch invoked the closure throughFNN, which passes arguments as an array. That convention is only correct for closures whose arity exceedsLEAN_CLOSURE_MAX_ARGS; below that the generated code takes its arguments separately, so the callee received the argument array in its first parameter and register garbage in the rest. The fixed-aritylean_apply_Nfunctions already guard this,lean_apply_15even assertingarity > 16immediately before itsFNNcall. The over-application branch now applies the firstarity - fixedarguments vialean_apply_n, which dispatches on the count and consumes the closure, and continues with the remainder.