llvm-svn: 114338

llvm-svn: 114336

document behavior. Will wonders never cease.

llvm-svn: 114334

llvm-svn: 114333

llvm-svn: 114332

actually resolves to a particular function. Fixes PR8181, from Faisal
Vali!

llvm-svn: 114331

llvm-svn: 114330

bodies, from Martin Vejnar!

llvm-svn: 114329

rdar://problem/8449849

llvm-svn: 114328

llvm-svn: 114326

Add GetDescription() and __repr__ () methods to most API classes, to allow
"print" from inside Python to print out the objects in a more useful
manner.

llvm-svn: 114321

Fix the "unable to rename temporary" lit test failing on Windows. rename is now copy + delete on Windows. Problem to be revisited for a permanent and clean solution.

llvm-svn: 114320

llvm-svn: 114319

llvm-svn: 114318

test/CodeGen/X86: Add explicit triplet -mtriple=i686-linux to 3 tests incompatible to Win32 codegen.

r114297 raises 3 failures. They might fail also on mingw.

llvm-svn: 114317

llvm-svn: 114316

llvm-svn: 114315

llvm-svn: 114314

llvm-svn: 114313

r114268 fixed the last of the blockers to enabling it.  I will be monitoring
for failures.

llvm-svn: 114312

llvm-svn: 114311

llvm-svn: 114310

readable and easier to edit.

llvm-svn: 114308

llvm-svn: 114307

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

llvm-svn: 114305

llvm-svn: 114304

llvm-svn: 114303

llvm-svn: 114302

getter expression. 
Fixes // rdar://8437240

llvm-svn: 114299

llvm-svn: 114297

LHS and when conditional expression is an array. Since
it will be decayed, saved expression must be saved with
decayed expression. This is necessary to preserve semantics
of this extension (and prevent an IRGen crash which expects
an array to always be decayed). I am sure there will be other
cases in c++ (aggregate conditionals for example) when saving of the 
expression must happen after some transformation on conditional
expression has happened. 
Doug, please review.  Fixes // rdar://8446940

llvm-svn: 114296

Patch by Che-Liang Chiou <clchiou@gmail.com>!

llvm-svn: 114294

llvm-svn: 114293

llvm-svn: 114292

very rarely used.

llvm-svn: 114286

llvm-svn: 114285

llvm-svn: 114284

restrict dyn_cast_or_null to pointer types, just like cast_or_null; re-commit of r114279, backed out in r114280

llvm-svn: 114282

llvm-svn: 114281