[analyzer] CStringChecker checks functions in the C standard library, not C++. Its external name is now unix.experimental.CString.

llvm-svn: 132958

The LLVM IR representation of byval arguments has a rather strange property: if the alignment of an argument to a call is less than the specified byval alignment for that argument, there is no way to specify the alignment of the implied copy.  Therefore, we must ensure that the alignment of the argument is at least the byval alignment.  To do this, we have to mess with the alignment of relevant alloca's in some cases, and insert a copy that conceptually shouldn't be necessary in some cases.

This patch tries relatively hard to avoid creating an extra copy if it can be avoided (see test3 in the included testcase), but it is not possible to avoid in some cases (like test2 in the included testcase).

rdar://9483886

llvm-svn: 132957

llvm-svn: 132956

[analyzer] Fix modeling of strnlen to be more conservative. Move tests we can't properly model (yet?) to string-fail.c.

llvm-svn: 132955

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

This fixes radar 8757124.

llvm-svn: 132949

llvm-svn: 132924

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

llvm-svn: 132919

llvm-svn: 132917

llvm-svn: 132905

- Move the diagnostic to the case statement instead of at the end of the switch
- Add a fix-it hint as to how to fix the compilation error

llvm-svn: 132903

handle memcpy and memmove. Spotted by Nico.

llvm-svn: 132902

llvm-svn: 132901

  struct {
    typedef int A = 0;
  };

According to the C++11 standard, this is not ill-formed, but does not have any ascribed meaning. We can't reasonably accept it, so treat it as ill-formed.

Also switch C++ from an incorrect 'fields can only be initialized in constructors' diagnostic for this case to C's 'illegal initializer (only variables can be initialized)'

llvm-svn: 132890

llvm-svn: 132879

llvm-svn: 132878

keyword in objc property decl.

llvm-svn: 132877

pointer assignment in C++. This was a longstanding problem spotted by
Jordy Rose.

llvm-svn: 132873

Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:

t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
      expression of type 'NSArray *' [-Wincompatible-pointer-types]
  NSSet *array = [[NSArray alloc] init];
         ^       ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note: 
      instance method 'init' is assumed to return an instance of its
      receiver
      type ('NSArray *')
- (id)init;
^

It also means that we get decent type inference when writing code in
Objective-C++0x:

  auto array = [[NSMutableArray alloc] initWithObjects:@"one",  @"two",nil];
  //    ^ now infers NSMutableArray* rather than id

llvm-svn: 132868

properties.

llvm-svn: 132866

PR10120: Make CodeGenModule::getVTableLinkage use NamedDecl::getLinkage to determine whether the vtable should be externally visible, instead of a rough approximation of it which messes up with templates.

While I'm here, zap the other user of isInAnonymousNamespace outside of Decl.cpp.

llvm-svn: 132861

llvm-svn: 132855

to study it.

llvm-svn: 132843

I believe, upon, careful review, that this code causes us to incorrectly
handle exception specifications of copy assignment operators in C++03
mode. However, we currently do not seem to properly implement the subtle
distinction between copying of members and bases made by implicit copy
constructors and assignment operators in C++03 - namely that they are
limited in their overload selection - in all cases. As such, I feel that
committing this code is correct pending a careful review of our
implementation of these semantics.

llvm-svn: 132841

[analyzer] PR8962 again. Ban ParenExprs (and friends) from block-level expressions (by calling IgnoreParens before adding expressions to blocks). Undo 132769 (LiveVariables' local IgnoreParens), since it's no longer necessary.

Also, have Environment stop looking through NoOp casts; it didn't match the behavior of LiveVariables. And once that's gone, the whole cast block of that switch is unnecessary.

llvm-svn: 132840

llvm-svn: 132835

isn't yet used for the less controlled environments of initialization.

Also a few random text fixups.

llvm-svn: 132833

- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree.  Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.

llvm-svn: 132831

// rdar://9566314

llvm-svn: 132791

This is a follow-up to r132565, and should address the rest of PR9969:

Warn about cases such as

int foo(A a, bool b) {
 return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}

also when + is an overloaded operator call.

llvm-svn: 132784

[analyzer] Ignore parentheses around block-level expressions when computing liveness. Fixes the other half of PR8962.

llvm-svn: 132769

llvm-svn: 132762

It is not a sanctioned keyword and is assumed as default.
// rdar://8790791

llvm-svn: 132753

comments.  rdar://problem/9037836

llvm-svn: 132752

This fixes a memory error on FreeBSD (and is the right thing to do
in any case).

llvm-svn: 132750

were intended for was suppressed.

llvm-svn: 132746

Very sorry for the accidental commit of WIP code.

llvm-svn: 132745

namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.

llvm-svn: 132744

llvm-svn: 132743

rdar://problem/9037836

llvm-svn: 132737