the existing test is a blackbox test. this one is going to be different.
the first test is a bit trivial ...
Change-Id: Iba1b0b5c32490677551ee92c36f381b884c2765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
This message is just informal, and not really relevant to the test case.
qtbase can now be built with -Werror=date-time
Change-Id: Ic14289f2f801d5a6e811869e60afb9691c7ca98b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
... as newer versions of nmake (and jom, for compatibility) have botched
circumflex processing (they simply don't do it when shortcutting the shell
evaluation).
as a side effect, the output is also more readable if the string contains
quotes.
Change-Id: I0506b59ceecb70da258c482f9973156b2803066d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
don't complain about various missing things resulting from replacing
default_pre.prf and having a private .qmake.cache.
Change-Id: Ie3471b514ebb1a80b72a480144551b56b5c7a254
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
In replacement for Q_ENUMS and Q_FLAGS.
Q_ENUM(Foo) has to be put after the declaration of Foo in an object.
It will tell moc to include the enum in the meta object (just like
Q_ENUMS) and will allow templated code to get the metaobject for
that enum.
Will be used by QDebug and QMetaType
Change-Id: Iefaf8ae07dc0359828102bf384809346629b3e23
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
The call was invalid from C99 perspective.
Change-Id: Ie07310735736eddf5eb0e142297e56164fde7fe4
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Contrarily to Q_OBJECTs, Q_GADGETs are not guaranteed to
descend from a Q_GADGET. Here, we ensure that if the first
superclass is a Q_GADGET, then the derived class will be
treated as one. This allows gaps in the Q_GADGET hierarchy
while preventing from trying to link to the inexistent
staticMetaObject if there's no such ancestor.
Change-Id: If10fb952e23655102a425bb18fe8babaf447a47f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
There's a change in Qt 5.4.0 that makes Qt compile with its own set of
D-Bus headers, which means QT_CFLAGS_DBUS may be empty. Thus, we can't
compile or link if we're using the actual libdbus-1 API to build the
test.
This commit makes these unit tests use the same dynamic loading
mechanism.
Change-Id: I56b2a7320086ef88793f6552cb54ca6224010451
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Under DBus it is possible to have methods and signals with the same name
or have methods which are reserved c++ keywords.
For example the logind session interface has a signal and method both
called Lock.
This patch allows generated methods to use a different method name
specified in the annotation that the original DBus name in the DBus
interface in a similar manner to how one can rename accessors.
[ChangeLog][QtDBus] Add annotation org.qtproject.QtDBus.MethodName to allow
autogenerating C++ methods with different names to the original DBus method
Change-Id: I08bbe77554fbdd348e93f82d45bab0d75d360c27
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
C++ standard advise to place 64k char limit for string literals, this
patch improves moc output so it is not affected anymore.
Task-number: QTBUG-36500
Change-Id: Iece630faaef45baebe8c7afe4fc51e0362c713de
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
When tokenizing, after macro expansion, moc needs to concatenate
subsequent string literals, because parser do not check for such
expressions.
Change-Id: Icc4f01395a5a7b67368eb8341a45ee74ade7d7f5
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
We map the Apple Clang versions to upstream, so that we have one
define to compare against.
Fixes build break on iOS due to qbasicatomic.h not defining
QT_BASIC_ATOMIC_HAS_CONSTRUCTORS on Apple Clang versions, which
is needed after 1e9db9f5e1
Change-Id: I17493c0187c20abc5d22e71944d62bfd16afbad2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We do not need to emit a diagnostic at definition time.
The diagnostic will be emit at expansion time.
Fix error when parsing boost header:
/usr/include/boost/fusion/container/vector/vector.hpp:25: Error: '#' is not followed by a macro parameter
Task-number: QTBUG-42233
Change-Id: I27deab362341f17ca3b0160615bb1b0934c3d5c3
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
The previously produced code was valid C++. Add the declaration
nevertheless to help people who want to use the switch in their
own code.
Task-number: QTBUG-42119
Change-Id: Ia47cf3930684474ff65e5cf37335d7d7f57a1d31
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The moc preprocessor is not necessarily fully compatible with the native
compiler preprocessor, which can lead to annoying warnings.
This fixes a problem particularly with the boost headers that rely on
MSVC only preprocessor features (to work around other MSVC preprocessor
deficiencies).
Task-number: QTBUG-29331
Change-Id: If884452969b512a746c81e235d31636b39c45b27
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
all else being equal, items with a higher numerical priority will appear
first in the result.
Change-Id: I4ee37ff404a53c4152a1e4fc2fc3c23ef525234d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This prevents conflicts in case of link time optimizations or
precompiled headers are used since we don't include qglobal.h
in the generated code.
Change-Id: I4266c8ae38e6eafefd28b3bde5cb725a24d67ea0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
At the moment, it's possible to have 2 properties with the same name,
which doesn't make much sense. Notify the user about that so she can
react on it.
Change-Id: I4865b71730921b79ce9dd8abb0cc760b3f1dbfd8
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Conflicts:
mkspecs/qnx-x86-qcc/qplatformdefs.h
src/corelib/global/qglobal.h
src/network/socket/qnativesocketengine_winrt.cpp
src/plugins/platforms/android/androidjniaccessibility.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
Manually adjusted:
mkspecs/qnx-armle-v7-qcc/qplatformdefs.h
to include 9ce697f2d5
Thanks goes to Sergio for the qnx mkspecs adjustments.
Change-Id: I53b1fd6bc5bc884e5ee2c2b84975f58171a1cb8e
Traditionally, RCC in "C mode" was meant to bundle small resources into
a binary, like help texts or an occasional icon. RCC produces a .cpp
file containing the actual data in a char array which is then passed
to the compiler and linker as a normal source file. Larger resources
should be compiled in RCC's binary mode and loaded at run time.
Current Qt Quick use tries to deploy large hunks of data in "C mode",
causing heavy compiler/system load.
This patch works around the issue by splitting the process into
three parts:
1. Create a C++ skeleton, as usual, but use a placeholder array
with "easily compilable" (mostly NULs) data instead.
2. Compile the skeleton file.
3. Replace the placeholder data with the real binary data.
time (qmake5 ; make clean ; make) takes 1.3 s real time for a
100 MB resource here, and there is still room for improving patching
performance if really needed.
Change-Id: I10a1645fd86a95a7d5663c89e19b05cb3b43ed1b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The comment shows to which string a QT_MOC_LITERAL is pointing.
Change-Id: Ia389d750b1b1c21e2242bad6beceea4f9298ff8e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
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>
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>
Moc should check full scope of any related objects or
gadget when it constructs extra data.
Change-Id: Ibd1b607a389cd4e788c0916984464cd9103d9c59
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
That way we can avoid name conflict with a namespace defined in
a different moc test
Change-Id: Id631d7c5556c9d6940e16dc53eb438dbcd0095eb
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Since now in Qt5 the moc does full macro substitution, it needs to handle
the defines passed is command argument, even if they span over multiple
tokens, or if they do not have any token.
Example:
moc '-DCOMPLEX=QVector<int>' '-DEMPTY=' foo.h
[ChangeLog][moc] Fixed passing -D of a macro defined to something more
complex than a single identifier.
Task-number: QTBUG-33668
Change-Id: Ie8131de215f1659a24af4778d52ee40cda19759f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
When declaring a Q_PROPERTY(SomeType::SomeEnum foo ...) and SomeType is not a
QObject but a gadget, then we must still include SomeType's meta object in the
list of related meta objects.
Task-number: QTBUG-35657
Change-Id: I46195140cb5d180c4f03bb1fe06a876e3fe11267
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
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>
It's still a relocation, but at least it can be marked read-only
after the relocation run, if indeed the dynamic linker goes to
such a length.
Change-Id: Ibadddac3ab99d2e58cc32cfd57311bddd3bdb0ef
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
Add qjson* implementation files from corelib/json
to the qmake build. Add a read-only compile mode,
enabled by defining QT_JSON_READONLY.
Add qmake built-in function parseJson(file, into)
which parses a json file into the given variable.
qmake uses a flat key -> value-list implementation
for storing variables, which means that some hackery
is need to represent arbitrarily nested JSON. Use a
special "_KEYS_" variable for arrays and objects:
Arrays:
["item1", "item2"]
$${array._KEYS_} -> 0 1 2
$${array.0} -> "item1"
$${array.1} -> "item2"
Objects:
{ "key1" : "value1", "key2" : "value2" }
$${object._KEYS_} -> key1 key2
$${object.key1} -> value1
$${object.key2} -> value2
Change-Id: I0aa2e4e4ae14fa25be8242bc16d3cffce32504d2
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
