| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
expression after overloading completes, make sure to keep the qualifier. Still not ready with that test-case...
llvm-svn: 84880
|
|
|
|
| |
llvm-svn: 84793
|
|
|
|
|
|
|
| |
conversion types for builtin overloaded operator candidates; I misread
this section in the standard the first time around.
llvm-svn: 84788
|
|
|
|
|
|
| |
Substitute TemplateIdRefExprs with DeclRefExprs. Doug, plz review :)
llvm-svn: 84763
|
|
|
|
|
|
| |
an overloaded function call operator.
llvm-svn: 84745
|
|
|
|
|
|
| |
testcase yet because FixOverloadedFunctionReference needs to be updated too. Doug, plz review.
llvm-svn: 84693
|
|
|
|
| |
llvm-svn: 84662
|
|
|
|
| |
llvm-svn: 84660
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<<=, >>= and the rest.
llvm-svn: 84568
|
|
|
|
|
|
|
| |
to '+=', '-=', '*=' and '/=' builtin operators and
fixes a logic bug exposed by doing this.
llvm-svn: 84538
|
|
|
|
|
|
|
| |
is a standard convesion and not a user-defined
conversion.
llvm-svn: 84525
|
|
|
|
|
|
|
|
| |
mark the result as referenced.
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
|
|
|
|
|
|
| |
builtin function ambiguity.
llvm-svn: 84289
|
|
|
|
|
|
|
| |
candidate types in BuiltinCandidateTypeSet::AddPointerWithMoreQualifiedTypeVariants
further trimming the overload candidate set.
llvm-svn: 84281
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 84043
|
|
|
|
| |
llvm-svn: 84034
|
|
|
|
| |
llvm-svn: 84030
|
|
|
|
|
|
| |
wip - To prune excessive reporting.
llvm-svn: 83889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 83694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will improve error messages. For
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
|
|
|
|
| |
llvm-svn: 83685
|
|
|
|
|
|
|
|
|
| |
users to
pass a LookupResult reference to lookup routines. Call out uses which assume a single
result.
llvm-svn: 83674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
operator's types.
llvm-svn: 83648
|
|
|
|
|
|
| |
I still don't like it but it is improvement over what we had.
llvm-svn: 83603
|
|
|
|
| |
llvm-svn: 83495
|
|
|
|
|
|
|
| |
convesion functions, look in base classes to.
(Removes a FIXME).
llvm-svn: 83472
|
|
|
|
|
|
| |
per Doug's obsevation.
llvm-svn: 83464
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
handle checking for a null pointer for a zero-valued
enumerator; moving the test case from CodeGen to Sema.
llvm-svn: 83350
|
|
|
|
|
|
| |
deciding const of null pointer conversion. Fixes PR5086.
llvm-svn: 83217
|
|
|
|
|
|
| |
user-defined type conversion. Fixes PR5040.
llvm-svn: 83211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 83153
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
function.
llvm-svn: 83027
|
|
|
|
| |
llvm-svn: 83022
|
|
|
|
|
|
|
| |
purpose of overload resolution is to be treated as a uner-defined
conversion.
llvm-svn: 83004
|
|
|
|
|
|
| |
reference/pointer. And a test case for code gen.
llvm-svn: 83000
|
|
|
|
|
|
|
| |
multiple times. This requires to be more careful about re-adding
candidates cached from the function template definition.
llvm-svn: 82967
|
|
|
|
| |
llvm-svn: 82844
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|