As far as I know, this implementation is complete but might be missing a
few optimizations. Exceptions and virtual bases are handled correctly.
Because I'm an optimist, the web page has appropriately been updated. If
I'm wrong, feel free to downgrade its support categories.
llvm-svn: 130642
template<typename T> auto f(T a) -> decltype(a.foo());
Since this is the primary reason for the introduction of this feature, downgrade implementation status to "Some examples work".
llvm-svn: 129533
Turn on the __has_feature switch for variadic templates, document
their completion, and put the ExtWarn into the c++0x-extensions
warning group.
llvm-svn: 123854
explicit-instantiation-declaration-after-explicit-instantiation-definition
errors. This wraps up explicit template instantiation for now.
llvm-svn: 85347
Now that parsing, semantic analysis, and (I think) code generation of
pseudo-destructor expressions and explicit destructor calls works,
update the example-dynarray.cpp test to destroy the objects it
allocates and update the test to actually compile + link.
The code seems correct, but the Clang-compiled version dies with a
malloc error. Time to debug!
llvm-svn: 81025
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
llvm-svn: 80953
pointers, by extending the "composite pointer type" logic to include
member pointer types.
Introduce test cases for member pointer comparisons, including those
that involve the builtin operator candidates implemented earlier.
llvm-svn: 79925
Implement support for C++ Substitution Failure Is Not An Error
(SFINAE), which says that errors that occur during template argument
deduction do *not* produce diagnostics and do not necessarily make a
program ill-formed. Instead, template argument deduction silently
fails. This is currently implemented for template argument deduction
during matching of class template partial specializations, although
the mechanism will also apply to template argument deduction for
function templates. The scheme is simple:
- If we are in a template argument deduction context, any diagnostic
that is considered a SFINAE error (or warning) will be
suppressed. The error will be propagated up the call stack via the
normal means.
- By default, all warnings and errors are SFINAE errors. Add the
NoSFINAE class to a diagnostic in the .td file to make it a hard
error (e.g., for access-control violations).
Note that, to make this fully work, every place in Sema that emits an
error *and then immediately recovers* will need to check
Sema::isSFINAEContext() to determine whether it must immediately
return an error rather than recovering.
llvm-svn: 73332
specialization's arguments are identical to the implicit template
arguments of the primary template. Typically, this is meant to be a
declaration/definition of the primary template, so we give that
advice.
llvm-svn: 73259
still aren't instantiating the definitions of class template members,
and core issues 275 and 259 will both affect the checking that we do
for explicit instantiations (but are not yet implemented).
llvm-svn: 71613
template class X<int>;
This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.
llvm-svn: 71608
- 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.
llvm-svn: 63431
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.
llvm-svn: 63215
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.
llvm-svn: 62231
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.
llvm-svn: 61878
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).
llvm-svn: 61059
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.
llvm-svn: 59674
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? :)
llvm-svn: 59663
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.
llvm-svn: 59643
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.
llvm-svn: 59638
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.
llvm-svn: 58821
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".
llvm-svn: 58817
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").
llvm-svn: 58767
-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.
llvm-svn: 53095
Douglas Gregor