[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
|
|
|
//===-- CommandCompletions.cpp --------------------------------------------===//
|
2010-06-09 00:52:24 +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
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2017-03-13 08:41:01 +08:00
|
|
|
#include "llvm/ADT/StringSet.h"
|
2016-02-20 03:33:46 +08:00
|
|
|
|
2011-02-01 13:15:22 +08:00
|
|
|
#include "lldb/Core/FileSpecList.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-30 05:13:06 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
2016-03-23 01:58:09 +08:00
|
|
|
#include "lldb/Core/PluginManager.h"
|
|
|
|
#include "lldb/Host/FileSystem.h"
|
2011-02-01 13:15:22 +08:00
|
|
|
#include "lldb/Interpreter/CommandCompletions.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
2015-03-04 09:58:01 +08:00
|
|
|
#include "lldb/Interpreter/OptionValueProperties.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-30 05:13:06 +08:00
|
|
|
#include "lldb/Symbol/CompileUnit.h"
|
2013-05-15 07:43:18 +08:00
|
|
|
#include "lldb/Symbol/Variable.h"
|
2017-03-23 02:40:07 +08:00
|
|
|
#include "lldb/Utility/FileSpec.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-03-13 08:41:01 +08:00
|
|
|
#include "lldb/Utility/TildeExpressionResolver.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2017-03-09 01:56:08 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2017-03-13 08:41:01 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2016-03-23 01:58:09 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
CommandCompletions::CommonCompletionElement
|
|
|
|
CommandCompletions::g_common_completions[] = {
|
2016-02-20 03:33:46 +08:00
|
|
|
{eCustomCompletion, nullptr},
|
2010-06-30 13:02:46 +08:00
|
|
|
{eSourceFileCompletion, CommandCompletions::SourceFiles},
|
|
|
|
{eDiskFileCompletion, CommandCompletions::DiskFiles},
|
|
|
|
{eDiskDirectoryCompletion, CommandCompletions::DiskDirectories},
|
|
|
|
{eSymbolCompletion, CommandCompletions::Symbols},
|
|
|
|
{eModuleCompletion, CommandCompletions::Modules},
|
2010-09-04 08:03:46 +08:00
|
|
|
{eSettingsNameCompletion, CommandCompletions::SettingsNames},
|
2011-04-14 06:47:15 +08:00
|
|
|
{ePlatformPluginCompletion, CommandCompletions::PlatformPluginNames},
|
|
|
|
{eArchitectureCompletion, CommandCompletions::ArchitectureNames},
|
2013-05-15 07:43:18 +08:00
|
|
|
{eVariablePathCompletion, CommandCompletions::VariablePath},
|
2016-02-20 03:33:46 +08:00
|
|
|
{eNoCompletion, nullptr} // This one has to be last in the list.
|
2010-06-09 00:52:24 +08:00
|
|
|
};
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
bool CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
CommandInterpreter &interpreter, uint32_t completion_mask,
|
2018-07-14 02:28:14 +08:00
|
|
|
CompletionRequest &request, SearchFilter *searcher) {
|
2010-06-09 00:52:24 +08:00
|
|
|
bool handled = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (completion_mask & eCustomCompletion)
|
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
for (int i = 0;; i++) {
|
|
|
|
if (g_common_completions[i].type == eNoCompletion)
|
|
|
|
break;
|
|
|
|
else if ((g_common_completions[i].type & completion_mask) ==
|
|
|
|
g_common_completions[i].type &&
|
2016-02-20 03:33:46 +08:00
|
|
|
g_common_completions[i].callback != nullptr) {
|
2010-06-09 00:52:24 +08:00
|
|
|
handled = true;
|
2018-07-14 02:28:14 +08:00
|
|
|
g_common_completions[i].callback(interpreter, request, searcher);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return handled;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::SourceFiles(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
2010-06-09 00:52:24 +08:00
|
|
|
// Find some way to switch "include support files..."
|
2018-07-14 02:28:14 +08:00
|
|
|
SourceFileCompleter completer(interpreter, false, request);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
if (searcher == nullptr) {
|
2010-08-27 05:32:51 +08:00
|
|
|
lldb::TargetSP target_sp = interpreter.GetDebugger().GetSelectedTarget();
|
2014-12-06 09:28:03 +08:00
|
|
|
SearchFilterForUnconstrainedSearches null_searcher(target_sp);
|
2010-06-09 00:52:24 +08:00
|
|
|
completer.DoCompletion(&null_searcher);
|
|
|
|
} else {
|
|
|
|
completer.DoCompletion(searcher);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
static void DiskFilesOrDirectories(const llvm::Twine &partial_name,
|
2019-08-27 19:32:22 +08:00
|
|
|
bool only_directories,
|
|
|
|
CompletionRequest &request,
|
[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
|
|
|
TildeExpressionResolver &Resolver) {
|
2017-03-13 08:41:01 +08:00
|
|
|
llvm::SmallString<256> CompletionBuffer;
|
|
|
|
llvm::SmallString<256> Storage;
|
|
|
|
partial_name.toVector(CompletionBuffer);
|
|
|
|
|
|
|
|
if (CompletionBuffer.size() >= PATH_MAX)
|
[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
|
|
|
return;
|
2017-03-13 08:41:01 +08:00
|
|
|
|
|
|
|
namespace path = llvm::sys::path;
|
|
|
|
|
|
|
|
llvm::StringRef SearchDir;
|
|
|
|
llvm::StringRef PartialItem;
|
|
|
|
|
|
|
|
if (CompletionBuffer.startswith("~")) {
|
|
|
|
llvm::StringRef Buffer(CompletionBuffer);
|
2017-03-17 06:28:04 +08:00
|
|
|
size_t FirstSep =
|
|
|
|
Buffer.find_if([](char c) { return path::is_separator(c); });
|
2017-03-13 08:41:01 +08:00
|
|
|
|
|
|
|
llvm::StringRef Username = Buffer.take_front(FirstSep);
|
|
|
|
llvm::StringRef Remainder;
|
|
|
|
if (FirstSep != llvm::StringRef::npos)
|
|
|
|
Remainder = Buffer.drop_front(FirstSep + 1);
|
|
|
|
|
2018-12-11 01:23:28 +08:00
|
|
|
llvm::SmallString<256> Resolved;
|
2017-03-13 08:41:01 +08:00
|
|
|
if (!Resolver.ResolveExact(Username, Resolved)) {
|
|
|
|
// We couldn't resolve it as a full username. If there were no slashes
|
|
|
|
// then this might be a partial username. We try to resolve it as such
|
|
|
|
// but after that, we're done regardless of any matches.
|
|
|
|
if (FirstSep == llvm::StringRef::npos) {
|
|
|
|
llvm::StringSet<> MatchSet;
|
2018-07-14 02:28:14 +08:00
|
|
|
Resolver.ResolvePartial(Username, MatchSet);
|
2017-03-13 08:41:01 +08:00
|
|
|
for (const auto &S : MatchSet) {
|
|
|
|
Resolved = S.getKey();
|
|
|
|
path::append(Resolved, path::get_separator());
|
2019-08-27 19:32:22 +08:00
|
|
|
request.AddCompletion(Resolved, "", CompletionMode::Partial);
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
|
|
|
}
|
[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
|
|
|
return;
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// If there was no trailing slash, then we're done as soon as we resolve
|
|
|
|
// the expression to the correct directory. Otherwise we need to continue
|
2017-03-13 08:41:01 +08:00
|
|
|
// looking for matches within that directory.
|
|
|
|
if (FirstSep == llvm::StringRef::npos) {
|
|
|
|
// Make sure it ends with a separator.
|
|
|
|
path::append(CompletionBuffer, path::get_separator());
|
2019-08-27 19:32:22 +08:00
|
|
|
request.AddCompletion(CompletionBuffer, "", CompletionMode::Partial);
|
[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
|
|
|
return;
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
// We want to keep the form the user typed, so we special case this to
|
|
|
|
// search in the fully resolved directory, but CompletionBuffer keeps the
|
|
|
|
// unmodified form that the user typed.
|
|
|
|
Storage = Resolved;
|
2018-06-29 18:27:18 +08:00
|
|
|
llvm::StringRef RemainderDir = path::parent_path(Remainder);
|
2018-06-19 04:11:38 +08:00
|
|
|
if (!RemainderDir.empty()) {
|
|
|
|
// Append the remaining path to the resolved directory.
|
|
|
|
Storage.append(path::get_separator());
|
|
|
|
Storage.append(RemainderDir);
|
|
|
|
}
|
2018-01-22 17:17:16 +08:00
|
|
|
SearchDir = Storage;
|
2017-03-13 08:41:01 +08:00
|
|
|
} else {
|
|
|
|
SearchDir = path::parent_path(CompletionBuffer);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
size_t FullPrefixLen = CompletionBuffer.size();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
PartialItem = path::filename(CompletionBuffer);
|
2018-09-01 07:03:28 +08:00
|
|
|
|
|
|
|
// path::filename() will return "." when the passed path ends with a
|
|
|
|
// directory separator. We have to filter those out, but only when the
|
|
|
|
// "." doesn't come from the completion request itself.
|
|
|
|
if (PartialItem == "." && path::is_separator(CompletionBuffer.back()))
|
2017-03-13 08:41:01 +08:00
|
|
|
PartialItem = llvm::StringRef();
|
2013-08-23 20:44:05 +08:00
|
|
|
|
2017-04-15 10:44:53 +08:00
|
|
|
if (SearchDir.empty()) {
|
|
|
|
llvm::sys::fs::current_path(Storage);
|
|
|
|
SearchDir = Storage;
|
|
|
|
}
|
2017-03-13 08:41:01 +08:00
|
|
|
assert(!PartialItem.contains(path::get_separator()));
|
2013-08-23 20:44:05 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
// SearchDir now contains the directory to search in, and Prefix contains the
|
|
|
|
// text we want to match against items in that directory.
|
2013-08-23 20:44:05 +08:00
|
|
|
|
2018-12-05 01:58:21 +08:00
|
|
|
FileSystem &fs = FileSystem::Instance();
|
2017-03-13 08:41:01 +08:00
|
|
|
std::error_code EC;
|
2018-12-05 01:58:21 +08:00
|
|
|
llvm::vfs::directory_iterator Iter = fs.DirBegin(SearchDir, EC);
|
|
|
|
llvm::vfs::directory_iterator End;
|
2017-03-13 08:41:01 +08:00
|
|
|
for (; Iter != End && !EC; Iter.increment(EC)) {
|
|
|
|
auto &Entry = *Iter;
|
2018-12-05 01:58:21 +08:00
|
|
|
llvm::ErrorOr<llvm::vfs::Status> Status = fs.GetStatus(Entry.path());
|
|
|
|
|
|
|
|
if (!Status)
|
|
|
|
continue;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
auto Name = path::filename(Entry.path());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
// Omit ".", ".."
|
|
|
|
if (Name == "." || Name == ".." || !Name.startswith(PartialItem))
|
|
|
|
continue;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-12-05 01:58:21 +08:00
|
|
|
bool is_dir = Status->isDirectory();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
// If it's a symlink, then we treat it as a directory as long as the target
|
|
|
|
// is a directory.
|
2018-12-05 01:58:21 +08:00
|
|
|
if (Status->isSymlink()) {
|
|
|
|
FileSpec symlink_filespec(Entry.path());
|
|
|
|
FileSpec resolved_filespec;
|
|
|
|
auto error = fs.ResolveSymbolicLink(symlink_filespec, resolved_filespec);
|
|
|
|
if (error.Success())
|
|
|
|
is_dir = fs.IsDirectory(symlink_filespec);
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
2018-12-05 01:58:21 +08:00
|
|
|
|
2017-03-13 08:41:01 +08:00
|
|
|
if (only_directories && !is_dir)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Shrink it back down so that it just has the original prefix the user
|
|
|
|
// typed and remove the part of the name which is common to the located
|
|
|
|
// item and what the user typed.
|
|
|
|
CompletionBuffer.resize(FullPrefixLen);
|
|
|
|
Name = Name.drop_front(PartialItem.size());
|
|
|
|
CompletionBuffer.append(Name);
|
|
|
|
|
|
|
|
if (is_dir) {
|
|
|
|
path::append(CompletionBuffer, path::get_separator());
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-08-27 19:32:22 +08:00
|
|
|
CompletionMode mode =
|
|
|
|
is_dir ? CompletionMode::Partial : CompletionMode::Normal;
|
|
|
|
request.AddCompletion(CompletionBuffer, "", mode);
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
2010-06-30 13:02:46 +08:00
|
|
|
}
|
|
|
|
|
2019-08-27 19:32:22 +08:00
|
|
|
static void DiskFilesOrDirectories(const llvm::Twine &partial_name,
|
|
|
|
bool only_directories, StringList &matches,
|
|
|
|
TildeExpressionResolver &Resolver) {
|
|
|
|
CompletionResult result;
|
|
|
|
std::string partial_name_str = partial_name.str();
|
|
|
|
CompletionRequest request(partial_name_str, partial_name_str.size(), result);
|
|
|
|
DiskFilesOrDirectories(partial_name, only_directories, request, Resolver);
|
|
|
|
result.GetMatches(matches);
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
static void DiskFilesOrDirectories(CompletionRequest &request,
|
|
|
|
bool only_directories) {
|
2018-11-09 09:59:28 +08:00
|
|
|
StandardTildeExpressionResolver resolver;
|
2018-07-28 02:42:46 +08:00
|
|
|
DiskFilesOrDirectories(request.GetCursorArgumentPrefix(), only_directories,
|
2019-08-27 19:32:22 +08:00
|
|
|
request, resolver);
|
2018-07-28 02:42:46 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::DiskFiles(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
|
|
|
DiskFilesOrDirectories(request, /*only_dirs*/ false);
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::DiskFiles(const llvm::Twine &partial_file_name,
|
|
|
|
StringList &matches,
|
|
|
|
TildeExpressionResolver &Resolver) {
|
|
|
|
DiskFilesOrDirectories(partial_file_name, false, matches, Resolver);
|
2010-06-30 13:02:46 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::DiskDirectories(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
|
|
|
DiskFilesOrDirectories(request, /*only_dirs*/ true);
|
2017-03-13 08:41:01 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::DiskDirectories(const llvm::Twine &partial_file_name,
|
|
|
|
StringList &matches,
|
|
|
|
TildeExpressionResolver &Resolver) {
|
|
|
|
DiskFilesOrDirectories(partial_file_name, true, matches, Resolver);
|
2010-06-30 13:02:46 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::Modules(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
2018-07-14 02:28:14 +08:00
|
|
|
ModuleCompleter completer(interpreter, request);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
if (searcher == nullptr) {
|
2010-08-27 05:32:51 +08:00
|
|
|
lldb::TargetSP target_sp = interpreter.GetDebugger().GetSelectedTarget();
|
2014-12-06 09:28:03 +08:00
|
|
|
SearchFilterForUnconstrainedSearches null_searcher(target_sp);
|
2010-06-09 00:52:24 +08:00
|
|
|
completer.DoCompletion(&null_searcher);
|
|
|
|
} else {
|
|
|
|
completer.DoCompletion(searcher);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::Symbols(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
2018-07-14 02:28:14 +08:00
|
|
|
SymbolCompleter completer(interpreter, request);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
if (searcher == nullptr) {
|
2010-08-27 05:32:51 +08:00
|
|
|
lldb::TargetSP target_sp = interpreter.GetDebugger().GetSelectedTarget();
|
2014-12-06 09:28:03 +08:00
|
|
|
SearchFilterForUnconstrainedSearches null_searcher(target_sp);
|
2010-06-09 00:52:24 +08:00
|
|
|
completer.DoCompletion(&null_searcher);
|
|
|
|
} else {
|
|
|
|
completer.DoCompletion(searcher);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::SettingsNames(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
2012-08-23 01:17:09 +08:00
|
|
|
// Cache the full setting name list
|
|
|
|
static StringList g_property_names;
|
|
|
|
if (g_property_names.GetSize() == 0) {
|
|
|
|
// Generate the full setting name list on demand
|
|
|
|
lldb::OptionValuePropertiesSP properties_sp(
|
|
|
|
interpreter.GetDebugger().GetValueProperties());
|
|
|
|
if (properties_sp) {
|
|
|
|
StreamString strm;
|
2016-02-20 03:33:46 +08:00
|
|
|
properties_sp->DumpValue(nullptr, strm, OptionValue::eDumpOptionName);
|
2012-08-23 01:17:09 +08:00
|
|
|
const std::string &str = strm.GetString();
|
|
|
|
g_property_names.SplitIntoLines(str.c_str(), str.size());
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2019-09-23 16:59:21 +08:00
|
|
|
for (const std::string &s : g_property_names)
|
|
|
|
request.TryCompleteCurrentArg(s);
|
2010-09-04 08:03:46 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::PlatformPluginNames(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
|
|
|
PluginManager::AutoCompletePlatformName(request.GetCursorArgumentPrefix(),
|
|
|
|
request);
|
2011-04-14 06:47:15 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::ArchitectureNames(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
|
|
|
ArchSpec::AutoComplete(request);
|
2011-04-14 06:47:15 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::VariablePath(CommandInterpreter &interpreter,
|
|
|
|
CompletionRequest &request,
|
|
|
|
SearchFilter *searcher) {
|
|
|
|
Variable::AutoComplete(interpreter.GetExecutionContext(), request);
|
2013-05-15 07:43:18 +08:00
|
|
|
}
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
CommandCompletions::Completer::Completer(CommandInterpreter &interpreter,
|
2018-07-14 02:28:14 +08:00
|
|
|
CompletionRequest &request)
|
|
|
|
: m_interpreter(interpreter), m_request(request) {}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
CommandCompletions::Completer::~Completer() = default;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
// SourceFileCompleter
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
CommandCompletions::SourceFileCompleter::SourceFileCompleter(
|
|
|
|
CommandInterpreter &interpreter, bool include_support_files,
|
2018-07-14 02:28:14 +08:00
|
|
|
CompletionRequest &request)
|
|
|
|
: CommandCompletions::Completer(interpreter, request),
|
2010-06-09 00:52:24 +08:00
|
|
|
m_include_support_files(include_support_files), m_matching_files() {
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec partial_spec(m_request.GetCursorArgumentPrefix());
|
2010-06-09 00:52:24 +08:00
|
|
|
m_file_name = partial_spec.GetFilename().GetCString();
|
|
|
|
m_dir_name = partial_spec.GetDirectory().GetCString();
|
|
|
|
}
|
|
|
|
|
2018-09-08 02:43:04 +08:00
|
|
|
lldb::SearchDepth CommandCompletions::SourceFileCompleter::GetDepth() {
|
|
|
|
return lldb::eSearchDepthCompUnit;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Searcher::CallbackReturn
|
2016-02-20 03:33:46 +08:00
|
|
|
CommandCompletions::SourceFileCompleter::SearchCallback(SearchFilter &filter,
|
|
|
|
SymbolContext &context,
|
2019-10-10 19:26:51 +08:00
|
|
|
Address *addr) {
|
2016-02-20 03:33:46 +08:00
|
|
|
if (context.comp_unit != nullptr) {
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_include_support_files) {
|
|
|
|
FileSpecList supporting_files = context.comp_unit->GetSupportFiles();
|
|
|
|
for (size_t sfiles = 0; sfiles < supporting_files.GetSize(); sfiles++) {
|
|
|
|
const FileSpec &sfile_spec =
|
|
|
|
supporting_files.GetFileSpecAtIndex(sfiles);
|
|
|
|
const char *sfile_file_name = sfile_spec.GetFilename().GetCString();
|
|
|
|
const char *sfile_dir_name = sfile_spec.GetFilename().GetCString();
|
|
|
|
bool match = false;
|
|
|
|
if (m_file_name && sfile_file_name &&
|
|
|
|
strstr(sfile_file_name, m_file_name) == sfile_file_name)
|
|
|
|
match = true;
|
|
|
|
if (match && m_dir_name && sfile_dir_name &&
|
|
|
|
strstr(sfile_dir_name, m_dir_name) != sfile_dir_name)
|
|
|
|
match = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (match) {
|
|
|
|
m_matching_files.AppendIfUnique(sfile_spec);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
2019-11-28 23:22:44 +08:00
|
|
|
const char *cur_file_name =
|
|
|
|
context.comp_unit->GetPrimaryFile().GetFilename().GetCString();
|
|
|
|
const char *cur_dir_name =
|
|
|
|
context.comp_unit->GetPrimaryFile().GetDirectory().GetCString();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
bool match = false;
|
|
|
|
if (m_file_name && cur_file_name &&
|
|
|
|
strstr(cur_file_name, m_file_name) == cur_file_name)
|
|
|
|
match = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (match && m_dir_name && cur_dir_name &&
|
|
|
|
strstr(cur_dir_name, m_dir_name) != cur_dir_name)
|
|
|
|
match = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (match) {
|
2019-11-28 23:22:44 +08:00
|
|
|
m_matching_files.AppendIfUnique(context.comp_unit->GetPrimaryFile());
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return Searcher::eCallbackReturnContinue;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::SourceFileCompleter::DoCompletion(
|
|
|
|
SearchFilter *filter) {
|
2010-06-09 00:52:24 +08:00
|
|
|
filter->Search(*this);
|
|
|
|
// Now convert the filelist to completions:
|
|
|
|
for (size_t i = 0; i < m_matching_files.GetSize(); i++) {
|
2018-07-28 02:42:46 +08:00
|
|
|
m_request.AddCompletion(
|
2010-06-09 00:52:24 +08:00
|
|
|
m_matching_files.GetFileSpecAtIndex(i).GetFilename().GetCString());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// SymbolCompleter
|
|
|
|
|
|
|
|
static bool regex_chars(const char comp) {
|
2019-11-29 19:26:33 +08:00
|
|
|
return llvm::StringRef("[](){}+.*|^$\\?").contains(comp);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-02-20 03:33:46 +08:00
|
|
|
|
|
|
|
CommandCompletions::SymbolCompleter::SymbolCompleter(
|
2018-07-14 02:28:14 +08:00
|
|
|
CommandInterpreter &interpreter, CompletionRequest &request)
|
|
|
|
: CommandCompletions::Completer(interpreter, request) {
|
2013-06-07 08:35:40 +08:00
|
|
|
std::string regex_str;
|
2018-07-14 02:28:14 +08:00
|
|
|
if (!m_request.GetCursorArgumentPrefix().empty()) {
|
2013-06-07 08:35:40 +08:00
|
|
|
regex_str.append("^");
|
2018-07-14 02:28:14 +08:00
|
|
|
regex_str.append(m_request.GetCursorArgumentPrefix());
|
2013-06-07 08:35:40 +08:00
|
|
|
} else {
|
|
|
|
// Match anything since the completion string is empty
|
|
|
|
regex_str.append(".");
|
|
|
|
}
|
|
|
|
std::string::iterator pos =
|
|
|
|
find_if(regex_str.begin() + 1, regex_str.end(), regex_chars);
|
|
|
|
while (pos < regex_str.end()) {
|
2010-06-09 00:52:24 +08:00
|
|
|
pos = regex_str.insert(pos, '\\');
|
2013-06-07 08:35:40 +08:00
|
|
|
pos = find_if(pos + 2, regex_str.end(), regex_chars);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2019-08-20 17:24:20 +08:00
|
|
|
m_regex = RegularExpression(regex_str);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2018-09-08 02:43:04 +08:00
|
|
|
lldb::SearchDepth CommandCompletions::SymbolCompleter::GetDepth() {
|
|
|
|
return lldb::eSearchDepthModule;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
Searcher::CallbackReturn CommandCompletions::SymbolCompleter::SearchCallback(
|
2019-10-10 19:26:51 +08:00
|
|
|
SearchFilter &filter, SymbolContext &context, Address *addr) {
|
2011-01-27 14:44:37 +08:00
|
|
|
if (context.module_sp) {
|
|
|
|
SymbolContextList sc_list;
|
|
|
|
const bool include_symbols = true;
|
2012-02-11 06:52:19 +08:00
|
|
|
const bool include_inlines = true;
|
|
|
|
context.module_sp->FindFunctions(m_regex, include_symbols, include_inlines,
|
2019-10-18 03:56:40 +08:00
|
|
|
sc_list);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
SymbolContext sc;
|
|
|
|
// Now add the functions & symbols to the list - only add if unique:
|
2011-01-27 14:44:37 +08:00
|
|
|
for (uint32_t i = 0; i < sc_list.GetSize(); i++) {
|
|
|
|
if (sc_list.GetContextAtIndex(i, sc)) {
|
2011-09-28 03:48:20 +08:00
|
|
|
ConstString func_name = sc.GetFunctionName(Mangled::ePreferDemangled);
|
2019-08-01 01:58:00 +08:00
|
|
|
// Ensure that the function name matches the regex. This is more than a
|
|
|
|
// sanity check. It is possible that the demangled function name does
|
|
|
|
// not start with the prefix, for example when it's in an anonymous
|
|
|
|
// namespace.
|
|
|
|
if (!func_name.IsEmpty() && m_regex.Execute(func_name.GetStringRef()))
|
2011-09-28 03:48:20 +08:00
|
|
|
m_match_set.insert(func_name);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return Searcher::eCallbackReturnContinue;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::SymbolCompleter::DoCompletion(SearchFilter *filter) {
|
2010-06-09 00:52:24 +08:00
|
|
|
filter->Search(*this);
|
|
|
|
collection::iterator pos = m_match_set.begin(), end = m_match_set.end();
|
|
|
|
for (pos = m_match_set.begin(); pos != end; pos++)
|
2018-07-28 02:42:46 +08:00
|
|
|
m_request.AddCompletion((*pos).GetCString());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// ModuleCompleter
|
2016-02-20 03:33:46 +08:00
|
|
|
CommandCompletions::ModuleCompleter::ModuleCompleter(
|
2018-07-14 02:28:14 +08:00
|
|
|
CommandInterpreter &interpreter, CompletionRequest &request)
|
|
|
|
: CommandCompletions::Completer(interpreter, request) {
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec partial_spec(m_request.GetCursorArgumentPrefix());
|
2010-06-09 00:52:24 +08:00
|
|
|
m_file_name = partial_spec.GetFilename().GetCString();
|
|
|
|
m_dir_name = partial_spec.GetDirectory().GetCString();
|
|
|
|
}
|
|
|
|
|
2018-09-08 02:43:04 +08:00
|
|
|
lldb::SearchDepth CommandCompletions::ModuleCompleter::GetDepth() {
|
|
|
|
return lldb::eSearchDepthModule;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-02-20 03:33:46 +08:00
|
|
|
Searcher::CallbackReturn CommandCompletions::ModuleCompleter::SearchCallback(
|
2019-10-10 19:26:51 +08:00
|
|
|
SearchFilter &filter, SymbolContext &context, Address *addr) {
|
2011-09-17 14:21:20 +08:00
|
|
|
if (context.module_sp) {
|
2010-06-09 00:52:24 +08:00
|
|
|
const char *cur_file_name =
|
|
|
|
context.module_sp->GetFileSpec().GetFilename().GetCString();
|
|
|
|
const char *cur_dir_name =
|
|
|
|
context.module_sp->GetFileSpec().GetDirectory().GetCString();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
bool match = false;
|
|
|
|
if (m_file_name && cur_file_name &&
|
|
|
|
strstr(cur_file_name, m_file_name) == cur_file_name)
|
|
|
|
match = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (match && m_dir_name && cur_dir_name &&
|
|
|
|
strstr(cur_dir_name, m_dir_name) != cur_dir_name)
|
|
|
|
match = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (match) {
|
2018-07-28 02:42:46 +08:00
|
|
|
m_request.AddCompletion(cur_file_name);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return Searcher::eCallbackReturnContinue;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
void CommandCompletions::ModuleCompleter::DoCompletion(SearchFilter *filter) {
|
2010-06-09 00:52:24 +08:00
|
|
|
filter->Search(*this);
|
|
|
|
}
|