[ChangeLog][QtCore][JSON] Added overloads of functions taking key
strings as QStringView; in QJsonObject, QJsonValue and QJsonDocument.
Change-Id: I78b40aba8200003acfae257ff06f5f15737005e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Refactored parts of insert() into a new private method insertAt(), which
can also be called by operator[]() to avoid a redundant key lookup.
This is in preparation for overloading QJsonObject's non-const methods
on QLatin1String.
As a bonus, this also avoids a redundant key lookup in
QJsonValueRef::operator=().
Change-Id: Ic481981d838e50bc55fb8e7844536749781899ce
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QObjects are not even reentrant, but this class must be thread-safe,
so it's always ... icky ... to have to analyze a "thread-safe
QObject", because for all intents and purposes, that's an oxymoron.
The QObject-ness isn't even used, except for defining a private slot,
connected to QCoreApplication::destroyed(). That slot just calls
waitForDone() on QThreadPool, which is a QObject itself, so use it
as the context object for the signal-slot connection, using a lambda
as slot.
So, strip the class of it's base class, convert the private slot to a
lambda and connect to that. Finally, remove the moveToThread() call,
because this new class can be destroyed from any thread, not just the
main one.
Change-Id: I0e33983aa7afd0ad621ece4afd10d9e4adad38c1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Unfortunately, we can't, yet, change QAbstractFileEngine::create() to
return a unique_ptr. But we should do it in Qt 6.
Change-Id: If18ff766bce73ecd4143274ac9f9a5a7b9d5912c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If it was used in the past, it no longer is, and can't be, because
it's not exported.
Change-Id: Ifb9c353e756add5b57bf0c5706c075bb2eb41d83
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Equality for QNetworkConfiguration is defined by identity of the
Private object, so even if there are QNCs with the same properties,
they will not compare equal. This probably happens when a user roams
through different WLANs (e.g. from work via public transport to home
and then back), and each time the home WLAN pops up, it will beget a
new QNetworkConfiguration, not comparing equal to the previous one.
So, over time, we might collect a sizeable amount of
QNetworkConfiguration objects just sitting in the cache without ever
being able to actually use an associated network session, because they
all have long since expired.
To fix, prune expired network sessions, and thus their associated
QNetworkConfigurations, from the cache. To not run every time, prune
only when this size of the cache is larger than 16 (arbitrary number).
Change-Id: I11a636f45ccf67420f84b1c79a4453a144de7c5c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Used for setting primaries without a full ICC profile.
Change-Id: I6dd8e62ca15bf1f86e7bbc01aaf8e0bd85803071
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Three *_unix.cpp are added twice for unix and for mac
Makefile:14766: warning: overriding commands for target `.obj/
qfilesystemengine_unix.o'
Makefile:14037: warning: ignoring old commands for target `.obj/
qfilesystemengine_unix.o'
Makefile:14913: warning: overriding commands for target `.obj/
qfilesystemiterator_unix.o'
Makefile:14184: warning: ignoring old commands for target `.obj/
qfilesystemiterator_unix.o'
Makefile:15071: warning: overriding commands for target `.obj/
qfsfileengine_unix.o'
Makefile:14342: warning: ignoring old commands for target `.obj/
qfsfileengine_unix.o'
Change-Id: Ia5f9d2873f738081c2d1e763efbdfc64209aaf7d
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
If QImageReader recognized the suffix of a file, it would by default
not check if the file contents matched the claimed format. Hence, a
valid but misnamed image file would fail to load.
Fix by adding contents check for suffix-recognized files.
[ChangeLog][QtGui][Image] Loading of image files having a file name
suffix for a different image file type has been fixed. QImageReader
will now ask the suffix format handler to confirm the file contents
(canRead()), and fall back to normal file content recognition on
failure. This implies a slight behavior change in
QImageReader::loopCount(), ::imageCount() and ::nextImageDelay(): For
an unreadable file with a recognized suffix, they would earlier return
0, while they now will return -1, i.e. error as per the documentation.
Fixes: QTBUG-42540
Fixes: QTBUG-68787
Change-Id: I205e83f29ed7190cbcae95dab960232544d012f6
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
It turns out that the only reason a recursive mutex is used was
because work() was locking it. But work() was only ever called from
functions that already had locked the mutex themselves, and kept it
locked across the call to work(). Clearly mark work() as expecting to
be called with the mutex held (by renaming the function to
rescheduleWithMutexHeld(), then drop the mutex locking from it.
After this change, a non-recursive mutex suffices, so save the memory
allocation and extra complexity involved with recursive mutexes.
Looking at the non-QT_CONFIG(thread) code in rescheduleWithMutexHeld(),
one might be tempted to expect a recursive mutex, since that code
calls QHostInfoRunnable::run() directly, which, in turn, recurses into
QHostInfoLookupManager whence control came, under mutex lock. But in
non-QT_CONFIG(thread) builds, QMutex is but an empty shell, all of its
operations are no-ops, so no possibility for deadlock, either.
Change-Id: Ic01d90c2ed3995b66ccf946d146fdaa6f9af3d8b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
warning C4573: the usage of 'tst_QNetworkReply::connect' requires the
compiler to capture 'this' but the current default capture mode does not
allow it
Change-Id: Ic9fd526fedf7c52e53e2b1136834c10bf4cd0ea9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It's not implemented
Change-Id: I56abb0a5fe0e6d5c2f5f678adadafed395456902
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
All users of the QPixmap ctor can pass rvalues, so take by rvalue-ref
and move into place. Adapt callers to actually pass rvalues.
Change-Id: Iacff2ed893ceaa1665b270ce466ffdc21ba800f1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QHostInfo isn't implicitly shared. The more important to optimize away
copies by providing a move constructor.
Port from QScopedPointer to Q_DECLARE_PRIVATE, as otherwise the move
ctor can't be inline, and we don't implement move ctors out-of-line in
Qt.
[ChangeLog][QtNetwork][QHostInfo] Added move contructor.
Change-Id: I6b63a04e36f63e299205830fdc590ff7e2af338b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's not <APPROOT> (any more, or was ever).
Fixes: QTBUG-76911
Change-Id: I6aed4df6a12e43c3ac8efffd15aed22128862c23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Applications might receive paths with Windows' '\\?\' markers, which
indicates a long path to Win32 APIs, when the application is opened by
explorer via file association. Qt not ignoring those markers will fail
to open such files.
By stripping the marker in QDir::fromNativeSeparators, QFile, QFileInfo
etc automatically are able to handle such paths. QDir::cleanPath is
also documented to normalize separators, so it needs to be done there
as well.
[ChangeLog][QtCore][QDir] Remove Windows specific long path markers
when handling file paths with native separators.
Change-Id: I526a890614edee8c85b39fc12c98e7ddb6e0d793
Fixes: QTBUG-75117
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This matches what translateDeadKey() returns for unhandled keys, and
processKeyboard() checks for when replacing qtKey with the result of
translateDeadKey().
Change-Id: I1500576b7b31047a7a35633a15cd6975b77d842d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The textdate API methods are deprecated in favor of QLocale; so
suggest use of QLocale in place of them. Don't credit the deprecated
methods as being used where they aren't.
Change-Id: I0abcb1f69729760ae1b86cb8088e4158c0ad6010
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Tasuku Suzuki <tasuku.suzuki@qbc.io>
Somehow I didn't test using QNetwork{Status,Connection}Monitor together
with Gui. In qwindowstheme.cpp we call CoInitialize and as such we
cannot use CoInitializeEx with a different thread mode.
Change-Id: If4a4441cc2616371d8b7cda72cfad11187d8f153
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Allows us to reference captured variables and keeps the function
local to where it's used.
Change-Id: I609892888720202021862d26a74ceb50e232f356
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
So that the context can be referenced during initialization.
Change-Id: I9ec69b2431ba1ac6256cb2e969a76f515497e247
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Well, yeah, it technically does...
qcborstream.h:245:15: warning: declaration shadows a typedef in the global namespace [-Wshadow]
/usr/include/libkern/OSTypes.h:36:26: note: previous declaration is here
Fixes: QTBUG-75825
Change-Id: Idce141629dd34287808bfffd159ee2a75428bf12
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Current codebases assume isCompressed() implies ZlibCompression, since
there was no compressionAlgorithm() getter. In order to force codebases
to change, deprecate isCompressed() and force handling of the algorithm.
The replacement API is being introduced in 5.14, which is why the
warning is being emitted in 5.15 only.
Change-Id: Ief874765cd7b43798de3fffd15a9f5d978951ea5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Cache can't be null, since it's a member of an extant object.
Change-Id: Id98140e1c2f0426cabbefffd157ed3cdd62a8bba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Windows has a problem relating to cross-DLL variable relocations: they
are not supported. Since QMetaObject's link to the parent class is done
via a pointer, every QMetaObject in a DLL or in the EXE that derives
from a class from another DLL (such as QObject) will be dynamically
initialized.
This commit changes the meta object pointers in QMetaObject::d from raw
pointers to a wrapper class SuperData, which is almost entirely source-
compatible with the pointer itself. On all systems except for Windows
with Qt 6, it's binary compatible with the current implementation.
But for Windows with Qt 6, this commit will store both the raw pointer
and a pointer to a function that returns the QMetaObject, with one of
them non-null only. For all meta objects constructed by moc, we store
the function pointer, which allows the staticMetaObject to be statically
intialized. For dynamic meta objects (QMetaObjectBuilder, QtDBus, QtQml,
ActiveQt), we'll store the actual raw pointer.
[ChangeLog][QtCore][QMetaObject] Some internal members of the
QMetaObject class have changed types. Those members are not public API
and thus should not cause source incompatibilities.
The macro QT_NO_DATA_RELOCATION existed in Qt 4 but was called
Q_NO_DATA_RELOCATION and only applied to Symbian. It was removed in
commit 24a72c4efa ("qglobal: Remove
symbian specific features").
Task-number: QTBUG-38876
Fixes: QTBUG-69963
Change-Id: Id92f4a61915b49ddaee6fffd14ae1cf615525e92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Caused by commit 01301b0b34, which made
vector.resize(vector.size()) not to detach, which was used by fill() and
assumed that detaching happened. The test does not test the resize()
behavior, only that fill() is not broken anymore.
[ChangeLog][QtCore][QVector] Fixed a regression that caused fill() not
to detach, corrupting shared copies.
Fixes: QTBUG-77058
Change-Id: I6aed4df6a12e43c3ac8efffd15b1b527a8007bf3
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
When changing the primary screen, the various changed signals of
QScreen were out of order. Most notably, the wrong DPI value was
emitted since QGuiApplicationPrivate::processScreenGeometryChange()
checks and emits DPI and orientation as well. Rearrange the code to
assign new the values and emit DPI first.
Task-number: QTBUG-76902
Change-Id: If4037108391c36ab3a8bfcb9b2989d5bea41202f
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
These were hidden in !QT_CONFIG(thread) code. The irony!
This patch does not change the semantics of the operations. It
just makes the implicit operations explicit.
Any fixes or optimizations are left for follow-up patches, if any.
Change-Id: I014eb71745532dae2efe7963aa87321f61b1bd7a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The mapping is static, but a dynamic (even mutable) container was
used.
Fix by using C tables and liner scan, which will be just as fast or
faster than a hash lookup, for the maximum of six entries of each
table.
Change-Id: I899d5b1428dc82cf58862f238595a266aef8279f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Now that we can depend on C++11, use _WITH_ARGS and std::initializer_list.
Saves ~400B in text size on optimized AMD64 GCC 9.1 Linux LTO builds.
Change-Id: I37fce1c63a5f74f6dfc059febf0152ac93c8be7f
Reviewed-by: David Faure <david.faure@kdab.com>
The mutex is only protecting 'nameMap'. Proof: it's only defined on
platforms on which there is a 'nameMap'. Also, nothing else is
mutable, so no lazy init going on here.
So, drop all the mutex protection, except where we access 'nameMap',
and draw the mutex as close as possible to the nameMap uses, iow: copy
ctor, prepareName() and nameToString().
As a consequence, the old (Ordered)MutexLocker class only needs to be
defined on Unix.
Change-Id: Ic969313bc48ad7ebf24c5dca7fd48359956b048d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
fix the bloody test for good - the idea to have a shared QNAM (shared
by test cases in this test) was somewhat wrong to start with.
Fixes: QTBUG-77053
Change-Id: I5755e96ec988e2dd546f527f3f902fc43914b0b7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As noted in RFC7230 Section 6.1 the 'Connection' options are case
insensitive.
https://tools.ietf.org/html/rfc7230#section-6.1
Change-Id: I80b98d82eaa5572d38a6c3f99383bc059ec91c54
Fixes: QTBUG-76990
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The code basically wants to get the last element of equal_range(id).
The problem is that backwards iteration on QHash is very expensive,
because it's implemented as forward search with wrap-around at bucket
end.
So it was implementing its own equal_range with look-ahead. The
problem is that it compared each key in the equal_range twice: once in
the if, and once more in the following while iteration.
I expect to see this kind of algorithm more as we move away from the
fake bidirectionalism of QHash, so I decided to implement it in a
generic way. We can copy it somewhere else when we find more users.
Change-Id: I7951652107ab897f6a456035f02e0339835e078d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As in QVarLengthArray (c34242c679), this will
probably bite someone someday, so fix it before there's a bug report.
Use ctor delegation to keep code size increase small.
There's also the benefit that default-constructing a QNetworkRequest now
no longer creates an expensive QUrl object just to destroy it unused again.
Add an auto-test.
Change-Id: I5ceb5402ca3946048d695244d1b1c36564a1e80a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Not visible in QMake, because of too old C++ standard used to compile it,
but in the qttools copy. Fix here, as the authorative source, first.
Change-Id: I2552eccfaab2cef0863686dcd888f2a5f25ca29f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QChar currently is convertible from nearly every integral type. This
is bad code hygiene and should be fixed come Qt 6.
The present patch is the result of compile fixes from marking these
constructors explicit.
Amends 60ca2f5f7c.
Change-Id: I06887104d42f8327eb6196afcde5f942a74a6a78
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The first one is trivially correct: it clearly doesn't modify the
container under iteration.
The second is a bit more subtle, because drawWindow() could be
expected to call a paintEvent and this could theoretically lead to
lowering, closing, or opening of a window. But this function just ends
up blit()ting, so it doesn't call into user code.
Change-Id: Id15e0102e9c8aa12516af27d771104e9993c48a1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
