llvm-svn: 60131

llvm-svn: 60007

instead of converting them to strings first.  This also fixes a
bunch of minor inconsistencies in the diagnostics emitted by clang
and adds a bunch of FIXME's to DiagnosticKinds.def.

llvm-svn: 59948

llvm-svn: 59921

"previously defined here" diagnostics all notes.

llvm-svn: 59920

with implicit quotes around them.  This has a bunch of follow-on 
effects and requires tweaking to a whole lot of code.  This causes
a regression in two tests (xfailed) by causing it to emit things like:

  Line 10: duplicate interface declaration for category 'MyClass1' ('Category1')

instead of:

  Line 10: duplicate interface declaration for category 'MyClass1(Category1)'

I will fix this in a follow-up commit.

As part of this, I had to start switching stuff to use ->getDeclName() instead
of Decl::getName() for consistency.  This is good, but I was planning to do this
as an independent patch.  There will be several follow-on patches
to clean up some of the mess, but this patch is already too big.

llvm-svn: 59917

without calling getAsString().  This implicitly puts quotes around the
name, so diagnostics need to be tweaked to accommodate this.

llvm-svn: 59916

llvm-svn: 59888

Implement a %plural modifier for complex plural forms in diagnostics. Use it in the overload diagnostics.

llvm-svn: 59871

This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first.

llvm-svn: 59835

llvm-svn: 59822

llvm-svn: 59819

Enable some more operator overloading tests, and don't look into an identifier for functions that might not have one

llvm-svn: 59818

llvm-svn: 59789

expression (smart_ptr->mem).

llvm-svn: 59732

llvm-svn: 59675

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

struct A {
  struct B;
};

struct A::B {
  void m() {} // Assertion failed: getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."
};

Introduce DeclContext::getLexicalParent which may be different from DeclContext::getParent when nested-names are involved, e.g:

   namespace A {
      struct S;
   }
   struct A::S {}; // getParent() == namespace 'A'
                   // getLexicalParent() == translation unit

llvm-svn: 59650

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

With this snippet:
  void f(a::b);

An assert is hit:
Assertion failed: CachedTokens[CachedLexPos-1].getLocation() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token", file ..\..\lib\Lex\PPCaching.cpp, line 98

Introduce Preprocessor::RevertCachedTokens that reverts a specific number of tokens when backtracking is enabled.

llvm-svn: 59636

not "int".

Fix a typo in the promotion of enumeration types that was causing some
integral promotions to look like integral conversions (leading to
extra ambiguities in overload resolution).

Check for "acceptable" overloaded operators based on the types of the
arguments. This is a somewhat odd check that is specified by the
standard, but I can't see why it actually matters: the overload
candidates it suppresses don't seem like they would ever be picked as
the best candidates.

llvm-svn: 59583

to support operators defined as member functions, e.g.,

  struct X { 
    bool operator==(X&);
  };

Overloading with non-member operators is supported, and the special
rules for the implicit object parameter (e.g., the ability for a
non-const *this to bind to an rvalue) are implemented.

This change also refactors and generalizes the code for adding
overload candidates for overloaded operator calls (C++ [over.match.expr]),
both to match the rules more exactly (name lookup of non-member
operators actually ignores member operators) and to make this routine
more reusable for the other overloaded operators.

Testing for the initialization of the implicit object parameter is
very light. More tests will come when we get support for calling
member functions directly (e.g., o.m(a1, a2)).

llvm-svn: 59564

DeclRefExprs and BlockDeclRefExprs into a single function
Sema::ActOnDeclarationNameExpr, eliminating a bunch of duplicate
lookup-name-and-check-the-result code.

Note that we still have the three parser entry points for identifiers,
operator-function-ids, and conversion-function-ids, since the parser
doesn't (and shouldn't) know about DeclarationNames. This is a Good
Thing (TM), and there will be more entrypoints coming (e.g., for C++
pseudo-destructor expressions).

llvm-svn: 59527

operator+, directly, using the same mechanism as all other special
names.

Removed the "special" identifiers for the overloaded operators from
the identifier table and IdentifierInfo data structure. IdentifierInfo
is back to representing only real identifiers.

Added a new Action, ActOnOperatorFunctionIdExpr, that builds an
expression from an parsed operator-function-id (e.g., "operator
+"). ActOnIdentifierExpr used to do this job, but
operator-function-ids are no longer represented by IdentifierInfo's.

Extended Declarator to store overloaded operator names. 
Sema::GetNameForDeclarator now knows how to turn the operator
name into a DeclarationName for the overloaded operator. 

Except for (perhaps) consolidating the functionality of
ActOnIdentifier, ActOnOperatorFunctionIdExpr, and
ActOnConversionFunctionExpr into a common routine that builds an
appropriate DeclRefExpr by looking up a DeclarationName, all of the
work on normalizing declaration names should be complete with this
commit.

llvm-svn: 59526

llvm-svn: 59484

llvm-svn: 59470

destructors, and conversion functions. The placeholders were used to
work around the fact that the parser and some of Sema really wanted
declarators to have simple identifiers; now, the code that deals with
declarators will use DeclarationNames.

llvm-svn: 59469

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

llvm-svn: 59443

llvm-svn: 59442

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

llvm-svn: 59331

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: 59042

llvm-svn: 59000

llvm-svn: 58989

llvm-svn: 58988

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

llvm-svn: 58916