Using char16_t instead of wchar_t in TestWebKitAPI URLParser tests
Some build bot (Linux ARM GTK port) fails since we cannot select the specific StringBuilder::append method for wchar_t. wchar_t implementation highly depends on platforms. sizeof(wchar_t) == 2 in VC++, while sizeof(wchar_t) == 4 in GCC. Instead of using wchar_t, we use char16_t and C++11 UTF-16 literal in test cases.
Created attachment 289774 [details] Patch
https://build.webkit.org/builders/GTK%20Linux%20ARM%20Release/builds/12283 failing example.
Watching EWS.
Created attachment 289801 [details] Patch
Comment on attachment 289801 [details] Patch r=me Be careful when committing this. The commit queue and svn-apply change the emoji to UTF-8 encoded emoji, which breaks the test.
Committed r206378: <http://trac.webkit.org/changeset/206378>
(In reply to comment #6) > Comment on attachment 289801 [details] > Patch > > r=me > Be careful when committing this. The commit queue and svn-apply change the > emoji to UTF-8 encoded emoji, which breaks the test. Thanks. Landed.
Seems a bit strange to use char16_t instead of UChar, given that we use UChar everywhere else in WebKit.
Another way to put that is: Maybe we should start using char16_t everywhere instead of UChar!
(In reply to comment #9) > Seems a bit strange to use char16_t instead of UChar, given that we use > UChar everywhere else in WebKit. This is just used to use u"UTF-16" literal in C++11 in this testing. This allows us to write UTF-16 chars including emoji directly in source code and makes testing easier. char16_t is used only before calling utf16String() function. After converting to WTFString, char16_t is no longer used. (In reply to comment #10) > Another way to put that is: Maybe we should start using char16_t everywhere > instead of UChar! That is very nice, but, it prevents us from using ICU functions easily. There are 2 problems I think. 1. Built ICU may use different UChar definition. If ICU is built with WebKit, we can replace UChar implementation from uint16_t to char16_t by passing -DUCHAR_TYPE=char16_t. However, if ICU is system's one, we carefully need to align UChar type to the system's one because C++ mangled names are different among char16_t, uint16_t, and wchar_t. For example, OS X's ICU's UnicodeString (const UChar *text, int32_t textLength) constructor is mangled as `__ZN3icu13UnicodeStringC2EPKti` -> UnicodeString(const unsigned short*, int). So UnicodeString(const char16_t*, int) causes a link error. If we only use ICU C API, we can ignore this problem. However, it seems that some places use ICU C++ APIs. 2. Windows ICU prefer wchar_t. Windows has a lot of APIs using wchar_t. So ICU uses wchar_t for UChar in Windows. This allows us to pass UChar* directly to Windows APIs. If we change UChar to char16_t, we need to use properly wchar_t and char16_t in those places. Personally, I think using char16_t instead of using ICU UChar doesn't give us nice benefit at this time. What do you think of?
*** Bug 161806 has been marked as a duplicate of this bug. ***