This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
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
Use this in the scripted breakpoint command. Added some tests for parsing
the key/value options. This uncovered a bug in handling parsing errors mid-line.
I also fixed that bug.
Differential Revision: https://reviews.llvm.org/D68363
llvm-svn: 373673
They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added because the old API allowed to look
(in theory) behind the cursor position which is no longer possible.
llvm-svn: 372861
The cursor position is always at the end of the current argument (as the
argument cut off after the cursor position). So this code is a no-op and
can be removed.
llvm-svn: 372851
The fact that index==-1 means "no arguments" is not obvious and only
used in one place from what I can tell. Also fixes several warnings
about using the cursor index as if it was a size_t when comparing.
Not fully NFC as we now also correctly update the partial argument list
when injecting the fake empty argument in the CompletionRequest
constructor.
llvm-svn: 372566
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
Summary:
Right now our argument completions are rather cryptic for command options as they only list the letters:
```
(lldb) breakpoint set -
Available completions:
-G
-C
-c
-d
-i
-o
-q
-t
-x
[...]
```
With the new completion API we can easily extend this with the flag description so that it looks like this now:
```
(lldb) breakpoint set -
Available completions:
-G -- The breakpoint will auto-continue after running its commands.
-C -- A command to run when the breakpoint is hit, can be provided more than once, the commands will get run in order left to right.
-c -- The breakpoint stops only if this condition expression evaluates to true.
-d -- Disable the breakpoint.
-i -- Set the number of times this breakpoint is skipped before stopping.
-o -- The breakpoint is deleted the first time it stop causes a stop.
-q -- The breakpoint stops only for threads in the queue whose name is given by this argument.
-t -- The breakpoint stops only for the thread whose TID matches this argument.
-x -- The breakpoint stops only for the thread whose index matches this argument.
```
The same happens with --long-options now.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67063
llvm-svn: 370628
The refactoring patch for the option completion broke the completion
for ambiguous long options. As this feature was also untested (as
testing ambiguous options with the current test methods is impossible),
I just noticed now. This patch restores the old behavior and adds a
test for this feature.
llvm-svn: 370185
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
Summary:
While investigating breakages caused by D63110, I noticed we were
building the short options strings in three places. Some of them used a
leading ':' to detect missing arguments, and some didn't. This was the
indirect cause of D63110. Here, I move the common code into a utility
function.
Also, unify the code which appends the sentinel value at the end of the
option vector, and make it harder for users to pass invalid argc-argv
combos to getopt (another component of D63110) by having the
OptionParser::Parse function take a (Mutable)ArrayRef.
This unification has uncovered that we don't handle missing arguments
while building aliases, However, it's not possible to write an effective
test for this, as right now it is not possible to return an error out of
the alias parsing code (which means we are printing the generic
"failure" message even after this patch).
Reviewers: mgorny, aprantl
Reviewed By: mgorny
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63770
llvm-svn: 365665
Relying on the value of optind for detecting missing arguments is
unreliable because its value after a failed parse is an implementation
detail. A more correct way to achieve this is to pass ':' at the
beginning of option string, which tells getopt to return ':' for missing
arguments.
For this to work, I also had to add a nullptr at the end of the argv
vector, as some getopt implementations did not work without that. This
is also an implementation detail, as getopt should normally be called
with argc+argc "as to main function" (i.e. null-terminated).
Thanks to Michał Górny for testing this patch out on NetBSD.
llvm-svn: 364317
The call to getopt_long didn't handle the case where the *last* option
had an argument missing.
<rdar://problem/51231882>
Differential Revision: https://reviews.llvm.org/D63110
llvm-svn: 363101
Jonas Devlieghere
Raphael Isemann
Martin Storsjö
Benjamin Kramer
Jim Ingham
Pavel Labath
Adrian Prantl
Davide Italiano