Summary: Following up to my CPPLanguageRuntime change, I'm moving ObjCLanguageRuntime into a plugin as well. Reviewers: JDevlieghere, compnerd, jingham, clayborg Subscribers: mgorny, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D64763 llvm-svn: 366148
Summary: Instead of hardcoding ClangASTContext and ObjCLanguageRuntime, we can generalize this by creating the method GetRuntimeType in LanguageRuntime and moving the current MaybeCalculateCompleteType implementation into ObjCLanguageruntime::GetRuntimeType Reviewers: jingham, clayborg, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D64159 llvm-svn: 365939
Summary: Instead of falling back to ObjCLanguageRuntime, we should be falling back to every loaded language runtime. This makes ValueObject more language agnostic. Reviewers: labath, compnerd, JDevlieghere, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D63240 llvm-svn: 364845
Summary: ObjCLanguageRuntime was being pulled into LanguageRuntime because of Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint, we can extend the LanguageRuntime plugin interface so that LanguageRuntimes can give us a BreakpointPrecondition for exceptions. Differential Revision: https://reviews.llvm.org/D63181 llvm-svn: 364098
Summary: Using llvm-style rtti gives us stronger guarantees around casting LanguageRuntimes. As discussed in D62755 Differential Revision: https://reviews.llvm.org/D62934 llvm-svn: 362884
by respecting the "artificial" attribute on variables. Function arguments that are artificial and useful to end-users are being whitelisted by the language runtime. <rdar://problem/45322477> Differential Revision: https://reviews.llvm.org/D61451 llvm-svn: 359841
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
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
The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
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