Prevent loop exits from unwinding the context/scope stacks beyond a call_sv for smartmatch subs and class constructors #23204
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.
smartmatch: fail to find the loop instead of crashing
dopoptoloop() or dopoptolabel() would find a loop outside the sub called from call_sv() and rewind the context and save stack to outside the context set up by call_sv(), crashes and panics ensure.
Switching stacks here also starts a new context stack, so the outer loop isn't found and we don't crash.
Most other callers to call_sv() (or call_method() etc) do the same.
I'm not entirely sure about passing flags = 1 to push_stackinfo(), this matches pp_sort, but not other callers.
Fixes #16608
class.c, injected_constructor: prevent loop exits exiting
Using last, next etc would pop the context stack to above the call_sv(), generally resulting in a crash or assertion failure.
The search the context to pop to stops at the top of the current context stack, and PUSHSTACKi() switches to a new stack, preventing the search from finding any loop outside the call_sv()
Similar to #16608
Also fixes a missing -DDEBUGGING string for PERLSI_REGCOMP