llvm-project/lldb/source/Utility/CompletionRequest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

82 lines
3.1 KiB
C++
Raw Normal View History

//===-- CompletionRequest.cpp ---------------------------------------------===//
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Refactoring for for the internal command line completion API (NFC) Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
2018-07-03 05:29:56 +08:00
//
//===----------------------------------------------------------------------===//
#include "lldb/Utility/CompletionRequest.h"
using namespace lldb;
using namespace lldb_private;
CompletionRequest::CompletionRequest(llvm::StringRef command_line,
unsigned raw_cursor_pos,
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
CompletionResult &result)
: m_command(command_line), m_raw_cursor_pos(raw_cursor_pos),
m_result(result) {
assert(raw_cursor_pos <= command_line.size() && "Out of bounds cursor?");
// We parse the argument up to the cursor, so the last argument in
// parsed_line is the one containing the cursor, and the cursor is after the
// last character.
llvm::StringRef partial_command(command_line.substr(0, raw_cursor_pos));
m_parsed_line = Args(partial_command);
if (GetParsedLine().GetArgumentCount() == 0) {
m_cursor_index = 0;
m_cursor_char_position = 0;
} else {
m_cursor_index = GetParsedLine().GetArgumentCount() - 1U;
m_cursor_char_position =
strlen(GetParsedLine().GetArgumentAtIndex(m_cursor_index));
}
// The cursor is after a space but the space is not part of the argument.
// Let's add an empty fake argument to the end to make sure the completion
// code. Note: The space could be part of the last argument when it's quoted.
if (partial_command.endswith(" ") &&
!GetCursorArgumentPrefix().endswith(" "))
AppendEmptyArgument();
}
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
std::string CompletionResult::Completion::GetUniqueKey() const {
// We build a unique key for this pair of completion:description. We
// prefix the key with the length of the completion string. This prevents
// that we could get any collisions from completions pairs such as these:
// "foo:", "bar" would be "foo:bar", but will now be: "4foo:bar"
// "foo", ":bar" would be "foo:bar", but will now be: "3foo:bar"
std::string result;
result.append(std::to_string(m_completion.size()));
result.append(m_completion);
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
2019-08-22 15:41:23 +08:00
result.append(std::to_string(static_cast<int>(m_mode)));
result.append(":");
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
result.append(m_descripton);
return result;
}
void CompletionResult::AddResult(llvm::StringRef completion,
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
2019-08-22 15:41:23 +08:00
llvm::StringRef description,
CompletionMode mode) {
Completion r(completion, description, mode);
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
// Add the completion if we haven't seen the same value before.
if (m_added_values.insert(r.GetUniqueKey()).second)
m_results.push_back(r);
}
void CompletionResult::GetMatches(StringList &matches) const {
matches.Clear();
for (const Completion &completion : m_results)
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
2019-08-22 15:41:23 +08:00
matches.AppendString(completion.GetCompletion());
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
}
void CompletionResult::GetDescriptions(StringList &descriptions) const {
descriptions.Clear();
for (const Completion &completion : m_results)
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
2019-08-22 15:41:23 +08:00
descriptions.AppendString(completion.GetDescription());
Add support for descriptions with command completions. Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
2018-09-14 05:26:00 +08:00
}