umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
part of the module with that umbrella directory. However, unlike
umbrella headers, which are expected to include all of the headers
within their subdirectories, Clang will automatically include all of
the headers it finds in the named subdirectory.

The intent here is to allow a module map to trivially turn a
subdirectory into a module, where the module's structure can mimic the
directory structure.

llvm-svn: 146165

llvm-svn: 146160

a modifier for a header declarartion, e.g.,

  umbrella header "headername"

Collapse the umbrella-handling code in the parser into the
header-handling code, so we don't duplicate the header-search logic.

llvm-svn: 146159

header to also support umbrella directories. The umbrella directory
for an umbrella header is the directory in which the umbrella header
resides.

No functionality change yet, but it's coming.

llvm-svn: 146158

that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.

llvm-svn: 146156

llvm-svn: 146155

directory_iterator for them.

llvm-svn: 146154

they are treated as errors.

Doing typo correction when these are just warnings slows down the
compilation of source which deliberately uses implicit function
declarations.

llvm-svn: 146153

llvm-svn: 146147

llvm-svn: 146146

llvm-svn: 146145

between the casted type of the return value of a malloc/calloc/realloc
call and the operand of any sizeof expressions contained within
its argument(s).

llvm-svn: 146144

llvm-svn: 146142

that have it in /usr/include (only OS X Lion so far).

llvm-svn: 146140

llvm-svn: 146138

llvm-svn: 146122

integration.

llvm-svn: 146098

dual support for compiler-rt on Linux, during bringup.

llvm-svn: 146094

private headers in a framework.

llvm-svn: 146082

llvm-svn: 146074

llvm-svn: 146056

llvm-svn: 146034

in addition to underlying type.

For example, the warning for printf("%zu", 42.0);
changes from "conversion specifies type 'unsigned long'" to "conversion
specifies type 'size_t' (aka 'unsigned long')"

(This is a second attempt after r145697, which got reverted.)

llvm-svn: 146032

-Allow it to be used with multiple BeginSourceFile/EndSourceFile calls; for this introduce
 a "finish" callback method in the DiagnosticConsumer. SDiagsWriter finishes up the serialization
 file inside this method.
-Make it independent of any particular DiagnosticsEngine; make it use the SourceManager of the
 Diagnostic object.
-Ignore null source ranges.

llvm-svn: 146020

llvm-svn: 146016

when we load a module map (module.map) from a directory, also load a
private module map (module_private.map) for that directory, if
present. That private module map can inject a new submodule that
captures private headers.

llvm-svn: 146012

Make sure we correctly zero-initialize unions containing a pointer to data member as the first field.  PR11487.

llvm-svn: 146009

SVal can be not only a symbol, but a MemRegion. Add support for such
cases.

llvm-svn: 146006

module, at least have the decency to complain about it.

llvm-svn: 146002

bound to not have side effects(!). Add constant-folding support for expressions
of void type, to ensure that we can still fold ((void)0, 1) as an array bound.

llvm-svn: 146000

methods with these attributes are sent to receivers
of 'id' type too. // rdar://10459930

llvm-svn: 145999

for a foldable constant rather than an IR-level constant. This is still far too
liberal, but is a step in the right direction.

llvm-svn: 145990

llvm-svn: 145987

for finding dependent symbols for taint.

llvm-svn: 145986

 - Created a new SymExpr type - SymbolCast.
 - SymbolCast is created when we don't know how to simplify a NonLoc to
NonLoc casts.
 - A bit of code refactoring: introduced dispatchCast to have better
code reuse, remove a goto.
 - Updated the test case to showcase the new taint flow.

llvm-svn: 145985

llvm-svn: 145984

llvm-svn: 145983

evaluator into constant initializer handling / IRGen. The practical consequence
of this is that the bitcast now lives in the constant's definition, rather than
in its uses.

The code in the constant expression evaluator was producing vectors of the wrong
type and size (and possibly of the wrong value for a big-endian int-to-vector
bitcast). We were getting away with this only because we don't yet support
constant-folding of any expressions which inspect vector values.

llvm-svn: 145981

llvm-svn: 145973

llvm-svn: 145958