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
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
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
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
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
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
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
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
Tamas Berghammer
Enrico Granata
Saleem Abdulrasool