QWidget::setVisible is virtual, and called via hide() by both the
QDialog and the QWidget destructor. A dialog that becomes invisible
when getting destroyed will at most execute the QDialog override.
Subclassing QDialog and overriding setVisible() to update the state
of the native platform dialog will not work, unless we explicitly
call hide() in the respective subclass's destructor.
Since e0bb9e81ab, QDialogPrivate::setVisible is
also virtual, and gets called by QDialog::setVisible. So the clean
solution is to move the implementation of the native dialog status
update into an override of QDialogPrivate::setVisible.
Add test that verifies that the transient parent of the dialog
becomes inactive when the (native) dialog shows (and skip if that
fails), and then becomes active again when the (native) dialog is
closed through the destructor of the Q*Dialog class. The test of
QFileDialog has to be skipped on Android for the same reason as the
widgetlessNativeDialog.
Fixes: QTBUG-116277
Pick-to: 6.6 6.5
Change-Id: Ie3f93980d8653b8d933bf70aac3ef90de606f0ef
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This allows us to control whether to run this particular test in ASan
mode or with specific loggers or not. Adding the expected log output for
tst_silent for other loggers is left as an exercise to the reader.
Change-Id: Ifa1111900d6945ea8e05fffd177f1548c8c8e714
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This reverts commit f20adcde30. The
implementation had the right idea, but this is not expected to work
reliably in C++. It's jumping out of several frames without cleaning
them out properly and our ASan-based memory leak-checker has started
complaining (the next commit will move this test elsewhere).
==19313==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 258 byte(s) in 1 object(s) allocated from:
#0 0x7ffa505c8e48 in __interceptor_malloc (/usr/lib64/libasan.so.5+0x109e48)
#1 0x7ffa4f2d7ff9 (/home/qt/work/install/lib/libQt6Core.so.6+0x896ff9)
#2 0x7ffa4f2d834d in QArrayData::allocate(QArrayData**, long long, long long, long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x89734d)
#3 0x7ffa4f23b700 (/home/qt/work/install/lib/libQt6Core.so.6+0x7fa700)
#4 0x7ffa4f1f6cc8 in QString::reallocData(long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b5cc8)
#5 0x7ffa4f1f68a7 in QString::resize(long long) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b58a7)
#6 0x7ffa4f2092ff (/home/qt/work/install/lib/libQt6Core.so.6+0x7c82ff)
#7 0x7ffa4f209e09 in QString::vasprintf(char const*, __va_list_tag*) (/home/qt/work/install/lib/libQt6Core.so.6+0x7c8e09)
#8 0x7ffa4ed0d83d (/home/qt/work/install/lib/libQt6Core.so.6+0x2cc83d)
#9 0x7ffa4ed114a9 in QMessageLogger::fatal(char const*, ...) const (/home/qt/work/install/lib/libQt6Core.so.6+0x2d04a9)
#10 0x5641d2604c40 in tst_Silent::messages() /home/qt/work/qt/qtbase/tests/auto/testlib/selftests/silent/tst_silent.cpp:77
#11 0x5641d26050fb in tst_Silent::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) tests/auto/testlib/selftests/silent/silent_autogen/include/tst_silent.moc:118
The restoration of the signal handler (which QtTest now has) is also
wrong: this needed to use sigaction() instead.
Change-Id: Ifa1111900d6945ea8e05fffd177f14fbc09a1d7d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
They can (it's just very, very unusual).
Fixes: QTBUG-116695
Pick-to: 6.5 6.6
Change-Id: I2b24e1d3cad44897906efffd178178f1542e67f2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Signals are blocked explicitly, so the modelReset signal that would
normally make the view update the accessibility framework does not work.
Update accessibility explicitly.
Pick-to: 6.5 6.6
Fixes: QTBUG-114423
Change-Id: Iba6f0b9dfb258e85111326184d7899bf0570a5c1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Fix a potential nullptr access in
QNetworkReplyHttpImplPrivate::loadFromCacheIfAllowed() on accessing to
QAbstractNetworkCache::data(). It is not yet clear in what cases
cached data can be null, especially if metaData is present,
but we have user reports of such crashes.
Amends a6776de0c7
Fixes: QTBUG-116788
Pick-to: 6.2 6.5 6.6
Change-Id: I548065c6f809d9d45db6dd785c28acbdc77621e2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Nothing in those files uses QPair; and a local build finished fine without them.
Task-number: QTBUG-115841
Change-Id: I669cfecaa9129bce6b31e464826287f138b159db
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
An assert that checks in debug mode is morally equivalent to an
assumption/contract in release mode. Rechecking that an assumption is
true is pointless (it's true by definition), so the code for the case
the check fails is effectively "dead".
Right now Q_ASSERT(x) doesn't turn into Q_ASSUME(x) because some
compilers still have poor codegen (and basically emit a check, even in
release mode). With C++23's [[assume(x)]] we may reconsider that. As
soon as we do it, this code is no longer theoretically dead but
practically dead.
Refactor the code so that the check is done unconditionally, and
if it fails, we assert (in debug mode). In release, we protect users
from a broken backend (which may cause an endless loop of user code
re-requesting the same permission, so it's worth avoiding it).
Change-Id: If0e70e7d88a585ce16ec4838ba7be747652d8155
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Having a context object is the common case, so it's worth optimizing
for it. Remove the routing through a metacall event, which isn't needed,
in favor of a simple queued invokeMethod. Also, always provide a context
object when calling the slot, even if one wasn't provided by the user;
simply use the "sender" object, that is, the internal QObject that is
activating the slot. (This way we match the semantics context-less
connect() overload, which uses the sender object as a context.)
Change-Id: I72051fc48cbda5729145557f15cec4693ffde6ce
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It makes sense (in my opinion) to have the top-level CMakeLists.txt
to include and call certain commands that should be controlled by
qtbase, to avoid submodule update difficulties when we want to do
changes in qtbase that shouldn't concern the top-level file.
Create cmake/QtBaseTopLevelHelpers.cmake and move some pre-existing
code from the top-level CMakeLists.txt into separate functions that
are defined in qtbase.
This file will be included in the top-level one and said commands will
be called there.
This also prepares for qt_print_build_instructions not call
qt_internal_qt_configure_end anymore, because it will be called
by the top-level project.
Pick-to: 6.6
Change-Id: I1fe3490001cf441d742c64b2ef1f267cd4362f6a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Before this change, the dirty feature code only checked for
differences between FEATURE_foo and QT_FEATURE_foo, without taking
into account modified INPUT_foo values that might passed via the
configure script.
This led to issues in certain scenarios when reconfiguring with the
configure script.
For example configuring with -gui / -DINPUT_gui=ON and then with
-no-gui / -DINPUT_gui=OFF would fail saying
'Feature "widgets": Forcing to "ON" breaks its condition'
This happens because the widgets feature depends on gui being
available, but because INPUT_gui modifications don't trigger the dirty
feature re-eval code, we don't recompute the value of widgets.
Extract the code that takes into account the INPUT_foo variables into
a separate function, and use it both when computing feature values and
also when detecting dirty features.
This means any non-matching INPUT_foo variables will now also trigger
dirty feature checking.
Use the same function to replace the duplicate code we have to early
initialize the developer-build, no-prefix and pkg-config features.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
To be able to reconfigure Qt with modified feature values using the
configure script, and take into account INPUT_foo values, we need to
ignore FEATURE_foo values. But we can't always ignore FEATURE_foo
values, because users might want to toggle them by editing
CMakeCache.txt or using an IDE.
What we can do is tell CMake we are configuring via the configure
script, in which case we can mostly be sure that any passed
INPUT_foo values should have higher priority than pre-cached
FEATURE_foo values.
We also need to remove all the cached INPUT_foo variables after they
have been used for feature computation, so that subsequent
reconfigurations where an INPUT_foo is not passed anymore, doesn't
cause a feature to accidentally reuse the previous (stale) value.
Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring
via the configure script, and use that as a marker to make INPUT_foo
values have a higher priority.
This needs to be done centrally in qt_evaluate_feature and also in a
few more locations where we check INPUT_ values, like the developer
build and pkgconfig features.
Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached
variable, we want to remove it at the end of the configuration phase,
so that future 'cmake .' reconfigurations are not considered to be done
via configure.
To do that, we unset it right at the end of
qt_build_repo_end in a per-repo build, and in the final
qt_print_build_instructions call in a top-level build.
The latter needs a cleaner fix in follow up commits in qt5.git and
qtbase.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if Qt was configured with -developer-build, configure
would pass to CMake -DINPUT_developer_build=ON, which will ensure that
both FEATURE_developer_build and QT_FEATURE_developer_build are set to
ON.
Then if somebody tries to toggle FEATURE_developer_build to OFF in
the CMakeCache.txt and rerun cmake, the feature will bounce back to ON,
due to the code in QtSetup.cmake that doesn't take into account if
FEATURE_developer_build is already defined, and thus reset it based
on the value that is cached in INPUT_developer_build.
Change the checks for INPUT_developer_build and INPUT_no_prefix,
to take into account the defined-ness of their
FEATURE_ counterparts.
If they are defined, ignore the INPUT_ values.
This allows toggling the FEATURE_ variables and also aligns with
the INPUT_ handling behavior that we have in qt_evaluate_feature which
ignores INPUT_ values once the FEATURE_ is defined.
While this aligns the behavior with other features, there is still a
problem.
If you first configure without -developer-build,
and FEATURE_developer_build is set OFF, and then reconfigure with
-developer-build, because FEATURE_developer_build is already defined,
the INPUT_developer_build=ON is ignored.
This is a problem for other features as well and will be handled in a
follow up change.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I4f31157b0e7963e4d43e28062a585e939ceea0c1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Before this change, if a user toggled a FEATURE_foo variable, we only
recomputed the value for dependent features who's CONDITION would break
with the new value. If the CONDITION was not broken, the dependent
feature value would remain unchanged.
For example if FEATURE_developer_build was OFF, and the user
toggled it to ON, the FEATURE_private_tests value would remain OFF,
because OFF is a valid value for private_tests' CONDITION.
But we would like FEATURE_private_tests to become ON if we toggled
FEATURE_developer_build to ON.
To address this case, we need to recompute features who's dependent
feature values have changed.
The algorithm introduced by this change is:
- keep track of initial dirty features, aka track when FEATURE_foo is
different from QT_FEATURE_foo. We expect FEATURE_foo to be the
variable that a user toggles in the cache file or an IDE.
- when evaluating feature values, collect feature dependencies from
the various expressions given to options like CONDITION, AUTODETECT
- if any feature dependency is marked dirty, reset the feature value
to its auto-computed value and mark the reset feature as dirty
- repeat for all feature evaluations
Because feature evaluation is eagerly recursive, we will successfully
reset all features that need resetting.
To ensure against unforeseen breakages, allow disabling this behavior
by configuring with -DQT_NO_FEATURE_AUTO_RESET=ON
Adjust some of the messages to contain more details.
Note that the pre-existing behavior of resetting feature values when
the condition can't be satisfied, stays. For example if
FEATURE_developer_build is OFF and FEATURE_private_tests is manually
toggled to ON, it will reset to OFF
because its condition can't be satisfied (developer_build is still
OFF).
Amends 61943aefd6
[ChangeLog][Build System] The build system will now try to recompute
configure features when dependent feature values are toggled by the
user.
Pick-to: 6.6
Fixes: QTBUG-96936
Task-number: QTBUG-85962
Task-number: QTBUG-112957
Task-number: QTBUG-116209
Change-Id: Ib627f3675df8a3b08f4936cdc9c51f2d6e15f58c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It makes more sense for it to live next to the other feature code.
Pick-to: 6.6
Task-number: QTBUG-96936
Task-number: QTBUG-85962
Task-number: QTBUG-112957
Task-number: QTBUG-116209
Change-Id: I8438e6fce9deaa5e709e4b0e2e1ea4eb0600a89a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
... by using valueBypassingBindings() when accessing the properties
from the setters.
Also adjust initModel() to use the raw pointers instead of accessing
the property when comparing the value and doing all connections.
This change is safe, because initModel() is a private method that is
only called from the constructors of the class and the setter.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: I6ecde571aeed74077099c6bf8f66736ba14d29f8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The formatting of the connections in the initModel() call was confusing
and made me overlook the fact that they all were directly used to
initialize the connections array.
Indent all the nested connections, and move the closing '}' to a
separate line to make the code more readable.
This commit amends 4f4a8e75ab.
Pick-to: 6.6 6.5
Change-Id: I607e09699a3b4865cb17639ffc75f754f4400c91
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The problem does not become apparent until a QQuickWidget or QRhiWidget
using Vulkan is put into a QScrollArea and then attempted to be scrolled
vertically.
Fixes: QTBUG-116338
Pick-to: 6.6 6.5
Change-Id: I55367b51aaf2bb8d039bf5e313a0d8c3d7908327
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Doing glGenQueries every time the window (and so swapchain) is resized
is not great.
Change-Id: Ide1cf970d86dd5469b06633a3276c2130b030037
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The setter is complicated, because it reads the values of four
properties (loopCount, totalCurrentTime, currentLoop, and direction)
and modifies the values of two properties (totalCurrentTime and
currentLoop).
For the read-only properties, inroduce local variables, so that the
binding evaluation is done only once, and re-use the local variables
afterwards.
For the read-write properties, use {set}ValueBypassingBindings()
methods, because we are anyway explicitly calling notify() afterwards.
Intorduce a newCurrentLoop local variable to calculate the new value
of currentLoop, and update the actual property only once.
Use the newCurrentLoop and msecs variables instead of accessing the
actual properties when determining if we need to notify about
property changes.
The other complexity is that the setter calls a virtual
updateCurrentTime() method in the middle of the calculation.
Subclasses can override the default implementation and modify the
properties there (at least QSequentialAnimationGroup updates
totalCurrentTime property under certain conditions). Keep it in
mind and re-read the property values after the call to the virtual
method.
As a drive-by, make some pre-existing variables const.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: I0a48bcabde15333e80ea2d54e308cb9438b310e7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
In order to test the impact of migration to QASV.
Task-number: QTBUG-101707
Pick-to: 6.6 6.5 6.2
Change-Id: I17f84ca98fc87d89bb4cd6ad98c8a12aecd315ee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The integration of QTBUG-113813 has failed because at the moment there
is no network information backend for QNX. Implement a simple dummy
backend to handle these cases.
Task-number: QTBUG-113813
Change-Id: Id6fa3e590c43b0125d82e8680733e30788d9894e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QHostInfo's lookup can notify a slot specified either via the
string-based SLOT or via PMF/function objects. In the first case,
an actual connection is established and a signal is emitted carrying the
result object.
In the PMF case, QHostInfo does not establish a connection and calls
the slot object "directly" (using some private QObject APIs).
The implementation was (and still somehow is) quite convoluted: the
index of the QHostInfoResult signal to be emitted was looked up, and
used to create a metacall event. However the metacall event was also
intercepted in an override of event(), and from there the slot was
called.
But we don't need to look the signal index up at all to do that, since
we are actually never emitting the signal! This can be done with a
custom event.
... but I'm not doing that as that's reinventing the wheel. Instead, I'm
using invokeMethod to call a private function of QHostInfoResult, and
from there we can invoke the slot object. This allows us to get rid of
the signal index lookup, remove the manual metacall event handling, and
the copy() kludge for SlotObjUniquePtr.
Change-Id: I2193acdad57788efd5250bd29f7a1c7505eed2f1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The 3-arg QObject::connect() overload (the "contextless" one) simply
forwards to the 4-arg overload, using the sender object as both
the sender and the receiver/context.
QHostInfo does not use connect() directly in order to emit notifications
that a lookup is finished. Instead, it uses some of QObject private
plumbing. When handling a lookup request that specifies a function
to call when done, but no context object, QHostInfo passes nullptr
as context/receiver.
Change QHostInfoResult's behavior to always have a "receiver": in case
the caller didn't specify one, use `this` (= the sender).
As a drive-by, this allows to streamline some code.
Change-Id: Ic2e63ac18ba36269036950b6f6b7fecea51d0c99
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
"GPL-2.0" as a SPDX identifier is deprecated in SPDX 3. Use
the more explicit GPL-2.0-only instead.
Pick-to: 6.2 6.5 6.6
Change-Id: Ie543135ad1d73205f7a94db140189f5132098ea2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
GPL-2.0 SPDX identifier is deprecated. Use the more explicit
GPL-2.0-only instead. Also, in SPDX expressions AND and OR
need to be all uppercase.
Pick-to: 6.2 6.5 6.6
Change-Id: I0875cf3b9b2020f69e3318d5ff314988a3992409
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Running the BenchmarkDemoQt6 application features a massive
startup time, followed by running out of memory (GPU-side,
assuming a discreet adapter), which is then remedied by the
system with heavy swapping. This is due to creating 8+ GB
of staging data.
While there are doubts about the application itself (seems there
is an upload for each Quick 3D Texture per material per model,
even though the texture itself is the same?), there is no reason
for the D3D12 backend to use so much more memory compared with
other backends.
That is now ensured by only creating a staging area for the data
(taking the 256-aligned row pitch requirement into account), not
simply using the subresource (i.e. the whole image) size. This is
equivalent to what e.g. the Vulkan backend does.
Pick-to: 6.6
Fixes: QTBUG-116729
Change-Id: I1b5083c6b859ec0736cd9fd792cba8236aeba6e3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
QVulkanFunctions and QVulkanDeviceFunctions now also support Vulkan 1.3.
Fixes: QTBUG-116465
Change-Id: I74f6188330dec1b776b4c6db423b9152ea71d1c3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Add a full stop to the briefs to clear the following qdoc warnings:
* multistreamclient.qdoc: '\brief' statement does not end with
a full stop.
* multistreamserver.qdoc: '\brief' statement does not end with
a full stop.
Change-Id: If0e58bc100a595f3ee00c79c31ac19f8d9ee3ad9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Make a local variable more local, set a variable only once its new
value is known to be valid.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: Ib6aa16e8c834f89c6ccc0715f20b0e5f0a7f3b6d
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
The serialization converter example's text converter's loadFile() can
be made tidier by making the conditions within its loop into a chain.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: Ic82355eab7380a0c671b3805ca140958bb1c5af5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
Add a change-of-zone manual test, based on a bug-report by Felix
Kälberer. This failed: debugging revealed that MS's mktime() doesn't
pick up a change to system zone.
Fixes: QTBUG-83881
Change-Id: I9b86398ef870627a059e269f85a0f5d9d9de284b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
After the v43 update landed, a bug surfaced that was fixed by it, so
it has been picked back to 6.6, in which it has landed before 6.6.0
branched. Consequently the new enum members are in fact [since 6.6],
not [since 6.7], so update the documentation to reflect reality.
(They may also be in 6.5.3, subject to ongoing debate, but they were
not in 6.5.0 so are not [since 6.5], even if 6.5's branch does end up
describing them as [since 6.5.3].)
Pick-to: 6.6
Change-Id: Ida938fc3e3575d6e45d61449123464ebb5b6638c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test case is an incomplete version of the test that will be added to
verify the fix for the referenced bug report. The test crashes already
when showing the dialog without this fix.
Task-number: QTBUG-116277
Pick-to: 6.6 6.5 6.2
Change-Id: I969a723157f6453b78bafae5cb24a6b37b1eea50
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The only user already has its own cache of transformed copy of acceptedEncoding list since 43d15dd572
Change-Id: I485b41555f327c6ff39dd48347240a725f00e09b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It was added in 5.12 and we've had a few upates since then.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: Iacb5368d4baa7d25f981bb0b8bd8d68b5461e17d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Marc disagreed with clang-format on some, which are thus excluded.
Pick-to: 6.6 6.5
Task-number: QTBUG-111228
Change-Id: I1402274635dba866a8160a68211874cb11dcfa61
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Hide the overload that doesn't take a context object.
Change-Id: Ibf8a46ad514b00be855be6fd7c72d6464881bb25
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since a non-null `member` implies a non-null `receiver`, streamline
the redundant check(s). While at it, introduce a simple boolean that
conveys the meaning of what we're checking for.
Change-Id: Ib9be162075771de74b1a6bc4426008b7c194df3a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If `member` is set it means that the caller wants us to connect
to a slot using string-based connections. That means `receiver`
must be non-null as well. Check for it.
Change-Id: I6b3542855147e95fecbf4c645b556c2047a1ed69
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
