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>
In Qt 5, when streaming an invalid QDate using a QDataStream version
earlier than Qt_5_0, QDate.jd is written and read as 0, which is an
invalid julian day for Qt versions earlier than 5.0. For Qt 5.0
however, 0 is a valid julian day, so when comparing a deserialised
invalid date (read using a QDataStream version < Qt_5_0) against a
default-constructed invalid date, they won't compare equal when they
should.
Task-number: QTBUG-26989
Change-Id: Ia76df493471f3b068c7d7187be20e3178eff2cc7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This enforced lowercasing causes subtle errors, like changing the
drive letter case when doing $$files(), which makes it difficult
to do any string matching against the result later.
Task-number: QTBUG-26985
Change-Id: I4973e3ac3e851e24af944295edf290cc98f02fb6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
It is already documented as deprecated in 5.0, so marking it as deprecated
since 6.0 is silly.
Change-Id: If72cc81bdad18c907022c48b9aa8e7d87eb88e59
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Parse the prl files generated by qmake to get the link dependencies. They
contain all the information we need, and they are the only location with
all the right information.
Change-Id: Id9dcc988f20a744297502eff008de085326cdbcf
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Clinton Stimpson <clinton@elemtech.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Change-Id: I8fa2f10edbee1080646324c0689b23eda44aa75d
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
The commit 2ef52ca124 introduced
an error regarding where the json file must reside.
Change-Id: I296c93abebb3e9f8c9e7e29a4a433201064969f0
Reviewed-by: Peter Kümmel <syntheticpp@gmx.net>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This enables Q_DECL_FINAL and Q_DECL_OVERRIDE backed by VC's
non-standard extensions from VC 2005 on. VC 2012 will support
the standard-compliant version, so use that there.
Change-Id: I96874fe3d36fcaa283d2d1f53d5eb6825e55f259
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Change d060b6f04f introduced some
new properties to QTextFormat which were unfinished and did not
match the documentation in the same change. I've updated the API
and docs to use the regular QFont enum for letter spacing type
instead of introducing bools (which inhibits expansions later)
or mutually exclusive properties in the text format.
Change-Id: Ife44993b6746c413e421fdaf92ebaaab6ba95977
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The Qt::KeypadModifier modifier is internally masked away from all
shortcuts. So it is not possible to set a keypad only shortcut.
Changed the implementation so that first a full keysequence match is
searched. Then if no match is found the same sequence is tried
without the keypad modifer.
Added a autotest for this also to cover the basic use cases relating
to this.
Task-number: QTBUG-20191
Change-Id: Ibe7740c705fd0ab1eece4809b9a0b48882172933
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Same change as for Q_DECLARE_METATYPE, but in the container and
smart pointer specialisations of it.
Change-Id: If9390ccc43eb3b07122f5ea5b8094139b5e1ded0
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The old code resulted in one memory fetch for the test plus another one
for the return value (at the assembler level). The new code reuses the
already-loaded value:
- movl _ZZN11QMetaTypeIdI12QDBusMessageE14qt_metatype_idEvE11metatype_id(%rip), %edx
- testl %edx, %edx
- je .L158
movl _ZZN11QMetaTypeIdI12QDBusMessageE14qt_metatype_idEvE11metatype_id(%rip), %eax
- ret
+ testl %eax, %eax
+ je .L160
+ rep; ret
It also saves one load in the not-yet-initialised case:
-.L158:
+.L160:
leaq .LC7(%rip), %rdi
subq , %rsp
.cfi_def_cfa_offset 16
movq himBH1, %rsi
call _Z17qRegisterMetaTypeI12QDBusMessageEiPKcPT_
movl %eax, _ZZN11QMetaTypeIdI12QDBusMessageE14qt_metatype_idEvE11metatype_id(%rip)
- movl _ZZN11QMetaTypeIdI12QDBusMessageE14qt_metatype_idEvE11metatype_id(%rip), %eax
addq , %rsp
.cfi_def_cfa_offset 8
ret
Change-Id: I769950449822f2b1587680e05518be0a4f3120a2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This allows to fold the deref() and the destroy() operations into one,
destroyIfLastRef().
The member variables were renamed since there's now a member function
of the same name (ref()).
Change-Id: Ib94416d9e658065bbf5d3711ecafaf0eb063af17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
We don't want people to go and call through the function pointer
directly.
Change-Id: I386645239974f008d513eaa62593c1141b294b60
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
These constructors might not benefit from being constexpr (as the objects are
only created on the heap), so don't suggest so. There's no disadvantage of them
begin constexpr, but their constexpr'ability depends on whether QAtomic has
a constexpr constructor, and the added complexity of finding that out isn't
worth it.
Change-Id: I089a29dcb98ba935c339dce09d71f283522a9afd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
I've introduced a variable $post_kw (post-class-keywords) that
contains the patterns which are expected after a class name.
This variable is used both for a negative look-ahead assertion
in the class-name capture (so the regex doesn't parse the
keywords as the class-name), as well as to carry the parser
over the keywords into the subclass clauses.
Change-Id: Ia534ca01a511e1c773d007f1b0b4f448e8d009d0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Now that qvariant_p.h's HasIsNullMethod check is fixed
so that it doesn't require Q_COMPILER_DECLTYPE anymore
to be able to deal with final classes, there's no point
in distinguishing Q_DECL_FINAL and Q_DECL_FINAL_CLASS
anymore, so remove the latter.
Change-Id: I31de5b63e7d2e44171a13e928997c946d93e05c9
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Currently, we have a C++11 version that requires Q_COMPILER_DECLTYPE
support, and can deal with final classes, and a C++98 version that
doesn't require any C++11 features, but fails on final classes.
What we're missing is a version that works for MSVC v8 and v9
(2005 and 2008), which sport the 'sealed' non-standard keywords
but lack decltype support. So far, we tried to solve the problem
by making class-level final special (Q_DECL_FINAL_CLASS), not
defining that macro for these two compilers, even though we did
define Q_DECL_FINAL, the method-level keyword.
This new formulation, taken from
http://stackoverflow.com/a/9655327/134841
supposedly supports all compilers with a minor #ifdef for
MSVC which doesn't like applying sizeof() the way we do.
However, testing has shown this to blow up on OSX.
So we use the less intrusive approach: add this variant as
a third version, only used by VC 2005 and 2008.
Change-Id: If1945f8a6e9ed36cb68212fa781d5e29eb2a082d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reformat the MSVC feature detection to be similar to other compilers, ie.
1. Inside the C++11 features section instead of where the compilers
are detected
2. In one block for the compiler, with sub-blocks for the version.
However, it's now not 100% compatible with the previous version,
since Q_CC_INTEL is now explicitly excluded while before it was
implicitly included in the MSVC case. I have no idea whether
that matters, since Q_CC_INTEL is handled for itself further up
already.
Change-Id: Id9e8da0a5394ad5643bcb29493f14bc6e8264c13
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
A recursive mutex operates on top of a non-recursive mutex. Therefore,
we can bypass the test for recursive.
The end result is simply that the compiler can inline the locking and
unlocking a little better inside the lock() and unlock() functions
Change-Id: Ic06d1344ccd411c22cbdef74536f3a4d368d75d7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This detected the same missing detach()s in QUrl::resolve.
Everything else works, no need for a mutex in Qt5's QUrl.
Change-Id: I0da51b7b0c6b810d314a26d4b638383cd17de12b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
No other call to fileInfoGatherer.getInfo(info) is #ifndef'ed on
QT_NO_FILESYSTEMWATCHER, so this one shouldn't be, either.
Change-Id: If145226c13d77460d6169a9ed3028647b0f565b5
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Majid Khan <mkhan3189@gmail.com>
When dragging and dropping within the same application, the QDropEvent
should contain exactly the same instance of QMimeData as it was set to
QDrag.
This solves the problem in
https://bugreports.qt-project.org/browse/QTBUG-26953
Change-Id: I3bc4da845ff4293c509343c1c8c62fc331416ec0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
\Auml for a with umlaut doesn't seem to work with qdoc anymore,
so replace this with the unicode value instead. Also, add
reference to arguments in glyphRuns() function.
Change-Id: I31861b384b822d1fbdcafbeeac07ea68a0e5fd07
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Also adds a new snippet which is just copy-pasted from the
old documentation, because the snippet-file previously referenced
seems to have disappeared.
Change-Id: I0180715544321e076acda769cbdcbf19d50a971b
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
standard paths should never be added to compiler/linker lines, as they
are likely to mess up the lookup order.
pkg-config does that filtering for us, but the home-grown config tools
don't, so we need to take care of it.
configure.exe does not have such auto-detection, so the change is not
necessary there.
Task-number: QTBUG-26850
Change-Id: I2f523d5cffb27c3d0a16cdef6ca8a4877c9983c0
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Mitch Curtis <mitch.curtis@nokia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@nokia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
We could mark the cold path with __attribute__((cold)) (since GCC 4.3),
but quick tests locally indicate that the compiler is smart enough to
determine that by itself.
It will inline the hot path in _q_futex, which in turn is inlined in the
lockInternal and unlockInternal functions, whereas the cold path is kept
outside.
Change-Id: I8ae7d851d4f050498bfb491ba87d3e25453a14f8
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Unlocking a mutex can never throw an exception. That doesn't make
sense and our code should make sure it can't happen. Right now,
provided that the system-level functions don't throw, we don't either.
Locking a mutex cannot throw on Linux because we use futexes
directly. A non-recursive mutex is just a futex, whereas a recursive
mutex uses a mutex (a futex) to manage a lock count.
However, on other platforms, due to the freelist, there can be memory
allocation, which means it might throw std::bad_alloc. Not because of
the freelist itself (that uses malloc and will just crash if malloc
fails) but because of Q_GLOBAL_STATIC. In 5.1, the global static will
be noexcept provided the type's constructor is so too (it is, in this
case).
Change-Id: I4c562383f48de1be7827b9afb512d73eaf0792d5
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This will ask the D-Bus library to free its caches. It's useful for
running valgrind on a D-Bus based application, so we can detect real
leaks.
We can't run this by default because there could be other users of
libdbus-1. Calling the shutdown function would make them stop working.
Change-Id: I9854b82afcdbc4955d6f0a1a1b49a673186242c8
Reviewed-by: Lorn Potter <lorn.potter@nokia.com>
There's a comment saying nanosleep's availability is questionable, but
the information of what systems don't have that is now lost in
time. It's quite likely that they were older, Unix systems we no
longer support anyway.
nanosleep comes from POSIX.1b-1993, which is merged into POSIX.1-2001,
so chances are that it's supported almost everywhere where Qt runs
(except for Windows anyway).
Change-Id: I4fd18f8715c43a42429000f3b3d2c3b7343f94b4
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
