[lldb-dev] CORRECTION: LLDB Evolution

[Kate Stone via lldb-dev]

Note that step 5 below is wildly inaccurate, a placeholder while drafting the note.  The actual command to reformat should be:

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.cpp" \) -exec clang-format -i {} +

If you’re curious where the longest lines in the original or resulting source come from you can try the following in an unformatted or post-formatting repository:

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.cpp" \) -exec awk '{ if (length($0) > max) max = length($0) } END { print max " {}" }' {} \; | sort -nr

Kate Stone k8stone at apple.com <mailto:k8stone at apple.com>
 Xcode Low Level Tools

> On Aug 8, 2016, at 2:40 PM, Kate Stone via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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.
> 
> 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.
> 
> Forward-Looking Goals
> 
>    1.	Testing Strategy Evaluation
> 
> 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.)
> 
>    2.	C++ Module Support
> 
> 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.
> 
>    3.	Establishing Language Integration Standards
> 
> 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.
> 
>    4.	Good Citizenship in the LLVM Community
> 
> 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.
> 
> One arbitrary source of inconsistency at present is LLDB’s coding standard.  That brings us to…
> 
> Near-Term Goal: Standardizing on LLVM-style clang-format Rules
> 
> 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:
> 
> Today - mechanical reformatting proposed, comment period begins
> 
> 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:
> Check out a clean copy of the existing repository
> Edit .clang-format in the root of the tree, remove all but the line “BasedOnStyle: LLVM”
> Change your current working directory to the root of the tree to reformat
> Double-check to make sure you did step 3 ;-)
> Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format -i {} +"
> 
> Aug 20th - comment period closes, final schedule proposed
> TBD (early September?) - patches land in svn
> 
> 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.
> 
> Kate Stone k8stone at apple.com <mailto:k8stone at apple.com>
>  Xcode Low Level Tools
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160809/f2162dad/attachment-0001.html>