[lldb-dev] LLDB Evolution

[Zachary Turner via lldb-dev]

On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
> *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:
>
>
>    1. Check out a clean copy of the existing repository
>    2. Edit .clang-format in the root of the tree, remove all but the line
>    “BasedOnStyle: LLVM”
>    3. Change your current working directory to the root of the tree to
>    reformat
>    4. Double-check to make sure you did step 3 ;-)
>    5. 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.
>

One thing we will need to take a look at is functions which have a very
deep indentation level. They have the potential to be made really ugly by
clang-format.  The default indentation will be reduced from 4 to 2, so that
will help, but I recall we had some lines that began very far to the right.


Here's a little bash command shows all lines with >= 50 leading spaces,
sorted in descending order by number of leading spaces.

grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n",
$0, t-length($0));}' |  sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; {
if ($3 >= 50) print $0 }'

It's less useful than I was hoping because most of the lines are noise
(line breaking in a function parameter list).

If there were a way to detect indentation level that would be better.
Mostly just to identify places that we should manually inspect after
running clang-format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160809/7c674e92/attachment.html>