This is accomplished by forcing the needed expressions for -Wuninitialized to always be CFGElements in the CFG.
This allows us to remove a fair amount of the code for -Wuninitialized.

Some fallout:
- AnalysisBasedWarnings.cpp now specifically toggles the CFGBuilder to create a CFG that is suitable for -Wuninitialized.  This
is a layering violation, since the logic for -Wuninitialized is in libAnalysis.  This can be fixed with the proper refactoring.
- Some of the source locations for -Wunreachable-code warnings have shifted.  While not ideal, this is okay because that analysis
already needs some serious reworking.

llvm-svn: 135480

ShadowMapEntry was.

llvm-svn: 135368

Zero this struct in a way that neither depends on the size of the struct nor triggers warnings from GCC.

llvm-svn: 135351

llvm-svn: 135348

llvm-svn: 135328

Test cases provided by Anton Lokhmot.

llvm-svn: 135322

convertToInt(integerParts*) and make them more reliable.

llvm-svn: 135279

llvm-svn: 135275

attributes. Fixes <rdar://problem/9561076>.

llvm-svn: 135273

which is required given the current setup for template
argument deduction substitution validation, and add a test
case to make sure we don't break it in the future.

llvm-svn: 135262

to represent a fully-substituted non-type template parameter.
This should improve source fidelity, as well as being generically
useful for diagnostics and such.

llvm-svn: 135243

Remove warnings of constant operands of logical operators from template instantiations.  Upon instantiation of template, value-dependent parameters are replaced by equivalent literals, so code like:

template<unsigned int A, unsigned int B> struct S {
  int foo() {
    int x = A && B;
  }
}

will not warn on A && B on every instantiation.  This will still warn on other cases inside templates, which will be caught on checking the template definition.

llvm-svn: 135222

Revert "For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either."

This reverts commit ac420c5053d6aa41d59f782caad9e46e5baaf2c2.

llvm-svn: 135210

llvm-svn: 135208

For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either.
This is a first baby step towards supporting generalized initializer lists. This also removes an aggregate
test case that was just plain wrong, assuming that non-aggregates couldn't be initialized with initializer lists
in C++11 mode.

llvm-svn: 135177

llvm-svn: 135175

is still terrible here because typo correction is not behaving well in
the presence of overloaded functions.

llvm-svn: 135128

PR8800: When building a conversion to A& using a member operatorA&(), do not require A to be a complete type.

llvm-svn: 135101

parsing lambda expressions, from John Freeman!

llvm-svn: 135090

Uhrain! Fixes PR10318.

llvm-svn: 135086

it as used.  Otherwise, we can fail to instantiate or validate the destructor,
which can lead to crashes in IR gen like PR10351.

llvm-svn: 135073

used in @selector expression because, well, their implementation 
is optional. // rdar://9545564

llvm-svn: 135057

__unknown_anytype, and rewrite such message sends correctly.

I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing;  this is clearly just debugger-specific behavior.

llvm-svn: 135051

Make it also available in ObjC++ propeties. Use common code for
objc and objc++ so they don't diverge. // rdar://9740328

llvm-svn: 135050

and (while I'm at it) teach it to grok the results of simple
assignments.

The first is PR10336.

llvm-svn: 135034

unrestricted unions, which ended up attempting to initialize objects
in a union (which CodeGen isn't prepared for). Fixes PR9683.

llvm-svn: 135027

Make it also available in ObjC++ propeties. // rdar://9740328

llvm-svn: 135001

implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771

llvm-svn: 134992

Found by valgrind.

llvm-svn: 134983

It would be cool if we could do overload resolution to suggest
the right function, but at least this fixes the crashing.

llvm-svn: 134976

code so that they only occur in a single place. No functionality change.

llvm-svn: 134961

[ARC] Complain about property without storage attribute when @synthesizing it, not at its declaration.

For this sample:

@interface Foo
@property id x;
@end

we get:

t.m:2:1: error: ARC forbids properties of Objective-C objects with unspecified storage attribute
@property  id x;
^
1 error generated.

The error should be imposed on the implementor of the interface, not the user. If the user uses
a header of a non-ARC library whose source code he does not have, we are basically asking him to
go change the header of the library (bad in general), possible overriding how the property is
implemented if he gets confused and says "Oh I'll just add 'copy' then" (even worse).

Second issue is that we don't emit any error for 'readonly' properties, e.g:

@interface Foo
@property (readonly) id x; // no error  here
@end

@implementation Foo
@synthesize x; // no error here too
@end

We should give an error when the implementor is @synthesizing a property which doesn't have
any storage specifier; this is when the explicit specifier is important, because we are
going to create an ivar and we want its ownership to be explicit.

Related improvements:
-OBJC_PR_unsafe_unretained turned out to not fit in ObjCPropertyDecl's bitfields, fix it.
-For properties of extension classes don't drop PropertyAttributesAsWritten values.
-Have PropertyAttributesAsWritten actually only reflect what the user wrote

rdar://9756610.

llvm-svn: 134960

Patch by Caitlin Sadowski.

llvm-svn: 134938

into a static helper.

Original patch by Caitlin Sadowski, style tweaks by me.

llvm-svn: 134937

llvm-svn: 134926

require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.

llvm-svn: 134906

functions. Fixes <rdar://problem/9731999>.

llvm-svn: 134897

llvm-svn: 134892

Found by valgrind.

llvm-svn: 134733

llvm-svn: 134731