definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.

llvm-svn: 108372

llvm-svn: 108363

and some are already synthesized by user declaration.

llvm-svn: 108341

llvm-svn: 108340

_Foo) from code-completion results when they come from a system
header.

llvm-svn: 108338

as well. Fixes radar 7975788.

llvm-svn: 108333

follow <name>;  instead they follow <type>, which has <name> as a subset.

Fixes PR7446.

llvm-svn: 108326

This flag and warning match GCC semantics. Also, move it to -Wextra as this is
a largely cosmetic issue and doesn't seem to mask problems. Subsequent fixes to
the tests which no longer by default emit the warning. Added explicit test
cases for both C and C++ behavior with the warning turned on.

llvm-svn: 108325

Add test case that was causing an infinite loop when reading PCH files. The test works with ToT Clang already

llvm-svn: 108318

are explicitly given.

llvm-svn: 108297

llvm-svn: 108296

or a catch of a record type by value or reference.  Also convert this to a
lazy cleanup.

llvm-svn: 108287

in class extensions (radar 8171968).

llvm-svn: 108283

llvm-svn: 108276

mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.

Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this;  for now we have some awkward code
duplication.

Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.

llvm-svn: 108270

to block context when first instantiating them.

llvm-svn: 108266

t2.c:2:12: warning: use of logical && with constant operand; switch to bitwise &
      or remove constant [-Wlogical-bitwise-confusion]
  return x && 4;
           ^  ~

wording improvement suggestions are welcome.

llvm-svn: 108260

(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary. 

Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.

llvm-svn: 108253

llvm-svn: 108245

size" error for code like 

  new (int [size])

to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.

llvm-svn: 108242

effect warning" by printing the qualifiers we saw and correctly
pluralizing the message, e.g.,

test/SemaCXX/conditional-expr.cpp:295:3: warning: 'const volatile' type
      qualifiers on return type have no effect
  const volatile Enum g2() {
  ^~~~~ ~~~~~~~~

llvm-svn: 108236

don't include the nested-name-specifier or template arguments: they
were only relevant when resolving the declaration. Fixes PR7460.

llvm-svn: 108235

strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types. 

Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().

Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).

llvm-svn: 108234

llvm-svn: 108233

for awhile.

llvm-svn: 108232

C++). Fixes PR7466.

llvm-svn: 108231

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

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: 108209

llvm-svn: 108194

llvm-svn: 108159

-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

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

be a dependent expression when its is built.

llvm-svn: 108026