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>
MSVC prints warnings if all slots are actually static methods:
moc_xxx.cpp:71: warning: C4189: '_t' : local variable is initialized but not referenced
This can be easily avoided by using Q_UNUSED.
Change-Id: Ice134a8a8d3e6aef1df1e7a89e9a2867281580fd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
This commit changes several instances where moc was generating code that
used 0 as a null pointer constant. The Q_NULLPTR define is the more
idiomatic way to do this, and additionally this silences warnings
generated by e.g. GCC's -Wzero-as-null-pointer-constant.
[ChangeLog][Tools][moc] Fixed "zero as null pointer constant" warnings
in moc's generated code.
Change-Id: Ibe382b7bdbdddaf20cb4bdfd075fcdd1f363f9d3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
That way we will be able to access property of objects that are not QObject
(Q_GADGET)
Change-Id: Ib8ef6e52fc621e0b0d6530f82b1aa205f1ed5fd9
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This provides a way to invoke Q_INVOKABLE method
Change-Id: I301cec2a21c2889fb9dde0b1eb6e92d0bd561bd7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The byte array literals are only used to append them to another
QByteArray, so they offer only the static size calculation as a
benefit.
However, there are several drawbacks:
- QByteArrayLiteral data cannot be shared the way string literals
can be, not even within a single TU, and they add a few ints
for the QByteArrayData header which cannot reside in BSS, but
need to be stored in DATA.
- QByteArrayLiteral *does* allocate when the compiler doesn't
support C++11 lambdas.
- QByteArrayLiteral, when not using RVO, litters the code with
QByteArray dtor calls, which are not inline, and thus can't
be optimized away.
In particular, when used like this, they do not prevent any
memory allocation (in fact, they might add some, absent lambdas).
So, just append (C) string literals.
Change-Id: Iee5dba8dd970c5cc6df116afc1f8709a62356b06
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
When compiling with the -Wswitch-default flag, the compiler
spits warnings for the moc generated files.
In certain development environments (e.g. where MISRA rules
have to be followed) every switch statement needs to have a
default case. Unfortunately the moc generated files contain
switch statements without default case. This patch adds a
default statement to all switch statements that are generated
by the moc compiler.
Change-Id: I8f3d81e3463fce4d3abf2ea5d0fa8727a7d9ba2e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comment shows to which string a QT_MOC_LITERAL is pointing.
Change-Id: Ia389d750b1b1c21e2242bad6beceea4f9298ff8e
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
There is no point in saving \0 twice. Any code that could relay on it
is broken anyway, because moc saves \0\0 for an empty string.
Change-Id: I28fa4f78aae8c883c088df43ec89d608a99b3bdd
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is the warning it fixes:
moc_foo.cpp:28:9: warning: conversion to ‘qptrdiff {aka long long int}’ from ‘long unsigned int’ may change the sign of the result [-Wsign-conversion]
- idx * sizeof(QByteArrayData) \
^
qarraydata.h:282:49: note: in definition of macro ‘Q_STATIC_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET’
{ Q_REFCOUNT_INITIALIZE_STATIC, size, 0, 0, offset } \
^
moc_foo.cpp:26:5: note: in expansion of macro ‘Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET’
Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET(len, \
^
moc_foo.cpp:33:1: note: in expansion of macro ‘QT_MOC_LITERAL’
QT_MOC_LITERAL(1, 23, 5),
^
[ChangeLog][moc][QTBUG-36128] Fixed sign conversion warning in generated file.
Task-number: QTBUG-36128
Change-Id: Ibf00974dbfb419bb53a3109d93e4cee598bb0588
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
A module plugin in qml belongs to a URI/namespace. This
uri is resolved run-time by QtDeclarative by knowing the
path of the qmldir that references the plugin.
For static plugins this becomes a problem, since we lost
the information regarding which plugin belongs to which
qmldir, since a static plugin has no file path.
To avoid pushing the responsibility of clarifying this
onto the application developer, it is better to embed this
information into the meta data of the plugins themselves.
Since this information can be resolved by the
build system, a new option to moc has been added:
-M<key=value>
that will let you add meta tags to the meta data from
the command line to each class that has an IID specified.
For the URI case, we can then e.g do:
-Muri=QtQuick.Controls -Muri=QtQuick.Controls.Private
Change-Id: I81a156660148fc94db6f3cac0473e9e1c8458c58
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Don't use the 'emit' keyword in the moc generated code for properties
with MEMBER
Task-number: QTBUG-33094
Change-Id: I5a0950e9c7a0dee347a6a6c79098e3e7d4776014
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This may happen when we have namespaces and the qualified name is used
to scope an enum.
Task-number: QTBUG-32933
Change-Id: Ic4923bbfb138387bae1e3694172661ace8342089
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Scripts are available in internal mkdist repo.
Added license tags, updated licenses and copyrights/contacts
Change-Id: Ibc734275f3000987eaa4f5c57f19d4e1fda2c479
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
when the type is a pointer to a registerable 1 argument template type.
Task-number: QTBUG-31002
Change-Id: Iac0d6b71b2b805a1876110a0781d02188083c4e5
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
If the object has only MEMBER properties, without any other property
specifying READ, the generated will fail to compile with this error:
tst_moc.moc: In member function ‘virtual int ClassWithOneMember::qt_metacall(QMetaObject::Call, int, void**)’:
tst_moc.moc:3810:42: error: ‘_v’ was not declared in this scope
That's because the '_v' is only declared if 'needTempVarForGet' is set,
and it should be set when we have a MEMBER property.
Change-Id: I829fad3faf69654b5a3fd540857df19f4a9449d4
Reviewed-by: Gerhard Gappmeier <gerhard.gappmeier@ascolab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This associates properties with member variables and
avoids writing getter and setter methods manually.
The metaCall() method directly accesses the member variable,
so additional method calls can be avoided.
The metaCall() setter code also supports NOTIFY signals,
which means the according signal is emitted when the property
gets written.
Task-number: QTBUG-16852
Change-Id: I88a1f237ea53a1e9cf65fc9ef2e207718eb8b6c3
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
We can't have T& declared/registered as a metatype (wont compile), but
using it as type for a slot argument is possible. With the recent
introduction of metatype auto-registration we have to make sure that moc
doesn't attempt to auto-register those. Simple types are handled correctly
already, this fixes containers and smart pointers.
Change-Id: Id96857c57d6ebf158a67e9d527c89dc195473b1b
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Breakage introduced by 819d0203e6 .
Extend QT_MOC_EXPORT to take the unqualified class name
as well for the function names.
Change-Id: I736097b564caa37c522d723780663d03341f9032
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Lukas Geyer <lgeyer@gmx.at>
Using non-qualified name for QT_MOC_EXPORT_PLUGIN() breaks template
instatiation for QPointer<T>::operator=(T*) in qt_plugin_instance()
when the class is embedded a namespace with the same name.
namespace Test {
class Test : public QObject
{
Q_OBJECT
Q_PLUGIN_METADATA(IID "Test")
public:
Test(QObject *parent = 0) : QObject(parent) {}
};
} // namespace Test
In function 'QObject* qt_plugin_instance()':
error: expected type-specifier before 'Test'
error: no match for 'operator=' in
'_instance = (int*)operator new(4u)'
note: candidates are:
In file included from qtbase\include\QtCore/qpointer.h:1:0,
from qtbase\include\QtCore/QtCore:68,
from test.cpp:1:
qtbase/src/corelib/kernel/qpointer.h:87:25:
note: QPointer<T>& QPointer<T>::operator=(T*) [with T = QObject]
qtbase/src/corelib/kernel/qpointer.h:87:25:
note: no known conversion for argument 1
from 'int*' to 'QObject*'
qtbase/src/corelib/kernel/qpointer.h:79:7:
note: QPointer<QObject>&
QPointer<QObject>::operator=(const QPointer<QObject>&)
qtbase/src/corelib/kernel/qpointer.h:79:7:
note: no known conversion for argument 1
from 'int*' to 'const QPointer<QObject>&'
error: expected ';' before 'Test'
Change-Id: Idd3e57ab1c888352ad2a8e8f6efca75d858089df
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This works similarly to the automatic registration for Q_PROPERTY types,
but in this case it mostly affects the need for users to
call qRegisterMetaType<T>() before using queued connections
with methods using non-built-in metatypes, or before using invokeMethod
manually.
Change-Id: Ib17d0606b77b0130624b6a88b57c36d26e97d12d
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
In Qt 4, the user needs to call qRegisterMetaType if the property
could otherwise be read before the type is registered with the metatype
system. This patch makes that unnecessary and automatic by registering
it when the first read indicates that it is not yet registered instead
or when QMetaProperty::userType is called before it is registered.
The types which are automatically registered exclude the built-in
types, which do not need to be registered, and include metatypes which
are automatically declared, such as pointers to QObject derived types
and containers of existing metatypes.
Change-Id: I0a06d8efdcb64121618e2378366d0142fa0771f5
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Moc checks for the use of the QPrivateSignal struct, which is part of
the Q_OBJECT macro and is private to each class that uses it. Moc then
generates a name of the signal which does not include the private
struct, and generates code to invoke such signals with an instance of
the private struct.
This way we can mark private signals as such and prevent them from
being emitted from subclasses or from outside of the class entirely.
The drawback to this is that it only works if the private
signal has no default arguments. However, at least in Qt, there are
no such signals.
Change-Id: Id16eadaa8d3c36a2c3b265077877f3e1d8304c84
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This change allows us to delay creating the actual meta object
until it is actually required.
Change-Id: I1c4a4226bd82fa606b206dd60322f49b49c32463
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
QMetaObjectExtraData was added when support for QMetaObject::newInstance
was added. One needed a place to put the pointer to static_metacall in
the QMetaObject.
But as we break binary compatibility, one can change the size of
QMetaObject, and put everything back inside QMetaObject's own structure.
Meaning it is not required anymore to have one QMetaObjectExtraData
instance per QMetaObject anymore.
Change-Id: If0b8f586cbaf633eed10045adee3ba3366826c86
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
That was a regression introduced in 1c5db1aff
Example:
signals: int *someSignal();
would produce this code:
int* _t0 = int*();
which does not compile
So have special handling for pointer to change it to '= 0'
Change-Id: Ie695e15e309d15c3cfd5c5a69ac8bf6d61ae9915
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This enables easier updating of those structs, by reducing the amount of
code that needs to be fixed. The common (and known) use cases are
covered by the two macros being introduced in each case.
Change-Id: I44981ca9b9b034f99238a11797b30bb85471cfb7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When cross-compiling, the qreal type can be different on the target
than on the host (e.g. double on host, and float on target). moc is
a host binary, so it shouldn't try to resolve the type id of qreal,
but instead always output "QMetaType::QReal" (which is just an alias
for QMetaType::Double or QMetaType::Float, depending on the target).
This was a regression introduced in commit
f95181c7bb (new meta-object format);
the special-casing for qreal should have been kept.
Moved the code that generates the type info into its own function so
the logic is shared by generateFunctions() and generateProperties().
Change-Id: I2b76cf063a08ba95a7e6033549452355f67283ac
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
QMetaType::Void was ambiguous, it was pointing to a valid type (void)
and in the same time it was signaling errors in QMetaType. There was
no clean way to check if returned type was valid void or some
unregistered type.
This feature will be used by new QMetaObject revision which will
store type ids instead of type names. So it will be easy to
distinguish between:
void mySlot();
MyUnregisteredType mySlot();
Change-Id: I73ff097f75585a95e12df74d50c6f3141153e771
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This commit introduces two significant changes to the meta-object
data format:
1) Meta-type information (QMetaType type/name) information is
stored directly in the meta-data for both properties and methods;
2) The original signature (string) of a method is no longer stored
in the meta-data, since it can be reconstructed from the method
name and parameter type info.
The motivation for this change is to enable direct access to method
names and type information (avoiding string-based lookup for types
if possible), since that's typically the information language
bindings (e.g. QML) need. (moc already had all the desired
information about methods, but it threw it away!)
This change keeps support for the older (6 and below) meta-object
revisions, but the support will be removed after a short grace
period.
The following public QMetaMethod functions have been added:
name() : QByteArray
returnType() : int
parameterCount() : int
parameterType(int index) : int
The following internal QMetaMethod function has been added:
getParameterTypes(int *types) : void
This commit extends the meta-method data to include explicit
type/name data for methods. The new data follows the existing
(5-word) method descriptors in the meta-data. The method descriptor
format was modified to enable this. First, the descriptor now
contains the meta-data index where the method's type/name information
can be found. Second, the descriptor contains the number of
parameters. Third, the descriptor has a reference to the name of the
method, not the full signature.
Each entry of a method's type/name array contains either the type id
(if it could be determined at meta-object definition time), or a
reference to the name of the type (so that the type id can be
resolved at runtime).
Lastly, instead of storing the method parameter names as a
comma-separated list that needs to be parsed at runtime (which was
how it was done prior to this commit), the names are now stored as
separate entries in the meta-object string table, and their indexes
are stored immediately after the method type info array. Hence,
parameter names can be queried through the public API without
parsing/allocating/copying, too.
Task-number: QTBUG-24154
Change-Id: Idb7ab81f12d4bfd658b74e18a0fce594f580cba3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Gabriel de Dietrich
Kai Koehne
Jędrzej Nowacki
Frederik Gladhorn
Axel Rasmussen
Olivier Goffart
Marc Mutz
Matti Paaso
Frederik Gladhorn
Kurt Pattyn
Jędrzej Nowacki
Simon Hausmann
Tasuku Suzuki
Jerome Pasion
Richard Moe Gustavsen
Teemu Kaukoranta
Gerhard Gappmeier
Sergio Ahumada
Iikka Eklund
Volker Krause
Friedemann Kleint
Lukas Geyer
Stephen Kelly
Aaron Kennedy
Lars Knoll
João Abecasis
Kent Hansen
Jędrzej Nowacki