DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.

Only enumerations and linkage specifications currently use transparent
DeclContexts.

Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.

llvm-svn: 61735

Perform default function/array conversion for input arguments to inline asm statements if the input expr can be a memory operand

llvm-svn: 61515

llvm-svn: 61486

llvm-svn: 61476

llvm-svn: 61456

Examples:
int;
typedef int;

llvm-svn: 61454

llvm-svn: 61442

Patch by Ilya Okonsky

llvm-svn: 61437

Keep track of template arguments when we parse them. Right now, we don't actually do anything with the template arguments, but they'll be used to create template declarations

llvm-svn: 61413

semantics and improve our handling of default arguments. Specifically,
we follow this order:

  - As soon as the see the '}' in the class definition, the class is
  complete and we add any implicit declarations (default constructor,
  copy constructor, etc.) to the class.
  - If there are any default function arguments, parse them
  - If there were any inline member function definitions, parse them

As part of this change, we now keep track of the the fact that we've
seen unparsed default function arguments within the AST. See the new
ParmVarDecl::hasUnparsedDefaultArg member. This allows us to properly
cope with calls inside default function arguments to other functions
where we're making use of the default arguments.

Made some C++ error messages regarding failed initializations more
specific. 

llvm-svn: 61406

Patch by Ilya Okonsky!

llvm-svn: 61394

llvm-svn: 61393

attached to an identifier. Instead, all overloaded functions will be
pushed into scope, and we'll synthesize an OverloadedFunctionDecl on
the fly when we need it. 

llvm-svn: 61386

llvm-svn: 61359

DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.

This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the 
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.

Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.

llvm-svn: 61357

llvm-svn: 61346

Support conversion from a null pointer constant o any Objective-C object pointer type. Fixes rdar://problem/6463298

llvm-svn: 61340

llvm-svn: 61337

property in a category and to issue diagnostics
for mismatch method in some other cases.

llvm-svn: 61336

llvm-svn: 61335

  - Overloading has to cope with having both static and non-static
    member functions in the overload set.
  - The call may or may not have an implicit object argument,
    depending on the syntax (x.f() vs. f()) and the context (static
    vs. non-static member function).
  - We now generate MemberExprs for implicit member access expression.
  - We now cope with mutable whenever we're building MemberExprs.

llvm-svn: 61329

llvm-svn: 61313

llvm-svn: 61312

llvm-svn: 61309

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

using it in ObjC's method parameter encoding.

llvm-svn: 61293

llvm-svn: 61290

llvm-svn: 61275

llvm-svn: 61260

llvm-svn: 61255

warning. This matches GCC's behavior and addresses
<rdar://problem/6458293>.

llvm-svn: 61246

llvm-svn: 61245

llvm-svn: 61229

llvm-svn: 61212

become useful or correct until we (1) parse template arguments
correctly, (2) have some way to turn template-ids into types,
declarators, etc., and (3) have a real representation of templates.

llvm-svn: 61208

code gen which did not belong there.

llvm-svn: 61203

emit duplicate diags (some in parser and some in sema) and to
warn about use of typequals in array sizes.  This implements 
PR2759.

llvm-svn: 61197

void foo() { return foo(); }

llvm-svn: 61188

Fix PR2790 by making a warning an EXTWARN instead of EXTENSION.
Add a new EXTENSION warning for "return (some void expression);"

llvm-svn: 61187

Delay semantic analysis of the C++ names casts when the subexpression is type-dependent or the destination type is dependent.

llvm-svn: 61165