In main.cpp, the loop is over a local variable which would be const
were it not for the multi-step initialization that I didn't want to
change. The loop body clearly doesn't modify the container, so port to
ranged for loop with std::as_const().
In printvolumes.cpp, the loop _does_ invoke unknown code (through the
function pointer passed as the second argument), but, as could be
expected, the two users of the function don't pass functions that know
about `volumes`:
- in the tst_QStorageInfo auto-test, an rvalue `volumes` is passed,
so we don't need to analyze the qInfoPrinter function passed there,
as it cannot possibly reference the temporary
- and in main.cpp of the manual test, we just pass printf (which is
technically UB (taking the address of a standard library function),
but I don't care right now).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ibcd10a0e0b3229d8f2a1d98545d8fa6d473a0f75
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Most of these are of trivial kind (loops over const locals).
The one that isn't, in cleanupTestCase(), is, however, also simple:
it's a loop over a local, too, but it would be too much churn to
change the initialization to make the container const, and the loop
body clearly doesn't modify the container, so just go with the
std::as_const() pattern here.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I188a78ea67a63be2d50a81fea431e5ea9f2783cb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Those are "public-ish" and exported functions (qstringalgorithms.h), so
one wouldn't expect that they get inlined most of the time. But they can
be inlined by other code inside qstring.cpp and if QtCore is compiled
with LTO.
More importantly, we want the compiler to inline qustrXXX_avx2() into
it, instead of tail-calling into qustrXXX_avx2(). This may seem like a
no-op but has one very important difference: backtraces will point to an
exported, function instead of an internal symbol. This will then allow
us to create valgrind suppressions.
Before unstripped:
==12492== Invalid read of size 32
==12492== at 0x53142EE: qustrchr_avx2(QStringView, char16_t) [clone .lto_priv.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x54A7AE6: QString::indexOf(QChar, long long, Qt::CaseSensitivity) const [clone .constprop.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218EC4: treatAsAbsolute(QString const&) (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Before, stripped:
==19477== Invalid read of size 32
==19477== at 0x5314395: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x54A7AE6: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218EC4: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
After:
==19692== Invalid read of size 32
==19692== at 0x53143C5: QtPrivate::qustrchr(QStringView, char16_t) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x54ABA46: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x5218824: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x521891A: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== Address 0x741919e is 2 bytes before a block of size 32 alloc'd
==19692== at 0x4843794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==19692== by 0x54A8A84: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x531EB1C: QString::fromLatin1(QByteArrayView) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Recommended suppressions:
{
qustrchr_avx2
Memcheck:Addr32
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
{
qustrchr_avx2-with-debuginfo
Memcheck:Addr32
fun:UnknownInlinedFun
fun:UnknownInlinedFun
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
Change-Id: Ib84fc618ac204205bf7afffd1772b1d87343dfd0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
I'd previously understood CLDR's minimumGroupingDigits to mean the
most significant group must have that many digits. It turns out to
mean only that the first grouping separator doesn't get added unless
the more significant group has this many. Once we have one separator,
more can be added that do isolate a single digit.
In the process, I discover some of the prior arithmetic is incorrect;
it is now fixed. Added some basic testing, amended some existing
tests. In the process, fixed naming of some double validator tests.
Pick-to: 6.6 6.5
Fixes: QTBUG-115740
Change-Id: Ia6ce011ba72e72428b015ca22b97d815ebf751b2
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
This source file is included in four other test projects, so it makes
more sense to port it away from Q_FOREACH than to white-list it
everywhere it's used.
The change in ModelMoveCommand::doCommand() is trivial. I only dropped
the pointless top-level const of the loop variable as a drive-by.
The change regarding `parents` in ModelChangeChildrenLayoutsCommand's
doCommand() is also trivial, I just ported to braced initialization to
get the QList to be const. We're forced by the Qt API
(layoutChanged()) to use a QList here, therefore no array.
Ibid., the change regarding `persistent` is simple. The container
cannot be marked as const without a lot of churn to its initialization
(applying IILE, basically), but other than that, it's a local
variable, and the loop body clearly doesn't modify it.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I7a0e85804626a3cc612921b49e72e4b9f30b676d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ib89d07fb751e3905a230ee5641e2e509e9415bed
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There was a gap in its numbering, and the quick brown fix could do
with some competition.
Change-Id: I1283bbb6ba321ae2b65b4459327f2428a45f85cc
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This one isn't trivial, but straight-forward: the only place the
container is modified is in fill(). Like the setOpaqueChildren()
function, this is only called from top-level test functions, and, in
particular, not from event handlers (setAttribute() sends events).
That fill() doesn't clear() the container, even though the single
UpdateWidget instance is being reused across test functions, looks
wrong, but doesn't invalidate this analysis.
Task-number: QTBUG-115803
Change-Id: I284a19da2fe476278986c61810dd334fc73034b0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The Q_FOREACH is in a header, so we need to port away from it,
otherwise it makes any TU that includes it (in PCH builds: all)
incompatible with QT_NO_FOREACH.
This is a trivial case of marking the local constructor const, but go
a step further and replace the QList with a C array ("never use a
dynamically-sized container for statically-sized data"). Both
consumers of the container (after s/foreach/for/) can deal with array.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I142e438dcf2d785bb34022a3fb1ff46b8eaa0edd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Prevents using the channel after it was destroyed.
Change-Id: I5d65fcde0d451dd8ce2c56f403e0bd1f41510382
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
This is more readable and at the same time helps to eradicate some
more Q_FOREACH uses for an eventual global QT_NO_FOREACH for all Qt
sources (QTBUG-115796).
Task-number: QTBUG-115803
Change-Id: I9cbe76bee8a6306fab0c0bc94cd874405ca825ba
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I40773a0397b83cce0c803967ee3fd7ae274933d3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ifef42704c4f695a8fb05ea5d9b3e095af3f35171
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Iecfc037c8bbfc0b3196ed0c65f680768a8d2353a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The density of Q_FOREACH uses is high here, too high for this author
to tackle in a short amount of time. But they're concentrated in just
a few TUs, so pick a different strategy:
Mark the whole plugin with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. Since the TUs are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too). I'm aware that Objective-C/C++ files are
currently probably implicitly NO_PCH_SOURCES, but don't rely on that.
Task-number: QTBUG-115839
Change-Id: If451501f3cb7cc3a182854a94bc5d27c907f6161
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QList rather pointlessly has a startsWith() function, which means this
code compiled. But the code makes no sense: it tests the same
condition over and over again, so I'm assuming that it should be
path.startsWith() and not path_s_.startsWith().
Amends 3f56950862, but that just
imported the code from qttools. I didn't check whether the bug was
present there, already.
Pick-to: 6.6 6.5
Change-Id: I98a4bbfe0400700655a5c2137f7a976a835a8d28
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since we enabled QT_USE_QSTRINGBUILDER by default for all plugins
it doesn't make sense to add this definition explicitly.
Change-Id: I22ad0b1fb567e12a842df4299231a5697ab9216d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Fixes
(qdoc) warning: Undocumented parameter 'enable' in QSqlQuery::enablePositionalBinding()
Amends the documentation introduced in e532933a2a
Change-Id: I638cf7e1dc1c9af911f6ca52bc27e6072fae1035
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The build fix applied to the 2.13.0 update has also been applied to
this update.
Pick-to: 6.6 6.5 5.15
Fixes: QTBUG-115340
Change-Id: I970b560948af3472b222690019a85a79c537b7d9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
These classes are not exported, so we don't run into duplicate vtables
here, but the header is included in a few TUs other than qhostinfo.cpp
(all, when building with PCH), so make sure we compile dtors only once.
Pick-to: 6.6 6.5
Change-Id: I51f6a6d27fc084ad469f82dc7aef3327bdd9a906
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Upstream change: https://github.com/intel/tinycbor/pull/238
Says it in the upstream commit message:
> Unfortunately, the container's initialization code doesn't exactly
> lend itself to making the container const (not even IILE
> (Immediately-Invoked Lambda Expression) would help here, due to the
> interdependency with len), so the idiomatic solution would be to use
> std::as_const()/qAsConst().
>
> The former is available from C++17, which we don't require, yet, and
> the latter is not available under QT_NO_AS_CONST (the default for Qt
> these days), so grab the nettle and implement a t17::as_const() that
> switches between a manual implementation of std::as_const and the
> real thing, depending on __cpp_lib_as_const. The t17 here mimicks
> the qNN (q20::remove_cvref_t/q23::forward_like/etc) mechanism used
> in Qt itself for backports, with s/q/t/ because ... _T_inyCbor.
>
> The t17 implementation is local to tst_encoder.cpp, but can easily
> be extracted into a separate header once more users emerge.
Task-number: QTBUG-115839
Change-Id: I200ae6abbb6173fa9d4b9964be66501c2145f066
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
These are all trivial: all are over (already or newly-made) const
local variables, albeit sometimes at the cost of an extra scope
(can't, yet, use C++20 ranged for loops with initializer).
In resizeMaximizedChildWindows(), decided to leave the container
construction as-is and use std::as_const instead (applying IILE to
make the container const would be too much churn).
In setViewMode(), removed a pointless clear() that prevented the
container from being marked const. There are no references to the
container following the clear(), and the container does not hold smart
pointers, so the clear() cannot have had non-trivial side-effects.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I00ce9c12ab696de30229f3605c16313af7eafffc
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The single use of Q_FOREACH in this test is safe to port 1:1 to a
ranged for-loop, since we're in a constructor, and the loop body only
calls member functions of data members (incl. the base class), so we
cannot possibly modify the container passed in as a constructor
argument: any connections or event processing that could re-enter our
caller hasn't been set up, yet.
Task-number: QTBUG-115803
Change-Id: I7095aef1edddbda0d1b0c471192b18acd6fd1793
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These are all simple: QObject::children() returns a reference-to-const
QList, so we can leave the calls in the for loop (no detach()ing).
The loop bodies also clearly don't modify the list of the QObject
children (they're just QVERIFYs).
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I9c5dcb2aefc433a1dead55dab669e645b6906963
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is iterating over data member containers that are otherwise only
touched in the constructor of the same object. Luckily, the
initialization of these containers does not require *this, so use
NSDMI and mark the containers const, proving they can never be
modified and thus the protective copy of Q_FOREACH isn't required. Now
that we got rid of Q_FOREACH, we can and do make them arrays for extra
measure ("never use dynamically-sized containers for statically-sized
data").
Unfortunately, C++ neither allows us to use "flexible array
members" nor AAA in NSDMI, so grab the nettle and supply the array
size manually (ever so slightly violating DRY, but the compiler will
complain if we get it wrong).
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: Ibb2ce48b6dcaf2e9d3d1a625602f3865d280c7c6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is iterating over a data member container that's otherwise only
touched in the constructor of the same object. The only reason why
it's not a const is that the initialization from QWizard::addPage()
makes that very cumbersome. So port to a ranged for-loop and apply
std::as_const().
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I033e3725df95b29a8ef295c4e74d746d83234835
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is iterating over the keys() of a member container we've just
filled in the same function. The loop body clearly doesn't modify the
container being iterated over. Port to the future-proof ranged
for-loop over asKeyValueRange(), using the _-in-SB pattern Christian
Ehrlicher showed me to indicate we're not interested in the value.
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I3d86a1de9ea460b7d57fa421ea76e41d2c122f43
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is safe to port to a ranged for loop, as it's iterating over a
private member container that is not modified under iteration
(WizardPage::shown() is just returning a boolean member).
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I50891e4b7509bd64399a128a5ee47d7795374f8e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This function is called only from one test function. Mark the
function's argument as const in the caller, bringing this use into the
const-local category, which is implicitly safe to port 1:1 to
ranged-for.
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I9145c1ae2aed5ab3cafc4947dc3eaaf9a27c6a04
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The former implies the latter, so it makes little sense to treat them
differently. Even if some types of targets are (currently) never
compiled with PCH, users of qt_internal_all_x() shouldn't need to know
such details.
Pick-to: 6.6 6.5
Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Fix typo so tst_qfuture on platforms without exceptions can be build
correctly.
Change-Id: I32c12effdda13da9c8669bfddd362acc1c8a14c7
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
For the child windows we have to use showNormal() explicitly,
as the default window state logic of platforms like iOS does
not have access to the QWindow, only to its flags, and we
can not use Qt::SubWindow as a proxy for being a child window,
as that's a window flag meant to be used for MDI sub windows.
Pick-to: 6.6
Change-Id: I2b5e669f6180ffdcb75479dece38ae5e5430aef6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
QPaintDeviceWindowPrivate::markWindowAsDirty() is used to signal that
the entire window needs repaint, for example when the window is being
resized. If multiple resize events come in before we have a chance to
redraw the window, we'll end up redrawing the window based on the
window's current size and exposed region, as we should, but we'll
still have a dirty region, because we didn't redraw the window at
any of its old (larger) sizes. Resetting the dirty region instead
of appending to it should be enough.
Pick-to: 6.6 6.5
Change-Id: I37443cc1044779f847348a2303a6cebc1a8f3bcb
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
This is the result of running util/normalize. In this second patch,
the tool replaces QPair with std::pair. This is a bit surprising, and
suggests we should replace all QPair with std::pair in our headers
soon.
Pick-to: 6.6
Change-Id: Iea0a2fb460a5da66fb534b3787c97d8300a04ca9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Ran the script, no new IDs to add. Revised tests of Central Standard
Time: America/Ojinaga has joined Matamoros for it, in Mexico.
Pick-to: 6.6 6.5
Fixes: QTBUG-115732
Task-number: QTBUG-111550
Change-Id: I9b41d8c0156b9fbe3961dbe9a35d55493fc55501
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Unifies code paths that end up closing and releasing the window.
Pick-to: 6.6
Change-Id: Ie041079a22bbae0912df0406291c8146f02d0cd7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Same implementation as for macOS.
[ChangeLog][iOS] QWindow::setMask() is now supported for masking the
rendering and touch input of child windows.
Pick-to: 6.6
Change-Id: I2f9429f0f8fa278fdd8edc15c7b242c7c6bc0ff0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
These three private methods were introduced in
4e60681c87 together with the QJniObject
class.
Digging through the whole git log for the qjniobject.h header shows
that the functions were never used. Not in template or inline methods,
and not even in the out-of-line methods.
Considering all the above, removing these methods would not cause BiC
or SiC issues, so just do it.
Pick-to: 6.6
Change-Id: Iaeeefbc2f1002e9413fd16651abd71381362a536
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
The only noteworthy point here is that, in order to mark it as const,
I had to move a container definition to the more narrow scope in which
it was actually initialized. There are no references to the container
outside the narrow scope that would require it to be defined in the
larger scope.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I20890f48a48ca662679f55fa5db759419d4db8c5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: Idd6e65065ee27c2d29ce1b49607aadb2eaf5e15d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Example got removed to tesets/manual in
8937169c19
Pick-to: 6.5 6.6
Change-Id: Ica1470b6b478f49e318ea51f244c599cd12bf5a3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's a free function, because a) it rhymes with move(ptr) and, of
course, SlotObjUniquePtr being a std::unique_ptr, b) we can't add
member functions to it (and no, inheriting from a type whose dtor is
neither protected nor virtual is nothing you will catch yours truly
doing).
Pick-to: 6.6 6.5
Change-Id: I2026126857a7bba204d683bad118e8a2c5cb2924
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Drops the direct deref'ing.
Pick-to: 6.6 6.5
Change-Id: I9f159244d50572659fa8e9cabfbef47e769ac54e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
