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

212 lines
8.1 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 {
CppTools: Move ProjectUpdateInfo to ProjectExplorer Used for updating project parts, so move it near RawProjectPart. Change-Id: I77aeffbdbfb3d2ec0de600f61dcf7fbb7a355a98 Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-08-29 09:59:45 +02:00
ProjectInfoGenerator::ProjectInfoGenerator(
const QFutureInterface<void> &futureInterface,
const ProjectExplorer::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: 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
for (const ProjectExplorer::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();
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: 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(
const ProjectExplorer::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: 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
QVector<ProjectPart::Ptr> ProjectInfoGenerator::createProjectParts(
const ProjectExplorer::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: 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: 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: 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
const ProjectExplorer::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: 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
ProjectExplorer::RawProjectPartFlags flags;
CppTools: Move ProjectUpdateInfo to ProjectExplorer Used for updating project parts, so move it near RawProjectPart. Change-Id: I77aeffbdbfb3d2ec0de600f61dcf7fbb7a355a98 Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
2019-08-29 09:59:45 +02:00
ProjectExplorer::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
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
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