Commit Graph

36 Commits

Author SHA1 Message Date
Enrico Granata 520a422bd8 Add a --element-count option to the expression command
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements

This has a couple subtle points but is mostly as straightforward as it sounds

Add a parray N <expr> alias for this new mode

Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this

llvm-svn: 267372
2016-04-25 00:52:47 +00:00
Enrico Granata 7aafb6a1d5 Fix a bug where one-lining display of child values would ignore the user's choice of format
llvm-svn: 254349
2015-12-01 00:04:52 +00:00
Enrico Granata 608d67c152 Introduce a way for Languages to specify whether values of "reference types" are "nil" (not pointing to anything) or uninitialized (never made to point at anything)
This latter determination may or may not be possible on a per-language basis; and neither is mandatory to implement for any language

Use this knowledge in the ValueObjectPrinter to generalize the notion of IsObjCNil() and the respective printout

llvm-svn: 252663
2015-11-10 22:39:15 +00:00
Enrico Granata 8cf44d9684 Upstream changes to the ValueObjectPrinter; nfc
llvm-svn: 252638
2015-11-10 19:07:58 +00:00
Greg Clayton 26014690aa All instance variables start with "m_". Fix "options" to be "m_options".
llvm-svn: 252013
2015-11-03 23:23:59 +00:00
Enrico Granata c8e7649a19 Let Language plugins vend a default DeclPrintingHelper in case a custom one is not specified for the specific invocation
llvm-svn: 250744
2015-10-19 22:04:25 +00:00
Enrico Granata e0ee1e1cd6 Teach an old pony a few new tricks.
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
2015-10-17 01:05:50 +00:00
Enrico Granata 73e8c4d09c Route the preferred-display-language mechanism to the ValueObjectPrinter and actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways
llvm-svn: 249507
2015-10-07 02:36:35 +00:00
Bruce Mitchener 59b5a37db0 DataFormatters: Rename clang_type to compiler_type.
Reviewers: granata.enrico

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D12930

llvm-svn: 247915
2015-09-17 18:43:40 +00:00
Zachary Turner 84f5b0df8e Fix some compiler warnings.
llvm-svn: 247164
2015-09-09 17:25:43 +00:00
Greg Clayton 99558cc424 Final bit of type system cleanup that abstracts declaration contexts into 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
2015-08-24 23:46:31 +00:00
Enrico Granata c1b7c09ac4 Add a more tweakable way for ValueObjectPrinter to control pointer expansion. NFC.
llvm-svn: 243301
2015-07-27 18:34:14 +00:00
Siva Chandra d26eb907bc Add option eTypeOptionHideEmptyAggregates.
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
2015-07-24 21:30:58 +00:00
Enrico Granata 443844c474 Revert r239873 - I actually want to think some more about this
llvm-svn: 239874
2015-06-17 02:11:48 +00:00
Enrico Granata ca201238ae Fix an issue where the oneliner printing of variables would ignore custom formatting
Because vector types use their formats in special ways (i.e. children get generated based on them), this change by itself would cause a regression in printing vector types with some custom formats
Work around that issue by special casing vector types out of this format-passdown mode. I believe there is a more general feature to be designed in this space, but until I see more cases of interest, I am going to leave this as a special case

Fixes rdar://20810062

llvm-svn: 239873
2015-06-17 02:06:24 +00:00
Enrico Granata d595733617 Fix a bug where trying to Dump() a ValueObject would use the static/non-synthetic version of the value even if the ValueObject one actually called Dump() on turned out to be dynamic and/or synthetic
This was of course overridable by using DumpValueObjectOptions, but the default should be saner and the previous behavior made for a few fun investigations....

rdar://problem/21065149

