at which point the C++ struct/class/union is fully parsed.

llvm-svn: 54569

- Move checking from MergeVarDecl->FinializeDeclaratorGroup. Since MergeVarDecl is called before the initializer is attacted, it can't be done there (this removes a long standing FIXME).
- Add Sema::isTentativeDefinition() and Sema::CheckForFileScopedRedefinitions().
- Remove FIXME's and touch-up test case.

Still some more work to do (forthcoming)...

llvm-svn: 54533

Fixes <rdar://problem/6093889> Nested enum redefinition crashes sema.

llvm-svn: 54463

scimark2 on Darwin.

 - Added Sema support for asm-label on variables, which I forgot before.

 - Update CodeGen to use GlobalDeclMap to determine if static Decls
   require emission (instead of LLVM module name lookup). Important
   since the Decl name and the LLVM module name can differ.

 - <rdar://problem/6116729>

llvm-svn: 54388

  ActOnDeclarator.

llvm-svn: 54353

 - ActOnDeclarator now takes an additional parameter which is the
   AsmLabel if used. Its unfortunate that this bubbles up this high,
   but we cannot just lump it in as an attribute without mistakenly
   *accepting* it as an attribute.
 - The actual asm-label itself is, however, encoded as an AsmLabelAttr
   on the FunctionDecl.
 - Slightly improved parser error recovery on malformed asm-labels.
 - CodeGen support still missing...

llvm-svn: 54339

Finally fix PR2189.  This makes a fairly invasive but important change to
move getAsArrayType into ASTContext instead of being a method on type.
This is required because getAsArrayType(const AT), where AT is a typedef
for "int[10]" needs to return ArrayType(const int, 10).

Fixing this greatly simplifies getArrayDecayedType, which is a good sign.

llvm-svn: 54317

No functionality change.

llvm-svn: 54265

ASTContext::getCanonicalType instead (PR2189)

llvm-svn: 54105

even if in a system header etc.  rdar://6079937

llvm-svn: 54038

llvm-svn: 54032

When constructing an ObjCIvarDecl object in Sema, provide its visibility up front instead of setting it afterwards.
This change also fixes a subtle bug where the access control of an ivar would be initialized to garbage if we didn't have an explicit visibility specifier (e.g., @private).

llvm-svn: 53955

of a specific smallvector size.

Fix protocol lists to pass down proper location info, so we get diagnostics
like this:

t.m:3:35: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
                                  ^

instead of this:

t.m:3:44: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
                                           ^


Add a new IdentifierLocPair typedef which is just a pair<IdentifierInfo*, SourceLocation>

llvm-svn: 53883

Unify ctx_iterator/ctx_begin()/ctx_end() and iterator/begin()/end() so that a single iterator type is used for both traversing decls of the same declaration context *and* of the parent declaration contexts, depending on the value of the bool parameter 'LookInParentCtx' that is passed to IdentifierResolver::begin().

llvm-svn: 53724

When in C++, make EnumConstant names hide tag names in the same scope, instead of colliding with them.

llvm-svn: 53702

- Make sure ObjCIvarDecl propagates the bitfield width.
- RewriteObjC::SynthesizeIvarOffsetComputation(): Avoid using the __OFFSETOF__ mumbo jumbo for bitfields (since it isn't legal C). This fixes <rdar://problem/5986079> clang ObjC rewriter: bitfields and ivar access don't mix.

llvm-svn: 53694

When checking for name collision between a tag and a previously defined namespace, the collision occured even when the tag was in a different nested scope.
Fix it by taking into account the scope when checking for namespace-tag name collisions.

llvm-svn: 53667

llvm-svn: 53467

llvm-svn: 53328

also fix the correspondent test (it was expecting more errors than it should. please confirm my fix is correct (at least gcc agrees with me)

llvm-svn: 53174

llvm-svn: 53074

by filling in the body of a union with enum constants.

llvm-svn: 53069

llvm-svn: 52956

the implementation of ProcessDeclAttributes.

llvm-svn: 52875

llvm-svn: 52874

Replace CurFunctionDecl and CurMethodDecl with methods getCurFunctionDecl() and getCurMethodDecl() that return the appropriate Decl through CurContext.

llvm-svn: 52852

llvm-svn: 52792

cases where mutation can introduce bugs.  Propagate around 'const'.

llvm-svn: 52772

llvm-svn: 52771

used to mutate the attribute list for declspecs when the type was 
converted, breaking the case where one declspec was shared by multiple
declarators.

This fixes rdar://6032532.

llvm-svn: 52769

by David Chisnall. 

llvm-svn: 52597

Patch by David Chisnall!

llvm-svn: 52586

Patch by David Chisnall!

llvm-svn: 52422

isn't guaranteed to exist. This fixes a crash with conflicting typedefs
coming from stdin.

This also fixes the crash in PR2406, but doesn't completely fix the 
issue; it appears there's something strange about the physical location 
for the definition of int64_t in stdlib.h.

llvm-svn: 52209

-ScopedDecls get chained to their DeclContext.
-DeclContext's DeclChain replaces FunctionDecl's DeclChain and EnumDecl's ElementList.

llvm-svn: 52164

  Added TagKind enum.
  Added getTagKind() method.
  Added convenience methods: isEnum(), isStruct(), isUnion(), isClass().
-RecordDecl/CXXRecordDecl::Create() accept a TagKind enum instead of a DeclKind one.

llvm-svn: 52160

pointer cast hack currently in isIntegerConstantExpr 
(in lib/AST/Expr.cpp).  Also removes an odd test that even gcc doesn't accept.

The reason the pointer cast hack is relevant here is that it makes Sema 
end up misinterpreting the relevant expression as a null pointer constant.

The reason for this patch is that I plan to remove the pointer cast hack 
sometime soon because it causes strange issues, especially in its 
current form; see my recent email to cfe-dev
"[PATCH] add constant expression evaluation to the AST and fix PR2413".

llvm-svn: 52120

llvm-svn: 52092

llvm-svn: 52054

moves the check for the invalid construct to a point where it doesn't 
affect other uses of isIntegerConstantExpr, and we can warn properly 
when the extension is used.  This makes it a bit more complicated, but 
it's a lot cleaner.

Steve, please tell me if this check is sufficient to handle the 
relevant system header.  I know it's enough to handle the testcase, but 
I don't know what exactly the original looks like.

llvm-svn: 51918