Coverity alerts about uninitialized members. While this might be ok
in the code here (ie TreeNode::splitLeft is never used for leaf nodes)
it can easily result in undefined behavior and other hard-to-debug
issues.
Initializing the struct with initializer syntax; compiler explorer
indicates that the compile will be able to optimze the calls to avoid
duplicate initialization of data members.
Change-Id: I0eb5d26e34f466d8c659c1945f02601aef511fbf
Fixes: QTBUG-84160
Fixes: QTBUG-84156
Coverity-Id: 218601
Coverity-Id: 11398
Pick-to: 5.15
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Use the combiners and an algorithm.
Change-Id: I577950bbd2e8b0556f28e2a8381e432c22bb0dc9
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Add a helper function so that we have a shortcut.
Instead of writing:
QHashCombine hash;
seed = hash(seed, fieldA);
seed = hash(seed, fieldB);
// etc.
return seed;
one can now simply write:
return qHashMulti(seed, fieldA, fieldB, fieldC);
Port a few usages inside qtbase as a demonstration.
[ChangeLog][QtCore][QHash] Added the qHashMulti and
qHashMultiCommutative functions as convenience helpers
to calculate a hash from multiple variables (typically,
data members of a class).
Change-Id: I881a9ad41168df20ceecc6588a94abe7ddc6a532
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
As what we did for QMake.
Amends commit 317383217b
Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I generated a rc file using VS2019 and I found that it's
using other macros.
According to [1], both of VOS_NT_WINDOWS32 and VOS__WINDOWS32 refers to
"File was designed for 32-bit Windows", although they have different
values, and 0x0L is the value of VFT2_UNKNOWN. So I think it's safe to
update them. VS2019 is using them as the default template for rc files,
after all.
[1] https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource
Change-Id: Ibaf91394668844492f1357da05b881b9d81aa15f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Prepare for the fact that the multi-key containers will no longer
inherit from the single-key ones. Refactor the code to follow
the existing.
Change-Id: I5fd4d7e33f8184c015e18e169af72e11a5e84f0d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We use the Catch2 testing framework to test Qt Testlib, which also opens
up the possibility of using it for other internal testing once it's made
available through the build system.
The test now has a --rebase mode which will write out the actual results
as new expected files. Once we add the required post-processing to the
results to remove timestamps and other testrun-specific data we can
remove the standalone python script generate_expected_output.py that
today has to be kept in sync with the test itself.
No attempt has been made to clean up the comparison-functions, but
these could all benefit from moving their logic from the comparison
to the sanitization step. This will both make the expected files
more generic, and will reduce the diff once a failure occurs, since
we're not seeing all the hunks that the comparison-functions ignored.
Change-Id: I1769d42e7958d56d1ad5da958db0e8fe3a2a3c23
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Setting the QMAKE_MANIFEST variable doesn't have
any effect for MSVC. This commit fixes that.
If the developer is setting this variable,
he/she will definitely use CONFIG-=embed_manifest_exe
or CONFIG-=embed_manifest_dll at the same time,
so I think there is no need to check this.
Change-Id: Ie32b7e0cded71efcf14bf4c0eecab5ab1944fa2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For some reason the Help target doesn't get its RC file generated
when building qttools, which leads to a build failure.
We don't quite know yet why all this is happening, but a workaround
fix seems to be to use an OBJECT library instead of an INTERFACE
library to propagate the generated RC file.
Amends 657fa0462d
Fixes: QTBUG-84155
Change-Id: I1e1c2f3b05bae2ed009020d031c6510a517c01ec
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As it was found recently CA fetcher, while building a chain with a missing
intermediary, may return the root we are already aware of (had in the "ROOT"
store). While this is in general harmless, it can be a bit surprising if
some code is analyzing the list of CA certificates after a handshake.
Pick-to: 5.15
Change-Id: I1df3b537e2a812de17e2c94ad4643cf36e7e946f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This enables the use of QChar::fromUcs4() instead of
QString::fromUcs4() in a call to putStringLiteral().
Change-Id: I6ed933cc92bfbb70ed2b168b7deeeb466bc6bfeb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The 'ch' never had to be a 32-bit variable. It only ever gets assigned
16-bit unsigned values, so make it a char16_t and thus implicitly
convertible to QChar, even when QChar(int) is being deprecated or
removed.
Change-Id: I8391c393ca860f8f73f1495d7764dacd57275ea7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
[ChangeLog][Third-Party Code] PCRE2 has been update to version
10.35.
Change-Id: I9793bdd3d25b88eea0d4479f544b297d065b5fb6
Pick-To: 5.15
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Code that's removed via QT_VERSION(6, 0, 0) check is already no
longer compiled.
Change-Id: I70865f330a6260ac2e9cf2770d599a5b6f7bb7d4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Conversions from non-char-types to QChar are going to be deprecated.
Use QChar::fromUcs2(), fromUcs4(), QLatin1Char(), or convert the
constructor argument to char16_t.
Change-Id: Ib45ebd5560aa3a2bc460037ab09773607485c6e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It seems that PCRE2_UCHAR16 is exactly ushort, even though it's
documented to be uint16_t. There's no requirement for these to be the
same type, nor for the PCRE typedef to continue to point to the same
type, so add explicit casts.
Change-Id: I89f65d29feaada84ea00688976a123364857bc58
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The old code malloc()ed a buffer to hold a copy of the data if a
substring of *this was to be inserted. Instead, use a QVarLengthArray.
Pick-to: 5.15
Change-Id: Ia3b4d7509bff2375ec0da5c890ecff2e9f7f335c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Yet Another Side Effect of not keeping iterator stability.
Although not idiomatic, the pattern
while (i != e) {
auto cur = i++;
if (cond)
erase(cur);
}
was actually correct. Move to the idiomatic erase pattern
instead (it = cont.erase(it)).
The example still has memory problems all over the place on
shutdown. At least now it doesn't crash when running.
Change-Id: I30bd2c4e2b3fa7fe4e28d4426ff3d894b9bae103
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Given that there is only one mouse (which might change some day, but
hasn't yet), there can only be one window containing the mouse,
regardless of which screen it's on. The implementation before was only
able to send enter/leave events when moving from one window to another
on the same screen; but we need the enter/leave events to be sent when
moving between two full-screen windows on two screens as well.
Also send an enter event the first time the mouse moves, to whichever
window that happens to be. A Wayland compositor that renders its own
cursor will need to know which screen is in use at the beginning.
Pick-to: 5.15
Fixes: QTBUG-83973
Task-number: QTBUG-55161
Task-number: QTBUG-79924
Change-Id: Ie6f36cd33b103955a70bac73c1485bf475c08468
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Overload uint/ushort versions with new char16_t/char32_t ones, and
[[deprecate]] the old ones. There's too much churn for doing the
replacement in one patch.
Change-Id: Ib1f90a1c46b80aa0fb1ea00ce614af49f49bd712
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Write a small range adapter that maps begin() to rbegin() and end() to
rend() of the underlying range, use it to replace indexed reverse
loops with ranged for ones.
Change-Id: I5498a23106b0432ce885e72e5e3912910f50b5c1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
More compact and isolates against decltype(size()) issues.
Had to make QXmlStreamSimpleStack iterable.
Change-Id: Icfa7b2ab09995c7a442fd8a5b2f5d6ce90120822
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Replace
if (hash.contains(x)) { // lookup #1
~~~ hash[x]; // lookup #2
with
if (auto it = hash.find(x); it != hash.end()) { // lookup
~~~ *it; // no lookup
halving the number of QHash lookups. The container is not shared, so
there's no danger of a detach when going directly to the non-const
function.
Change-Id: Ifae409f98e0be972b31a24326ad548723831fda8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Ditto fromUcs4(uint*) with fromUcs4(char32_t*).
The ushort/uint forms will be deprecated.
Change-Id: Ia4ce45ed8679951b24af13109e3e498f51fc3c89
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QIODevice::read() returns qint64, not int, and nbytesread is qint64,
too.
Pick-to: 5.15
Change-Id: I6d41c5c656336a95bb115b461282e9f247493c25
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Update the auto test accordingly, and at the same time remove
all uses of QTextStream (as they aren't required).
Change-Id: I71b7cf6a6b54ea59507f27d5d2d04cc5ae5885fc
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Get rid of the hack for the FreeFunction and instead add a proper
function pointer to clear the data to the ConverterState struct.
Change-Id: I104aae1a4381c69f1a254713ec76e1aeaa862cdc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Accessible name change events were not being relayed through UI Automation.
This caused changes in the state of combo boxes and possibly other quick
controls to be missed by UI Automation clients. This would result, for
instance, in Narrator not reading the state of a combo box when its current
index was changed with the keyboard.
Fixes: QTBUG-70621
Pick-to: 5.15
Change-Id: I16de0ff2bb0fb5227111d5347c25f442e9b0a533
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Insofar the information was just in the commit message
(00a8be85d1); add that explanation
to the code itself.
Change-Id: Ice1919c803a31918e8228091b3192728cbbc32f4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was masked by all QChar ctors being made explicit, except the char16_t one,
which was left as the only viable choice.
Change-Id: I68da90730de0a7bdcd0825b4557b8534fbda2533
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The fromUcs2() named ctor is designed to replace all the non-char
integral-type constructors of QChar which make it very hard to control
the implicit QChar conversions, which have caused a few bugs in Qt
itself. As a classical named contructor, it simply returns QChar.
The fromUcs4() named "ctor", however, needs to expand surrogate pairs,
and thus can't just return QChar. Instead, it returns a small struct
that contains one or two char16_t's, can be iterated over and be
implicitly converted to QStringView. To avoid bikeshedding the name
(FromUcs4Result, of course :), it's defined inline and thus can't be
named outside the function. This function replaces most uses of
QChar::requiresSurrogates() in QtBase.
[ChangeLog][QtCore][QChar] Added fromUcs2(), fromUcs4().
Change-Id: I803708c14001040f75cb599e33c24a3fb8d2579c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are (at least) two implementations of the low-level case-folding
algorithm, one of which (for QChar::toLower()) seems to be wrong (it
doesn't deal with special cases which expand to more than one code
point).
The algoithm hidden in QString and entangled with the QString
detaching code makes reusing the code much harder.
At the same time, the dependency of the algorithm on the unicode
tables makes exposing a non-allocating result type in the public API
hard. std::u16string would be an alternative if we can assure that all
implementations use SSO with at least four characters.
So, for the time being, leave this as internal API for use in an
upcoming QStringView::toLower() as well as case-insensitive hashing.
Change-Id: Iabb2611846f6176776aa20e634f44d8464f3305c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Comparing with <, >, <= or >= such pointers as are not pointing into
the same array is UB. A clever compiler could look at the code,
determine that the only valid execution is for it to return true, and
just always take the copy.
While that would be benign, it's not guaranteed that this would be the
outcome (it's UB, after all), and, of course, we don't want to take
the performance hit if we don't need it.
Pick-to: 5.15
Change-Id: I48cda232ff10a3c9fd4babcd7e7103a3aed126e8
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Comparing with <, >, <= or >= such pointers as are not pointing into
the same array is UB. A clever compiler could look at the code,
determine that the only valid execution is for it to return true, and
just always take the copy.
While that would be benign, it's not guaranteed that this would be the
outcome (it's UB, after all), and, of course, we don't want to take
the performance hit if we don't need it.
Fix by using std::less, which guarantees a total ordering for all
pointers.
Pick-to: 5.15
Change-Id: If07b9363b2ecd573f259e4fa972b629362061ce5
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
