RESOLVED FIXED 103866
Replace JSValue::description() with JSValue::dump(PrintStream&)
https://bugs.webkit.org/show_bug.cgi?id=103866
Summary Replace JSValue::description() with JSValue::dump(PrintStream&)
Filip Pizlo
Reported 2012-12-03 00:57:05 PST
JSValue::description() does the horrible static char buf[thingy] thingy.
Attachments
the patch (16.41 KB, patch)
2012-12-03 01:06 PST, Filip Pizlo
darin: review+
buildbot: commit-queue-
patch for landing (17.13 KB, patch)
2012-12-03 15:10 PST, Filip Pizlo
buildbot: commit-queue-
patch for landing (19.47 KB, patch)
2012-12-03 22:06 PST, Filip Pizlo
no flags
Filip Pizlo
Comment 1 2012-12-03 01:06:21 PST
Created attachment 177205 [details] the patch Let's see how many bots this breaks.
Build Bot
Comment 2 2012-12-03 01:49:05 PST
Darin Adler
Comment 3 2012-12-03 10:17:15 PST
Comment on attachment 177205 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=177205&action=review Looks like your only build problem is an .exp file on Windows. > Source/JavaScriptCore/ChangeLog:32 > + (JSValue): Please remove bogus lines like these from your change log. > Source/WTF/ChangeLog:12 > + (WTF): Please remove bogus lines like this. > Source/WTF/ChangeLog:15 > + (WTF): Please remove bogus lines like this. > Source/WTF/wtf/StringPrintStream.cpp:98 > + return String::fromUTF8(m_buffer, m_next); This can fail if there are invalid UTF-8 sequences in the buffer. And then we’ll get a null string back from the fromUTF8 function. Do we want/need to handle that? > Source/WTF/wtf/StringPrintStream.h:63 > +// Convert to a String using UTF8 conversion. I don’t think the UTF8 emphasis in this comment is helpful. If we wanted to emphasize UTF-8, then we should have done that in the name StringPrintStream::toString. Since we don’t want to emphasize it there, there no reason to emphasize it here.
Filip Pizlo
Comment 4 2012-12-03 15:05:55 PST
(In reply to comment #3) > (From update of attachment 177205 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=177205&action=review > > Looks like your only build problem is an .exp file on Windows. > > > Source/JavaScriptCore/ChangeLog:32 > > + (JSValue): > > Please remove bogus lines like these from your change log. Fixed. > > > Source/WTF/ChangeLog:12 > > + (WTF): > > Please remove bogus lines like this. Fixed. > > > Source/WTF/ChangeLog:15 > > + (WTF): > > Please remove bogus lines like this. Fixed. > > > Source/WTF/wtf/StringPrintStream.cpp:98 > > + return String::fromUTF8(m_buffer, m_next); > > This can fail if there are invalid UTF-8 sequences in the buffer. And then we’ll get a null string back from the fromUTF8 function. Do we want/need to handle that? I don't think so. This is used for debugging exclusively at this point, and I believe that in all cases the input is currently some combination of: - String constants from our own code. - Things that used to WTF::String but were converted to a CString via String::utf8(). If it ever becomes a problem I guess we could use fromUTF8WithLatin1Fallback. Also, do we happen to have a fromUTF8() variant that inserts a '?' or other dummy marker character for cases where it encountered garbage? This could be useful for example in the new profiler (https://bugs.webkit.org/show_bug.cgi?id=102999) if at some point something internally in JSC created an invalid UTF8 sequence - we'd still want to get some output rather than a null string, and falling all the way back to Latin1 might not be appropriate. > > > Source/WTF/wtf/StringPrintStream.h:63 > > +// Convert to a String using UTF8 conversion. > > I don’t think the UTF8 emphasis in this comment is helpful. If we wanted to emphasize UTF-8, then we should have done that in the name StringPrintStream::toString. Since we don’t want to emphasize it there, there no reason to emphasize it here. I'll remove it.
Filip Pizlo
Comment 5 2012-12-03 15:10:07 PST
Created attachment 177344 [details] patch for landing I think that Windows will still have problems. I will wait for Win EWS before landing.
Build Bot
Comment 6 2012-12-03 17:02:48 PST
Comment on attachment 177344 [details] patch for landing Attachment 177344 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/15132173
Filip Pizlo
Comment 7 2012-12-03 22:06:40 PST
Created attachment 177416 [details] patch for landing Trying this again.
Filip Pizlo
Comment 8 2012-12-04 11:30:21 PST
Note You need to log in before you can comment on or make changes to this bug.