summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
...
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-162-98/+158
| | | | llvm-svn: 247831
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* Move Objective-C data formatters to the Objective-C language plugin where ↵Enrico Granata2015-09-1410-4335/+10
| | | | | | they belong llvm-svn: 247627
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-093-41/+83
| | | | | | | | notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
* Preparatory work for letting language plugins help the StringPrinter with ↵Enrico Granata2015-09-092-105/+22
| | | | | | formatting special characters llvm-svn: 247189
* Fix some compiler warnings.Zachary Turner2015-09-091-0/+2
| | | | llvm-svn: 247164
* Data formatter candidate matches can be generated in a number of ways; ↵Enrico Granata2015-09-091-31/+12
| | | | | | | | | | language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter) This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables llvm-svn: 247112
* Implement a Target::GetTypeSystemForLanguage API, as well as provide helpers ↵Enrico Granata2015-09-082-32/+35
| | | | | | on the TypeSystem to get numeric types of specific sizes and signedness llvm-svn: 247082
* Use LLVM casting for TypeSystem so you can cast it to subclasses.Greg Clayton2015-09-084-14/+19
| | | | | | | | | | | | | | This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like: class TypeSystem { virtual ClangASTContext * AsClangASTContext() = 0; } As you can now just use the llvm::dyn_cast and other casts. llvm-svn: 247041
* Add a --language (-l) option to type category {enable|disable} to allow ↵Enrico Granata2015-09-041-0/+14
| | | | | | people to turn on and off formatters for a given language llvm-svn: 246884
* Never mind, I see what the problem is on the Windows build. Attempt a fixEnrico Granata2015-09-041-1/+2
| | | | llvm-svn: 246876
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-0412-2594/+61
| | | | llvm-svn: 246873
* Nuke CXXFormatterFunctions.cpp - split the contents of it across different ↵Enrico Granata2015-09-0421-300/+331
| | | | | | | | 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
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Fix cmake build.Bruce Mitchener2015-09-031-0/+1
| | | | llvm-svn: 246746
* Purge a few places where *LanguageRuntime.h was being used when it Jim Ingham2015-09-035-5/+0
| | | | | | wasn't needed. llvm-svn: 246744
* CXXFormatterFunctions.{h|cpp} is not a good thing to have around, so start ↵Enrico Granata2015-09-035-988/+1033
| | | | | | splitting stuff in different files in preparation for removing it and factoring formatters to the plugins where they belong llvm-svn: 246743
* Move the functions that FormatManager uses to actually load formatters into ↵Enrico Granata2015-09-023-99/+123
| | | | | | | | their own file These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things llvm-svn: 246612
* std::initializer_list is not safe to return from a function, as copies are ↵Enrico Granata2015-09-011-1/+1
| | | | | | not guaranteed to extend the lifetime of the underlying storage llvm-svn: 246597
* Add logging to a couple of regions of codeEnrico Granata2015-09-011-0/+52
| | | | llvm-svn: 246580
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-014-24/+285
| | | | | | | | | | | | | | | | | Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
* Revert "Add support for language plugins to provide data formatters"Pavel Labath2015-09-014-276/+28
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* Add support for language plugins to provide data formattersEnrico Granata2015-09-014-28/+276
| | | | | | | | | | | | | | | | | Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246515
* Switch data formatters over to using std::function for their callbacks ↵Enrico Granata2015-08-272-5/+4
| | | | | | instead of raw function pointers. NFC llvm-svn: 246130
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-2417-43/+42
| | | | | | | | | | | | | | | | | | | | 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
* Convert GetNumTemplateArguments() and GetTemplateArgument() to be instance ↵Enrico Granata2015-08-133-5/+5
| | | | | | functions on the CompilerType and the TypeSystem llvm-svn: 244846
* ClangASTType is now CompilerType.Greg Clayton2015-08-1115-54/+54
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-1111-19/+25
| | | | | | | | This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
* Fix a bug where the std::list synthetic child provider would not clean its ↵Enrico Granata2015-07-281-0/+1
| | | | | | | | cache correctly on update, causing stale children to be returned in some circumstances Fixes rdar://20560680 llvm-svn: 243472
* There is no reason why this formatter should not cascade. Make it cascadeEnrico Granata2015-07-281-1/+1
| | | | llvm-svn: 243369
* Add a more tweakable way for ValueObjectPrinter to control pointer ↵Enrico Granata2015-07-271-15/+56
| | | | | | expansion. NFC. llvm-svn: 243301
* Add option eTypeOptionHideEmptyAggregates.Siva Chandra2015-07-241-1/+12
| | | | | | | | | | | | | | | | | | Summary: For certain data structures, when the synthetic child provider returns zero children, a summary like "Empty instance of <typename>" could be more appropriate than something like "size=0 {}". This new option helps hide the trailing "{}". This is also exposed with a -h option for the command "type summary add". Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11473 llvm-svn: 243166
* Remove a static helper function and use the StringPrinter API exclusively to ↵Enrico Granata2015-07-171-43/+10
| | | | | | format NSStrings llvm-svn: 242583
* Teach the "extend char types" (char16_t, char32_t and wchar_t) formatters ↵Enrico Granata2015-07-171-0/+3
| | | | | | that a *single character* whose value is 0 is actually a valid thing to print out llvm-svn: 242572
* Teach the NSString data formatter to handle embedded NULs in short ASCII stringsEnrico Granata2015-07-171-1/+16
| | | | llvm-svn: 242559
* Improve the NSString data formatter so that explicitly-lengthed Unicode ↵Enrico Granata2015-07-171-4/+8
| | | | | | strings print embedded NULs correctly llvm-svn: 242555
* Teach the std::wstring data formatter how to properly display strings with ↵Enrico Granata2015-07-172-3/+41
| | | | | | embedded NUL bytes llvm-svn: 242501
* Add StringPrinter support for printing a std::string with embedded NUL bytesEnrico Granata2015-07-172-36/+56
| | | | llvm-svn: 242496
* Add a summary for vector typesEnrico Granata2015-07-072-1/+67
| | | | | | | | | | | | The summary is - quite simply - a one-line printout of the vector elements We still need synthetic children: a) as a source of the elements to print in the summary b) for graphical IDEs that display structure regardless of the summary settings rdar://5429347 llvm-svn: 241531
* When I introduced hard-coded formatters, I made them non-cacheableEnrico Granata2015-07-011-5/+9
| | | | | | | | | This is because - in theory - the formatter could match on not just the type, but also other properties of a ValueObject, so a per-type caching would not be a good thing On the other hand, that is not always true - sometimes the matching truly is per-type So, introduce a non-cacheable attribute on formatters that decides whether a formatter should or should not be cached. That way, the few formatters that don't want themselves cached can do so, but most formatters (including most hard-coded ones) can cache themselves just fine llvm-svn: 241184
* Revert r239873 - I actually want to think some more about thisEnrico Granata2015-06-171-16/+2
| | | | llvm-svn: 239874
* Fix an issue where the oneliner printing of variables would ignore custom ↵Enrico Granata2015-06-171-2/+16
| | | | | | | | | | | formatting Because vector types use their formats in special ways (i.e. children get generated based on them), this change by itself would cause a regression in printing vector types with some custom formats Work around that issue by special casing vector types out of this format-passdown mode. I believe there is a more general feature to be designed in this space, but until I see more cases of interest, I am going to leave this as a special case Fixes rdar://20810062 llvm-svn: 239873
* Fixing a potential issue where the NSIndexPath formatter could try to access ↵Enrico Granata2015-06-161-95/+124
| | | | | | | | stale data No test because I did not see this happen - it has been found by code inspection as a response to seeing crash logs about this llvm-svn: 239851
* Add a formatter for wchar_t[N] arraysEnrico Granata2015-06-151-7/+12
| | | | | | rdar://21299888 llvm-svn: 239777
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-0811-25/+19
| | | | | | This seems to break expression evaluation on the linux build. llvm-svn: 239366
* Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath2015-06-0811-19/+25
| | | | | | | | | | | | | Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8712 Original Author: Ryan Brown <ribrdb@google.com> llvm-svn: 239360
* Fix a bug where trying to Dump() a ValueObject would use the ↵Enrico Granata2015-06-031-0/+22
| | | | | | | | | | static/non-synthetic version of the value even if the ValueObject one actually called Dump() on turned out to be dynamic and/or synthetic This was of course overridable by using DumpValueObjectOptions, but the default should be saner and the previous behavior made for a few fun investigations.... rdar://problem/21065149 llvm-svn: 238961
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-2921-42/+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
* Remove unused #includes of ScriptInterpreterPython.hZachary Turner2015-05-282-2/+1
| | | | llvm-svn: 238470
* Fixed a ton of gcc compile warningsVince Harron2015-05-131-15/+15
| | | | | | | | | | Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
OpenPOWER on IntegriCloud