llvm-svn: 59443

llvm-svn: 59442

representing the names of declarations in the C family of
languages. DeclarationName is used in NamedDecl to store the name of
the declaration (naturally), and ObjCMethodDecl is now a NamedDecl.

llvm-svn: 59441

Thanks to Doug for the review. Actual effects of mutable to follow.

llvm-svn: 59331

conversion functions. Instead, we just use a placeholder identifier
for these (e.g., "<constructor>") and override NamedDecl::getName() to
provide a human-readable name.

This is one potential solution to the problem; another solution would
be to replace the use of IdentifierInfo* in NamedDecl with a different
class that deals with identifiers better. I'm also prototyping that to
see how it compares, but this commit is better than what we had
previously.

llvm-svn: 59193

functions for built-in operators, e.g., the builtin

  bool operator==(int const*, int const*)

can be used for the expression "x1 == x2" given:

  struct X {
    operator int const*();
  } x1, x2;

The scheme for handling these built-in operators is relatively simple:
for each candidate required by the standard, create a special kind of
candidate function for the built-in. If overload resolution picks the
built-in operator, we perform the appropriate conversions on the
arguments and then let the normal built-in operator take care of it. 

There may be some optimization opportunity left: if we can reduce the
number of built-in operator overloads we generate, overload resolution
for these cases will go faster. However, one must be careful when
doing this: GCC generates too few operator overloads in our little
test program, and fails to compile it because none of the overloads it
generates match.

Note that we only support operator overload for non-member binary
operators at the moment. The other operators will follow.

As part of this change, ImplicitCastExpr can now be an lvalue.

llvm-svn: 59148

llvm-svn: 59000

llvm-svn: 58988

llvm-svn: 58987

Some cleanups to the declaration/checking of overloaded operators in C++. Thanks to Sebastian for the review

llvm-svn: 58986

llvm-svn: 58916

No Sema functionality change, just the signatures of the Action/Sema methods.

llvm-svn: 58913

functions in C++, e.g.,

  struct X {
    operator bool() const;
  };

Note that these conversions don't actually do anything, since we don't
yet have the ability to use them for implicit or explicit conversions.

llvm-svn: 58860

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

llvm-svn: 58804

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

Keep track of whether a C++ class is an aggregate. Don't allow initialization of non-aggregates with initializer lists.

llvm-svn: 58757

duplication in the handling of copy-initialization by constructor,
which occurs both for initialization of a declaration and for
overloading. The initialization code is due for some refactoring.

llvm-svn: 58756

for constructor initializations, e.g.,

  class A { };
  class B : public A { 
    int m;
  public:
    B() : A(), m(17) { };
  };

llvm-svn: 58749

Create a new expression class, CXXThisExpr, to handle the C++ 'this' primary expression. Remove CXXThis from PredefinedExpr

llvm-svn: 58695

llvm-svn: 58692

Diagnose use of 'this' in a C++ default argument. Thanks to Eli for correcting my bogus assertion about it already being handled

llvm-svn: 58691

llvm-svn: 58649

  X x(5, 7);

llvm-svn: 58641

cope with the case where a user-defined conversion is actually a copy
construction, and therefore can be compared against other standard
conversion sequences. While I called this a hack before, now I'm
convinced that it's the right way to go.

Compare overloads based on derived-to-base conversions that invoke
copy constructors. 

Suppress user-defined conversions when attempting to call a
user-defined conversion.

llvm-svn: 58629

when appropriate.

Conversions for class types now make use of copy constructors. I've
replaced the egregious hack allowing class-to-class conversions with a
slightly less egregious hack calling these conversions standard
conversions (for overloading reasons).

llvm-svn: 58622

llvm-svn: 58538

conversions.

Notes:
  - Overload resolution for converting constructors need to prohibit
    user-defined conversions (hence, the test isn't -verify safe yet).
  - We still use hacks for conversions from a class type to itself. 
    This will be the case until we start implicitly declaring the appropriate
    special member functions. (That's next on my list)

llvm-svn: 58513

etc more generic. For some targets, long may not be equal to pointer size. For
example: PIC16 has int as i16, ptr as i16 but long as i32.

Also fixed a few build warnings in assert() functions in CFRefCount.cpp,
CGDecl.cpp, SemaDeclCXX.cpp and ParseDeclCXX.cpp.

llvm-svn: 58501

Notes:
  - Constructors are never found by name lookup, so they'll never get
    pushed into any scope. Instead, they are stored as an 
    OverloadedFunctionDecl in CXXRecordDecl for easy overloading.
  - There's a new action isCurrentClassName that determines whether an
    identifier is the name of the innermost class currently being defined;
    we use this to identify the declarator-id grammar rule that refers to 
    a type-name. 
  - MinimalAction does *not* support parsing constructors.
  - We now handle virtual and explicit function specifiers.

llvm-svn: 58499

llvm-svn: 58404

llvm-svn: 58381

ImplicitConversionSequence and, when doing so, following the specific
rules of [over.best.ics]. 

The computation of the implicit conversion sequences implements C++
[over.ics.ref], but we do not (yet) have ranking for implicit
conversion sequences that use reference binding.

llvm-svn: 58357

of copy initialization. Other pieces of the puzzle:

  - Try/Perform-ImplicitConversion now handles implicit conversions
    that don't involve references.
  - Try/Perform-CopyInitialization uses
    CheckSingleAssignmentConstraints for C. PerformCopyInitialization
    is now used for all argument passing and returning values from a
    function.
  - Diagnose errors with declaring references and const values without
    an initializer. (Uses a new Action callback, ActOnUninitializedDecl).
  
We do not yet have implicit conversion sequences for reference
binding, which means that we don't have any overloading support for
reference parameters yet.

llvm-svn: 58353

llvm-svn: 58040

Factored the QualTypeOrdering predicate into its own header
(TypeOrdering.h), now that it is used in two places.

llvm-svn: 58001

don't have duplicated direct base classes.

Seriliazation of base class specifiers is not yet implemented.

llvm-svn: 57991

llvm-svn: 57909

typedef int f();
struct S {
   f *x; // incorrectly assuming this is function decl, leading to failed assertions.
};

llvm-svn: 57598

llvm-svn: 57514