The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug.
Created a helper with the correct logic and changed both methods to use it.

llvm-svn: 65532

llvm-svn: 65529

Also changed ObjCInterfaceDecl::lookupClassMethod() to look through a categories protocols.

Test/patch submitted by Jean-Daniel Dupas (thanks!).

llvm-svn: 65526

pretty sure we want to keep constant expression verification outside of 
Evaluate. Because of that, the short-circuit evaluation doesn't 
generally make sense, and the comma warning doesn't make sense in its 
current form.

llvm-svn: 65525

is a rather big change, but I think this is the direction we want to go; 
the code is significantly shorter now, and it doesn't duplicate Evaluate 
code.  There shouldn't be any visible changes as far as I know.

There has been some movement towards putting ICE handling into 
Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate 
instead of isICE).  This patch is sort of the opposite of the approach, 
making ICE handling work without Evaluate being aware of it. I think 
this approach is better because it separates the code that does the 
constant evaluation from code that's calculating a rather 
arbitrary predicate.

The one thing I don't really like about this patch is that 
the handling of commas in C99 complicates it signficantly. (Seriously, 
what was the standards committee thinking when they wrote that 
part?) I think I've come up with a decent approach, but it doesn't feel
ideal.  I might add some way to check for evaluated commas from Evaluate 
in a subsequent patch; that said, it might not be worth bothering.

llvm-svn: 65524

llvm-svn: 65519

 - <rdar://problem/6622451> Bad x86_64 code gen for message call taking one argument.

llvm-svn: 65510

anymore.  If we want to reuse bits and pieces to add strict checking for 
constant initializers, we can dig them out of SVN history; the existing 
code won't be useful as-is.

llvm-svn: 65502

variable declarations where applicable.  Also, a few fixes to 
TryToFixInvalidVariablyModifiedType for issues that this exposed.

llvm-svn: 65500

llvm-svn: 65489

derive from a class template specialization, e.g.,

  class B : public A<int> { };

llvm-svn: 65488

llvm-svn: 65487

llvm-svn: 65486

llvm-svn: 65485

  vector<vector<double>> Matrix;

In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.

In C++0x, this token is always broken into two '>' tokens.

llvm-svn: 65484

expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.

llvm-svn: 65480

decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.

llvm-svn: 65478

specializations. In particular:

  - Make sure class template specializations have a "template<>"
    header, and complain if they don't.
  - Make sure class template specializations are declared/defined
    within a valid context. (e.g., you can't declare a specialization
    std::vector<MyType> in the global namespace).

llvm-svn: 65476

code) when calling noreturn functions; general expression emission
isn't ready to do the right thing in all cases.

llvm-svn: 65473

 - PR3662.

llvm-svn: 65472

 - No functionality change.

llvm-svn: 65470

  std::vector<int>::allocator_type

When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:

  template<> class Outer::Inner<int> { ... };

We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.

Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.

llvm-svn: 65467

global variable) out of GenerateStaticBlockVarDecl. 
 - No intended functionality change.
 - Prep for some mild cleanups and PR3662.

llvm-svn: 65466

llvm-svn: 65462

llvm-svn: 65461

only from a function definition (that does not have a prototype) are
only used to determine the compatible with other declarations of that
same function. In particular, when referencing the function we pretend
as if it does not have a prototype. Implement this behavior, which
fixes PR3626.

llvm-svn: 65460

Sema::CheckAssignmentConstraints; not really visible, but the right 
thing to do.

llvm-svn: 65428

retain/release checker: Implement basic tracking of autorelease stack.  Next thing is to wire up pools with their contents.

llvm-svn: 65425

llvm-svn: 65423

llvm-svn: 65422

llvm-svn: 65414

make sure objc2's nonfragile abi is enacted for Leopard too.
add -fobjc-gc-only flag to the image_info symbol.

llvm-svn: 65413

Fix broken logic from my last commit.  Branches only occur at basic blocks that end with terminators.

llvm-svn: 65410

Fix diagnostic regression where the leak diagnostic could appear earlier in the path than the branches taken.

llvm-svn: 65407

llvm-svn: 65403

llvm-svn: 65401

string size as an argument.

llvm-svn: 65400

llvm-svn: 65399

llvm-svn: 65398

llvm-svn: 65397