560440 - Remove deprecated static fields of RegExp.prototype

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Deprecated_Features#RegExp_Methods

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.

Comment 1

[Luke Wagner [:luke]]

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.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

For the record: http://mxr.mozilla.org/mozilla-central/search?string=RegExp.%24&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

Comment 3

[Brendan Eich [:brendan]]

Also:

http://www.google.com/codesearch?as_q=RegExp\.\%24&btnG=Search+Code&hl=en&as_lang=javascript&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

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.

/be

Comment 6

[Chris Leary [:cdleary] (not checking bugmail)]

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.

Comment 7

[jsp]

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?

Comment 8

[Eric Shepherd [:sheppy]]

Noted that $1...$9 are deprecated and should not be used (and enhanced the warnings against them where already noted):

https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/replace
https://developer.mozilla.org/en/JavaScript/Reference/Deprecated_Features#RegExp_Properties

Could not find anywhere else that mentions this syntax; if you do, please let me know.

Comment 9

[jsp]

The "Specifying a string as a parameter" section of https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/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 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf. They are replacement patterns, distinct from the RegExp.$n global properties despite the similarity.

The deprecated features page looks fine.

Comment 10

[Eric Shepherd [:sheppy]]

(In reply to jsp from comment #9)
> The "Specifying a string as a parameter" section of
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/
> 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
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf.
> They are replacement patterns, distinct from the RegExp.$n global properties
> despite the similarity.
> 
> The deprecated features page looks fine.

Fixed; sorry about that!