This reverts
commit 3bf19030ab.
CodeAssist: Fragile proposals aren't closed by automatic proposals.
which fixed the case [1] but introduced the regression in case [2]. Re-
implement the fix for [1] in a different way: Check whether the new
proposal has any items to show before closing the function signature
hint.
Case [1]
void f(int);
void g()
{
f(bar // This is what we will have in the end. The steps are:
// 1. Type "f("
// --> OK, function signature pop up is shown.
// 2. Type "bar"
// --> OPS, function signature pop up is closed and no
// new completion list is shown because "bar" does
// not match any declarations.
}
Case [2]
int barman = 0;
void f(int);
void g()
{
f(bar // This is what we will have in the end. The steps are:
// 1. Type "f("
// --> OK, function signature pop up is shown.
// 2. Type "bar"
// --> OPS, no auto completion list for "barman" is
// proposed.
}
Task-number: QTCREATORBUG-16934
Change-Id: I8456275d951de9e6fc53285a5dbcbd448d49ad08
Reviewed-by: David Schulz <david.schulz@qt.io>
Keep the highlight as long as the cursor is directly behind the closing
character and the editor is the focus widget.
Change-Id: Ic1d4bac263e9d2f395791dad7ecdceb9d69635c5
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Currently we are just using the first that is found. Which could lead
to unexpected behavior. Adjust the API to make clear just one assistant
is supported per editor type.
Change-Id: I711e66b4c5c5f347118357a8bafa0ffc6d650f7e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For unit test we need to break every dependency to the TextEditor
Widget etc.. With an abstract interface we can implement it in clang
without relying on unwanted dependencies. It makes it also easier to
compute the values deferred.
Change-Id: I1b313a1625f4e80bd324ab4bf1a7c4f6b690abe9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
If we send already a completion we should test if there is already one
sent for the same position.
Change-Id: Ie88f89bff0e1da1c5e747827a45154c7ccaecabc
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
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>
...for the following case:
void fun1();
void fun2();
void g()
{
fu // Type 'n', wait for the widget, hit return to choose the item
}
Once e.g. "fun1" is chosen, the completion is triggered again but the
processor (and as result the assist interface) is not freed.
The assumption was that for the AsynchronousWithThread case
IAssistProcessor::perform() would either return 0 (async completion was
started) or != 0 for an immediate proposal. It turns out there is a
third case: no proposal if the completion is not applicable, e.g.
choosing an item in the example above will retrigger completion, however
no completion makes sense for "fun1()<CURSOR>" for an idle editor.
Workaround the case with a getter/setter in IAssistProcessor. Proper
solution should (slightly?) rework the IAssistProcessor API.
Change-Id: I44dde8287998d54ded1ea07e7c39a5157cf62029
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
Leak happened if the user triggered the completion again, before the
results for the first completion arrived.
Side note: This is one more reason for using smart pointers to manage
code assist objects.
Change-Id: I582d364286ca47f8622383f3365ad4e5933eb2df
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
Manually managing the ownership of the code assist objets gets messy. We
should use smart pointers.
Change-Id: I29fe665e52438a79c3268b74898c583bb302f1fc
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
This is required for the CodemodelBackendIPC integration in the
ClangCodeModelPlugin. Since the heavy calculation happens in a separate
process, we only need to send appropriate requests and receive results
for a working completion. However, the CodeAssist API does not fit here
since it only provides means of caculating the results in the main
thread or a worker thread. We can't use the worker thread approach since
that would lead to threading issues regarding QLocalSocket in
CodemodelBackendIPC.
IAssistProcessor::setAsyncProposalAvailable() will hand the results
back to CodeAssist in order to display them.
Change-Id: I496192560fb406ec40fa8bcb7904f7a03d2eef50
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
... to the editor factories and pass it to the document, not the widget.
Saves some code, puts fewer objects into the object pool.
Change-Id: Iaaf250af74dc4e0c62700873accbb40ba88b7d9e
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: David Schulz <david.schulz@digia.com>
... and some of the related implementation details
Change-Id: I1f03aa5acf2d3fb2cfc2a6a7845f3d3578b0408d
Reviewed-by: David Schulz <david.schulz@digia.com>
Simplifies the code base by removing one level of unused
and unneeded abstraction.
- Merge {I,Default}AssistInterface to AssistInterface
- Merge {IAssist,Basic}ProposalItem to AssistProposalItem
- Merge {IGenericProposal,BasicProposalItemList}Model to GenericProposalModel
Change-Id: I54ee7b095427383d67a00fc1d87c3808c21d812d
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
There was document(), textDocument() and baseTextDocument().
Two should be enough...
Change-Id: Id9e41c8d857c5cb3269a9fce5ab594d34448c982
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
Also adding the possibility to insert text into the blockselection.
Task-number: QTCREATORBUG-7773
Change-Id: I7a47a1d630f769a8253ee1a2f21057820ea170d5
Reviewed-by: Lukas Holecek <hluk@email.cz>
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
...since it does not make sense for TextEditor::QuickFix and
TextEditor::FollowSymbol.
Regarding the bug:
- The bug was exposed by having "Active completion" set to *not*
"Manual" in Options > Text Editor > Completion.
- After choosing one item from the overrides list the cursor was
positioned just right before the beginning of a function name, which
is a valid activation sequence (see CodeAssistantPrivate::process()))
As a consequence, a new proposal was requested.
Task-number: QTCREATORBUG-10345
Change-Id: Ib0d10192863fb33c0958a9afbf76ca8e7de772f8
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Immediate proposals are displayed for asynchronous providers and fragile
proposals.
The idea is to show already available results immediately. The proposal
calculated in the process runner can then replace the immediate
proposal.
Change-Id: I7903e6677c9dfeb4957eb416062fff1fb01ff23f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
...from CompletionAssistProvider, so other providers can be executed
asynchronously, too.
Change-Id: I6ec06f6d76bc2937bc272450b4e8dffd81ee868e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... for the same function
Task-number: QTCREATORBUG-5748
Change-Id: Iadf5be76c24f95cf057c2112a8248bea2a9e20cf
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
And not from the global object pool. This way, the editors that have
different highlighters for various language dialects, or editors that
support multiple languages in a single editor, can decide themselves on
what CompletionAssistProvider to provide.
Change-Id: Ieebc4a8e7b3de6470fdb8103035aa3b8b2ba6598
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