llvm-svn: 238961
2015-06-03 20:43:54 +00:00
Enrico Granata 3fa6dc904a Fix an issue where values would be printed in one-line mode even if you asked to see locations and/or asked for flat output mode
llvm-svn: 232113
2015-03-12 22:16:20 +00:00
Enrico Granata a126e462c2 Do some cleanup of DumpValueObjectOptions. The whole concept of raw printing was split between feature-specific flags, and an m_be_raw flag, which then drove some other changes in printing behavior. Clean that up, so that each functionality has its own flag .. oh, and make the bools all go in a bitfield since I may want to add more of those over time
llvm-svn: 222548
2014-11-21 18:47:26 +00:00
Enrico Granata 622be238eb Expose the type-info flags at the public API layer. These flags provide much more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593
llvm-svn: 220322
2014-10-21 20:52:14 +00:00
Enrico Granata ddac7611ee If a ValueObject has a child that vends synthetic children, but only does so 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
2014-10-09 18:47:36 +00:00
Enrico Granata d07cfd3ae4 Extend synthetic children to produce synthetic values (as in, those that GetValueAsUnsigned(), GetValueAsCString() would return)
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value

The rationale for doing things this way is twofold:

- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature

Comes with a test case

llvm-svn: 219330
2014-10-08 18:27:36 +00:00
Enrico Granata 0f883ffbdb Add a -V <bool> flag to frame variable/expression that enables execution of type validators. The jury is still out on what the user experience of type validators should be, so for now gate it on a specific flag. The mode I am using is prefix variables that fail to validate with a bang, and then emitting the actual validation error on a separate line. Of course, given the total absence of validators, this should never actually happen to you
llvm-svn: 217303
2014-09-06 02:20:19 +00:00
Enrico Granata e8daa2f843 Introduce the concept of a "display name" for types
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
2014-05-17 19:14:17 +00:00
Enrico Granata 8a068e6c43 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
2014-04-23 23:16:25 +00:00
Enrico Granata 465f4bc287 <rdar://problem/16006373>
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
2014-02-15 01:24:44 +00:00
Enrico Granata 5000ee16f6 <rdar://problem/15776874>
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
2014-01-27 21:31:26 +00:00
Enrico Granata 90890bba04 If a user specifies a format option to frame variable or expression, that format should prevail over whatever format(s) a summary specifies
(see test case for an example)

llvm-svn: 199857
2014-01-23 01:21:18 +00:00
Enrico Granata fcf0c4e31a Further fixes to the dynamic type system prompted by ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command
llvm-svn: 193818
2013-10-31 22:42:00 +00:00
Enrico Granata 106260c574 Improvements to the ValueObjectPrinter to behave correctly in more dynamic value cases
llvm-svn: 193204
2013-10-22 22:42:14 +00:00
Enrico Granata 41b1653350 --raw was not always doing the right thing w.r.t. one-lining children. This checkin fixes that
llvm-svn: 192116
2013-10-07 17:59:03 +00:00
Enrico Granata 938d1d67e8 Cleaner way to work around the lack of delegating constructors on some versions of GCC
llvm-svn: 192013
2013-10-05 00:20:27 +00:00
Enrico Granata a29cb0bada <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
2013-10-04 23:14:13 +00:00
Enrico Granata 245b3caa57 A more thorough fix for the newlines issue
llvm-svn: 191919
2013-10-03 18:11:24 +00:00
Enrico Granata 39938938cf <rdar://problem/15118409>
Fix an issue with the new ValueObjectPrinter where in some cases spurious \n would be printed

llvm-svn: 191869
2013-10-03 02:06:02 +00:00
Daniel Malea 73435afda7 Fix build with GCC 4.6.2 (non-c++11 compilant compiler)
- delegating c'tors not supported

llvm-svn: 191709
2013-09-30 23:12:05 +00:00
Enrico Granata 4d93b8cdf3 <rdar://problem/14393032>
DumpValueObject() 2.0

This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
 When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
    1 = 2;
    2 = 3;
}

 When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
    1 = 2;
    2 = 3;
}

- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5 

On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed

Test case to follow

llvm-svn: 191694
2013-09-30 19:11:51 +00:00