summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters/ValueObjectPrinter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-111-38/+0
| | | | | | | | This is a half-implemented feature that as far as we can tell was never used by anything since its original inclusion in 2014. This patch removes it to make remaining the code easier to understand. Differential Revision: https://reviews.llvm.org/D71310
* [NFC] Simplify codeJonas Devlieghere2019-08-211-17/+13
| | | | | | This simplifies the code and updates the comments. llvm-svn: 369491
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-6/+6
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-28/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Don't add a newline if the object description already has one.Jim Ingham2017-03-311-1/+6
| | | | | | <rdar://problem/25755431> llvm-svn: 299147
* Remove some dead code from DumpValueObjectOptions::PointerDepthTamas Berghammer2017-03-181-24/+2
| | | | llvm-svn: 298189
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-7/+6
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Simplify the PrintableRepresentationSpecialCases code; we never used the ↵Enrico Granata2016-11-071-1/+1
| | | | | | ePrintableRepresentationSpecialCasesOnly value and with enum classes the names doesn't need to be that long llvm-svn: 286176
* Preliminary plumbing work to make 'parray' able to take offset and stride ↵Enrico Granata2016-11-041-10/+19
| | | | | | options llvm-svn: 286003
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-882/+755
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Add a --element-count option to the expression commandEnrico Granata2016-04-251-11/+39
| | | | | | | | | | | | | 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
* Fix a bug where one-lining display of child values would ignore the user's ↵Enrico Granata2015-12-011-1/+1
| | | | | | choice of format llvm-svn: 254349
* Introduce a way for Languages to specify whether values of "reference types" ↵Enrico Granata2015-11-101-7/+22
| | | | | | | | | | 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
* Upstream changes to the ValueObjectPrinter; nfcEnrico Granata2015-11-101-24/+119
| | | | llvm-svn: 252638
* All instance variables start with "m_". Fix "options" to be "m_options".Greg Clayton2015-11-031-56/+56
| | | | llvm-svn: 252013
* Let Language plugins vend a default DeclPrintingHelper in case a custom one ↵Enrico Granata2015-10-191-11/+16
| | | | | | is not specified for the specific invocation llvm-svn: 250744
* Teach an old pony a few new tricks.Enrico Granata2015-10-171-25/+81
| | | | | | | | 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
* Route the preferred-display-language mechanism to the ValueObjectPrinter and ↵Enrico Granata2015-10-071-2/+3
| | | | | | actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways llvm-svn: 249507
* DataFormatters: Rename clang_type to compiler_type.Bruce Mitchener2015-09-171-2/+2
| | | | | | | | | | Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12930 llvm-svn: 247915
* Fix some compiler warnings.Zachary Turner2015-09-091-0/+2
| | | | llvm-svn: 247164
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Add a more tweakable way for ValueObjectPrinter to control pointer ↵Enrico Granata2015-07-271-15/+56
| | | | | | expansion. NFC. llvm-svn: 243301
* Add option eTypeOptionHideEmptyAggregates.Siva Chandra2015-07-241-1/+12
| | | | | | | | | | | | | | | | | | 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
* Revert r239873 - I actually want to think some more about thisEnrico Granata2015-06-171-16/+2
| | | | llvm-svn: 239874
* Fix an issue where the oneliner printing of variables would ignore custom ↵Enrico Granata2015-06-171-2/+16
| | | | | | | | | | | 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
* Fix a bug where trying to Dump() a ValueObject would use the ↵Enrico Granata2015-06-031-0/+22
| | | | | | | | | | 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
* Fix an issue where values would be printed in one-line mode even if you ↵Enrico Granata2015-03-121-1/+5
| | | | | | asked to see locations and/or asked for flat output mode llvm-svn: 232113
* Do some cleanup of DumpValueObjectOptions. The whole concept of raw printing ↵Enrico Granata2014-11-211-7/+7
| | | | | | 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
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-211-4/+4
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* If a ValueObject has a child that vends synthetic children, but only does so ↵Enrico Granata2014-10-091-3/+2
| | | | | | 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
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-6/+30
| | | | | | | | | | | | | | | | | 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
* Add a -V <bool> flag to frame variable/expression that enables execution of ↵Enrico Granata2014-09-061-0/+45
| | | | | | 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
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | 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
* Allow summary formatters to take ValueObjects into account when deciding ↵Enrico Granata2014-04-231-2/+2
| | | | | | | | 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
* <rdar://problem/16006373>Enrico Granata2014-02-151-9/+9
| | | | | | | 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
* <rdar://problem/15776874>Enrico Granata2014-01-271-3/+2
| | | | | | | | 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
* If a user specifies a format option to frame variable or expression, that ↵Enrico Granata2014-01-231-9/+9
| | | | | | | | format should prevail over whatever format(s) a summary specifies (see test case for an example) llvm-svn: 199857
* Further fixes to the dynamic type system prompted by ↵Enrico Granata2013-10-311-2/+1
| | | | | | ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command llvm-svn: 193818
* Improvements to the ValueObjectPrinter to behave correctly in more dynamic ↵Enrico Granata2013-10-221-8/+29
| | | | | | value cases llvm-svn: 193204
* --raw was not always doing the right thing w.r.t. one-lining children. This ↵Enrico Granata2013-10-071-1/+1
| | | | | | checkin fixes that llvm-svn: 192116
* Cleaner way to work around the lack of delegating constructors on some ↵Enrico Granata2013-10-051-35/+32
| | | | | | versions of GCC llvm-svn: 192013
* <rdar://problem/12042982>Enrico Granata2013-10-041-1/+61
| | | | | | | | | | | | | | | | | | | 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
* A more thorough fix for the newlines issueEnrico Granata2013-10-031-0/+2
| | | | llvm-svn: 191919
* <rdar://problem/15118409>Enrico Granata2013-10-031-2/+2
| | | | | | Fix an issue with the new ValueObjectPrinter where in some cases spurious \n would be printed llvm-svn: 191869
* Fix build with GCC 4.6.2 (non-c++11 compilant compiler)Daniel Malea2013-09-301-5/+16
| | | | | | - delegating c'tors not supported llvm-svn: 191709
* <rdar://problem/14393032>Enrico Granata2013-09-301-0/+533
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
OpenPOWER on IntegriCloud