In general, the STL cannot avoid all stack overflows. (We don't know how much stack has been consumed when the user calls us, so thinking any thoughts might be too much.) However, <regex> tries to throw exceptions instead of stack overflowing due to excessive recursion. We've had a long-standing struggle with exactly where to set this threshold during matching; right now our threshold detects most potential overflows before they happen, but not all.

However, we don't do anything during regex construction. It turns out that requesting an excessive number of capture groups can easily trigger a stack overflow. We even had commented-out legacy code, indicating that our predecessors thought about this scenario somewhat. This PR adds a hardcoded limit arbitrarily set at 1000, which is more than generous enough for realistic code, yet comfortably far away from where I begin to observe stack overflows.

Alternatively, we could have more comprehensive logic to track the number of nested function calls during regex construction (which I believe would be entirely ABI-safe), but I'd like to go with this targeted change for now.