if passed in a NULL new_value and the operation intended is eVarSetOperationAssign.
This fixed a bug where in TestSettings.py:

        # Set the run-args and the env-vars.
        self.runCmd('settings set target.process.run-args A B C')
        self.runCmd('settings set target.process.env-vars ["MY_ENV_VAR"]=YES')
        # And add hooks to restore the settings during tearDown().
        self.addTearDownHook(
            lambda: self.runCmd("settings set -r target.process.run-args"))
        self.addTearDownHook(
            lambda: self.runCmd("settings set -r target.process.env-vars"))

"settings set -r target.process.env-vars" was not restoring the original env-vars
setting.

llvm-svn: 116895

Create more useful instance names for target, process and thread instances.

Change default 'set' behavior so that all instance settings for the specified variable will be
updated, unless the "-n" ("--no_override") command options is specified.

llvm-svn: 114808

and have them return a bool to indicate success or not.

llvm-svn: 114361

the parent of Process settings;   add 'default-arch' as a
class-wide setting for Target.    Replace            lldb::GetDefaultArchitecture
with Target::GetDefaultArchitecture & Target::SetDefaultArchitecture.

Add 'use-external-editor' as user setting to Debugger class & update
code appropriately.

Add Error parameter to methods that get user settings, for easier
reporting of bad requests.

Fix various other minor related bugs.

Fix test cases to work with new changes.

llvm-svn: 114352

replacing the "(lldb)" prompt, the "frame #1..." displays when doing
stack backtracing and the "thread #1....". This will allow you to see 
exactly the information that you want to see where you want to see it.
This currently isn't hookup up to the prompts yet, but it will be soon.

So what is the format of the prompts? Prompts can contain variables that
have access to the current program state. Variables are text that appears
in between a prefix of "${" and ends with a "}". Some of the interesting
variables include:

// The frame index (0, 1, 2, 3...)
${frame.index}

// common frame registers with generic names
${frame.pc}
${frame.sp}
${frame.fp}
${frame.ra}
${frame.flags}

// Access to any frame registers by name where REGNAME is any register name:
${frame.reg.REGNAME}

// The current compile unit file where the frame is located
${file.basename}
${file.fullpath}

// Function information
${function.name}
${function.pc-offset}

// Process info
${process.file.basename}
${process.file.fullpath}
${process.id}
${process.name}

// Thread info
${thread.id}
${thread.index}
${thread.name}
${thread.queue}
${thread.stop-reason}

// Target information
${target.arch}

// The current module for the current frame (the shared library or executable
// that contains the current frame PC value):
${module.file.basename}
${module.file.fullpath}

// Access to the line entry for where the current frame is when your thread
// is stopped:
${line.file.basename}
${line.file.fullpath}
${line.number}
${line.start-addr}
${line.end-addr}

Many times the information that you might have in your prompt might not be
available and you won't want it to print out if it isn't valid. To take care
of this you can enclose everything that must resolve into a scope. A scope
is starts with '{' and ends with '}'. For example in order to only display
the current file and line number when the information is available the format
would be:

"{ at {$line.file.basename}:${line.number}}"

Broken down this is:

start the scope: "{"

format whose content will only be displayed if all information is available:
        "at {$line.file.basename}:${line.number}"

end the scope: "}"

We currently can represent the infomration we see when stopped at a frame:

frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19

with the following format:

"frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n"

This breaks down to always print:

        "frame #${frame.index}: ${frame.pc} "

only print the module followed by a tick if we have a valid module:

        "{${module.file.basename}`}"
        
print the function name with optional offset:
        "{${function.name}{${function.pc-offset}}"

print the line info if it is available:
        
        "{ at ${line.file.basename}:${line.number}}"

then finish off with a newline:

        "\n"

Notice you can also put newlines ("\n") and tabs and everything else you
are used to putting in a format string when desensitized with the \ character.

Cleaned up some of the user settings controller subclasses. All of them 
do not have any global settings variables and were all implementing stubs
for the get/set global settings variable. Now there is a default version
in UserSettingsController that will do nothing.

llvm-svn: 114306

in an initializer.

llvm-svn: 114107

or a settings prefix, and it will list information about the subset of settings
you requested.  Also added tab-completion (now that it takes an optional argument).

llvm-svn: 113952

Remove all visible uses of "[DEFAULT]" instance name.

Add ability to rename UserSettingsInstances after they have been created
(via UserSettingsController::RenameInstanceSettings.

llvm-svn: 113950

Make get/set variable at the debugger level always set the particular debugger's instance variables rather than
the default variables.

llvm-svn: 113474

Make sure creating a pending instance doesn't also trigger creating a live instance; also make sure creating a
pending instance uses the specified instance name rather than creating a new one; add brackets to instance names
when searching for and removing pending instances.

llvm-svn: 113370

llvm-svn: 113309

in UserSettingsController.cpp.

llvm-svn: 113268

llvm-svn: 113245

This is a very large commit that completely re-does the way lldb
handles user settable internal variables (the equivalent of set/show
variables in gdb).  In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes).  The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure.  The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter.  Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)

Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class).  The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).

llvm-svn: 113041