llvm-svn: 127133

llvm-svn: 127132

declaration because of interesting ordering dependencies while
instantiating a class template or member class thereof. Complain,
rather than asserting (+Asserts) or silently rejecting the code
(-Asserts).

Fixes the crash-on-invalid in PR8965. 

llvm-svn: 127129

llvm-svn: 127128

llvm-svn: 127126

arguments at the same offset, since it's needed when creating the empty
DeclRefExpr when deserializing. Fixes a memory corruption issue that would lead
to random bugs and crashes.

llvm-svn: 127125

llvm-svn: 127124

Fix copy-and-paste typo in the transformation of Microsoft __uuidof expressions, from Eric Niebler via John Wiegley

llvm-svn: 127123

llvm-svn: 127121

llvm-svn: 127120

llvm-svn: 127119

Reinstate r127112, "Propagate new-style exception spec information to ExtProtoInfo.", this time with the missing header.

llvm-svn: 127118

conversion function when we're binding the result to a reference, drop
cv-qualifiers on the type we're referring to, since we should be
deducing a type that can be adjusted (via cv-qualification) to the
requested type. Fixes PR9336, and the remaining Boost.Assign failure.

llvm-svn: 127117

It seems missing "clang/Basic/ExceptionSpecificationType.h".

llvm-svn: 127115

llvm-svn: 127112

llvm-svn: 127111

template name as the result of substitution. The qualifier is handled
separately by the tree transformer, so we would end up in an
inconsistent state.

This is actually the last bit of PR9016, and possibly also fixes
PR8965. It takes Boost.Icl from "epic fail" down to a single failure.

llvm-svn: 127108

llvm-svn: 127094

template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.

Fixes PR9016.

llvm-svn: 127092

transform the type that replaces the template type parameter. In the
vast majority of cases, there's nothing to do, because most template
type parameters are replaced with something non-dependent that doesn't
need further transformation. However, when we're dealing with the
default template arguments of template template parameters, we might
end up replacing a template parameter (of the template template
parameter) with a template parameter of the enclosing template. 
 
This addresses part of PR9016, but not within function
templates. That's a separate issue.

llvm-svn: 127091

that at cc1 level we will always have normalized triple and thus can
provide necessary default based on e.g. environment value (e.g. for
"arm-eabi" triple, etc.)

llvm-svn: 127087

llvm-svn: 127086

llvm-svn: 127085

llvm-svn: 127082

llvm-svn: 127061

use the translation unit as its declaration context, then deserialize
the actual lexical and semantic DeclContexts after the template
parameter is complete. This avoids problems when the DeclContext
itself (e.g., a class template) is dependent on the template parameter
(e.g., for the injected-class-name).

llvm-svn: 127056

Currently we can only remap a file by creating a MemoryBuffer and replacing the file contents with it.
Allow remapping a file by specifying another filename whose contents should be loaded if the original
file gets loaded. This allows to override files without having to create & load buffers in advance.

llvm-svn: 127052

Introduce OwnsRemappedFileBuffers field in ASTUnit, indicating whether the ASTUnit should delete the remapped buffers.

llvm-svn: 127051

When diagnostics are suppressed (e.g., because of code completion), don't trigger the ExprTemplates.empty() check at the end of a function body

llvm-svn: 127046

llvm-svn: 127042

too. Fixes PR7900.

While I'm in this area, improve the diagnostic when the type being
destroyed doesn't match either of the types we found.

llvm-svn: 127041

llvm-svn: 127039

to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.

llvm-svn: 127037

to find the instantiated declaration within a template instantiation
fails to do so. It's likely that the original instantiation got
dropped due to instantiation failures, which doesn't actually break
the invariants of the AST. This eliminates a number of
crash-on-invalid failures, e.g., PR9300.

llvm-svn: 127030

properly cope with NULL return values.

llvm-svn: 127024

Emit a stop point before a call expression so that debugger has some chance of getting some footing when user wants to stop at 2nd bar() in following expression when all function calls are inlined.
  = bar() + ... + bar() + ...

clang keeps track of column numbers, so we could put location entries for all subexpressions but that will significantly bloat debug info in general, but a location for call expression is helpful here.

llvm-svn: 127018

DependentTemplateSpecializationType during tree transformation, retain
the NestedNameSpecifierLoc as it was used to translate the template
name, rather than reconstructing it from the template name.

Fixes PR9401.

llvm-svn: 127015

capture the template parameters of template template parameters.

llvm-svn: 127012

DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.

Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).

How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?

I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.

llvm-svn: 127004

template <class T> void foo();
template <> void foo<int>(); /* Spec 1 */
template <> void foo<int>(); /* Spec 2 */

If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1.
Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location).

llvm-svn: 127002