Allow summary formatters to take ValueObjects into account when deciding whether values/children should be printed and if child names should be shown
This decision has always been statically-bound to

Allow summary formatters to take ValueObjects into account when deciding 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

show more ...

<rdar://problem/12055586>

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&&,

<rdar://problem/12055586>

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

show more ...

sweep up -Wformat warnings from gcc

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-

sweep up -Wformat warnings from gcc

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

show more ...

cleanup unreferenced functions

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

cleanup unreferenced functions

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

show more ...

rdar://16361422

Add NSMutableData to the list of types that the NSData formatter knows to represent

llvm-svn: 204289

rdar://15648942

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>

Move a couple formatters from category AppKit to CoreFoundation

llvm-svn: 200713

__CFString should also format as an NSString

llvm-svn: 198727

New and improved data formatter for std::shared_ptr<> and std::weak_ptr<>

llvm-svn: 198724

Add a new way to bind a format to a type: by enum type
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 w

Add a new way to bind a format to a type: by enum type
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

show more ...

FormatNavigator has long stopped navigating anything - the generation of possible formatters matches is now done elsewhere
So, rename the class for what it truly is: a FormattersContainer
Also do a b

FormatNavigator has long stopped navigating anything - the generation of 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

show more ...

<rdar://problem/15530080>

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

<rdar://problem/15530080>

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

show more ...

Renaming the setting to enable/disable automatic one-lining of summaries as auto-one-line-summaries

llvm-svn: 193801

This checkin introduces the notion of hardcoded formatters, which LLDB can bind to a ValueObject internally depending on any criteria
User-vended by-type formatters still would prevail on these hardc

This checkin introduces the notion of hardcoded formatters, which LLDB can 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

show more ...

<rdar://problem/15143022>

CFNumberRef is toll-free bridged to NSNumber
We can use the same summary formatter for both types

llvm-svn: 193666

<rdar://problem/15319880>

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 sta

<rdar://problem/15319880>

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

show more ...

One should actually not do one-line printing of nested aggregates even if they are not the base class
This check was overly strict. Relax it.
While one could conceivably want nested one-lining:
(Foo)

One should actually not do one-line printing of nested aggregates even if 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

show more ...

Get rid of the FooStructSynth, it was a testing thing I put in and forgot to remove
Hopefully nobody had a struct Foo in their app:-)

llvm-svn: 193092

Fix python-free build.

llvm-svn: 193053

This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics

llvm-svn: 192928

<rdar://problem/15235492>

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 dum

<rdar://problem/15235492>

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

show more ...

<rdar://problem/12632394>

Add a format for FourCharCode

This is now safe to do thanks to the "formats in categories" feature

llvm-svn: 192233

<rdar://problem/11778815>

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 desirab

<rdar://problem/11778815>

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

show more ...

<rdar://problem/15154623>

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>

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

<rdar://problem/12042982>

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

show more ...