[cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases

Eli Friedman eli.friedman at gmail.com
Mon Oct 31 19:30:09 PDT 2011


On Tue, Oct 25, 2011 at 5:26 PM, Seth Cantrell <seth.cantrell at gmail.com> wrote:
> Okay, so I haven't changed the serialization stuff. I did restrict getString to only char based strings and added a different function for the serializer to use. I also removed the change I'd made to containsNonAsciiOrNull, but since that uses getString() it's still restricted to char based strings now.

Committed as r143415+r143416+r143417+r143418.  Thanks!

-Eli

> results of 'make test' :
>
> Making Clang 'lit.site.cfg' file...
> Making Clang 'Unit/lit.site.cfg' file...
> --- Running clang tests for x86_64-apple-darwin11.2.0 ---
> lit.py: lit.cfg:143: note: using clang: '/Users/********/llvm-make/Release+Asserts/bin/clang'
> Testing Time: 57.02s
>  Expected Passes    : 3938
>  Expected Failures  : 25
>  Unsupported Tests  : 1
>
>
>
>
>
>
>
> On Oct 24, 2011, at 11:16 PM, Eli Friedman wrote:
>
>> On Mon, Oct 24, 2011 at 8:01 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>
>>> On Oct 24, 2011, at 7:13 PM, Eli Friedman wrote:
>>>
>>>> On Mon, Oct 24, 2011 at 6:43 PM, Seth Cantrell <seth.cantrell at gmail.com> wrote:
>>>>>
>>>>> Consider the literals L"\xD83D\xDC7F" and L"\U0001F47F" (The former being the UTF-16 surrogate pair corresponding to the latter). For a Windows target these two literals are indistinguishable after we do the initial translation in Sema::ActOnStringLiteral. The resulting StringLiteral will store the same data, and have the same Kind and CharByteWidth. But on a platform with sizeof(wchar_t)==4 the two will not be the same.
>>>>
>>>> That isn't what I meant; it's okay for the serialized AST to vary
>>>> across targets.  It just shouldn't vary across hosts.
>>>
>>>
>>> FWIW, serialization does vary across hosts, because we don't take any care whatsoever to deal with endianness issues in the AST reader/writer (and we tend to read integers from mmap'd files).
>>
>> Okay; then I guess we don't need to worry about either issue. :)
>>
>> -Eli
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>




More information about the cfe-dev mailing list