Its ugly, its slow (bug 560358), its a potential information leak that needs special wrapper treatment, and its non-standard. Time to nuke it from orbit.
This will eliminate cx->regExpStatics and all the cruft associated with it. It will also greatly streamline and simplify the match path of regexps.
Flat string matching is used for str_search, str_match, and str_replace to avoid costly regexp paths (also StringMatch is getting pretty fast (bug 558270)). I wimped out on doing flat matching for regexps that don't contain meta-chars precisely because of all the RegExp static field gunk required to not break it. With them gone, it would be fairly easy to do.
For the record: http://mxr.mozilla.org/mozilla-central/search?string=RegExp.%24&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central
I wish Google had used its wealth to pay for these sites and programs to be rewritten, but they stealthed v8 and missed that chance.
We are not going to break the web this much, much as I would love to nuke the RegExpStatics from orbit.
Study the affected JS code, come up with a better plan that keeps compatibility.
*** Bug 665372 has been marked as a duplicate of this bug. ***
*** Bug 437101 has been marked as a duplicate of this bug. ***
I think this is a WONTFIX -- we can't change this without breaking the web, unless some ES opt-in de jure says that these no longer exist.
Any page on the Web that uses RegExp.$1...$9 is already skating on thin ice, as discussed in bug 437101 and bug 320811, because extensions may modify the values before they're used. (Unless bug 571355 addresses that problem; that bug is way beyond me.)
Is there some mechanism that could be used to warn developers of the dangers of using RegExp.$1...$9, perhaps when they're running under a debugger?
Noted that $1...$9 are deprecated and should not be used (and enhanced the warnings against them where already noted):
Could not find anywhere else that mentions this syntax; if you do, please let me know.
The deprecated features page looks fine.
(In reply to jsp from comment #9)
> The "Specifying a string as a parameter" section of
> replace says $n and $nn are non-standard and deprecated and should not be
> used. This is wrong; they're (currently) documented on page 147 of
> They are replacement patterns, distinct from the RegExp.$n global properties
> despite the similarity.
> The deprecated features page looks fine.
Fixed; sorry about that!