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

object to a __weak object type. // rdar://9732636

llvm-svn: 134706

- fix a comment.
- Remove an unnecessary { } block.

llvm-svn: 134690

object to a __weak object/type. // rdar://9732636.
One item is yet todo.

llvm-svn: 134655

object to a __weak object/type. // rdar://9732636.
This is objc side of things. objc++ side tbd.

llvm-svn: 134624

clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!

llvm-svn: 134615

where we have an immediate need of a retained value.

As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain.  This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.

rdar://problem/9504800

llvm-svn: 134605

expressions.

llvm-svn: 134583

rather than a computed std::distance(). At some point I had convinced
myself that these two were different; but as far as I can tell on
re-exampination they aren't, and the number of block IDs is actually
just a count of the blocks in the CFG.

While this removes the primary motivation for guarding all of this with
CollectStats, I have a patch coming up that will almost certainly make
it important again.

llvm-svn: 134552

throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.

llvm-svn: 134548

llvm-svn: 134529

classes which are incompatible with weak references.
// rdar://9693477

llvm-svn: 134522

declaration with dependent type. Fixes PR10232 /
<rdar://problem/9700653>.

llvm-svn: 134515

Special detail is added for uninitialized variable analysis as this has
serious performance problems than need to be tracked.

Computing some of this data is expensive, for example walking the CFG to
determine its size. To avoid doing that unless the stats data is going
to be used, we thread a bit into the Sema object to track whether
detailed stats should be collected or not. This bit is used to avoid
computations whereever the computations are likely to be more expensive
than checking the state of the flag. Thus, counters are in some cases
unconditionally updated, but the more expensive (and less frequent)
aggregation steps are skipped.

With this patch, we're able to see that for 'gcc.c':
*** Analysis Based Warnings Stats:
232 functions analyzed (0 w/o CFGs).
  7151 CFG blocks built.
  30 average CFG blocks per function.
  1167 max CFG blocks per function.
163 functions analyzed for uninitialiazed variables
  640 variables analyzed.
  3 average variables per function.
  94 max variables per function.
  96409 block visits.
  591 average block visits per function.
  61546 max block visits per function.

And for the reduced testcase in PR10183:
*** Analysis Based Warnings Stats:
98 functions analyzed (0 w/o CFGs).
  8526 CFG blocks built.
  87 average CFG blocks per function.
  7277 max CFG blocks per function.
68 functions analyzed for uninitialiazed variables
  1359 variables analyzed.
  19 average variables per function.
  1196 max variables per function.
  2540494 block visits.
  37360 average block visits per function.
  2536495 max block visits per function.

That last number is the somewhat scary one that indicates the problem in
PR10183.

llvm-svn: 134494

instantiating functions.

Fixes PR10272.

llvm-svn: 134491

variadic argument pack expansions as having changed, rather than doing
it for each changed expansion, which leaves out zero-argument packs
with catastrophic consequences.

Fixes PR10260.

llvm-svn: 134483

as scope specifiers;  diagnose the attempt, rather than letting it go
to an assert.  The rest of PR10264.

llvm-svn: 134479

structure to hold inferred information, then propagate each invididual
bit down to -cc1.  Separate the bits of "supports weak" and "has a native
ARC runtime";  make the latter a CodeGenOption.

The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.

llvm-svn: 134453

passed to it, and unknown selectors causing potential leak.
// rdar://9659270

llvm-svn: 134449

instantiated function template was written with a prototype or via
some kind of typedef. Fixes PR10273 / <rdar://problem/9723679>. 

llvm-svn: 134426

ActOnDeclarator can return NULL. Fixes PR10270, from Hans Wennborg!

llvm-svn: 134416

llvm-svn: 134403