A regex literal using a valid Unicode property escape such as /\p{Mark}/u fails to parse with invalid regular expression: Unsupported Unicode property: Mark. One bad regex kills the whole script: x.com's bundle.Communities.16ac38ba.js fails to parse entirely, so none of its webpack modules register, and any module that requires into it dies mid-evaluation (Cannot read properties of undefined (reading 'call')). Webpack caches the half-evaluated module, which later resurfaces as a confusing Cannot access a lexical binding before initialization ReferenceError from an export getter — observed on every x.com load.
What happens
The Starling JS parser eagerly validates every regex literal at parse time: ValidateRegExpLiteral (src/Starling.Js/Parse/JsParser.cs:1329-1342) compiles the pattern through the Starling RegExp engine and converts any syntax failure into a parse-phase error. That eager validation is spec-correct — an invalid regex literal is an early SyntaxError in ECMAScript.
The actual bug is that the Starling RegExp engine's property support is a small whitelist. RegexParser.ParsePropertyEscape (src/Starling.RegExp/RegexParser.cs:595-615, throw at 610) accepts only the names in RegexCharClass.SupportedProperties (src/Starling.RegExp/RegexCharClass.cs:103-116): Letter, Number, Decimal_Number, White_Space, Punctuation, Symbol, Uppercase_Letter, Lowercase_Letter, ID_Start, ID_Continue, and their short aliases. Mark/M and most of the spec's required properties are missing, so a perfectly valid pattern is treated as a syntax error and takes the whole file down with it.
Two more gaps in the same code:
ParsePropertyEscape ignores the property name in Name=Value form (it keeps only the value), so \p{Script=Greek} and \p{General_Category=L} are conflated.BuildPropertyRanges (RegexCharClass.cs:120+) scans code points only up to 0xFFFF, so even supported properties miss astral-plane characters.
Fix
Real fix: extend the Starling RegExp engine to the ECMAScript \p{...} surface:
- all General_Category values and aliases (
Mark/M, Mn, Mc, Me, Cf, and the rest), accepting both bare-value and General_Category=Value forms
- the spec's required binary properties (
Alphabetic, White_Space, Assigned, and so on), adding to the existing table approach
Script= / Script_Extensions= handled as their own namespace instead of being conflated with category names- property ranges built over the full code-point space, not just the BMP
.NET's System.Globalization.UnicodeCategory and CharUnicodeInfo can generate the category ranges, so most of this is table plumbing, not algorithm work.
Not a fix: moving validation from parse time to construction time. Eager parse-phase SyntaxError is what the spec requires for genuinely invalid literals. The whitelist being too small is the defect.
Context
Found during the x.com/nasa boot investigation on 2026-06-10 (branch feat/js-stack-trampoline). Verified against the real chunk with the exact message above. Same blast-radius pattern as two sibling parser issues (template-substitution comma, parenthesized in): one parse error silently kills every webpack module in a chunk and produces misleading downstream errors.
A regex literal using a valid Unicode property escape such as
/\p{Mark}/ufails to parse withinvalid regular expression: Unsupported Unicode property: Mark. One bad regex kills the whole script: x.com'sbundle.Communities.16ac38ba.jsfails to parse entirely, so none of its webpack modules register, and any module that requires into it dies mid-evaluation (Cannot read properties of undefined (reading 'call')). Webpack caches the half-evaluated module, which later resurfaces as a confusingCannot access a lexical binding before initializationReferenceError from an export getter — observed on every x.com load.What happens
The Starling JS parser eagerly validates every regex literal at parse time:
ValidateRegExpLiteral(src/Starling.Js/Parse/JsParser.cs:1329-1342) compiles the pattern through the Starling RegExp engine and converts any syntax failure into a parse-phase error. That eager validation is spec-correct — an invalid regex literal is an early SyntaxError in ECMAScript.The actual bug is that the Starling RegExp engine's property support is a small whitelist.
RegexParser.ParsePropertyEscape(src/Starling.RegExp/RegexParser.cs:595-615, throw at 610) accepts only the names inRegexCharClass.SupportedProperties(src/Starling.RegExp/RegexCharClass.cs:103-116): Letter, Number, Decimal_Number, White_Space, Punctuation, Symbol, Uppercase_Letter, Lowercase_Letter, ID_Start, ID_Continue, and their short aliases.Mark/Mand most of the spec's required properties are missing, so a perfectly valid pattern is treated as a syntax error and takes the whole file down with it.Two more gaps in the same code:
ParsePropertyEscapeignores the property name inName=Valueform (it keeps only the value), so\p{Script=Greek}and\p{General_Category=L}are conflated.BuildPropertyRanges(RegexCharClass.cs:120+) scans code points only up to0xFFFF, so even supported properties miss astral-plane characters.Fix
Real fix: extend the Starling RegExp engine to the ECMAScript
\p{...}surface:Mark/M,Mn,Mc,Me,Cf, and the rest), accepting both bare-value andGeneral_Category=ValueformsAlphabetic,White_Space,Assigned, and so on), adding to the existing table approachScript=/Script_Extensions=handled as their own namespace instead of being conflated with category names.NET's
System.Globalization.UnicodeCategoryandCharUnicodeInfocan generate the category ranges, so most of this is table plumbing, not algorithm work.Not a fix: moving validation from parse time to construction time. Eager parse-phase SyntaxError is what the spec requires for genuinely invalid literals. The whitelist being too small is the defect.
Context
Found during the x.com/nasa boot investigation on 2026-06-10 (branch
feat/js-stack-trampoline). Verified against the real chunk with the exact message above. Same blast-radius pattern as two sibling parser issues (template-substitution comma, parenthesizedin): one parse error silently kills every webpack module in a chunk and produces misleading downstream errors.