Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2685183003:
[regexp] Sticky handling in fast slow path (Closed)
Description[regexp] Correct lastIndex behavior in RegExp.prototype[@@replace]
@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.
This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.
BUG=v8:5361
Review-Url: https://codereview.chromium.org/2685183003
Cr-Commit-Position: refs/heads/master@{#43234}
Committed: https://chromium.googlesource.com/v8/v8/+/c0fe56e63debf06b420ec34272b697c041056284
Patch Set 1 #Patch Set 2 : Fix simple string fast path #Patch Set 3 : Fix DCHECK #Patch Set 4 : Reset lastIndex on failure iff sticky #Patch Set 5 : Test expectations #Patch Set 6 : Remove unused vars #Patch Set 7 : ToUint32 and push loads to uses #Patch Set 8 : Revert "Remove custom ToUint32" #
Total comments: 2
Messages
Total messages: 40 (36 generated)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: CLs for remote refs other than refs/heads/master must contain NOTRY=true and NOPRESUBMIT=true in order for the CQ to process them
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...) v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)
The CQ bit was checked by jgruber@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== [regexp] Sticky handling in fast slow path BUG= ========== to ========== [regexp] Correct lastIndex behavior in RegExp.prototype[@@replace] @@replace has a pretty complex implementation, taking different paths for various situations (e.g.: global/nonglobal regexp, functional/string replace argument, etc.). Each of these paths must implement similar logic for calling into the RegExpBuiltinExec spec operation, and many paths get this subtly wrong. This CL fixes a couple of issues related to the way @@replace handles lastIndex: * All paths now respect lastIndex when calling into exec (some used to assume 0). * lastIndex is now advanced after a successful match for sticky regexps. * lastIndex is now only reset to 0 on failure for sticky regexps. BUG=v8:5361 ==========
Description was changed from ========== [regexp] Correct lastIndex behavior in RegExp.prototype[@@replace] @@replace has a pretty complex implementation, taking different paths for various situations (e.g.: global/nonglobal regexp, functional/string replace argument, etc.). Each of these paths must implement similar logic for calling into the RegExpBuiltinExec spec operation, and many paths get this subtly wrong. This CL fixes a couple of issues related to the way @@replace handles lastIndex: * All paths now respect lastIndex when calling into exec (some used to assume 0). * lastIndex is now advanced after a successful match for sticky regexps. * lastIndex is now only reset to 0 on failure for sticky regexps. BUG=v8:5361 ========== to ========== [regexp] Correct lastIndex behavior in RegExp.prototype[@@replace] @@replace has a pretty complex implementation, taking different paths for various situations (e.g.: global/nonglobal regexp, functional/string replace argument, etc.). Each of these paths must implement similar logic for calling into the RegExpBuiltinExec spec operation, and many paths get this subtly wrong. This CL fixes a couple of issues related to the way @@replace handles lastIndex: * All paths now respect lastIndex when calling into exec (some used to assume 0). * lastIndex is now advanced after a successful match for sticky regexps. * lastIndex is now only reset to 0 on failure for sticky regexps. BUG=v8:5361 ==========
jgruber@chromium.org changed reviewers: + littledan@chromium.org, yangguo@chromium.org
This fixes a couple of issues around lastIndex handling for sticky regexps. Please take a look. As an aside - all the different @@replace paths are pretty scary. It'd be awesome to simplify this sometime; I'd love to just rip out all slow paths but a generic one, but that's probably a pipe dream since we'd regress too much. https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... File src/builtins/builtins-regexp.cc (right): https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... src/builtins/builtins-regexp.cc:282: Node* const string_length = LoadStringLength(string); This and below are drive-by cleanups that push loads to before use sites. https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... src/builtins/builtins-regexp.cc:2372: Node* const match_indices = RegExpPrototypeExecBodyWithoutResult( Replaced RE.p.exec emulation by inlined version of the actual exec code to avoid issues around lastIndex.
On 2017/02/13 12:15:38, jgruber wrote: > This fixes a couple of issues around lastIndex handling for sticky regexps. > Please take a look. > > As an aside - all the different @@replace paths are pretty scary. It'd be > awesome to simplify this sometime; I'd love to just rip out all slow paths but a > generic one, but that's probably a pipe dream since we'd regress too much. > > https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... > File src/builtins/builtins-regexp.cc (right): > > https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... > src/builtins/builtins-regexp.cc:282: Node* const string_length = > LoadStringLength(string); > This and below are drive-by cleanups that push loads to before use sites. > > https://codereview.chromium.org/2685183003/diff/140001/src/builtins/builtins-... > src/builtins/builtins-regexp.cc:2372: Node* const match_indices = > RegExpPrototypeExecBodyWithoutResult( > Replaced RE.p.exec emulation by inlined version of the actual exec code to avoid > issues around lastIndex. lgtm.
The CQ bit was checked by jgruber@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 140001, "attempt_start_ts": 1487234964317040,
"parent_rev": "4e4a968e0eb2f86fc5bbbd9f7e5c7f98e5111732", "commit_rev":
"c0fe56e63debf06b420ec34272b697c041056284"}
Message was sent while issue was closed.
Description was changed from ========== [regexp] Correct lastIndex behavior in RegExp.prototype[@@replace] @@replace has a pretty complex implementation, taking different paths for various situations (e.g.: global/nonglobal regexp, functional/string replace argument, etc.). Each of these paths must implement similar logic for calling into the RegExpBuiltinExec spec operation, and many paths get this subtly wrong. This CL fixes a couple of issues related to the way @@replace handles lastIndex: * All paths now respect lastIndex when calling into exec (some used to assume 0). * lastIndex is now advanced after a successful match for sticky regexps. * lastIndex is now only reset to 0 on failure for sticky regexps. BUG=v8:5361 ========== to ========== [regexp] Correct lastIndex behavior in RegExp.prototype[@@replace] @@replace has a pretty complex implementation, taking different paths for various situations (e.g.: global/nonglobal regexp, functional/string replace argument, etc.). Each of these paths must implement similar logic for calling into the RegExpBuiltinExec spec operation, and many paths get this subtly wrong. This CL fixes a couple of issues related to the way @@replace handles lastIndex: * All paths now respect lastIndex when calling into exec (some used to assume 0). * lastIndex is now advanced after a successful match for sticky regexps. * lastIndex is now only reset to 0 on failure for sticky regexps. BUG=v8:5361 Review-Url: https://codereview.chromium.org/2685183003 Cr-Commit-Position: refs/heads/master@{#43234} Committed: https://chromium.googlesource.com/v8/v8/+/c0fe56e63debf06b420ec34272b697c0410... ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001) as https://chromium.googlesource.com/v8/v8/+/c0fe56e63debf06b420ec34272b697c0410... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
