fix warning when generating VS 2013 project

/FS forces the compiler to synchronize pdb file writes.
This option is not needed when building with Visual Studio itself.
Still, qmake needs to know it when parsing the compiler flags.

Task-number: QTBUG-36535
Change-Id: Id5b68c4028844e0b95904e08b5121310a4ff13d6
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Delete the children before updating the Cocoa menubar

When the Cocoa menubar is updated then it ensures that the merged native
menu items are visible if appropriate. However when the old menubar is
deleted then it causes the merged native items to be hidden. Therefore
we ensure the children are deleted first which causes the native items
to be hidden and then update the menubar so that they can be correctly
visible if they should be.

Change-Id: I426864a5d2ec1f34c03290ac66371b12bf77cc00
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
fix crash when using GTK 2.14 function in old gtk

This is additional fix for bug 23569.
Previous fix (SHA1 7fcf1cf674d09d9dd1d41e2913252017f1d599ca) is not enough.
QGtkStyle was still crashing with old gtk (< 2.14)
in drawComplexControl () function.
Bug was reproducible on CentOS 5.x and Red Hat 5.x.

Current patch makes the same check as in commit mentioned but in another
line of code.

Task-number: QTBUG-23569

Change-Id: I261b61bc93ccaada879ed02ad4d0bef62935335b
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Harri Porten <porten@froglogic.com>
Added #include "qnumeric.h" to qglobal.h

Including qnumeric.h causes QtGlobal to have all of the functions that
the documentation indicates that it brings.

Task-number: QTBUG-36715
Change-Id: Ib08ccc18a85dfe4ecd18ef1dfbfec3e90ab8ec2c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make parsing of template arguments more robust.

At first, my goal was just to fix Moc::until() to parse properly
template arguments containing expressions containing > or >>
such as Foo<(8>>2)>

But with the test, I realized that normalizeType also requires change
not to split the > > too much.

And QMetaObjectPrivate::decodeMethodSignature should not interpret
the ) within the template parameter as the end of the function.

Change-Id: Ia9d3a2a786368aeda1edcf66280d70f64cf05070
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Draw more inactive style elements in retina res.

Update drawColorLessButton() and qt_mac_cg_context()
to handle paint devices with a devicePixelRatio greater
than one.

Task-number: QTBUG-36792

Change-Id: I9d642846b299fc7048bb8e08765b9e1d7ee631fc
Reviewed-by: Denis Dzyubenko <denis@ddenis.info>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Remove incomplete paragraph from QSet::iterator documentation

I could trace the dangling 'However, ' back to Qt 4.2. We probably will
never knew what the rest of the sentence was, exactly ... since the
previous paragraph is anyhow covering the same grounds we can just
remove the paragraph.

Change-Id: I1dda56e1ad17932205b8f40a527ca90a7592ad40
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Doc: Adding a new page to Qt Creator's external page file.

-new page called "Creating an Android Applicaion"

Change-Id: Ibe17f7c96aee3fe6c549a27d3b0f2b93cc0a5453
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
moc: Fix parsing of operator<

moc would skip the 'operator' keyword as unknown and try to parse a type again
but as it sees the '<' it looks for the corresponding '>' which does not exist
types can't start with '<' anyway, so return an invalid type and continue
parsing as usual

Task-number: QTBUG-36834

Change-Id: If3d27076ef9947abf8c57c594713eece9334d0b0
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
tst_qsignalblocker: simplify test

This test can assume that the QObject::signalsBlocked property works as
advertized, so just check signalsBlocked() in repsonse to QSignalBlocker
manipulations.

Change-Id: I99e4ef9c4ed05c3840233d92a587636d2d78f59a
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QFont: add missing qHash overload

The properties that make up the hash value are chosen to be the same as those
that make up QFontDef's op<() and op==(). Indeed, the implementation for QFont
simply delegates to the one of QFontDef, which has been added for this purpose,
but may prove useful in its own right down the line.

The code would greatly benefit from a qHash(qreal) implementation. Lacking
this, the patch uses multiplication with 10000 and qRound64() to convert
the one floating-point property used in the hash to an integer. This is
probably the right thing to do anyway, to avoid epsilon problems.

[ChangeLog][QtGui][QFont] Added qHash overload for this class.

[ChangeLog][QtCore][QHash] Allowed QFont to be used as a key in QHash/QSet.

Change-Id: I2c1cb5d9da53e26cb2c0f1a7c357731e73eea78e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add qHash() overloads for floating-point types

