and mark "clarifying memory allocation" as done, since it turns out that our
optimizations here (such as they are) already conform to the new rules.

llvm-svn: 181110

llvm-svn: 181109

Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.

llvm-svn: 181108

to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).

llvm-svn: 181107

to not let it update the thread list or else we'll infinite recurse
call back to UpdateThreadList.

llvm-svn: 181106

This takes the linking of almost all modules in a clang build from 6:32
to 0:19.

llvm-svn: 181105

Now that we hava a convinient place to keep it, remeber the set of
identified structs as we merge modules.

This speeds up the linking of all the bitcode files in clang with the
gold plugin and -plugin-opt=emit-llvm (i.e., link only, no codegen) from
5:25 minutes to 13.6 seconds!

Patch by Xiaofei Wan!

llvm-svn: 181104

llvm-svn: 181103

Flipping which one is the implementation will let us optimize linkInModule.

llvm-svn: 181102

- Sema tests added and CodeGen tests are pending

Differential Revision: http://llvm-reviews.chandlerc.com/D728

llvm-svn: 181101

Also remove unused includes.

llvm-svn: 181100

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