summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/LibCxxUnorderedMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-041-172/+0
| | | | llvm-svn: 246873
* Nuke CXXFormatterFunctions.cpp - split the contents of it across different ↵Enrico Granata2015-09-041-1/+2
| | | | | | | | files, so that things are better organized along the C++/ObjC line This is preparatory work for moving these formatters into language categories llvm-svn: 246827
* Purge a few places where *LanguageRuntime.h was being used when it Jim Ingham2015-09-031-1/+0
| | | | | | wasn't needed. llvm-svn: 246744
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Reorganize some of the data formatters code to simplify ↵Enrico Granata2014-10-221-0/+35
| | | | | | CXXFormattersFunction.h. Also, add a synthetic child provider for libc++'s version of std::initializer_list<T> llvm-svn: 220421
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-1/+1
| | | | llvm-svn: 202723
* Better error reporting when a variable can't beSean Callanan2014-02-281-1/+4
| | | | | | | | | | | read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-1/+2
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* <rdar://problem/14071463>Enrico Granata2013-09-121-0/+135
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb This checkin converts that sample script to a C++ provider built into LLDB A test case is also provided llvm-svn: 190564
OpenPOWER on IntegriCloud