under the ARM ABI.

llvm-svn: 112588

terrible, FIXME left to do a proper job of diagnosing this.

llvm-svn: 112581

llvm-svn: 112580

declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.

llvm-svn: 112579

Teach the CFGBuilder not do die on CXXBindTemporaryExpr, CXXOperatorCallExpr. Fixes a Boost.Graph crasher.

llvm-svn: 112578

llvm-svn: 112577

llvm-svn: 112569

llvm-svn: 112566

Add a forgotten place where the enclosing namespace set matters, plus a big testcase for inline namespace fun.

llvm-svn: 112565

llvm-svn: 112564

Rename DeclContext::getLookupContext to getRedeclContext and change its semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them.

llvm-svn: 112563

Decl::getEnclosingNamespaceContext has no reason to explicitly skip transparent contexts, and would be wrong to do so with inline namespaces.

llvm-svn: 112562

instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.

We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.

We now compile Boost.Polygon properly.

llvm-svn: 112561

llvm-svn: 112552

of that parameter, reduce the level by the number of active template
argument lists rather than by 1. The number of active template
argument lists is only > 1 when we have a class template partial
specialization of a member template of a class template that itself is
a member template of another class template. 

... and Boost.MSM does this. Fixes PR7669.

llvm-svn: 112551

llvm-svn: 112549

llvm-svn: 112541

llvm-svn: 112537

llvm-svn: 112533

namely when the friend function prototype is already used
at the point of the template definition that is supposed
to inject the friend function. Testcase verifies four
scenarios.
I would like receive some code review for this.

llvm-svn: 112524

deduction where the parameter is a function reference, function
pointer, or member function pointer and the argument is an overloaded
function. Fixes <rdar://problem/8360106>, a template argument
deduction issue found by Boost.Filesystem.

llvm-svn: 112523

intrinsic.

llvm-svn: 112504

- Fixed a regression where assigning '0' would be reported
- Changed the way self assignments are filtered to allow constant testing
- Added a test case for assign ops
- Fixed one test case where a function pointer was not considered constant
- Fixed test cases relating to 0 assignment

llvm-svn: 112501

some issues being sorted out.

llvm-svn: 112493

llvm-svn: 112491

llvm-svn: 112490

ASTContext::DeclAttrs. Otherwise, iterators will go stale when the
DenseMap reallocates, which can cause crashes when, e.g., looping over
the attributes in a template to instantiate them and add the results
to the instantiation of that template.

llvm-svn: 112488

when we're taking the address of a unresolvable value, it might be an
implicit member access. Fixes some Boost.Spirit regressions.

llvm-svn: 112487

#pragma without requiring it to be in the "clang" namespace, from
Louis Gerbarg!

llvm-svn: 112484

specifications, from Martin Vejnar!

llvm-svn: 112482

the pp-number in a hexadecimal floating point literal, from Francois
Pichet! Fixes PR7968.

llvm-svn: 112481

llvm-svn: 112478

llvm-svn: 112477

case with redeclaration checking for fields, from Faisal Vali!
Fixes PR7970.

llvm-svn: 112476

llvm-svn: 112475

before using them.

llvm-svn: 112468

 - Zero-initialize UDLData so that crashes stop
 - Stop complaining that we can't emit them (we most certainly can)

llvm-svn: 112467

so please review echristo and let me know if the logic is wrong now.

llvm-svn: 112466

llvm-svn: 112460

The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.

llvm-svn: 112458