No functionality change.

llvm-svn: 160501

llvm-svn: 160500

[Sanitizer] When obtaining the data for loaded modules, add address ranges of loadable segments only. Looks like address range of PT_TLS segment may intersect with loadable segments of other modules.

llvm-svn: 160498

(instead of basenames) from DWARF. Use this behavior in llvm-dwarfdump tool.

Reviewed by Benjamin Kramer.

llvm-svn: 160496

Simplify UninitializedValues.cpp by removing logic to handle the previous (imprecise) representation
of '&&' and '||' in the CFG.  This is no longer needed, and greatly simplifies the code.

llvm-svn: 160494

llvm-svn: 160493

llvm-svn: 160492

This macro was being unconditionally set to zero, preceded by a FIXME comment.
This fixes <rdar://problem/11845441>.  Patch by Michael Gottesman!

llvm-svn: 160491

Relaxed enumeration constant naming rules for scoped enumerators so they no longer emit a diagnostic when the enumeration's name matches that of the class.  Fixes PR13128.

llvm-svn: 160490

llvm-svn: 160488

Allow debugserver to match process names that are longer than MAXCOMLEN (16) characters. We do this by digging up argv[0] from another sysctl if the process name supplied is longer than 16 characters.

llvm-svn: 160487

It crashes mingw32-gcc-4.4.

llvm-svn: 160486

llvm-svn: 160485

The hack of recognizing a -D__IPHONE_OS_VERSION_MIN_REQUIRED option
in place of -mios-simulator-version-min leaves the Darwin version
unspecified.  It can be set separately with -mmacosx-version-min (which
makes no sense) or inferred to match the host version (which is unpredictable
and usually wrong).  This really needs to get cleaned up, but in the
meantime, force the OS X version to 10.6 so that the behavior is sane for
the iOS simulator.  Thanks for Argyrios for the patch.
<rdar://problem/11858187>

llvm-svn: 160484

llvm-svn: 160483

llvm-svn: 160482

llvm-svn: 160481

llvm-svn: 160480

llvm-svn: 160479

llvm-svn: 160478

llvm-svn: 160477

llvm-svn: 160476

llvm-svn: 160475

TextComment node was considered whitespace even if it contained other child
nodes.

llvm-svn: 160474

llvm-svn: 160473

llvm-svn: 160472

llvm-svn: 160471

Panzer. I've not been able to trigger a failure caused by this, so no test yet.
Also included is a small change from Paul Robinson to only consider the
FailureKind if the overload candidate did actually fail.

llvm-svn: 160470

llvm-svn: 160468

llvm-svn: 160467

Cleaned up the lldb_private::Mangled class to get rid of the tokenizing code that has bit rotted and isn't being used. Also cleaned up the API to the "lldb_private::Mangled" to always take "const ConstString &" arguments instead of both "const ConstString &" and "const char *". 

llvm-svn: 160466

is one more that MRM_DF which is 55.  Previously, it held value 45, the same
as MRM_D0.

llvm-svn: 160465

llvm-svn: 160464

llvm-svn: 160463

llvm-svn: 160462

As pointed out by Anna, we only differentiate between explicit message sends

This also adds support for ObjCSubscriptExprs, which are basically the same
as properties in many ways. We were already checking these, but not emitting
nice messages for them.

This depends on the llvm::PointerIntPair change in r160456.

llvm-svn: 160461

Per Anna's comment that "add..." sounds like a method that modifies
the receiver, rather than its argument.

No functionality change.

llvm-svn: 160460

We will need to be able to easily reconstruct a CallEvent from an ExplodedNode
for diagnostic purposes, and that's exactly what factory functions are for.
CallEvent objects are small enough (four pointers and a SourceLocation) that
returning them through the stack is fairly cheap. Clients who just need to use
existing CallEvents can continue to do so using const references.

This uses the same sort of "kind-field-dispatch" as SVal, though most of the
nastiness is contained in the DISPATCH and DISPATCH_ARG macros at the end of
the file. (We can't use a template for this because member-pointers to base
class methods don't call derived-class methods even when casting to the
derived class. We can't use variadic macros because they're a C99 feature.)

llvm-svn: 160459

ObjC properties are handled through their semantic form of ObjCMessageExprs
and their wrapper PseudoObjectExprs, and have been for quite a while. The
syntactic ObjCPropertyRefExprs do not appear in the CFG and are not visited
by ExprEngine.

No functionality change.

llvm-svn: 160458

llvm-svn: 160457