summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
...
* Teach an old pony a few new tricks.Enrico Granata2015-10-171-25/+81
| | | | | | | | ValueObjectPrinter can now mask out pointer values during a printout; also, it supports helper functions to print declarations in different formats if needed Practically speaking however, this change is NFC as nothing yet uses it in the codebase llvm-svn: 250599
* Move TypeSummaryImpl over to LLVM-style RTTI for subclassingEnrico Granata2015-10-161-8/+10
| | | | llvm-svn: 250567
* Resubmit: RenderScript command for printing allocation contents Ewan Crawford2015-10-161-0/+2
| | | | | | | | | Previous commit r250281 broke TestDataFormatterSmartArray.py Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager. Differential Revision: http://reviews.llvm.org/D13730 llvm-svn: 250499
* Fix build with python disabled after r249597Keno Fischer2015-10-161-5/+0
| | | | | | | | | | | | | | | Summary: r249597 introduced a usage of GetTypeSummary in lldb-mi. That function used to only be available when python is enabled. However, there is no reason for that anymore since that is now dealt with at a different abstraction layer. Reviewers: ki.stfu, evgeny777, clayborg, granata.enrico Subscribers: elehcim, brucem, lldb-commits Differential Revision: http://reviews.llvm.org/D13577 llvm-svn: 250494
* Route the preferred-display-language mechanism to the ValueObjectPrinter and ↵Enrico Granata2015-10-071-2/+3
| | | | | | actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways llvm-svn: 249507
* Enable the StringPrinter to have prefixes that are strings instead of just a ↵Enrico Granata2015-10-071-5/+12
| | | | | | single character; and also introduce a comparable suffix mechanism llvm-svn: 249506
* Introduce a variant of GetSummaryAsCString() that takes a LanguageType ↵Enrico Granata2015-10-071-2/+5
| | | | | | | | argument, and use it when crafting summaries by running selectors This is the first in a series of commits that are meant to teach LLDB how to properly handle multi-language formatting of values llvm-svn: 249503
* Create a logging category that is specific to data formatters activityEnrico Granata2015-10-062-8/+8
| | | | llvm-svn: 249433
* Introduce a FormattersMatchData class which contains all the information ↵Enrico Granata2015-10-064-150/+177
| | | | | | | | that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
* Made GetScratchTypeSystemForLanguage return an error if desired.Sean Callanan2015-10-021-1/+1
| | | | | | | Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
* Fix evaluation of unicode character arrays (char16_t[] and char32_t[])Dawn Perchik2015-09-251-0/+13
| | | | | | | | | | | | | | | | Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
* Fix covered-switch-default warning in FormatManager.Bruce Mitchener2015-09-231-1/+0
| | | | | | | | | | | | | | | | Summary: The default case doesn't need to be here as the switch covers all possible values. If there's a new "lazy bool" value added in the future, the compiler would start to warn about the new case not being covered. Reviewers: granata.enrico, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13084 llvm-svn: 248365
* Allow CompilerType to express a vote on whether oneliner printing should happenEnrico Granata2015-09-231-0/+17
| | | | llvm-svn: 248363
* Add {TypeSystem|CompilerType}::GetTypeForFormatters()Enrico Granata2015-09-231-1/+1
| | | | | | | | | Different type system may have different notions of attributes of a type that do not matter for data formatters matching purposes For instance, in the case of clang types, we remove some qualifiers (e.g. "volatile") as it doesn't make much sense to differentiate volatile T from T in the data formatters This new API allows each type system to generate, if needed, a type that does not have those unwanted attributes that the data formatters can then consume to generate matches llvm-svn: 248359
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-172-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
* DataFormatters: Rename clang_type to compiler_type.Bruce Mitchener2015-09-173-21/+21
| | | | | | | | | | Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
* Add the ability for formatter categories to be bound to one or more languagesEnrico Granata2015-09-175-14/+164
| | | | | | What that does is it restricts formatters in those categories to only match to types coming from "compatible" source languages llvm-svn: 247872
* 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
OpenPOWER on IntegriCloud