a class type from itself or a derived class thereof, enumerate
constructors and permit user-defined conversions to the arguments of
those constructors. This fixes the wacky implicit conversion sequence
used in std::auto_ptr's lame emulation of move semantics.
llvm-svn: 88670
- Comparing template parameter lists to determine if we have a redeclaration
- Comparing template parameter lists to determine if we have equivalent
template template parameters
- Comparing template parameter lists to determine whether a template
template argument is valid for a given template template parameter.
Previously, we did not distinguish between the last two cases, which
got us into trouble when we were looking for exact type matches
between the types of non-type template parameters that were dependent
types. Now we do, so we properly delay checking of template template
arguments until instantiation time.
Also, fix an accidental fall-through in a case statement that was
causing crashes.
llvm-svn: 86992
ArrayType>()) does not instantiate. Update all callers that used this
unsafe feature to use the appropriate ASTContext::getAs*ArrayType method.
llvm-svn: 86596
(without complaining if it fails) to get proper semantics: reference
binding with a derived-to-base conversion and the enumeration of
constructors for user-defined conversions. There are probably more
cases to fix, but my prior attempt at statically ensuring that
complete-type checking always happens failed. Perhaps I'll try again.
With this change, Clang can parse include/llvm/*.h!
llvm-svn: 86129
still be dependent or invoke an overloaded operator. Previously, we
only supported builtin operators.
BinaryOperator/CompoundAssignOperator didn't have this issue because
we always built a CXXOperatorCallExpr node, even when name lookup
didn't find any functions to save until instantiation time. Now, that
code builds a BinaryOperator or CompoundAssignOperator rather than a
CXXOperatorCallExpr, to save some space.
llvm-svn: 86087
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
llvm-svn: 85500
so that we maintain better source information after template argument
deduction and overloading resolves down to a specific
declaration. Found and dealt with a few more cases that
FixOverloadedFunctionReference didn't cope with.
(Finally) added a test case that puts together this change with the
DeclRefExpr change to (optionally) include nested-name-specifiers and
explicit template argument lists.
llvm-svn: 84974
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,
namespace N { int i; }
int j = N::i;
Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.
Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.
llvm-svn: 84962
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
llvm-svn: 84623
The most important effect of this is that function templates only referenced by address expressions now get instantiated. This, in turn, means that Hello World compiles with the Apache stdcxx library even when using endl.
llvm-svn: 84363
Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case.
llvm-svn: 84362
sets of builtin operators. Currently, it is applied
to '++' and '->*' operators. I need to apply it to others
as well. Also, heuristics need be applied to
BuiltinCandidateTypeSet::AddPointerWithMoreQualifiedTypeVariants.
This is WIP.
llvm-svn: 84187
to a member operator template. We missed updating this call site when
adding support for function templates; bug exposed by a test for
PR5072.
llvm-svn: 84111
user-defined type conversions, issue list of ambiguites in addition
to the diagnostic. So, clang now issues the following:
b.cpp:19:19: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct C1'
int i = c1->*pmf;
~~^
b.cpp:19:19: note: because of ambiguity in conversion of 'struct C1' to 'struct E *'
b.cpp:5:5: note: candidate function
operator E*();
^
b.cpp:11:5: note: candidate function
operator E*();
^
llvm-svn: 83862
struct B;
B f();
void g() {
f();
}
We now get
t.cpp:6:3: error: calling 'f' with incomplete return type 'struct B'
f();
^~~
t.cpp:3:3: note: 'f' declared here
B f();
^
t.cpp:1:8: note: forward declaration of 'struct B'
struct B;
^
llvm-svn: 83692
Now we produce things like:
bug1.cpp:21:11: error: use of overloaded operator '->*' is ambiguous
int i = c->*pmf; // expected-error {{use of overloaded operator '->*' is ambiguous}} \
~^ ~~~
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int const struct A::*')
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int restrict struct A::*')
...
Still need to look at an issue (indicated as FIXME in the test case).
llvm-svn: 83650
Doug, please review. There is a FIXME in the test case with a question
which is unrelated to this patch (that is, error is issued
before set of builtins are added to the candidate list).
llvm-svn: 83429
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
llvm-svn: 83396
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.
llvm-svn: 83175
had to do with an initialized field when multiple type conversions
are ambiguous but must be treated as user defined conversion for
overload resolution purposes.
llvm-svn: 83079
value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.
In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.
llvm-svn: 82748
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
llvm-svn: 82728
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
llvm-svn: 82705
that there is one more argument (the one following the comma) and make
the candidate non-viable if the function cannot accept any argument in
that position.
llvm-svn: 82625
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
llvm-svn: 82549
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
llvm-svn: 81907
Douglas Gregor