Change-Id: I7a4259ac43e59a8f50ee1c5072a3da5b977d8bfe
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
There are cases, where the conversion from a wildcard pattern to
a regular expression should not lead to an anchored pattern. Allow
this, but adding an optional second argument to
wildcardToRegularExpression, that allows tuning the conversion.
Change-Id: Ida7a32d65ee49bf58d5f8d9906c0a0cd8954a02a
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The CMAKE_INSTALL_RPATH cache var had the PATH type, which made
CMake transform the value into an absolute path, getting rid of the
$ORIGIN value.
Fix that by changing the cache var type to STRING.
Also clean up the all-caps commands, add a usage example and print
the install RPATH.
Change-Id: Ibf40cfde4283369ddfcf52609143799cc8e47d68
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* support lambda expressions
* remove the need to specify result_type
* use std::invoke to apply map|filter function
* remove usage of FunctionWrapper* and createFunctionWrapper
Task-number: QTBUG-33735
Task-number: QTBUG-82646
Change-Id: Ibcbe4278f0742c29182bd506081db0abb516f85f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
This is required to support QtVirtualKeyboard's third party OpenWnn
library.
Change-Id: I64b6a2b6b6b0259bea5aa249a8c901def31f916c
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
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>
