This patch fixes LLDB data formatter support for llvm::Expected<T> with
the following changes:
llvm/utils/lldbDataFormatters.py: Fix ExpectedSynthProvider to handle
non-templated storage types (e.g., int, int*). Previously the formatter
only worked with templated storage types like std::reference_wrapper<T>.
cross-project-tests/lit.cfg.py:
Fix get_lldb_version_string() to use locally-built LLDB on non-Darwin
platforms instead of system LLDB
Fix minimum version from "1900" to "19.0.0" (typo in original code)
New test files: Added expected.cpp and expected.test to test the
formatter with Expected<int> and Expected<int*>.
---------
Co-authored-by: Jeffrey Tan <jeffreytan@fb.com>
Reverts a4cc033408fe0a69aad6865ddc7e020d64098f20.
Relanding the original patch as-is, but changing the `__builtin_debugtrap`s to explicitly set breakpoints. Some bots failed to compile the tests when `__builtin_debugtrap` was used.
Also adding `REQUIRES: lldb-formats-compatibility` to the test because some build-bots run the tests with an LLDB version that doesn't support the `FindDirectNestedType` API.
Original commit message:
This patch revives the llvm::PointerIntPair LLDB data-formatter. The previous version was commented out because it relied on expression evaluation and was hence slow/brittle. The formatter in this PR doesn't rely on evaluating expressions.
Drive-by change:
* removes the llvm::PointerUnion formatter which was also commented out. A future version of it will look very different than it does now, so there's no point in keeping it because the diff won't be helpful in a review.
Depends on:
* https://github.com/llvm/llvm-project/pull/173238
(only last commit relevant for review)
This patch revives the `llvm::PointerIntPair` LLDB data-formatter. The
previous version was commented out because it relied on expression
evaluation and was hence slow/brittle. The formatter in this PR doesn't
rely on evaluating expressions.
Drive-by change:
* removes the `llvm::PointerUnion` formatter which was also commented
out. A future version of it will look very different than it does now,
so there's no point in keeping it because the diff won't be helpful in a
review.
- check the length of data before casting as `char[N]` because the will
cause lldb to allocate `N` bytes of memory.
---------
Co-authored-by: Dave Lee <davelee.com@gmail.com>
Improve the `StringRef` summary formatter in the following ways:
* inherit adherence to the `target.max-string-summary-length` setting
* support non-printable bytes (such as null bytes, and any other binary data)
With the previous implementation, some non-printable bytes would raise a
Python exception.
Originally implemented in https://github.com/swiftlang/swift/pull/29014.
I've made a couple changes:
1. Use the target's address size, not lldb
2. Replaced the loop with a format string
Add a synthetic child provider for `DenseSet`, which is a wrapper around
`DenseMap`. This provider leverages the existing `DenseMap` provider,
reshaping its dictionary structured children into a set.
I just tried to load this into LLDB built against Python 3.8.5 and got
the following error: `TypeError: 'type' object is not subscriptable`. I
could fix this by wrapping the annotations in quotes but since Python
3.7 this syntax can be enabled with `from __future__ import
annotations`.
Fixes `SmallString` summary provider, which was incorrectly producing the empty string.
Initially I thought the strings I was debugging were empty for unknown reasons, but
that was not the case.
Instead of hard-coding the name `lldbDataFormatters`, use `__name__` to
get the module's name.
This allows the formatters to be loaded from any path, with any
filename.
Previously types such as `SmallVector<clang::Attr, 4> *` would
trigger the assertion inside the `SmallVector` formatter:
```
assert self.type_size != 0
```
This happens because `the_type.GetTemplateArgumentType(0)` returns
`None` (since `the_type` is a pointer to the `SmallVector`).
This patch dereferences `the_type` if it's a pointer type. We do this
for references already.
Differential Revision: https://reviews.llvm.org/D157961
Add summary and synthetic data formatters for `llvm::DenseMap`.
This implementation avoids expression evaluation by using a heuristic. However, as
heuristics go, there is a corner case: A single deleted entry (a single "tombstone"),
will result in a child value with an invalid key but a valid value.
Instead of calling `getEmptyKey()` and `getTombstoneKey()` to determine which buckets
are empty, and which contain real key-values, the heuristic scans all buckets to
identify keys that exist only once. These singleton keys are considered valid.
The empty key will always exist multiple times. However the tombstone key may exist
zero, one, or many times. The heuristic has no problems when there are zero or many
tombstones, but when there is exactly one deleted entry (one tombstone), then the
heuristic will incorrectly identify it as valid.
Differential Revision: https://reviews.llvm.org/D137028
When a type has a summary and synthetic child provider, the children are shown
only if `--expand`/`-e` is given.
This updates `lldbDataFormatters.py` to expand children of types that have both
a summary and synthetic children.
Differential Revision: https://reviews.llvm.org/D132095
Also, add summaries for `SmallVector` and `ArrayRef`,
and fix the `StringRef` summary provider so it doesn't
ignore the `Length` field.
Differential Revision: https://reviews.llvm.org/D117779
num_children is "last_index" + 1, thus
num_children + 1 = "last_index" + 2
this worked anyway because the index of `$$dereference$$` would work as long as
it was past the last index.
Add deref support to `llvm::Optional` in `lldbDataFormatters.py`.
This creates a synthetic provider that adds dereference support, but otherwise proxies all access to the underlying value.
With this change, an optional value can be displayed by running `v *someOptional`, and its contents can be accessed with the arrow `operator->`, for example `v someOpt->HasThing`. This matches expressions usable from expression evaluation.
See also D97165 and D97524.
Differential Revision: https://reviews.llvm.org/D97525
These data formatters make the string value appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.
Differential Revision: https://reviews.llvm.org/D66354
llvm-svn: 369175
SmallVector was changed to store a begin and a size rather than a
begin and an end a while back. Update the formatter to look at the
correct members.
llvm-svn: 346252
The llvm::Optional data formatter needs to look through the `Storage`
container if it's present.
Before:
220 if (Op && Op->getOp() != dwarf::DW_OP_LLVM_fragment)
-> 221 HasComplexExpression = true;
222
223 // If the register can only be described by a complex expression (i.e.,
224 // multiple subregisters) it doesn't safely compose with another complex
Target 0: (llc) stopped.
(lldb) p Op
(llvm::Optional<llvm::DIExpression::ExprOperand>) $0 = None
After:
(lldb) p Op
(llvm::Optional<llvm::DIExpression::ExprOperand>) $0 =
(llvm::DIExpression::ExprOperand) storage = {
Op = 0x000000010603d460
}
llvm-svn: 337752
This lets lldb give sane output for SmallVectors, e.g.
Before:
(lldb) p sv
(llvm::SmallVector<int, 10>) $0 = {
(llvm::SmallVectorImpl<int>) llvm::SmallVectorImpl<int> = {
(llvm::SmallVectorTemplateBase<int>) llvm::SmallVectorTemplateBase<int> = {
(llvm::SmallVectorTemplateCommon<int>) llvm::SmallVectorTemplateCommon<int> = {
(llvm::SmallVectorBase) llvm::SmallVectorBase = {
(void *) BeginX = 0x00007fff5fbff960
...
}
After:
(lldb) p sv
(llvm::SmallVector<int, 10>) $0 = {
(int) [0] = 42
(int) [1] = 23
...
}
The script is still a bit rough so expect crashes for vectors of complex types.
Synthetic children are _not_ available in xcode 4.2, newer LLDBs should work though.
llvm-svn: 148308
