... out of SessionManager.
The idea is to later move SessionManager into the Core plugin,
which both is sensible conceptually and also prerequisite to
merge the Bookmark plugin into TextEditor plugin.
Currently, only the interface is split, as the load/save
implemetations are non-mechanical to disentangle.
Change-Id: I31631db3094ea192825a2ccaa6add6188662940b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Get rid of QFutureInterface argument from
ITestConfiguration::createOutputReader() and from
TestOutputReader c'tor.
The fine-grained progress reporting was broken anyway:
1. The assumption was that testCaseCount was meant to be
the total number of test functions executed. It didn't
include the initTestCase() and cleanupTestCase(),
while those were reported on runtime apparently
(and exceeding the max progress by 2).
2. In case of tst_qtcprocess, when the whole test was run,
the testCaseCount reported 41, while the real
number of functions was 26 (+2 = 28 for init/cleanup).
3. While the max progress was set to testCaseCount initially,
the corresponding FutureProgress rendered the progress
always in 0-100 range, what didn't match the reality.
Instead, rely on TaskTree progress, which resolution
is per test as a whole. So, when executing a series
of tests this should scale fine. In addition, the
progress advances fluently according to the expected
run time - with 10 seconds hardcoded.
The original code locations, where progress was bumped,
are left with a TODO comment for any possible future tweaks.
Like in case of result reporting, fine-grained progress
reporting may be implemented by providing additional signal,
so there is no need for QFutureInterface inside
TestOutputReader.
Change-Id: Idc11d55e3a49dac8d1788948b9a82f68199203c6
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
That's closer to the intended semantics. The "other" use in docker
will be changed to an optional<Environment> as follow-up to
keep this here mechanical.
Change-Id: I43ef9da6c9c7731b28f9d6fab6413ce9c4f428b4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
More descriptive, and later implementable without full expansion.
Change-Id: Ic3b17ea0b07273f292827a7b63e7695b4bd1cf23
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There was no proper separation of responsibilities between these
plugins. In particular, CppTools had lots of editor-related
functionality, so it's not clear why it was separated out in the first
place.
In fact, for a lot of code, it seemed quite arbitrary where it was put
(just one example: switchHeaderSource() was in CppTools, wheras
switchDeclarationDefinition() was in CppEditor).
Merging the plugins will enable us to get rid of various convoluted
pseudo-abstractions that were only introduced to keep up the artificial
separation.
Change-Id: Iafc3bce625b4794f6d4aa03df6cddc7f2d26716a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and a few unncessary namespace qualifications.
Change-Id: If1dde79a0b6b68ba8706faf038c3512f0b3e666f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Still some missing bits as some QString members had different meanings
depending on their context.
Change-Id: Ib48eab54498974a26bbd5123cbffeefee5f7e79c
Reviewed-by: hjk <hjk@qt.io>
Preparation for having code based and build system based
test items.
Task-number: QTCREATORBUG-23332
Change-Id: I4d21142d74b40b988d82c69d02f5c6633c8cebe4
Reviewed-by: David Schulz <david.schulz@qt.io>
Preparation for an additional simpler test configuration
which needs to have the same common base.
Change-Id: I1800ed5d7301f1aea99eba6ef588a204697bd569
Reviewed-by: David Schulz <david.schulz@qt.io>
If there are more than one target for a run configuration
we ended up in the first matching.
Tests may use different environments to test different things.
If the user tried to handle this by using a modified
environment for different targets failed even when the
correct target was selected.
Change-Id: Ie954c985969ffd187fe60b4ecb86aa2717d559f1
Reviewed-by: David Schulz <david.schulz@qt.io>
Do not access list items if there are none.
Amends 502ad9badb.
Fixes: QTCREATORBUG-24421
Change-Id: I2982f675bba36eac98cb116acf64472a9f415977
Reviewed-by: hjk <hjk@qt.io>
Ensure all possible project parts are taken into account
when gathering build system targets.
When having multiple possible build system targets for a
test - which may easily happen e.g. when defining tests
beside the main application inside a big top-level
CMakeLists.txt - let the user decide which one to run.
Fixes: QTCREATORBUG-24268
Change-Id: Ia7b7e4148fe8e8dab55832c435f12cc78f5c2f7a
Reviewed-by: David Schulz <david.schulz@qt.io>
... and TestConfiguration. This allows dropping code that
reconstruct framework ids and framework lookup by id.
Change-Id: I0bb1e6e135376e21f96b9fab7971aa097787e483
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A convenience wrapper for
applicationTargets().buildTargetInfo(buildKey),
the only context using the BuildTargetInfoList member.
Also, only one of the free comparison functions is ever used,
only in one place. Inline it there.
Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
* use nullptr
* override
* remove old style casts
* fix most of the code model warnings
Change-Id: Ia08e846f9326ae28ca7e7d66748e25a8b817b9b1
Reviewed-by: Xing Xiong
Reviewed-by: David Schulz <david.schulz@qt.io>
If the startup project or the current active target changes
while tests are running strange things can happen as we rely
on these both being unchanged from triggering the run.
Explicitly check for these being unchanged and cancel the
test run if necessary.
Change-Id: I506c7b1c0ca4b6ea31559556f6141fe9276d0ad0
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
The build system targets no more contain the additional
pipe character. This patch fixes some 'guessed config'
warnings.
The check for the build key can now also be done
without restriction as it is unique nowadays not only
for Qbs builds.
Change-Id: Ic4e62d678c2188d0591c618cdcc156580b40b834
Reviewed-by: David Schulz <david.schulz@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since bc698d4ce6 the build system targets / build keys are
unique on their own.
Simplify the completion of test configurations and improve
readability.
Change-Id: I258e8a35a4740dd58b1365498ca399258092e0e3
Reviewed-by: hjk <hjk@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Especially when using CMake based projects in combination with GTest
we might have lots of build targets defined inside the same
'project file'. Overwriting the already assigned content is purely
wrong. Instead handle each found build system target on its own.
Task-number: QTCREATORBUG-17882
Task-number: QTCREATORBUG-18932
Change-Id: I3297a9e1da8ae4186fd4267e3485368b1a059314
Reviewed-by: David Schulz <david.schulz@qt.io>
If we already had a correct executable we might end up using
the wrong one when trying to complete the configuration again.
So, if the former configuration already had an executable set
do not try to complete the configuration again.
Change-Id: I270be71d87b311c6a5eaad14e0d5a2de60353e5d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
There are several complex project layouts that lead to failing
to determine the correct runnable for tests.
If this happens prompt the user for the runnable to use instead
of performing wild guesses or blindly using a wrong one.
Task-number: QTCREATORBUG-17882
Task-number: QTCREATORBUG-18922
Task-number: QTCREATORBUG-18932
Change-Id: I1575f310c450e56c087f1e689d0fc7dfb0cd0bef
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
If we have not found a local executable any further processing
is not necessary as the outcome will be the same: we will not
be able to start the test runnable.
Change-Id: Iaa4bbd533ced6184148f941c1cba394f9f47554d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
If we cannot find the respective build target to execute
tests, but we only have a single build target then
we now assume that this will be the right one.
Change-Id: I0f7c3c4f371bce3a7f328e7c28dc61cadf7f6e9e
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Move used enums more central to avoid duplicating
information and unify their usages.
Change-Id: I33e9bdc11f7da16ecabf03991b5a5f550a53bdad
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Replace some members by a single one.
By using the StandardRunnable we automatically get more
information that can be used later (arguments, device).
Change-Id: Id2afb6dffc27d97da568372f6ee13c7181fc393a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This might help to figure out what is wrong if we are
not able to determine which run configuration must be
used or if this determination goes wrong.
Task-number: QTCREATORBUG-17882
Change-Id: I6f1dc573b4a8c07035fa521d056ccde890f07142
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Base the selection of the run configuration on the executable
we have gotten already from the BuildTargetInfo and take
deployment information into account.
This also reverts cce1e130 partially and avoids
stuffing unrelated information into the buildsystemtarget.
Change-Id: I3de6e910a5fd1092d428ec4afc33c4ca62daaa25
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As we are still constructing build system target to compare with
on the test runner's side instead of getting the complete
information from the run configuration we ended up using the wrong
one in several circumstances. Avoid this by using the executable
information we already got.
Task-number: QTCREATORBUG-17783
Change-Id: I40431bef228f7070109297873c472fea410dbd16
Reviewed-by: David Schulz <david.schulz@qt.io>