This implementation is based on GCC's implementation of std::hash<FP>, but only
to the extent of checking for zero before hashing the bits. The bit hasher is
the Qt one; I didn't even look what GCC uses.

The check against 0.0 is mandated by the requirement to have
  \forall x,y: x == y => qHash(x) == qHash(y)
which would be violated for x = 0.0 and y = -0.0 if we only hashed the bits.

Implemented out-of-line to avoid potential FP-comparison warnings, as well
as to be able to use the file-static hash() functions, which gets inlined
unlike qHashBits(), which cannot be.

[ChangeLog][QtCore][QHash/QSet] Allowed to use float, double and long double
as QHash/QSet keys.

Change-Id: I38cec4afb860f17e9f8be7b67544e58b330f8fff
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Centralize the merging toFloat conversions

The QByteArray version was missing the overflow check that the other
versions had.

Change-Id: I03cd92e5e5a84c038bee1f1ee217e93e9d9a675a
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Work around ICC 14 bug: __attribute__((deprecated)) with text

Apparently it doesn't like the text.

Change-Id: If8e14df84f0d9915018eac94df16bf1b679155e0
Reviewed-by: Keith Gardner <kreios4004@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Initial support for the Intel Compiler 14.0 on OS X

ICC 8 and 9 are positively ancient. I doubt anyone is using them for
Qt, let alone Qt 5. ICC 11 through 13 haven't supported OS X.

ICC now masquerades as Clang, so we need to let qmake and
qcompilerdetection.h know about it.

Change-Id: If0d2bd8b6a4a45250c15c9472c062effc76f17de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add a testAndSet overload to the atomics that returns the current value

This is extremely useful, since the most common action after a failed
compare-and-swap is to loop around, trying again with the current
value as found in memory.

Code currently written as:
    do {
        Type value = atomic.load();
        ...
    } while (!atomic.testAndSetRelaxed(value, desired));

Becomes:
    Type value = atomic.load();
    do {
        ...
    } while (!atomic.testAndSetRelaxed(value, desired, value));

In most CPU architectures, the value that was found in memory is known
to the compare-and-swap code, so this is more efficient than the
previous code. In architectures where the value is not known, the new
code is no worse than before.

The implementation sometimes modified an existing function, sometimes
it added a new one, depending on whether more registers were needed in
the assembly (like ARMv6-7), the code became more complex (ARMv5), the
optimizer failed (C++11), or it was just plain equivalent (MIPS).

Change-Id: I7d6d200ea9746ec8978a0c1e1969dbc3580b9285
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add the rest of the non-volatile members of std::atomic to QBasicAtomic

[ChangeLog][QtCore][Atomic support]Added more operations to the atomic
classes, including operator T(), operator=(T), operator++,
operator--. For the QAtomicInteger, bit-manipulation operations are
also provided, both in operator and in fetchAndXxxYyyyyy modes.

Change-Id: I39c07be74e15e0a48f9e931f4342b182004dee1a
Reviewed-by: David Faure <david.faure@kdab.com>
Make the printing of complex Unicode in a QString prettier

This also has the advantage of not requiring the use of the locale
codec. Quite an advantage if you're debugging the locale codec. But it's
mostly so that we don't get question marks that hide the difference we
were trying to locate.

[ChangeLog][QtTest] QtTest now prints an escaped version of QStrings
that failed to compare with QCOMPARE. That is, instead of converting
non-printable characters to question marks, QtTest will print the
Unicode representation of the character in question.

Change-Id: I44c1ef3246b188c913dacd3ca4df02581356ea41
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QOpenGLTextureBlitter: add some autotests

Change-Id: I07a4847a19908c1a6d7fb02649b306dfa0148f49
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
QOpenGLTextureBlitter: Remove Origin location for the Target rect

The Origin for Target rect was deemed a confusing concept. The current
implementation would translate the target rect to the coordinate system
specified. However, the order and "direction" of the vertices would
always be the same. So drawing a texture in for one target rect defined in
one coordinate system would paint the texture the same way as it would
when a texture was drawn for a target rect drawn in the "opposite"
coordinate system. The point with this was that if you wanted to "flip"
the texture you would specify that with the source coordinate system.

However, this approach breaks on different levels, such as QRect has functions
which expects a top left coordinate system (ie. top() and bottom()).

In the end Qt uses a top left coordinate system, hence QWindow specifies
a top left coordinate system, and hence the api becomes easier if it is
not possible to define the coordinate system of the target viewport.

Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>