llvm-svn: 64387

llvm-svn: 64306

constants.

llvm-svn: 63491

llvm-svn: 63379

represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.

The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.

llvm-svn: 63317

have to try to guess which member is being initialized.

llvm-svn: 63315

initializers.

  - We now initialize unions properly when a member other than the
    first is named by a designated initializer.
  - We now provide proper semantic analysis and code generation for
    GNU array-range designators *except* that side effects will occur
    more than once. We warn about this.

llvm-svn: 63253

 - Merged into single ComplexEvaluator, these share too much logic to
   be worth splitting for float/int (IMHO). Will split on request.

llvm-svn: 63248

The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.

Known limitations:
  - Designating a member of a union that isn't the first member may
    result in bogus initialization (we warn about this)
  - GNU array-range designators are not supported (we warn about this)

llvm-svn: 63242

llvm-svn: 62950

__builtin___CFStringMakeConstantString.  (We get into trouble in 
GenerateStaticBlockVarDecl if the constant folder isn't accurate.)

llvm-svn: 62949

constant.

llvm-svn: 62948

llvm-svn: 62930

llvm-svn: 62438

llvm-svn: 62387

llvm-svn: 62101

information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
  1) The use of a qualified-id instead of an unqualified-id suppresses
     argument-dependent lookup
  2) If the name refers to a virtual function, the qualified-id
  version will call the function determined statically while the
  unqualified-id version will call the function determined dynamically
  (by looking up the appropriate function in the vtable).

Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.

llvm-svn: 61789

which can refer to static data members, enumerators, and member
functions as well as to non-static data members.

Implement correct lvalue computation for member references in C++. 
Compute the result type of non-static data members of reference type properly.

llvm-svn: 61294

output that GCC does.  rdar://6440297

llvm-svn: 60922

and separates lexical name lookup from qualified name lookup. In
particular:
  * Make DeclContext the central data structure for storing and
    looking up declarations within existing declarations, e.g., members
    of structs/unions/classes, enumerators in C++0x enums, members of
    C++ namespaces, and (later) members of Objective-C
    interfaces/implementations. DeclContext uses a lazily-constructed
    data structure optimized for fast lookup (array for small contexts,
    hash table for larger contexts). 

  * Implement C++ qualified name lookup in terms of lookup into
    DeclContext.

  * Implement C++ unqualified name lookup in terms of
    qualified+unqualified name lookup (since unqualified lookup is not
    purely lexical in C++!)

  * Limit the use of the chains of declarations stored in
    IdentifierInfo to those names declared lexically.

  * Eliminate CXXFieldDecl, collapsing its behavior into
    FieldDecl. (FieldDecl is now a ScopedDecl).

  * Make RecordDecl into a DeclContext and eliminates its
    Members/NumMembers fields (since one can just iterate through the
    DeclContext to get the fields).

llvm-svn: 60878

llvm-svn: 60323

llvm-svn: 60032

llvm-svn: 59857

moment.

llvm-svn: 59435

llvm-svn: 59433

llvm-svn: 59426

llvm-svn: 59405

llvm-svn: 59375

llvm-svn: 59371

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

llvm-svn: 59057

t.c:1:13: error: cannot codegen this designators yet
int a[10] = {2, 4, [8]=9, 10};
            ^~~~~~~~~~~~~~~~~

llvm-svn: 58220

llvm-svn: 57909

llvm-svn: 57392

constant lvalue.  Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.

llvm-svn: 57163

constants for them, just use the constant evaluator to do the job.  This
also fixes crashes on 'unknown constant builtins'.

llvm-svn: 57155

llvm-svn: 55299

llvm-svn: 55249

Add ExplicitCastExpr to replace the current CastExpr, and have ImplicitCastExpr and ExplicitCastExpr derive from a common base class (CastExpr):

Expr
  -> CastExpr
     -> ExplicitCastExpr
     -> ImplicitCastExpr 

llvm-svn: 54955

llvm-svn: 54837

 - We are beyond the point where this shows up often and when it does
   generating miscompiled files is bad.

llvm-svn: 54836