1306461 - Normalise and partially disable RegExp legacy features

Status: NEW

(Core :: JavaScript: Standard Library, task, P3)

Description

[Claude Pache]

This bug is about implementing the following ES proposal
https://github.com/tc39/proposal-regexp-legacy-features

Here is the summary of the needed changes. For some of those, there is a low risk of breaking.

Normalisation
-------------
1. RegExp statics (RegExp.$1, etc.) must be configurable and non-enumerable (note: already implemented by Chrome).


Partially disabling RegExp#compile
----------------------------------
2. disable `RegExp.prototype.compile()` for cross-realm calls:
    `RegExp.prototype.compile.call(otherRealm_regexp)` must throw.

3. disable `RegExp.prototype.compile()` on instances of proper subclasses of RegExp:
    `var rx = new (class extends RegExp {})(''); rx.complile('x');` must throw.


Partially disabling RegExp statics
----------------------------------
4. disable RegExp statics after cross-realm matches:
    `RegExp.prototype.exec.call(otherRealm_regexp, '')` updates neither `RegExp.$1` nor `otherRealm_RegExp.$1`.

5. prevent RegExp statics to be accessed from any other object than RegExp:
    `Object.create(RegExp).$1` must throw.

6. disable RegExp statics for matches with instances of proper subclasses of RegExp:
    `var rx = new (class extends RegExp {})(''); rx.exec(''); RegExp.$1` must throw.

Comment 1

[Tooru Fujisawa [:arai]]

about updating RegExp static properties after RegExp#exec, here's the difference between implementations:

code:
  "abc".replace(/(.)/g, function() {
    console.log(RegExp.$1);
    return "";
  });

result:
  Firefox and Safari
    a
    b
    c

  Chrome
    c
    c
    c

this is because of that we're doing match and function call in the same loop, if that optimization is not observable (there's no modification to RegExp prototype and instance, see bug 1264264), to avoid creating a list of match result.

so, if RegExp static properties are added to the spec, the condition about optimizability won't be met in most case (since it's hard to check if RegExp static properties are not accessed inside the function).
I'll check how much performance regression could happen if we split the loop into 2, shortly.

Comment 2

[Tooru Fujisawa [:arai]]

Attachment: Comparison of String#replace between single loop and 2 loops

here's the comparison between the original m-c (before) and modified one that does match and function call separately (after),
with the code that replaces variable-length string.

so, it takes up to x1.7 time with the testcase, when the string gets longer and there are many matched objects.
of course it depends on the length of the list, so if the replace doesn't match so many places, there's almost no difference.

Comment 3

[Mark S. Miller]

> it takes up to x1.7 time with the testcase

This is an opportunity! If you add the optimization so that things are faster once the RegExp statics are deleted, and advertise the fact, it will encourage people to delete the RegExp statics as they should.