llvm-svn: 169095

Recursively prune some includes.

llvm-svn: 169094

llvm-svn: 169093

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.

llvm-svn: 169092

In preparation for the FileCheck enhancement to support backreferences.

llvm-svn: 169090

llvm-svn: 169089

llvm-svn: 169088

llvm-svn: 169086

llvm-svn: 169078

llvm-svn: 169077

an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.

llvm-svn: 169075

Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.

llvm-svn: 169068

llvm-svn: 169066

scope when dealing with nested blocks. Fixes <rdar://problem/12778708>.

llvm-svn: 169065

Don't emit a warning with an input/output parameter. We assume the user knows what they're doing here.

llvm-svn: 169059

llvm-svn: 169058

state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>

llvm-svn: 169057

the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.

llvm-svn: 169054

<rdar://problem/12780159>.

llvm-svn: 169051

llvm-svn: 169045

module, provide a module import stack similar to what we would get for
an include stack, e.g.,

In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module

<rdar://problem/12696425>

llvm-svn: 169042

llvm-svn: 169041

llvm-svn: 169037

llvm-svn: 169030

llvm-svn: 169028

files are loaded.

llvm-svn: 169027

building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.

llvm-svn: 169021

Patch by Edwin Vane.

llvm-svn: 169000

llvm-svn: 168994

the beginning and end of the range are in different macro arguments.
PR14399.

llvm-svn: 168984

llvm-svn: 168977

llvm-svn: 168968

If 'x' is a temporary, x.getAs<Foo>() may not be safe if the result is
supposed to persist (if its address is stored somewhere). Since getAs()
can return a null value, the result is almost always stored into a
variable, which of course is not safe when the original value dies.

This has caused several bugs with GCC's "Temporaries May Vanish Sooner Than
You Expect" optimization; in C++11 builds, at least, we'll be able to catch
these problems now.

I would suggest applying these to other getAs() and get*As() methods
(castAs is "better" because sometimes the result is used directly, which
means the temporary will still be live), but these two have both caused
trouble in the analyzer in the past.

llvm-svn: 168967

llvm-svn: 168962

import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.

Fixes <rdar://problem/12552849>.

llvm-svn: 168961

llvm-svn: 168959

llvm-svn: 168958

llvm-svn: 168957

llvm-svn: 168956

llvm-svn: 168953