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

reader statistics), to show the local-to-global mappings. The only
such mapping we have (at least, for now) is for source location
offsets.

llvm-svn: 136687

all of the kinds of IDs that can be offset. No effectively
functionality change; this is preparation for adding remapping for
IDs.

llvm-svn: 136686

llvm-svn: 136679

No functional change.

llvm-svn: 136678

This reverts commit 67d097e1232b7d66f58989c16a45b8a11721f76e.
We found a miscompile with ARM byval, which is still being investigated.
In the meantime, this works around the problem by disabling ARM byval.

Conflicts:
	lib/CodeGen/TargetInfo.cpp

llvm-svn: 136662

Add a skeleton for the Keychain Services API Checker. Register it as OSX experimental for now. Note, the checker still does not handle tracking of escaped values, taking into account the return value of the allocator functions, nor the actual bug reporting.. 

llvm-svn: 136659

llvm-svn: 136658

without bailing out when va_arg is an aggregate expression. However, 
alignment checking needs to be added in isSafeToEliminateVarargsCast in
InstCombineCalls.cpp in order to produce correct mips code (see link below).

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/042047.html

llvm-svn: 136647

Unfortunately, llvmgcc doesn't always work when writing temporary output to
/dev/null.  Therefore, create a temp file that is later deleted.
rdar://9837692

llvm-svn: 136644

llvm-svn: 136630

llvm-svn: 136628

Move the serialization of the MODULE_OFFSET_MAP out of the source-manager-writing code and into the general chained-PCH writing code

llvm-svn: 136624

Rename the AST file's SOURCE_LOCATION_MAP to MODULE_OFFSET_MAP, to indicate the greater role it will soon play in remapping.

llvm-svn: 136619

llvm-svn: 136602

llvm-svn: 136581

EndRangeLoc should always be set to at least the ending paren or brace.

llvm-svn: 136573

broken because the end location of the parameter was the end location of the default arg,
resulting in a source range that could begin in one file and end in another.

llvm-svn: 136572

appropriate sentinel at the end of the argument list. Also, put the
sentinel warnings under -Wsentinel. Fixes <rdar://problem/8764236>.

llvm-svn: 136566

statement. Fixes <rdar://problem/9229438>.

llvm-svn: 136564

variadic bit (", ..." or ", args...") into the prior placeholder, like
we do with functions and methods. Fixes <rdar://problem/9740808>.

llvm-svn: 136563

(such as in, inout, byref, and oneway) to code completion
results. Fixes <rdar://problem/8844158>.

llvm-svn: 136562

llvm-svn: 136561

libstdc++ hack has reverted these type traits to keywords. Icky, but
fixes <rdar://problem/9836262>.

llvm-svn: 136560

already-defined and forward-declared results. Already-defined results
are fine because they could be the start of a category. Fixes
<rdar://problem/9811691>.

llvm-svn: 136559

special diagnostic for ARC ownership-qualified types. We wouldn't want
to expose Objective-C programmers to the term "POD", would we? Fixes
<rdar://problem/9772982>.

llvm-svn: 136558

a fallback, if normal header search fails. Another attempt at
<rdar://problem/9824020>.

llvm-svn: 136557