[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
|
|
|
//===-- CompletionRequestTest.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
|
|
|
//
|
2019-01-19 16:50: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 "gtest/gtest.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Utility/CompletionRequest.h"
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
TEST(CompletionRequest, Constructor) {
|
2018-07-14 02:28:14 +08:00
|
|
|
std::string command = "a bad c";
|
|
|
|
|
const unsigned cursor_pos = 3;
|
2019-09-23 17:46:17 +08:00
|
|
|
const size_t arg_index = 1;
|
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
|
|
|
StringList matches;
|
2018-09-14 05:26:00 +08:00
|
|
|
CompletionResult result;
|
2018-07-14 02:28:14 +08:00
|
|
|
|
2019-07-31 11:48:29 +08:00
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
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
|
|
|
|
2020-01-28 17:21:30 +08:00
|
|
|
EXPECT_EQ(request.GetRawLine(), "a b");
|
|
|
|
|
EXPECT_EQ(request.GetRawLineWithUnusedSuffix(), command);
|
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
|
|
|
EXPECT_EQ(request.GetRawCursorPos(), cursor_pos);
|
|
|
|
|
EXPECT_EQ(request.GetCursorIndex(), arg_index);
|
2018-07-14 02:28:14 +08:00
|
|
|
|
2019-09-24 15:22:44 +08:00
|
|
|
EXPECT_EQ(request.GetParsedLine().GetArgumentCount(), 2u);
|
2019-09-25 20:40:01 +08:00
|
|
|
EXPECT_EQ(request.GetCursorArgumentPrefix().str(), "b");
|
2018-07-28 02:42:46 +08:00
|
|
|
}
|
|
|
|
|
|
2019-09-23 17:46:17 +08:00
|
|
|
TEST(CompletionRequest, FakeLastArg) {
|
|
|
|
|
// We insert an empty fake argument into the argument list when the
|
|
|
|
|
// cursor is after a space.
|
|
|
|
|
std::string command = "a bad c ";
|
|
|
|
|
const unsigned cursor_pos = command.size();
|
|
|
|
|
CompletionResult result;
|
|
|
|
|
|
|
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
|
|
|
|
|
2020-01-28 17:21:30 +08:00
|
|
|
EXPECT_EQ(request.GetRawLine(), command);
|
|
|
|
|
EXPECT_EQ(request.GetRawLineWithUnusedSuffix(), command);
|
2019-09-23 17:46:17 +08:00
|
|
|
EXPECT_EQ(request.GetRawCursorPos(), cursor_pos);
|
|
|
|
|
EXPECT_EQ(request.GetCursorIndex(), 3U);
|
|
|
|
|
|
2019-09-24 15:22:44 +08:00
|
|
|
EXPECT_EQ(request.GetParsedLine().GetArgumentCount(), 4U);
|
2019-09-25 20:40:01 +08:00
|
|
|
EXPECT_EQ(request.GetCursorArgumentPrefix().str(), "");
|
2019-09-23 17:46:17 +08:00
|
|
|
}
|
|
|
|
|
|
2019-09-23 16:59:21 +08:00
|
|
|
TEST(CompletionRequest, TryCompleteCurrentArgGood) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
StringList matches, descriptions;
|
|
|
|
|
CompletionResult result;
|
|
|
|
|
|
|
|
|
|
CompletionRequest request(command, 3, result);
|
|
|
|
|
request.TryCompleteCurrentArg("boo", "car");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
|
|
|
|
EXPECT_EQ(1U, result.GetResults().size());
|
|
|
|
|
EXPECT_STREQ("boo", matches.GetStringAtIndex(0U));
|
|
|
|
|
EXPECT_EQ(1U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("car", descriptions.GetStringAtIndex(0U));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(CompletionRequest, TryCompleteCurrentArgBad) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
CompletionResult result;
|
|
|
|
|
|
|
|
|
|
CompletionRequest request(command, 3, result);
|
|
|
|
|
request.TryCompleteCurrentArg("car", "card");
|
|
|
|
|
|
|
|
|
|
EXPECT_EQ(0U, result.GetResults().size());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(CompletionRequest, TryCompleteCurrentArgMode) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
CompletionResult result;
|
|
|
|
|
|
|
|
|
|
CompletionRequest request(command, 3, result);
|
|
|
|
|
request.TryCompleteCurrentArg<CompletionMode::Partial>("bar", "bard");
|
|
|
|
|
|
|
|
|
|
EXPECT_EQ(1U, result.GetResults().size());
|
|
|
|
|
EXPECT_EQ(CompletionMode::Partial, result.GetResults()[0].GetMode());
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-23 16:16:19 +08:00
|
|
|
TEST(CompletionRequest, ShiftArguments) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
const unsigned cursor_pos = 3;
|
2019-09-23 17:46:17 +08:00
|
|
|
const size_t arg_index = 1;
|
2019-09-23 16:16:19 +08:00
|
|
|
StringList matches;
|
|
|
|
|
CompletionResult result;
|
|
|
|
|
|
|
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2020-01-28 17:21:30 +08:00
|
|
|
EXPECT_EQ(request.GetRawLine(), "a b");
|
|
|
|
|
EXPECT_EQ(request.GetRawLineWithUnusedSuffix(), command);
|
2019-09-23 16:16:19 +08:00
|
|
|
EXPECT_EQ(request.GetRawCursorPos(), cursor_pos);
|
|
|
|
|
EXPECT_EQ(request.GetCursorIndex(), arg_index);
|
|
|
|
|
|
2019-09-24 15:22:44 +08:00
|
|
|
EXPECT_EQ(request.GetParsedLine().GetArgumentCount(), 2u);
|
|
|
|
|
EXPECT_STREQ(request.GetParsedLine().GetArgumentAtIndex(1), "b");
|
2019-09-23 16:16:19 +08:00
|
|
|
|
|
|
|
|
// Shift away the 'a' argument.
|
|
|
|
|
request.ShiftArguments();
|
|
|
|
|
|
|
|
|
|
// The raw line/cursor stays identical.
|
2020-01-28 17:21:30 +08:00
|
|
|
EXPECT_EQ(request.GetRawLine(), "a b");
|
|
|
|
|
EXPECT_EQ(request.GetRawLineWithUnusedSuffix(), command);
|
2019-09-23 16:16:19 +08:00
|
|
|
EXPECT_EQ(request.GetRawCursorPos(), cursor_pos);
|
|
|
|
|
|
|
|
|
|
// Partially parsed line and cursor should be updated.
|
|
|
|
|
EXPECT_EQ(request.GetCursorIndex(), arg_index - 1U);
|
2019-09-24 15:22:44 +08:00
|
|
|
EXPECT_EQ(request.GetParsedLine().GetArgumentCount(), 1u);
|
2019-09-25 20:40:01 +08:00
|
|
|
EXPECT_EQ(request.GetCursorArgumentPrefix().str(), "b");
|
2019-09-23 16:16:19 +08:00
|
|
|
}
|
|
|
|
|
|
2018-07-28 02:42:46 +08:00
|
|
|
TEST(CompletionRequest, DuplicateFiltering) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
const unsigned cursor_pos = 3;
|
|
|
|
|
StringList matches;
|
|
|
|
|
|
2018-09-14 05:26:00 +08:00
|
|
|
CompletionResult result;
|
2019-07-31 11:48:29 +08:00
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
2018-07-28 02:42:46 +08:00
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(0U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
|
|
|
|
|
// Add foo twice
|
|
|
|
|
request.AddCompletion("foo");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(1U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(1U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
|
|
|
|
|
request.AddCompletion("foo");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(1U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(1U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
|
|
|
|
|
// Add bar twice
|
|
|
|
|
request.AddCompletion("bar");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(2U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(2U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
|
|
|
|
|
request.AddCompletion("bar");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(2U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(2U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
|
|
|
|
|
// Add foo again.
|
|
|
|
|
request.AddCompletion("foo");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(2U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(2U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
|
|
|
|
|
// Add something with an existing prefix
|
|
|
|
|
request.AddCompletion("foobar");
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(3U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_EQ(3U, matches.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
EXPECT_STREQ("foobar", matches.GetStringAtIndex(2));
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-14 05:26:00 +08:00
|
|
|
TEST(CompletionRequest, DuplicateFilteringWithComments) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
const unsigned cursor_pos = 3;
|
|
|
|
|
StringList matches, descriptions;
|
|
|
|
|
|
|
|
|
|
CompletionResult result;
|
2019-07-31 11:48:29 +08:00
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(0U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
|
|
|
|
|
// Add foo twice with same comment
|
|
|
|
|
request.AddCompletion("foo", "comment");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(1U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
EXPECT_EQ(1U, matches.GetSize());
|
|
|
|
|
EXPECT_EQ(1U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(0));
|
|
|
|
|
|
|
|
|
|
request.AddCompletion("foo", "comment");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(1U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
EXPECT_EQ(1U, matches.GetSize());
|
|
|
|
|
EXPECT_EQ(1U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(0));
|
|
|
|
|
|
|
|
|
|
// Add bar twice with different comments
|
|
|
|
|
request.AddCompletion("bar", "comment");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(2U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
EXPECT_EQ(2U, matches.GetSize());
|
|
|
|
|
EXPECT_EQ(2U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
|
|
|
|
|
request.AddCompletion("bar", "another comment");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(3U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
EXPECT_EQ(3U, matches.GetSize());
|
|
|
|
|
EXPECT_EQ(3U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(1));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(2));
|
|
|
|
|
EXPECT_STREQ("another comment", descriptions.GetStringAtIndex(2));
|
|
|
|
|
|
|
|
|
|
// Add foo again with no comment
|
|
|
|
|
request.AddCompletion("foo");
|
|
|
|
|
result.GetMatches(matches);
|
|
|
|
|
result.GetDescriptions(descriptions);
|
|
|
|
|
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(4U, result.GetNumberOfResults());
|
2018-09-14 05:26:00 +08:00
|
|
|
EXPECT_EQ(4U, matches.GetSize());
|
|
|
|
|
EXPECT_EQ(4U, descriptions.GetSize());
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(0));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(1));
|
|
|
|
|
EXPECT_STREQ("comment", descriptions.GetStringAtIndex(1));
|
|
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(2));
|
|
|
|
|
EXPECT_STREQ("another comment", descriptions.GetStringAtIndex(2));
|
|
|
|
|
EXPECT_STREQ("foo", matches.GetStringAtIndex(3));
|
|
|
|
|
EXPECT_STREQ("", descriptions.GetStringAtIndex(3));
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-28 02:42:46 +08:00
|
|
|
TEST(CompletionRequest, TestCompletionOwnership) {
|
|
|
|
|
std::string command = "a bad c";
|
|
|
|
|
const unsigned cursor_pos = 3;
|
|
|
|
|
StringList matches;
|
|
|
|
|
|
2018-09-14 05:26:00 +08:00
|
|
|
CompletionResult result;
|
2019-07-31 11:48:29 +08:00
|
|
|
CompletionRequest request(command, cursor_pos, result);
|
2018-07-28 02:42:46 +08:00
|
|
|
|
|
|
|
|
std::string Temporary = "bar";
|
|
|
|
|
request.AddCompletion(Temporary);
|
|
|
|
|
// Manipulate our completion. The request should have taken a copy, so that
|
|
|
|
|
// shouldn't influence anything.
|
|
|
|
|
Temporary[0] = 'f';
|
2018-07-14 02:28:14 +08:00
|
|
|
|
2018-09-14 05:26:00 +08:00
|
|
|
result.GetMatches(matches);
|
2019-08-19 22:52:48 +08:00
|
|
|
EXPECT_EQ(1U, result.GetNumberOfResults());
|
2018-07-28 02:42:46 +08:00
|
|
|
EXPECT_STREQ("bar", matches.GetStringAtIndex(0));
|
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
|
|
|
}
|