Bug 162537 – Using char16_t instead of wchar_t in TestWebKitAPI URLParser tests

• Component: New Bugs
• Status: RESOLVED FIXED

[Yusuke Suzuki]

Using char16_t instead of wchar_t in TestWebKitAPI URLParser tests

[Yusuke Suzuki]

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.

[Yusuke Suzuki]

Created attachment 289774 [details]
Patch

[Yusuke Suzuki]

https://build.webkit.org/builders/GTK%20Linux%20ARM%20Release/builds/12283 failing example.

[Yusuke Suzuki]

Watching EWS.

[Yusuke Suzuki]

Created attachment 289801 [details]
Patch

[Alex Christensen]

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.

[Yusuke Suzuki]

Committed r206378: <http://trac.webkit.org/changeset/206378>

[Yusuke Suzuki]

(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.

[Darin Adler]

Seems a bit strange to use char16_t instead of UChar, given that we use UChar everywhere else in WebKit.

[Darin Adler]

Another way to put that is: Maybe we should start using char16_t everywhere instead of UChar!

[Yusuke Suzuki]

(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?

[Carlos Alberto Lopez Perez]

*** Bug 161806 has been marked as a duplicate of this bug. ***