Repository navigation
A global scan drops the trailing empty match: "a".match(/a*/g) is ["a"], node gives ["a",""] #9430
Description
"a".match(/a*/g) // node ["a",""] perry ["a"]
"ab".match(/b*/g) // node ["","b",""] perry ["","b"]
"a".replace(/a*/g, "<>") // node "<><>" perry "<>"Same for matchAll. No flags beyond g are involved.
When the previous match ends at the end of the haystack, the scan stops instead of taking the final zero-width match that ECMAScript's RegExpExec loop produces there.
This is what makes test_parity_regex_replace_fn_lookahead diverge from node today, and it is why the /gms rows for terminator-final subjects had to be excluded from #9427's #9408 fixture — with a comment in the file pointing here.
Activity
fix(runtime): a global scan keeps the empty match at a match's end (P…
fix(runtime): exec/test keep the whole subject, and a global scan kee…
proggeramlug commentedon Sep 2, 2026
Fixed by PR #9437: the shared
global_scan.rsloop implements ECMAScript's keep-empty-match-then-advance rule for the two Rust-iterator lanes (regressalready had it and is the pinned control). Wider than filed: the rule fires at EVERY match-end position, not just the trailing one.test_gap_9430_global_scan_trailing_empty.ts(64 diff lines before). Verified on main0a1c137d90with a fresh build: fixture byte-identical tonode --experimental-strip-types(stdout, stderr, and exit code).The third independent root cause found nearby —
spliton the fancy-regex lane never running@@split, widened by #9427 — is #9438.