<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="" style="font-family: HelveticaNeue;">LLDB has come a long way since the project was first announced. As a robust debugger for C-family languages and Swift, LLDB is constantly in use by millions of developers. It has also become a foundation for bringing up debugger support for other languages like Go and RenderScript. In addition to the original macOS implementation the Linux LLDB port is in active use and Windows support has made significant strides. IDE and editor integration via both SB APIs and MI have made LLDB available to even more users. It’s definitely a project every contributor can be proud of and I’d like to take a moment to thank everyone who has been involved in one way or another.</div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class="" style="font-family: HelveticaNeue;">It’s also a project that shows some signs of strain due to its rapid growth. We’ve accumulated some technical debt that must be paid off, and in general it seems like a good time to reflect on where we'll be headed next. We’ve outlined a few goals for discussion below as well as one more short-term action. Discussion is very much encouraged.</div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class="" style="font-family: HelveticaNeue;"><b class="">Forward-Looking Goals</b></div><div class="" style="font-family: HelveticaNeue;"><br class=""></div><div class="" style="font-family: HelveticaNeue;"> 1.<span class="Apple-tab-span" style="white-space: pre;"> </span>Testing Strategy Evaluation</div><div class="" style="font-family: HelveticaNeue;"><br class=""></div></div><blockquote class="" style="font-family: HelveticaNeue; margin: 0px 0px 0px 40px; border: none; padding: 0px;">Keeping our code base healthy is next to impossible without a robust testing strategy. Our existing suite of tests is straightforward to run locally, and serves as a foundation for continuous integration. That said, it is definitely not exhaustive. Obvious priorities for improvement include gathering coverage information, investing in more conventional unit tests in addition to the suite of end-to-end tests, and introducing tests in code bases where we depend on debugger-specific behavior (e.g.: for expression evaluation.)</blockquote><div class="" style="font-family: HelveticaNeue;"><div class=""><br class=""></div><div class=""> 2.<span class="Apple-tab-span" style="white-space: pre;"> </span>C++ Module Support</div><div class=""><br class=""></div></div><blockquote class="" style="font-family: HelveticaNeue; margin: 0px 0px 0px 40px; border: none; padding: 0px;">LLDB takes advantage of Clang modules for type information and expression evaluation. This has been used extensively for C and Objective-C scenarios, but Clang C++ module support is now mature enough that we can extend our support accordingly. Fully embracing C++ modules will enable LLDB expressions to take advantage of template declarations and other constructs that are better represented by declarations than the artifacts produced during compilation.</blockquote><div class="" style="font-family: HelveticaNeue;"><div class=""><br class=""></div><div class=""> 3.<span class="Apple-tab-span" style="white-space: pre;"> </span>Establishing Language Integration Standards</div><div class=""><br class=""></div></div><blockquote class="" style="font-family: HelveticaNeue; margin: 0px 0px 0px 40px; border: none; padding: 0px;">As more languages build on LLDB’s foundation the project runs the risk of growing deep dependencies on a wide variety of compilers and runtimes. The community needs to engage in a constructive conversation about how best to keep the core of LLDB clean and allow language support to be plugged in. Whether this should occur at compile-time or runtime and how best to organize repositories and branches to meet the needs of our diverse community will be an ongoing topic of discussion.</blockquote><div class="" style="font-family: HelveticaNeue;"><div class=""><br class=""></div><div class=""><div class=""><div class=""> 4.<span class="Apple-tab-span" style="white-space: pre;"> </span>Good Citizenship in the LLVM Community</div><div class=""><br class=""></div></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">Last, but definitely not least, LLDB should endeavor to be a good citizen of the LLVM community. We should encourage developers to think of the technology stack as a coherent effort, where common code should be introduced at an appropriate level in the stack. Opportunities to factor reusable aspects of the LLDB code base up the stack into LLVM will be pursued.</div><div class=""><br class=""></div><div class="">One arbitrary source of inconsistency at present is LLDB’s coding standard. That brings us to…</div><div class=""><br class=""></div></blockquote><div class=""></div></div></div><div class="" style="font-family: HelveticaNeue;"><div class=""><b class="">Near-Term Goal: Standardizing on LLVM-style clang-format Rules</b></div><div class=""><br class=""></div><div class="">We’ve heard from several in the community that would prefer to have a single code formatting style to further unify the two code bases. Using clang-format with the default LLVM conventions would simplify code migration, editor configuration, and coding habits for developers who work in multiple LLVM projects. There are non-trivial implications to reformatting a code base with this much history. It can obfuscate history and impact downstream projects by complicating merges. Ideally, it should be done once with as much advance notice as is practical. Here’s the timeline we’re proposing:</div><div class=""><br class=""></div><div class=""><b class="">Today</b> - mechanical reformatting proposed, comment period begins</div><div class=""><br class=""></div></div><blockquote class="" style="font-family: HelveticaNeue; margin: 0px 0px 0px 40px; border: none; padding: 0px;">To get a preview of what straightforward reformatting of the code looks like, just follow these steps to get a clean copy of the repository and reformat it:</blockquote><blockquote class="" style="font-family: HelveticaNeue; margin: 0px 0px 0px 40px; border: none; padding: 0px;"><ol class=""><li class="">Check out a clean copy of the existing repository</li><li class="">Edit .clang-format in the root of the tree, remove all but the line “BasedOnStyle: LLVM”</li><li class="">Change your current working directory to the root of the tree to reformat</li><li class="">Double-check to make sure you did step 3 ;-)</li><li class="">Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format -i {} +"</li></ol></blockquote><br class="" style="font-family: HelveticaNeue;"><div class="" style="font-family: HelveticaNeue;"><div class=""><b class="">Aug 20th</b> - comment period closes, final schedule proposed</div><div class=""><b class="">TBD (early September?)</b> - patches land in svn</div><div class=""><br class=""></div><div class="">The purpose of the comment period is to review the straightforward diffs to identify areas where comment pragmas should be used to avoid undesirable formatting (tables laid out in code are a classic example.) It’s also a time when feedback on the final timetable can be discussed, and any unforeseen implications can be discovered. We understand that LLDB tends toward relatively long names that may not always work well with the LLVM convention of wrapping at 80 columns. Worst case scenarios will be evaluated to determine the desired course of action.</div><div class=""><br class=""></div></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="" style="font-family: LucidaGrande; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font color="#424242" class="" style="font-family: 'Lucida Grande'; font-size: x-small;">Kate Stone</font><span class="" style="font-family: 'Lucida Grande'; font-size: x-small;"> </span><font color="#009193" class="" style="font-family: 'Lucida Grande'; font-size: x-small;"><a href="mailto:k8stone@apple.com" class="">k8stone@apple.com</a></font></div><div class="" style="font-family: Times; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font face="Lucida Grande" size="1" class=""><font color="#009193" class=""></font> Xcode <font color="#424242" class="">Low Level Tools</font></font></div></div></div></div></div></div>
</div>
<br class=""></body></html>