<div class="gmail_quote">On Mon, Jul 16, 2012 at 10:56 AM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Jul 16, 2012 at 10:49 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
><br>
> On Jul 16, 2012, at 10:47 , Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On 16.07.2012, at 19:32, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br>
>><br>
>>> Hi, everyone. We recently hit an assertion when trying to output a fixit with Unicode characters in it; it reduces down to this:<br>
>>><br>
>>> void test() {<br>
>>> printf("∆: %d", 1L);<br>
>>> }<br>
>>><br>
>>> I could of course just disable fixits when there are Unicode characters involved, but I'd like to fix this the right way. The trouble is -fdiagnostics-parseable-fixits, which is supposed to be machine-readable output, and in this case is a three-byte UTF-8 character three columns or one column? I think one column is the right way to go, but I wanted to get some other opinions before I start working on a patch.<br>

>><br>
>> This actually depends on the system. On some systems we'll print the unicode codepoint in hex, others will get the 1 column char. There is the llvm::sys::locale::columnWidth function to get this information in a portable way.<br>

><br>
> Okay, that gives us two problems, then…for user-visible fixits we can use llvm::sys::locale::columnWidth (thanks, Ben), but then -fdiagnostics-parseable-fixits will have different column numbers? Is that okay?<br>
><br>
> (Currently -fdiagnostics-parseable-fixits counts columns in bytes rather than characters.)<br>
<br>
</div></div>Machine-parsable "columns" are not the same as columns in the<br>
terminal.  I'm pretty sure the model we want is one "column" per<br>
Unicode code point, regardless of how it is displayed.</blockquote><div><br></div><div>How should we behave if the file contains a byte sequence which is not valid UTF-8 (for instance, if arbitrary raw data is placed inside a raw string literal)? For the machine-parsable form, I'd feel more comfortable with bytes from the start of the line for this reason.</div>
</div>