really horrible extensions that are disabled by default but that can
be accepted by -fheinous-gnu-extensions (but which always emit a 
warning when enabled).

As our first instance of this, implement PR3788/PR3794, which allows
non-lvalues in inline asms in contexts where lvalues are required. bleh.

llvm-svn: 66910

Also changed BlockDecl API to be more consistent (wrt FunctionDecl).

llvm-svn: 66904

This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris). 

The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.

llvm-svn: 66896

Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).

Will replace with something better today...

llvm-svn: 66893

C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time. 

Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.

Instantiation of these expressions is completely wrong. I'll work on
that next.

llvm-svn: 66851

llvm-svn: 66837

llvm-svn: 66835

Store the type of the integral value within a TemplateArgument, so that we can more efficiently reconstruct an IntegerLiteral from it during template instantiation

llvm-svn: 66833

instantiation. This is roughly the structure we want to expression
instantiation.

llvm-svn: 66816

be CompoundStmts. I think this is a valid assumption, and felt that the API
should reflect it. Others please validate this assumption to make sure I didn't
break anything.

llvm-svn: 66814

width of bitfields. 

I'll be burning this down and replacing it with a properly-dispatched
implementation like the one used for types.

llvm-svn: 66796

should fix the largest problem in <rdar://problem/6669847>.

llvm-svn: 66741

class members to the corresponding in-class declaration.

Diagnose the erroneous use of 'static' on out-of-line definitions of
class members. 

llvm-svn: 66740

Move most of the checking from ActOnCXXMemberDeclarator to other, more general routines. This is a step toward separating the checking logic from Declarators, which in turn is required for template instantiation.

llvm-svn: 66734

Make sure that we set the access specifier for an instantiated FieldDecl, and that the aggregate and POD flags for an instantiated class template are updated based on instantiation of a FieldDecl

llvm-svn: 66701

llvm-svn: 66698

llvm-svn: 66696

llvm-svn: 66689

for FieldDecls so that the parser and the template instantiation make
use of the same semantic checking module.

llvm-svn: 66685

template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?

llvm-svn: 66662

llvm-svn: 66659

llvm-svn: 66658

Sema/asm.c:64:9: error: invalid % escape in inline assembly string
  asm("%!" : );   // expected-error {{invalid % escape in inline assembly string}}
      ~~^~

llvm-svn: 66606

translation unit.

Thread the various declarations of variables via
VarDecl::getPreviousDeclaration.

llvm-svn: 66601

llvm-svn: 66598

definitions. We were rejecting tentative definitions of incomplete
(which is bad), and now we don't.

This fix is partial because we don't do the end-of-translation-unit
initialization for tentative definitions that don't ever have any
initializers specified.

llvm-svn: 66584

context of a template-id for which we need to instantiate default
template arguments.

In the TextDiagnosticPrinter, don't suppress the caret diagnostic if
we are producing a non-note diagnostic that follows a note diagnostic
with the same location, because notes are (conceptually) a part of the
warning or error that comes before them.

llvm-svn: 66572

only print the template instantiation backtrace for the first error.

Also, if a base class has failed to type-check during instantiation,
just drop that base class and continue on to check other base classes.

llvm-svn: 66563

  'struct A<double, int>'

In the "template instantiation depth exceeded" message, print
"-ftemplate-depth-N" rather than "-ftemplate-depth=N".

An unnamed tag type that is declared with a typedef, e.g., 

  typedef struct { int x, y; } Point;

can be used as a template argument. Allow this, and check that we get
sensible pretty-printing for such things.

llvm-svn: 66560

to a diagnostic that will be invoked after the diagnostic (if it is
not suppressed). The hooks are allowed to produce additional
diagnostics (typically notes) that provide more information. We should
be able to use this to help diagnostic clients link notes back to the
diagnostic they clarify. Comments welcome; I'll write up documentation
and convert other clients (e.g., overload resolution failures) if
there are no screams of protest.

As the first client of post-diagnostic hooks, we now produce a
template instantiation backtrace when a failure occurs during template
instantiation. There's still more work to do to make this output
pretty, if that's even possible.

llvm-svn: 66557

llvm-svn: 66551

llvm-svn: 66549

(default: 99). Beyond this limit, produce an error and consider the
current template instantiation a failure.

The stack we're building to track the instantiations will, eventually,
be used to produce instantiation backtraces from diagnostics within
template instantiation. However, we're not quite there yet.

This adds a new Clang driver option -ftemplate-depth=NNN, which should
eventually be generated from the GCC command-line operation
-ftemplate-depth-NNN (note the '-' rather than the '='!). I did not
make the driver changes to do this mapping.

llvm-svn: 66513

such as replacing 'T' in vector<T>. There are a few aspects to this:

  - Extend TemplateArgument to allow arbitrary expressions (an
    Expr*), and switch ClassTemplateSpecializationType to store
    TemplateArguments rather than it's own type-or-expression
    representation.

  - ClassTemplateSpecializationType can now store dependent types. In
    that case, the canonical type is another
    ClassTemplateSpecializationType (with default template arguments
    expanded) rather than a declaration (we don't build Decls for
    dependent types).

  - Split ActOnClassTemplateId into ActOnClassTemplateId (called from
    the parser) and CheckClassTemplateId (called from
    ActOnClassTemplateId and InstantiateType). They're smart enough to
    handle dependent types, now.

llvm-svn: 66509

a warning and then threw away the AST.  While I'm in there, tighten up the
code to actually reject completely bogus cases (sending a message to a 
struct).  We still allow sending a message to an int, which doesn't make
sense but GCC allows it and is easy to support.

llvm-svn: 66468

This fixes <rdar://problem/6496506> Implement class setter/getter for properties.

llvm-svn: 66465

llvm-svn: 66431

llvm-svn: 66423

llvm-svn: 66422

Rename DiagnoseIncompleteType to RequireCompleteType, and update the documentation to reflect the fact that we can instantiate templates here

llvm-svn: 66421