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 [email protected] <mailto:[email protected]>
Xcode Low Level Tools
> On Aug 8, 2016, at 2:40 PM, Kate Stone via lldb-dev <[email protected]>
> 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 [email protected] <mailto:[email protected]>
> Xcode Low Level Tools
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
