summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename eExecution*** to eExpression*** to be consistent with the result type.Jim Ingham2014-05-051-2/+2
| | | | llvm-svn: 207945
* Allow summary formatters to take ValueObjects into account when deciding ↵Enrico Granata2014-04-233-13/+13
| | | | | | | | 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/16540961>Enrico Granata2014-04-101-4/+2
| | | | | | | | The "unexpected value" message only matters to me, but is bound to make the experience more confusing for people when some uninitialized memory looks like an NSNumber and then can't be formatted properly, and that error comes out in the UI Just drop the error message entirely - nobody but me cares llvm-svn: 205978
* <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-043-6/+13
| | | | | | | 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
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+1
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* <rdar://problem/16424592>Enrico Granata2014-03-311-3/+1
| | | | | | | | For some reason, the libc++ vector<bool> data formatter was essentially a costly no-up, doing everything required of it, except actually generating the child values! This restores its functionality llvm-svn: 205259
* 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
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-038-18/+16
| | | | llvm-svn: 202723
* Better error reporting when a variable can't beSean Callanan2014-02-285-11/+53
| | | | | | | | | | | 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
* <rdar://problem/15593026>Enrico Granata2014-02-251-18/+30
| | | | | | Fix the algorithm used to detect a loop in a std::list llvm-svn: 202205
* <rdar://problem/16006373>Enrico Granata2014-02-151-9/+9
| | | | | | | Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before llvm-svn: 201455
* 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
* 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/15776874>Enrico Granata2014-01-271-3/+2
| | | | | | | | ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero. llvm-svn: 200247
* If a user specifies a format option to frame variable or expression, that ↵Enrico Granata2014-01-231-9/+9
| | | | | | | | format should prevail over whatever format(s) a summary specifies (see test case for an example) llvm-svn: 199857
* __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-082-2/+48
| | | | llvm-svn: 198724
* Add a new way to bind a format to a type: by enum typeEnrico Granata2013-12-282-6/+98
| | | | | | | | | | | 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
* Centralize the code for GetValueAsCString() in TypeFormatImpl (the ↵Enrico Granata2013-12-221-0/+88
| | | | | | | | | | | implementing class of "type format ...") TypeFormatImpl used to just wrap a Format (and Flags for matching), and then ValueObject itself would do the printing deed With this checkin, the responsibility of generating a value string is centralized in the data formatter (as it should, and already is for summaries) This change is good practice per se, and should also enable us to extend the type format mechanism in a cleaner way llvm-svn: 197874
* There is no need to use the expression parser to generate true and false - ↵Enrico Granata2013-12-211-11/+18
| | | | | | writing in a buffer is good enough llvm-svn: 197858
* All data formatters come in "match exact" and "match regex" stylesEnrico Granata2013-12-201-72/+68
| | | | | | This refactoring makes it less error-prone to define formatter types with the correct match schemes llvm-svn: 197800
* FormatNavigator has long stopped navigating anything - the generation of ↵Enrico Granata2013-12-203-137/+137
| | | | | | | | | 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-224-33/+163
| | | | | | | | | | | | | | | | | 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
* <rdar://problem/15449837>Enrico Granata2013-11-211-10/+60
| | | | | | | Change the NSSet data formatter to not use the expression parser to produce synthetic children In small-scale experimentation with lldb-perf, this improves our performance by around 25% llvm-svn: 195294
* This patch does a couple of things. Jim Ingham2013-11-074-28/+30
| | | | | | | | | | | | | | | | | | | | | | It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-046-11/+11
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-026-11/+11
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Further fixes to the dynamic type system prompted by ↵Enrico Granata2013-10-311-2/+1
| | | | | | ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command llvm-svn: 193818
* 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
* Improvements to the ValueObjectPrinter to behave correctly in more dynamic ↵Enrico Granata2013-10-221-8/+29
| | | | | | value cases llvm-svn: 193204
* 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-172-28/+90
| | | | | | 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-085-63/+204
| | | | | | | 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
* --raw was not always doing the right thing w.r.t. one-lining children. This ↵Enrico Granata2013-10-071-1/+1
| | | | | | checkin fixes that llvm-svn: 192116
* Cleaner way to work around the lack of delegating constructors on some ↵Enrico Granata2013-10-051-35/+32
| | | | | | versions of GCC llvm-svn: 192013
* <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-044-48/+136
| | | | | | | | | | | | | | | | | | | 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
* A more thorough fix for the newlines issueEnrico Granata2013-10-031-0/+2
| | | | llvm-svn: 191919
* <rdar://problem/15118409>Enrico Granata2013-10-031-2/+2
| | | | | | Fix an issue with the new ValueObjectPrinter where in some cases spurious \n would be printed llvm-svn: 191869
* Fix build with GCC 4.6.2 (non-c++11 compilant compiler)Daniel Malea2013-09-301-5/+16
| | | | | | - delegating c'tors not supported llvm-svn: 191709
OpenPOWER on IntegriCloud