The internal representation of the Attributes class will be opaque. All of the
query methods will need to query the opaque class. Therefore, these methods need
to be out-of-line.
No functionality change intended.

llvm-svn: 165305

llvm-svn: 165304

llvm-svn: 165303

Move expansion of SETB_C(8/16/32/64)r from MCInstLower to ExpandPostRAPseudos and mark them as pseudos in the td file.

llvm-svn: 165302

llvm-svn: 165301

It is now a regex command alias that more faithfully emulates gdb's
behavior, most importantly, "bt 5" will backtrace 5 frames of the
currently selected thread.  "bt all" still backtraces all threads
(unlike gdb) and for users who have learned to use "bt -c 5", that
form is still accepted.

llvm-svn: 165300

expansion on the dSYM path we find if it starts with a tilde.

llvm-svn: 165299

llvm-svn: 165298

llvm-svn: 165297

llvm-svn: 165296

reflect that the columns were just swapped.

llvm-svn: 165295

often hear feedback from people that having the lldb commands on
the left hand side is non-intuitive -- they say "I want a *gdb* to
*lldb* table, not a *lldb* to *gdb* table".  It doesn't seem odious
to go from the right-hand column to the left hand column but I've
heard this same feedback enough that it's also pointless to keep
the format lldb-first, gdb-second when it was an arbitrary choice
to begin with.

llvm-svn: 165294

This document describes how to set up LLVM-style RTTI for a class
hierarchy. Surprisingly, this was not previously documented.

Also, link it into ProgrammersManual.html.

llvm-svn: 165293

Use isa<> or cast<> when semantically that is what is happening. Also
some trivial "style" cleanups at fix sites.

llvm-svn: 165292

This is a mechanical change of dynamic_cast<> to dyn_cast<>. A number of
these uses are actually more like isa<> or cast<>, and will be changed
to the semanticaly appropriate one in a future patch.

llvm-svn: 165291

llvm-svn: 165290

PR14029, clang part.

llvm-svn: 165289

PR14029, LLVM part.

llvm-svn: 165288

Follow up to r165072. Try a different approach: only move the load when it's going to be folded into the call. rdar://12437604

llvm-svn: 165287

Workaround for libstdc++4.6 <atomic> bug: make comment more explicit about what's going on, per Sean Silva's suggestion.

llvm-svn: 165286

are in fact identity operations. We detect these and kill their
partitions so that even splitting is unaffected by them. This is
particularly important because Clang relies on emitting identity memcpy
operations for struct copies, and these fold away to constants very
often after inlining.

Fixes the last big performance FIXME I have on my plate.

llvm-svn: 165285

the rewrite visitor to make the fact that the speculation is completely
independent a bit more clear.

I promise that this is just a cut/paste of the one visitor and adding
the annonymous namespace wrappings. The diff may look completely
preposterous, it does in git for some reason.

llvm-svn: 165284

This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.

(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)

llvm-svn: 165283

llvm-svn: 165282

importedASTFile indexing callback.

llvm-svn: 165281

clang_Cursor_getModule
clang_Module_getParent
clang_Module_getName
clang_Module_getFullName
clang_Module_getNumTopLevelHeaders
clang_Module_getTopLevelHeader

llvm-svn: 165280

that are associated with a (sub)module.

llvm-svn: 165279

loaded entities vector, otherwise its meaning will change when a module
is imported and the vector size changes.

llvm-svn: 165278

import declaration.

llvm-svn: 165277

llvm-svn: 165276

segmented registers.  Test case to come.

llvm-svn: 165275

<rdar://problem/12099999> renaming SBStream::Printf to Print in the scripting world in order to avoid supporting varargs through SWIG

llvm-svn: 165274

 - outside C++, return undef (behavior is not undefined unless the value is used)
 - in C++, with -fcatch-undefined-behavior, perform an appropriate trap
 - in C++, produce an 'unreachable' (behavior is undefined immediately)

llvm-svn: 165273

A tweak to the previous commit to ensure that we don't try to use -> on a NULL pointer (should not happen but better be safe than sorry)

llvm-svn: 165272

<rdar://problem/12413390> Fixing an issue where synthetic ValueObjects do not properly resolve their value

llvm-svn: 165271

llvm-svn: 165270

enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing

        Mutex::Locker(m_map_mutex);

This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately.  Instead,

        Mutex::Locker locker(m_map_mutex);

does what is intended.  For some reason -Wshadow happened to
highlight these as shadowed variables.

I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>

llvm-svn: 165269

from LLVM and Clang.  This made "svn update" very
unpleasant if the original repository was fetched by
build-llvm.pl.

llvm-svn: 165268

llvm-svn: 165267

because the unwinders typically can find its
value.

llvm-svn: 165266