llvm-svn: 102695

specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.

llvm-svn: 102693

entering the current instantiation.  Set up a little to preserve type location
information for typename types while we're in there.

Fixes a Boost failure.

llvm-svn: 102673

address of an overloaded function (or function template), perform that
resolution prior to determining the implicit conversion
sequence. This resolution is not part of the implicit conversion
sequence itself.

Previously, we would always consider this resolution to be a
function pointer decay, which was a lie: there might be an explicit &
in the expression, in which case decay should not occur. This caused
the CodeGen assertion in PR6973 (where we created a 
pointer to a pointer to a function when we should have had a pointer
to a function), but it's likely that there are corner cases of
overload resolution where this would have failed.

Cleaned up the code involved in determining the type that will
produced afer resolving the overloaded function reference, and added
an assertion to make sure the result is correct. Fixes PR6973.

llvm-svn: 102650

categories. Issue usual warnings instead of
confusing error message. Radar 7920807

llvm-svn: 102645

Do some minor refactoring along the way.

llvm-svn: 102635

for similar methods.  No functionality change.

llvm-svn: 102634

specializations, substitute the deduced template arguments and check
the resulting substitution before concluding that template argument
deduction succeeds. This marvelous little fix makes a bunch of
Boost.Spirit tests start working.

llvm-svn: 102601

specializations, separate out the deduction part from the checking and
substitution of the deduced arguments.

llvm-svn: 102600

bindings when the template argument is still an expression; it happens
while checking the template arguments of a class template partial
specializations. Fixes PR6964.

llvm-svn: 102595

template decl itself, not its context.  Testcase to follow;  fixes selfhost.

llvm-svn: 102578

template argument deduction or (more importantly) the final substitution
required by such deduction.  Makes access control magically work in these
cases.

Fixes PR6967.

llvm-svn: 102572

classes, since we only warn (not error) on offsetof() for non-POD
types. We store the base path within the OffsetOfExpr itself, then
evaluate the offsets within the constant evaluator.

llvm-svn: 102571

as well as pre- and post-inc/decrements in C (not that I think it
matters for any C code).

llvm-svn: 102552

Fix template instantiation for __builtin_offfsetof expressions that refer to members of anonymous structs/unions

llvm-svn: 102551

llvm-svn: 102548

Amadini.

This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.

OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.

There are two major caveats to this patch:

  1) CodeGen cannot handle the case where __builtin_offsetof is not a
  constant expression, so it produces an error. So, to avoid
  regressing in C, we retain the old UnaryOperator-based
  __builtin_offsetof implementation in C while using the shiny new
  OffsetOfExpr implementation in C++. The old implementation can go
  away once we have proper CodeGen support for this case, which we
  expect won't cause much trouble in C++.

  2) __builtin_offsetof doesn't work well with non-POD class types,
  particularly when the designated field is found within a base
  class. I will address this in a subsequent patch.

Fixes PR5880 and a bunch of assertions when building Boost.Python
tests. 

llvm-svn: 102542

ivar of c++ object types.

llvm-svn: 102500

llvm-svn: 102496

complete, return an error rather than falling back to building a
dependent declaration reference, since we might not be in a dependent
context. Fixes a fiendish crash-on-invalid in Boost.FunctionTypes that
I wasn't able to reduce to anything useful.

llvm-svn: 102491

template argument deduction, use the lexical declaration context as
the owner for friend function templates. Fixes 2 failures in
Boost.Graph.

llvm-svn: 102489

visible. Fixes the remaining two failures in Boost.ScopeExit.

llvm-svn: 102466

keep track of whether we need to zero-initialize storage prior to
calling its constructor. Previously, we were only tracking this when
implicitly constructing the object (a CXXConstructExpr).

Fixes Boost's value-initialization tests, which means that the
Boost.Config library now passes all of its tests.

llvm-svn: 102461

we were relying on checking for abstract class types when an array
type was actually used to declare a variable, parameter, etc. However,
we need to check when the construct the array for, e.g., SFINAE
purposes (see DR337). Fixes problems with Boost's is_abstract type
trait. 

llvm-svn: 102452

UnresolvedLookupExpr and UnresolvedMemberExpr by substituting the
naming class we computed when building the expression in the
template...

... which we didn't always do correctly. Teach
UnresolvedMemberExpr::getNamingClass() all about the new 
representation of injected-class-names in templates, so	that it	can
return a naming	class that is the current instantiation.

Also, when decomposing a template-id into its template name and its
arguments, be sure to set the naming class on the LookupResult
structure. 

Fixes PR6947 the right way.

llvm-svn: 102448

from AST, consider ivar array of objects
(per Doug's comment).

llvm-svn: 102446

tag of the same name, compare the lookup contexts rather than the
actual contexts. Fixes PR6923.

llvm-svn: 102437

variables. Fixes PR6948.

llvm-svn: 102436

expressions, be sure to set the naming class of the LookupResult
structure. Fixes PR6947.

llvm-svn: 102434

with a qualifier referencing a different type.

llvm-svn: 102409

of a class template or class template partial specialization.  That is to
say, in
  template <class T> class A { ... };
or
  template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context.  This allows us to track the
current instantiation appropriately even inside AST routines.  It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).

llvm-svn: 102407

by using TypeSourceInfo, cleaning up the representation
somewhat. Teach getTypeOperand() to strip references and
cv-qualifiers, providing the semantic view of the type without
requiring any extra storage (the unmodified type remains within the
TypeSourceInfo). This fixes a bug found by Boost's call_traits test.

Finally, clean up semantic analysis, by splitting the ActOnCXXTypeid
routine into ActOnCXXTypeId (the parser action) and two BuildCXXTypeId
functions, which perform the semantic analysis for typeid(type) and
typeid(expression), respectively. We now perform less work at template
instantiation time (we don't look for std::type_info again) and can
give better diagnostics.

llvm-svn: 102393

llvm-svn: 102390

thing. Audit all uses of Type::isStructure(), changing those calls to
isStructureOrClassType() as needed (which is alsmost
everywhere). Fixes the remaining failure in Boost.Utility/Swap.

llvm-svn: 102386

Objective-C++. This is the last bit of (non-blocks-related) template
instantiation logic for Objective-C++. Yay! 

llvm-svn: 102382

llvm-svn: 102379

references and isa expressions. Also, test template instantiation of
unresolved member references to Objective-C ivar references and isa
expressions.

llvm-svn: 102374

statements. This is the last of the Objective-C statements.

llvm-svn: 102356

function-parameter checking and splitting it into the normal
ActOn*/Build* pair in Sema. We now use VarDecl to represent the @catch
parameter rather than the ill-fitting ParmVarDecl.

llvm-svn: 102347

@catch a VarDecl. The dynamic type is still a ParmVarDecl, but that
will change soon. No effective functionality change.

llvm-svn: 102341