Re: [Libreoffice-commits] core.git: Handle wchar_t as native C++11 type on windows

The below commit means that internally in LIBO_INTERNAL_ONLY code, 
sal_Unicode and sal_uInt16 no longer "clash" (due to being typedefs to 
the same underlying type) on any platform.  The intent is to switch 
sal_Unicode from a typedef of wchar_t to a typedef of char16_t (still 
for LIBO_INTERNAL_ONLY only) on the Windows/MSVC platform once we drop 
support for MSVC 2013---at which point all platforms will use a typedef 
of char16_t for LIBO_INTERNAL_ONLY,

For backward compatibility, non-LIBO_INTERNAL_ONLY remains as it always was:
* For Windows/MSVC, sal_Unicode is a typedef of wchar_t, which, thanks 
to /Zc:wchar_t- is a typedef of unsigned short (which is the same 
underlying type as sal_uInt16).
* For all other platforms, sal_Unicode is a typedef of sal_uInt16 directly.

The below commit apparently also means that your next Windows build will 
likely break due to stale PCH data unless you do a full rebuild.

On 05/03/2016 09:26 PM, David Ostrovsky wrote:
> commit e16fa715c43dcdf836ce8c400b6d54eae87b627d
> Author: David Ostrovsky <david@ostrovsky.org>
> Date:   Sun Mar 13 09:18:00 2016 +0100
>
>     Handle wchar_t as native C++11 type on windows
>
>     The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
>     according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
>     was not implemented as a built-in type, but was declared in wchar.h as
>     a typedef for unsigned short. Now, years later after the end of life
>     this outdated toolchain, there is no reason not to use native type.
>
>     The only issue could be the ABI compatibility. But on a quick look at
>     least, it looks like none of the mangled C++ symbols in the stable URE
>     interface actually depend on wchar_t.
>
>     We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
>     5.2, though.
>
>     Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
>     Reviewed-on: https://gerrit.libreoffice.org/22589
>     Tested-by: Jenkins <ci@libreoffice.org>
>     Reviewed-by: Stephan Bergmann <sbergman@redhat.com>