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

203 lines
7.9 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/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/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 {
ProjectInfoGenerator::ProjectInfoGenerator(const QFutureInterface<void> &futureInterface,
const ProjectUpdateInfo &projectUpdateInfo)
: 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
for (const RawProjectPart &rpp : m_projectUpdateInfo.rawProjectParts) {
if (m_futureInterface.isCanceled())
return ProjectInfo();
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
for (ProjectPart::Ptr part : createProjectParts(rpp))
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: 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: 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
static ProjectPart::Ptr projectPartFromRawProjectPart(const RawProjectPart &rawProjectPart,
ProjectExplorer::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())
part->projectMacros += ProjectExplorer::Macro::toMacros(ProjectPart::readProjectConfigFile(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
part->headerPaths = rawProjectPart.headerPaths;
part->precompiledHeaders = rawProjectPart.precompiledHeaders;
part->selectedForBuilding = rawProjectPart.selectedForBuilding;
return part;
}
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> ProjectInfoGenerator::createProjectParts(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,
rawProjectPart.fileClassifier);
if (cat.hasParts()) {
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
const ProjectPart::Ptr part = projectPartFromRawProjectPart(rawProjectPart,
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
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
}
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: 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(
const RawProjectPart &rawProjectPart,
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
{
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;
}
// TODO: If no toolchain is set, show a warning
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;
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) {
const ProjectExplorer::HeaderPaths builtInHeaderPaths
= tcInfo.headerPathsRunner(flags.commandLineFlags, tcInfo.sysRootPath);
ProjectExplorer::HeaderPaths &headerPaths = part->headerPaths;
for (const ProjectExplorer::HeaderPath &header : builtInHeaderPaths) {
const ProjectExplorer::HeaderPath headerPath{header.path, header.type};
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