Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-28T14:20:19+00:00 2019-12-28T14:20:19+00:00 Raphael Isemann teemperor@gmail.com 2019-12-28T13:35:07+00:00 urn:sha1:8612e92ed590e615f9f56e4fb86a1fdaf3a39e15 Instead of returning NamedDecls and then calling GetASTContext to find back the ClangASTContext we used can just implement the FindDecl variant that returns CompilerDecls (and implement the other function by throwing away the ClangASTContext part of the compiler decl). 2019-12-17T11:24:31+00:00 Raphael Isemann teemperor@gmail.com 2019-12-17T11:22:34+00:00 urn:sha1:ff0102b32cfe506dfc16a86e38e70b0940697aa2 Summary: As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup. This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around for now). The motivation for this is that I don't think that the current approach of implementing modern-type-lookup will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has so far made the transition work much more complicated than it has to be. A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring and actually testing the existing code we have. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html Reviewers: shafik, martong Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss Tags: #lldb Differential Revision: https://reviews.llvm.org/D71562 2019-11-23T16:56:23+00:00 Raphael Isemann risemann@apple.com 2019-11-23T16:56:05+00:00 urn:sha1:7af53d75c60bf5c09157daeebff86b9e594bf1ee That happened in 20d51b2f14ac4488f684f8f but LLDB wasn't updated. 2019-10-01T12:55:37+00:00 Raphael Isemann teemperor@gmail.com 2019-10-01T12:55:37+00:00 urn:sha1:c73bfc98f81ee353db90303acfbcd4dcd494e57e We have no use case in LLDB where we actually do want to change the ASTContext after it the ClangASTContext has been constructed. All callers of setASTContext are just setting the ASTContext directly after construction, so we might as well make this a Constructor instead of supporting this tricky use case. llvm-svn: 373330 2019-10-01T09:02:05+00:00 Raphael Isemann teemperor@gmail.com 2019-10-01T09:02:05+00:00 urn:sha1:cf62871488486c6a76c71a3135af26e82a238822 NFC preparation work for upcoming ExternalASTMerger patches. llvm-svn: 373312 2019-08-20T18:47:30+00:00 Alex Langford apl@fb.com 2019-08-20T18:47:30+00:00 urn:sha1:1271521ed887308abeb740f2e738c2d3333febc8 Summary: This introduces a layer between DeclVendor and the currently implemented DeclVendors (ClangModulesDeclVendor and AppleObjCDeclVendor). This allows the removal of DeclVendor::GetImporterSource which is extremely clang-specific, freeing up the interface to be more general. A good follow up to this would be to remove the remaining instances of clang in DeclVendor, either by moving things to ClangDeclVendor or by using wrappers (e.g. CompilerDecl instead of clang::NamedDecl). Differential Revision: https://reviews.llvm.org/D66451 llvm-svn: 369424 2019-08-01T21:32:04+00:00 Harlan Haskins harlan@harlanhaskins.com 2019-08-01T21:32:04+00:00 urn:sha1:84586c1423aae1ca12f5203215b0eeb7c148ed6d Summary: Currently, clang's FileManager uses NULL as an indicator that a particular file did not exist, but would not propagate errors like permission issues. Instead, teach FileManager to use llvm::ErrorOr internally and return rich errors for failures. Reviewers: arphaman, bruno, martong, shafik Subscribers: nemanjai, kbarton, MaskRay, jkorous, dexonsmith, kadircet, jsji, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D65534 llvm-svn: 367618 2019-07-21T10:31:13+00:00 Raphael Isemann teemperor@gmail.com 2019-07-21T10:31:13+00:00 urn:sha1:ca9dfdfaecaa13fc075858a2965fd2f43e7bc8e1 Summary: We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext. However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up crashing whenever we create a CompilerType for one of these types. Simplest way to trigger this bug is to just look up NSObject from a module: (lldb) expr @import Foundation (lldb) type lookup NSObject Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39. This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor. Reviewers: davide, shafik Reviewed By: davide Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64989 llvm-svn: 366653 2019-07-17T16:51:16+00:00 Raphael Isemann teemperor@gmail.com 2019-07-17T16:51:16+00:00 urn:sha1:3fce6b5da169c77c4047a4632f28b41d33d7c0a9 Summary: Currently the ClangModulesDeclVendor is spamming the expression log with the compiler flags it is using, which creates a log that looks like this: ``` clang -fmodules -fimplicit-module-maps ``` This patch removes all these newlines and just prints the compiler flags in one line as you see in the command line: ``` clang -fmodules -fimplicit-module-maps [...] ``` Reviewers: shafik, davide Reviewed By: davide Subscribers: davide, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64858 llvm-svn: 366347 2019-04-23T20:17:04+00:00 Frederic Riss friss@apple.com 2019-04-23T20:17:04+00:00 urn:sha1:acbf0058e93d3a8f95ea3ace586f99320ce1c425 Before a Debugger gets a Target, target settings are routed to a global set of settings. Even without this, some part of the LLDB which exist independently of the Debugger object (the Module cache, the Symbol vendors, ...) access directly the global default store for those settings. Of course, if you modify one of those global settings while they are being read, bad things happen. We see this quite a bit with FileSpecList settings. In particular, we see many cases where one debug session changes target.exec-search-paths while another session starts up and it crashes when one of those accesses invalid FileSpecs. This patch addresses the specific FileSpecList issue by adding locking to OptionValueFileSpecList and never returning by reference. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60468 llvm-svn: 359028