... 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>
... while a parse is going on.
Fixes: QTCREATORBUG-25137
Change-Id: I02a914332ef120caee044139581e1901b4537bff
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Take care of handling file permission changes centrally.
TextDocument had its own, caching implementation of tracking the backing
file's read-only state. Move that into IDocument directly.
IDocument::reload with a permission-only change is not a very
interesting case, but every subclass needed to add handling of it.
Instead, remove TypePermission from the file-change types, and handle it
separately via the now unified checkPermissions() implementation.
IDocument::reloadBehavior already was never called with TypePermission.
Change-Id: I321d47ba6193bc878efa9bb50ba7a739fa492745
Reviewed-by: David Schulz <david.schulz@qt.io>
That is, processes run via qmake's system() function.
Fun fact disovered while implementing this: "Canceling" the loading of a
qmake project did nothing at all except making the progress bar red at
the end of the parsing procedure. Now at least we terminate the
currently running processes invoked by system(), so the parsing threads
can continue and eventually finish.
Task-number: QTCREATORBUG-24825
Task-number: QTCREATORBUG-25000
Task-number: QTCREATORBUG-25194
Change-Id: Ic92ef200d3a49bbdeff0429ae7038fe3f1935b38
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
- message(): Print to general messages and blink
- warning(), error(): create item in Issues pane
- parse error and other errors: create item in Issues pane
Task-number: QTCREATORBUG-24430
Change-Id: I6b37cef0b9e53e2207341bd179e2c60a40da9ee0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has too many side effects.
Amends fcd6384f4d.
T_SYSTEM and E_SYSTEM are now treated the same.
Fixes: QTCREATORBUG-24551
Change-Id: Ib6df2762d329f2ddc0dd66190454159d446a9ac9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
After a re-parse, the existing IDocuments need to be updated with the
new QmakePriFile object, as the old one may no longer be valid and thus
cause a crash on the next re-parse.
Amends f3bd07efd1.
Fixes: QTCREATORBUG-24683
Change-Id: Ib03d3005cb7831f1e05cb116aa3cdfe6cf5e72ad
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
