Files
qt-creator/src/plugins/cpptools/baseeditordocumentparser.cpp

150 lines
4.9 KiB
C++
Raw Normal View History

/****************************************************************************
**
** Copyright (C) 2016 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 "baseeditordocumentparser.h"
#include "baseeditordocumentprocessor.h"
#include "cppmodelmanager.h"
#include "cppprojectpartchooser.h"
C++: Base parsing on editor document instead of widget This mainly takes CppEditorSupport apart. * Parsing is now invoked by CPPEditorDocument itself by listening to QTextDocument::contentsChanged(). * Upon construction and destruction CPPEditorDocument creates and deletes an EditorDocumentHandle for (un)registration in the model manager. This handle provides everything to generate the working copy and to access the editor document processor. * A CPPEditorDocument owns a BaseEditorDocumentProcessor instance that controls parsing, semantic info recalculation and the semantic highlighting for the document. This is more or less what is left from CppEditorSupport and can be considered as the backend of a CPPEditorDocument. CPPEditorDocument itself is quite small. * BuiltinEditorDocumentProcessor and ClangEditorDocumentProcessor derive from BaseEditorDocumentProcessor and implement the gaps. * Since the semantic info calculation was bound to the widget, it also calculated the local uses, which depend on the cursor position. This calculation got moved into the extracted class UseSeletionsUpdater in the cppeditor plugin, which is run once the cursor position changes or the semantic info document is updated. * Some more logic got extracted: - SemanticInfoUpdater (logic was in CppEditorSupport) - SemanticHighlighter (logic was in CppEditorSupport) * The *Parser and *Processor classes can be easily accessed by the static function get(). * CppHighlightingSupport is gone since it turned out to be useless. * The editor dependency in CompletionAssistProviders is gone since we actually only need the file path now. Change-Id: I49d3a7bd138c5ed9620123e34480772535156508 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
2014-08-19 15:59:29 +02:00
#include "editordocumenthandle.h"
namespace CppTools {
/*!
\class CppTools::BaseEditorDocumentParser
\brief The BaseEditorDocumentParser class parses a source text as
precisely as possible.
It's meant to be used in the C++ editor to get precise results by using
the "best" project part for a file.
Derived classes are expected to implement updateImpl() this way:
\list
\li Get a copy of the configuration and the last state.
\li Work on the data and do whatever is necessary. At least, update
the project part with the help of determineProjectPart().
\li Ensure the new state is set before updateImpl() returns.
\endlist
*/
BaseEditorDocumentParser::BaseEditorDocumentParser(const QString &filePath)
: m_filePath(filePath)
{
}
BaseEditorDocumentParser::~BaseEditorDocumentParser()
{
}
QString BaseEditorDocumentParser::filePath() const
{
return m_filePath;
}
BaseEditorDocumentParser::Configuration BaseEditorDocumentParser::configuration() const
{
QMutexLocker locker(&m_stateAndConfigurationMutex);
return m_configuration;
}
void BaseEditorDocumentParser::setConfiguration(const Configuration &configuration)
{
QMutexLocker locker(&m_stateAndConfigurationMutex);
m_configuration = configuration;
}
void BaseEditorDocumentParser::update(const UpdateParams &updateParams)
{
QFutureInterface<void> dummy;
update(dummy, updateParams);
}
void BaseEditorDocumentParser::update(const QFutureInterface<void> &future,
const UpdateParams &updateParams)
{
QMutexLocker locker(&m_updateIsRunning);
updateImpl(future, updateParams);
}
BaseEditorDocumentParser::State BaseEditorDocumentParser::state() const
{
QMutexLocker locker(&m_stateAndConfigurationMutex);
return m_state;
}
void BaseEditorDocumentParser::setState(const State &state)
{
QMutexLocker locker(&m_stateAndConfigurationMutex);
m_state = state;
}
ProjectPart::Ptr BaseEditorDocumentParser::projectPart() const
{
return state().projectPart;
}
BaseEditorDocumentParser::Ptr BaseEditorDocumentParser::get(const QString &filePath)
C++: Base parsing on editor document instead of widget This mainly takes CppEditorSupport apart. * Parsing is now invoked by CPPEditorDocument itself by listening to QTextDocument::contentsChanged(). * Upon construction and destruction CPPEditorDocument creates and deletes an EditorDocumentHandle for (un)registration in the model manager. This handle provides everything to generate the working copy and to access the editor document processor. * A CPPEditorDocument owns a BaseEditorDocumentProcessor instance that controls parsing, semantic info recalculation and the semantic highlighting for the document. This is more or less what is left from CppEditorSupport and can be considered as the backend of a CPPEditorDocument. CPPEditorDocument itself is quite small. * BuiltinEditorDocumentProcessor and ClangEditorDocumentProcessor derive from BaseEditorDocumentProcessor and implement the gaps. * Since the semantic info calculation was bound to the widget, it also calculated the local uses, which depend on the cursor position. This calculation got moved into the extracted class UseSeletionsUpdater in the cppeditor plugin, which is run once the cursor position changes or the semantic info document is updated. * Some more logic got extracted: - SemanticInfoUpdater (logic was in CppEditorSupport) - SemanticHighlighter (logic was in CppEditorSupport) * The *Parser and *Processor classes can be easily accessed by the static function get(). * CppHighlightingSupport is gone since it turned out to be useless. * The editor dependency in CompletionAssistProviders is gone since we actually only need the file path now. Change-Id: I49d3a7bd138c5ed9620123e34480772535156508 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
2014-08-19 15:59:29 +02:00
{
CppModelManager *cmmi = CppModelManager::instance();
if (CppEditorDocumentHandle *cppEditorDocument = cmmi->cppEditorDocument(filePath)) {
if (BaseEditorDocumentProcessor *processor = cppEditorDocument->processor())
C++: Base parsing on editor document instead of widget This mainly takes CppEditorSupport apart. * Parsing is now invoked by CPPEditorDocument itself by listening to QTextDocument::contentsChanged(). * Upon construction and destruction CPPEditorDocument creates and deletes an EditorDocumentHandle for (un)registration in the model manager. This handle provides everything to generate the working copy and to access the editor document processor. * A CPPEditorDocument owns a BaseEditorDocumentProcessor instance that controls parsing, semantic info recalculation and the semantic highlighting for the document. This is more or less what is left from CppEditorSupport and can be considered as the backend of a CPPEditorDocument. CPPEditorDocument itself is quite small. * BuiltinEditorDocumentProcessor and ClangEditorDocumentProcessor derive from BaseEditorDocumentProcessor and implement the gaps. * Since the semantic info calculation was bound to the widget, it also calculated the local uses, which depend on the cursor position. This calculation got moved into the extracted class UseSeletionsUpdater in the cppeditor plugin, which is run once the cursor position changes or the semantic info document is updated. * Some more logic got extracted: - SemanticInfoUpdater (logic was in CppEditorSupport) - SemanticHighlighter (logic was in CppEditorSupport) * The *Parser and *Processor classes can be easily accessed by the static function get(). * CppHighlightingSupport is gone since it turned out to be useless. * The editor dependency in CompletionAssistProviders is gone since we actually only need the file path now. Change-Id: I49d3a7bd138c5ed9620123e34480772535156508 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
2014-08-19 15:59:29 +02:00
return processor->parser();
}
return BaseEditorDocumentParser::Ptr();
C++: Base parsing on editor document instead of widget This mainly takes CppEditorSupport apart. * Parsing is now invoked by CPPEditorDocument itself by listening to QTextDocument::contentsChanged(). * Upon construction and destruction CPPEditorDocument creates and deletes an EditorDocumentHandle for (un)registration in the model manager. This handle provides everything to generate the working copy and to access the editor document processor. * A CPPEditorDocument owns a BaseEditorDocumentProcessor instance that controls parsing, semantic info recalculation and the semantic highlighting for the document. This is more or less what is left from CppEditorSupport and can be considered as the backend of a CPPEditorDocument. CPPEditorDocument itself is quite small. * BuiltinEditorDocumentProcessor and ClangEditorDocumentProcessor derive from BaseEditorDocumentProcessor and implement the gaps. * Since the semantic info calculation was bound to the widget, it also calculated the local uses, which depend on the cursor position. This calculation got moved into the extracted class UseSeletionsUpdater in the cppeditor plugin, which is run once the cursor position changes or the semantic info document is updated. * Some more logic got extracted: - SemanticInfoUpdater (logic was in CppEditorSupport) - SemanticHighlighter (logic was in CppEditorSupport) * The *Parser and *Processor classes can be easily accessed by the static function get(). * CppHighlightingSupport is gone since it turned out to be useless. * The editor dependency in CompletionAssistProviders is gone since we actually only need the file path now. Change-Id: I49d3a7bd138c5ed9620123e34480772535156508 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
2014-08-19 15:59:29 +02:00
}
ProjectPart::Ptr BaseEditorDocumentParser::determineProjectPart(
const QString &filePath,
const Configuration &config,
const State &state,
const ProjectExplorer::Project *activeProject,
Language languagePreference,
bool hasActiveProjectChanged)
{
Internal::ProjectPartChooser chooser;
chooser.setFallbackProjectPart([](){
return CppModelManager::instance()->fallbackProjectPart();
});
chooser.setProjectPartsForFile([](const QString &filePath) {
return CppModelManager::instance()->projectPart(filePath);
});
chooser.setProjectPartsFromDependenciesForFile([&](const QString &filePath) {
const auto fileName = Utils::FileName::fromString(filePath);
return CppModelManager::instance()->projectPartFromDependencies(fileName);
});
return chooser.choose(filePath,
state.projectPart,
config.manuallySetProjectPart,
config.stickToPreviousProjectPart,
activeProject,
languagePreference,
hasActiveProjectChanged);
}
} // namespace CppTools