<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 16, 2012, at 11:56 , Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Jul 16, 2012 at 11:35 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br><blockquote type="cite">How should we behave if the file contains a byte sequence which is not valid<br>UTF-8 (for instance, if arbitrary raw data is placed inside a raw string<br>literal)? For the machine-parsable form, I'd feel more comfortable with<br>bytes from the start of the line for this reason.<br></blockquote><br>Source code which isn't valid UTF-8 is illegal, even in raw string<br>literals. That said, we allow it in some cases anyway, so we need to<br>recover consistently.<br><br>We could define a consistent scheme for data which isn't UTF-8, but<br>you're right, it might be easier to just use "bytes since the last<br>newline".<br><br>-Eli<br></blockquote></div><br><div>Three things about that:</div><div><br></div><div>(1) The C standard explicitly <i>permits</i> multibyte characters (of arbitrary encoding) in 5.2.1.2. C++ [lex.phases]p1.1 implies a similar idea (non-basic characters are conceptually mapped into the source character set using UCNs). So saying non-UTF-8 code is "illegal" is sort of arbitrary; I'm not sure if we've ever documented this restriction, but we certainly don't enforce it.</div><div><br></div><div>(2) This is for fixits, which can appear within invalid code. I'm working on Unicode recovery in a private branch.</div><div><br></div><div>(3) Chris has said we assume UTF-8 for now.</div><div><br></div><div><div><blockquote type="cite">We want to assume that the input charset is in UTF8 for now. If we ever add support for other code pages, we'll either do it by rewriting the entire buffer all at once ahead of time (this is really the only option if the input is in UTF16), or by doing something else crazy like pervasively making the lexer know about single-byte codepages. Since we only support UTF8 for now, I'd just <span></span>start there.</blockquote></div><br></div><div>( <a href="http://llvm.org/bugs/show_bug.cgi?id=13178#c7">http://llvm.org/bugs/show_bug.cgi?id=13178#c7</a> )</div><div><br></div><div>In order to fix the crasher, I'll change the human-readable output to use printed columns, using sys::locale::columnWidth as suggested by Ben. I'll leave the parseable diagnostics as-is for now, but add a note to our manual that machine-parseable ranges use "bytes from the beginning of the line" as the index. We can revisit that at any time.</div><div><br></div><div>Jordan</div></body></html>