Figure out what the fixed expression is, and print it. Added another target setting to
quietly apply fixits for those who really trust clang's fixits.

Also, moved the retry into ClangUserExpression

Figure out what the fixed expression is, and print it. Added another target setting to
quietly apply fixits for those who really trust clang's fixits.

Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.

<rdar://problem/25351938>

llvm-svn: 264793

show more ...

Expose top-level Clang expressions via the command line and the API.

Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have fu

Expose top-level Clang expressions via the command line and the API.

Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers. Names defined by these are given priority over all other
symbol lookups.

This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way. It also adds a flag controlling
this to SBExpressionOptions so that this API is usable externally. It also adds
a test that validates that this works. (The test requires a fix to the Clang
AST importer which I will be committing shortly.)

<rdar://problem/22864976>

llvm-svn: 264662

show more ...

Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions se

Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.

This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.

<rdar://problem/25351938>

llvm-svn: 264379

show more ...

Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in some files in source/Commands; other minor fixes.

llvm-svn: 261356

Added support to the expression command for dropping into the REPL at will.

"expr -r" does this. It also returns to a REPL if the LLDB command interpreter
is neseted inside it, for example in cases

Added support to the expression command for dropping into the REPL at will.

"expr -r" does this. It also returns to a REPL if the LLDB command interpreter
is neseted inside it, for example in cases where a REPL command resulted in a
breakpoint being hit or a crash.

llvm-svn: 250780

show more ...

Decide on the expression language inside UserExpression

When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're ru

Decide on the expression language inside UserExpression

When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're running
SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes
this.

Based on patch from [email protected]
Reviewed by: dawn
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13267

llvm-svn: 249624

show more ...

Fix minor typos in comments.

llvm-svn: 249533

Route the preferred-display-language mechanism to the ValueObjectPrinter and actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways

llvm-svn: 249507

This patch makes Clang-independent base classes for all the expression types that lldb currently vends.

Before we had:

ClangFunction
ClangUtilityFunction
ClangUserExpression

and code all over in

This patch makes Clang-independent base classes for all the expression types that lldb currently vends.

Before we had:

ClangFunction
ClangUtilityFunction
ClangUserExpression

and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:

FunctionCaller
UtilityFunction
UserExpression

You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.

Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.

The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.

Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.

llvm-svn: 247720

show more ...

Set the default language to use when evaluating to that of the frame's CU.

* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be u

Set the default language to use when evaluating to that of the frame's CU.

* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.

Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102

llvm-svn: 246829

show more ...

Purge a few places where *LanguageRuntime.h was being used when it
wasn't needed.

llvm-svn: 246744

Jim told me about a cleaner way to include headers from plug-ins.

This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we w

Jim told me about a cleaner way to include headers from plug-ins.

This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.

llvm-svn: 246738

show more ...

In preparation for factoring persistent variables into a generic part and a
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expre

In preparation for factoring persistent variables into a generic part and a
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.

It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.

llvm-svn: 246737

show more ...

Move things from the LanguageRuntime that obviously belong in the new Language plugin instead.

llvm-svn: 246611

Specify a language to use when parsing expressions.

This patch adds the option -l/--language to the expression command, for
use when setting the language options or choosing an alternate FE. If
not

Specify a language to use when parsing expressions.

This patch adds the option -l/--language to the expression command, for
use when setting the language options or choosing an alternate FE. If
not specified, the target.language setting is used.

Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11447

llvm-svn: 243187

show more ...

Fixed line wrapping for the "long help" content in LLDB commands. Content is now dynamically wrapped for the column width of the current terminal. Lines that begin with whitespace will be indented

Fixed line wrapping for the "long help" content in LLDB commands. Content is now dynamically wrapped for the column width of the current terminal. Lines that begin with whitespace will be indented identically on subsequent lines to maintain formatting.

Existing commands supplying this type of help content have been reworked to take advantage of the changes. In addition to formatting changes, content was changes for accuracy and clarity purposes.

<rdar://problem/21269977>

llvm-svn: 242122

show more ...

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

Add support for custom commands to set flags on themselves
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::Ge

Add support for custom commands to set flags on themselves
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())

Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones

llvm-svn: 238286

show more ...

Fix handling of backslashes in Args parsing

Summary:
Presently Args::SetCommandString allows quotes to be escaped with backslash. However, the
backslash itself is not removed from the argument, nor

Fix handling of backslashes in Args parsing

Summary:
Presently Args::SetCommandString allows quotes to be escaped with backslash. However, the
backslash itself is not removed from the argument, nor there is a way to escape the backslash
itself. This leads to surprising results:

"a b" c" -> 'a b', 'c' # Here we actually have an unterminated quote, but that is ignored
"a b\" c" -> 'a b\" c' # We try to escape the quote. That works but the backslash is not removed.
"a b\\" c" -> 'a b\\" c' # Escaping the backslash has no effect.

This change changes quote handling to be more shell-like:
- single quotes and backquotes are literal and there is no way to escape the closing quote or
anything else inside;
- inside double quotes you can use backslash to escape the closing quote and another backslash
- outside any quotes, you can use backslash to escape quotes, spaces and itself.

This makes the parsing more consistent with what the user is familiar and increases the
probability that pasting the command line from shell to the "process launch" command "just work".

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 230955

show more ...

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused fun

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb

llvm-svn: 226199

show more ...

This is the first step of making lldb able to create target-specific things
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get co

This is the first step of making lldb able to create target-specific things
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.

Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.

We should also make a command & SB API way to prime this ur-target.

llvm-svn: 222600

show more ...

Complete rewrite of interactive editing support for single- and multi-line input.

Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over

Complete rewrite of interactive editing support for single- and multi-line input.

Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements

llvm-svn: 222163

show more ...

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

This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and
re-enables OptionValidators.

llvm-svn: 212627

Document the "thread.completed-expression" feature in the "expression" command help.

llvm-svn: 212558

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