summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/FormatManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Nuke CXXFormatterFunctions.cpp - split the contents of it across different ↵Enrico Granata2015-09-041-2/+9
| | | | | | | | 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
* Move the functions that FormatManager uses to actually load formatters into ↵Enrico Granata2015-09-021-99/+2
| | | | | | | | 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 support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-12/+143
| | | | | | | | | | | | | | | | | 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-011-134/+16
| | | | | | 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-011-16/+134
| | | | | | | | | | | | | | | | | 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
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-4/+4
| | | | | | | | | | | | | | | | | | | | 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
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-8/+8
| | | | | | 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-111-2/+2
| | | | | | | | 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
* There is no reason why this formatter should not cascade. Make it cascadeEnrico Granata2015-07-281-1/+1
| | | | llvm-svn: 243369
* Add a summary for vector typesEnrico Granata2015-07-071-0/+20
| | | | | | | | | | | | 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
* 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-081-2/+2
| | | | | | 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-081-2/+2
| | | | | | | | | | | | | 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
* 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
* Remove unused #includes of ScriptInterpreterPython.hZachary Turner2015-05-281-1/+0
| | | | llvm-svn: 238470
* A few improvements to our vector types formatting story:Enrico Granata2015-03-061-11/+15
| | | | | | | | | - use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatting - special case a vector of char to display byte values instead of characters by default Fixes the test failures Ilia was seeing llvm-svn: 231504
* Provide synthetic children for some vector typesEnrico Granata2015-03-061-0/+9
| | | | | | | | | | Unlike GDB, we tackle the problem of representing vector types in different styles by having a synthetic child provider that recognizes the format you're trying to apply to the variable, and coming up with the right type and number of child values to match that format This makes for a more compact representation and less visual noise Fixes rdar://5429347 llvm-svn: 231449
* Add missing check for LLDB_DISABLE_PYTHON in FormatManagerTamas Berghammer2015-02-111-0/+2
| | | | llvm-svn: 228856
* Fix a couple typos in the previous commitEnrico Granata2015-02-101-0/+1
| | | | llvm-svn: 228762
* Add an LLDB summary for CMTime. Fixes rdar://15370376Enrico Granata2015-02-101-0/+19
| | | | llvm-svn: 228759
* Harden against the process pointer being null - this seems like it shouldn't ↵Enrico Granata2015-01-281-0/+2
| | | | | | | | happen, except it did - by a user stopping the debugger while the variables view was refreshing Fixes rdar://19599357 llvm-svn: 227350
* Remove the last vestige of the world before data formatters :-)Enrico Granata2014-12-101-0/+11
| | | | | | | | Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem This patch transitions that code into a hardcoded summary llvm-svn: 223906
* Move a bunch of summary formatters to oneliner mode. This makes more cases ↵Enrico Granata2014-11-111-25/+34
| | | | | | eligible for oneline printing, and fixes rdar://18120906 llvm-svn: 221701
* Shuffle a couple of formatters around. This should fix the bug that never ↵Enrico Granata2014-10-291-12/+10
| | | | | | dies, aka rdar://15154623 llvm-svn: 220836
* Reorganize some of the data formatters code to simplify ↵Enrico Granata2014-10-221-0/+1
| | | | | | CXXFormattersFunction.h. Also, add a synthetic child provider for libc++'s version of std::initializer_list<T> llvm-svn: 220421
* Add synthetic children support for NSIndexPathEnrico Granata2014-10-151-0/+2
| | | | llvm-svn: 219852
* If a ValueObject has a child that vends synthetic children, but only does so ↵Enrico Granata2014-10-091-2/+13
| | | | | | to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them llvm-svn: 219427
* Stop enabling the std::vector<bool> data formatter for libstdc++, and for ↵Enrico Granata2014-10-031-7/+0
| | | | | | that matter, also skip running the test on Darwin. libstdc++ is more relevant on non-Apple platforms llvm-svn: 218952
* Unused functions break the -Werror build. Revert for now.Enrico Granata2014-09-161-9/+0
| | | | llvm-svn: 217900
* Add a convenience function to FormatManager to setup an empty filter (one ↵Enrico Granata2014-09-161-0/+9
| | | | | | that suppresses all children, that is) llvm-svn: 217891
* When deciding if one-liner printing applies, and you find a summary, the ↵Enrico Granata2014-09-111-3/+2
| | | | | | summary is a good candidate to ask. While in theory one could want one-liner printing with a non-one-liner summary, I don't see LLDB as the best place to solve such inner conflicts llvm-svn: 217641
* Introduce the notion of a "type validator" formatterEnrico Granata2014-09-051-1/+88
| | | | | | | | | | Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
* Add __NSCFDictionary to the list of NSDictionary-like types for which we ↵Enrico Granata2014-08-271-0/+1
| | | | | | know to generate synthetic children llvm-svn: 216513
* Refactor the hardcoded formatters facility to use sequences of lambdas - ↵Enrico Granata2014-08-191-16/+55
| | | | | | still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
* Enable the data formatter for std::vector<bool> on libc++ again. In recent ↵Enrico Granata2014-08-161-0/+2
| | | | | | clang builds, we are vended a different typename, which the formatter needs to match against. llvm-svn: 215801
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-271-2/+2
| | | | | | | | Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
* Allow summary formatters to take ValueObjects into account when deciding ↵Enrico Granata2014-04-231-1/+1
| | | | | | | | whether values/children should be printed and if child names should be shown This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself llvm-svn: 207046
* <rdar://problem/12055586>Enrico Granata2014-04-101-3/+29
| | | | | | | | Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-3/+9
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-22/+0
| | | | | | | | | | | | | This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
* rdar://16361422Enrico Granata2014-03-201-0/+1
| | | | | | Add NSMutableData to the list of types that the NSData formatter knows to represent llvm-svn: 204289
* rdar://15648942Enrico Granata2014-02-071-0/+19
| | | | | | | Provide a filter for libc++ std::atomic<T> This just hides some implementation clutter and promotes the actual content to only child status llvm-svn: 200984
* <rdar://problem/15154623>Enrico Granata2014-02-031-3/+3
| | | | | | Move a couple formatters from category AppKit to CoreFoundation llvm-svn: 200713
* __CFString should also format as an NSStringEnrico Granata2014-01-081-0/+1
| | | | llvm-svn: 198727
* New and improved data formatter for std::shared_ptr<> and std::weak_ptr<>Enrico Granata2014-01-081-2/+3
| | | | llvm-svn: 198724
* Add a new way to bind a format to a type: by enum typeEnrico Granata2013-12-281-1/+1
| | | | | | | | | | | The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type, LLDB will display it as-if it was of enumeration type <sometype> This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type, but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges) The SB API has also been improved to handle both types of formats, and a test case is added llvm-svn: 198105
* FormatNavigator has long stopped navigating anything - the generation of ↵Enrico Granata2013-12-201-39/+39
| | | | | | | | | possible formatters matches is now done elsewhere So, rename the class for what it truly is: a FormattersContainer Also do a bunch of related text substitutions in the interest of overall naming clarity llvm-svn: 197795
OpenPOWER on IntegriCloud