Simply handling error reporting in regular expression patterns using the current code demands a full-blown TokenStream, but this becomes somewhat problematic as single-byte parsing happens -- because it forces extra template-duplicating for some RegExpParser code, above and beyond just a single/double-byte distinction. Let's create error information based on the actual pattern text to evade this duplication.

Comment on attachment 8862133 [details] [diff] [review] Patch Review of attachment 8862133 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/irregexp/RegExpParser.cpp @@ +287,5 @@ > + > + // The line of context must be null-terminated, and StringBuffer doesn't > + // make that happen unless we force it to. > + if (!windowBuf.append('\0')) > + return; sounds like it's better having dedicated method for appending null-terminator.

Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/2c965dfef6c8 Make RegExpParser::ReportError give better error messages that point directly at the offending character within the pattern, rather than just at the start of the RegExp literal. r=arai

Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/21447217ddbd Followup hazard fix. (Maybe the varargs threw off the hazard analysis, where the suppress-GC operation occurred *inside* a varargs function? *shrug*) r=bustage

Backed out because the follow-up didn't fix the hazard: https://hg.mozilla.org/integration/mozilla-inbound/rev/5022472053033960fd63f266f1c100c02df8de7a https://hg.mozilla.org/integration/mozilla-inbound/rev/71f91a6c6e5572b90cc3be567fe0be3e509f0688 Follow-up push with hazard: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=21447217ddbd0350120bb26de3d2906afd9970e8&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=95383446&repo=mozilla-inbound

The hazards continued, so the two changesets with no bug also got backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/dcfe22d0425811dc1683d8a625bc9c471c06985c https://hg.mozilla.org/integration/mozilla-inbound/rev/ab09f197b2019a58c507c15b68d2a9c5eb27665e Push with hazard: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=53672c48392add5e976edd062af5abfa45f48818&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=95435649&repo=mozilla-inbound

Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/bfd50ac2e7bd Make RegExpParser::ReportError give better error messages that point directly at the offending character within the pattern, rather than just at the start of the RegExp literal. r=arai

In case anyone is ever curious: there was nothing wrong with this patch. Or with the followup -- which I folded into the relanding because pushing all the varargs stuff as far down as possible, *inside* GC suppression shenanignas, seemed safest for analyzers. The real problem was with the no-bug changesets mentioned in comment 6, which hit a bug in the GC analysis toolchain. Apparently GCC gives non-uniquified names to anonymous types, an anonymous type in the busted code was given a name ".215", and because of how I changed inclusions, an anonymous type in a totally different compilation unit, that *did* contain a GC type, got assigned the same ".215" name. Analysis sees a transitive "GC type" used across a GCing operation, hilarity ensues. At sfink's instructions I worked around this by giving the offending anonymous type that wasn't really a GC type a name, and all returned to wellness. This latter problem is now being tracked in bug 1361444, but in the meantime, if anyone else ever sees a really inscrutable compile error along these lines, try giving names to the complained-about anonymous type to fix it.