llvm-svn: 138257

llvm-svn: 138256

llvm-svn: 138255

 - FormatCategories now are directly mapped by ConstString objects instead of going through
   const char* -> ConstString -> const char*
 - FormatCategory callback does not pass category name anymore. This is not necessary because
   FormatCategory objects themselves hold their name as a member variable

llvm-svn: 138254

llvm-svn: 138253

llvm-svn: 138252

llvm-svn: 138251

llvm-svn: 138250

llvm-svn: 138249

a context switching object.

llvm-svn: 138248

llvm-svn: 138247

llvm-svn: 138246

llvm-svn: 138245

  If you have a Python module foo, in order to use its contained objects in LLDB you do not need to use
  'from foo import *'. You can use 'import foo', and then refer to items in foo as 'foo.bar', and LLDB
  will know how to resolve bar as a member of foo.
  Accordingly, GNU libstdc++ formatters have been moved from the global namespace to gnu_libstdcpp and a few
  test cases are also updated to reflect the new convention. Python docs suggest using a plain 'import' en lieu of
  'from-import'.

llvm-svn: 138244

llvm-svn: 138243

llvm-svn: 138242

llvm-svn: 138241

This matches gcc's logic. Half of PR10661.

llvm-svn: 138240

  const int &x = x;

This crashed by inifinetly recursing within the lvalue evaluation
routine. I've added a (somewhat) braindead way of preventing this
recursion. If folks have better suggestions for how to avoid it I'm all
ears.

That said, we have some work to do. This doesn't trigger a single
warning for uninitialized, self-initialized or otherwise completely
wrong code. In some senses, the crash was almost better.

llvm-svn: 138239

subject to change. Check for equality instead.

llvm-svn: 138238

llvm-svn: 138237

llvm-svn: 138236

llvm-svn: 138235

failures are resolved.

llvm-svn: 138234

llvm-svn: 138231

functionality into DEFINE_TRANSPARENT_OPERAND_ACCESSORS. A side-effect
of this is that the operand accessors for Constants will tolerate NULL
operands, fixing PR10663.

llvm-svn: 138230

plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable 
themselves when the right binary/target triple are being debugged. The 
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object 
pointer which can be inspected to see if the main executable, target triple,
or any shared  libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.

llvm-svn: 138228

llvm-svn: 138227

llvm-svn: 138226

Currently getMacroArgExpandedLocation is very inefficient and for the case
of a location pointing at the main file it will end up checking almost all of
the SLocEntries. Make it faster:

-Use a map of macro argument chunks to their expanded source location. The map
 is for a single source file, it's stored in the file's ContentCache and lazily
 computed, like the source lines cache.
-In SLocEntry's FileInfo add an 'unsigned NumCreatedFIDs' field that keeps track
 of the number of FileIDs (files and macros) that were created during preprocessing
 of that particular file SLocEntry. This is useful when computing the macro argument
 map in skipping included files while scanning for macro arg FileIDs that lexed from
 a specific source file. Due to padding, the new field does not increase the size
 of SLocEntry.

llvm-svn: 138225

[analyzer] Migrate the aliasing effects of CFRetain and CFMakeCollectable from CFRefCount to RetainReleaseChecker. No intended functionality change.

llvm-svn: 138223

[analyzer] Remove FIXME; Ted reminded me that -init is not guaranteed to return its receiver and pretending that it does won't actually buy us anything. (Comment change only.)

llvm-svn: 138221

[analyzer] Migrate return value handling from CFRefCount to ExprEngine. This seems to result in a minor performance hit, but I think that will go away again once we eliminate TransferFuncs from function calls entirely.

llvm-svn: 138220

I am planning to eliminate the TempScopInfo pass. To simplify this I remove
some features that may later be added to the ScopInfo pass.

The interchange pass is currently strongly tested and furthermore ment to be
replaced by the general scheduling optimizer. Reductions itself can later
be added easily.

llvm-svn: 138219

llvm-svn: 138215

llvm-svn: 138214

Patch by Aaron Ballman!

llvm-svn: 138213

[analyzer] RetainReleaseChecker always wants region change updates. There's no need for a flag, at least not right now.

llvm-svn: 138212

llvm-svn: 138211

[analyzer] Move handling of hardcoded noreturn ("panic") methods from CFRefCount to NoReturnFunctionChecker. No functionality change intended.

llvm-svn: 138210