(use of return instead of continue), wording.

llvm-svn: 150215

llvm-svn: 150212

llvm-svn: 150210

llvm-svn: 150209

This looks like it had a small, but measurable performance improvement on -O0
compile time for our ObjC tests.

llvm-svn: 150208

llvm-svn: 150207

has been declared in its primary class, superclass,
or in one of their protocols, no need to issue unimplemented method. 
// rdar://10823023

llvm-svn: 150206

Make sure a variable with a C++ direct initializer triggers jump scope checking.  Fixes PR10620 / <rdar://problem/9958362> .

llvm-svn: 150204

It was never updated for API changes in r149311/r149336/r149339
and r147688.

llvm-svn: 150202

Hardcoding the location of the build directory seems like it would
break at `make install`/packaging time.

llvm-svn: 150201

Double fields of by-value class objects should be passed in floating point
registers.

llvm-svn: 150200

Kill the brief and full explanation fields from StaticDiagInfoRec. They were unused and wasted space for nothing.

- per PR11952.

llvm-svn: 150199

class objects follow the same rules as those returning struct objects.

llvm-svn: 150196

list; it is not an expression.

llvm-svn: 150194

llvm-svn: 150193

llvm-svn: 150192

semantics. 

llvm-svn: 150190

llvm-svn: 150181

llvm-svn: 150180

llvm-svn: 150172

[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.

llvm-svn: 150168

function call operator (to the lambda class). This allows us to IRgen
calls to simple (non-capturing) lambdas, e.g.,

  [](int i, int j) -> int { return i + j; }(1, 2)

Eli will be providing test cases as he brings up more IRgen.

llvm-svn: 150166

and rapidly becoming untrue.

llvm-svn: 150165

[expr.prim.lambda].

llvm-svn: 150164

unevaluated operands. Be certain that we're marking everything
referenced within a capture initializer as odr-used.

llvm-svn: 150163

llvm-svn: 150162

We were passing a decl to the consumer after all pending deserializations were finished
but this was not enough; due to processing by the consumer we may end up into yet another
deserialization process but the way FinishedDeserializing() was setup we would not ensure
that everything was fully deserialized before returning to the consumer.

Separate ASTReader::FinishedDeserializing() into two semantic actions.
The first is ensuring that a deserialization process ends up will fully deserialized decls/types even
if the process is started by the consumer.
The second is pushing "interesting" decls to the consumer; we make sure that we don't re-enter this
section recursively be checking a variable.

llvm-svn: 150160

difference in the qual type. This is a workaround for the fact that
the type isn't artificial but the this decl is, however, we don't
have any way of representing it in the current metadata. For now,
however, just don't cache the full type.

Fixes rdar://10831526 and probably a couple of others.

llvm-svn: 150159

llvm-svn: 150158

empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.

llvm-svn: 150157

Very simple so far - we just highlight every allocation and release
site.

llvm-svn: 150156

llvm-svn: 150155

calls to Decl::getASTContext() by Decl's methods will find the TranslationUnitDecl
without crashing due to a parent declaration context still deserializing.

llvm-svn: 150153

This was from way-back-when (r82583) when Clang's C++ support wasn't prime-time
yet. Production quality C++ was tested experimentally from r100119 and turned
on by default in r141063.

Patch by Justin Bogner.

llvm-svn: 150148

llvm-svn: 150147

llvm-svn: 150146

lvalue-to-rvalue conversions in constant expressions.

llvm-svn: 150145

Patch by Remi Gacogne

llvm-svn: 150144

llvm-svn: 150141

llvm-svn: 150140