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>
Commit 310031188c (Fix moc stumbling over gcc __attribute__
extensions, 2012-10-01) applied similar logic for GNU style
attributes.
Change-Id: I550eaefd703b4e974e6ffae7716f02074c8a8823
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
moc's C++ is not 100% accurate, so better process the invalid macro with
a warning rather than an error.
Such errors occurred in the QSKIP macro with variadic arguments since
that macro is defined conditionally.
It is also causing problem in boost header (cf task QTBUG-29331)
Task-number: QTBUG-29331
Change-Id: Ice6a01b675286540d6470c8e36920b7efd39b540
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
this works with -no-gui, and doesn't interfere with our upcoming ANGLE
hackery.
Change-Id: I2985cc0acd1fbf185b8967ffe58606b1b7dd9d1e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
When encountering code such as:
X<a<b>
moc does not have the mean to know if 'a' is a type or a variable, so the
type parser currently assume that '<' always open a template parameter.
(instead of being the operator<)
The type parser do not care about the actual type, it just need to strip
the string out. The problem is that then the whole rest of the file will
be considered as the type.
With this patch, we also stop the parsing at semicolon. The type will
be wrong, but this allow the parser to recover and it will continue to
look for more classes after this.
(In other words, moc will no longer break if it encounter such construct
in a header. But it will still not parse such types correctly if used
within a Q_OBJECT class)
Task-number: QTBUG-31218
Change-Id: I1fef6bc58493d7c00df72401c9ad55463b24eaa7
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
qWarning now depends on QT_MESSAGE_PATTERN, depending on that variable.
It will show things like the moc process id or the Parser::error
function name. We don't want that.
Change-Id: I5b35401200f0f7de2442aa77d700a82402081489
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
moc do not see Q_COMPILER_VARIADIC_MACROS as defined (because it does
not know the builtins defines)
So it would never parse those macro, and never generate the signals or
slot.
Always let moc parse the variadic macro, and put non-macro function in
the header so the generated code would compile on every compiler
Change-Id: Ie9504539ee737c81e831b217f8d623fe810d9e35
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Both gcc and clang allow the use of '$' in their identifiers as an
extension. moc should not throw a parse error if there is one in the
file. Instead, consider '$' as valid in identifiers.
Task-number: QTBUG-22720
Change-Id: I8be3a52429c0db5b7e8308b8f4fe475d3d3994bf
Reviewed-by: Simon Hausmann <simon.hausmann@digia.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>
When performing macro argument substitution, one should keep the set of
macro to exclude, else we can enter an infinite recursion.
Testcase:
#define M1(A) A
#define M2 M1(M2)
Task-number: QTBUG-29759
Change-Id: I564bbfed65e1c8599592eaf12c6d67285d2fd9ce
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Exhausting the symbol list while looking for the
final right parenthesis means it is missing.
Task-number: QTBUG-29308
Change-Id: Iccf5897b0f5eb719699fd12d6c8e4a16ff189d9b
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Exhausting the symbol list while looking for the
final right parenthesis means it is missing.
Task-number: QTBUG-29308
Change-Id: Iccf5897b0f5eb719699fd12d6c8e4a16ff189d9b
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Remove srcify() function, which was warned about as unused
on Windows.
Change-Id: I731d3b6f058d4246e39dcf9a137619ae5087d751
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Correclty replace macros according to the C++ standard.
Use the correct replacement method also to evaluate
With this moc correctly processes boost headers.
Task-number: QTBUG-27546
Change-Id: I001b3054c5fcdc34d46cfa53d1387bd19436f361
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
In WebKit we use moc -E to pre-process various files before throwing at
further build creation tools. The pre-processing is used to filter out
code depending in #ifdef'fed features.
The latest addition to the family of pre-processed files is the CSS grammar,
which is written in Bison. It contains rule lines like
$$ = parser->createFoo()
and when pre-processing this moc stumbles over the dollar sign. Instead
of ignoring un-tokenizable input we should add it to the current token
if we're in preprocessor-only mode, otherwise the $$ gets eaten and we
produce data-loss by printing out less characters than.
Change-Id: Ib32e7c04b38dd2ba3726201e76f27405f7ea6c0d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reported by David Faure.
In KDE a DEPRECATED macro gets defined in a header file created by cmake.
The define is not guarded with #if Q_CC_GNU or similar because at cmake
time the compiler is determined. Therefore moc suddenly sees this gcc
specific token and stumbles over it.
This patch simply defines an empty __attribute__ macro that will expand
to nothing and thus become invisible to moc's "C++ parser" after the
pre-processing.
Change-Id: I4448b9ac3f72b6334e32b27484401fb0fca23a0c
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Added some test cases that check that moc
correctly expands #defines
Change-Id: I7fe6eed129d46ca9281d73064571cae43b32410d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
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>
Otherwise the containers might be forward declared in the moc file,
and when the moc file is compiled in a standalone translation unit,
the full definition of it would not be available. This results in
odd compile errors, so instead generate the includes if required.
Change-Id: Ie01c5a5d45314daad0b00dec03b3e1e18cdbae64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Krause <volker.krause@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
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>
While writing the test, I found that moc doesn't yet support
volatile slots. I left the tests in, commented, for a time
when it does.
Change-Id: Ib5fa00b25600618aedcc66739630054f3c879b99
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This only works with the C++11 contextual keyword
directly, the MSVC equivalent 'sealed', or the Qt
define for it.
While this isn't a problem for syncqt, being an
internal tool, moc should eventually be able to parse
user code using local C++11-final-wrapping macros.
For this, I guess moc would have to be taught to
expand macros in code and not just test #if clauses,
potentially driven by something like
#pragma qt-moc expand-this
#define MY_FINAL_CLASS final
but that's something for someone more intimately
familiar with moc's source than I am.
Change-Id: Id6aec961a881e8d5a9b76a7fc8e1c02c71913f64
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This is just for completeness of the understanding of the limitations
of private signals. There are no private signals in Qt which have
overloads.
Change-Id: Ic34c555aea360ee34beec796e597657888573da9
Reviewed-by: Olivier Goffart <ogoffart@woboq.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 reverts commit 5bb1408927.
The temporary measure used to support redefinition of QtDeclarative
class names during the transition period is no longer required.
Task-number: QTBUG-24517
Change-Id: Ib90f08fcdfb02e004e594ac72b698eaa0325d98d
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Like with the numerous g++ mkspecs, we have mkspecs with suffixes, and
these mkspecs should still match the clang globs.
Change-Id: I9296408b5192bc72cc468d229a57923e3f5ab6f0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
