While collections containing nil elements can still be iterated over in an
Objective-C for-in loop, the most common Cocoa collections -- NSArray,
NSDictionary, and NSSet -- cannot contain nil elements. This checker adds
that assumption to the analyzer state.

This was the cause of some minor false positives concerning CFRelease calls
on objects in an NSArray.

llvm-svn: 158319

This has a small hit in the case where only one class is interesting
(NilArgChecker) but is a big improvement when looking for one of several
interesting classes (VariadicMethodTypeChecker), in which the most common
case is that there is no match.

llvm-svn: 158318

It found a lot of cruft in LLVM that I removed last week and I couldn't find any
false positives. Time to give it more testing.

llvm-svn: 158317

only using the linkage.

Use and test both, documenting that considering the visibility and linkage
of template parameters is a difference from gcc.

llvm-svn: 158309

llvm-svn: 158307

llvm-svn: 158300

such as "protocol" and "expression" being implicitly turned into links to
mistakenly-generated Doxygen pages:
- Escaping @ symbols when Doxygen would otherwise incorrectly interpret them;
- Escaping # symbols when they're not intended as explicit Doxygen link 
  requests, such as when discussing preprocessor directives;
- In one odd case, unescaping @ in @__experimental_modules_import, because
  Doxygen wrote '\@' to the output in that case, causing the example in the
  description of ImportDecl to be wrong; and
- Fixing a typo: @breif -> @brief.

llvm-svn: 158299

llvm-svn: 158298

consider them when enumerating builtin operator candidates.

llvm-svn: 158293

llvm-svn: 158292

We need an efficient mechanism to determine whether a defaulted default
constructor is constexpr, in order to determine whether a class is a literal
type, so keep the incrementally-built form on CXXRecordDecl. Remove the
on-demand computation of same, so that we only have one method for determining
whether a default constructor is constexpr. This doesn't affect correctness,
since default constructor lookup is much simpler than selecting a constructor
for copying or moving.

We don't need a corresponding mechanism for defaulted copy or move constructors,
since they can't affect whether a type is a literal type. Conversely, checking
whether such functions are constexpr can require non-trivial effort, so we defer
such checks until the copy or move constructor is required.

Thus we now only compute whether a copy or move constructor is constexpr on
demand, and only compute whether a default constructor is constexpr in advance.
This is unfortunate, but seems like the best solution.

llvm-svn: 158290

an explicitly-defaulted default constructor would be constexpr. This is
necessary in weird (but well-formed) cases where a class has more than one copy
or move constructor.

Cleanup of now-unused parts of CXXRecordDecl to follow.

llvm-svn: 158289

initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288

llvm-svn: 158287

llvm-svn: 158286

expressions.

llvm-svn: 158285

llvm-svn: 158284

llvm-svn: 158282

llvm-svn: 158281

llvm-svn: 158277

llvm-svn: 158275

No functionality change.

llvm-svn: 158272

llvm-svn: 158270

in the same line do not override getting a cursor for the previous declaration.

e.g:

int x, y;
@synthesize prop1, prop2;

pointing at 'x'/'prop1' would give 'y'/'prop2' because their source ranges overlap.

rdar://11361113

llvm-svn: 158258

llvm-svn: 158254

Still not linked in; comments and additions are very welcome.

llvm-svn: 158253

While this code is valid C++98, it is not valid C++11. The problem can be
reduced to:

class MDNode;

class DIType {
  operator MDNode*() const {return 0;}
};

class WeakVH {
  WeakVH(MDNode*) {}
};

int main() {
  DIType di;
  std::pair<void*, WeakVH> p(std::make_pair((void*)0, di)));
}

This was not detected by any of the bots we have because they either compile
C++98 with libstdc++ (which allows it), or C++11 with libc++ (which incorrectly
allows it). I ran into the problem when compiling with VS 2012 RC.

Thanks to Richard for explaining the issue.

llvm-svn: 158245

to a change done long ago in r57393.

llvm-svn: 158243

llvm-svn: 158241

This could happen for cases like this:

- (NSArray *)getAllNames:(NSArray *)images {
  NSMutableArray *results = [NSMutableArray array];
  for (auto img in images) {
    [results addObject:img.name];
  }
  return results;
}

Here the property access will fail because 'img' has type 'id', rather than,
say, NSImage.

This warning will not fire in templated code, since the 'id' could have
come from a template parameter.

llvm-svn: 158239

llvm-svn: 158238

typo-correction after a scope specifier.

llvm-svn: 158231

Objective-C literals conceptually always create new objects, but may be
optimized by the compiler or runtime (constant folding, singletons, etc).
Comparing addresses of these objects is relying on this optimization
behavior, which is really an implementation detail.

In the case of == and !=, offer a fixit to a call to -isEqual:, if the
method is available. This fixit is directly on the error so that it is
automatically applied.

Most of the time, this is really a newbie mistake, hence the fixit.

llvm-svn: 158230

This occurs when you have two insertions and the first one is so long that the
second fixit's column is before the first fixit ends. The edits themselves
don't actually overlap, but our command-line preview does.

llvm-svn: 158229

constexpr until we get to the end of the class definition. When that happens,
be sure to remember that the class actually does have a constexpr constructor.

This is a stopgap solution, which still doesn't cover the case of a class with
multiple copy constructors (only some of which are constexpr). We should be
performing constructor lookup when implicitly defining a constructor in order
to determine whether all constructors it invokes are constexpr.

llvm-svn: 158228

variable which wasn't removed when the original patch was committed.

llvm-svn: 158225

to addition.

We should not to warn in case the malloc size argument is an
addition containing 'sizeof' operator - it is common to use the pattern
to pack values of different sizes into a buffer. 

Ex:

uint8_t *buffer = (uint8_t*)malloc(dataSize + sizeof(length));

llvm-svn: 158219

The preprocessor's handling of diagnostic push/pops is stateful, so
encountering pragmas during a re-parse causes problems. HTMLRewrite
already filters out normal # directives including #pragma, so it's
clear it's not expected to be interpreting pragmas in this mode.

This fix adds a flag to Preprocessor to explicitly disable pragmas.
The "right" fix might be to separate pragma lexing from pragma
parsing so that we can throw away pragmas like we do preprocessor
directives, but right now it's important to get the fix in.

Note that this has nothing to do with the "hack" of re-using the
input preprocessor in HTMLRewrite. Even if we someday copy the
preprocessor instead of re-using it, the copy would (and should) include
the diagnostic level tables and have the same problems.

llvm-svn: 158214

from Tom Honermann!

llvm-svn: 158211

that does not exist.

rdar://11607033

llvm-svn: 158193