Factor out backend into more generic function to easily support new
accessors.
No functional changes.
Change-Id: I715ce2842d2c63574bdf6ada0d0e32fbfd5d08fb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We try to locate the old symbol name in the generated ui header and
rename the symbol in the background.
Task-number: QTCREATORBUG-1179
Change-Id: Iaf68e3922cd728cbc87d0dc97125e34b8bdaa6be
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
... and re-use the old QtcProcess::readAllStandard* names for
a QString-returning 'decoded' version.
For now, only use that in 'full Utf8' cases, to stay bug-compatible,
the plan is, however, to employ the QTextCodecs we have already
in the channel buffers. That will be one-by-one, though.
Change-Id: Id209e0671920d4ea4197918e872f441254112d52
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When parsing remote .pro files the parsers needs to pretend it runs
on the remote device.
All internal data are now "local on the remote", so that string
manipulation in .pro files "just works", and a 'device root'
string is passed around to relevant functions which then use
it to construct FilePath::toFSPathString()-style paths that
our custom FSEngineImpl can then map to the real device.
Remote $$system() calls are intercepted by the local parser and
redirected using the usual QtcProcess mechanims.
Quite a bit of the ProParser needed adjustments, so there's some
potential for regression.
Task-number: QTCREATORBUG-28242
Task-number: QTCREATORBUG-28161
Task-number: QTCREATORBUG-28355
Change-Id: I6100e7aca4e1db35f5e9689004110aab57e2c595
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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>
This was a alias for .stringAppended(), but can be used too easily
when .pathAppended() is meant.
Change-Id: Ia3b64d39828d4074b43d87c923ce3a6a87038948
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
... by FilePath::isSameExecutable().
The only non-mechanical case is the use inside QmakeBuildSystem::testToolChain
using a build environment instead of the FilePath's device environment.
This make a difference in theory due to the use of PATHEXT in the actual
check, but I believe the case that someone creates a 'qmake.foo' and
a 'qmake.bar', adds .foo and .bar to PATHEXT and then complains that
there's a warning missing about not-matching mkspecs has zero
likelihood in reality (and will break other places in Creator anyway).
Change-Id: Id6a8d1e4dc2eb74ca81610ccb1c4ee94c6f47e12
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
When trying to jump to a symbol in a qml file the Qml Model may find
the location in a generated .qml file in the build folder.
QtCreator searches in all generated .qrc files to try and find
the source file so it can jump to it instead.
Previously not all auto-generated ".rcc" folders would be found
as only the folders of targets (executables) were searched.
Plugins or Static Libraries were not searched.
With this fix, all projects nodes are searched for the ".rcc" folder
and therefore also finds them for Dynamic / Static libraries and
plugins.
Fixes: QTCREATORBUG-27173
Change-Id: Ic51ac8fbc82c15785cbefd76787942a512ecf3db
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Neither cmake nor qmake know the full iOS compiler command line, so we
have to construct the target triple for the code model ourselves.
Fixes: QTCREATORBUG-28278
Change-Id: I6cac06f340e9388de5c86509a8df4ac00eef87cd
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>
E.g. linux-oe-g++/qmake.conf has this craziness:
QMAKE_CXX = arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a9
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security
Since there seems to be no hope for a fix, we work around it by looking
for compiler options in the alleged executable names and forwarding them
along with the flags from the actual *FLAGS variables.
Fixes: QTCREATORBUG-28201
Change-Id: Id0651677dd7b444a5f443e63d36e8dec52106af7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Stenger <christian.stenger@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>
When configuring a CMake project on the command line, CMake will
(correctly) find and use the compiler from the current developer
directory, usually somewhere in
/Applications/Xcode.app/Contents/Developer
But Qt Creator auto-detects and sets up the compiler /usr/bin/clang(++)
for desktop kits. This leads to a compiler mismatch between kits and the
imported build, and to new kits registered in Qt Creator for the import.
Since /usr/bin/clang(++) is just a thin wrapper that resolves to the
compiler in the current developer directory, resolve that in Qt Creator
with "xcrun -f <command>" too (caching the result), and include that
when comparing toolchains for importing builds.
Fixes: QTCREATORBUG-27591
Change-Id: I301e2a4e267450b488b49d0c32d4ce89001bb5ec
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The patch breaks several plugin unit tests; at the very least QtSupport,
AutoTest and ClangCodeModel.
This reverts commit 72aa77ced7.
Change-Id: Iaa7f452d0f43d0072b0bbcf8934fa0dcd6f9b240
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
qmake is a "build tool", and it is also a "query tool" when called with
parameter "-query". Qt Creator, so far, assumes that building and
querying with a Qt installation are done with one and the same tool:
qmake. This change adds the ability to register a Qt version vie either
qmake or qtpaths and still build with qmake, if that is installed (which
is not anymore mandatory from Qt 6 on).
1) Distinguish between Qt query tool and qmake build tool:
Add QtVersion::queryToolFilePath() to the existing
QtVersion::qmakeFilePath(), and use queryToolFilePath in most "query"
related code, and qmakeFilePath when building with qmake (e.g. in
QmakeProjectManager).
Also, a couple of functions and variables were renamed from *qmake* to
*queryTool* in order to express that the affected code is about
querying/managing Qt versions rather than about building with qmake.
2) Support manual Qt Version adding by qtpaths via file dialog
This change adds qtpaths to the "Add" Qt Version file picker filter.
After selection, "qtpaths -query" is executed for testing purposes. If
that fails, (e.g. because it is an older Qt version), qmake is instead
chosen, silently.
Task-number: QTCREATORBUG-22175
Task-number: QTCREATORBUG-25546
Change-Id: I4d9c1e7eec7d5ae7c5a8d2e1a1ed95addff69966
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qmake may construct QMAKE_CC and QMAKE_CXX by using paths from
environment variables that have native delimiters. That is the case with
Android (see mkspecs/android-clang/qmake.conf).
That leads to QMAKE_CC and QMAKE_CXX having mixed-style path separators,
and that is the reason to treat them as user input.
Change-Id: I1baf180c16710f4cd00ac182fa241b84ae99fa38
Reviewed-by: David Schulz <david.schulz@qt.io>
The main thread doesn't kill processes directly, but
sets just the cancel flag.
Instead of waiting infinitely long for a process to finish
we poll periodically (every 100ms) for the canceled flag
inside the thread that started the process.
Amends: a30aa4421a
Task-number: QTCREATORBUG-26333
Change-Id: I599d5c6cd69381cadc4a01c65f6a79f9a9bbd3fb
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
E.g. when the last use of the libraries was removed from .pro files.
This also makes the use more similar to the other build systems and
allows making Project::{add,remove}ProjectLanguage private.
Change-Id: Ib23d83f2fb5aab728b344c164a1331429b44e345
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
also renamed the qmlscene* qmlRuntime*
Change-Id: Ifd522e21f5ce30aaa54060fdcebee2cd8b9463c4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Do not try to reuse the QFutureInterface that is used for the parsing
process. Reusing the QFutureInterface can lead to issues. So far no
problems were triggered, but a30aa4421a
introduced a watcher that tells the qmake parser to ignore all system
calls after the future was canceled. This was somehow, sometimes
triggered on the reused QFutureInterface even though the user didn't
cancel anyhing, leading to all system calls to bail out in the
subsequent run.
Using a new QFutureInterface instance for each parsing run solves the
issue.
Amends a30aa4421a
Fixes: QTCREATORBUG-25970
Change-Id: I6836c97038c36968e93815c6121bc284edbe19bb
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Each call of CppModelManager::updateSourceFiles detaches the current
snapshot.
The extra compilers where set up and triggered individually, and
resulted in individual updateSourceFiles calls with the single result
file of the extra compiler. For Qt Creator this would lead to 200
calls in quick succession after project load, potentially leading to a
freeze of multiple seconds.
Instead of updating the result files of the extra compilers individually
after project load, integrate the update into the regular project source
file update. So we end up with only a single call of updateSourceFiles.
For this the project updater needs to trigger the extra compilers, and
wait for all to finish as well as the regular project part update,
before
triggering the parser.
Task-number: QTCREATORBUG-25783
Change-Id: I34f6df0fc0f96bcb42ee65019bee39cf49176c1f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and isSubProject.
Take the opportunity to rename them into isInQtSourceDirectory and
a isQtSubProject to make its limited scope clearer.
An open question is why this is only used for qmake projects.
Change-Id: If36f9457583eac17e149624ec46e5de10dd4a5a5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There are some internal hard asserts on that.
Change-Id: I93bbdff0c9625d42d5f9da3f12219ad90c478d5d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
