PCRE2 doesn't select the no for positive lookbehind.

[swgmike]

I'm posting due to a bug in PCRE2 based on the response to a regular expression issue I poste at the following link. That owner stated he is using PCRE 10.42 See firasdib/Regex101#1957 (comment)

A summary of the issue is
I'm trying to use positive lookbehind to find an overloaded keyword such as "::if" where only the first colon : before the if is sufficient. Thus the character pattern to match is [^:]. If not found the yes group is (if) and will highlight it and if found, the no group is set to anything but in my case will be empty ().

A copy of the steps I encountered from the link above are:
Searching for the colon NOT to be present.
Case1: Scenario 1: yes case
(?(?<=[^:])(if)|(mike))) string: Is candy if or mike? Result: Highlights the if for the yes case. (works)
Case1: Scenario 2: no case
(?(?<=[^:])(if)|(mike))) string: Is candy ::if or mike? Result: Doesn't highlight mike for the no group since : is before the if (doesn't work)

Searching for the colon to be present.
Case 2: scenario 1: yes case
(?(?<=[:])(if)|(mike))) string: Is candy ::if or mike? Result: Highlight if after the two colons (works)
Case 2: scenario 2: no case
(?(?<=[:])(if)|(mike))) string: Is candy if or mike? Result: Since no colon before if, it highlights the no case "mike" (works)

Case 3: scenario 1 same as above but using names.
(?'COND'(?<=[^:])(if)|(mike))) string: Is candy :if or mike? Result: Highlights mike since colon present (works)
(?'COND'(?<=[^:])(if)|(mike))) string: Is candy if or mike? Result: Highlights mike but no colon present should highlight if (doesn't work)
Case 3: scenario 2 see above
(?"COND'(?<=[:])(if)|(mike))) string: Is candy :if or mike? Result: Highlights if after the colon present (works)
(?'COND'(?<=[:])(if)|(mike))) string: Is candy if or mike? Result: Highlights mike since no colon (works)

[zherczeg]

(?(?<=[^:])(if)|(mike))) string: Is candy ::if or mike?
Result: Doesn't highlight mike for the no group since : is before the if (doesn't work)

https://regex101.com/r/saKPjb/1
I don't get the problem. The pattern doesn't match as you mentioned. Where is the "doesn't work" part?

[swgmike]

The regular expression on the website regex101 you included states the expression doesn't match the expression.
I expected it to highlight "mike" since it is the no/false condition because the test string includes ":if" and I'm testing that it doesn't include the colon.

[swgmike]

I've removed the noncapturing group and simplified it as (?<=[^:])(if)|(mike) for this case it highlights "mike"; however, if the match is changed to {:] , the regex101 will highlight both if and mike when I expect only if to be highlighted.

Now if a named group is specified as, (?'COND'(?<=[:])(if)|(mike)), it willl highlight both if and mike and if the match is changed to [^:] it will highlight only mike. Thus, in these two cases, it will highlight both when the colon is to be matched.

If the named group switched to a non-named group, the match for [:} will highlight both the if and mike. but for [^:] nothing is highlighted and says no match found in the string to be searched.

So since regex101 website uses PCRE2, it could be info returned for their website to use is the cause, or their website has an issue. No sure which of the two right now.

[zherczeg]

/(?<=[^:])(if)|(mike)/ This is not the simplification of the original pattern, this is completely different thing. You didn't remove a non-capturing block, you removed a conditional expression. Is it possible that you accidentally used a regex syntax which you don't know? Regex101 parses the pattern, and you can check its parts.

[PhilipHazel]

Your first case is an invalid regex: (?(?<=[^:])(if)|(mike))) has too many closing parens. But ignoring the final ) it works as expected. The pattern starts with a condition (?(?<=[^:]) the condition is "not preceded by colon". If the condition is true, the pattern then goes on to match "if", If the condition is not true the pattern goes on to match "mike". In your first string, "... if ... mike..." there are lots of places where the condition is true, but only one of them is followed by "if", and that is what matches. In your second string, where there is a colon before "if", the condition is false only in that one position, and as it is not followed by "mike", the whole match fails. This is entirely correct behaviour.