| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Simplify string comparisons (NFC) (#139394) | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Simplify a string comparison (NFC) (#139932) | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
| 1 年前 | ||
| 1 年前 | ||
Revert " [clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)" (#169397) This reverts commit 3773bbe and relands the last revert attempt 40334b8. 3773bbe broke the build for the build configuration described in here: https://github.com/llvm/llvm-project/pull/165277#issuecomment-3572432250 | 8 个月前 | |
[clang] NFC: rename TagType::getOriginalDecl back to getDecl (#163271) This rename was made as part of https://github.com/llvm/llvm-project/pull/147835 in order to ease rebasing the PR, and give a nice window for other patches to get rebased as well. It has been a while already, so lets go ahead and rename it back. | 9 个月前 | |
[lldb][ClangASTImporter][NFC] Create helper for CanImport Upstreams a CanImport helper for clang::Decls. | 11 个月前 | |
[lldb] Fix dynamic type resolution for types parsed from declarations (#137974) This fixes a regression caused by us starting to parse types from declarations. The code in TypeSystemClang was assuming that the value held in ClangASTMetadata was authoritative, but this isn't (and cannot) be the case when the type is parsed from a forward-declaration. For the fix, I add a new "don't know" state to ClangASTMetadata, and make sure DWARFASTParserClang sets it only when it encounters a forward declaration. In this case, the type system will fall back to completing the type. This does mean that we will be completing more types than before, but I'm hoping this will offset by the fact that we don't search for definition DIEs eagerly. In particular, I don't expect it to make a difference in -fstandalone-debug scenarios, since types will nearly always be present as definitions. To avoid this cost, we'd need to create some sort of a back channel to query the DWARFASTParser about the dynamicness of the type without actually completing it. I'd like to avoid that if it is not necessary. | 1 年前 | |
[lldb] Fix dynamic type resolution for types parsed from declarations (#137974) This fixes a regression caused by us starting to parse types from declarations. The code in TypeSystemClang was assuming that the value held in ClangASTMetadata was authoritative, but this isn't (and cannot) be the case when the type is parsed from a forward-declaration. For the fix, I add a new "don't know" state to ClangASTMetadata, and make sure DWARFASTParserClang sets it only when it encounters a forward declaration. In this case, the type system will fall back to completing the type. This does mean that we will be completing more types than before, but I'm hoping this will offset by the fact that we don't search for definition DIEs eagerly. In particular, I don't expect it to make a difference in -fstandalone-debug scenarios, since types will nearly always be present as definitions. To avoid this cost, we'd need to create some sort of a back channel to query the DWARFASTParser about the dynamicness of the type without actually completing it. I'd like to avoid that if it is not necessary. | 1 年前 | |
[lldb][DeclVendor] Remove ClangDeclVendor (#164380) The ClangDeclVendor used to contain more Clang-specific code than it does nowadays. But at this point, all it does is wrap the DeclVendor::FindDecls call and copy the resulting decls into std::vector<clang::NamedDecl*>. I.e., it converts the generic CompilerDecls to clang::NamedDecl*s. In my opinion at this point it doesn't do enough to justify making it part of the DeclVendor hierarchy. This patch removes the ClangDeclVendor and instead does the conversion at callsite. | 9 个月前 | |
| 1 年前 | ||
[lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (#106442) …NFC] This patch is the first patch in a series reworking of Pete Lawrence's (@PortalPete) amazing proposal for better expression evaluator error messages (https://github.com/llvm/llvm-project/pull/80938) This patch is preparatory patch for improving the rendering of expression evaluator diagnostics. Currently diagnostics are rendered into a string and the command interpreter layer then textually parses words like "error:" to (sometimes) color the output accordingly. In order to enable user interfaces to do better with diagnostics, we need to store them in a machine-readable fromat. This patch does this by adding a new llvm::Error kind wrapping a DiagnosticDetail struct that is used when the error type is eErrorTypeExpression. Multiple diagnostics are modeled using llvm::ErrorList. Right now the extra information is not used by the CommandInterpreter, this will be added in a follow-up patch! | 1 年前 | |
[lldb][DeclVendor] Remove ClangDeclVendor (#164380) The ClangDeclVendor used to contain more Clang-specific code than it does nowadays. But at this point, all it does is wrap the DeclVendor::FindDecls call and copy the resulting decls into std::vector<clang::NamedDecl*>. I.e., it converts the generic CompilerDecls to clang::NamedDecl*s. In my opinion at this point it doesn't do enough to justify making it part of the DeclVendor hierarchy. This patch removes the ClangDeclVendor and instead does the conversion at callsite. | 9 个月前 | |
[lldb][Expression] Remove m_found_function_with_type_info in favour of boolean return (#141774) I've been skimming this code while investigating a bug around module lookup and this looked like something we could clean up. We don't need to be carrying around state inside of NameSearchContext to tell us to look into modules. We can signal this via a boolean return from LookupFunction. | 1 年前 | |
[LLDB] Add some declarations related to REPL support for mojo This simple diff declares some enum values needed to create a REPL for the mojo language. Differential Revision: https://reviews.llvm.org/D150303 | 3 年前 | |
[lldb] Remove unused forward declaration RecordingMemoryManager The corresponding class definition was removed by: commit 8dfb68e0398ef48d41dc8ea058e9aa750b5fc85f Author: Sean Callanan <scallanan@apple.com> Date: Tue Mar 19 00:10:07 2013 +0000 | 3 年前 | |
[clang][NFC] Inline Frontend/FrontendDiagnostic.h -> Basic/DiagnosticFrontend.h (#162883) d076608d58d1ec55016eb747a995511e3a3f72aa moved some deps around to avoid cycles and left clang/Frontend/FrontendDiagnostic.h as a shim that simply includes clang/Basic/DiagnosticFrontend.h. This PR inlines it so that nothing in tree still includes clang/Frontend/FrontendDiagnostic.h. Doing this will help prevent future layering issues. See #162865. Frontend already depends on Basic, so no new deps need to be added anywhere except for places that do strict dep checking. | 8 个月前 | |
[lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation (#161688) Depends on: * https://github.com/llvm/llvm-project/pull/162050 Since it's a 'Note' diagnostic it would only show up when expression evaluation actually failed. This helps with expression evaluation failure reports in mixed language environments where it's not quite clear what language the expression ran as. It may also reduce confusion around why the expression evaluator ran an expression in a language it wasn't asked to run (a softer alternative to what I attempted in https://github.com/llvm/llvm-project/pull/156648). Here are some example outputs: # Without target (lldb) expr blah note: Falling back to default language. Ran expression as 'Objective C++'. # Stopped in target (lldb) expr blah note: Ran expression as 'C++14'. (lldb) expr -l objc -- blah note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'. (lldb) expr -l c -- blah note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'. (lldb) expr -l c++14 -- blah note: Ran expression as 'C++14' (lldb) expr -l c++20 -- blah note: Ran expression as 'C++20' (lldb) expr -l objective-c++ -- blah note: Ran expression as 'Objective C++' (lldb) expr -l D -- blah note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'. I didn't put the diagnostic on the same line as the inline diagnostic for now because of implementation convenience, but if reviewers deem that a blocker I can take a stab at that again. Also, other language plugins (namely Swift), won't immediately benefit from this and will have to emit their own diagnistc. I played around with having a virtual API on UserExpression or ExpressionParser that will be called consistently, but by the time we're about to parse the expression we are already several frames deep into the plugin. Before (and at the beginning of) the generic UserExpression::Parse call we don't have enough information to notify which language we're going to parse in (at least for the C++ plugin). rdar://160297649 rdar://159669244 | 9 个月前 | |
[lldb][ClangModulesDeclVendor] Don't stop loading Clang modules if an individual import failed (#166940) Depends on: * https://github.com/llvm/llvm-project/pull/166917 When loading all Clang modules for a CU, we stop on first error. This means benign module loading errors may stop us from importing actually useful modules. There's no good reason to bail on the first one. The pathological case would be if we try to load a large number of Clang modules but all fail to load for the same reason. That could happen, but in practice I've always seen only a handful of modules failing to load out of a large number. Particularly system modules are useful and usually don't fail to load. Whereas project-specific Clang modules are more likely to fail because the build system moves the modulemap/sources around. This patch accumulates all module loading errors and doesn't stop when an error is encountered. | 8 个月前 | |
[LLDB][ClangExpression] Allow expression evaluation from within C++ Lambdas This patch adds support for evaluating expressions which reference a captured this from within the context of a C++ lambda expression. Currently LLDB doesn't provide Clang with enough information to determine that we're inside a lambda expression and are allowed to access variables on a captured this; instead Clang simply fails to parse the expression. There are two problems to solve here: 1. Make sure clang::Sema doesn't reject the expression due to an illegal member access. 2. Materialize all the captured variables/member variables required to evaluate the expression. To address (1), we currently import the outer structure's AST context onto $__lldb_class, making the contextClass and the NamingClass match, a requirement by clang::Sema::BuildPossibleImplicitMemberExpr. To address (2), we inject all captured variables as locals into the expression source code. **Testing** * Added API test | 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][ClangExpression] Allow expression evaluation from within C++ Lambdas This patch adds support for evaluating expressions which reference a captured this from within the context of a C++ lambda expression. Currently LLDB doesn't provide Clang with enough information to determine that we're inside a lambda expression and are allowed to access variables on a captured this; instead Clang simply fails to parse the expression. There are two problems to solve here: 1. Make sure clang::Sema doesn't reject the expression due to an illegal member access. 2. Materialize all the captured variables/member variables required to evaluate the expression. To address (1), we currently import the outer structure's AST context onto $__lldb_class, making the contextClass and the NamingClass match, a requirement by clang::Sema::BuildPossibleImplicitMemberExpr. To address (2), we inject all captured variables as locals into the expression source code. **Testing** * Added API test | 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] Add some declarations related to REPL support for mojo This simple diff declares some enum values needed to create a REPL for the mojo language. Differential Revision: https://reviews.llvm.org/D150303 | 3 年前 | |
[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152) Part for relanding https://github.com/llvm/llvm-project/pull/122887. I split this to test where the performance regession comes from if modules are not used. | 1 年前 | |
[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152) Part for relanding https://github.com/llvm/llvm-project/pull/122887. I split this to test where the performance regession comes from if modules are not used. | 1 年前 | |
[lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation (#161688) Depends on: * https://github.com/llvm/llvm-project/pull/162050 Since it's a 'Note' diagnostic it would only show up when expression evaluation actually failed. This helps with expression evaluation failure reports in mixed language environments where it's not quite clear what language the expression ran as. It may also reduce confusion around why the expression evaluator ran an expression in a language it wasn't asked to run (a softer alternative to what I attempted in https://github.com/llvm/llvm-project/pull/156648). Here are some example outputs: # Without target (lldb) expr blah note: Falling back to default language. Ran expression as 'Objective C++'. # Stopped in target (lldb) expr blah note: Ran expression as 'C++14'. (lldb) expr -l objc -- blah note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'. (lldb) expr -l c -- blah note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'. (lldb) expr -l c++14 -- blah note: Ran expression as 'C++14' (lldb) expr -l c++20 -- blah note: Ran expression as 'C++20' (lldb) expr -l objective-c++ -- blah note: Ran expression as 'Objective C++' (lldb) expr -l D -- blah note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'. I didn't put the diagnostic on the same line as the inline diagnostic for now because of implementation convenience, but if reviewers deem that a blocker I can take a stab at that again. Also, other language plugins (namely Swift), won't immediately benefit from this and will have to emit their own diagnistc. I played around with having a virtual API on UserExpression or ExpressionParser that will be called consistently, but by the time we're about to parse the expression we are already several frames deep into the plugin. Before (and at the beginning of) the generic UserExpression::Parse call we don't have enough information to notify which language we're going to parse in (at least for the C++ plugin). rdar://160297649 rdar://159669244 | 9 个月前 | |
[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 年前 | |
Revert " [clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)" (#169397) This reverts commit 3773bbe and relands the last revert attempt 40334b8. 3773bbe broke the build for the build configuration described in here: https://github.com/llvm/llvm-project/pull/165277#issuecomment-3572432250 | 8 个月前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
Revert " [clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)" (#169397) This reverts commit 3773bbe and relands the last revert attempt 40334b8. 3773bbe broke the build for the build configuration described in here: https://github.com/llvm/llvm-project/pull/165277#issuecomment-3572432250 | 8 个月前 | |
[lldb][ClangModulesDeclVendor] Revamp error handling when loading Clang modules (#166917) Instead of propagating the errors as a bool+Stream we change the ClangModulesDeclVendor module loading APIs to use llvm::Error. We also reword some of the diagnostics (notably removing the hardcoded error: prefix). A follow-up patch will further make the module loading errors less noisy. See the new tests for what the errors look like. rdar://164002569 | 8 个月前 | |
[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] Add some declarations related to REPL support for mojo This simple diff declares some enum values needed to create a REPL for the mojo language. Differential Revision: https://reviews.llvm.org/D150303 | 3 年前 | |
[lldb][ClangModulesDeclVendor] Print Clang module loading errors to expression log instead of console (#166964) Depends on: * https://github.com/llvm/llvm-project/pull/166917 * https://github.com/llvm/llvm-project/pull/166940 While these errors can contribute to an expression failing, they are never *the* reason the expression failed. I.e., they are always just 'note:' diagnostics that we hand-emit. Because they are quite noisy (and we potentially have many of them if we auto-load all modules in a CU), this patch logs the errors to the expr log, instead of the console. Previously these errors would only get omitted when the expression itself failed. Meaning if the expression failed, we'd dump these 'note' module load errors in next to the actual expression error, obscuring the output. Moreover, if the expression succeeded, any module load errors would be dropped. Now we always log all module loading errors to the expression log, regardless of whether the expression fails or not. | 8 个月前 | |
[lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (#106442) …NFC] This patch is the first patch in a series reworking of Pete Lawrence's (@PortalPete) amazing proposal for better expression evaluator error messages (https://github.com/llvm/llvm-project/pull/80938) This patch is preparatory patch for improving the rendering of expression evaluator diagnostics. Currently diagnostics are rendered into a string and the command interpreter layer then textually parses words like "error:" to (sometimes) color the output accordingly. In order to enable user interfaces to do better with diagnostics, we need to store them in a machine-readable fromat. This patch does this by adding a new llvm::Error kind wrapping a DiagnosticDetail struct that is used when the error type is eErrorTypeExpression. Multiple diagnostics are modeled using llvm::ErrorList. Right now the extra information is not used by the CommandInterpreter, this will be added in a follow-up patch! | 1 年前 | |
[lldb] Add templated CompilerType::GetTypeSystem (NFC) (#140424) Add an overloaded GetTypeSystem to specify the expected type system subclass. Changes code from GetTypeSystem().dyn_cast_or_null<TypeSystemClang>() to GetTypeSystem<TypeSystemClang>(). | 1 年前 | |
[clang] NFC: reintroduce clang/include/clang/AST/Type.h (#155050) This reintroduces Type.h, having earlier been renamed to TypeBase.h, as a redirection to TypeBase.h, and redirects most users to include the former instead. This is a preparatory patch for being able to provide inline definitions for Type methods which would otherwise cause a circular dependency with Decl{,CXX}.h. Doing these operations into their own NFC patch helps the git rename detection logic work, preserving the history. This patch makes clang just a little slower to build (~0.17%), just because it makes more code indirectly include DeclCXX.h. | 11 个月前 | |
[lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation (#161688) Depends on: * https://github.com/llvm/llvm-project/pull/162050 Since it's a 'Note' diagnostic it would only show up when expression evaluation actually failed. This helps with expression evaluation failure reports in mixed language environments where it's not quite clear what language the expression ran as. It may also reduce confusion around why the expression evaluator ran an expression in a language it wasn't asked to run (a softer alternative to what I attempted in https://github.com/llvm/llvm-project/pull/156648). Here are some example outputs: # Without target (lldb) expr blah note: Falling back to default language. Ran expression as 'Objective C++'. # Stopped in target (lldb) expr blah note: Ran expression as 'C++14'. (lldb) expr -l objc -- blah note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'. (lldb) expr -l c -- blah note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'. (lldb) expr -l c++14 -- blah note: Ran expression as 'C++14' (lldb) expr -l c++20 -- blah note: Ran expression as 'C++20' (lldb) expr -l objective-c++ -- blah note: Ran expression as 'Objective C++' (lldb) expr -l D -- blah note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'. I didn't put the diagnostic on the same line as the inline diagnostic for now because of implementation convenience, but if reviewers deem that a blocker I can take a stab at that again. Also, other language plugins (namely Swift), won't immediately benefit from this and will have to emit their own diagnistc. I played around with having a virtual API on UserExpression or ExpressionParser that will be called consistently, but by the time we're about to parse the expression we are already several frames deep into the plugin. Before (and at the beginning of) the generic UserExpression::Parse call we don't have enough information to notify which language we're going to parse in (at least for the C++ plugin). rdar://160297649 rdar://159669244 | 9 个月前 | |
[LLDB] Add some declarations related to REPL support for mojo This simple diff declares some enum values needed to create a REPL for the mojo language. Differential Revision: https://reviews.llvm.org/D150303 | 3 年前 | |
[lldb] Use correct path separator for C++ library files lookup (#98144) Use POSIX-style path separators when checking for libcpp library path. This is necessary to run API tests from 'std-module' group compiled on Windows host for Linux target. | 2 年前 | |
[lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC) There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec. | 3 年前 | |
[lldb] Use *Set::insert_range and a range constructor (NFC) (#133548) This patch uses *Set::insert_range and a range constructor of DenseSet to clean up the code to populate sets. | 1 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb][Expression] Don't create Objective-C IR checker for pure-C++ targets/frames (#144503) There's no need to create this utility function (and run it) for targets/frames that aren't Objective-C/Objective-C++. | 1 年前 | |
[lldb][Expression] Remove IR pointer checker (#144483) Currently when jitting expressions, LLDB scans the IR instructions of the $__lldb_expr and will insert a call to a utility function for each load/store instruction. The purpose of the utility funciton is to dereference the load/store operand. If that operand was an invalid pointer the utility function would trap and LLDB asks the IR checker whether it was responsible for the trap, in which case it prints out an error message saying the expression dereferenced an invalid pointer. This is a lot of setup for not much gain. In fact, creating/running this utility expression shows up as ~2% of the expression evaluation time (though we cache them for subsequent expressions). And the error message we get out of it is arguably less useful than if we hadn't instrumented the IR. It was also untested. Before: (lldb) expr int a = *returns_invalid_ptr() error: Execution was interrupted, reason: Attempted to dereference an invalid pointer.. The process has been returned to the state before expression evaluation. After: (lldb) expr int a = *returns_invalid_ptr() error: Expression execution was interrupted: EXC_BAD_ACCESS (code=1, address=0x5). The process has been returned to the state before expression evaluation. This patch removes this IR checker. | 1 年前 | |
| 1 年前 | ||
[lldb] Avoid calling DataLayout constructor accepting Module pointer (NFC) (#102839) The constructor initializes *this with a copy of M->getDataLayout(), which can just be spelled as DataLayout DL = M->getDataLayout(). In all places where the constructor is used, Module outlives DataLayout, so store a reference to it instead of cloning. Pull Request: https://github.com/llvm/llvm-project/pull/102839 | 1 年前 | |
[llvm][clang] Use the VFS in FileCollector (#160788) This PR changes llvm::FileCollector to use the llvm::vfs::FileSystem API for making file paths absolute instead of using llvm::sys::fs::make_absolute() directly. This matches the behavior of the compiler on most other input files. | 10 个月前 | |
[clang] NFC: rename TagType::getOriginalDecl back to getDecl (#163271) This rename was made as part of https://github.com/llvm/llvm-project/pull/147835 in order to ease rebasing the PR, and give a nice window for other patches to get rebased as well. It has been a while already, so lets go ahead and rename it back. | 9 个月前 | |
[lldb][Expression] Remove m_found_function_with_type_info in favour of boolean return (#141774) I've been skimming this code while investigating a bug around module lookup and this looked like something we could clean up. We don't need to be carrying around state inside of NameSearchContext to tell us to look into modules. We can signal this via a boolean return from LookupFunction. | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 6 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 1 年前 |