feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity
Files
381c5656e7495cb4332a8ddbcf14843bf211b8b1
qt-creator/src/plugins/cpptools/cppprojectinfogenerator.h

62 lines
2.4 KiB
C
Raw Normal View History

CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01: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
** Copyright (C) 2017 The Qt Company Ltd.
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** Contact: https://www.qt.io/licensing/
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
**
** 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
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** 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.
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
**
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** 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.
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
**
****************************************************************************/
Wholesale conversion to #pragma once Kudos to cgmb and https://github.com/cgmb/guardonce Change-Id: Ifa8970734b8d43fd08c9260c645bdb0228633791 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-03-18 07:55:01 +01:00
#pragma once
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
CppTools: Remove enum duplication Change-Id: I2eb452780c21f8d30034bcfbb3266fc8daa10802 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
2018-10-08 10:54:27 +02:00
#include "cpptools_utils.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
#include "projectinfo.h"
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01: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
#include <QFutureInterface>
QbsProjectManager: Reduce calls to mime database. Qbs already has some definite information about file types. Change-Id: I024feeae3e6df5ec5462924ffedc7332e585f6b7 Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com> Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
2016-02-22 15:47:39 +01:00
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
namespace CppTools {
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 {
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01: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
class ProjectInfoGenerator
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
{
public:
Fix CppProjectUpdater cancelAndWaitForFinished The code was pushing an additional QFutureInterface through the whole chain of functions, which was used for canceling. But since it was never started (and never finished, and never used for reporting results), calling waitForFinshed on it never had any effect with Qt5 and locks up with Qt6. Instead of using a separate QFutureInterface, use the actual QFuture that is available and intended for it. Fixes: QTCREATORBUG-24902 Change-Id: I5a49bcecc9cf70fbffa93aee4293004f9369df58 Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2020-11-10 17:55:54 +01:00
ProjectInfoGenerator(const QFutureInterface<ProjectInfo> &futureInterface,
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
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
ProjectInfo generate();
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01: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
private:
Fix clang warnings about copies in range-for constructs Change-Id: If50553964483626e72a816b1d23fa81b45ed9ca7 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2020-06-15 13:40:39 +02:00
const QVector<ProjectPart::Ptr> createProjectParts(
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);
ProjectPart::Ptr createProjectPart(const ProjectExplorer::RawProjectPart &rawProjectPart,
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
const ProjectPart::Ptr &templateProjectPart,
const ProjectFiles &projectFiles,
const QString &partName,
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 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
private:
Fix CppProjectUpdater cancelAndWaitForFinished The code was pushing an additional QFutureInterface through the whole chain of functions, which was used for canceling. But since it was never started (and never finished, and never used for reporting results), calling waitForFinshed on it never had any effect with Qt5 and locks up with Qt6. Instead of using a separate QFutureInterface, use the actual QFuture that is available and intended for it. Fixes: QTCREATORBUG-24902 Change-Id: I5a49bcecc9cf70fbffa93aee4293004f9369df58 Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2020-11-10 17:55:54 +01:00
const QFutureInterface<ProjectInfo> m_futureInterface;
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
const ProjectExplorer::ProjectUpdateInfo &m_projectUpdateInfo;
CppTools: Give early warning if kit has no compilers We keep getting bug reports from users who forgot to set a compiler in their kit and then get confused by (misleading) warnings from the code model. Improve the situation by detecting the condition that a C/C++ project's current kit does not have a C/C++ compiler and showing a warning for that in the issues pane. Task-number: QTCREATORBUG-23247 Change-Id: I10164e85ad595f3a386340e7813d1f3e40fbecb5 Reviewed-by: hjk <hjk@qt.io>
2020-01-30 13:40:16 +01:00
bool m_cToolchainMissing = false;
bool m_cxxToolchainMissing = false;
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
CppTools: Moving ProjectPartBuilder in its own header Change-Id: I0aa65ec6c80dcd437f13ff70021388b0da57ccfd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
2016-01-11 21:08:13 +01:00
} // namespace CppTools
Copy Permalink