- Support initialization of reference members; complain if any
reference members are left uninitialized.
- Use C++ copy-initialization for initializing each element (falls
back to constraint checking in C)
- Make sure we diagnose when one tries to provide an initializer
list for a non-aggregate.
- Don't complain about empty initializers in C++ (they are permitted)
- Unrelated but necessary: don't bother trying to convert the
decl-specifier-seq to a type when we're dealing with a C++
constructor, destructor, or conversion operator; it results in
spurious warnings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63431 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a stupid mistake in UnwrapSimilarPointers that made any two member pointers compatible as long as the pointee was the same.
Make a few style corrections as suggested by Chris.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63215 91177308-0d34-0410-b5e6-96231b3b80d8
Small cleanup in the handling of user-defined conversions.
Also, implement an optimization when constructing a call. We avoid
recomputing implicit conversion sequences and instead use those
conversion sequences that we computed as part of overload resolution.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62231 91177308-0d34-0410-b5e6-96231b3b80d8
Duplicate-member checking within classes is still a little messy, and
anonymous unions are still completely broken in C. We'll need to unify
the handling of fields in C and C++ to make this code applicable in
both languages.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61878 91177308-0d34-0410-b5e6-96231b3b80d8
functions. They work except that name lookup within the default
arguments needs to be deferred until the class definition is complete
(see FIXME in the test).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61059 91177308-0d34-0410-b5e6-96231b3b80d8
being called to be converted to a reference-to-function,
pointer-to-function, or reference-to-pointer-to-function. This is done
through "surrogate" candidate functions that model the conversions
from the object to the function (reference/pointer) and the
conversions in the arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59674 91177308-0d34-0410-b5e6-96231b3b80d8
with function call syntax, e.g.,
Functor f;
f(x, y);
This is the easy part of handling calls to objects of class type
(C++ [over.call.object]). The hard part (coping with conversions from
f to function pointer or reference types) will come later. Nobody uses
that stuff anyway, right? :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59663 91177308-0d34-0410-b5e6-96231b3b80d8
built-in operator candidates. Test overloading of '&' and ','.
In C++, a comma expression is an lvalue if its right-hand
subexpression is an lvalue. Update Expr::isLvalue accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59643 91177308-0d34-0410-b5e6-96231b3b80d8
post-decrement, including support for generating all of the built-in
operator candidates for these operators.
C++ and C have different rules for the arguments to the builtin unary
'+' and '-'. Implemented both variants in Sema::ActOnUnaryOp.
In C++, pre-increment and pre-decrement return lvalues. Update
Expr::isLvalue accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59638 91177308-0d34-0410-b5e6-96231b3b80d8
operators. For example, one can now write "x + y" where x or y is a
class or enumeration type, and Clang will perform overload resolution
for "+" based on the overloaded operators it finds.
The other kinds of overloadable operators in C++ will follow this same
approach.
Three major issues remain:
1) We don't find member operators
2) Since we don't have user-defined conversion operators, we can't
call any of the built-in overloaded operators in C++ [over.built].
3) Once we've done the semantic checks, we drop the overloaded
operator on the floor; it doesn't get into the AST at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58821 91177308-0d34-0410-b5e6-96231b3b80d8
operators in C++. Overloaded operators can be called directly via
their operator-function-ids, e.g., "operator+(foo, bar)", but we don't
yet implement the semantics of operator overloading to handle, e.g.,
"foo + bar".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58817 91177308-0d34-0410-b5e6-96231b3b80d8
Implicit declaration of destructors (when necessary).
Extended Declarator to store information about parsed constructors
and destructors; this will be extended to deal with declarators that
name overloaded operators (e.g., "operator +") and user-defined
conversion operators (e.g., "operator int").
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58767 91177308-0d34-0410-b5e6-96231b3b80d8
for constructor initializations, e.g.,
class A { };
class B : public A {
int m;
public:
B() : A(), m(17) { };
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58749 91177308-0d34-0410-b5e6-96231b3b80d8
-Set "Named Casts" feature to partial parser/sema support because reinterpret_cast is not properly implemented.
-Removed "Virtual functions" feature because it is already covered by "Class definitions".
-Removed "Templates" because we should either list *all* missing/supported features or just list the features with some support. Mentioning just a few missing features without listing all of them makes little sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@53095 91177308-0d34-0410-b5e6-96231b3b80d8
Cedric Venet
Sebastian Redl
Douglas Gregor
Daniel Dunbar
Argyrios Kyrtzidis
Chris Lattner
Gabor Greif