Fix beginning fixups of captures after Regex span support #66713
Conversation
The Regex span support changed the scanning infrastructure to always be based on spans. That means that when a string is passed in by the caller, internally we still operate on it as a span. That also means we can take advantage of slicing, and if the caller has specified via a beginning/length set of arguments that we should only process a substring, we can just slice to that substring. That, however, then means that all offsets computed by the scanning implementation are 0-based rather than beginning-based. The span change included a fixup for the overall match position, but not for the position of each individual capture, and that then meant that captures were providing the wrong values. We unfortunately didn't have any tests for validating groups that also involved non-0 beginnings with string inputs.
|
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions Issue DetailsThe Regex span support changed the scanning infrastructure to always be based on spans. That means that when a string is passed in by the caller, internally we still operate on it as a span. That also means we can take advantage of slicing, and if the caller has specified via a beginning/length set of arguments that we should only process a substring, we can just slice to that substring. That, however, then means that all offsets computed by the scanning implementation are 0-based rather than beginning-based. The span change included a fixup for the overall match position, but not for the position of each individual capture, and that then meant that captures were providing the wrong values. We unfortunately didn't have any tests for validating groups that also involved non-0 beginnings with string inputs. Fixes #66697
|
The Regex span support changed the scanning infrastructure to always be based on spans. That means that when a string is passed in by the caller, internally we still operate on it as a span. That also means we can take advantage of slicing, and if the caller has specified via a beginning/length set of arguments that we should only process a substring, we can just slice to that substring. That, however, then means that all offsets computed by the scanning implementation are 0-based rather than beginning-based. The span change included a fixup for the overall match position, but not for the position of each individual capture, and that then meant that captures were providing the wrong values. We unfortunately didn't have any tests for validating groups that also involved non-0 beginnings with string inputs.
ghost
locked as resolved and limited conversation to collaborators
The Regex span support changed the scanning infrastructure to always be based on spans. That means that when a string is passed in by the caller, internally we still operate on it as a span. That also means we can take advantage of slicing, and if the caller has specified via a beginning/length set of arguments that we should only process a substring, we can just slice to that substring. That, however, then means that all offsets computed by the scanning implementation are 0-based rather than beginning-based. The span change included a fixup for the overall match position, but not for the position of each individual capture, and that then meant that captures were providing the wrong values. We unfortunately didn't have any tests for validating groups that also involved non-0 beginnings with string inputs.
Fixes #66697