René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RegExp modifier groups `(?i:…)` / `(?-i:…)` can get the wrong case sensitivity (fixed in V8 15.4, please cherry-pick 4cc98031)","articleBody":"### Version\n\nv24.20.0 and v26.10.0. Also reproduced on v24.7.0, v24.9.0, v24.14.1, and on v22.14.0 with `--js-regexp-modifiers`.\n\n### Platform\n\n```text\nDarwin 24.6.0 arm64\n```\n\n### Subsystem\n\ndeps/v8 (irregexp)\n\n### What steps will reproduce the bug?\n\nSave as `modifier-case.js` and run `node modifier-case.js`. No dependencies; it also runs under d8.\n\n```js\nconst log = typeof print === \"function\" ? print : console.log;\nconst first = (source, flags, input) => new RegExp(source, flags).exec(input)?.[0] ?? null;\nconst show = (label, got, want) => log(`${got === want ? \"ok  \" : \"FAIL\"} ${label}: got ${JSON.stringify(got)}, expected ${JSON.stringify(want)}`);\n\n// 1. Fresh process, short pattern. The failing atom count depends on the V8 version.\nfor (const n of [24, 49]) {\n  const x = \"x?\".repeat(n);\n  show(`${n} x? then (?i:a?) on \"A\"`, first(x + \"(?i:a?)\", \"\", \"A\"), \"A\");\n  show(`${n} x? then (?-i:a?) with /i on \"A\"`, first(x + \"(?-i:a?)\", \"i\", \"A\"), \"\");\n}\n\n// 2. Any pattern whose source is longer than 20,480 characters.\nshow(`x?(?i:a?) padded to 20,481 chars on \"A\"`, first(\"x?(?i:a?)\" + \"(?:)\".repeat(5118), \"\", \"A\"), \"A\");\n\n// 3. A long-running process: once enough regex code has been generated,\n//    a modifier pattern compiled for the first time is wrong from then on.\nshow(`/x?(?i:a?)/ before the workload`, first(\"x?(?i:a?)(?:q{0,0})\", \"\", \"A\"), \"A\");\nconst filler = Array.from({ length: 32 }, (_, i) => \"abcdefgh\"[i % 8] + \"{0,3}\").join(\"\");\nfor (let k = 0; k \u003c 2000; k++) {\n  const re = new RegExp(filler + \"z{0,\" + k + \"}\");\n  re.exec(\"ab\");\n  re.exec(\"ab\");\n}\nshow(`/x?(?i:a?)/ after 2,000 unrelated regexes`, first(\"x?(?i:a?)(?:q{0,1})\", \"\", \"A\"), \"A\");\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery time. It needs a letter inside a `(?i:…)` or `(?-i:…)` group, plus one of three conditions:\n\n- a certain number of preceding optional atoms: 49–51, 102–104 … on V8 13.6, and 24–26, 52–54 … on V8 14.6;\n- a source longer than 20,480 characters;\n- a process that has already generated enough regex code.\n\nThe third makes it a practical problem. In a long-running server or test run, any modifier pattern first compiled after that point matches wrongly for the rest of the process, while the same pattern is correct in a fresh process.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nEvery line prints `ok`, as it does on d8 15.6.62. Per the [RegExp modifiers](https://github.com/tc39/proposal-regexp-modifiers) semantics (ES2025), `(?i:a?)` matches `\"A\"`, and `(?-i:a?)` inside `/…/i` does not.\n\n### What do you see instead?\n\nv24.20.0 (V8 13.6.233.17-node.53):\n\n```text\nok   24 x? then (?i:a?) on \"A\": got \"A\", expected \"A\"\nok   24 x? then (?-i:a?) with /i on \"A\": got \"\", expected \"\"\nFAIL 49 x? then (?i:a?) on \"A\": got \"\", expected \"A\"\nFAIL 49 x? then (?-i:a?) with /i on \"A\": got \"A\", expected \"\"\nFAIL x?(?i:a?) padded to 20,481 chars on \"A\": got \"\", expected \"A\"\nok   /x?(?i:a?)/ before the workload: got \"A\", expected \"A\"\nFAIL /x?(?i:a?)/ after 2,000 unrelated regexes: got \"\", expected \"A\"\n```\n\nv26.10.0 (V8 14.6.202.34-node.34):\n\n```text\nFAIL 24 x? then (?i:a?) on \"A\": got \"\", expected \"A\"\nFAIL 24 x? then (?-i:a?) with /i on \"A\": got \"A\", expected \"\"\nok   49 x? then (?i:a?) on \"A\": got \"A\", expected \"A\"\nok   49 x? then (?-i:a?) with /i on \"A\": got \"\", expected \"\"\nFAIL x?(?i:a?) padded to 20,481 chars on \"A\": got \"\", expected \"A\"\nok   /x?(?i:a?)/ before the workload: got \"A\", expected \"A\"\nFAIL /x?(?i:a?)/ after 2,000 unrelated regexes: got \"\", expected \"A\"\n```\n\nd8 15.6.62 (via jsvu): all seven lines `ok`.\n\n### Additional information\n\n\n**Upstream fix.** V8 [4cc98031](https://chromium.googlesource.com/v8/v8/+/4cc980311389bef473644f1ea7833171f128ac57) ([CL 8260876](https://chromium-review.googlesource.com/c/v8/v8/+/8260876), \"[regexp] Store flags on RegExpNode and remove ActionNode::MODIFY_FLAGS\", 2026-08-28) landed during V8 15.4 development. Its message describes this mechanism: the old design stored modifier flags as mutable state on the compiler, and \"out-of-order emission via worklists\" let that state leak across branches. The three conditions above all force that kind of emission.\n\nI haven't bisected to that exact commit. What I have verified is that V8 15.2 (Chromium 152) fails and d8 15.6.62 passes. The CL is a redesign across `src/regexp/` (10 files, including tests), so it may not apply cleanly to V8 13.6 or 14.6. It builds on the earlier, narrower [d315af3d](https://chromium.googlesource.com/v8/v8/+/d315af3d83cfe3bc1709f5b140db393db42790b3) ([CL 8257209](https://chromium-review.googlesource.com/c/v8/v8/+/8257209), \"[regexp] Reset compiler flags between word boundary branches\"), which a backport may also need.\n\n**Related.** Chromium issue [560182133](https://issues.chromium.org/issues/560182133) reports the long-running case with `/(?i:(a)|(b))\\2/d` on `\"BB\"` against Node v26.5.1. It was closed as obsolete on the assumption that V8 main was already fixed. That pattern also returns `null` on v24.20.0 and v26.10.0 after the 2,000-regex workload above, and for a source over 20,480 characters.\n\n**Workarounds.** Both of these are correct on the affected versions:\n- put `i` on the whole pattern rather than using a modifier group;\n- spell the letter as a character class, such as `[aA]` or `(?i:[a])`.\n\n**How it was found.** Differential fuzzing of [regex-partial-match](https://github.com/TomStrepsil/regex-partial-match), which uses the running V8 as its oracle. The results drifted part way through long runs.\n\n**Request.** Please cherry-pick 4cc98031 (with d315af3d if needed) into v24.x and v26.x. v22.x is affected too, but only with `--js-regexp-modifiers`.","author":{"url":"https://github.com/TomStrepsil","@type":"Person","name":"TomStrepsil"},"datePublished":"2026-09-25T10:11:33Z","url":"https://github.com/nodejs/node/issues/66277"}