Introduce a TypeSystem interface to support adding non-clang languages.

Reviewers: clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D8712
Or

Introduce a TypeSystem interface to support adding non-clang languages.

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

show more ...

Don't #include "lldb-python.h" from anywhere.

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,

Don't #include "lldb-python.h" from anywhere.

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

show more ...

Remove unused #includes of ScriptInterpreterPython.h

llvm-svn: 238470

A few improvements to our vector types formatting story:
- use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatt

A few improvements to our vector types formatting story:
- 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

show more ...

Provide synthetic children for some vector types

Unlike GDB, we tackle the problem of representing vector types in different styles by having a synthetic child provider that recognizes the format yo

Provide synthetic children for some vector types

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

show more ...

Add missing check for LLDB_DISABLE_PYTHON in FormatManager

llvm-svn: 228856

Fix a couple typos in the previous commit

llvm-svn: 228762

Add an LLDB summary for CMTime. Fixes rdar://15370376

llvm-svn: 228759

Harden against the process pointer being null - this seems like it shouldn't happen, except it did - by a user stopping the debugger while the variables view was refreshing

Fixes rdar://19599357

ll

Harden against the process pointer being null - this seems like it shouldn't happen, except it did - by a user stopping the debugger while the variables view was refreshing

Fixes rdar://19599357

llvm-svn: 227350

show more ...

Remove the last vestige of the world before data formatters :-)
Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem

This patch tran

Remove the last vestige of the world before data formatters :-)
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

show more ...

Move a bunch of summary formatters to oneliner mode. This makes more cases eligible for oneline printing, and fixes rdar://18120906

llvm-svn: 221701

Shuffle a couple of formatters around. This should fix the bug that never dies, aka rdar://15154623

llvm-svn: 220836

Reorganize some of the data formatters code to simplify 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 NSIndexPath

llvm-svn: 219852

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 availabl

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

show more ...

Stop enabling the std::vector<bool> data formatter for libstdc++, and for 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.

llvm-svn: 217900

Add a convenience function to FormatManager to setup an empty filter (one that suppresses all children, that is)

llvm-svn: 217891

When deciding if one-liner printing applies, and you find a summary, the 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 se

When deciding if one-liner printing applies, and you find a summary, the 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

show more ...

Introduce the notion of a "type validator" formatter

Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's content

Introduce the notion of a "type validator" formatter

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

show more ...

Add __NSCFDictionary to the list of NSDictionary-like types for which we know to generate synthetic children

llvm-svn: 216513

Refactor the hardcoded formatters facility to use sequences of lambdas - still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type

Refactor the hardcoded formatters facility to use sequences of lambdas - 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

show more ...

Enable the data formatter for std::vector<bool> on libc++ again. In recent clang builds, we are vended a different typename, which the formatter needs to match against.

llvm-svn: 215801

lldb: remove adhoc implementation of array_sizeof

Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional

lldb: remove adhoc implementation of array_sizeof

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

show more ...

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 car

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

show more ...