[regexp] Experimental support for regexp named captures

src/js/regexp.js

Index: src/js/regexp.js
diff --git a/src/js/regexp.js b/src/js/regexp.js
index ef6a4aed053b3d15f23056a64c4540112be08337..a881c490006b8e961c8c8a1125952231f986e409 100644
--- a/src/js/regexp.js
+++ b/src/js/regexp.js
@@ -141,7 +141,7 @@ function DoRegExpExec(regexp, string, index) {
 // This is kind of performance sensitive, so we want to avoid unnecessary
 // type checks on inputs. But we also don't want to inline it several times
 // manually, so we use a macro :-)
-macro RETURN_NEW_RESULT_FROM_MATCH_INFO(MATCHINFO, STRING)
+macro RETURN_NEW_RESULT_FROM_MATCH_INFO(MATCHINFO, STRING, JSREGEXP)
   var numResults = NUMBER_OF_CAPTURES(MATCHINFO) >> 1;
   var start = MATCHINFO[CAPTURE0];
   var end = MATCHINFO[CAPTURE1];
@@ -160,6 +160,9 @@ macro RETURN_NEW_RESULT_FROM_MATCH_INFO(MATCHINFO, STRING)
     }
     j++;
   }
+  // For each named capture 'a', create a property result.a containing the
+  // corresponding captured string.
+  %RegExpResultAttachNamedCaptures(result, JSREGEXP);

[Yang, 2016/06/13 10:54:52]

This is going to be fairly expensive, and affects every regexp, even ones that
has no named captures. I'm pretty sure this affects the Octane benchmark score,
especially the regexp benchmark.

We need a more efficient way to check whether the regexp has named captures at
all, and only go into runtime if we do.

I can think of a few alternatives, in descending order of what I think is best.
- We implement this whole macro as turbofan stub. That's going to be fairly
involved.
- We check for kIrregexpCaptureNameMapIndex in regexp data in the generated code
of %_RegExpConstructResult and call into %RegExpResultAttachNamedCaptures from
there if necessary.
- We use a hidden property using a private symbol as key to store whether we
have named captures on the regexp. Loading from a property should be a lot
cheaper thanks to inline caching and optimizations in optimized code. We could
even store the fixed array for the property names there.
- We change the RegExpExecStub to encode another element in MATCHINFO to
indicate whether there is a named capture.
- We can add another bit to regexp flags so that we can check upfront using
%_RegExpFlags (see macros.py, REGEXP_GLOBAL). This is somewhat hacky, but easier
to implement.

How about we first land the rest of the CL without storing named properties to
the result object?

[jgruber, 2016/06/13 13:09:59]

I'm tending towards this as an initial approach. This would mean passing the
JSRegExp into %_RegExpConstructResult for accessing the capture map though.
Sounds good.

   return result;
 endmacro
 
@@ -170,7 +173,7 @@ function RegExpExecNoTests(regexp, string, start) {
   if (matchInfo !== null) {
     // ES6 21.2.5.2.2 step 18.
     if (REGEXP_STICKY(regexp)) regexp.lastIndex = matchInfo[CAPTURE1];
-    RETURN_NEW_RESULT_FROM_MATCH_INFO(matchInfo, string);
+    RETURN_NEW_RESULT_FROM_MATCH_INFO(matchInfo, string, regexp);
   }
   regexp.lastIndex = 0;
   return null;
@@ -219,7 +222,7 @@ function RegExpSubclassExecJS(string) {
   if (updateLastIndex) {
     this.lastIndex = RegExpLastMatchInfo[CAPTURE1];
   }
-  RETURN_NEW_RESULT_FROM_MATCH_INFO(matchIndices, string);
+  RETURN_NEW_RESULT_FROM_MATCH_INFO(matchIndices, string, this);
 }
 %FunctionRemovePrototype(RegExpSubclassExecJS);
 
@@ -260,7 +263,7 @@ function RegExpExecJS(string) {
   if (updateLastIndex) {
     this.lastIndex = RegExpLastMatchInfo[CAPTURE1];
   }
-  RETURN_NEW_RESULT_FROM_MATCH_INFO(matchIndices, string);
+  RETURN_NEW_RESULT_FROM_MATCH_INFO(matchIndices, string, this);
 }
 
 
@@ -1214,7 +1217,7 @@ var InternalRegExpMatchInfo = new InternalPackedArray(2, "", UNDEFINED, 0, 0);
 function InternalRegExpMatch(regexp, subject) {
   var matchInfo = %_RegExpExec(regexp, subject, 0, InternalRegExpMatchInfo);
   if (!IS_NULL(matchInfo)) {
-    RETURN_NEW_RESULT_FROM_MATCH_INFO(matchInfo, subject);
+    RETURN_NEW_RESULT_FROM_MATCH_INFO(matchInfo, subject, regexp);
   }
   return null;
 }