| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets. This patch improves data formatting for CoreFoundation containers: CFDictionary and CFSet. These data formatters make the containers and their children appear in Xcode's variables view (and on the command line) without having to expand the data structure. Previous implementation only supported showing the container's element count. (lldb) frame var dict (__NSCFDictionary *) dict = 0x00000001004062b0 2 key/value pairs (lldb) frame var set (__NSCFSet *) set = 0x0000000100406330 2 elements Now the variable can be dereferenced to dispaly the container's children: (lldb) frame var *dict (__NSCFDictionary) *dict = { [0] = { key = 0x0000000100004050 @"123" value = 0x0000000100004090 @"456" } [1] = { key = 0x0000000100004030 @"abc" value = 0x0000000100004070 @"def" } } (lldb) frame var *set (__NSCFSet) *set = { [0] = 0x0000000100004050 @"123" [1] = 0x0000000100004030 @"abc" } rdar://39882287 Differential Revision: https://reviews.llvm.org/D78396 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> | 6 年前 | |
[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from scan.coverity.com: 1094796 1095721 1095728 1095737 1095741 1095756 1095779 1095789 1095805 1214552 1229457 1232475 1274006 1274010 1293427 1364800 1364802 1364804 1364812 1364816 1374902 1374909 1384975 1399312 1420451 1431704 1454230 1454554 1454615 1454579 1454594 1454832 1457759 1458696 1461909 1467658 1487814 1487830 1487845 Differential Revision: https://reviews.llvm.org/D130098 | 3 年前 | |
[lldb/cmake] Remove EXTRA_CXXFLAGS arg (#143731) We have one library using this and three libraries directly calling target_compile_options. Might as well standardize on the latter. | 1 年前 | |
[lldb] Upgrade GetIndexOfChildWithName to use llvm::Expected (#136693) This patch replaces the use of UINT32_MAX as the error return value of GetIndexOfChildWithName with llvm::Expected. # Tasks to do in another PR 1. Replace CalculateNumChildrenIgnoringErrors with CalculateNumChildren. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update lldb_private::formatters::ExtractIndexFromString to use llvm::Expected. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608). | 1 年前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
Make CompilerType safe When a process gets restarted TypeSystem objects associated with it may get deleted, and any CompilerType objects holding on to a reference to that type system are a use-after-free in waiting. Because of the SBAPI, we don't have tight control over where CompilerTypes go and when they are used. This is particularly a problem in the Swift plugin, where the scratch TypeSystem can be restarted while the process is still running. The Swift plugin has a lock to prevent abuse, but where there's a lock there can be bugs. This patch changes CompilerType to store a std::weak_ptr<TypeSystem>. Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by introducing a wrapper class CompilerType::WrappedTypeSystem that has a dyn_cast_or_null() method. The only sites that need to know about the weak pointer implementation detail are the ones that deal with creating TypeSystems. rdar://101505232 Differential Revision: https://reviews.llvm.org/D136650 | 3 年前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb][DataFormatters] Change ExtractIndexFromString to return std::optional (#138297) This PR is in continuation of https://github.com/llvm/llvm-project/pull/136693. | 1 年前 | |
[clang] Improve nested name specifier AST representation (#147835) This is a major change on how we represent nested name qualifications in the AST. * The nested name specifier itself and how it's stored is changed. The prefixes for types are handled within the type hierarchy, which makes canonicalization for them super cheap, no memory allocation required. Also translating a type into nested name specifier form becomes a no-op. An identifier is stored as a DependentNameType. The nested name specifier gains a lightweight handle class, to be used instead of passing around pointers, which is similar to what is implemented for TemplateName. There is still one free bit available, and this handle can be used within a PointerUnion and PointerIntPair, which should keep bit-packing aficionados happy. * The ElaboratedType node is removed, all type nodes in which it could previously apply to can now store the elaborated keyword and name qualifier, tail allocating when present. * TagTypes can now point to the exact declaration found when producing these, as opposed to the previous situation of there only existing one TagType per entity. This increases the amount of type sugar retained, and can have several applications, for example in tracking module ownership, and other tools which care about source file origins, such as IWYU. These TagTypes are lazily allocated, in order to limit the increase in AST size. This patch offers a great performance benefit. It greatly improves compilation time for [stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for test_on2.cpp in that project, which is the slowest compiling test, this patch improves -c compilation time by about 7.2%, with the -fsyntax-only improvement being at ~12%. This has great results on compile-time-tracker as well:  This patch also further enables other optimziations in the future, and will reduce the performance impact of template specialization resugaring when that lands. It has some other miscelaneous drive-by fixes. About the review: Yes the patch is huge, sorry about that. Part of the reason is that I started by the nested name specifier part, before the ElaboratedType part, but that had a huge performance downside, as ElaboratedType is a big performance hog. I didn't have the steam to go back and change the patch after the fact. There is also a lot of internal API changes, and it made sense to remove ElaboratedType in one go, versus removing it from one type at a time, as that would present much more churn to the users. Also, the nested name specifier having a different API avoids missing changes related to how prefixes work now, which could make existing code compile but not work. How to review: The important changes are all in clang/include/clang/AST and clang/lib/AST, with also important changes in clang/lib/Sema/TreeTransform.h. The rest and bulk of the changes are mostly consequences of the changes in API. PS: TagType::getDecl is renamed to getOriginalDecl in this patch, just for easier to rebasing. I plan to rename it back after this lands. Fixes #136624 Fixes https://github.com/llvm/llvm-project/issues/43179 Fixes https://github.com/llvm/llvm-project/issues/68670 Fixes https://github.com/llvm/llvm-project/issues/92757 | 11 个月前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb] Upgrade GetIndexOfChildWithName to use llvm::Expected (#136693) This patch replaces the use of UINT32_MAX as the error return value of GetIndexOfChildWithName with llvm::Expected. # Tasks to do in another PR 1. Replace CalculateNumChildrenIgnoringErrors with CalculateNumChildren. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update lldb_private::formatters::ExtractIndexFromString to use llvm::Expected. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608). | 1 年前 | |
[lldb] Upgrade GetIndexOfChildWithName to use llvm::Expected (#136693) This patch replaces the use of UINT32_MAX as the error return value of GetIndexOfChildWithName with llvm::Expected. # Tasks to do in another PR 1. Replace CalculateNumChildrenIgnoringErrors with CalculateNumChildren. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update lldb_private::formatters::ExtractIndexFromString to use llvm::Expected. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608). | 1 年前 | |
[lldb][DataFormatters] Change ExtractIndexFromString to return std::optional (#138297) This PR is in continuation of https://github.com/llvm/llvm-project/pull/136693. | 1 年前 | |
[NFC][lldb] Remove duplicated checks (#169093) Removed duplicated checks reported by cppcheck | 8 个月前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb] Add summary for NSIndirectTaggedPointerString (#136025) rdar://143164164 | 1 年前 | |
[lldb] Add summary for NSIndirectTaggedPointerString (#136025) rdar://143164164 | 1 年前 | |
[lldb] Move Objective-C constants into ObjCConstants.h Move Objective-C constants into ObjCConstants.h and share them between Cocoa and AppleObjCTypeEncodingParser. Differential revision: https://reviews.llvm.org/D107679 | 4 年前 | |
[lldb][ObjC][NFC] Rewrite IsPossibleObjCMethodName in terms of llvm::StringRef (#167660) We've seen some crashes around this area (particularly around checking/handling raw C-strings). Dealing with StringRefs makes it a bit easier to reason about. This doesn't fix anything per se, but is an improvement in readability. rdar://164519648 | 8 个月前 | |
[lldb][ObjC][NFC] Rewrite IsPossibleObjCMethodName in terms of llvm::StringRef (#167660) We've seen some crashes around this area (particularly around checking/handling raw C-strings). Dealing with StringRefs makes it a bit easier to reason about. This doesn't fix anything per se, but is an improvement in readability. rdar://164519648 | 8 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 8 个月前 | ||
| 8 个月前 |