Commit Graph

5 Commits

Author SHA1 Message Date
Kate Stone b9c1b51e45 *** 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
2016-09-06 20:57:50 +00:00
Enrico Granata f96fd0dd1d Remove what I believe are the last known instances of formatters that run code
llvm-svn: 265865
2016-04-08 22:49:31 +00:00
Jim Ingham a309efef39 Change Target::EvaluateExpression to take an ExecutionContextScope * rather than a
StackFrame * (StackFrame is an ExecutionContextScope.)  That allows you to call an
expression on a particular Thread, but not using the context of any particular frame.
That in turn is useful for injecting utility functions that don't actually depend on
locals/self/etc of the current frame.

I also had to include StackFrame.h in a couple of places so the compiler knew
how to downcast StackFrame to ExecutionContextScope.

<rdar://problem/22852953>

llvm-svn: 251564
2015-10-28 22:23:17 +00:00
Enrico Granata 675f49bbd5 This is the work I was building up to with my patches yesterday
Introduce the notion of Language-based formatter prefix/suffix
This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values

This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this

llvm-svn: 249587
2015-10-07 18:36:53 +00:00
Enrico Granata 170c395e70 Move Objective-C data formatters to the Objective-C language plugin where they belong
llvm-svn: 247627
2015-09-14 22:18:32 +00:00