This eliminates a bogus warning identified in the test below.

This fixes <rdar://problem/5968256> clang on xcode: error: incompatible type initializing 'NSObject<XCSelectionSource> *', expected 'id<NSObject,XCSelectionSource>'

llvm-svn: 51832

Add some more test cases that demonstrate clang is a bit stricter than GCC. These can be fixed lazily if they become a problem.

llvm-svn: 51830

Teach Sema::CheckConditionalOperands() to check for ObjCQualifiedIdType's. This fixes a bogus error.

<rdar://problem/5967036> clang on xcode: error: incompatible operand types ('id<DTOutputStreams>' and 'DTFilterOutputStream *')

llvm-svn: 51828

llvm-svn: 51827

llvm-svn: 51826

TranslationUnit object instead of an ASTContext. By default it calls
Initialize(ASTConstext& Context) (to match with the current interface used by
most ASTConsumers).

Modified the ObjC-Rewriter to use InitializeTU, and to tell the TranslationUnit
to not free its Decls.  This is a workaround for: <rdar://problem/5966749>

llvm-svn: 51825

Some fancy footwork to accommodate embedded preprocessor directives within an interface.

llvm-svn: 51815

This fix involved tightening up needToScanForQualifiers(), which predated ObjCQualifiedIdType.
It also includes a minor tweak to the code that searches for the beginning of the qualified type. If the AST contained the correct beginning of the declaration (i.e. the beginning of the declaration specifiers), this code would be more robust. Since it doesn't, we apply an adhoc heuristic. Note that DeclSpec contains this info...we just don't propagate it to the AST (at present).

llvm-svn: 51812

Hack RewriteObjC::RewriteObjCStringLiteral() to include the filename in the generated code (replacing any non-alphanumeric characters with "_"). This allows header files to contain ObjCStringLiterals.

llvm-svn: 51811

llvm-svn: 51809

llvm-svn: 51803

Teach Expr::isLvalue() about ObjC properties. For now, all properties are writable. Added a FIXME for another day.

llvm-svn: 51800

types so that they end up the correct size.

llvm-svn: 51787

this does is reconstruct the type for structs and arrays if the type 
wouldn't be compatible otherwise.

The assertion about packing in the struct type reconstruction code 
sucks, but I don't see any obvious way to fix it.  Maybe we need a general
utility method to take a list of types and alignments and try to construct an
unpacked type if possible?

llvm-svn: 51785

associated declaration. This is a prerequisite to handling
general union initializations; for example, an array of unions involving 
pointers has to be turned into a struct because the elements can have 
incompatible types.

I refactored the code a bit to make it more readable; now, the logic for 
definitions is all in EmitGlobalVarInit.

The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it 
separately.

By itself, this patch should not cause any visible changes.

llvm-svn: 51783

required by the standard (the standard doesn't know anything about 
implicit casts).

Disallow pointers cast to non-integral arithmetic types as constant 
expressions.  This was previously allowed by accident. 

llvm-svn: 51779

llvm-svn: 51778

Patch by Holger Schurig!

llvm-svn: 51774

Fix some strict-aliasing warnings by using Stmt* instead of Expr* in VariableArrayType, EnumConstantDecl, and VarDecl.

llvm-svn: 51772

of elements.

llvm-svn: 51769

essentially that we were destroying the declarations twice.

(Note that we don't use -serialize directly in the testsuite, only 
SerializeTest.)

llvm-svn: 51768

This fixes a crash on the included testcase (found in NetHack).

llvm-svn: 51767

llvm-svn: 51765

llvm-svn: 51764

bit-field initialization; ugly code, X86-only, but it works, at least 
for basic stuff.  Separates/adds union initialization; currently disabled,
though, because the struct/array code needs modifications to support 
elements of the wrong type.

Fixes PR2381 and PR2309 with the bit-field initialization.  And NetHack 
compiles and appears to work with a few tweaks (to work around the lack 
of transparent_union support, and clang being a bit strict about
conflicting declarations).

llvm-svn: 51763

and union codepaths and fixes some minor bugs.

I'm reasonably confident this is accurate, at least for X86.  I'll 
correct any bugs as I find them; I haven't found any for a while, 
though.

llvm-svn: 51762

While it is far from complete, it does fix the following <rdar://problem/5967199> clang on xcode: error: member reference is not to a structure or union

llvm-svn: 51719

llvm-svn: 51707

- #include ExprObjC.h in many places

llvm-svn: 51703

llvm-svn: 51689

llvm-svn: 51683

constant expressions.

llvm-svn: 51682

unsigned because it's possible (at least in theory) to have
have both positive and negative pointers pointing to the same object.

llvm-svn: 51681

in unions (we don't want to do the union-specific bitcast for 
bit-fields).

llvm-svn: 51678

expressions.

llvm-svn: 51677

alignment and alignment attributes.

llvm-svn: 51676

emit incomplete types, because they crash llc, and always use the 
logical location as the current location so we don't crash doing invalid 
queries on CurLoc.

llvm-svn: 51675

This change makes clang generate the same thing as llvm-gcc.

llvm-svn: 51674

nothing fundamentally wrong with it. Emitting unpacked structs where 
possible is more work for almost no practical benefit.  We'll probably 
want to fix it at some point anyway, but it's low priority.

The issue with long double in particular is that LLVM thinks an X86 long
double is 10 bytes, while clang considers it for all purposes to be
either 12 or 16 bytes, depending on the platform, even in a packed
struct.

llvm-svn: 51673

llvm-svn: 51672