one for building up the diagnostic that is in flight (DiagnosticBuilder)
and one for pulling structured information out of the diagnostic when
formatting and presenting it.

There is no functionality change with this patch.

llvm-svn: 59849

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

llvm-svn: 59829

llvm-svn: 59822

llvm-svn: 59819

llvm-svn: 59805

strings.  This allows us to have considerable flexibility in how
these things are displayed and provides extra information that
allows us to merge away diagnostics that are very similar.

Diagnostic modifiers are a string of characters with the regex
[-a-z]+ that occur between the % and digit.  They may 
optionally have an argument that can parameterize them.

For now, I've added two example modifiers.  One is a very useful
tool that allows you to factor commonality across diagnostics
that need single words or phrases combined.  Basically you can
use %select{a|b|c}4 with with an integer argument that selects
either a/b/c based on an integer value in the range [0..3).

The second modifier is also an integer modifier, aimed to help
English diagnostics handle plurality.  "%s3" prints to 's' if 
integer argument #3 is not 1, otherwise it prints to nothing.
I'm fully aware that 's' is an English concept and doesn't
apply to all situations (mouse vs mice).  However, this is very
useful and we can add other crazy modifiers once we add support
for polish! ;-)

I converted a couple C++ diagnostics over to use this as an
example, I'd appreciate it if others could merge the other
likely candiates.  If you have other modifiers that you want,
lets talk on cfe-dev.

llvm-svn: 59803

and fall through better.

llvm-svn: 59799

llvm-svn: 59791

llvm-svn: 59789

llvm-svn: 59743

expression (smart_ptr->mem).

llvm-svn: 59732

llvm-svn: 59729

llvm-svn: 59716

llvm-svn: 59714

llvm-svn: 59713

llvm-svn: 59712

of doing the lookup_decl, the hash lookup is cheap.  Also,
typeid doesn't happen enough in real world code to worry about
it.

I'd like to eventually get rid of KnownFunctionIDs from Sema
also, but today is not that day.

llvm-svn: 59711

looking up the "std" identifier is trivial.  Just do it, particularly
since this is only done if the namespace hasn't already been looked up.

llvm-svn: 59710

used in one cold place.

llvm-svn: 59709

just check for it when needed.  It doesn't incur real cost
in any hot paths.

llvm-svn: 59708

from Sebastian to enforce that a literal string is passed in,
and use this to avoid having to call strlen on it.

llvm-svn: 59706

diagnostics on use of __weak attribute on fields,
Early support for read/write barriers for objc fields.

llvm-svn: 59682

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

llvm-svn: 59661

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

The core fix in Sema::ActOnClassMessage(). All the other changes have to do with passing down the SourceLocation for the receiver (to properly position the cursor when producing an error diagnostic).

llvm-svn: 59639

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

PragmaPackStack. Thanks Chris!

llvm-svn: 59616

llvm-svn: 59609

first.  This should allow removal of a bunch of II->getName() calls.

llvm-svn: 59601

llvm-svn: 59600

llvm-svn: 59598

llvm-svn: 59589

__builtin_prefetch code to only emit one diagnostic per builtin_prefetch.
While this has nothing to do with the rest of the patch, the code seemed
like overkill when I was updating it.

llvm-svn: 59588

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