Patch forthcoming.
Created attachment 204844 [details] work in progress
Created attachment 204863 [details] it compiles!
Created attachment 204918 [details] the patch
Comment on attachment 204918 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=204918&action=review > Source/WTF/ChangeLog:11 > + Also made it possible to convert a UChar to a utf8 CString without > + allocating a StringImpl. Since this is only used with dump() methods, why do we care about allocating a StringImpl?
(In reply to comment #4) > (From update of attachment 204918 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=204918&action=review > > > Source/WTF/ChangeLog:11 > > + Also made it possible to convert a UChar to a utf8 CString without > > + allocating a StringImpl. > > Since this is only used with dump() methods, why do we care about allocating a StringImpl? Because you cannot ref/deref StringImpl's on the compiler thread, which implicitly means you cannot allocate them. That's an important assertion, since StringImpl's aren't thread-safe ref-counted. So we want to keep that assertion; but to keep it, we can't allocate StringImpls in the compiler thread.
Created attachment 204925 [details] patch for landing Now including tests.
Landed in http://trac.webkit.org/changeset/151781