Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-02-06T09:54:24+00:00 2020-02-06T09:54:24+00:00 Martin Storsjö martin@martin.st 2020-02-05T20:29:59+00:00 urn:sha1:22633f85bb7d317ff97c86b6ae7817b678777d93 Differential Revision: https://reviews.llvm.org/D74084 (cherry picked from commit 5bbaf543585c54868f8a2bdd9e74edcf395b24b3) 2020-01-10T10:45:24+00:00 Jaroslav Sevcik jarin@google.com 2020-01-10T10:44:14+00:00 urn:sha1:902974277d507a149e33487d32e4ba58c41451b6 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 2019-12-12T19:39:41+00:00 Vedant Kumar vsk@apple.com 2019-12-12T19:08:56+00:00 urn:sha1:46d970cc436068af826e5f6a59033dd0f10c570d 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 2019-12-11T17:27:12+00:00 Adrian Prantl aprantl@apple.com 2019-12-10T23:32:57+00:00 urn:sha1:ee64dfd953f89a9d3df3c13a28b1bce33f33f4cb 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 2019-12-11T00:11:10+00:00 Adrian Prantl aprantl@apple.com 2019-12-10T22:29:13+00:00 urn:sha1:2fb07b90dc1c2c08fe6fc69c9d569a1fc2c8a8e1 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 2019-12-11T00:11:10+00:00 Adrian Prantl aprantl@apple.com 2019-12-10T21:22:03+00:00 urn:sha1:b3801de7c50faa2b730e62e1cfabeec8c5cebae2 Differential Revision: https://reviews.llvm.org/D71296 2019-12-10T23:57:53+00:00 Adrian Prantl aprantl@apple.com 2019-12-10T18:58:06+00:00 urn:sha1:70e3d0ea55e8b9385168d389fcba16a283f20214 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 2019-12-10T23:53:40+00:00 Adrian Prantl aprantl@apple.com 2019-12-10T00:38:19+00:00 urn:sha1:62a6d9770450f93a2dcdf04710a73341af2f54fa 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 2019-12-10T23:21:24+00:00 Davide Italiano ditaliano@apple.com 2019-12-10T23:20:49+00:00 urn:sha1:f387b99745101d5843d397a2a65dc4102c6f8e14 Suggested by Adrian. 2019-12-10T22:59:34+00:00 Davide Italiano ditaliano@apple.com 2019-12-10T22:44:51+00:00 urn:sha1:bbcdcea4bf8423041108e22dc619f7d5fdae9870 Reviewers: aprantl, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71305