diff options
author | Marc Mutz <marc.mutz@kdab.com> | 2017-03-30 19:49:32 +0200 |
---|---|---|
committer | Marc Mutz <marc.mutz@kdab.com> | 2017-04-20 06:50:36 +0000 |
commit | 126c4eae84fee0e5bc4e9c6db167d92e87b7f612 (patch) | |
tree | 330dbd270045bc11f5b36208ae4b027bfe8ceb32 /tests/auto/bic/data/QtXml.5.6.0.linux-gcc-amd64.txt | |
parent | 3dcc075f4a5efce348a6fa00cf5a0adef97b1089 (diff) |
Split Q_COMPILER_UNICODE_STRINGS: add Q_STDLIB_UNICODE_STRINGS
Since commit bf2160e72cd8840a8e604438cbdc807483ac980a, we can rely on
charNN_t support in all compilers except MSVC 2013, and since that
commit, we use (in 5.10, not 5.9, yet)
!defined(Q_OS_WIN) || defined(Q_COMPILER_UNICODE_STRINGS)
when we only need charNN_t, the type, as opposed to its library
support (u16string, char_traits<char16_t>, ...).
This patch splits the Q_C_UNICODE_STRINGS macro into two, adding
Q_STDLIB_UNICODE_STRINGS for when we need std::uNNstring, leaving
Q_C_UNICODE_STRINGS for when we need just charNN_t support.
In QDebug, when constructing a QChar out of a char16_t, cast to ushort
first, since QChar(char16_t) was only officially introduced in Qt 5.10.
[ChangeLog][Potentially Source-Incompatible Changes] The internal
Q_COMPILER_UNICODE_STRINGS macro is now defined if the compiler
supports charNN_t, even if the standard library does not. To check for
availability of std::uNNstring, use the new Q_STDLIB_UNICODE_STRINGS
macro.
Change-Id: I8f210fd7f1799fe21faf54506475a759b1f76a59
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'tests/auto/bic/data/QtXml.5.6.0.linux-gcc-amd64.txt')
0 files changed, 0 insertions, 0 deletions