This is required to support QtVirtualKeyboard's third party OpenWnn
library.
Change-Id: I64b6a2b6b6b0259bea5aa249a8c901def31f916c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Explicitly use the Qt APIs that return QPixmap and QBitmap by value, and
fix the API taking those to use const references rather than pointers
or const values.
Change-Id: I2bb7ad1edb3b65f806f0475fca383e5b9bdb61f3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
(cherry picked from commit b61ea367a5)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Try to read past an UTF-8 BOM even if no textcodec support is available,
but do set the status to FormatError then.
This is in line with the general 'best effort' approach in QSettings.
It also allows qmake (that is built without textcodec support) to
gracefully load qt.conf files with a UTF-8 BOM, though non-Latin1
characters might still be misrepresented.
Fixes: QTBUG-83456
Change-Id: I31b45dc5a8adf7950910897a2b33ae16990d3818
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This amends f36b042e2b to only check
permissions for uris that are going to be local to the device itself.
Other uris, such as http, https etc, should go through fine without a
check.
Change-Id: If05caadb6e0712d9db8f57185ef017d724d9e172
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It doesn't exist in every instantiation of the template; this becomes
evident when attempting to build QQuickListView:
error: 'using Chain = struct QHashPrivate::MultiNodeChain<FxViewItem*>'
{aka 'struct QHashPrivate::MultiNodeChain<FxViewItem*>'} has no member named 'size'
Change-Id: I24748c15f3995083eec06d86a3c0dced2209c303
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Otherwise we will fail to resolve the symbol and will not create
a forwarding header for the class.
Change-Id: I34922d8458bdb994a194108183ac9b9d14530c5e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
lupdate can deal with Objective-C++ sources nowadays, most
likely due to appending them to SOURCES instead of the
deprecated OBJECTIVE_SOURCES.
Task-number: QTBUG-30125
Change-Id: Ifc6b06f13e0f679a011d999f11c2e6d25dcf27ed
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It doesn't make sense to lose precision, and that's a fatal warning
when used on a 32-bit platform:
implicit conversion loses integer precision: 'quint64' (aka 'unsigned long long')
to 'quint32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
Also fix coding style.
Amends 7ef3826497
Change-Id: I2c8f51883d74f0c6dc1b5faefe7b3ace1d9c15b9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
As a drive-by, also fix spelling of architecture.
Change-Id: Ibeaa6b611ddbb75b9492deb5d97a64ed8b030c3a
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
This allows us to use regular expressions in bootstrapped tools
such as moc and tracegen.
Change-Id: I4310dd15bf26651aac6ab30c884e025ca06b3099
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The double-swap technique I used was flawed and broke on
self-assignment. What I had meant to use was the move-and-swap
technique. Thanks to Peppe for pointing it out.
This also fixes a compiler bug in the Green Hills compiler. It was
finding the wrong "swap" function in qSwap:
using std::swap;
swap(value1, value2);
It's supposed to find swap(QCborValue &, QCborValue &) due to argument-
dependent lookup. It's instead finding std::swap<QCborValue>, which
recurses.
Fixes: QTBUG-83390
Change-Id: Ibdc95e9af7bd456a94ecfffd1603e1bee90cd107
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Change the hash function of QTypeRevision and QtFontFallbacksCacheKey
to use size_t and add a few casts.
Change-Id: I89a8fc617abbe8b0c67529ec41795691c99b0574
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This change adds the setWinTabEnabled() function to Qt Platform Headers,
which allows an application to set at run-time whether the WinTab API will
be used for tablet input instead of the native Windows Ink API.
[ChangeLog][Windows] The setWinTabEnabled() function added to Qt Platform
Headers now allows an application to set at run-time whether the WinTab API
will be used for tablet input instead of the native Windows Ink API.
Fixes: QTBUG-83218
Change-Id: I51d3c7316baeda136763cf37c2f54295905450ec
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Some test cases are sensitive to the exact ordering inside
QHash, and need adjustments when we change QHash or the
hashing functions.
Some rcc tests now also need 32bit specific data, as the hashing
functions for 32 and 64 bit are different now (as we use size_t).
Change-Id: Ieab01cd55b1288336493b13c41d27e42a008bdd9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Requires one more branch inside the loop, but that should not
really matter performance wise. And it should expand to less code.
Change-Id: I4619dd2a2e6fedf8d109009a5b6d7410ed89f1fb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This commit replaces MurmurHash with SipHash for all strings longer than
the size of a pointer. The most important difference between those
algorithms is that MurmurHash has this unwelcome property: for two
byte sequences x and y, if you know that x and y have the same hashing
for a given seed, then they have the same hashing for all seeds.
SipHash has no such issue. If the seed changes, the strings that used to
compute to the same hash are no longer likely to do so.
We've chosen to implement a SipHash-1-2 algorithm instead of the regular
2-4 as that has roughly the same performance as the old DJB33XA
algorithm. It's around 50% slower than MurmurHash, which is
acceptable given the added security.
Task-number: QTBUG-47566
Change-Id: I09100678ff4443e6be06fffd14819c8878d223e2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The old implementation was either using CRC32 on modern processors
or a trivial, but rather slow implementation.
We can't continue with CRC32, as that implementation can only
give us 32bit hashes, where we now need to support 64bit in Qt 6.
Change the implementation to use MurmurHash, as public domain
implementation that is both very fast and leads to well distributed hashes.
This hash function is about as fast as the SSE optimized CRC32 implementation
but works everywhere and gives us 64 bit hash values.
Here are some numbers (time for 10M hashes):
14 char 16 char
QByteArray QString float
old qHash (non CRC32) 127ms 134ms 48ms
old qHash (using SSE CRC32 instructions 60ms 62ms 46ms
new qHash 52ms 43ms 46ms
Unfortunately MurmurHash is not safe against hash table DoS attacks, as
potential hash collisions are indepenent of the seed. This will get
addressed in followup commit, where we use SipHash or an SSE optimized
AES based hashing algorithm that does not have those issues.
Change-Id: I4fbc0ac299215b6db78c7a0a2a1d7689b0ea848b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
At the same time use the opportunity to refactor the
insertion code inside the implementation of QHash to
avoid copy and move constructors as much as possible
and always construct nodes in place.
Change-Id: I951b4cf2c77a17f7db825c6a776aae38c2662d23
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is required, so that QHash and QSet can hold more
than 2^32 items on 64 bit platforms.
The actual hashing functions for strings are still 32bit, this will
be changed in a follow-up commit.
Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is used by QSet to avoid storing extra data for the value
in the Hash. Re-implement the optimization after the changes to QHash.
Change-Id: Ic7eba53d1c0398399ed5b25fef589ad62567445f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make use of the new features available in QHash and do a more
performant implementation than the old one.
Change-Id: Ie74b3cdcc9871cd241aca205672093dc395d04a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A brand new QHash implementation using a faster and more memory efficient data
structure than the old QHash.
A new implementation for QHash. Instead of a node based approach as the old
QHash, this implementation now uses a two stage lookup table. The total
amount of buckets in the table are divided into spans of 128 entries.
Inside each span, we use an array of chars to index into a storage area
for the span.
The storage area for each span is a simple array, that gets (re-)allocated
with size increments of 16 items. This gives an average memory overhead of
8*sizeof(struct{ Key; Value; }) + 128*sizeof(char) + 16 for each span.
To give good performance and avoid too many collisions, the array keeps its
load factor between .25 and .5 (and grows and rehashes if the load factor goes
above .5).
This design allows us to keep the memory overhead of the Hash very small, while
at the same time giving very good performance. The calculated overhead for a
QHash<int, int> comes to 1.7-3.3 bytes per entry and to 2.2-4.3 bytes for
a QHash<ptr, ptr>.
The new implementation also completely splits the QHash and QMultiHash classes.
One behavioral change to note is that the new QHash implementation will not
provide stable references to nodes in the hash when the table needs to grow.
Benchmarking using https://github.com/Tessil/hash-table-shootout shows
very nice performance compared to many different hash table implementation.
Numbers shown below are for a hash<int64, int64> with 1 million entries. These
numbers scale nicely (mostly in a linear fashion with some variation due to
varying load factors) to smaller and larger tables. All numbers are in seconds,
measured with gcc on Linux:
Hash table random random random random reads full
insertion insertion full full after iteration
(reserved) deletes reads deletes
------------------------------------------------------------------------------
std::unordered_map 0,3842 0,1969 0,4511 0,1300 0,1169 0,0708
google::dense_hash_map 0,1091 0,0846 0,0550 0,0452 0,0754 0,0160
google::sparse_hash_map 0,2888 0,1582 0,0948 0,1020 0,1348 0,0112
tsl::sparse_map 0,1487 0,1013 0,0735 0,0448 0,0505 0,0042
old QHash 0,2886 0,1798 0,5065 0,0840 0,0717 0,1387
new QHash 0,0940 0,0714 0,1494 0,0579 0,0449 0,0146
Numbers for hash<std::string, int64>, with the string having 15 characters:
Hash table random random random random reads
insertion insertion full full after
(reserved) deletes reads deletes
--------------------------------------------------------------------
std::unordered_map 0,4993 0,2563 0,5515 0,2950 0,2153
google::dense_hash_map 0,2691 0,1870 0,1547 0,1125 0,1622
google::sparse_hash_map 0,6979 0,3304 0,1884 0,1822 0,2122
tsl::sparse_map 0,4066 0,2586 0,1929 0,1146 0,1095
old QHash 0,3236 0,2064 0,5986 0,2115 0,1666
new QHash 0,2119 0,1652 0,2390 0,1378 0,0965
Memory usage numbers (in MB for a table with 1M entries) also look very nice:
Hash table Key int64 std::string (15 chars)
Value int64 int64
---------------------------------------------------------
std::unordered_map 44.63 75.35
google::dense_hash_map 32.32 80,60
google::sparse_hash_map 18.08 44.21
tsl::sparse_map 20.44 45,93
old QHash 53.95 69,16
new QHash 23.23 51,32
Fixes: QTBUG-80311
Change-Id: I5679734144bc9bca2102acbe725fcc2fa89f0dff
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add a new QRangeCollection type to store and manage
multiple page ranges. This moves out the parser and validator
logic from the platform dependent (UNIX) dialog and makes it
publicly available from QPrinter.
This improves the usability of QPrinter in those applications
which doesn't use print dialog to configure printer.
(e.g.: QTextDocument, QWebEnginePage)
Change-Id: I0be5a8a64781c411f83b96a24f216605a84958e5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Followup to ed3ed0b9db68916fede4 and
3c159957f8.
In QWindowSystemInterfacePrivate::fromNativeTouchPoints() and
QWindowSystemInterfacePrivate::toNativeTouchPoints() we continue using
struct TouchPoint's QRectF area as storage for the screen position +
ellipse diameters; as the comment says, this is _unrotated_, meaning
that rotation is stored separately, and area should not be construed as
the bounding box of the rotated ellipse. (In Qt 6 we can make the
QPA touchpoint look the same as the QTouchEvent::TouchPoint to
eliminate the need to calculate the center of the rect.)
In QGraphicsScenePrivate::updateTouchPointsForItem(), setRect() sets the
position and the ellipse diameters, but the latter is redundant because
the purpose of this function is to localize a touchpoint to the
coordinate system of a particular QGraphicsItem. Ellipse diameters
should stay the same.
In QApplicationPrivate::updateTouchPointsForWidget(), as in
QGraphicsScene, we are localizing touchpoints to a widget
and to the screen that the widget is shown on, so only the position
needs to be set, while preserving the sub-pixel resolution that
mapFromGlobal(QPoint) loses.
Fixes: QTBUG-83403
Change-Id: I61d29e14cbe38567767b164af6ae895082c5e1a1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Clear Linux containers running as root may have no /etc/passwd. But
they'll have /etc/machine-id because systemd creates that. Also test
/proc/version (a Linux-specific file) because that isn't writeable even
by root.
Take the opportunity to check with access() instead of assuming root and
only root can write to the file.
Change-Id: Ibdc95e9af7bd456a94ecfffd1603e8359604752b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This was never tested. The infinite loop in QCborContainerPrivate::grow
is the proof.
[ChangeLog][QtCore][QCborArray] Fixed an infinite loop when operator[]
was called with with an index larger than the array's size plus 1.
Change-Id: Ibdc95e9af7bd456a94ecfffd1603df3855c73f20
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Similar to the QJsonObject issue of the previous commit (found with the
same tests, but not the same root cause). One fix was that copying of
byte data from the QByteArray to itself won't work if the array
reallocates. The second was that
assign(*that, other.concrete());
fails to set other.d to null after moving. By calling the operator=, we
get the proper sequence of events.
[ChangeLog][QtCore][QCborMap] Fixed some issues relating to assigning
elements from a map to itself.
Note: QCborMap is not affected by the design flaw discovered in
QJsonObject because it always appends elements (it's unsorted), so
existing QCborValueRef references still refer to the same value.
Task-number: QTBUG-83366
Change-Id: Ibdc95e9af7bd456a94ecfffd1603df846f46094d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The refactoring to use CBOR missed two places where we could assign from
the same object and thus cause corruption. In fixing this issue, I found
a design flaw in QJsonObject, see Q_EXPECT_FAILing unit test and task
QTBUG-83398.
[ChangeLog][QtCore][QJsonObject] Fixed a regression from 5.13 that
incorrect results when assigning elements from an object to itself.
Fixes: QTBUG-83366
Change-Id: Ibdc95e9af7bd456a94ecfffd1603df24b06713aa
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Avoids ASAN warning of ODR violation:
SUMMARY: AddressSanitizer: odr-violation: global 'typeinfo name for
QSocketEngineHandler' at ../../../../../src/network/socket/qabstractsocketengine.cpp
This trick has not been needed since we got Q_AUTOTEST_EXPORT. The main .pro
file has:
requires(qtConfig(private_tests))
Change-Id: Ibdc95e9af7bd456a94ecfffd1603e598932b88ad
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
