Test case: "ab".replace(/a/, "$<c>$<d>") Expected: "$<c>$<d>b" Actual: "$<$<d>b" ECMA262: https://tc39.es/ecma262/#sec-getsubstitution (step 11) Test262: https://test262.report/browse/built-ins/RegExp/named-groups/string-replace-nocaptures.js
Created attachment 386812 [details] Patch
Comment on attachment 386812 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=386812&action=review Wow, what an interesting bug. r=me, but a couple of questions. > Source/JavaScriptCore/runtime/StringPrototype.cpp:-226 > - result.append(replacement.substring(i, 2)); > - offset = i + 2; > - advance = 1; So was this the correct behavior prior to named capture groups? Or is this too associated with https://github.com/tc39/proposal-regexp-named-groups/issues/29? > Source/JavaScriptCore/runtime/StringPrototype.cpp:-232 > - // FIXME: https://bugs.webkit.org/show_bug.cgi?id=176434 We should also close the referenced bug, right?
(In reply to Ross Kirsling from comment #2) > So was this the correct behavior prior to named capture groups? Or is this > too associated with > https://github.com/tc39/proposal-regexp-named-groups/issues/29? No, I believe it wasn't. For backwards compatibility, named capture groups leave "$<..>" as-is for a RegExp w/o named groups. This patch isn't associated with https://github.com/tc39/proposal-regexp-named-groups/issues/29: I've only removed FIXMEs to avoid submitting another patch. > We should also close the referenced bug, right? I've just closed https://bugs.webkit.org/show_bug.cgi?id=176434, thank you.
The commit-queue encountered the following flaky tests while processing attachment 386812 [details]: transitions/default-timing-function.html bug 138901 (authors: dino@apple.com and graouts@apple.com) The commit-queue is continuing to process your patch.
Comment on attachment 386812 [details] Patch Clearing flags on attachment: 386812 Committed r254088: <https://trac.webkit.org/changeset/254088>
All reviewed patches have been landed. Closing bug.
<rdar://problem/58355159>
*** Bug 213023 has been marked as a duplicate of this bug. ***