llvm-svn: 136852

KeychainAPI checker: Add basic diagnostics. Track MemoryRegion istead of SymbolicRef since the address might not be a symbolic value in some cases, for example in fooOnlyFree() test.

llvm-svn: 136851

llvm-svn: 136850

llvm-svn: 136849

structures.  Alignment can be enforced with the use of anonymous bitfields 
(e.g., int :0), but this is not currently supported.  Add this test case to 
document the current state, which will hopefully be fixed shortly. 

llvm-svn: 136848

IDs will never cross module boundaries, since they're tied to the
CXXDefinitionData, so just use a local mapping throughout. Eliminate
the global -> local tables and supporting data.

llvm-svn: 136847

designed to be executed, and its output inspected for correct values,
but we aren't executing it. We're just compiling it, and dumping it to
/dev/null. It also isn't freestanding. If there is a desire to have this
test actually stick around, complain and I'll revert this and try to add
the file checks necessary to make this actually test things.

llvm-svn: 136846

llvm-svn: 136841

reader. Tested with the usual "gaps" method.

llvm-svn: 136839

[analyzer] rename all experimental checker packages to have 'experimental' be the common root package.

llvm-svn: 136835

own, incorrectly, for releasing objects at the end of a full-expression.

llvm-svn: 136823

reader, and fix up the one (!) place where we were improperly mapping
a local ID to a global ID. Tested via the usual "gaps" trick.

llvm-svn: 136817

Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.

llvm-svn: 136807

[analyzer] Introduce MallocOverflowSecurityChecker, a simple flow-sensitive checker that may be useful for security auditing.  This checker is currently too noisy to be on by default.

llvm-svn: 136804

those declated in its protocols. First half or // rdar://6191214

llvm-svn: 136794

llvm-svn: 136792

llvm-svn: 136788

integer, and initialise its TypeSourceInfo. The initialisation fixes a
crash when using pre-compiled preambles with C++ code-completion. From
Erik Verbruggen! Fixes PR10511.

llvm-svn: 136786

llvm-svn: 136783

AST file, along with an enumeration naming those predefined
declarations. No functionality change, but this will make it easier to
introduce new predefined declarations, when/if we need them.

llvm-svn: 136781

llvm-svn: 136780

reader, to allow AST files to be loaded with their declarations
remapped to different ID numbers. Fix a number of places where we were
either failing to map local declaration IDs into global declaration
IDs or where interpreting the local declaration IDs within the wrong
module. 

I've tested this via the usual "random gaps" method. It works well
except for the preamble tests, because our handling of the precompiled
preamble requires declaration and preprocessed entity to be stable
when parsing code and then loading that back into memory. This
property will hold in general, but my randomized testing naturally
breaks this property to get more coverage. In the future, I expect
that the precompiled preamble logic won't need this property.

I am very unhappy with the current handling of the translation unit,
which is a rather egregious hack. We're going to have to do something
very different here for loading multiple AST files, because we don't
want to have to cope with merging two translation units. Likely, we'll
just handle translation units entirely via "update" records, and
predefine a single, fixed declaration ID for the translation
unit. That will come later.

llvm-svn: 136779

unless done in a context where the value is used retained.

llvm-svn: 136769

A homogeneous aggregate is an aggregate data structure where after flattening
any nesting there are 1 to 4 elements of the same base type that is either a
float, double, or Neon vector.  All Neon vectors of the same size, either 64
or 128 bits, are treated as equivalent for this purpose.  When using the
AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by
expanding them into a sequence of their base types.  This requires extending
the existing support for expanded arguments to handle not only structs, but
also constant arrays and complex types.

llvm-svn: 136767

Static Analyzer diagnostics visualization: when the last location on a path is end of the function, the arrow should point to the closing brace, not the statement before it. Patch by Ted Kremenek.

llvm-svn: 136761

function, be sure to drop parameter attributes when dropping their
associated arguments.  Patch by Aaron Landwehr!

llvm-svn: 136753

1. Be more tolerant of comments in -CC (comment-preserving) mode.  We were missing a few cases.

2. Make sure to expand the second FOO in "#if defined FOO FOO".  (See also
r97253, which addressed the case of "#if defined(FOO FOO".)

Fixes PR10286.

llvm-svn: 136748

Patch by Jim (Ningjie) Chen.

llvm-svn: 136734

llvm-svn: 136728

has a single element.  This disables the warning in cases where
there is a clear bug, but this is really rare (who uses arrays
with one element?) and it also silences a large class of false
positive issues with C89 code that is using tail padding in structs.

A better version of this patch would detect when an array is in
a tail position in a struct, but at least patch fixes the huge
false positives that are hitting postgres and other code.

llvm-svn: 136724

enough to offer to investigate the underlying issue.  Thanks to Doug for his
assistance as well.

llvm-svn: 136719

statement inside a block. // rdar://9878420

llvm-svn: 136717

Someone with more cmake experience want to throw me a bone? :)

llvm-svn: 136709

by eliminating the type ID from constructor, destructor, and
conversion function names. There are several reasons for this change:
  - A given type (say, int*) isn't guaranteed to have a single, unique
  type ID within a chain of PCH files. Hence, we could end up hashing
  based on the wrong type ID, causing name lookup to fail.

  - The mapping from types back to type IDs required one DenseMap
  entry for every type that was ever deserialized, which was an
  unacceptable cost to support just the name lookup of constructors,
  destructors, and conversion functions. Plus, this mapping could
  never actually work with chained or multiple PCH, based on the first
  bullet.

Once we have eliminated the type from the hash function, these
problems go away, as does my horrible "reverse type remap" hack, which
was doomed from the start (see bullet #1 above) and far too
complicated. 

However, note that removing the type from the hash function means that
all constructors, destructors, and conversion functions have the same
hash key, so I've updated the caller to double-check that the
declarations found have the appropriate name.

llvm-svn: 136708

[analyzer] Drastically simplify ExprEngine::VisitInitListExpr() by assuming all initializer expressions have already been evaluated.

llvm-svn: 136706

llvm-svn: 136703

information including the fully preprocessed source file(s) and command line 
arguments.  The developer is asked to attach this diagnostic information to a 
bug report.
rdar://9575623

llvm-svn: 136702

Following up the earlier refactoring/cleanup work by fixing up how we manage the virtual files the ASTReader has to handle.  Specifically, this occurs when the reader is reading AST files that were created in memory and not written to disk.  For example, when a user creates a chained PCH using command line flags.  These virtual files are stored in MemoryBuffers in ChainIncludeSource.cpp, and then read back in by the ASTReader.  This patch moves the management of these buffers into the ModuleManager, so that it becomes the authority on where these buffers are located.

llvm-svn: 136697

KeychainAPI checker: only check the paths on which the allocator function returned noErr. (+ minor cleanup)

llvm-svn: 136694

reader. This scheme permits an AST file to be loaded with its type IDs
shifted anywhere in the type ID space. 

At present, the type indices are still allocated in the same boring
way they always have been, just by adding up the number of types in
each PCH file within the chain. However, I've done testing with this
patch by randomly sliding the base indices at load time, to ensure
that remapping is occurring as expected. I may eventually formalize
this in some testing flag, but loading multiple (non-chained) AST
files at once will eventually exercise the same code.

There is one known problem with this patch, which involves name lookup
of operator names (e.g., "x.operator int*()") in cases where multiple
PCH files in the chain. The hash function itself depends on having a
stable type ID, which doesn't happen with chained PCH and *certainly*
doesn't happen when sliding type IDs around. We'll need another
approach. I'll tackle that next.

llvm-svn: 136693