Clean up QStringLiteral definition

We require lambda support in the compiler since Qt 5.7, so drop
the guard macro.

Apart from MSVC 2013, all our supported compiler also support
char16_t:

- VxWorks uses GCC 4.8, which supports char16_t since 4.5.
- ICC supports char16_t since v12.1; we require v14+.
- ONX uses a GCC which supports char16_t in the compiler,
  but is equipped with a stdlib that does not sport char16_t
  support, which is why we revoke its Q_C_UNICODE_STRINGS in
  qcompilerdetection.h. But we don't need stdlib support, we
  only need the core language feature.
  This is the only platform where this patch actually changes
  something. It removes the, rather unfair, pessimization of
  the platform which could have supported the static-storage-
  duration implementation of QStringLiteral instead of the
  fallback, which uses dynamic memory (QString::fromUtf8()).
- GCC and Clang support char16_t since 4.5 and 3.0, resp.,
  which is far below our minimum compiler requirements in
  effect since Qt 5.7.
- On Windows, MSVC supports char16_t since 2015 only, and we
  still support 2013, but on Windows, wchar_t is the same size
  as char16_t, so instead of u"str" we can fall back to L"str".

So simplify the implementation of QStringLiteral by assuming
that all these feature are present, adding noexcept to the
lambda to make noexcept() queries return true.

This allows us to guarantee:

[ChangeLog][QtCore] QStringLiteral is now guaranteed to be
evaluated at compile-time. The last platform (QNX) to use the
QString::fromUtf8() fallback has been ported to allocate the
string data statically, too.

Change-Id: I7920d7a77001e5c5550e7c7d57ceb7c51c9eb443
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

0 files changed, 0 insertions, 0 deletions