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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102491 91177308-0d34-0410-b5e6-96231b3b80d8
T::template apply<U>), handling a few cases where we previously failed
and performing substitutions on such dependent names. Fixes a crash in
Boost.PropertyTree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102490 91177308-0d34-0410-b5e6-96231b3b80d8
template argument deduction, use the lexical declaration context as
the owner for friend function templates. Fixes 2 failures in
Boost.Graph.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102489 91177308-0d34-0410-b5e6-96231b3b80d8
function types.
This could potentially have unexpected side-effects, so look here if there are
new regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102464 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102461 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102452 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102448 91177308-0d34-0410-b5e6-96231b3b80d8
This works around stack corruption / crashes resulting from PR6944, and also
works around people who expect 'what works on my machine' to work everywhere
(GCC crashes in a number of cases on SPARC that should now work correctly with
clang).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102430 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102407 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102393 91177308-0d34-0410-b5e6-96231b3b80d8
.S files. "# 123" is passed through as-is, not treated as a line
marker in this mode. No testcase, because it would be nasty and isn't
worth it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102391 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102386 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C++. This is the last bit of (non-blocks-related) template
instantiation logic for Objective-C++. Yay!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102382 91177308-0d34-0410-b5e6-96231b3b80d8
references and isa expressions. Also, test template instantiation of
unresolved member references to Objective-C ivar references and isa
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102374 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102347 91177308-0d34-0410-b5e6-96231b3b80d8
@catch a VarDecl. The dynamic type is still a ParmVarDecl, but that
will change soon. No effective functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102341 91177308-0d34-0410-b5e6-96231b3b80d8
using declaration, look at its underlying declaration to determine the
lookup result kind (e.g., overloaded, unresolved). Fixes at least one
issue in Boost.Bimap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102317 91177308-0d34-0410-b5e6-96231b3b80d8
- Fix some places that had the alignment hard coded.
- Use ABI type alignment, not preferred type alignment -- neither of this is exactly right, as we really want the C type alignment as required by the runtime, but the ABI alignment is a more correct choice.
This should be equivalent for x86_64, but fixes the alignment for ARM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102314 91177308-0d34-0410-b5e6-96231b3b80d8
Benjamin Kramer
David Chisnall
Abramo Bagnara
Douglas Gregor
John McCall
Eli Friedman
Fariborz Jahanian
Daniel Dunbar
Enea Zaffanella
Devang Patel
Chris Lattner