With some minor modification from me.

llvm-svn: 147160

Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.

llvm-svn: 147157

llvm-svn: 147149

complete the result type, preventing crashes later.

llvm-svn: 147107

parser has hitherto been an implementation waiting
for a use.  I have now tied the '-o' option for
the expression command -- which indicates that the
result is an Objective-C object and needs to be
printed -- to the ExpressionParser, which
communicates the desired type to Clang.

Now, if the result of an expression is determined
by an Objective-C method call for which there is
no type information, that result is implicitly
cast to id if and only if the -o option is passed
to the expression command.  (Otherwise if there
is no explicit cast Clang will issue an error.
This behavior is identical to what happened before
r146756.)

Also added a testcase for -o enabled and disabled.

llvm-svn: 147099

Xcode workspace that aren't actually desirable.
Reverted.

llvm-svn: 147097

llvm-svn: 147072

llvm-svn: 147061

llvm-svn: 147033

with incomplete definition data were being converted.
Now Clang attempts to complete RecordDecls before
converting them, avoiding a nasty crash.

llvm-svn: 147029

types that have been imported multiple times.

The discussion below uses this diagram:

ASTContext     A      B      C
Decl           Da     Db     Dc
ASTImporter    \-Iab-/\-Iac-/
               \-----Iac----/

When a Decl D is imported from ASTContext A to
ASTContext B, the ASTImporter Iab records the
pair <Da, Db> in a DenseMap.  That way, if Iab
ever encounters Da again (for example, as the
DeclContext for another Decl), it can use the
imported version.  This is not an optimization,
it is critical: if I import the field "st_dev"
as part of importing "struct stat," the field
must have DeclContext equal to the parent
structure or we end up with multiple different
Decls containing different parts of "struct
stat."  "struct stat" is imported once and
recorded in the DenseMap; then the ASTImporter
finds that same version when looking for the
DeclContext of "st_dev."

The bug arises when Db is imported into another
ASTContext C and ASTContext B goes away.  This
often occurs when LLDB produces result variables
for expressions.  Ibc is aware of the transport
of Db to Dc, but a brand new ASTImporter, Iac,
is responsible for completing Dc from its source
upon request.  That ASTImporter has no mappings,
so it will produce a clone of Dc when attempting
to import its children.  That means that type
completion operations on Dc will fail.

The solution is to create Iac as soon as Ibc
imports D from B to C, and inform Iac of the
mapping between Da and Dc.  This allows type
completion to happen correctly.

llvm-svn: 147016

llvm-svn: 146978

llvm-svn: 146957

llvm-svn: 146956

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBValue.CreateValueFromExpression().

llvm-svn: 146954

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.

llvm-svn: 146948

llvm-svn: 146936

llvm-svn: 146935

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBStream APIs.

llvm-svn: 146934

llvm-svn: 146930

llvm-svn: 146924

llvm-svn: 146922

llvm-svn: 146919

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBDebugger APIs.

llvm-svn: 146917

llvm-svn: 146912

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBCommandReturnObject.AppendMessage().

llvm-svn: 146911

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBCommandInterpreter APIs.

llvm-svn: 146909

<rdar://problem/10596340>

llvm-svn: 146902

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBModule and SBSection APIs.

llvm-svn: 146899

"id" from being found by the parser as an
externally-defined type.  Before, "id" would
sometimes make it through if it was defined in
a namespace, but this sometimes caused
confusion, for example when it conflicted with
std::locale::id.

llvm-svn: 146891

llvm-svn: 146890

SBThread::GetStopReasonDataCount/GetStopReasonDataAtIndex() need to handle eStopReasonWatchpoint.

llvm-svn: 146812

build script that applies any local patches to
LLVM/Clang.

llvm-svn: 146811

and debugserver-156.

llvm-svn: 146808

as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers.  That way this will always
be good.

llvm-svn: 146806

which have the dwarf DIE tag (DW_TAG_XXX enum) and TypeFlags for each type.

llvm-svn: 146802

enhanced disassembler classify disassemblers by
target triple (as a string) rather than just by
the architecture component of the triple.  This
fixes a problem where different variants of the
Thumb instruction set were lumped into the same
hash bucket.

llvm-svn: 146799

llvm-svn: 146798

llvm-svn: 146777

valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider

Patch from Enrico Granata:

The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.

The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.

llvm-svn: 146768