[Bug 49018][lldb] Fix incorrect help text for 'memory write' command

Certain commands like 'memory write', 'register read' etc all use
the OptionGroupFormat options but the help usage text for those

[Bug 49018][lldb] Fix incorrect help text for 'memory write' command

Certain commands like 'memory write', 'register read' etc all use
the OptionGroupFormat options but the help usage text for those
options is not customized to those commands.

One such example is:

(lldb) help memory read
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.
(lldb) help memory write
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.

This patch allows such commands to overwrite the help text for the options
in the OptionGroupFormat group as needed and fixes help text of memory write.

llvm.org/pr49018.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D114448

show more ...

[lldb/Interpreter][NFC] Replace default constructors/destructors bodies with "=default"

[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 ----------------------------------------

[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

show more ...

[lldb][NFC] Remove dead code that is supposed to handle invalid command options

Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is un

[lldb][NFC] Remove dead code that is supposed to handle invalid command options

Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).

This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66522

llvm-svn: 369625

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Replace "nullptr-terminated" C-arrays of OptionValueEnumeration with safer llvm::ArrayRef

Differential Revision: https://reviews.llvm.org/D49017

llvm-svn: 343130

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to r

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue

if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)

continue

if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""

out.write(line)

os.rename(tmp, sys.argv[1])

Differential Revision: https://reviews.llvm.org/D46144

llvm-svn: 331197

show more ...

Move ArchSpec to the Utility module

The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.

This

Move ArchSpec to the Utility module

The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.

This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.

llvm-svn: 318048

show more ...

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that h

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.

llvm-svn: 302872

show more ...

Delete some more dead includes.

This breaks the cycle between Target and PluginLanguageC++, reducing
the overall cycle count from 43 to 42.

llvm-svn: 298561

Break some dependencies in lldbUtility.

Differential Revision: https://reviews.llvm.org/D29359

llvm-svn: 293806

Jim unintentionally had the gdb-format specifiers falling through
after r276132 so that 'x/4b' would print out a series of 4 8-byte
quantities. Fix that, add a test case.

<rdar://problem/29930833>

Jim unintentionally had the gdb-format specifiers falling through
after r276132 so that 'x/4b' would print out a series of 4 8-byte
quantities. Fix that, add a test case.

<rdar://problem/29930833>

llvm-svn: 293002

show more ...

Update OptionGroup::SetValue to take StringRef.

Then deal with all the fallout.

Differential Revision: https://reviews.llvm.org/D24847

llvm-svn: 282265

Try to fix build errors on Android.

It doesn't like the implicit conversion from T[] to ArrayRef<T>
so I'm using `llvm::makeArrayRef()`. Hopefully I got everything.

llvm-svn: 282195

Convert option tables to ArrayRefs.

This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<Op

Convert option tables to ArrayRefs.

This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.

In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.

Differential revision: https://reviews.llvm.org/D24834

llvm-svn: 282188

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Decoupled Options from CommandInterpreter.

Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a

Decoupled Options from CommandInterpreter.

Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.

This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.

Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham

llvm-svn: 278440

show more ...

If x/i is followed by x/g, the format should be reset to 'x'.

Otherwise, you have to say "x/gx" to what you obviously intended to
happen to happen.

<rdar://problem/27415507>

llvm-svn: 276132

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore,

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.

None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.

llvm-svn: 238581

show more ...

Refactor OptionValue::SetValueFromCString to use llvm::StringRef

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D7676

llvm-svn: 230005

Revert "Fix broken tests due to new error output."

This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and
re-enables OptionValidators.

llvm-svn: 212627

Fix broken tests due to new error output.

This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.

Restores broken tests on FreeBSD

Fix broken tests due to new error output.

This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.

Restores broken tests on FreeBSD, Linux, MacOSX.

Changes reverted: r212500, r212317, r212290.

llvm-svn: 212543

show more ...

Adds the notion of an OptionValidator.

The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger st

Adds the notion of an OptionValidator.

The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.

This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.

Reviewed by: Greg Clayton, Jim Ingham

Differential Revision: http://reviews.llvm.org/D4369

llvm-svn: 212290

show more ...

Switch NULL to C++11 nullptr in source/Interpreter

Patch by Robert Matusewicz

llvm-svn: 206711

<rdar://problem/15192088>

gdb-format a (as in p/a) would fail as it needed to set a byte size (unsurprisingly enough)
This should be acknowledged by the condition check and not cause a failure

llvm

<rdar://problem/15192088>

gdb-format a (as in p/a) would fail as it needed to set a byte size (unsurprisingly enough)
This should be acknowledged by the condition check and not cause a failure

llvm-svn: 192511

show more ...