Fix that triggering a diagnostic tooltip from the diagnostic
location/range itself (underlined text) did not show the icon on the
left and the actions/toolbuttons on the right in the tooltip.
Instead of showing the tooltip content itself, request the tooltip for
the corresponding text mark to get the extra decoration and actions.
Change-Id: I5e94aca117a761f7a798d4f4b33db6e386e54d84
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
This includes also the query data for the help system (F1) for an
identifier under cursor.
Regressions (libclang changes necessary):
- Function signatures do not contain default values.
- Aliases are not resolved for/at:
- template types
- qualified name of a type
Fixes/Improvements:
- Resolve "auto"
- On a template type, show also the template parameter.
- For a typedef like
typedef long long superlong;
the tooltip was "long long superlong", which was confusing.
Now, "long long" is shown.
New:
- Show first or \brief paragraph of a documentation comment.
- Show size of a class at definition.
- Show size of a field member in class definition.
Task-number: QTCREATORBUG-11259
Change-Id: Ie1a07930d0e882015d07dc43e35bb81a685cdeb8
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
* Move the combox box for switching the parse configurations out of the
"Additional Preprocessor Directives" dialog ('#'-button) to make it
better visible/accessible. Also, decouple the extra preprocessor
directives from the concrete parse context since this is not anymore
in same dialog.
* The combo box appears only if multiple parse configurations are
available for a file.
* The first time multiple parse configurations are detected, an info bar
is shown that points the user to the combox box. A "Do Not Show Again"
button is provided.
* Upon selecting an entry, the preferred parse configuration is saved as
part of the session. The setting can be cleared with the context menu
entry on the combo box.
Follow-up changes need to ensure that the display name and/or tooltip is
unambiguous, e.g. for qbs and cmake projects.
Change-Id: I9e9773704187291524ad7b605bfdddd83ef5b19d
Reviewed-by: David Schulz <david.schulz@qt.io>
As long as there are project parts for a source file, always determine
the best project part, instead of trying to stick to the previous one.
This ensures the best project part at all times and simplifies the code.
Change-Id: I25ea3eb43a5a3e6d93688d4b8965f596dc9ae22b
Reviewed-by: David Schulz <david.schulz@qt.io>
Parse issues can have multiple reasons (invalid kit, not a project file,
actual parse issue) and we should be able to tell them apart. With this
change, we can distinguish between the fallback project part and a
ambiguous project part.
Follow up changes will use this to display more accurate diagnostics.
Change-Id: Icc8767607cc17dc14d6227b07f34e81ba5525a96
Reviewed-by: David Schulz <david.schulz@qt.io>
...instead of C++ headers.
For the Clang Code Model this results in using "-x c-header" instead of
"-x c++-header".
This introduces a new option in Options > C++ > "Code Model" to
configure this.
Change-Id: I8a0ce8fa6155f5ef58743ebc7f1d0b500fbf6599
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Parsing happens rotationally on the translation units.
The recently parsed translation unit is used for completion jobs while
the older version is used for parse jobs.
Advantages:
A1. A completion job cannot be blocked anymore by currently running
parse job.
A2. Faster triggering of parse jobs. A reparse was triggered about
1650ms after the last keystroke. This is down to 500ms now since we
do not have a blocking translation unit for the completion anymore.
Disadvantages:
D1. Memory consumption is doubled for an edited document.
This could be addressed by suspending the second translation unit
after some time of inactivity.
D2. Setup of the supportive translation unit takes some time.
Change-Id: I958c883c01f274530f5482c788c15cd38d6f4c3e
Reviewed-by: David Schulz <david.schulz@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>
We used to call QTextCharFormat::setToolTip from the ExtraSelection to
install the diagnostic tooltip. Since this allows to set only text
tooltips and we would like to introduce a custom tooltip widget for
diagnostics, make use of CppHoverHandler, which is more flexible.
Change-Id: Ia1b2c3c50810596ce4a3a025002e6e4efd8789db
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
We broke the dependency of
BaseEditorDocumentProcessor *BaseEditorDocumentProcessor::get(const QString &filePath)
It's hiding static calls and it is much easier to do it that way than to
provide a reference to every user. It's also possible to exchange it with
different implementations for different test cases.
Change-Id: Ic74699b45948e8b48f7efb6a1b295ba2641b8951
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
BaseEditorDocumentProcessor was holding a TextEditor::TextDocument but
only used the QTextDocument and the file path.
Change-Id: I349cc95d973adeaf9f94638d84333f592c14e7f9
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>
They are invokable by the usual means (Alt+Enter, editor's context menu
> Refactor) plus by the context menu of the editor's left margin for the
related line.
The fixit text comes directly from libclang and is thus not translated.
We modify the text slighty by stripping the diagnostic category prefix
("note:", "error:", ...) and capitalizing the first letter.
A follow-up change should properly indicate available refactorings with
a refactoring icon in the editor's left margin.
Task-number: QTCREATORBUG-14868
Change-Id: I86157c9f824d2a9dedf19087476d02ad1e6cc854
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>
Diagnostics are now moved to the clang backend process. Fixits are
supported too.
Change-Id: I20faacf466bbf78dec479220c3d7b336a47bc453
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
...and related functions. For clarity in client code.
Change-Id: Icad6fc7b1eee2ce46a2eba8435359837a23409c8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
When the length of the highlight is specified, the code does not properly
check for end of line. This causes some lines to be highlighted when only
the last word was supposed to be.
For example, with this code:
1: void foo(int x);
2: int a = foo
3: ();
4: int b = foo(
5: );
line 2 and 4 used to be completely highlighted (underlined), instead of
just 'foo'.
Change-Id: I40e895410ce0f38bad0adbccd509fd2943c93c97
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
First step of some more 'Base' removal in TextEditor.
s/Core::TextDocument/Core::BaseTextDocument/
s/TextEditor::BaseTextDocument/TextEditor::TextDocument/
Change-Id: I71ba325a2f0ad72ec9dae0d96846cbae72d326f7
Reviewed-by: hjk <hjk121@nokiamail.com>
Replace the CppModelManagerInterface/derived CppModelManager
combo by a more common CppModelManager/CppModelManagerPrivate
pimpl pattern.
Change-Id: Ia4582845ed94d5ef60b8571bab9b2260c6290287
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This eliminates a bunch of list->set->list conversions. Especially the
ProjectInfo::appendProjectPart takes lots of time converting for every
part added.
Change-Id: Ib3c8cd4b0ad6c012ccbeed12ebedd46b9b6cca95
Reviewed-by: Daniel Teske <daniel.teske@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>
