llvm-svn: 114189

use inside lldb (lldb_private::StreamFile, and lldb_private::StreamString).

llvm-svn: 114188

This mainly prevents failures and/or crashes when multiple processes try to read/write the same PCH file. (rdar://8392711&8294781); suggestion & review by Daniel!

llvm-svn: 114187

needs to find some libraries, which may require searching the directories given
by LIBRARY_PATH on curiously configured systems.  So pass on LIBRARY_PATH.

llvm-svn: 114186

llvm-svn: 114185

llvm-svn: 114184

llvm-svn: 114183

extension when missing LHS. This patch covers scalar
conditionals only. Others are wip.
(pr7726, radar 8353567).

llvm-svn: 114182

llvm-svn: 114176

It is also workaround for PR7927.

llvm-svn: 114175

the enclosing scope, which confuses gcc v3.4 to no end

llvm-svn: 114174

llvm-svn: 114173

ever use fallback.
 - Not necessary for clang as a compiler, but useful for testing purposes.

llvm-svn: 114172

Module. Patch by Mike Gist!

llvm-svn: 114171

llvm-svn: 114167

now that eprintf symbol issue is resolved.

llvm-svn: 114166

used on Darwin anymore, and Clang might not always link with the library it is
currently found in.

llvm-svn: 114165

toolchain.", while I investigate the totally non-surprising ensuing breakage.

llvm-svn: 114164

The Windows users will appreciate this.

llvm-svn: 114158

the bug I introduced to ClangASTContext is
resolved.

llvm-svn: 114157

llvm-svn: 114156

llvm-svn: 114155

expression to include the modifier.
 - Gross, but this a corner case we don't expect to see often in practice, but
   it is worth accepting.
 - Also improves diagnostics on invalid modifiers.

llvm-svn: 114154

the bases are completely initialized.  This won't work --- base
initializer expressions can rely on the vtables having been set up.
Check for uses of 'this' in the initializers and force a vtable
initialization if found.

This might not be good enough;  we might need to extend this to handle
the possibility of arbitrary code finding an external reference to this
(not yet completely-constructed!) object and accessing through it,
in which case we'll probably find ourselves doing a lot more unnecessary
stores.

llvm-svn: 114153

an ASTContext; also added a function to get the
Clang-style CVR qualifiers for a type as an
unsigned int.

llvm-svn: 114152

Reorganized it too.

llvm-svn: 114151

llvm-svn: 114149

so that it detects errors on platforms where libm doesn't set errno.
It's still subject to host libm details though.

llvm-svn: 114148

llvm-svn: 114147

the GCC dir. Unfortunately, this breaks -lstdc++ on SnowLeopard, etc. because
the libstdc++ dylib was hiding there. Workaround this by providing the path to
the right -lstdc++.6 (the only version used in recent memory) if we can't see an
obvious -lstdc++, but can find = -lstdc++.6.

llvm-svn: 114146

the cleanup might not be dominated by the allocation code.
In this case, we have to store aside all the delete arguments
in case we need them later.  There's room for optimization here
in cases where we end up not actually needing the cleanup in
different branches (or being able to pop it after the
initialization code).

Also make sure we only call this operator delete along the path
where we actually allocated something.

Fixes rdar://problem/8439196.

llvm-svn: 114145

-lstdc++. This is the best gross solution for a gross problem.

This issue is that historically, GCC has add -L options to its internally
library directories. This has allowed users and platforms to end up depending on
the layout of GCC's internal library directories.

We want to correct this mistake by eliminating that -L, but this means that
existing libraries which are in the GCC lib dir won't be found. We are going to
handle this by treating those -l names as "reserved", and requiring toolchains
to know how to add the right full path to the reserved library.

The immediately side effect of this is that users trying to use -L to find their
own -lstdc++ will need to start using -nostdlib (which is a good idea
anyway). Another side effect is that -stdlib=libc++ -lstdc++ will now do the
"right" thing, for curious definitions of right.

llvm-svn: 114144

llvm-svn: 114143

llvm-svn: 114142

because it was using Twine.h's declaration of operator<<(const Twine &).

llvm-svn: 114141

llvm-svn: 114140

LLVM libraries.

llvm-svn: 114139

llvm-svn: 114138

llvm-svn: 114137

prototype scope, temporarily set the context of the enumeration
declaration to the translation unit. We do the same thing for
parameters, until we have an actual function declaration on which to
hang them. Fixes <rdar://problem/8435682>.

There is more work to do in this area, since we have existing bugs
with tags being declared/defined in function parameter lists. This fix
is correct, and we'll end up extending it when we deal with those
existing bugs.

llvm-svn: 114135