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

complaining about mismatches in the global method pool.

llvm-svn: 133123

be more consistent in how parenthesized ranges which hit macros are
handled. Also makes the code significantly shorter, and the diagnostics
when macros are present a bit more useful.

Pair programmed w/ Matthew.

llvm-svn: 133122

llvm-svn: 133120

Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.

Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.

llvm-svn: 133103

were just punting on template argument deduction for a number of type
nodes. Most of them, obviously, didn't matter.

As a consequence of this, make extended vector types (via the
ext_vector_type attribute) actually work properly for several
important cases:
  - If the attribute appears in a type-id (i.e, not attached to a
  typedef), actually build a proper vector type
  - Build ExtVectorType whenever the size is constant; previously, we
  were building DependentSizedExtVectorType when the size was constant
  but the type was dependent, which makes no sense at all.
  - Teach template argument deduction to handle
  ExtVectorType/DependentSizedExtVectorType.

llvm-svn: 133060

llvm-svn: 133056

before the template parameters have acquired a proper context (e.g.,
because the enclosing context has yet to be built), provide empty
parameter lists for all outer template parameter scopes to inhibit any
substitution for those template parameters. Fixes PR9643 /
<rdar://problem/9251019>.

llvm-svn: 133055

either imlicitly (for builtins) or explicitly (due to multiple
specification of the same attributes). Fixes <rdar://problem/9612060>.

llvm-svn: 133045

protected in the case where a variable is being initialized by a
trivial default constructor but has a non-trivial destructor.

llvm-svn: 133037

llvm-svn: 133036

Change the output for -Wshift-overflow and
-Wshift-sign-overflow to an unsigned hexadecimal. It makes
more sense for looking at bits than a signed decimal does.
Also, change the diagnostic's wording from "overrides"
to "sets".

This uses a new optional argument in APInt::toString()
that adds the '0x' prefix to hexademical numbers.

This fixes PR 9651.

Patch by nobled@dreamwidth.org!

llvm-svn: 133033

inference, to be used (only) by the Objective-C rewriter.

llvm-svn: 133025

llvm-svn: 132996

as constant size arrays.  This has slightly different semantics in some insane cases, but allows
us to accept some constructs that GCC does.  Continue to be pedantic in -std=c99 and other
modes.  This addressed rdar://8733881 - error "variable-sized object may not be initialized"; g++ accepts same code

llvm-svn: 132983

as an extension.

llvm-svn: 132980

- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors

llvm-svn: 132979

llvm-svn: 132975

Make __gnu_inline__ functions in gnu99 mode work the same way as inline functions in gnu89 mode in terms of redefinitions.

rdar://9559708 .

llvm-svn: 132953

reason to allow the user to control these semantics through a flag.

llvm-svn: 132919

llvm-svn: 132917

llvm-svn: 132905

handle memcpy and memmove. Spotted by Nico.

llvm-svn: 132902