llvm-svn: 143894

llvm-svn: 143891

llvm-svn: 143890

llvm-svn: 143889

investigate build failure.

llvm-svn: 143888

llvm-svn: 143887

llvm-svn: 143886

include ownership qualifiers from the type.

llvm-svn: 143885

llvm-svn: 143884

llvm-svn: 143883

llvm-svn: 143882

llvm-svn: 143881

llvm-svn: 143880

 - Also, fix a refacto that left extra "all" component in list (this is now
   defined in the groups explicitly)

llvm-svn: 143879

llvm-svn: 143878

llvm-svn: 143877

Process::Wait on Windows (mimicing POSIX behaviour).

llvm-svn: 143876

aren't guaranteed to live long enough otherwise.

llvm-svn: 143875

detection system that is providing the library paths and crt object
files.

This, modulo any bugs that need to be shaken out, resolves numerous bugs
with how we handle header paths. Here are a few that I know of:
- We no longer need to enumerate all GCC versions searched.
- OpenSUSE searched GCC versions in the wrong order.
- There were typos when selecting various patterns, etc.
- We aren't stating quite some many directories now.
- SysRoot didn't always work in a reasonable way.

I'm working on tests for this, but the tests are making me and Lit sad.
The real testing for this type of driver change is to try it out on
various distributions. I'll hit the common ones right away, and start
more thorough testing tomorrow after some sleep.

llvm-svn: 143874

path triples. Also order the 32-bit triples a bit more reasonably.

llvm-svn: 143873

For some reason clang and msvc accept this, but gcc doesn't.

llvm-svn: 143872

the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.

llvm-svn: 143871

llvm-svn: 143870

This will facilitate further use and recombinations of them.

llvm-svn: 143869

"XFAIL: msys" has no effect, due to XFAIL inspects triplet, and msys build does not use *-msys-* but *-mingw32.

llvm-svn: 143868

property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions.  It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.

Most of the effort here is in dealing with the various
clients of the AST.  I've gone ahead and simplified the
ObjC rewriter's use of properties;  other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily.  Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.

I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.

llvm-svn: 143867

directories. This way we stop at the first multiarch directory found on
the system. This achieves the real intended result of pruning
non-existent directories.

llvm-svn: 143866

a better way. The more I think about it the more worried I am that this
hammer is simply too large. We should only be reaching out to the
filesystem when doing interesting "detection" things, not gratuitously.

Original commit message:
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.

The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.

llvm-svn: 143865

This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.

The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.

llvm-svn: 143864

path. That assumption should never have been true, but it was until
I fixed it. Now that its fixed, add a triple here to get correct
behavior even on Windows.

llvm-svn: 143863

Thanks to Chen Weiren.

llvm-svn: 143862

llvm-svn: 143861

llvm-svn: 143858

llvm-svn: 143857

llvm-svn: 143856

and prevent the diagnostic preprocessor run from writing a depfile.

llvm-svn: 143846

Thanks to Peter for pointing out how easy this is to do. I'm now much
happier with this solution.

llvm-svn: 143842

edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.

A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.

I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.

llvm-svn: 143841

variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.

llvm-svn: 143840

Michael!

llvm-svn: 143839