summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
* [LLDB] Fix compilation with GCC 5Martin Storsjö2020-02-062-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D74084 (cherry picked from commit 5bbaf543585c54868f8a2bdd9e74edcf395b24b3)
* Data formatters: Look through array element typedefsJaroslav Sevcik2020-01-101-1/+23
| | | | | | | | | | | | | | | | | Summary: Motivation: When formatting an array of typedefed chars, we would like to display the array as a string. The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup. Reviewers: teemperor, clayborg Reviewed By: teemperor, clayborg Subscribers: clayborg, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72133
* TypeCategory: Initialize m_enabled to falseVedant Kumar2019-12-121-1/+1
| | | | | | | | | The initialization was accidentally lost in https://reviews.llvm.org/D71310, causing a ubsan failure: /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35: runtime error: load of value 190, which is not a valid value for type 'bool' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35 in http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake-sanitized/621/consoleText
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-119-266/+6
| | | | | | | | 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
* Remove unsound caching in LanguageCategoryAdrian Prantl2019-12-101-4/+0
| | | | | | | | Analogous to https://reviews.llvm.org/D71233 it is not safe to cache something that depends on the actual ValueObject in a cache then keys only off the type name. Differential Revision: https://reviews.llvm.org/D71297
* Replace redundant code in LanguageCategory with templates (NFC)Adrian Prantl2019-12-101-132/+55
| | | | Differential Revision: https://reviews.llvm.org/D71296
* [FormatManager] Move Language lookup into the obviously non-cached part (NFC)Adrian Prantl2019-12-101-16/+16
| | | | | | | | | | | | | | This refactoring makes the lookup caching easier to reason about. This has no observable effect although it does slightly change what is being cached. - Before this patch a negative lookup in the LanguageCategory would be cached, but a positive wouldn't. - After this patch LanguageCategory lookups aren't cached by FormatManager, period. (LanguageCategory has its own FormatCache for this!) Differential Revision: https://reviews.llvm.org/D71289
* Do not cache hardcoded formats in FormatManagerAdrian Prantl2019-12-101-12/+18
| | | | | | | | | | | | | | The cache in FormatCache uses only a type name as key. The hardcoded formats, synthetic children, etc inspect an entire ValueObject to determine their eligibility, which isn't modelled in the cache. This leads to bugs such as the one in this patch (where two similarly named types in different files have different hardcoded summary providers). The problem is exaggerated in the Swift language plugin due to the language's dynamic nature. rdar://problem/57756763 Differential Revision: https://reviews.llvm.org/D71233
* [DataFormatters] Change the Get() method to take a LanguageType.Davide Italiano2019-12-103-18/+18
| | | | Suggested by Adrian.
* [TypeCategory] IsApplicable gets a LanguageType, not a ValueObject.Davide Italiano2019-12-101-6/+5
| | | | | | | | | | Reviewers: aprantl, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71305
* Replace redundant code in FormatManager and FormatCache with templates (NFC)Adrian Prantl2019-12-104-504/+124
| | | | | | | | | | | | | | | This is a preparatory patch for an upcoming bugfix. FormatManager and friends have four identical implementations of many accessor functions to deal with the four types of shared pointers in the FormatCache. This patch replaces these implementations with templates. While this patch drastically reduces the amount of source code and its maintainablity, it doesn't actually improve code size. I'd argue, this is still an improvement. rdar://problem/57756763 Differential Revision: https://reviews.llvm.org/D71231
* [FormatManager] GetCandidateLanguages shouldn't know about ValueObject.Davide Italiano2019-12-092-4/+5
| | | | | | | | | | Reviewers: jingham, teemperor, JDevlieghere, aprantl Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71236
* [FormatManager] Provide a single entrypoint for GetCandidateLanguages().Davide Italiano2019-12-091-5/+1
|
* [TypeCategory] HasLanguage() is now unused.Davide Italiano2019-12-031-6/+0
|
* [DataVisualization] Simplify. NFCI.Davide Italiano2019-12-031-2/+1
|
* [TypeCategory] Nothing passes down a list of languages.Davide Italiano2019-12-031-7/+3
| | | | | | | | | | | | Summary: This should allow further simplifications, but it's a first step. Reviewers: teemperor, jingham, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70983
* Simplify condition (NFC)Adrian Prantl2019-10-011-1/+1
| | | | llvm-svn: 373352
* Code cleanup: Change FormattersContainer::KeyType from SP to rvalueJan Kratochvil2019-09-042-27/+24
| | | | | | | | | | | There is now std::shared_ptr passed around which is expensive for manycore CPUs. Most of the times (except for 3 cases) it is now just std::moved with no CPU locks needed. It also makes it possible to sort the keys (which is now not needed much after D66398). Differential revision: https://reviews.llvm.org/D67049 llvm-svn: 370863
* [FormatManage] Fix the format info orderJonas Devlieghere2019-08-221-2/+3
| | | | | | | The format info entries need to match the order of the enum entries. This should fix the two failing data-formatter tests. llvm-svn: 369617
* [FormatManager] Add static_assert to keep formats in sync.Jonas Devlieghere2019-08-221-1/+5
| | | | | | | | This adds a static assert that ensures that there's a format info entry for every format enum value. This should prevent others from making the same mistake I made and Jason kindly fixed in r369611. (Thanks!) llvm-svn: 369614
* The g_format_infos table needs to be updated in concert with theJason Molenda2019-08-221-0/+1
| | | | | | | | | enum Format entries; else we can crash in a place like FormatManager::GetFormatAsCString(). We should add bounds checks to prevent this more reliably, but for tonight I'm just adding this entry to keep an address-sanitizer test run working. llvm-svn: 369611
* [NFC] Simplify codeJonas Devlieghere2019-08-211-17/+13
| | | | | | This simplifies the code and updates the comments. llvm-svn: 369491
* Revert "[CompilerType] Simplify the interface a bit more.."Davide Italiano2019-08-061-8/+12
| | | | | | | | There's actually a test downstream that fails with this. I think we can still get rid of it, but I need to do some work there first. llvm-svn: 367963
* [CompilerType] Simplify the interface a bit more..Davide Italiano2019-08-061-12/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: .. removing IsMeaninglessWithoutTypeResolution(). I'm fairly confident this was introduced to support swift, where static types [without dynamic counterpart] don't carry a lot of value. Since then, the formatters and dynamic type resolution has been rewritten, and we employ different solutions. This function is unused here too, so let's get read of it. <rdar://problem/36377967> Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65782 llvm-svn: 367957
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-7/+15
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-242-117/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-237-25/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-151-10/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-262-3/+2
| | | | | | | | | | | | | | This is part two of the change started in r359330. This patch moves the ownership of the script interpreter from the command interpreter into the debugger. I would've preferred to remove the lazy initialization, however the fact that the scripting language is set after the debugger is created makes that tricky. So for now this does exactly the same thing as when it was under the command interpreter. The result is that this patch is fully NFC. Differential revision: https://reviews.llvm.org/D61211 llvm-svn: 359354
* [DataFormatters] Remove LLDB_DISABLE_PYTHON from TypeCategory.Davide Italiano2019-03-152-25/+0
| | | | llvm-svn: 356271
* [DataFormatters] Remove LLDB_DISABLE_PYTHON from FormatManager.Davide Italiano2019-03-152-10/+0
| | | | | | And DataVisualization. One step closer. llvm-svn: 356225
* [DataFormatters] Delete unused code. Not even exposed in the API.Davide Italiano2019-03-142-21/+0
| | | | | | | I stumbled upon this while removing LLDB_DISABLE_PYTHON when not needed. llvm-svn: 356176
* [Python] Start eradicating unneeded LLDB_DISABLE_PYTHON guards.Davide Italiano2019-03-143-8/+0
| | | | | | | While we don't have a bot, I'm testing by hand that this configuration compiles. We'll probably set up one once I'm done flensing. llvm-svn: 356171
* Pass ConstString by value (NFC)Adrian Prantl2019-03-065-23/+23
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-1/+1
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-111-1/+3
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1917-68/+51
| | | | | | | | | | | | | | | | | 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
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-152-4/+5
| | | | | | This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
* Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl2019-01-152-13/+18
| | | | | | | | | | | | | | | | | | | | | | | The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-141-3/+2
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* Simplify Boolean expressionsJonas Devlieghere2018-12-1510-26/+22
| | | | | | | | | | | 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-1115-60/+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-305-55/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use exact equality for category language matching, for all languages, except ↵Vadim Chugunov2017-06-061-18/+3
| | | | | | those specifically mentioned. llvm-svn: 304832
* Rename Error -> Status.Zachary Turner2017-05-122-7/+7
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Stop calling ValueObject::SetName from synthetic child providersTamas Berghammer2017-03-311-6/+4
| | | | | | | | | | | | | | | Summary: Calling ValueObject::SetName from a sythetic child provider would change the underying value object used for the non-synthetic child as well what is clearly unintentional. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31371 llvm-svn: 299259
* 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 DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Isolate Target-specific functionality of DataExtractor.Zachary Turner2017-03-031-3/+5
| | | | | | | | | | | | | | | | In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
OpenPOWER on IntegriCloud