summaryrefslogtreecommitdiff
path: root/src/plugins/cpptools/cppprojectupdater.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge CppTools into CppEditorChristian Kandeler2021-09-011-80/+0
| | | | | | | | | | | | | | | | There was no proper separation of responsibilities between these plugins. In particular, CppTools had lots of editor-related functionality, so it's not clear why it was separated out in the first place. In fact, for a lot of code, it seemed quite arbitrary where it was put (just one example: switchHeaderSource() was in CppTools, wheras switchDeclarationDefinition() was in CppEditor). Merging the plugins will enable us to get rid of various convoluted pseudo-abstractions that were only introduced to keep up the artificial separation. Change-Id: Iafc3bce625b4794f6d4aa03df6cddc7f2d26716a Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* CppTools: Use only const pointers for ProjectInfo and ProjectPartChristian Kandeler2021-08-271-1/+1
| | | | | | | | All members were already const, but this makes it clear at all points of use that these data structures are immutable. Change-Id: Iea615c090bde462c445d15223caccc561b0c713d Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* CppTools: Turn some classes into pure value typesChristian Kandeler2021-08-131-2/+1
| | | | | | | | | | | | | ProjectInfo, ProjectPart and ProjectUpdateInfo used to carry pointers to Project and/or Toolchain, even though they were used in contexts where these pointers were either unsafe to access or not guaranteed to be valid anymore, which made their use difficult and error-prone. We turn these classes into pure value types by copying in all relevant information before the first async operation takes place. Fixes: QTCREATORBUG-25678 Change-Id: I1914b0dbda6c7dfba6c95e5e92f2d69977755590 Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* Don't update extra compilers individually after project loadEike Ziller2021-07-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Each call of CppModelManager::updateSourceFiles detaches the current snapshot. The extra compilers where set up and triggered individually, and resulted in individual updateSourceFiles calls with the single result file of the extra compiler. For Qt Creator this would lead to 200 calls in quick succession after project load, potentially leading to a freeze of multiple seconds. Instead of updating the result files of the extra compilers individually after project load, integrate the update into the regular project source file update. So we end up with only a single call of updateSourceFiles. For this the project updater needs to trigger the extra compilers, and wait for all to finish as well as the regular project part update, before triggering the parser. Task-number: QTCREATORBUG-25783 Change-Id: I34f6df0fc0f96bcb42ee65019bee39cf49176c1f Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* CppProjectUpdater: Wait for all tasks to be finished in d'torJarek Kobus2021-05-271-5/+3
| | | | | | | | | | | | | | It may happen that the old task was canceled and still running while the new task was started. Later, when the d'tor is called both old and new tasks may still be running. Before we waited only for the new task to be finished in d'tor. Now we are waiting for all tasks to be finished. Amends: 7fb592fe0cfec22ae7e966b9c6b88aa801bf9592 Task-number: QTCREATORBUG-25709 Change-Id: Id4b44cd36ee03aa45472b15d8fbb25a2cab77e92 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Remove unneeded includesJarek Kobus2020-11-121-1/+0
| | | | | Change-Id: I67fee9303509b7080e123a2a5826e200ce498ce2 Reviewed-by: hjk <hjk@qt.io>
* Fix CppProjectUpdater cancelAndWaitForFinishedEike Ziller2020-11-111-1/+2
| | | | | | | | | | | | | | | | 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>
* Make CppProjectUdpater a final classJarek Kobus2020-11-091-1/+1
| | | | | | | | | | | | | Silence the warning: "Call to virtual method 'CppProjectUdpater::cancel' during destruction bypasses virtual dispatch". CppProjectUpdater's d'tor calls cancelAndWaitForFinished(), and the latter calls in turn virtual cancel() method. As long as we don't have subclasses of CppProjectUdpater, calling a virtual cancel() from the d'tor should be safe. Change-Id: If2ebe6a190649319401d4e4b0f6977f547c51dac Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* GenericProject: Make dependency on CppTools optionalEike Ziller2019-09-131-3/+15
| | | | | | | | | | | | | Especially in the light of the language server, the generic project is currently the project one can use for language servers that require a "project workspace". Makes it possibly to run Qt Creator with "-noload CppTools" if you still want to use generic projects with some other language. Change-Id: Ib9059289a2db4c44c0c1060a02fcdafacb885fbd Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
* CppTools: Move ProjectUpdateInfo to ProjectExplorerEike Ziller2019-09-121-3/+2
| | | | | | | Used for updating project parts, so move it near RawProjectPart. Change-Id: I77aeffbdbfb3d2ec0de600f61dcf7fbb7a355a98 Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
* CppProjectUpdater: Remove unread attributeBernhard Beschow2019-01-061-4/+1
| | | | | | Change-Id: I51123e5b5609de431cfa6d1558aed0b9739ff9c8 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
* QbsProject: Remove unread attributeBernhard Beschow2019-01-061-3/+0
| | | | | | | | Also remove the signal CppProjectUpdater::projectInfoUpdated() which is now unused. Change-Id: I65afe8f96cd8175edaf8ccb6e5067e4f9cd8d99f Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
* CppTools: Use override consistentlyTobias Hunger2018-05-071-1/+1
| | | | | | | clang-tidy fixes from modernize-use-override check. Change-Id: I0e6d6a9df3e87b8042ccc5ea0adc70070a3821d6 Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
* CppTools/ProjectManagers: Reduce ui blocking when loading projectsNikolai Kosjar2017-02-201-0/+69
${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>
View Lorry Controller Status