varienty of cases. // rdar://9092208

llvm-svn: 127257

llvm-svn: 125752

a forward class. // rdar://8851803

llvm-svn: 125699

in liu of a class method getter. objc++ uses a different
code path and is more involved (TBD).

llvm-svn: 125061

  - BlockDeclRefExprs always store VarDecls
  - BDREs no longer store copy expressions
  - BlockDecls now store a list of captured variables, information about
    how they're captured, and a copy expression if necessary
    
With that in hand, change IR generation to use the captures data in       
blocks instead of walking the block independently.        

Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.

llvm-svn: 125005

llvm-svn: 124786

  error: no super class declared in @interface for 'XXX'

to be:

  error: 'X' cannot use 'super' because it is a root class

The latter explains what the user actually did wrong.

Fixes: <rdar://problem/8904409>
llvm-svn: 124074

llvm-svn: 123482

complete. However, if it returns a reference type, don't require the
type it refers to to be complete. Fixes <rdar://problem/8807070>.

llvm-svn: 123214

if property-dot expression is decidedly
an rvalue. // rdar://8155806.

llvm-svn: 122430

unknown type and there is a possibility that
at runtime method is resolved to a deprecated or 
unavailable method.  Addreses // rdar://8769853

llvm-svn: 122294

in a forward @class object. // rdar://8774513

llvm-svn: 121933

llvm-svn: 121516

not actually frequently used, because ImpCastExprToType only creates a node
if the types differ.  So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.

In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.

This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.

Ted Kremenek kindly contributed the analyzer workarounds in this patch.

llvm-svn: 120890

no property accessor class method to be found, instead of
crashing in IRGen. // rdar://8703553

llvm-svn: 120855

into the latter.

llvm-svn: 120643

'Class' type, disgnostic should refere to a
class method. Fixes // rdar://8592156

llvm-svn: 120517

out because there are still bugs left.

llvm-svn: 119722

store it on the expression node.  Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.

Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.

llvm-svn: 119685

llvm-svn: 118966

anymore.

llvm-svn: 117357

PR6056, //rdar: //8564463

llvm-svn: 116819

identifiers to determine good typo-correction candidates. Once we've
identified those candidates, we perform name lookup on each of them
and the consider the results. 

This optimization makes typo correction > 2x faster on a benchmark
example using a single typo (NSstring) in a tiny file that includes
Cocoa.h from a precompiled header, since we are deserializing far less
information now during typo correction.

There is a semantic change here, which is interesting. The presence of
a similarly-named entity that is not visible can now affect typo
correction. This is both good (you won't get weird corrections if the
thing you wanted isn't in scope) and bad (you won't get good
corrections if there is a similarly-named-but-completely-unrelated
thing). Time will tell whether it was a good choice or not.

llvm-svn: 116528

'super' as receiver of property or a setter/getter
methods. //rdar: //8525788

llvm-svn: 116483

vla. Implements pr7827.

llvm-svn: 114737

sends. These are far trickier than instance messages, because we
typically have something like

  NSArray alloc]

where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).

llvm-svn: 114057

narrow, almost useless case where we're inside a parenthesized
expression, e.g.,

  (NSArray alloc])

The solution to the general case still eludes me.

llvm-svn: 114039

part of parser recovery. For example, given:

  a method1:arg];

we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:

fixit-objc-message.m:17:3: error: missing '[' at start of message
      send expression
  a method1:arg];
  ^
  [

The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.

llvm-svn: 113968

One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.

llvm-svn: 112244

Clients of Sema don't need to know (for example) the list of diagnostics we
support.

llvm-svn: 112093

to the new constants.

llvm-svn: 112047

#include Sema.h while keeping all the AST declarations opaque.  That may
not be reasonably attainable, though.

llvm-svn: 111907

M-x query-replace-regexp
\(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result

llvm-svn: 111903

llvm-svn: 111901

llvm-svn: 111863

and remove getStrData().  Patch by Peter Davies (with some tweaks).

llvm-svn: 111229

llvm-svn: 110945

type receiver (pr7861).

llvm-svn: 110696

(radar 8127244).

llvm-svn: 110622

llvm-svn: 110078