This is old leftover cruft from the days when C++ was not yet ready
for prime time.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141063 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141062 91177308-0d34-0410-b5e6-96231b3b80d8

-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
 class name, not the location of '@'.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141061 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141060 91177308-0d34-0410-b5e6-96231b3b80d8

installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.

This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.

This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.

Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141056 91177308-0d34-0410-b5e6-96231b3b80d8

was assembly.  Otherwise, something like -save-temps causes the integrated
assembler to warn.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141055 91177308-0d34-0410-b5e6-96231b3b80d8

using the integrated assembler.
rdar://10216353

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141053 91177308-0d34-0410-b5e6-96231b3b80d8

separate thread with the "suitably large" stack, so we don't blow the
stack when building modules recursively.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141051 91177308-0d34-0410-b5e6-96231b3b80d8

Make sure SourceManager::getFileIDLoaded doesn't hang in release build because of invalid passed parameter.
rdar://10210140

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141048 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Remove redundant state (AnalysisContext pointer for every BinaryOperator tracked) from IdempotentOperationChecker.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141045 91177308-0d34-0410-b5e6-96231b3b80d8

functions. // rdar://10186536


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141037 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] In UndefBranchChecker, use a node generator which does not create an edge/branching. (ExprEngine should be in charge of generating edges. The checkers should examine the condition and generate PostCondition node if needed.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141034 91177308-0d34-0410-b5e6-96231b3b80d8

  - Remove unused FindUndefExpr::ProgramStateManager.
  - The Condition parameter of the callback is the terminator of the block, no need to retrieve it again.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141027 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141018 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141012 91177308-0d34-0410-b5e6-96231b3b80d8

is designed to allow the detection to record more rich information about
the installation than just a single path.

Mostly, the functionality remains the same. This is primarily
a factoring change. However, the new factoring immediately fixes one
issue where on ubuntu we didn't walk up enough layers to reach the
parent lib path. I'll have a test tree for that once I finish making the
Ubuntu tree work reasonably.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141011 91177308-0d34-0410-b5e6-96231b3b80d8

not bind to a temporary. Fixes //rdar://10188258


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141009 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141008 91177308-0d34-0410-b5e6-96231b3b80d8

sync between DiagnosticsEngine and PartialDiagnostic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141006 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141002 91177308-0d34-0410-b5e6-96231b3b80d8

configuration, although the test still stubs out more directories than
are necessary or common in order to exercise all of the lookup paths
observed with upstream GCC.

This finishes testing the distribution-independent and
GCC-installation-independent parts of the library path search logic.
More testing is still needed for the triple detection, GCC-installation
detection, and handling distributions with unusual configurations.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141000 91177308-0d34-0410-b5e6-96231b3b80d8

enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.

With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.

Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.

If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140999 91177308-0d34-0410-b5e6-96231b3b80d8

include *any* path on crtbegin.o unless we actually find such a file via
one of the search paths. We still strictly check the search paths right
after this, so we'll catch any issues there.

The reason for this is that the driver does some normalization of the
path on the actual object file, and this changes the textual format of
the string on Windows. It no longer matches the textual format of the
sysroot flag.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140998 91177308-0d34-0410-b5e6-96231b3b80d8

any distros that use this, building a multilib GCC from mainline will
install linker scripts here.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140996 91177308-0d34-0410-b5e6-96231b3b80d8

This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.

Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140995 91177308-0d34-0410-b5e6-96231b3b80d8

This is still very much a WIP, but sysroot was completely broken before
this so we are moving closer to correctness.

The crux of this is that 'ld' (on Linux, the only place I'm touching
here) doesn't apply the sysroot to any flags given to it. Instead, the
driver must translate all the paths it adds to the link step with the
system root. This is easily observed by building a GCC that supports
sysroot, and checking its driver output.

This patch just fixes the non-multilib library search paths. We should
also use this in many other places, but first things first.

This also allows us to make the Linux 'ld' test independent of the host
system. This in turn will allow me to check in test tree configurations
based on various different distro's configuration. Again, WIP.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140990 91177308-0d34-0410-b5e6-96231b3b80d8

Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is

  -Immediately before the arguments: -(id)first:(int)x second:(int)y;
  -With a space between the arguments: -(id)first: (int)x second: (int)y;
  -For nullary selectors, immediately before ';': -(void)release;

In such cases we infer the locations instead of storing them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140989 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140988 91177308-0d34-0410-b5e6-96231b3b80d8

Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is

  -Immediately before the arguments: [foo first:1 second:2]
  -With a space between the arguments: [foo first: 1 second: 2]
  -For nullary selectors, immediately before ']': [foo release]

In such cases we infer the locations instead of storing them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140987 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140986 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140985 91177308-0d34-0410-b5e6-96231b3b80d8

objc method decls.

They are not stored in the AST yet.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140984 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140983 91177308-0d34-0410-b5e6-96231b3b80d8

They are not kept in the AST yet.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140982 91177308-0d34-0410-b5e6-96231b3b80d8

precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.

This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.

There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.

If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.

No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140981 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140978 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140977 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140976 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140975 91177308-0d34-0410-b5e6-96231b3b80d8

support both a fragile and non-fragile ABI, and it can be selected at
runtime.  That driver option also works on Darwin (although obviously
the code is not necessarily usable if the system runtime is fragile)
so just do that.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140973 91177308-0d34-0410-b5e6-96231b3b80d8