Raise LocalJumpError if returning from proc inside lambda inside method outside of the lambda #4223
Conversation
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
…od outside of the lambda Previously, return in a proc inside a lambda inside a method could return to two separate places. If the return occurred while still inside the lambda, it returned to the lambda. If the return occured while outside the lambda, it returned to the method. Fix this by checking the parent iseqs of the proc for a lambda proc, and recording the iseq. When processing the callstack looking for the return target, if you don't find a lambda proc or you find a different lambda proc that the expected lambda proc, it means the lambda proc has already returned, and therefore the proc return should raise a LocalJumpError. This currently adds a param flag on the iseq for whether the iseq is a lambda proc, since I cannot figure out how to get the proc object from the parent iseq to check whether it is a lambda proc. Fixes [Bug #17105]
headius
approved these changes
Feb 25, 2021
There was a problem hiding this comment.
I cannot review the C code portions of this, but I can confirm that the added test cases match JRuby behavior we fixed in jruby/jruby#6351 using a similar strategy.
|
Sorry for long absent. def foo(maker)
pr = send(maker){
proc{ return :inner }
}
innner_pr = pr[]
innner_pr[]
:never
end
begin
p foo(:lambda)
rescue => e
p e
end
begin
p foo(:proc)
rescue => e
p e
endis expected but |
|
@ko1 Is it possible to fix this issue with the current VM design? I couldn't determine how to get access to the proc/lambda at the point that the |
|
I find the way to implement this spec with current information, but it is complicated.... |
ko1
added a commit
to ko1/ruby
that referenced
this pull request
Apr 1, 2021
A "return" statement in a Proc in a lambda like:
`lambda{ proc{ return }.call }`
should return outer lambda block. However, the inner Proc can become
orphan Proc from the lambda block. This "return" escape outer-scope
like method, but this behavior was decieded as a bug.
[Bug #17105]
This patch raises LocalJumpError by checking the proc is orphan or
not from lambda blocks before escaping by "return".
Most of tests are written by Jeremy Evans
ruby#4223
ko1
added a commit
that referenced
this pull request
Apr 2, 2021
A "return" statement in a Proc in a lambda like:
`lambda{ proc{ return }.call }`
should return outer lambda block. However, the inner Proc can become
orphan Proc from the lambda block. This "return" escape outer-scope
like method, but this behavior was decieded as a bug.
[Bug #17105]
This patch raises LocalJumpError by checking the proc is orphan or
not from lambda blocks before escaping by "return".
Most of tests are written by Jeremy Evans
#4223
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.
Previously, return in a proc inside a lambda inside a method could
return to two separate places. If the return occurred while still
inside the lambda, it returned to the lambda. If the return occured
while outside the lambda, it returned to the method.
Fix this by checking the parent iseqs of the proc for a lambda proc,
and recording the iseq. When processing the callstack looking for
the return target, if you don't find a lambda proc or you find a
different lambda proc that the expected lambda proc, it means the
lambda proc has already returned, and therefore the proc return
should raise a LocalJumpError.
This currently adds a param flag on the iseq for whether the iseq is
a lambda proc, since I cannot figure out how to get the proc object
from the parent iseq to check whether it is a lambda proc.
Fixes [Bug #17105]