in ctor-initializer list.

llvm-svn: 74541

llvm-svn: 74481

list.

llvm-svn: 74480

llvm-svn: 74472

in the ctor-initializer list. More to come.

llvm-svn: 74465

llvm-svn: 74362

llvm-svn: 74307

these are usually because the parser was thoroughly confused.  In addition
to typing the value being declared as an int and hoping for the best, we
mark the value as invalid so we don't get chains of errors when it is
used downstream.  In C, implicit int actually is valid, so typing the thing
as int is good and marking it invalid is bad. :)

llvm-svn: 74266

but at least we don't crash :)

llvm-svn: 74264

llvm-svn: 74262

llvm-svn: 74258

llvm-svn: 74257

llvm-svn: 74216

templates.

For example, this now type-checks (but does not instantiate the body
of deref<int>):

  template<typename T> T& deref(T* t) { return *t; }

  void test(int *ip) {
    int &ir = deref(ip);
  }

Specific changes/additions:
  * Template argument deduction from a call to a function template.
  * Instantiation of a function template specializations (just the
  declarations) from the template arguments deduced from a call.
  * FunctionTemplateDecls are stored directly in declaration contexts
  and found via name lookup (all forms), rather than finding the
  FunctionDecl and then realizing it is a template. This is
  responsible for most of the churn, since some of the core
  declaration matching and lookup code assumes that all functions are
  FunctionDecls.

llvm-svn: 74213

llvm-svn: 74175

when it should.

llvm-svn: 73992

llvm-svn: 73885

llvm-svn: 73833

llvm-svn: 73812

work in progress.

llvm-svn: 73782

It's an error to use a function declared in a class definition as a default argument before the function has been declared.

llvm-svn: 73234

llvm-svn: 73178

llvm-svn: 73177

T::*) and implement template instantiation for member pointer types.

llvm-svn: 73151

llvm-svn: 72747

Fix an off by one error when trying to perform copy initialization of operator new and operator delete arguments. Sebastian, please review.

llvm-svn: 72670

llvm-svn: 72664

llvm-svn: 72624

Add a member lookup criteria constructor for searching for overridden virtual member functions. Use this instead of regular name lookup when checking for overriding functions so we will see declarations that would otherwise be hidden. Fixes 6902298.

llvm-svn: 72601

printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.

llvm-svn: 72590

llvm-svn: 72580

llvm-svn: 72571

specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:

  1) In C++, one is not allowed to define tag types within a type
  specifier (e.g., static_cast<struct S { int x; } *>(0) is
  ill-formed) or within the result or parameter types of a
  function. We now diagnose this.

  2) We can extend DeclGroups to contain information about any tags
  that are declared/defined within the declaration specifiers of a
  variable, e.g.,

    struct Point { int x, y, z; } p;

  This will help improve AST printing and template instantiation,
  among other things.

  3) For C99, we can keep track of whether a tag type is defined
  within the type of a parameter, to properly cope with cases like,
  e.g.,

    int bar(struct T2 { int x; } y) {
      struct T2 z;
    }

  We can also do similar things wherever there is a type specifier,
  e.g., to keep track of where the definition of S occurs in this
  legal C99 code:

    (struct S { int x, y; } *)0

  

llvm-svn: 72555

Add a big test case for I-C-Es in C++, and a fix to make it work. The fix might not be the right way to do it.

llvm-svn: 72490

llvm-svn: 72409

Avoid using the built-in type checker for assignment in C++ when classes are involved. Patch by Vyacheslav Kononenko.

llvm-svn: 72212

and it isn't clear exactly what it's supposed to mean. Thanks Eli!

llvm-svn: 72142

llvm-svn: 71972

llvm-svn: 71970

narrower, so it doesn't catch expresions that aren't sub-expressions of
__extension__ operator.

llvm-svn: 71967