llvm-svn: 100578

declared in categories.

llvm-svn: 100577

  (void*) someFunction(5, 10, 15, 20);
where the cast is presumably meant to be to 'void'.

llvm-svn: 100574

There is probably a more elegant way to do this.

llvm-svn: 100573

them the same way as fields.  This fixes a regression in RegionStore::RemoveDeadbindings()
that emerged from going to the cluster-based analysis.

llvm-svn: 100570

Radar 7770501.

llvm-svn: 100568

to a SDNode that didn't have code generated for it.

llvm-svn: 100566

llvm-svn: 100563

that protected members be used on objects of types which derive from the
naming class of the lookup.  My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.

llvm-svn: 100562

When a frame pointer is not otherwise required, and dynamic stack alignment
is necessary solely due to the spilling of a register with larger alignment
requirements than the default stack alignment, the frame pointer can be both
used as a general purpose register and a frame pointer. That goes poorly, for
obvious reasons. This patch brings back a bit of old logic for identifying
the use of such registers and conservatively reserves the frame pointer
during register allocation in such cases.

For now, implement for X86 only since it's 32-bit linux which is hitting this,
and we want a targeted fix for 2.7. As a follow-on, this will be expanded
to handle other targets, as theoretically the problem could arise elsewhere
as well.

llvm-svn: 100559

while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.

llvm-svn: 100558

llvm-svn: 100557

llvm-svn: 100556

statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".

llvm-svn: 100555

This fixes the Bullet regression on i386/nocona.

llvm-svn: 100553

llvm-svn: 100551

llvm-svn: 100550

llvm-svn: 100549

down the set of code-completion results based on Objective-C
conventions. 

llvm-svn: 100548

llvm-svn: 100547

llvm-svn: 100546

that the integrated assembler is working.

llvm-svn: 100545

and remove assumptions about operand order

llvm-svn: 100544

allowing backend errors to be mapped through clang's 
diagnostics subsystem, including the backend location info.

We now get:

$ clang asm.c -c -o t.o -integrated-as
<inline asm>:1:2: error: unrecognized instruction
        abc incl    %eax
        ^
1 diagnostic generated.

With colors, and correct "# diagnostics generated".

llvm-svn: 100543

llvm-svn: 100542

Add a simplified constructor for clients that don't have locations
like "file not found" errors.

llvm-svn: 100538

llvm-svn: 100537

llvm-svn: 100536

presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.

llvm-svn: 100535

llvm-svn: 100534

block pointer type comparison.

llvm-svn: 100533

llvm-svn: 100532

A certain GDB testsuite case (local.cc) has a function nested inside a
class nested inside another function.  GCC presents the innermost
function to llvm-convert first.  Heretofore, the debug info mistakenly
placed the inner function at module scope.  This patch walks the GCC
context links and instantiates the outer class and function so the
debug info is properly nested.  Radar 7426545.

llvm-svn: 100530

deciding when we need to emit an extra "command failed" diagnostic.
 - This also fixes the case where we were emitting that extra diagnostics, even
   when using clang w/ the integrated assembler, which has good diagnostics.

llvm-svn: 100529

"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively, that we know about.

Note that this implementation does not yet work well with precompiled
headers; that's coming soon.

llvm-svn: 100528

llvm-svn: 100527

e.g., the right-hand side of binary expressions.

llvm-svn: 100526

llvm-svn: 100525

llvm-svn: 100521

use case where someone wants to resurrect LLVM after calling llvm_shutdown,
but I'm not aware of any clients that are affected by this.

llvm-svn: 100519