[proggeramlug]

Summary

A literal unescaped [ inside a [...] character class is valid in JS (a plain [), but both Rust engines — the regex crate and the fancy-regex fallback — reject it as "invalid character class". js_regex_to_rust passed it through unchanged.

Why this mattered (and why it's NOT an engine limitation)

Perry already has a fancy-regex fallback that supports backreferences, lookahead, and lookbehind. But the same translated pattern string feeds both engines: when the regex crate bails on an advanced construct and the code falls back to fancy-regex, an unescaped [ makes fancy-regex reject the pattern too — even though it fully supports the rest.

get-intrinsic's path-split pattern is exactly this shape:

[^%.[\]]+|\[(?:(-?\d+...)|(["'])((?:(?!\2)[^\\]|\\.)*?)\2)\]|(?=(?:\.|\[\])...)

It has backreferences (\2) and lookahead ((?=...)) — both fancy-regex-compatible — but the leading [^%.[\]] class with a literal [ made it throw SyntaxError: Invalid regular expression: …: invalid pattern at init while compiling Express (#3527). Escaping the [ → the whole pattern compiles under fancy-regex and matches correctly.

Fix

Track character-class depth in js_regex_to_rust and escape a literal [ found inside a class to \[ (semantics-preserving in both engines). Also gate the (?<name>...) named-group rewrite on being outside a class, where ( is literal.

Verification

• The get-intrinsic pattern now compiles under fancy-regex and matches (%Array.prototype.push% → Array); the Express tree advances past it.
• Unit test js_regex_to_rust_escapes_literal_bracket_in_class covers the escaping, the named-group interaction, and end-to-end compilation of the full pattern. cargo fmt --check clean.

Part of the #3527 chain (prior: #3537/#3543/#3546, #3551, #3733, #3751, #3764, #3771, #3776). No version bump / changelog — folded in at merge per the worktree-PR convention.