__builtin___CFStringMakeConstantString and CF typed function calls 
with explicit cf_returns_retained/cf_returns_not_retained attributes.
// rdar://9544832

llvm-svn: 133535

llvm-svn: 133529

Expr value not getting changed by this call.

llvm-svn: 133527

of: a + b ? x : y. In our testing of this flag we've yet to hit a single
case where the existing precedence was correct, so we should suggest
grouping the ?: first.

llvm-svn: 133526

// rdar://9474349

llvm-svn: 133525

MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given

  const int& r = 1.0;

The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value. 

IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.

llvm-svn: 133521

use the deprecated forms of llvm::StringMap::GetOrCreateValue().

llvm-svn: 133515

llvm-svn: 133501

message sent to an objc method (or property access)
// rdar://9474349

llvm-svn: 133469

Patch by Henry Mason with tweaks by me.

llvm-svn: 133453

(or follow up) extern declaration with weak_import as 
an actual definition. make clang follows this behavior. 
// rdar://9538608
llvm-gcc treats an extern declaration with weak_import

llvm-svn: 133450

pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.

llvm-svn: 133428

effectively that this abstraction simply doesn't exist. That is
highlighted by the fact that by using it we were papering over a more
serious error in this warning: the fact that we warned for *invalid*
constructs involving member pointers and block pointers.

I've fixed the obvious issues with the warning here, but this is
confirming an original suspicion that this warning's implementation is
flawed. I'm looking into how we can implement this more reasonably. WIP
on that front.

llvm-svn: 133425

llvm-svn: 133418

This makes 'isPointerLikeType' a little less confusing, and pulls the
decay check into a separate interface that is much more clear and
concrete. Also, just implement these as logical wrappers around other
predicates. Having a switch based implementation isn't likely to be
necessary. We can try to optimize them later if they show up on
a profile.

llvm-svn: 133405

Trieu, and fix them by checking for array and function types as well as
pointer types.

I've added a predicate method on Type to bundle together the logic we're
using here: isPointerLikeType(). I'd welcome better names for this
predicate, this is the best I came up with. It's implemented as a switch
to be a touch lighter weight than all the chained isa<...> casts that
would result otherwise.

llvm-svn: 133383

deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.

One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.

However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.

llvm-svn: 133327

silently dropped ownership qualifiers that were being applied to
ownership-qualified, substituted type that was *not* a substituted
template type parameter. We now provide a diagnostic in such cases,
and recover by dropping the added qualifiers.

Document this behavior in the ARC specification.

llvm-svn: 133309

ownership-unqualified retainable object type as __strong. This allows
us to write, e.g.,

  std::vector<id>

and we'll infer that the vector's element types have __strong
ownership semantics, which is far nicer than requiring:

  std::vector<__strong id>

Note that we allow one to override the ownership qualifier of a
substituted template type parameter, e.g., given

  template<typename T>
  struct X {
    typedef __weak T type;
  };

X<id> is treated the same as X<__strong id>. At instantiation type,
the __weak in "__weak T" overrides the (inferred or specified)
__strong on the template argument type, so that we can still provide
metaprogramming transformations.

This is part of <rdar://problem/9595486>.

llvm-svn: 133303

Add a minor hack to avoid using isNullPointerConstant on a hot path.  Fixes -O0 compile-time regressions from r133196.

rdar://9629775 .

llvm-svn: 133290

llvm-svn: 133264

llvm-svn: 133257

llvm-svn: 133246

they should still be officially __strong for the purposes of errors, 
block capture, etc.  Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables.  Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting         
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.

llvm-svn: 133243

[temp.deduct.call]p4 to the deduction performed for 'auto', finishing
the fix for PR9233.

llvm-svn: 133239

argument type for C++ [temp.deduct.call]p4 out of
Sema::FinishTemplateArgumentDeduction(). No functionality change.

llvm-svn: 133237

storage specifier is different from the storage specifier on the
template. If that storage specifier is the same, then we only warn.

Thanks to John for the prodding.

llvm-svn: 133236

C++, which means:
  - binding the temporary as needed in Sema, so that we generate the
  appropriate call to the destructor, and
  - emitting the compound literal into the appropriate location for
  the aggregate, rather than trying to emit it as a temporary and
  memcpy() it.

Fixes PR10138 / <rdar://problem/9615901>.

llvm-svn: 133235

specifier on an explicit specialization to a warning, since neither
EDG nor GCC diagnose this code as ill-formed.

llvm-svn: 133232

operators, don't make an initializer or sub-operation for zero-width
bitfields.

llvm-svn: 133221

through an ellipsis. Fixes <rdar://problem/9623945>.

llvm-svn: 133219

llvm-svn: 133215

(even though it is incomplete type) because gcc
says so. // rdar://9622422

llvm-svn: 133208

Add a new warning when a NULL constant is used in arithmetic operations.  The warning will fire on cases such as:

int x = 1 + NULL;

llvm-svn: 133196

constants. Fixes PR10145.

llvm-svn: 133179

__builtin_ versions of these functions as well as the normal function
versions, so that it works on platforms where memset/memcpy/memmove
are macros that map down to the builtins (e.g., Darwin). Fixes
<rdar://problem/9372688>.

llvm-svn: 133173

null at any time. // rdar://9612030

llvm-svn: 133168

checks that the deduced argument type for a function call matches the
actual argument type provided. The only place we've found where the
consistency checking should actually cause template argument deduction
failure is due to qualifier differences that don't fall into the realm
of qualification conversions (which are *not* checked when we
initially perform deduction). However, we're performing the full
checking as specified in the standard to ensure that no other cases
exist.

Fixes PR9233 / <rdar://problem/9039590>.

llvm-svn: 133163

and the programmer intended to write 'sizeof(*p)'. There are several
elements to the new version:

1) The actual expressions are compared in order to more accurately flag
   the case where the pattern that works for an array has been used, or
   a '*' has been omitted.
2) Only do a loose type-based check for record types. This prevents us
   from warning when we happen to be copying around chunks of data the
   size of a pointer and the pointer types for the sizeof and
   source/dest match.
3) Move all the diagnostics behind the runtime diagnostic filter. Not
   sure this is really important for this particular diagnostic, but
   almost everything else in SemaChecking.cpp does so.
4) Make the wording of the diagnostic more precise and informative. At
   least to my eyes.
5) Provide highlighting for the two expressions which had the unexpected
   similarity.
6) Place this diagnostic under a flag: -Wsizeof-pointer-memaccess

This uses the Stmt::Profile system for computing #1. Because of the
potential cost, this is guarded by the warning flag. I'd be interested
in feedback on how bad this is in practice; I would expect it to be
quite cheap in practice. Ideas for a cheaper / better way to do this are
also welcome.

The diagnostic wording could likely use some further wordsmithing.
Suggestions welcome here. The goals I had were to: clarify that its the
interaction of 'memset' and 'sizeof' and give more reasonable
suggestions for a resolution.

An open question is whether these diagnostics should have the note
attached for silencing by casting the dest/source pointer to void*.

llvm-svn: 133155

argument types for mem{set,cpy,move}. Character pointers, much like void
pointers, often point to generic "memory", so trying to check whether
they match the type of the argument to 'sizeof' (or other checks) is
unproductive and often results in false positives.

Nico, please review; does this miss any of the bugs you were trying to
find with this warning? The array test case you had should be caught by
the array-specific sizeof warning I think.

llvm-svn: 133136