feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity
Files
6d7e5eb8d17194b124c8986d670ff96fda96f0f3
qt-creator/src/plugins/cpptools/cppprojectinfogenerator.cpp

245 lines
9.3 KiB
C++
Raw Normal View History

CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
/****************************************************************************
**
** Copyright (C) 2017 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of Qt Creator.
**
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3 as published by the Free Software
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
** included in the packaging of this file. Please review the following
** information to ensure the GNU General Public License requirements will
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
**
****************************************************************************/
#include "cppprojectinfogenerator.h"
#include "cppprojectfilecategorizer.h"
#include <projectexplorer/headerpath.h>
Plugins: Add compilation database plugin Introduce compilation database project support. Pass the arguments list for each file directly to ClangCodeModel via extraCodeModelFlags therefore introduce a dependency from the ClangCodeModel plugin. Change-Id: Iea5760d379de1ea246382dce56de0adf7ab5673d Task-number: QTCREATORBUG-21115 Reviewed-by: Marco Bubke <marco.bubke@qt.io>
2018-08-13 11:15:27 +02:00
#include <projectexplorer/projectexplorerconstants.h>
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
#include <projectexplorer/taskhub.h>
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
Toolchains: Detect unspecified language version We checked the command line from the project manager for "-std=X" and friends to figure out the language version to use. However, if such a flag was not provided, we assumed the latest version we support. This could conflict with the actual version of the compiler and its predefined macros. Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the predefined macros of the toolchain. The MSVC compiler is an exception to this, as it does not seem to properly set the value - check for _MSVC_LANG if possible, otherwise simply assume some versions as before. While at it, add also support for C17/C18 and the upcoming C++2a. Task-number: QTCREATORBUG-20884 Task-number: QTCREATORBUG-21188 Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-09-27 10:18:44 +02:00
#include <utils/qtcassert.h>
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
#include <QTimer>
CppTools: De-duplicate list of include paths It makes more sense to handle this centrally than in all the build system plugins. Fixes: QTCREATORBUG-24515 Change-Id: I1c0f815d44135bcfb76ce51c67b6494a50e1de48 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2020-09-07 13:56:12 +02:00
#include <set>
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
using namespace ProjectExplorer;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
namespace CppTools {
namespace Internal {
Fix CppProjectUpdater cancelAndWaitForFinished The code was pushing an additional QFutureInterface through the whole chain of functions, which was used for canceling. But since it was never started (and never finished, and never used for reporting results), calling waitForFinshed on it never had any effect with Qt5 and locks up with Qt6. Instead of using a separate QFutureInterface, use the actual QFuture that is available and intended for it. Fixes: QTCREATORBUG-24902 Change-Id: I5a49bcecc9cf70fbffa93aee4293004f9369df58 Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2020-11-10 17:55:54 +01:00
ProjectInfoGenerator::ProjectInfoGenerator(const QFutureInterface<ProjectInfo> &futureInterface,
const ProjectUpdateInfo &projectUpdateInfo)
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
: m_futureInterface(futureInterface)
, m_projectUpdateInfo(projectUpdateInfo)
{
}
ProjectInfo ProjectInfoGenerator::generate()
{
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
ProjectInfo projectInfo(m_projectUpdateInfo.project);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
for (const RawProjectPart &rpp : m_projectUpdateInfo.rawProjectParts) {
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
if (m_futureInterface.isCanceled())
return ProjectInfo();
Fix clang warnings about copies in range-for constructs Change-Id: If50553964483626e72a816b1d23fa81b45ed9ca7 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2020-06-15 13:40:39 +02:00
for (const ProjectPart::Ptr &part : createProjectParts(rpp))
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
projectInfo.appendProjectPart(part);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
static const auto showWarning = [](const QString &message) {
QTimer::singleShot(0, TaskHub::instance(), [message] {
TaskHub::addTask(BuildSystemTask(Task::Warning, message));
});
};
if (m_cToolchainMissing) {
showWarning(QCoreApplication::translate("CppTools",
"The project contains C source files, but the currently active kit "
"has no C compiler. The code model will not be fully functional."));
}
if (m_cxxToolchainMissing) {
showWarning(QCoreApplication::translate("CppTools",
"The project contains C++ source files, but the currently active kit "
"has no C++ compiler. The code model will not be fully functional."));
}
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
return projectInfo;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools: Move RawProjectPart to ProjectExplorer Doesn't have any dependencies into CppTools anymore, therefore moving it reduces the dependencies of the project managers to CppTools as well. Change-Id: Ibe728abe59eb88a8877943dca1f48a85163e27ac Reviewed-by: hjk <hjk@qt.io>
2019-08-28 18:22:45 +02:00
static ProjectPart::Ptr projectPartFromRawProjectPart(
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
const RawProjectPart &rawProjectPart, Project *project)
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
{
ProjectPart::Ptr part(new ProjectPart);
CppTools: Fix setting ProjectPart::project This was forgotten in commit 8c90998fff6ec3cf85ad87b56175e86b6f0a93d0 CppTools/ProjectManagers: Reduce ui blocking when loading projects Change-Id: I5c3a8a4015dd3b4389a21a80367a9eac7ebd95fd Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-02-21 12:26:04 +01:00
part->project = project;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
part->projectFile = rawProjectPart.projectFile;
part->projectConfigFile = rawProjectPart.projectConfigFile;
ProjectPart: Allow for line/column information in project file Keep this information separate so that plugins using the information do not need to start parsing the project file. Change-Id: Ibecf431de1b12bbe820c6f8f9c986cffeb4972d2 Reviewed-by: Tim Jenssen <tim.jenssen@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-02-27 14:02:38 +01:00
part->projectFileLine = rawProjectPart.projectFileLine;
part->projectFileColumn = rawProjectPart.projectFileColumn;
ProjectPart: Add callGroupId Do not rely on the projectfile being unique anymore. Change-Id: I52e63b3ac8aeca43ef70af1d59d1d8612bd3540e Reviewed-by: Tim Jenssen <tim.jenssen@qt.io> Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-02-27 14:37:41 +01:00
part->callGroupId = rawProjectPart.callGroupId;
CppTools: Add target information to ProjectPart This is important to be able to map sources to actual things that are going to be built. Change-Id: I1aef940767d60192642ed79a1703cff8dfdad9e1 Reviewed-by: Tim Jenssen <tim.jenssen@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-02-27 14:46:45 +01:00
part->buildSystemTarget = rawProjectPart.buildSystemTarget;
CppTools: Add target type information to project part Let project managers store information whether a project part belongs to an executable or a library and use this information inside the AutoTest plugin. This information will help to determine which targets are relevant for the execution of tests. Change-Id: I93b42797bf55225425398dc83aecea3c99eea290 Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-08-29 12:11:27 +02:00
part->buildTargetType = rawProjectPart.buildTargetType;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
part->qtVersion = rawProjectPart.qtVersion;
Convert macros from plain QByteArray to a vector of structs The old code model expected the macros as C++ formatted text ("#define Foo 42) but newer targets like the Clang codemodel expect key value arguments like "-DFoo=42". So instead of parsing the text again and again we use an abstract data description. Task-number: QTCREATORBUG-17915 Change-Id: I0179fd13c48a581e91ee79bba9d42d501c26f19f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-07 15:00:38 +01:00
part->projectMacros = rawProjectPart.projectMacros;
CppTools: Fix initial macro parsing for generic project The extra macros in the config files are being read in CppModelManager::internalDefinedMacros(), but they also affect the language features in ProjectPart::updateLanguageFeatures(). Task-number: QTCREATORBUG-1478 Change-Id: Ic197b0b7d4cc6e6a74637da0c710b0630daae25c Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-11-23 17:21:35 +02:00
if (!part->projectConfigFile.isEmpty())
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
part->projectMacros += Macro::toMacros(ProjectPart::readProjectConfigFile(part));
CppTools: De-duplicate list of include paths It makes more sense to handle this centrally than in all the build system plugins. Fixes: QTCREATORBUG-24515 Change-Id: I1c0f815d44135bcfb76ce51c67b6494a50e1de48 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2020-09-07 13:56:12 +02:00
// Prevent duplicate include paths.
std::set<QString> seenPaths;
for (const HeaderPath &p : qAsConst(rawProjectPart.headerPaths)) {
const QString cleanPath = QDir::cleanPath(p.path);
if (seenPaths.insert(cleanPath).second)
part->headerPaths << HeaderPath(cleanPath, p.type);
}
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
part->precompiledHeaders = rawProjectPart.precompiledHeaders;
part->selectedForBuilding = rawProjectPart.selectedForBuilding;
return part;
}
Fix clang warnings about copies in range-for constructs Change-Id: If50553964483626e72a816b1d23fa81b45ed9ca7 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2020-06-15 13:40:39 +02:00
const QVector<ProjectPart::Ptr> ProjectInfoGenerator::createProjectParts(
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
const RawProjectPart &rawProjectPart)
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
{
Utils: Move C++ language details from ProjectExplorer to Utils We want to use them in the backend processes too so it's nice to share them in Utils. A concrete size was added too because they should be serialized. Change-Id: Id5eb8f46643d5159f034fc9559f68a08d7e5847a Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-01-09 18:31:20 +01:00
using Utils::LanguageExtension;
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
QVector<ProjectPart::Ptr> result;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
ProjectFileCategorizer cat(rawProjectPart.displayName,
rawProjectPart.files,
CppTools: Remove dependency of RawProjectPart to ProjectFile The feature to category files to ProjectFiles was used by the qmake project manager to specify if the file is "active", and by the Qbs project manager to avoid unnecessary MIME type checking. Make these two different use-cases explicit in the API. Change-Id: Ia5a7da37f100149366fc75060fe04687e15f2bd3 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-08-28 12:23:37 +02:00
rawProjectPart.fileIsActive);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
CppTools: Ensure that parse contexts are backed up by a toolchain Otherwise empty parse contexts (e.g. not having any include paths...) will be created that are not useful. Fixes: QTCREATORBUG-22421 Change-Id: I5c9172aee38503d8b48762416e17e7047679bf2e Reviewed-by: Cristian Adam <cristian.adam@gmail.com> Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-09 10:24:57 +02:00
if (!cat.hasParts())
return result;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
CppTools: Ensure that parse contexts are backed up by a toolchain Otherwise empty parse contexts (e.g. not having any include paths...) will be created that are not useful. Fixes: QTCREATORBUG-22421 Change-Id: I5c9172aee38503d8b48762416e17e7047679bf2e Reviewed-by: Cristian Adam <cristian.adam@gmail.com> Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-09 10:24:57 +02:00
const ProjectPart::Ptr part = projectPartFromRawProjectPart(rawProjectPart,
m_projectUpdateInfo.project);
if (m_projectUpdateInfo.cxxToolChain) {
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
if (cat.hasCxxSources()) {
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
result << createProjectPart(rawProjectPart,
part,
cat.cxxSources(),
cat.partName("C++"),
CppTools: Remove enum duplication Change-Id: I2eb452780c21f8d30034bcfbb3266fc8daa10802 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 10:54:27 +02:00
Language::Cxx,
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
LanguageExtension::None);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
if (cat.hasObjcxxSources()) {
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
result << createProjectPart(rawProjectPart,
part,
cat.objcxxSources(),
cat.partName("Obj-C++"),
CppTools: Remove enum duplication Change-Id: I2eb452780c21f8d30034bcfbb3266fc8daa10802 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 10:54:27 +02:00
Language::Cxx,
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
LanguageExtension::ObjectiveC);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
} else if (cat.hasCxxSources() || cat.hasObjcxxSources()) {
m_cxxToolchainMissing = true;
CppTools: Ensure that parse contexts are backed up by a toolchain Otherwise empty parse contexts (e.g. not having any include paths...) will be created that are not useful. Fixes: QTCREATORBUG-22421 Change-Id: I5c9172aee38503d8b48762416e17e7047679bf2e Reviewed-by: Cristian Adam <cristian.adam@gmail.com> Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-09 10:24:57 +02:00
}
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
CppTools: Ensure that parse contexts are backed up by a toolchain Otherwise empty parse contexts (e.g. not having any include paths...) will be created that are not useful. Fixes: QTCREATORBUG-22421 Change-Id: I5c9172aee38503d8b48762416e17e7047679bf2e Reviewed-by: Cristian Adam <cristian.adam@gmail.com> Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-09 10:24:57 +02:00
if (m_projectUpdateInfo.cToolChain) {
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
if (cat.hasCSources()) {
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
result << createProjectPart(rawProjectPart,
part,
cat.cSources(),
cat.partName("C"),
Toolchains: Detect unspecified language version We checked the command line from the project manager for "-std=X" and friends to figure out the language version to use. However, if such a flag was not provided, we assumed the latest version we support. This could conflict with the actual version of the compiler and its predefined macros. Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the predefined macros of the toolchain. The MSVC compiler is an exception to this, as it does not seem to properly set the value - check for _MSVC_LANG if possible, otherwise simply assume some versions as before. While at it, add also support for C17/C18 and the upcoming C++2a. Task-number: QTCREATORBUG-20884 Task-number: QTCREATORBUG-21188 Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-09-27 10:18:44 +02:00
Language::C,
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
LanguageExtension::None);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
if (cat.hasObjcSources()) {
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
result << createProjectPart(rawProjectPart,
part,
cat.objcSources(),
cat.partName("Obj-C"),
Toolchains: Detect unspecified language version We checked the command line from the project manager for "-std=X" and friends to figure out the language version to use. However, if such a flag was not provided, we assumed the latest version we support. This could conflict with the actual version of the compiler and its predefined macros. Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the predefined macros of the toolchain. The MSVC compiler is an exception to this, as it does not seem to properly set the value - check for _MSVC_LANG if possible, otherwise simply assume some versions as before. While at it, add also support for C17/C18 and the upcoming C++2a. Task-number: QTCREATORBUG-20884 Task-number: QTCREATORBUG-21188 Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-09-27 10:18:44 +02:00
Language::C,
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
LanguageExtension::ObjectiveC);
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
} else if (cat.hasCSources() || cat.hasObjcSources()) {
m_cToolchainMissing = true;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools: Ensure that parse contexts are backed up by a toolchain Otherwise empty parse contexts (e.g. not having any include paths...) will be created that are not useful. Fixes: QTCREATORBUG-22421 Change-Id: I5c9172aee38503d8b48762416e17e7047679bf2e Reviewed-by: Cristian Adam <cristian.adam@gmail.com> Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-09 10:24:57 +02:00
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
return result;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
ProjectPart::Ptr ProjectInfoGenerator::createProjectPart(
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
const RawProjectPart &rawProjectPart,
CppTools/ProjectExplorer: Remove enum duplication ... between CppTools::ProjectPart and ProjectExplorer::ToolChain. Change-Id: I8b448747e454adbed77547460383b8515462cc81 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 09:49:02 +02:00
const ProjectPart::Ptr &templateProjectPart,
const ProjectFiles &projectFiles,
const QString &partName,
Language language,
Utils: Move C++ language details from ProjectExplorer to Utils We want to use them in the backend processes too so it's nice to share them in Utils. A concrete size was added too because they should be serialized. Change-Id: Id5eb8f46643d5159f034fc9559f68a08d7e5847a Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-01-09 18:31:20 +01:00
Utils::LanguageExtensions languageExtensions)
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
{
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
RawProjectPartFlags flags;
ToolChainInfo tcInfo;
Toolchains: Detect unspecified language version We checked the command line from the project manager for "-std=X" and friends to figure out the language version to use. However, if such a flag was not provided, we assumed the latest version we support. This could conflict with the actual version of the compiler and its predefined macros. Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the predefined macros of the toolchain. The MSVC compiler is an exception to this, as it does not seem to properly set the value - check for _MSVC_LANG if possible, otherwise simply assume some versions as before. While at it, add also support for C17/C18 and the upcoming C++2a. Task-number: QTCREATORBUG-20884 Task-number: QTCREATORBUG-21188 Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-09-27 10:18:44 +02:00
if (language == Language::C) {
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
flags = rawProjectPart.flagsForC;
tcInfo = m_projectUpdateInfo.cToolChainInfo;
}
// Use Cxx toolchain for C projects without C compiler in kit and for C++ code
if (!tcInfo.isValid()) {
flags = rawProjectPart.flagsForCxx;
tcInfo = m_projectUpdateInfo.cxxToolChainInfo;
}
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
ProjectPart::Ptr part(templateProjectPart->copy());
part->displayName = partName;
part->files = projectFiles;
part->toolchainType = tcInfo.type;
part->isMsvc2015Toolchain = tcInfo.isMsvc2015ToolChain;
part->toolChainWordWidth = tcInfo.wordWidth == 64 ? ProjectPart::WordWidth64Bit
: ProjectPart::WordWidth32Bit;
Clang: Avoid consuming gcc internal include paths Given the (default) include paths of GCC, e.g. /usr/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 /usr/include/c++/7/backward /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include discard gcc-internal paths like /usr/lib/gcc/x86_64-linux-gnu/7/include as they are not relevant for clang and even confuse it with regard to #include_next. Paths below the gcc install dir are considered as gcc-internal. The install dir is queried with $ gcc -print-search-dirs Some GCC distributions, like MinGW, ship the standard library headers in the install dir. Ensure to not discard these. Fixes: QTCREATORBUG-22898 Change-Id: Ia85258fb01b72ad073e71390e003fe8268e3b01f Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-10-10 11:04:01 +02:00
part->toolChainInstallDir = tcInfo.installDir;
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
part->toolChainTargetTriple = tcInfo.targetTriple;
part->extraCodeModelFlags = tcInfo.extraCodeModelFlags;
Clang: Forward compiler options for gcc/clang Rely on clang to do the "right thing" with them. Change-Id: I44adf2cd5c61549896da3fc9b7c35c2fb0142060 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2019-01-08 16:22:39 +01:00
part->compilerFlags = flags.commandLineFlags;
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
part->warningFlags = flags.warningFlags;
PchManager: Split pch tasks in project and system pch tasks Like you can see in the task numbers this patch is touching many different areas. So I will only touch the main parts. It is using a clang action instead of an extra process which will be enabling the handling of generated files in PCHs. The flags from the project part are now not anymore transformed in a command line but they are saved in the container semantically aware so that they can later be merged. Most of this patch is simply polishing of other patches. Task-number: QTCREATORBUG-21346 Task-number: QTCREATORBUG-21380 Task-number: QTCREATORBUG-21382 Task-number: QTCREATORBUG-21383 Task-number: QTCREATORBUG-21693 Task-number: QTCREATORBUG-21778 Change-Id: I9b0c02d8149b554254e819448fbc61eeaa5b7494 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-12-17 12:06:57 +01:00
part->language = language;
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
part->languageExtensions = flags.languageExtensions;
// Toolchain macros and language version
if (tcInfo.macroInspectionRunner) {
auto macroInspectionReport = tcInfo.macroInspectionRunner(flags.commandLineFlags);
part->toolChainMacros = macroInspectionReport.macros;
part->languageVersion = macroInspectionReport.languageVersion;
// No compiler set in kit.
} else if (language == Language::C) {
Utils: Move C++ language details from ProjectExplorer to Utils We want to use them in the backend processes too so it's nice to share them in Utils. A concrete size was added too because they should be serialized. Change-Id: Id5eb8f46643d5159f034fc9559f68a08d7e5847a Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-01-09 18:31:20 +01:00
part->languageVersion = Utils::LanguageVersion::LatestC;
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
} else {
Utils: Move C++ language details from ProjectExplorer to Utils We want to use them in the backend processes too so it's nice to share them in Utils. A concrete size was added too because they should be serialized. Change-Id: Id5eb8f46643d5159f034fc9559f68a08d7e5847a Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-01-09 18:31:20 +01:00
part->languageVersion = Utils::LanguageVersion::LatestCxx;
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
}
// Header paths
if (tcInfo.headerPathsRunner) {
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
const HeaderPaths builtInHeaderPaths
CompilationDatabase: Asjust the sysroot and target handling If the sysroot option is found - set it as a kit sysroot (only in CompilationDatabase project where we have a cloned kit which does not affect the other existing kits). In other cases use the backup for the sysroot from the toolchain (can exist for clang toolchains based on mingw). Provide target when searching builtin include paths for clang. Fixes: QTCREATORBUG-22339 Change-Id: Ibe07c2e490ba4f7e0d259e6df698d641dbfd0298 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-04-25 16:06:39 +02:00
= tcInfo.headerPathsRunner(flags.commandLineFlags,
tcInfo.sysRootPath,
tcInfo.targetTriple);
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
HeaderPaths &headerPaths = part->headerPaths;
for (const HeaderPath &header : builtInHeaderPaths) {
const HeaderPath headerPath{header.path, header.type};
CppTools: Inline ToolChainEvaluator Change-Id: Ie5579820e4683a5e4d7d73034441d662e017b6a3 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 11:04:03 +02:00
if (!headerPaths.contains(headerPath))
headerPaths.push_back(headerPath);
}
}
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
part->languageExtensions |= languageExtensions;
part->updateLanguageFeatures();
CppTools: Make create* methods return something Change-Id: I20cfdaef23e9b7c48c9d3b4f27157e771fd9bc7f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2017-10-27 13:31:11 +02:00
return part;
CppTools/ProjectManagers: Reduce ui blocking when loading projects ${AnyProject}::updateCppCodeModel() did two potentially not that cheap operations in the ui thread: (1) Querying the MimeDatabase for the mime type for the source files of the project. In 99.9% of the cases no files need to be read for this as the file extension will resolve the type. The expensiveness comes from the sheer number of files that can occur. (2) Calling compilers with the "(sub)project's compiler command line" to determine the macros. While the caches avoid redundant calls, the number of the unique compiler calls makes this still a ui-freezing experience. These two operations are moved into a worker thread. For this, the expensive compiler calls are encapsulated in thread safe lambdas ("runners") in order to keep the "mutexed" data minimal. The original API calls of the toolchains are implemented in terms of the runners. While adapting the project managers, remove also the calls to setProjectLanguage(). These are redundant because all of the project managers already set a proper value in the constructor. Also, currently there is no need (client) to report back detection of C sources in project parts. This also keeps CppProjectUpdater simple. There is still room for improvement: * Run the compiler calls in parallel instead of sequence. * Ensure that the mime type for a file is determined exactly once. Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-02-06 16:59:53 +01:00
}
} // namespace Internal
} // namespace CppTools
Copy Permalink