at -O0. The only change from the previous patch is that we don't try
to generate virtual method thunks for an available_externally
function.

llvm-svn: 108230

llvm-svn: 108220

VarDecl.

llvm-svn: 108218

class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.

llvm-svn: 108217

llvm-svn: 108214

they're not something the user typed (at least, not here).

llvm-svn: 108212

llvm-svn: 108209

While collecting members for a class, always create delcaration entry for methods. Debug info for method definition will be generated while generating code for method body. 
Tested by classes.exp in gdb testsuite.

llvm-svn: 108205

Split the normal and chained PCH writing paths and add a tiny bit of implementation to the latter. WIP.

llvm-svn: 108200

totally unnecessary.

llvm-svn: 108199

llvm-svn: 108198

llvm-svn: 108195

llvm-svn: 108194

llvm-svn: 108175

test the performance of code-completion without testing the
performance of printf().

llvm-svn: 108172

on the fly when constructing it.

llvm-svn: 108166

llvm-svn: 108159

constructor.

llvm-svn: 108157

-O0, since we won't be using the definitions for anything anyway. For
lib/System/Path.o when built in Debug+Asserts mode, this leads to a 4%
improvement in compile time (and suppresses 440 function bodies).

<rdar://problem/7987644>

llvm-svn: 108156

around by exempting enums from the check, but this doesn't handle a lot of
cases. A better approach is to directly check if the operator comes from
a macro expansion.

I've removed a reference to the rdar that originally led to the enum
suppression when removing it's overly contrived test case. Let me know if that
number or a more reasilistic test case involving enums is still needed.

llvm-svn: 108128

In the case of backtracking, the cached token lexer will be the only 
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.

This fixes PR7072.

llvm-svn: 108124

root cause of PR7481 and probably more, and has no apparent 
testcases.  I don't understand the logic here so I can't repair it.

llvm-svn: 108119

int test1() {
  return;
}

default to an error.

llvm-svn: 108108

'expected ';' after top level declarator' which is much less vague.

llvm-svn: 108106

a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.

Also, avoid skipping randomly after a declaration if a
semicolon is missing.  Before we'd get:

t.c:3:1: error: expected function body after function declarator
void bar();
^

Now we get:

t.c:1:11: error: invalid token after top level declarator
void foo()
          ^
          ;

llvm-svn: 108105

llvm-svn: 108104

probably try and switch more of these if I can.

llvm-svn: 108085

llvm-svn: 108068

llvm-svn: 108067

that loads it, not by linking against them directly.

llvm-svn: 108055

llvm-svn: 108054

llvm-svn: 108051

default arguments to template parameters don't have a DeclContext when
instantiated, and so we can't detect that we're in an instantiation context as
opposed to the definition context. However, it fixes the more commonly-occuring
cases in TMP code that use devolve to this type of tautology after
substitution.

llvm-svn: 108044

llvm-svn: 108042

llvm-svn: 108031

llvm-svn: 108028

be a dependent expression when its is built.

llvm-svn: 108026

block literal expression.

llvm-svn: 108019

Slightly improve the diagnostic when using a qualified function typedef to declare nonmember or static member functions.

llvm-svn: 108018

possibility of adding an unitialized one into the folding set.

llvm-svn: 108016