Fix erroneous exclusion of classes from related meta objects in moc

Assume an unrelated class that declares an enum and uses Q_ENUMS. Consider
then a class that uses UnrelatedClass::Enum as a Q_PROPERTY. We used to
include UnrelatedClass in the primary class's related meta objects, in order
to support use-cases like
    obj->setProperty("enumProperty", "ValueOfEnumAsString");

If however moc happens to see Q_DECLARE_METATYPE(UnrelatedClass::Enum), then it
would exclude it from the related meta objects, which would silently break the
string based enum value conversion. This was meant as an optimization, but it
isn't apparent to the developer why sometimes the string conversion would
work and sometimes not (depending on whether somebody declares that macro).
This also becomes visible in QML, which relies on the same embedded type
information for enum assignments.

This patch removes that check in moc's code generator and cleans up the code a
little. However always including the prefix of Q_PROPERTY(SomePrefix::Enum ...)
is not correct either, because it may be that SomePrefix is a namespace, which
would cause compilation issues. Therefore we limit the inclusion of related
meta objects only to Q_OBJECT decorated classes the moc has seen, and for these
we save the fully qualified name in the related meta objects array (for QTBUG-2151).

While this patch makes the previous workaround for namespace issues by using a
Q_DECLARE_METATYPE not workable anymore, by saving the fully qualified name we
are making a hopefully sufficient effort to not require a workaround in the
first place. There's always the new workaround of fully qualifying the type in
Q_PROPERTY.

One side-effect of this change is that in the autoPropertyMetaTypeRegistration
test of tst_moc, the CustomQObject for Q_PROPERTY(CustomQObject::Number
enumValue ...) is now a related meta object, and therefore when querying for
the type of this property via QMetaProperty::userType(), we are now aware of
this being an enum and try to resolve CustomQObject::Number via
QMetaType::type(qualfiedName). As there is no guarantee for this to succeed, we
must now also do what is done in the non-enum code path in ::userType(), which
is to call the moc generated type registration function.

Task-number: QTBUG-33577
Task-number: QTBUG-2151
Change-Id: Ibf20e7421cba464c558a25c76a7e1eef002c6cff
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
tst_qlinedit: Create a new test widget on demand for each test.

The test used a member testWidget that was cleared and reset after each
test, which caused focus fights and side effects. The widget is now
created and shown only when necessary.

Change-Id: I0dc635e9d4cdf4f899994b88206bb0125526f6df
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Implement support for ref-qualified QString::toLatin1 & friends

This is the first step in implementing an in-place conversion of QString
to QByteArray. This requires ref-qualifiers in member functions so we
know that we have an rvalue QString.

Converting from UTF-16 to Latin1 always requires half the memory.

For conversion from UTF-16 to UTF-8, the typical string will also need
the same memory or less: characters from U+0000 to U+007F consume one
fewer byte; characters from U+0080 to U+07FF and from U+10000 to
U+1FFFFF occupy the same space in UTF-8 and UTF-16; it's only the ones
from U+0800 to U+FFFF that consume more space in the UTF-8 string.

For the locale's 8-bit codec, we can't be sure and the code (currently)
needs to go through QTextCodec anyway.

This requires a #define set before #include'ing "qstring.h". However,
since qstring.h is included by the QtCore PCH, we need an extra qmake
compiler without the PCH flags to compile this .cpp.

After this change, the distribution of calls in QtCore, Network, Gui,
and Widgets is as follows:

                  const &               &&
 toUtf8           31 (74%)              11 (26%)
 toLatin1         79 (77%)              24 (23%)
 toLocal8Bit      26 (16%)              138 (84%)

Change-Id: Idd96f9ddb51b989bc59f6da50054dd10c953dd4f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Improve the Latin1 conversion in QString a little

First, use Qt::Uninitialized, since we're about to overwrite the memory
anyway with the new Latin 1 string.

Second, move the actual body of the conversion to a static void
function, which seems to improve code generation a little and, of
course, paves the way for the in-place conversion.

Change-Id: Iaed99ba1e52facad676510aa98443223e188d70a
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Add the UTF16-to-Latin1 in-place converter

This is only possible for two important reasons:

1) QString and QByteArray d pointers are both done with QArrayData and
   that class does not care that the alignof(T) changes from 2 to 1,
   so we can give the pointer from QString to QByteArray
   (after adapting the allocated size, which is now double)

2) conversion from UTF16 to Latin1 always has fewer bytes (exactly half)

Change-Id: I17b2690c910f3de8db55156c6d6b5f55be06d827
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
PCH stands for "precompiled header", not "prefix"

Change-Id: Ied8148be931992247e446719a0eaeec0dc868330
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
QNetworkCookie: allow cookies for IPv4 domains

If the domain is an IP address, we should not do any magic regarding
leading dots etc.

Task-number: QTBUG-35022

Change-Id: I7722de4e6027666dde27e9e37b6353e3da775d94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
QNetworkCookie: allow cookies for IPv6 domains

For IPv6 addresses don't call toAce as it returns the empty string.
We should reflect the behavior of browsers here, which all accept
cookies from IPv6 addresses.

Original-patch-by: David Tapuska <dtapuska@blackberry.com>

Task-number: QTBUG-35022

Change-Id: Ic00369e923d044ec459822b2405865c13e4185b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Richard J. Moore <rich@kde.org>