Close PR - Issue #110450 does not reproduce in current codebase

[Copilot]

Closes #110450

Investigation Summary

After investigation, the issue reported in #110450 does not reproduce with the current codebase. All test patterns from the issue work correctly without throwing ArgumentOutOfRangeException.

Root Cause Analysis

The original hypothesis was that MatchIndex and MatchLength could be called with zero matchcount, causing negative array indices. However, investigation revealed that:

1. Both the interpreter and compiled regex engines check IsMatched before calling TransferCapture
2. IsMatched verifies matchcount[cap] > 0 before any array access
3. This existing guard prevents the hypothesized issue from occurring

Testing

Verified all patterns from the issue:

var pattern = @"(?'time'){2}(?=((?'-time')|(?'x')){3}(((?'count')(((?'-count')|((?'-x')))(?'count')){2}|0)(?((?'-count'){3})|((?'-count')|){3})(?!(?'-x')))|){2}";
var regex = new Regex(pattern, RegexOptions.Compiled);
var matches = regex.Matches("25525511135");  // Works correctly, no exception

Conclusion

The issue appears to have been already fixed in the codebase or was not consistently reproducible. No changes are needed. This PR can be closed.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Regex throw an exception Specified argument was out of the range of valid values. in compiled mode</issue_title>
<issue_description>### Description

I'm trying to simplify the pattern.
And there are also some issues with this pattern in source generation.

Reproduction Steps

using System;
using System.Text.RegularExpressions;

//The pattern when this bug was first discovered
string pattern = @"^(?=\d{3,12})(?'time'){12}(((?=((?'-time')(?'y')|(?'x')){12}((?'time-y')|){12}((^[1-9](?'count')(((?'-count')|((?'-x')|(?'-x1'))\d|(?'x1'\d))(?'count')){2}|0)(?=\d{3,9}$)(?((?'-count'){3})(?<!^\d([6-9]\d|5[6-9]))|((?'-count')|){3})([1-9](?'count')(((?'-count')|((?'-x')|(?'-x2'))\d|(?'x2'\d))(?'count')){2}|0)(?=\d{2,6}$)(?((?'-count'){3})(?<![3-9]\d\d|\d([6-9]\d|5[6-9]))|((?'-count')|){3})([1-9](?'count')(((?'-count')|((?'-x')|(?'-x3'))\d|(?'x3'\d))(?'count')){2}|0)(?=\d{1,3}$)(?((?'-count'){3})(?<![3-9]\d\d|\d([6-9]\d|5[6-9]))|((?'-count')|){3})(?(\d\d\d$)(?![3-9]\d\d|\d([6-9]\d|5[6-9])))([1-9]\d*|0)$(?!(?'-x'))((?'-x')|){12}))|)(?'-time')){12}";
//this pattern would work normally in compiled when input = "101023"
pattern = @"(?'time'){2}(?=((?'-time')|(?'x')){3}((^[1-9](?'count')(((?'-count')|((?'-x'))\d)(?'count')){2}|0)(?((?'-count'){3})|((?'-count')|){3})([1-9](?'count')(((?'-count')|((?'-x'))\d)(?'count')){2}|0)(?!(?'-x')))){2}";
//this pattern is also  bad in compiled mode, but it does seem to cause Group#2 to permanently fail to match in source generated
pattern = @"(?'time'){2}(?=((?'-time')|(?'x')){3}(((?'count')(((?'-count')|((?'-x')))(?'count')){2}|0)(?((?'-count'){3})|((?'-count')|){3})(?!(?'-x')))){2}";
//This pattern seems to have issues in both compiled mode and source-generated code. 
pattern = @"(?'time'){2}(?=((?'-time')|(?'x')){3}(((?'count')(((?'-count')|((?'-x')))(?'count')){2}|0)(?((?'-count'){3})|((?'-count')|){3})(?!(?'-x')))|){2}";
string input = "25525511135";
Regex regex = new Regex(pattern, RegexOptions.Compiled);
var mhes = regex.Matches(input);
try
{
	Console.WriteLine(mhes.Count);
}catch(Exception e)
{
	Console.WriteLine(e.Message);
}
try
{
	Console.WriteLine("Group#2's captures count : "+Regex.Match(input, pattern).Groups[2].Captures.Count);
}catch(Exception e)
{
	Console.WriteLine(e.Message);
}

Expected behavior

12
Group#2's captures count : 1

Actual behavior

Specified argument was out of the range of valid values.
Group#2's captures count : 1

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #119444

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[stephentoub]

@copilot, these same helpers are also used by the interpreter, which does not have the same problem. Are you sure the problem is in the helpers? Why doesn't the interpreter hit the issue then?

[Copilot]

@copilot, these same helpers are also used by the interpreter, which does not have the same problem. Are you sure the problem is in the helpers? Why doesn't the interpreter hit the issue then?

You're absolutely right. Both the interpreter and compiled code check IsMatched before calling TransferCapture, which ensures MatchIndex and MatchLength are never called with a zero matchcount from that path.

I've verified that the patterns from the issue no longer reproduce the exception in the current codebase, suggesting the issue may have been fixed elsewhere or doesn't reproduce consistently. The guards I added are defensive but unnecessary given the existing IsMatched checks.

Should I revert these changes since the helpers already have implicit protection through the IsMatched guard at the call sites?