summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/FormatManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* <rdar://problem/15530080>Enrico Granata2013-11-221-0/+133
| | | | | | | | | | | | | | | | | Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395
* Renaming the setting to enable/disable automatic one-lining of summaries as ↵Enrico Granata2013-10-311-1/+1
| | | | | | auto-one-line-summaries llvm-svn: 193801
* This checkin introduces the notion of hardcoded formatters, which LLDB can ↵Enrico Granata2013-10-301-0/+39
| | | | | | | | | | | | bind to a ValueObject internally depending on any criteria User-vended by-type formatters still would prevail on these hardcoded ones For the time being, while the infrastructure is there, no such formatters exist This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it llvm-svn: 193724
* <rdar://problem/15143022>Enrico Granata2013-10-301-0/+1
| | | | | | | CFNumberRef is toll-free bridged to NSNumber We can use the same summary formatter for both types llvm-svn: 193666
* <rdar://problem/15319880>Enrico Granata2013-10-251-0/+4
| | | | | | | | | | Introduce a new boolean setting enable-auto-oneliner This setting if set to false will force LLDB to not use the new compact one-line display By default, one-line mode stays on, at least until we can be confident it works. But now if it seriously impedes your workflow while it evolves/it works wonders but you still hate it, there's a way to turn it off llvm-svn: 193450
* One should actually not do one-line printing of nested aggregates even if ↵Enrico Granata2013-10-231-11/+7
| | | | | | | | | | | | they are not the base class This check was overly strict. Relax it. While one could conceivably want nested one-lining: (Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14) the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact. Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :) llvm-svn: 193218
* Get rid of the FooStructSynth, it was a testing thing I put in and forgot to ↵Enrico Granata2013-10-211-11/+1
| | | | | | | | remove Hopefully nobody had a struct Foo in their app:-) llvm-svn: 193092
* Fix python-free build.Joerg Sonnenberger2013-10-201-0/+2
| | | | llvm-svn: 193053
* This is the last piece of work for "formats in categories": we now cache ↵Enrico Granata2013-10-171-27/+27
| | | | | | formats as well as summaries and synthetics llvm-svn: 192928
* <rdar://problem/15235492>Enrico Granata2013-10-151-0/+8
| | | | | | | | | Extend DummySyntheticProvider to actually use debug-info vended children as the source of information Make Python synthetic children either be valid, or fallback to the dummy, like their C++ counterparts This allows LLDB to actually stop bailing out upon encountering an invalid synthetic children provider front-end, and still displaying the non synthetized ivar info llvm-svn: 192741
* <rdar://problem/12632394>Enrico Granata2013-10-081-0/+21
| | | | | | | | Add a format for FourCharCode This is now safe to do thanks to the "formats in categories" feature llvm-svn: 192233
* <rdar://problem/11778815>Enrico Granata2013-10-081-1/+62
| | | | | | | Formats (as in "type format") are now included in categories The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable llvm-svn: 192217
* <rdar://problem/15154623>Enrico Granata2013-10-051-37/+37
| | | | | | | Several CF* data formatters were in the AppKit category This puts them back where they belong, i.e. in category CoreFoundation llvm-svn: 192008
* <rdar://problem/12042982>Enrico Granata2013-10-041-0/+60
| | | | | | | | | | | | | | | | | | | This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff: this ValueObject does not have a summary its children have no synthetic children its children are not a non-empty base class without a summary its children do not have a summary that asks for children to show up the aggregate length of all the names of all the children is <= 50 characters you did not ask to see the types during a printout your pointer depth is 0 This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?) Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be) llvm-svn: 191996
* <rdar://problem/14071463>Enrico Granata2013-09-121-1/+3
| | | | | | | | 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
* clean up about 22 warnings messagesMichael Sartain2013-08-071-4/+4
| | | | llvm-svn: 187900
* Adding a summary for ObjC blocksEnrico Granata2013-07-101-0/+7
| | | | llvm-svn: 186023
OpenPOWER on IntegriCloud