Update comments, fix * placement, fix method names that are not
used in clang, add a linkInModule that takes a Mode and put it
in Linker.cpp.

llvm-svn: 181099

The linker is now responsible only for actually linking the modules, it
is up to the clients to create and destroy them.

llvm-svn: 181098

llvm-svn: 181097

llvm-svn: 181096

llvm-svn: 181095

llvm-svn: 181094

the list of Decls for a given DeclContext.  This
is useful for LLDB's implementation of
FindExternalLexicalDecls.

llvm-svn: 181093

llvm-svn: 181092

After recent OperatingsSystem plug-in changes, the lldb_private::Process and lldb_private::Thread subclasses were changed and the API was not respected properly.

This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.

These changes keep the lldb_private::Process subclasses clean and no changes are required.

llvm-svn: 181091

llvm-svn: 181090

conversion-type-id, in preparation for this becoming valid in c++1y mode.
No functionality change; small diagnostic improvement.

llvm-svn: 181089

[analyzer;alternate edges] start experimenting with control flow "barriers" to prevent an edge being optimized away.

llvm-svn: 181088

llvm-svn: 181087

llvm-svn: 181086

[analyzer; alternate edges] - merge control edges where we descend to a subexpression and pop back out.

llvm-svn: 181085

This change required some minor changes to LocationContextMap to have it map
from PathPieces to LocationContexts instead of PathDiagnosticCallPieces to
LocationContexts.  These changes are in the other diagnostic
generation logic as well, but are functionally equivalent.

Interestingly, this optimize requires delaying "cleanUpLocation()" until
later; possibly after all edges have been optimized.  This is because
we need PathDiagnosticLocations to refer to the semantic entity (e.g. a statement)
as long as possible.  Raw source locations tell us nothing about
the semantic relationship between two locations in a path.

llvm-svn: 181084

These were being dropped due a transcription mistake from the original
algorithm.

llvm-svn: 181083

llvm-svn: 181082

tags off by default for now. Move diagnostic code
to DiagnosticCommentKinds.td. // rdar://12381408

llvm-svn: 181081

Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().

llvm-svn: 181080

llvm-svn: 181079

UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string.  Updated callers to use the new method.

llvm-svn: 181078

llvm-svn: 181077

llvm-svn: 181076

This was causing a bunch of test cases to fail in python_api/process since they relied on SBValue::GetLocation()

llvm-svn: 181075

llvm-svn: 181074

Per discussion in cfe-commits, asserting may be a better way than introducing a special test flag.

llvm-svn: 181073

llvm-svn: 181072

commands. // rdar://12381408

llvm-svn: 181071

llvm-svn: 181070

llvm-svn: 181069

rdar://problem/13788593

llvm-svn: 181068

Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.

Fixes <rdar://problem/13663996>.

llvm-svn: 181067

llvm-svn: 181066

[Preprocessor] For the MacroExpands preprocessor callback, also pass the MacroArgs object that provides information about
the argument tokens for a function macro.

llvm-svn: 181065

Rename ObjCImplementationDecl::getSuperLoc() -> getSuperClassLoc() for consistency with ObjCInterfaceDecl::getSuperClassLoc()

llvm-svn: 181064

help performance -- if the FileSpec we're examining does not contain the
UUID we're looking for, don't bother examining the file any further.

llvm-svn: 181063

llvm-svn: 181062

Clear up any deadlocks on Apple builds that were due to the lldb_private::Process.m_private_run_lock variable. 

If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well.

llvm-svn: 181061

There isn't a speedup when using unbuffered I/O. It slows it down in fact.

llvm-svn: 181060