More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We can't stop the clangbackend from processing huge files, but at least
our built-in parser.
Fixes: QTCREATORBUG-21590
Change-Id: I506024495ba0632692f2845c6c204360f4c61b33
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
System include paths are appended after other includes by the compiler. So
we should set them as system includes and not as normal includes. Otherwise
we change the include order. Headers in system include paths are not
cluttering the screen with unwanted warning and by the way improve
performance too.
ProjectPartHeaderPath was a dopperganger of HeaderPath, so we merged them.
Change-Id: I7c394b4098b697de79761499ffcd5913cc02d652
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The m_parserFuture.cancel() in ~BuiltinEditorDocumentProcessor() did not
cancel anything. Thus, closing a document while the parser was running
led to a blocking UI thread.
Now it cancels at the next include directive it encounters.
Change-Id: I092fddbbd747e0bc95265b6e9b4fcc26b3f76cb3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Also extracting inline HeaderPath class and change projects list in vector
because the size is larger than a pointer.
Change-Id: I885fdff3fe9bccc877634d1615249755f5b674fd
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
...nowadays we only need the working copy.
Change-Id: I30924b3c5dc68b428d6c10f6ba015b0640b476d2
Reviewed-by: Marco Bubke <marco.bubke@theqtcompany.com>
Fix use-after-free for the following case:
1. Open an editor
2. Trigger a long processing completion
(e.g. simulate with QThread::msleep in
CppCompletionAssistInterface::getCppSpecifics)
3. ...and immediately close the editor (e.g. with Ctrl+W)
4. Wait until it crashes.
The completion thread relied on the BuiltinEditorDocumentParser object,
which is deleted once the editor is closed. Fixed by sharing the
ownership of that object between the *EditorDocumentProcessor and the
completion assist interface.
This case came up when doing tests for the bug report below.
Task-number: QTCREATORBUG-14991
Change-Id: I0b009229e68fc6b7838740858cdc41a32403fe6f
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
...so derived classes are freed from doing this.
Change-Id: I73f3eca54be14cfd6542a466f0e9c024457bef07
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
Among others, BaseEditorDocumentParser::projectPart() was a blocking
operation in case the parser was running. This led to noticeable GUI
freezes for the ClangCodeModel since the function was called from the
main thread.
Rework *EditorDocumentParser to clearly separate the configuration data
(input) from the actual object state. Querying/setting configuration or
(last) state does not block anymore. update() is supposed to get the
necessary configuration and the last state at the beginning and to set
the new state at end.
Change-Id: Ib4b534fa6ff373c3059826726b3f10ece95acc21
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
... by keying on Utils::FileName
Task-number: QTCREATORBUG-12390
Change-Id: Ia98afb5a9160a7fd9225a2f9e02539ff3c35ae86
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
It logically depends on the Snapshot and has a related lifetime.
Keeping it in the Snapshot avoids some code compelxity.
Change-Id: I24ee4483b44d9b0d7f2e4d494ae7ea624b949f9c
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
...so that SemanticInfoUpdater does not depend anymore on the
EditorDocumentParser. Accessing the snapshot was a blocking operation
that delayed the semantic info update longer than actually needed.
Change-Id: I348d22ef83ab310d4319b2e8b9678fe90ee24d6a
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
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>
