Skip to content

fix: resolve backslash-escaped characters in .regexp string literals - #11

Merged
Mearman merged 3 commits into
mainfrom
fix/regexp-double-escape
Sep 11, 2026
Merged

fix: resolve backslash-escaped characters in .regexp string literals#11
Mearman merged 3 commits into
mainfrom
fix/regexp-double-escape

Conversation

@Mearman

@Mearman Mearman commented Sep 11, 2026

Copy link
Copy Markdown
Member

The vendored parser's readString() sliced a text-string literal's raw source between its two quotes with no RFC 8610 SESC escape processing at all, so a backslash written to escape another character (a quote, or itself) stayed in the token's Literal verbatim instead of being consumed. A .regexp rule needing an escaped backslash (\\., \\+) therefore parsed with an extra literal backslash still attached, which the emitter then re-embedded into a generated new RegExp(...) call, double-escaping it and silently changing what the pattern matches.

Found generating wire-mesh's new dm-room-path rule ([0-9a-f]{64}\\+[0-9a-f]{64}) — confirmed the same bug already affects the already-shipped namespacedDomainIdSchema too, since namespaced-domain-id's own pattern has the identical escaped-dot shape.

Fixed upstream first per this project's own foundation decision (docs/0001-foundation.md): webdriverio/cddl#91 / webdriverio/cddl#92, cherry-picked into the vendored fork here in the meantime.

Test plan

  • pnpm build && pnpm test && pnpm lint && pnpm typecheck — all green
  • New regression test round-trips both the DM-room-path shape and the real namespaced-domain-id rule through parse → emitModule → generated schema → safeParse

Cherry-picked from Mearman/cddl's fix/string-literal-escape-sequences
(tracking webdriverio/cddl#91/#92): readString() sliced a text-string
literal's raw source between its two quotes with no RFC 8610 SESC
escape processing at all, so a backslash written to escape another
character (a quote, or itself) stayed in the token's Literal verbatim.
A .regexp rule needing an escaped backslash therefore parsed with an
extra literal backslash still attached, which the emitter then
re-embedded into a generated RegExp source string, double-escaping it
and silently changing what the pattern matches.
…itted RegExp

Pins two cases through the real parse -> emitModule -> generated-schema
pipeline: a synthetic DM-room-path-style rule pairing two hex components
with an escaped literal plus, and wire-mesh's real namespaced-domain-id
rule, which has carried the double-escaping bug since before this
project existed.
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
🔒 Security Review 🔄 Running since 2026-09-11T14:20:17.477666Z dd4962b PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@Mearman
Mearman merged commit 0d79903 into main Sep 11, 2026
2 checks passed
@Mearman
Mearman deleted the fix/regexp-double-escape branch September 11, 2026 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant