Missing special lookup rule in Sema::ActOnInstanceMessage().

llvm-svn: 59467

C++ constructors, destructors, and conversion functions now have a
FETokenInfo field that IdentifierResolver can access, so that these
special names are handled just like ordinary identifiers. A few other
Sema routines now use DeclarationNames instead of IdentifierInfo*'s.

To validate this design, this code also implements parsing and
semantic analysis for id-expressions that name conversion functions,
e.g.,

  return operator bool();

The new parser action ActOnConversionFunctionExpr takes the result of
parsing "operator type-id" and turning it into an expression, using
the IdentifierResolver with the DeclarationName of the conversion
function. ActOnDeclarator pushes those conversion function names into
scope so that the IdentifierResolver can find them, of course.

llvm-svn: 59462

are trying to use the old GCC "casts as lvalue" extension.  We don't and
will hopefully never support this.

llvm-svn: 59460

llvm-svn: 59459

llvm-svn: 59444

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

llvm-svn: 59426

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

llvm-svn: 59331

function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)

I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.

llvm-svn: 59306

candidates. Thanks to Chris for the review!

llvm-svn: 59260

llvm-svn: 59255

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

llvm-svn: 59167

llvm-svn: 59163

llvm-svn: 59157

adding a testcase.

llvm-svn: 59156

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

Introduce a single AST node SizeOfAlignOfExpr for all sizeof and alignof expressions, both of values and types.

llvm-svn: 59057

llvm-svn: 59042

llvm-svn: 59036

llvm-svn: 59027

llvm-svn: 59000

llvm-svn: 58990

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

Introduce ScopedDecl::getLexicalDeclContext() which is different from ScopedDecl::getDeclContext() when there are nested-names.
e.g.:
  namespace A {
    void f(); // SemanticDC (getDeclContext) == LexicalDC (getLexicalDeclContext) == 'namespace A'
  }
  void A::f(); // SemanticDC == namespace 'A'
               // LexicalDC == global namespace

llvm-svn: 58948

When a tag has nested-name ('struct foo::bar'), use not 'CurContext' but the context of the nested-name ('foo::').

llvm-svn: 58945

-Use more of the non nested-name code path.
-Also use the ActOnTagStruct code path.

llvm-svn: 58944

llvm-svn: 58916

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

llvm-svn: 58913

Move named cast helpers out of Sema, as Chris requested. This requirse making a few functions public that weren't before.

llvm-svn: 58906

llvm-svn: 58873

llvm-svn: 58870

-When parsing declarators, don't depend on "CurScope->isCXXClassScope() == true" for constructors/destructors
-For C++ member declarations, don't depend on "Declarator.getContext() == Declarator::MemberContext"

llvm-svn: 58866

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

void f() {
   int +; // crash here
}

llvm-svn: 58846

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