Conversation
The [no_code_pointer] optimisation gives some closures a different env type body (no supertype, no function-ref field). At the registration sites, [arity] was normalised to 0 for these closures, so they registered as [cps_env_0_<id>] / [env_0_<id>]. That was not sufficient, though: a genuine arity-0 closure with a code pointer registers the very same name with an incompatible (with-supertype, function-ref-bearing) body. The two clashed — the first one to register won, and the loser emitted a [struct.new] inconsistent with the recorded type. Loop hoisting and CPS-mode effect handlers are two natural sources of arity-0 closures, making the collision easy to trigger. Drop the arity from the type name when there is no code pointer (arity is implicit in that case, since the struct has no function-ref field). The [arity = 0] normalisation is then redundant in [Closure.bind_environment]; in [Closure.translate] the same applies, with [need_curry_fun] guarded directly on [no_code_pointer] so no unused curry function is emitted.
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
1 participant
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.
The
no_code_pointeroptimisation gives some closures a different env type body (no supertype, no function-ref field). At the registration sites,aritywas normalised to 0 for these closures, so they registered ascps_env_0_<id>/env_0_<id>. That was not sufficient, though: a genuine arity-0 closure with a code pointer registers the very same name with an incompatible (with-supertype, function-ref-bearing) body. The two clashed — the first one to register won, and the loser emitted astruct.newinconsistent with the recorded type.I don't have a reproducer on
master, but the issue occurs both with loop hoisting (#2245) and WASI (#1831) .