Fix handling of capture groups inside of negative lookarounds#97463
Fix handling of capture groups inside of negative lookarounds#97463stephentoub merged 1 commit intodotnet:mainfrom
Conversation
The Regex compiler and source generator weren't uncapturing captures inside of a negative lookaround. That then leads both to subsequent backreferences matching when they shouldn't.
ghost
added
the
|
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions Issue DetailsThe Regex compiler and source generator weren't uncapturing captures inside of a negative lookaround. That then leads both to subsequent backreferences matching when they shouldn't. Fixes #97455
|
danmoseley
left a comment
danmoseley
left a comment
There was a problem hiding this comment.
Seems reasonable - I assume these tests still run and pass on .NET Framework..?
|
No analogous issue with positive lookarounds? |
Yes |
No, those captures are supposed to persist (and do). |
| yield return (@"(?=(\d))4\1", "43", RegexOptions.None, 0, 2, false, ""); | ||
|
|
||
| // Zero-width negative lookbehind assertion: Actual - "(\\w){6}(?<!XXX)def" | ||
| yield return (@"(\w){6}(?<!XXX)def", "XXXabcdef", RegexOptions.None, 0, 9, true, "XXXabcdef"); |
There was a problem hiding this comment.
@stephentoub are we covered for testing analogous case for negative lookbehind? eg., (?<!(b)a)\1 shouldn't match bb
There was a problem hiding this comment.
Probably not from a test perspective; the src fix covers both directions. Feel free to submit a pr.
|
does https://regex101.com/r/jsQ12z/1 mean that regex101 is still using 6.0? |
More likely is it's using the interpreter |
2 participants
The Regex compiler and source generator weren't uncapturing captures inside of a negative lookaround. That then leads both to subsequent backreferences matching when they shouldn't.
Fixes #97455