branch/revision information. Use that information in the driver,
rather than one-off branch/revision computation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83321 91177308-0d34-0410-b5e6-96231b3b80d8
explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83225 91177308-0d34-0410-b5e6-96231b3b80d8
- Add ObjCInterfaceDecl::lookupPrivateInstanceMethod().
- Convert clients.
No functionality change - One less method in Sema:-)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83224 91177308-0d34-0410-b5e6-96231b3b80d8
of the flow-control checks for falling off the end of a function,
since the return type may instantiate to void. Similarly, if a
return statement has an expression and the return type of the function
is void, don't complain if the expression is type-dependent, since
that type could instantiate to void.
Fixes PR5071.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83222 91177308-0d34-0410-b5e6-96231b3b80d8
functions when they are explicitly declared, e.g., via a function
template specialization or explicit template instantiation
declaration. Don't try to synthesize bodies for the special member
functions in this case; rather, check whether we have an implicit
declaration and, if so, synthesize the appropriate function
body. Fixes PR5084.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83212 91177308-0d34-0410-b5e6-96231b3b80d8
type is a template-id (e.g., basic_ostream<CharT, Traits>) and the
argument type is a class that has a derived class matching the
parameter type. Previously, we were giving up on template argument
deduction too early.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83177 91177308-0d34-0410-b5e6-96231b3b80d8
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic.
One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:
assert(Result.isInvalid() &&
"C++ binary operator overloading is missing
candidates!");
if (Result.isInvalid())
PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);
The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83175 91177308-0d34-0410-b5e6-96231b3b80d8
scheme, we can switch the previous scheme over to using this code
path. There's a bit of simplifications yet to do as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83138 91177308-0d34-0410-b5e6-96231b3b80d8
concrete types. Use unqualified desugaring for getAs<> and sundry.
Fix a few users to either not desugar or use qualified desugar, as seemed
appropriate. Removed Type's qualified desugar method, as it was easy
to accidentally use instead of QualType's.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83116 91177308-0d34-0410-b5e6-96231b3b80d8
Parameter declarations that differ only in the presence or absence of const and/or volatile are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83104 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
Douglas Gregor
Benjamin Kramer
Anders Carlsson
Mike Stump
Steve Naroff
Ted Kremenek
Rafael Espindola
John McCall
Tanya Lattner
Argyrios Kyrtzidis