llvm-svn: 59824

llvm-svn: 59821

llvm-svn: 59806

code gen. method.

llvm-svn: 59767

write-barriers.

llvm-svn: 59748

llvm-svn: 59740

to static function. Added comments.

llvm-svn: 59738

from Sebastian to enforce that a literal string is passed in,
and use this to avoid having to call strlen on it.

llvm-svn: 59706

diagnostics on use of __weak attribute on fields,
Early support for read/write barriers for objc fields.

llvm-svn: 59682

objects as __strong when attribute unspecified.

llvm-svn: 59654

llvm-svn: 59645

llvm-svn: 59622

value).
 - Use extra argument to EmitStoreThroughLValue to provide place to
   write update bit-field value if caller requires it.
 - This fixes several FIXMEs.

llvm-svn: 59615

llvm-svn: 59613

llvm-svn: 59611

llvm-svn: 59610

llvm-svn: 59594

Also, took care of Daniel's commments.

llvm-svn: 59575

__weak objects.

llvm-svn: 59560

llvm-svn: 59553

llvm-svn: 59543

are formed.  In particular, a diagnostic with all its strings and ranges is now
packaged up and sent to DiagnosticClients as a DiagnosticInfo instead of as a 
ton of random stuff.  This has the benefit of simplifying the interface, making
it more extensible, and allowing us to do more checking for things like access
past the end of the various arrays passed in.

In addition to introducing DiagnosticInfo, this also substantially changes how 
Diagnostic::Report works.  Instead of being passed in all of the info required
to issue a diagnostic, Report now takes only the required info (a location and 
ID) and returns a fresh DiagnosticInfo *by value*.  The caller is then free to
stuff strings and ranges into the DiagnosticInfo with the << operator.  When
the dtor runs on the DiagnosticInfo object (which should happen at the end of
the statement), the diagnostic is actually emitted with all of the accumulated
information.  This is a somewhat tricky dance, but it means that the 
accumulated DiagnosticInfo is allowed to keep pointers to other expression 
temporaries without those pointers getting invalidated.

This is just the minimal change to get this stuff working, but this will allow
us to eliminate the zillions of variant "Diag" methods scattered throughout
(e.g.) sema.  For example, instead of calling:

  Diag(BuiltinLoc, diag::err_overload_no_match, typeNames,
       SourceRange(BuiltinLoc, RParenLoc));

We will soon be able to just do:

  Diag(BuiltinLoc, diag::err_overload_no_match)
      << typeNames << SourceRange(BuiltinLoc, RParenLoc));

This scales better to support arbitrary types being passed in (not just 
strings) in a type-safe way.  Go operator overloading?!

llvm-svn: 59502

strings instead of array of strings.  This reduces string copying
in some not-very-important cases, but paves the way for future 
improvements.

llvm-svn: 59494

representing the names of declarations in the C family of
languages. DeclarationName is used in NamedDecl to store the name of
the declaration (naturally), and ObjCMethodDecl is now a NamedDecl.

llvm-svn: 59441

moment.

llvm-svn: 59435

llvm-svn: 59433

llvm-svn: 59426

llvm-svn: 59405

llvm-svn: 59404

Patch by Fariborz!

llvm-svn: 59377

llvm-svn: 59375

llvm-svn: 59372

llvm-svn: 59371

llvm-svn: 59358

llvm-svn: 59345

function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)

I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.

llvm-svn: 59306

 - Logic such as this quite possibly should be optional builder
   behavior.

llvm-svn: 59213

landing pads.
 - Primarily a cleanliness issue instead of a performance issue (this
   eliminates all blocks w/o predecessors on 176.gcc/expr.c), but this
   also allows subsequent code to recognize it is unreachable and
   potentially avoid IRgen.

llvm-svn: 59211

 - Use dotted notation for blocks related to a particular statement
   type.
 - Use .end for landing pads.

No functionality change in NDEBUG mode. :)

llvm-svn: 59210

 - Indicates that caller is done with the block and it can be dropped
   if it has no predecessors. Useful for callers who need to make
   landing pads but which may not be reached.

No functionality change.

llvm-svn: 59207