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

LLDB help content has accumulated over time without a recent attempt to
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text rela

LLDB help content has accumulated over time without a recent attempt to
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.

<rdar://problem/24868841>

llvm-svn: 275485

show more ...

fixits are apparently called fix-its.

<rdar://problem/26998596>

llvm-svn: 273979

[LLDB] Added support for PHI nodes to IR interpreter

This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may n

[LLDB] Added support for PHI nodes to IR interpreter

This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms).

Patch by cameron314

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

llvm-svn: 269340

show more ...

Fixed multiline expressions, and removed some dead code.

IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be
implemented but isn't. This means that multiline expressions do

Fixed multiline expressions, and removed some dead code.

IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be
implemented but isn't. This means that multiline expressions don't work. This
patch fixes that. Test case to follow in the next commit.

llvm-svn: 268970

show more ...

Add a --element-count option to the expression command
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays su

Add a --element-count option to the expression command
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements

This has a couple subtle points but is mostly as straightforward as it sounds

Add a parray N <expr> alias for this new mode

Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this

llvm-svn: 267372

show more ...

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 scallanan@apple.com
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 ...