(*SKIP)(*F) within a (?(DEFINE)) does not skip position

[PhilipHazel]

This is #2725 from the old Bugzilla.

PH: It is documented at the end of pcre2pattern.3 that COMMIT, PRUNE, and SKIP are confined within a subroutine call in PCRE2, and just cause it to fail to match. I cannot remember why this is so. Subroutine calls appeared in PCRE before they did in Perl, so it might be that this behaviour dates from then, but it might also be because Perl has exhibited some conflicting behaviour in the past.

PH: Experiments show certain inconsistencies in Perl, which documents that (*ACCEPT) stays within a subroutine call, but is not explicit about the others, though it does state that a subroutine is processed as an independent subpattern. For the moment, we are not going to change anything in PCRE, partly because though this is an easy change in the interpreter, it is a substantial upgrade for the JIT.

OnlineCop wrote: The language of pcre2pattern.3 states:

(*SKIP)

This verb, when given without a name, is like (*PRUNE), except that if the pattern is unanchored, the "bumpalong" advance is not to the next character, but to the position in the subject where (*SKIP) was encountered. (*SKIP) signifies that whatever text was matched leading up to it cannot be part of a successful match if there is a later mismatch.

(*FAIL) in a group called as a subroutine has its normal effect: it forces an immediate backtrack.
(*COMMIT), (*SKIP), and (*PRUNE) cause the subroutine match to fail when triggered by being backtracked to in a group called as a subroutine. There is then a backtrack at the outer level.

There is no mention of (*SKIP) or (*PRUNE) being unable to modify the bumpalong of the outer level.

Perl appears to modify the bumpalong before the subroutine match fails, which (like PCRE2) then causes a backtrack at the outer level.

I believe that all other verbs, including (*ACCEPT), are fine to stay as-is, and the only change here being that (*SKIP) should be able to modify the outer level's bumpalong advance.